移动端推理引擎赛道 — 核心技术难点

基于 ncnn / MNN / ONNX Runtime / TNN / Paddle-Lite / MACE 源码调研 调研时间：2026-06-22

难点总览

1. SIMD 内存布局与通用性的矛盾

核心矛盾：要让 SIMD 指令（NEON/SSE/AVX）跑满带宽，数据必须按特定方式排列；但”特定方式”在不同硬件上不一样。

日常类比：超市货架上商品要方便拿取，就得按”最常被一起购买”的方式摆放。但不同顾客的购物组合不同——把薯片放在可乐旁边方便聚会党，却让健身党多走一段路去找蛋白粉。

真实案例：

ncnn 的 elempack 设计把”打包多少个 channel”变成一个动态参数：NEON 设备上 elempack=4（128-bit），AVX 设备上 elempack=8（256-bit），AVX-512 设备上 elempack=16（512-bit）。代价是每当相邻两层的 elempack 不同时，需要插入 convert_packing 操作——相当于超市要频繁重新摆货。

层 A (elempack=8, AVX) → [convert_packing] → 层 B (elempack=4, NEON fallback)
                              ↑ 额外内存拷贝 + 格式变换

MNN/TNN 选择固定的 NC4HW4 布局——channel 维度永远按 4 打包。好处是全链路布局统一，不需要中间转换。坏处是在 AVX-512（512-bit = 16 个 float）设备上浪费了 75% 的 SIMD 宽度。

MACE 对 OpenCL GPU 更极端——定义了 8 种 image2d 映射方式（CONV2D_FILTER、IN_OUT_CHANNEL、WINOGRAD_FILTER 等），每种 Op 选最优映射。格式转换代码膨胀到难以维护的程度。

根本难点：硬件 SIMD 宽度在持续演进（ARM SVE 甚至是可变长度向量），但推理引擎的内存布局是”编译时决策”——一旦选定就贯穿整个推理栈。没有哪种布局能同时对所有硬件最优。你要么像 ncnn 那样承受动态转换的开销，要么像 MNN 那样接受”对部分硬件不是最优”的妥协。

2. 算子爆炸：Op × Backend × Precision 组合地狱

核心矛盾：深度学习模型有 200+ 种算子，每种算子在不同硬件上需要不同的优化实现，再乘以精度（fp32/fp16/int8/bf16）维度，工程量呈指数增长。

日常类比：一家连锁餐厅有 200 道菜（Op），在 6 个城市开店（Backend），每家店还要出大份/中份/小份（Precision）。理论上需要 200×6×3 = 3600 个独立的备料方案。任何一家现实中的连锁店都不会这么干——必须找到复用策略。

真实案例：

Paddle-Lite 的三维坐标系 (Target, Precision, Layout) 最直白地暴露了这个问题。static_kernel_pick_pass 要在这个三维空间中为每个 Op 选最优 Kernel，相邻 Op 的坐标不匹配时自动插入三类 cast：

type_target_cast_pass   ← 跨设备拷贝 (ARM → OpenCL)
type_precision_cast_pass ← 精度转换 (fp32 → int8)
type_layout_cast_pass   ← 布局变换 (NCHW → NHWC)

MNN 用 Geometry Compiler 降维打击这个问题：非计算密集 Op（Reshape/Transpose/Slice/Concat）不写 kernel，只生成 Region 映射描述。最终统一到 Raster Op 执行。这把”每个 Op × 每个 Backend”降为”核心 Op × Backend + 其余 Op 只写 shape 逻辑”。

传统方式：|Op| × |Backend| 个 kernel 实现 → 200 × 6 = 1200
MNN 方式：核心 Op (~20) × Backend + 其余 Op 只写 GeometryComputer → 120 + 180 = 300

ncnn 的策略是”手写一切”——Convolution_arm.cpp 一个文件内就包含了 1x1/3x3/Winograd/im2col/depthwise 多种路径，按 elempack 和精度再展开。代码极度冗长但性能极致。

根本难点：深度学习算子标准还在快速演进（ONNX 从 opset 7 演进到 opset 21+，每个版本语义可能变化）。ORT 为此需要给同一个 Add 算子维护 opset 7-12 / opset 13 / opset 14+ 三套 kernel。新算子不断涌现，而每个算子的高性能实现需要熟悉底层硬件的工程师花费数周手写优化。优化人才的稀缺性才是真正的瓶颈——不是写不出来，而是没人写。

