yolo11s 混合精度 vs W8A16

在 n / s 的 W8A16 之外，给 yolo11s 补测的第三个方案：混合精度。结论先说：这次的混合精度不值得用 —— 20% 档几乎不提速，10% 档提速有限且精度掉到比 n 还差；纯 W8A8 虽快 2.3× 但在单输出格式下不可用。

三方案总表：n W8A16 · s W8A16 · s 混合精度

第三个方案是 yolo11s 混合精度：AI Hub --lite_mp percentage=X;override_qtype=int16，从 W8A8 出发，把量化最敏感的 X% 层提到 int16。跑了 X = 20% 和 10%，并附上 s 的纯 W8A8 作为下限参照。同一 ONNX、同一校准集、同一 runtime、同一台 S23、fp32 I/O；延迟和峰值内存取 3 次 profile 的中位。 C 臂的精度一律是打过框解码补丁之后的（纯 W8A8 除外，见下）。

为什么效果不好

挑中的层恰好是最贵的层

lite_mp 按敏感度自动选层提到 int16，选中的大多是高分辨率的前几层（stem 与 layer 0–5）。按层数是 10% / 20%，按 FLOPs 加权却是约 10% / 33% 的计算仍在 int16。

8/16 bit 交界的转换开销

每个精度交界都要插入转换算子：backbone 从 177 个算子变成 195（10%）/ 201（20%），全模型从 378 变成 404 / 413。编译产物也因此比纯 W8A16 还大。

纯 W8A8 为什么检测全没了

Pose 头是单一输出 (1,56,8400)，框坐标（0–690 px）与置信度、关键点可见度（0–1）共用一个编码。 8 bit 下每档约 2.7 px，0–1 的值全部量化成 0 → 没有任何检测能过阈值。单输出格式下，输出张量必须留在 16 bit （混合精度的两档都自动把它留在了 int16）。

混合精度也要打框解码补丁

两档混合精度的框解码三张量同样被 MSE 截尾（上沿约 37 网格），打补丁后才是表中的数字；补丁对 uint16 / uint8 编码都适用（scripts/quant_patch_decode_encoding.py）。

还能怎么做

要比 n 更准、能接受慢 1.4–1.5×：用 s · W8A16，这仍是 s 的最佳配置。
想拿到接近纯 W8A8 的速度：手工指定精度 —— 只把少数计算量小的敏感张量留 int16（Pose 输出与框解码、注意力 QKᵀ/softmax、8 路抽头），其余（包括高分辨率前几层）全部 int8。lite_mp 只能按比例自动选层，这需要自己改 QDQ 模型的编码位宽，工作量明显更大，未做。
高分辨率前几层对 a8 敏感这一点本身值得记下：纯 W8A8 的 backbone 特征误差（0.185）主要来自这里。

口径

量化：AI Hub quantize，weights INT8 / activations INT8 起步，--lite_mp percentage=10|20;override_qtype=int16；纯 W8A8 不带该选项。其余与 W8A16 相同：同一 ONNX、同一校准集（128 张，复用同一个已上传 dataset）、默认 range_scheme。
设备与编译：Samsung Galaxy S23，precompiled_qnn_onnx，fp32 I/O；每个编译产物 profile 3 次取中位。
精度：本地 ONNX Runtime 跑 QDQ 图对各自 FP32；测试集与 W8A16 页相同。C 臂除纯 W8A8 外均为打过框解码补丁的模型。
脚本：quant_aihub_submit.py --acts 8 --reuse --name-suffix _mp10 --options "--lite_mp ..." → quant_y11s_mp_device.py → quant_y11s_accuracy.py → quant_y11s_build_viewer.py。