有一次我在某个边缘设备上部署一个目标检测模型模型训练得很收敛离线验证指标也好看结果一换到真实推理环境单帧耗时直接翻倍内存也逼近上限几乎没法上线。当时我能想到的最直接、成本最低的方案就是量化——把浮点参数压到更低位数让模型跑得更快、更省内存。这件事听起来是个经典的“AI模型量化精度与推理速度平衡”话题但实际动手时会发现它不是简单地填两个开关就能搞定的。这篇文章是我在多个项目里折腾量化的真实记录。你可以把它当成一份“精度账本”精度为什么掉、掉在哪、怎么控制损失、怎么在速度和精度之间做取舍。读者不需要有很深的底层功底只要对模型训练和部署有基本概念就能顺着思路复现。我会把事情拆成几个部分先讲清楚量化损失的本质再聊需求侧怎么定目标接着对比两种主流做法最后用我手头一个具体项目的完整回放来收尾。1. 量化损失从哪里来离群值往往是头号元凶1.1 浮点变定点分桶必然会有误差量化的本质是把模型里的参数和中间激活值从高精度表示变成低精度表示。最典型的一种是 FP3232位浮点到 INT88位有符号整数。FP32 能表达的范围大约是 -3.4e38 到 3.4e38而 INT8 只有 -128 到 127。哪怕一个模型里所有数值都被限制在很小的范围内8 位整数也只有 256 个离散档位可以选。这就像用一把只有 256 格刻度的尺子去量千变万化的数值。量出来的结果必然是某个刻度附近的近似值这个近似和真实值之间的差距就是量化误差。FP32 到 INT8 的压缩比是 4 倍内存和带宽直接少 75%但代价也很明确每个数值都要经过一次“四舍五入”。一次舍入误差也许很小可神经网络动辄几百万个参数再经过几层甚至几十层前向计算误差会叠加、传导。真正让我印象深刻的不是这条常识而是误差分布并不均匀。在真实的模型里参数和激活值的分布往往像一个长尾分布大部分数值落在很小的区间里偶尔有几个特别大的“离群值”把整体范围拉得很宽。如果量化时按照 min-max 严格映射那么出现频率最高的正常数值反而会被压缩到几个刻度里信息损失远超过预期如果手动截断掉那些离群值那么这部分信息又会被直接抹掉。这个取舍是量化精度问题的根源也是“精度和速度平衡”这句话背后真正需要较劲的地方。1.2 校准集量化参数的“照妖镜”模型参数量和权重不是随机数量化时需要一组代表性数据帮统计分布然后算出缩放因子 scale 和零点 zero_point。这一步叫校准。校准集的选择极其关键它不是随便找几十张图丢进去就完事的。我见过很多坑最典型的一个是校准集和线上真实数据分布不一致。比如某个模型在训练时主要见到室内强光场景但线上实际输入有大量逆光、暗光、夜间帧。如果校准集里全是亮堂堂的图统计出来的激活分布就会偏向高值区间量化后的暗光部分直接被挤到接近零的档位检测能力肉眼可见地崩掉。实际操作里我习惯用百分位截断而不是 min-max。min-max 对离群值完全没有抵抗力一个异常大值就能把 scale 撑大好几倍。百分位截断则不把最大值当真而是看分布的分位数。比如取 99.99 百分位作为激活上限超过这个范围的值直接截断做饱和处理。这样大多数正常数值能保留足够的量化档位少数极端值损失一些也无所谓。我常用的伪代码很简单def compute_scale(activations, percentile99.99): amax 分位数计算(activations.abs(), percentile) scale amax / 127.0 return scale需要说明的是百分位数的选取本身也是一次调参。取值太高等于没截断取值太低会把正常分布截掉一大半。我一般会在校准集里先统计一下激活值的分布曲线再决定用 99.9 还是 99.99。对不同层也可以分别设置没必要所有层都用同一个策略。2. 延迟还是吞吐先根据真实运行形态定量化目标2.1 在线服务、离线任务和端侧设备答案不一样开始量化之前我强烈建议先回答一个问题你这模型上线之后到底是在什么形态下跑不同场景对“速度”的定义完全不同量化目标也完全不同。在线交互服务里单次请求的延迟往往是最重要的。用户点一下按钮模型要在几十毫秒内返回结果。此时量化追求的是“单请求延迟够不够低”batch size 通常很小甚至一张一张地推。离线批处理场景则相反一次性给模型好几千个样本追求的是整体吞吐量单位时间内能处理多少样本。这时量化带来的单样本延迟下降可能没那么关键但批次变大后更小的模型占用可以让每个 batch 塞进更多数据吞吐收益会被放大。端侧设备和嵌入式设备又是另一个维度。它的内存、功耗、带宽都紧张模型可能只有几百 KB 到几十 MB 的空间。此时量化带来的一大好处不是“推理变快”那么简单而是“能不能放进去”“能不能长时间跑不掉电”。我项目里有些模型 FP32 版本根本装不进目标设备量化到 INT8 之后才勉强塞进去。运行形态首要约束量化优先级在线小 batch 交互单次延迟优先降延迟同时不能太伤精度离线大批量处理吞吐量可以更激进int8 或更低端侧/嵌入式内存、功耗、模型体积先把体积压下来精度可放宽GPU 推理服务显存、算子效率结合混合精度看具体算子支持2.2 底层硬件指令决定量化能快多少量化后的模型快不快不完全取决于模型本身很大程度上由部署硬件是否支持相应的低精度计算指令决定。主流 CPU 上8 位整数运算通常可以用单指令多数据方式并行计算一次指令能同时处理多个数据GPU 上也有针对低精度整数或半精度浮点的专门加速单元。如果底层硬件不支持极可能发生这样的情况模型虽然量化了但推理框架找不到对应的算子实现只能在内存里转来转去速度不升反降。我踩过一个具体的坑在某个端侧平台上跑量化模型延迟只降了 10% 左右排查半天才发现推理框架对 INT8 的支持不完整部分算子被自动回退到 FP32 计算。每一层都要做一次反量化、算完再量化回去来回转换的开销把收益吞掉了大半。从那以后我在选择量化方案前都会先跑一个“算子兼容性检查”把模型里的每个算子在目标设备上单独跑一遍看有没有回退。这一步花的时间不多却能避免后面的整体返工。3. PTQ 和 QAT两条主线先用低成本的摸底3.1 PTQ从校准集到部署的低成本流程训练后量化也就是常说的 PTQ是全流程里成本最低、见效最快的办法。它不需要重新训练模型只需要拿少量代表性数据做校准得到量化参数然后推理时把参数量化到目标位宽。整个过程通常小时级甚至分钟级。我做 PTQ 的流程基本是这样从线上日志里采一批真实样本作为校准集数量一般在几百到一两千之间。用校准集跑一遍前向统计收集各层激活的概率分布。选定标准策略比如对称量化还是非对称量化、按层量化还是按通道量化。根据分布和策略计算 scale / zero_point。在验证集上对比量化前后的精度指标重点看有没有类别或样本子集掉得特别狠。用目标设备实际跑一次延迟和资源占用测试。按通道量化通常比按层量化保留更多精度因为它允许每一层里的不同输出通道拥有独立缩放因子对分布不一致的情况更友好。代价是计算量稍大最后生成的模型文件也会大一点。在速度允许的情况下我几乎总是先开 per-channel 试试不行再退层级。3.2 QATPTQ 搓不回来时再上别一上来就搞如果 PTQ 之后精度明显掉得不能忍下一步就轮到量化感知训练也就是 QAT。QAT 的核心思路是在训练过程中就模拟量化误差把量化的“舍入”操作放到前向计算里让网络参数逐渐适应低精度表达。我个人的习惯是先别急着直接跑 QAT。先用 PTQ 定位哪些层对量化最敏感然后只对这些层做 QAT其他层保持 PTQ 的结果。这样能大幅缩短训练周期。我见过很多人一上来就把整个模型丢进 QAT 里训几天最后发现大部分层其实不敏感纯属浪费算力。方案数据需求成本精度保留适用场景PTQ少量线上样本即可小时级多数场景足够快速上线、模型较大、精度余量足QAT原始训练数据最好还有类标天级更高可定点修复精度敏感、量产后精度掉太多混合方案先 PTQ 后按层 QAT中接近完整训练折中主义常见于目标检测QAT 里的一个重要细节是“伪量化算子”。前向时它把浮点值先量化成低精度整数再反量化回浮点这样误差就被暴露给了反向传播但反向传播时量化过程中的 round 函数通常没有导数需要做直通估计把梯度直接从回传路径“跳过” round。这个细节对训练稳定性的影响很大如果直通估计处理得不好可能出现 loss 震荡、指标抖动。4. 量化后真实性能怎么测别让合成基准骗了你4.1 预热和分位数比平均耗时更可靠量化完成之后很多人习惯直接跑一遍 benchmark 脚本看平均延迟降了多少。想法没错但用平均值做决策非常容易被骗。首先模型推理在首次调用时往往有一段初始化、显存/内存分配、权重加载的开销。跑一次和跑完几十次之后的耗时完全不一样。正确的做法是先跑足够多次数做预热让框架把所有资源都准备好再开始统计。其次平均延迟对偶发的长尾毫秒级波动不敏感一个稳定在 10ms 的模型可能因为有 5% 的请求跑到 30ms用户体验就崩了。我一般会统计 P50、P95、P99 这几个分位数延迟的离散程度和绝对值一样重要。还有一个容易被忽略的细节测量时要带着真实的输入形状。有些框架会根据输入尺寸做图优化如果你在测试时只用固定尺寸线上出现的多尺寸输入可能会频繁触发重新构图延迟暴增。这种问题在量化模型的部署中尤其常见因为推理引擎经常会针对特定数据布局做 kernel 选择。4.2 别只测单帧要测吞吐和并发量化对单帧延迟的影响只是其中一个维度。如果你的模型是跑在服务端并且要处理并发请求那么你在测试时就要模拟真实的并发压力而不是拿单线程的循环去压。举个例子某个模型 FP32 版本在单线程下单帧耗时 54ms看起来不高但服务端要同时处理 4 个并发请求时单线程没有配额可用整体吞吐直接上不去。量化到 INT8 后单帧耗时降到 12ms如果再叠加推理框架的多线程能力同一时刻能并行处理的请求量就翻了好几倍。延迟降下来只是表象真正的收益往往体现在“资源占用下降、并发能力上升”上。我整理过一个测量清单每次量化后我都会照着过一遍预热至少 50 次再统计 P50 / P95 / P99 延迟。至少跑两种 batch size真实服务中的 batch size以及硬件最大 batch size。记录内存峰值和模型文件体积这两项端侧部署特别重要。在目标硬件上测而不是在开发机上测因为指令集支持完全不同。如果模型包含非量化算子比如某些自定义层单独测一下这些算子的耗时占比。5. 一个盘点检测模型的回看从 54ms 提速到 12ms再找回丢掉的精度5.1 基线数据和第一轮量化结果前面这些方法不是纸上谈兵。我手头有一个典型的仓库盘点场景目标检测项目模型需要从边缘端的货架画面里识别货物和盘点标记点。部署环境是一颗 4 核 CPU、内存 2GB 的小主机实时性要求单帧处理不超过 30ms。基线情况是这样的FP32 模型文件 92MB单线程实测单帧耗时约 54ms直接超出了时限一倍。离线验证精度 mAP 是 81.2%看着不错但根本没有上线余地。第一轮我直接上了 PTQINT8、按通道量化、百分位校准。量化之后模型文件从 92MB 降到 23MB单帧耗时 54ms 降到 12ms加速大约 4.5 倍内存占用也降了不少。说实话这个结果已经让人比较满意了如果只看整体指标感觉可以上线。5.2 指标回落到特定类别定位过程但我按类别拆开看 mAP 时发现了问题。整体 mAP 从 81.2% 掉到 77.1%算是能接受可“盘点标记点”这一类的 AP 从 83% 掉到了 61%属于断崖式下跌。这个类是项目核心功能丢了它整个系统就没意义。我开始排查第一步是看量化后每一层的输出分布。先把线上真实回放的暗光、低对比度帧丢进模型里对比 FP32 和 INT8 的中间激活值。在量产前的检测头附近我发现大量本来应该在中间范围的激活值被压缩到了低档位原因在于校准集里几乎全是白天正常光照的货架画面缺少暗光帧。统计分布时暗光场景下激活值的动态范围没有被充分体现量化时就出现了分布偏差。本质上是校准集代表性问题不是量化本身的问题。想通这一点之后我补了一批线上回放的暗光、俯拍、局部遮挡帧进校准集把百分位重设到 99.9重新计算 scale。这一轮盘点标记点类的 AP 从 61% 回升到 69.2%整体 mAP 回到 78% 左右仍比基线低一些但至少不再断崖。5.3 混合精度和局部 QAT把最后的损失一点点补回来校准集修正之后整体情况已经能接受但我觉得还有余量。接下来做了两件事。第一件事是混合精度。通过输出分布分析我发现对“盘点标记点”类最敏感的是检测头最后的几层。于是把这几层保留 FP16其余层继续用 INT8。混合后单帧耗时只从 12ms 涨到 13.1ms几乎可以忽略而这一类 AP 涨到了 75% 左右。敏感层权重占据的参数量不大用更高精度表达它们反而比整体 8 位更划算。第二件事是局部 QAT。前面分析已经锁定了敏感层我只对其中两个回归分支做 QAT 微调冻结其余所有层用仓库盘点数据训练了两个 epoch。训练时给量化误差加了直通估计并适当调低了学习率。最后这一轮整体 mAP 恢复到 79.6%盘点标记点 AP 恢复到接近 80%而量化后的速度仍然保持在 12.3ms 左右。到这里这个项目从“基准慢一倍”变成“达标且精度几乎无损”。我从这个案例里得到的经验是量化精度事故很少是全模型范围一起崩更多是先在某一个类别、某一部分输入上暴露出来。所以每次量化后我都不只看整体指标而是强制自己按类别、按输入分布拆开看。阶段处理方式单帧耗时整体 mAP目标类 AP基线FP3254ms81.2%83%第一轮INT8 PTQ12ms77.1%61%校准修正补充暗光帧校准12ms78%69.2%混合精度敏感层 FP16 INT813.1ms79%75%局部 QAT敏感层微调12.3ms79.6%79.5%6. 把“速度-精度平衡”拆成预算分配问题走到这一步我已经不想再把“量化”当成一个孤立的优化动作了。我更习惯把它想成一次预算分配整张模型图是有速度预算的每个算子能分到多少毫秒如果要换精度该在哪些环节花更贵的“高精度币”。一旦用这种视角看问题量化的决策就变得非常清晰。具体操作上我会先把模型在目标设备上跑一遍 profiling按算子把耗时拉出来。再对耗时占比高、精度敏感性低的层优先做 INT8甚至考虑更低位的尝试对精度敏感性高的层要么保留 FP16要么单独做 QAT。整个调优过程是一轮一轮迭代的每次只改一批算子重新测量速度和精度看有没有“性价比”更高的调整空间。例如在第五章的项目里FP16 层的耗时占比只有不到 10%却决定了目标类 10 个百分点的精度这就是值得的“高价预算”。有些层占用 20% 的耗时但对最终输出根本没太大影响把它们的位宽一降再降几乎不会带来精度变化这才是量化的最佳下手处。最后再分享两个我从实践中沉淀下来的小习惯。第一量化校准集建议直接从线上日志里抽不能让测试或开发集代劳分布不一致的坑我已经踩过不止一次。第二每次量化完先别急着删 FP32 模型它永远是精度有争议时的对照物等量化模型稳定跑一段时间后再考虑清理基线版本。