3. 图优化深度与模型加载延迟的拉锯

核心矛盾：图优化做得越多，推理越快；但优化过程本身消耗时间和内存，拖慢模型加载（首帧延迟）。

日常类比：出门前花 30 分钟规划最优路线，路上能省 10 分钟。如果只出门走 5 分钟的路，规划时间比走路时间还长——得不偿失。

真实案例：

六个引擎的图优化深度差异巨大：

ncnn:        无独立优化 pass → 加载 < 10ms
TNN:         NetOptimizer (conv+bn 融合等) → 加载 ~50ms
MNN:         Geometry Compiler 降级 → 加载 ~100ms
ORT:         图变换链 + EP 分区 → 加载 ~200ms
Paddle-Lite: **50+ MIR pass** → 加载可达 500ms+

Paddle-Lite 的 MIR（Model Intermediate Representation）管线包括 SSAGraph 构建、50+ 个 pass（kernel 选择、3 个维度的 cast 插入、50+ 种算子融合、子图切分、内存优化），对复杂模型的首次加载延迟明显。解决方案是 AOT 离线优化——opt 工具预先跑完所有 pass，生成 .nb 格式，运行时直接加载优化结果。

MNN 的 Geometry Compiler 面临另一个问题：Pipeline::encode() 的四步流水线（SizeCompute → GeometryTransform → onCreate → onResize）需要完整遍历计算图。对动态 Shape 模型，每次输入形状变化都要重跑 encode()——这把”一次性加载成本”变成了”每帧成本”。

根本难点：用户对”打开 App 后第一次用 AI 功能”的等待容忍度极低（<200ms），但复杂模型（如 LLM）的图结构可能有上千个节点。你无法在 200ms 内完成深度优化，又不愿放弃优化带来的持续性能收益。AOT 离线优化是目前的最优妥协，但增加了部署复杂度（需要针对每种目标设备提前编译）。

4. NPU/DSP 黑盒适配：子图切分与 Fallback 的边界

核心矛盾：NPU/DSP 能把部分算子加速 10-100 倍，但它们只支持有限的算子集。一个模型中哪些层走 NPU、哪些层 fallback 回 CPU，这个切分决策的好坏直接决定端到端性能。

日常类比：请了一个很贵的翻译（NPU），他只会翻译英语和法语。一段文字里夹杂了德语（不支持的 Op），你要么把整段话拆开让他翻能翻的部分——但拆来拆去的沟通成本（数据搬运）可能比直接用普通翻译（CPU）还高。

真实案例：

MACE 的 Hexagon 整图下推是最激进的策略——把整个网络定义一次性发给 DSP：

HexagonControlWrapper::SetupGraph(net_def);     // 整图传给 DSP
HexagonControlWrapper::ExecuteGraphNew(...);     // 整图执行

好处是零 CPU↔DSP 数据传输开销。坏处是只要有一个 Op 不被 DSP 支持，整个方案就不可用，必须退回 CPU/GPU 路径。没有中间状态。

ORT 的 EP 分区是最灵活的策略——EP 通过 GetCapability() 声明能处理的节点集合，剩余节点自动落到下一级 EP。但相邻两个 EP 之间的数据传输（自动插入 MemcpyToHost/MemcpyFromHost）可能成为瓶颈：

[TensorRT EP: Conv→BN→ReLU] → MemcpyToHost → [CPU EP: CustomOp] → MemcpyFromHost → [TensorRT EP: Conv→...]
                                    ↑ GPU→CPU→GPU 两次数据搬运

Paddle-Lite 的 NNAdapter 提供了中间方案——validate_program() 先询问硬件”你能跑哪些 Op”，MIR 的 subgraph_pass 据此决定切分边界。但 NPU 厂商的算子支持列表经常不准确（标称支持但实际精度不达标或有 shape 限制），导致运行时才发现问题。

根本难点：NPU 是黑盒——你不知道内部实现细节，只有一个”支持/不支持”的二值答案。实际中还存在”支持但性能反而不如 CPU”的灰色地带（比如小 tensor 走 NPU 的调度开销大于计算收益）。最优切分需要运行时 profiling，但 profiling 本身有成本。这本质上是一个信息不完全的优化问题。

5. 内存峰值控制与计算并行的冲突

