边缘AI基础：端侧设备类型、算力约束、典型应用场景及对模型量化的需求

在进入PTQ（训练后量化）精度评估的细节之前，必须先厘清一个根本问题：我们究竟要把模型部署到什么样的硬件上？端侧AI与云端AI最大的差异在于物理边界——功耗、内存带宽、算力天花板和实时性要求共同构成了一个“约束盒子”。本章将系统梳理端侧设备的类型谱系、算力分级、典型场景的量化敏感度，以及这些因素如何直接决定PTQ策略的选择。理解这些基础，是后续评估量化误差、设计校准集、分析层间敏感度的前提。

2.1 端侧设备类型谱系与算力分级

端侧AI设备并非一个均质的集合，从几十毫瓦的MCU到几十瓦的车载域控制器，其计算架构、内存层次和软件生态差异巨大。理解这个谱系是选择量化方案的第一步。我们可以将设备划分为四个主要层级：超低功耗MCU/IoT级别、移动AP级别、边缘计算盒级别、车载域控制器级别。

核心原理：算力与内存的“剪刀差”

端侧设备最核心的约束不是峰值算力，而是“算力-内存带宽-功耗”三者之间的不平衡。以手机SoC为例，其NPU算力可能达到15 TOPS，但内存带宽往往只有30-50GB/s，这意味着一个需要大量访存的浮点模型即使算力足够，也会被带宽卡死。量化之所以成为端侧部署的刚需，正是因为它同时压缩了模型体积（减少内存占用）和访存量（减少带宽压力），而不仅仅是加速计算。

实战场景：智能音箱的唤醒词模型

一个典型的IoT场景是智能音箱中的语音唤醒。设备采用Cortex-M7内核，主频400MHz，内置1MB SRAM。模型为DS-CNN（深度可分离卷积），FP32大小约1.8MB，直接部署会超出SRAM容量导致无法启动。初始现象是模型编译失败，报错“region RAM overflow”。分析过程：首先确认模型各层的内存占用，发现第一层卷积的激活值就占用了300KB。解决路径：采用PTQ量化到INT8，模型体积降至450KB，激活值降至80KB，成功部署。但量化后唤醒率从98.2%降至96.5%，通过per-channel量化（而非per-tensor）和收集200条真实环境噪声作为校准集，唤醒率恢复至97.8%。复盘经验：MCU级别的量化必须同时关注权重和激活的存储布局，且校准集必须包含目标场景的噪声特征，否则低信噪比下量化误差会被放大。

2.2 典型应用场景的量化敏感度分析

不同场景对量化误差的容忍度差异极大。这取决于任务类型、输出维度和安全等级。例如，图像超分任务对细节纹理敏感，量化后容易出现块效应；而目标检测任务对边界框回归的精度要求较高，但对分类置信度的微小波动相对容忍。

核心原理：任务敏感度分级

我们将常见端侧任务分为三个敏感度等级：高敏感（像素级回归、医学影像、语义分割）、中敏感（目标检测、人脸识别、姿态估计）、低敏感（分类、语音唤醒、关键词检测）。高敏感任务通常需要保留更多比特位（如混合精度INT8/INT16），或者采用更精细的量化策略（如per-channel、逐层敏感度分析）。

判断方法：量化敏感度快速评估流程

1. 层间敏感度扫描： 对每一层单独量化（其余层保持FP32），观察精度下降曲线，找出“离群层”。
2. 激活值分布分析： 统计每层激活值的动态范围，若分布呈长尾或极端不对称，则该层量化风险高。
3. 端到端指标验证： 在目标设备的模拟器或真实硬件上运行量化模型，对比关键业务指标（如mAP、F1、延迟P99）。
4. 鲁棒性测试： 用对抗样本或噪声输入测试量化模型，确保不会出现灾难性失效。

案例拆解：车载ADAS的车道线检测

某Tier1供应商需要在英伟达Orin-N平台（算力100 TOPS）上部署车道线检测模型，要求帧率≥30FPS，且车道线分类的IoU≥0.75。初始FP32模型在Orin上运行帧率仅18FPS，无法满足实时性。目标明确：通过PTQ将模型从FP32压缩到INT8，同时保持IoU下降不超过0.02。关键输入数据：模型为ResNet18-based encoder + 两个分割头，FP32大小约34MB。分析过程：首先进行层敏感度扫描，发现最后一个encoder stage的激活值分布范围极大（-12.8 ~ +11.2），直接per-tensor量化导致IoU从0.78跌至0.61。操作步骤：对该层改用per-channel量化，并采用KL散度校准方法（而非MinMax），同时将校准集从500张普通公路图扩展至包含隧道、雨天、逆光等2000张挑战场景。结果对比：量化后模型大小降至8.7MB，帧率提升至32FPS，IoU为0.76，满足要求。风险与代价：per-channel量化在Orin的INT8加速器上会引入额外的反量化开销，导致部分层延迟增加约8%，但整体仍满足实时性。复盘经验：车载场景的量化校准集必须覆盖光照突变和恶劣天气，否则夜间场景会出现车道线断裂。

2.3 量化需求与硬件加速器的匹配

并非所有端侧硬件都支持INT8计算。部分老旧的DSP或GPU只支持FP16，而最新的NPU则支持INT4/INT8混合精度。因此，PTQ方案必须与目标硬件的指令集和数据类型对齐。

核心原理：硬件数据类型支持矩阵

实战场景：工业缺陷检测的边缘盒子

某工厂使用RK3588边缘盒子做PCB板缺陷检测，模型为EfficientNet-B0分类器。初始FP32模型在RK3588上推理延迟为45ms，无法满足产线节拍（≤30ms）。目标：量化到INT8，延迟降至20ms以内，且分类准确率下降不超过0.5%。关键约束：RKNN NPU不支持Softmax的量化，需要将Softmax层保留在CPU上执行。操作步骤：使用RKNN-Toolkit进行PTQ，校准集采用500张包含正常、划痕、缺件、污渍四类的现场图像。量化后延迟降至18ms，但准确率从99.2%降至97.8%，超过0.5%的容忍线。分析发现，问题出在最后一个全连接层的激活值分布极度不均匀（大量接近0的负值）。解决方案：对该层使用混合精度（INT16），其余层保持INT8，准确率恢复至98.9%，延迟仅增加1.2ms。复盘经验：在NPU上，混合精度是解决敏感层问题的有效手段，但需要确认硬件是否支持INT16的算子加速，否则会退化为CPU计算，反而增加延迟。

2.4 常见误区与总结复盘

在端侧PTQ实践中，以下误区反复出现，值得警惕。

• 误区一：只关注权重量化，忽略激活量化。 实际上，激活值的动态范围变化更大，对精度影响往往超过权重。务必使用校准集统计激活分布。
• 误区二：校准集与部署场景分布不一致。 例如用白天街景校准，却在夜间使用。这会导致量化尺度偏移，精度下降。
• 误区三：盲目追求INT4。 虽然INT4能进一步压缩体积，但当前多数端侧NPU对INT4的支持不成熟，且精度损失难以控制。建议从INT8起步，仅在内存极度受限时考虑INT4，并配合精度补偿。
• 误区四：忽略“反量化”开销。 在CPU上，反量化操作（dequantize）可能抵消量化带来的加速收益。在NPU上，如果算子不支持INT8输入，则需要插入量化/反量化节点，增加延迟。