量化模型部署为何在不同芯片上成败各异

同一个量化后的 NanoDet，交给两台 Qualcomm 设备，一台拒绝加载，另一台把全部 324 层放上 NPU，耗时 1.39 ms。差别不在模型权重，而在模型末尾残留的浮点计算，以及设备运行路径是否接受它。

这次实验提醒我们：看到「支持 w8a8」还不能判断模型能否部署。真正要核对的是计算图、运行时和设备之间的约定。对需要接入端侧推理的程序员，这比单看跑分更有参考价值。

为什么已经量化，设备还是拒绝加载

作者使用 NanoDet，以 COCO val2017 的 23 张真实图片进行校准，量化精度为 w8a8，也就是权重和激活均使用 8 位表示。原计划是 24 张，但其中一张下载失败。

同一份计算图被交给 Dragonwing RB3 Gen 2（QCS6490）和 Galaxy S25：RB3 的 QNN 路径拒绝加载，S25 则成功运行。

问题出在 NanoDet 导出的内容。它不只有卷积，还把检测结果的解码计算装进了图里：GFL 检测头需要把分布转成数值，再解码出检测框坐标。这部分位于卷积之后，仍然执行浮点运算，量化器无法将它转换。

RB3 的 QNN 路径要求图的输入输出满足完全量化的约定，因此拒绝了这张带浮点尾部的图。S25 的 QNN 路径则接受了它。

模型被标记为量化，不等于整张图都满足目标设备的执行要求。

作者此前在 RB3 上测试的 YOLOv11-N 就没有遇到这个问题：其导出结果是原始卷积输出，没有携带这样的解码尾部，量化后 341 层全部运行在 NPU 上，耗时 5.03 ms。这支持了作者的解释，但不能据此推断所有 YOLO 导出方式都一样。

量化提速多少，要先看原来跑在哪里

S25 上，量化后的 NanoDet 耗时 1.39 ms，浮点路径则是 1.47 ms。差距很小，因为浮点版本原本就已经全部运行在 NPU 上。

作者同时给出 RB3 从 90 ms 到 6.47 ms 的对比，解释为浮点路径主要落在 CPU 上，量化后才获得明显收益。不过，所给原文没有明确交代 6.47 ms 对应的具体执行路径，不能把它当成那条已经拒绝加载的 QNN 路径的成绩。

量化的收益，既取决于数值精度，也取决于计算最终落在哪个处理器上。

这也是作者强调逐层性能分析（per-layer profile）的原因。总耗时能告诉你快慢，逐层记录才能说明哪些算子去了 NPU、哪些留在 CPU，以及瓶颈出现在哪里。

跨精度比较时，层数也不能直接作为效率依据。量化图会增加 quantize 算子，因此浮点图和量化图的层数可能不同。作者建议比较延迟，而不是拿层数多少判断性能。他还提到此前实验中出现过 27× 的差距，用来说明运行路径对结果的影响，但这段原文没有提供那次实验的完整条件。

把解码移出图，是可选方案，还是已经验证的修复

针对 RB3 的拒绝，作者提出了两条路线：

• 改走 TFLite 编译路径，让卷积运行在 NPU 上，浮点解码留在 CPU 上。
• 拆分模型导出，让 backbone 和 head 的纯卷积部分通过 QNN 执行，再由宿主端完成解码。

两种方案都把图内难以量化的尾部计算交给宿主端处理。但原文将它们列为待选方案，没有给出修复后的实测结果。

因此，「解码应该放在宿主端」更适合被理解为针对当前兼容性问题的工程取舍。S25 已经能够接纳整张图，是否也值得拆分，仍要看拆分带来的数据传输、调用和维护成本。

作者还将模型发布为 AI Hub external recipe，把 w8a8 列入支持精度，并在配方的测试报告中记录了 RB3 的 QNN 拒绝情况。保留失败记录，能让后续使用者提前知道限制。

我的判断

作者最有价值的结论是：报告量化性能时，必须同时写清设备和运行路径。单独一个 w8a8 标签，连「能运行」都无法保证，更不能代表某个固定的加速幅度。

但这仍然是特定模型、设备与路径下的实验。原文没有交代 QNN 版本等完整环境信息，也没有验证两条修复路线；23 张校准图片对应的检测精度变化同样未给出。它能帮助定位部署兼容性问题，还不足以证明量化后的模型达到了业务所需的准确率。

与直接拆图相比，保留完整计算图可以少维护一套宿主端解码逻辑。具体选哪条路，应由兼容性、精度和实测延迟决定，不能把一次设备拒绝推广成通用架构规则。

能拿来做什么

• 接入端侧检测模型前，先检查导出图是否包含后处理，尤其是解码、坐标转换等浮点运算，确认目标路径是否接受它们。
• 整理推理报告时，同时记录设备、精度、运行路径和逐层执行位置，并把加载失败也列入结果。
• 遇到量化后无法加载时，可以评估 TFLite 混合执行或拆出宿主端解码，但要分别验证延迟与检测精度，不能只确认模型成功运行。