核心矛盾：要降低内存峰值，就要及时释放中间结果（用完即弃）；但要支持计算并行或分支合并，中间结果必须保留更长时间。

日常类比：做饭时灶台空间有限（内存）。你想同时开两个锅（并行计算），就需要两个锅同时占灶台。如果灶台只放得下一个锅（内存紧张），只能做完一个菜再做下一个——速度变慢但空间够用。

真实案例：

ncnn 的 Light mode 是最激进的内存回收策略——中间 blob 被下游层消费后立即释放：

层A output → 层B 消费 → 立即释放层A output → 层C 无法再访问

配合按需递归（只计算被请求的输出链路），未触及的分支不分配任何内存。这在单路推理场景下内存峰值极低。但代价是：如果后续想取另一个中间层的输出（比如做特征可视化或多任务输出），需要重新计算整条链路。

ORT 的 SequentialExecutionPlan 做生命周期分析——生命周期不重叠的 tensor 共享同一块 buffer。但在有分支合并（如 ResNet 的 skip connection）的网络中，跨越多层的 tensor 生命周期很长，挤压了其他 tensor 的复用空间。

MACE 的 MemoryManager 提供 4 种租用方式：

RENT_PRIVATE  ← 权重独占，不可复用
RENT_SHARE    ← Op 输出间共享（生命周期不重叠时复用）
RENT_SCRATCH  ← 临时缓冲区，用完即弃
RENT_SLICE    ← 从模型数据零拷贝切片

根本难点：最优内存规划是一个 NP-hard 问题（本质上是区间着色问题/寄存器分配问题）。移动设备内存通常 2-6 GB，而大模型（如 LLM）的 KV-Cache 可能占数 GB。当你同时运行多个模型（OCR + 翻译 + 语音）时，内存峰值控制变成系统级问题——不是单个引擎能解决的。

6. 动态 Shape 推理对静态优化栈的颠覆

核心矛盾：大量图优化（算子融合、内存预分配、kernel 选择）依赖于编译时已知的 tensor 形状；但真实应用中输入尺寸经常变化（不同分辨率的图片、不同长度的文本序列）。

日常类比：工厂流水线（静态优化）一旦设定好就效率极高，但只能生产一种尺寸的产品。现在客户要求”每件产品尺寸都可能不同”——流水线的优势瞬间消失，得退回手工作坊模式。

真实案例：

MNN 的四步 Pipeline encode 流程对动态 Shape 的影响最为突出：

Pipeline::encode() → (1) SizeCompute → (2) GeometryTransform → (3) onCreate → (4) onResize

当输入 shape 变化时，步骤 (1)(2)(4) 都需要重新执行——(1) 重新推导所有中间 tensor 形状，(2) 重新生成 Region 映射，(4) 重新分配临时内存。只有 (3) 创建的 Execution 对象可以复用。对于逐帧 shape 变化的视频处理场景，这个重计算开销不可忽略。

ncnn 的按需递归策略在动态 Shape 下反而有优势——不做全局内存预分配，每次推理时按实际 shape 即时分配。但失去了内存复用的优化空间。

Paddle-Lite 的 50+ MIR pass 中，很多 pass 假设形状已知（如算子融合判断两个 conv 能否合并取决于 tensor 维度）。动态 Shape 模型走不了这些 pass，相当于放弃了大部分离线优化收益。

根本难点：静态 shape 是整个优化栈的基石——从内存池大小、Winograd tile 选择、到 GPU workgroup 配置都依赖已知形状。动态 shape 的本质是把”编译时优化”退化为”运行时决策”——每一步都要重新判断，消除了预计算的收益。目前没有引擎能优雅地同时做到”深度静态优化”和”灵活动态适配”。

7. GPU 路径碎片化：Vulkan vs OpenCL vs Metal

核心矛盾：移动端没有统一的 GPU 计算标准。iOS 只有 Metal，Android 的 OpenCL 驱动质量参差不齐，Vulkan Compute 是最新标准但生态不成熟。选哪条路，就决定了你的平台覆盖和性能天花板。

日常类比：想在全国开快递站（GPU 加速），但北方只有顺丰网点（Metal），南方只有中通网点（OpenCL），而新建的京东物流（Vulkan）覆盖全国但网点还不够密。你只能选一两家合作，或者花三倍成本全接入。

真实案例：

ncnn 选择 Vulkan——获得了跨平台覆盖（Android/Windows/Linux/macOS 全支持），但需要为每个算子手写 GLSL Compute Shader，编译为 SPIR-V 嵌入二进制。shader 变体数量巨大：

convolution_*.comp:
  - convolution.comp           (通用)
  - convolution_pack4.comp     (elempack=4)
  - convolution_pack8.comp     (elempack=8)
  - convolution_1x1s1d1.comp   (特化尺寸)
  - convolution_3x3s1d1.comp   (特化尺寸)
  ... 几十个变体

MACE 的 OpenCL 路径区分 image2d 和 buffer 两种 GPU 内存模式——8 种 BufferContentType 决定了 tensor 到 image2d 的映射方式。image2d 利用 GPU 纹理缓存的 2D 空间局部性，性能通常优于 buffer 模式，但有尺寸限制（image2d 的宽/高上限因设备而异）。

OpenCL image2d 路径：纹理缓存友好，受 max_image_width/height 限制
OpenCL buffer 路径：无尺寸限制，但无法利用纹理缓存
→ 大 tensor 不得不用 buffer，性能下降 30-50%

MNN/TNN 同时维护 OpenCL + Metal 两套 GPU 后端——每套都有独立的算子实现、内存管理、kernel 编译逻辑。工程量接近”写了两个半引擎”。

根本难点：GPU API 的碎片化是硬件生态的问题，不是软件能解决的。Vulkan 理论上是统一答案，但其 Compute Shader 的调试工具不成熟、各厂商驱动实现质量参差不齐（某些 Android 设备的 Vulkan Compute 性能反而不如 OpenCL）。你选择了最大覆盖面，就要承受最多的兼容性问题。

8. 量化精度损失与校准成本

核心矛盾：INT8 量化能带来 2-4 倍推理加速和 75% 模型体积缩减，但精度损失可能让模型不可用。校准（calibration）需要代表性数据和大量实验，与”快速部署”目标冲突。

日常类比：照片从 RAW 格式（fp32）压缩成 JPEG（int8）。大多数照片看不出区别，但拍星空/低光场景（困难任务）时 JPEG 的色阶断裂肉眼可见。你不试就不知道哪张照片会翻车。

真实案例：

所有六个引擎都支持 INT8 量化，但量化策略差异大：

ncnn 提供 post-training quantization (PTQ) 工具，用 KL 散度校准：收集激活值分布 → 找到最优量化范围 → 截断超出范围的值。对大多数 CNN 模型效果不错。

MNN 更进一步支持 Quantization-Aware Training (QAT)——在训练过程中模拟量化噪声，让模型学会”容忍”低精度。精度损失更小但需要重新训练。

TNN 的 NC8HW8 布局专门为 ARM fp16 设计——8 个 half 恰好填满 128-bit NEON 寄存器。fp16 推理在大多数场景精度损失可忽略，是比 int8 更安全的”轻量化”选择。

根本难点：量化本质上是有损压缩——你在用信息精度换计算速度。但精度损失是任务相关且不可预测的：同一个量化方案对分类任务精度掉 0.1%、对检测任务可能掉 2%、对分割任务可能掉 5%。没有通用的”安全量化”策略，每个模型 × 每个任务都需要独立验证。这让自动化量化部署管线成为奢望。

9. 跨设备数据传输与同步开销

核心矛盾：异构计算（CPU + GPU + NPU）的收益取决于”计算加速 > 数据搬运开销”这个不等式。但在移动端，设备间带宽有限，小 tensor 的搬运开销可能超过计算收益。

日常类比：工厂有三条流水线（CPU/GPU/NPU），每条擅长不同工序。但工件从一条线转到另一条线需要用小推车搬运——如果工件太小或转移太频繁，搬运时间比加工时间还长，还不如一条线干完。

真实案例：

ORT 在 EP 分区边界自动插入 Memcpy 节点：

[CUDA EP] → MemcpyToHost → [CPU EP: 不支持的 Op] → MemcpyFromHost → [CUDA EP]
              GPU→CPU                                    CPU→GPU
              ~0.5ms                                     ~0.5ms

如果 CPU EP 上的 Op 本身只计算 0.1ms，这 1ms 的搬运开销就让异构方案得不偿失。ORT 没有自动判断”这个 Op 走 CPU 是否值得”的机制——EP 认领了就认领了。

MACE 的 Hexagon DSP 通过 ION 共享内存实现 CPU↔DSP 零拷贝——物理页在两侧共享，避免了实际数据搬运。但 ION 在不同 Android 版本上行为不一致（Android 12+ 推荐 DMA-BUF），兼容性问题频出。

MNN 的虚拟 Tensor + Region 机制在同一设备内实现了零拷贝（Reshape/Transpose 等操作只改描述不搬数据），但跨设备时仍需要 Backend::onCopyBuffer() 做实际传输和布局转换。

根本难点：PCIe/共享内存的带宽是固定的物理约束。推理图的最优设备分配是一个联合优化问题——不仅要考虑每个 Op 在不同设备上的执行时间，还要考虑其相邻 Op 的位置（决定了搬运成本）。这是一个 NP-hard 的调度问题，现有方案都只是启发式近似。

10. 端侧 LLM 推理的内存墙与 KV-Cache 管理

核心矛盾：大语言模型推理需要存储 KV-Cache（所有已生成 token 的 Key/Value 向量），缓存大小随序列长度线性增长。移动设备内存有限（3-8 GB，还要留给系统和其他 App），KV-Cache 很快成为瓶颈。

日常类比：写作文时需要回头翻看已经写过的内容（KV-Cache）。桌面越小（内存越小），能摊开的稿纸越少——要么只能看最近几页（截断上下文），要么字写小一点（量化 Cache），要么把旧页收进抽屉需要时再拿出来（换入换出）。

真实案例：

MNN 是六个引擎中对端侧 LLM 支持最深的——内建了 LLM 推理管线。但其 NC4HW4 布局对 LLM 的 Attention 机制不友好——Attention 的核心是 Q×K^T 矩阵乘，操作维度是 (seq_len, head_dim)，与 NC4HW4 的 channel 打包维度正交。需要频繁 layout 转换。

以 7B 参数 LLM（如 Llama-2-7B）为例估算 KV-Cache：

FP16 精度：
  每层 KV = 2 × seq_len × hidden_dim × sizeof(fp16)
  32 层 × 2 × 2048 tokens × 4096 dim × 2 bytes = 1 GB

序列长度翻倍到 4096 tokens → 2 GB → 移动设备可用内存告急

ORT 通过 GenAI 扩展支持 LLM，使用 Paged Attention（借鉴 vLLM 的思路）——把 KV-Cache 按固定大小的”页”管理，避免碎片化。但在移动端，Page 粒度选择本身是问题：页太大浪费内存，页太小增加管理开销。

根本难点：LLM 的内存需求与传统 CV 模型完全不同——CV 模型推理完就释放中间状态（无状态），LLM 需要跨请求保持状态（KV-Cache 在对话过程中持续增长）。现有推理引擎的内存管理架构是为无状态推理设计的（如 ncnn 的 Light mode 用完即弃、MACE 的 RENT_SHARE 生命周期复用），需要从根本上重新设计内存分配器来适配有状态推理。

9. 模型格式碎片化与转换损耗

核心矛盾

类比：每个国家都有自己的电源插头标准，出国旅行必须带一堆转换头——而且有些转换头会让电压不稳。

训练框架（PyTorch/TensorFlow/PaddlePaddle）导出的模型，到部署框架都需要一次格式转换。每次转换都可能引入精度损失或功能丢失。

真实案例：

六个引擎的原生格式完全不同：

转换过程中的典型问题：

• 动态 shape 信息丢失（某些转换器只支持固定 shape）
• 自定义算子无法转换（训练框架的自定义 Op 在推理框架无对应实现）
• 量化信息不兼容（QAT 模型的量化参数格式各家不同）
• 控制流（if/while）支持参差不齐

ONNX 试图做”通用中间格式”，但 opset 版本碎片化本身又成了问题——ORT 需要为同一个算子维护多个版本的 kernel（如 Add 在 opset 7-12、13、14+ 语义不同）。

根本难点：模型格式本质上是对”计算图 + 权重 + 元数据”的序列化方案。每个引擎因为内部表示不同（ncnn 的 ParamDict vs MNN 的 FlatBuffers Schema vs Paddle-Lite 的 MIR），需要不同的序列化格式来最高效地映射到运行时结构。统一格式意味着所有引擎都要接受”反序列化后再转换为内部表示”的开销，这在移动端冷启动场景下不可接受。

10. 功耗与热管理的系统级约束

核心矛盾

类比：手机就像一个散热能力很差的小房间里的暖气——开太大会过热降频（throttling），开太小又不够暖。而且房间温度还受”邻居”（其他 App）影响。

移动设备不是服务器——没有风扇、散热有限、电池容量小。推理引擎必须在性能、功耗、温度三者之间动态平衡。

真实案例：

MACE 是六个引擎中功耗管理做得最深的：

CPU 功耗管理：
  AFFINITY_BIG_ONLY    → 绑定大核（性能优先）
  AFFINITY_LITTLE_ONLY → 绑定小核（功耗优先）
  AFFINITY_POWER_SAVE  → 动态选择

GPU 功耗管理：
  GPUPerfHint    → 性能提示（Normal/High/Low）
  GPUPriorityHint → 优先级提示

DSP 功耗管理：
  SetPower(perf_level, latency) → 直接控制电压/频率角点

但即使 MACE 做了这么多，仍然面临根本困境：

• 无法预知其他应用的负载：如果用户同时在后台录视频，推理引擎能用的算力大幅缩减
• 热降频不可预测：SoC 温度达到阈值后自动降频，推理延迟突然翻倍
• 大小核调度器是 OS 控制的：引擎只能”建议”用大核，最终决策权在 Linux 调度器

其他引擎的功耗管理相对薄弱——ncnn/MNN/TNN/ORT 主要通过线程数控制间接影响功耗，没有直接的电源管理 API。

根本难点：推理引擎运行在 OS 之上，但功耗和热管理的决策权在 OS 之下（内核调度器、固件、硬件热保护）。引擎能做的只是”在给定约束下尽量高效”，无法真正”管理”功耗。这是一个跨层次的系统问题——需要 App 层、引擎层、OS 层、硬件层四层协同，而现有架构中这四层几乎完全隔离。

领域难度总结

移动端推理引擎的核心难度可以归纳为三层矛盾：

┌─────────────────────────────────────────────────────────────┐
│  第一层：硬件碎片化（不可控）                                    │
│  ARM 大小核 / GPU 型号 / NPU 指令集 / 内存带宽 → 各不相同       │
├─────────────────────────────────────────────────────────────┤
│  第二层：抽象与性能的永恒博弈（核心矛盾）                        │
│  统一接口 vs 硬件特化 / 通用优化 vs 手写 kernel                 │
│  ncnn 选择极致手写 → 性能好但扩展难                             │
│  ORT 选择厚抽象层 → 扩展好但单点性能让步                        │
│  MNN 用 Geometry Compiler 折中 → 复杂度转移到编译器              │
├─────────────────────────────────────────────────────────────┤
│  第三层：移动端系统约束（区别于服务器推理）                       │
│  内存 < 4GB / 功耗受限 / 热降频 / 冷启动敏感 / 后台随时被杀     │
│  → 服务器上的"暴力出奇迹"策略全部失效                           │
└─────────────────────────────────────────────────────────────┘

从六个项目的设计决策中可以看出，没有一个引擎能同时在所有维度做到最优：

这意味着犀牛鸟参与的真正价值不在于”解决某个难点”，而在于深入理解这些 trade-off 背后的工程哲学——为什么在特定约束下，某个设计决策是”最不坏的选择”。

E 线扩展：部署链相关补充难点

以下 3 条来自 E 线跨赛道研究，聚焦「模型从训练到端侧」的衔接问题：

11. PNNX 转换静默失败模式

PNNX 在处理反常 float 常量（denormalized float）时可能静默输出错误模型而不报错（ncnn issue #6614）。更广泛地说，PyTorch 到 ncnn 的转换链中，新算子支持滞后于 PyTorch 版本更新，导致转换失败时用户难以定位原因。

12. MoE 动态路由无法映射到静态计算图

YOLO-Master 的 ES-MoE 使用实例级 Top-K 路由，推理时不同实例激活不同专家组合。ONNX/ncnn/TensorRT 的静态图假设与此根本冲突。当前 workaround（全专家并行 / 单专家蒸馏）要么丧失稀疏优势，要么损失精度。详见 跨赛道文档。

13. 端侧部署引擎选型碎片化

同一个 YOLO 模型部署到 ncnn、MNN、ORT Mobile，需要完全不同的转换链、量化工具和 API。没有统一的「模型部署标准」，开发者需要为每个目标引擎单独维护流水线。详见 端侧部署流水线 中的选型决策表。