做模型部署这行干久了就会有个体会模型训练完只是第一步真正上线跑得起来、跑得快才算数。围绕“AI 模型量化精度与推理速度平衡”这个话题我前前后后折腾了快三年。量化这个技术原理上讲起来很简单——把 FP32 的权重和激活用更低比特表示——但真正把精度保持住、速度提上去里面全是细节。这篇文章就当是你踩坑前的参考地图适合正在做模型部署的工程师也适合刚接触量化、想搞清楚原理和实操取舍的人。先给一个整体的量不是所有模型都适合量化也不是所有量化都要做到 INT8。有的模型量化后精度几乎不动有的掉两三个点。问题不在于量化本身而在于你有没有搞清楚精度去哪儿了、怎么把平衡点找回来。全文我就按“原理—方案—实操—实测—避坑”这个顺序来写中间涉及到的参数和步骤都是可以直接抄去用的。1. 量化到底换掉了什么先看精度是怎么丢的1.1 从 FP32 到 INT8数值表示发生了什么变化要理解精度损失先得看数值表示本身。FP32 用 32 位存一个数里面有 1 位符号、8 位指数、23 位尾数能表示的范围特别大精度也高小数能精确到小数点后大约 7 位。INT8 只有 256 个取值范围就是 -128 到 127每个整数之间没有“小数”的概念。量化做的事情就是拿一个线性映射把 FP32 数值范围里的一段对应到 INT8 的 256 个刻度上。这个映射由两个关键参数决定scale缩放系数和 zero point零点偏移。反量化的时候整数还原成浮点的公式是 r (q - zero_point) * scale。整个过程相当于用一把只有 256 个刻度的尺子去量一段很宽的连续区间尺子上的每一个刻度代表一个小范围落在同一个小范围内的所有浮点值还原后都是同一个值。举一个具体的例子。假设某层权重分布在 -5.0 到 5.0 之间用对称量化映射到 INT8 的 -128 到 127那 scale 就是 (5.0 - (-5.0)) / (127 - (-128)) ≈ 10.0 / 255 ≈ 0.0392。也就是说量化后的每个整数刻度代表 0.0392 的浮点宽度。真实值 1.234 量化成 round(1.234 / 0.0392) 31反量化回来是 31 × 0.0392 1.2152误差 0.0188。这个误差看起来不起眼但在卷积里成百上千次乘法加法之后会被持续放大。这样一来误差就有两个来源。一个是舍入误差真实值落在两个整数刻度之间量化后只能取最近的整数还原回来就偏了一点。另一个是截断误差真实值超出了你设定的映射范围例如上例里真实值如果是 6.0已经超出了 5.0 的上限映射的时候直接把 6.0 压成 127还原回来就是 4.98误差被截断了。这两类误差在数学上都很小但模型里上百万个参数层层叠加有些层的输出就会明显偏离原来的分布。1.2 精度损失的真实来源不是所有层都背锅很多人以为量化精度掉是因为“数字精度不够了”其实远没这么简单。我实际排查下来精度掉得厉害的模型问题绝大多数出在少数几个“敏感层”上。敏感层的含义是这一层输入或输出的数值分布非常尖存在个别特别大的 outlier 值。比如某个激活层的输出大部分在 0 到 1 之间但偶尔会蹦出一个 8 或 10。如果校准的时候你按最大值 10 来定范围那整个 0 到 1 的有效区间只占了刻度的一小段量化分辨率被严重稀释如果按 99% 分位点把 8、10 当成异常截断掉那些 outlier 对应的输出又会偏差很大。怎么选都会伤一方。另一个容易忽略的来源是权重分布。卷积层的权重按输出通道看每个通道的分布差异可能非常大甚至有的通道几乎全在零附近有的通道跨度很大。如果不区分通道用整个张量的全局范围去做缩放数值很小的通道在量化后可能只剩几个有效刻度信息基本被磨平了。这也是为什么成熟的推理引擎默认对权重用 per-channel 量化、对激活用 per-tensor 量化——就是针对这种分布差异做的妥协。还有个细节FP16 和 INT8 不是一回事。FP16 虽然只有 16 位但它依然是指数加尾数的结构动态范围很大只是精度比 FP32 略低一般不会造成明显的精度损失。真正让模型“质变”的是从浮点跳到整数这一步。所以有时候你会看到有人用 FP16 做混合精度就恢复了精度因为那些敏感层需要的只是动态范围而不是高密度的小数精度。2. 量化方案怎么选PTQ 和 QAT 的取舍2.1 训练后量化PTQ成本和收益的最优解PTQ 的流程特别直接拿一批样本跑一遍模型统计每一层激活的数值分布算好 scale 和 zero point再把模型导出成 INT8 版本。整个过程不需要动训练脚本也不需要额外准备 GPU 做重训快的话几分钟就能出结果是一般量化时的第一步。我一般先跑 PTQ因为它给了你一个精度的“底价”。如果量化后的精度损失在 1 个点以内直接用它如果在 1 到 3 个点之间先别急着上 QAT试试换校准策略后面第 3 部分会说如果超过 3 个点那基本上是模型本身对量化太敏感再做校准优化意义不大要上 QAT 或者混合精度。PTQ 的具体步骤可以这样拆先准备校准集通常是几百张代表性图片然后把模型切成推理模式按批次输入校准数据同时用 hook 或者引擎自带的统计接口记录每一层激活的 min/max 或直方图接下来按你选的策略max 或分位点算出每个张量的 scale 和 zero point最后用这些参数把权重转换成 INT8固化到量化模型里。这里每一步都有坑后面第 3 部分和第 5 部分会展开讲。PTQ 有一个很关键的坑校准数据要跟真实业务分布一致。我见过一个反例做车辆检测校准集用的是白天拍的街头图线上跑的时候到了夜间场景精度直接崩了。因为白天激活分布和夜间差别很大校准出来的 scale 只对白天友好。后来重新按“白天夜间雨天”抽样做了校准集精度立刻回来了。这算是 PTQ 里最容易被低估的一环校准集的质量比校准算法的参数更影响最终结果。2.2 量化感知训练QAT为精度做纠偏QAT 的思路是在训练阶段就把量化操作“模拟”进网络前向传播时把权重和激活先做一遍伪量化量化再反量化让网络提前适应量化误差反向传播的时候权重仍然用 FP32 更新避免梯度因为量化而失真。相当于让模型在训练时就“知道”自己以后会被压成 INT8学会用更鲁棒的分布去适配。QAT 一般是在预训练模型的基础上做低学习率微调而不是从头训练。实际效果我可以负责任地说QAT 并不能保证损失完全恢复只是让损失比 PTQ 小。比如某个分割模型PTQ 掉了 2.8 个点QAT 微调 3 个 epoch 后只掉 0.7 个点这个收益在工程上非常值得。但代价也不小要接入训练框架的量化感知接口要准备微调数据和算力整个流程比 PTQ 复杂一个量级。我的建议是别一上来就 QAT。先用 PTQ 摸底确认是模型敏感问题再决定是否用 QAT。另外 QAT 微调时要注意冻结 BN 层参数或者在量化图里把 BN 折叠好否则 BN 的统计量跟伪量化节点互相干扰训练半天精度纹丝不动的情况我也遇到过。还有学习率QAT 微调的学习率一般要比原始训练小一个数量级我用 1e-5 到 1e-4 这个区间比较多。2.3 混合精度预算不够时的聪明妥协有些层对量化极其敏感但你又不想为了几层单独去跑 QAT。这时候可以走混合精度绝大多数层用 INT8少数敏感层保持 FP16甚至某些数值动态范围很大的特殊算子单独保留 FP32。混合精度的难点是怎么找那几层。有一些自动搜索工具能做这事但我的经验是先跑完整 PTQ然后用第 3 部分讲的逐层对比方法找出误差最大的前几个层手工把它们挑出来提高到 FP16再量化一遍看整体精度。通常 90% 的精度损失会集中在不到 10% 的层上把这部分层挑出去精度能找回大半速度损失却只有几个百分点。这里有一个有意思的观察敏感层往往分布在网络的“信息瓶颈”位置也就是通道数从多变少、空间分辨率从大变小的地方。这类层的输出要浓缩足够多的信息对数值扰动格外敏感。下次遇到精度掉得厉害优先去这些位置找原因比逐层扫描要快得多。3. 拿捏平衡的实操套路从校准到调参3.1 校准数据集怎么选才靠谱校准集不是越大越好也不是随便拿验证集的子集就完事。我自己的通用标准是至少覆盖业务场景的 3 个以上典型子类每类 50 张以上总数 500 到 1000 就足够。再多对结果影响不大反而拖慢校准时间。选校准集的时候有几个雷区要避开。第一不要全用训练效果最好的那批样本模型在它们上面输出非常自信激活分布集中校准出来的结果容易盲目乐观。第二不要用重复度高的数据几十张图来回复制分布统计全歪了。第三分类模型和检测模型要分开想检测模型有背景类校准数据里背景和前景的比例要跟线上一致不然激活分布偏到前景上背景分支的 scale 就是错的。另外有个反直觉的点校准集的标签根本不重要。因为校准只是统计激活分布不需要知道样本的 ground truth。这就要求你在抽样时更关注样本的“分布代表性”而不是“任务正确性”。换句话说哪怕是一堆没打过标、但覆盖面足够广的线上无标签流量也是很好的校准数据。3.2 定位敏感层量化前后的逐层对比定位敏感层这件事建议不要靠猜而是做一个量化前后逐层输出的对比脚本。做法也不复杂拿到 FP32 模型和量化后的模型把同一批校准数据分别送进去在关键层卷积、全连接、激活层后面用 hook 把输出接出来然后逐层算两个输出的余弦相似度或者均方误差、KL 散度也行。# 伪代码对比 FP32 与量化模型逐层输出 def collect_outputs(model, input): outputs {} def hook_fn(name): def fn(module, input, output): outputs[name] output.detach().clone() return fn # 在目标层注册 hook再 forward 一次 model(input) return outputs fp32_out collect_outputs(fp32_model, calib_sample) int8_out collect_outputs(int8_model, calib_sample) for name in fp32_out.keys(): sim cosine_similarity(fp32_out[name], int8_out[name]) print(f{name}: cosine{sim:.4f})我用下来余弦相似度是最直观的低于 0.99 的层基本就是敏感层。把这些层标出来看它们在网络里的位置——如果集中在前几层说明输入分布的问题如果集中在某个分支或残差结构的起始位置说明那里的数值本身就容易放大误差。这个对比脚本一定要保证两个模型在算子上是严格对齐的否则对比出来的差距可能是实现差异而非量化损伤。我踩过这个坑测出来十来层都“敏感”后来发现是某个算子在两个模型的执行流程里 padding 行为不一样修完对齐之后真正敏感的只剩 3 层。3.3 关键参数怎么调分位点、粒度与批次校准阶段有几个旋钮值得反复试。校准时的分位点是最常调的。默认用最大值max定范围但如果激活里有长尾用 99.99% 分位点往往能显著提升精度。我处理过一个案例按 max 算模型掉 1.8 个点改成 99.99% 分位截掉极端尾部再去量化只掉 0.6 个点。分位点太低也不行比如设到 99%截断太狠误差反而变大。比较稳妥的做法是从 99.9% 到 99.99% 扫一遍看精度曲线。权重量化粒度也值得开。如果推理引擎支持一定要开 per-channel。权重 per-channel 比 per-tensor 在常见分类、检测模型上通常能找回 0.3 到 1 个点这是性价比最高的改动基本零成本。校准批次大小别设太小。批次里的样本多样性不够统计出来的激活范围会偏窄我通常用 32 到 64。批次太大容易超出内存而且在 128 以后收益基本到顶。这三个旋钮改完之后如果精度还在 2 个点以上我就直接考虑 QAT 或混合精度不再跟校准死磕。4. 实测数据损失多少精度换来多少速度4.1 一个典型分类模型的量化实测记录下面这组数据来自我自己做过的一个图像分类 Demo模型规模在 100M 参数以内输入 224x224跑在一块中端推理卡上。为了让结果有可比性所有版本都用了同一个推理引擎、同样的线程数和 batch size。方案单帧延迟模型体积精度Top1相对 FP32 变化FP32 基线2.3ms412MB89.4%-INT8 PTQmax 校准0.9ms103MB87.8%-1.6%INT8 PTQ99.99% 校准0.9ms103MB88.6%-0.8%INT8 PTQ per-channel0.9ms103MB89.0%-0.4%混合精度5 层 FP161.1ms132MB89.2%-0.2%QAT 微调 3 个 epoch0.9ms103MB89.2%-0.2%这几行数据能把很多道理讲清楚。第一优化校准策略带来的收益比换方案还要重要同一个模型光把校准分位点从 max 改成 99.99%精度就从 -1.6% 收回到 -0.8%。第二per-channel 又拿回 0.4 个点三个便宜改动叠加之后PTQ 已经很接近 FP32 了。第三混合精度和 QAT 在这种本就不算敏感的模型上收益并不明显说明方案选择要按模型情况来不是越高阶越好。4.2 速度收益的来源和边界INT8 的速度优势来自两个层面。一是模型体积直接除以 4从 412MB 到 103MB内存带宽压力大幅下降。对很多实际业务来说推理瓶颈根本不在算力而在访存——数据从内存搬到计算单元的时间比计算本身还长。这种情况下换成 INT8访存量减到四分之一延迟自然明显下降。二是硬件的低精度计算单元效率更高特别是在支持 INT8 加速的推理卡上同样的功耗和硅片面积可以并行更多计算。这也是为什么同样的模型在手机端、边缘盒子上INT8 往往比 FP32 快 2 到 4 倍而在纯 CPU 服务器上可能只有 1.5 到 2.5 倍。但速度收益有一个边界如果你的算子没全部走 INT8比如图里残留了几个不支持量化的算子那这几层照样是 FP32整体速度提升会被它们拖累。量化分析器里一定要看每一层的实际执行类型别只盯着最底下的汇总数字。之前帮一个同事排查他的模型量化后只快了 1.3 倍查半天发现某个自定义算子占了 30% 的时间始终走 FP32换掉之后就正常了。5. 常见问题与避坑实录5.1 校准集“背题”精度看着漂亮上线翻车这是我见过最隐蔽的坑。校准集跟测试集高度重合或者校准集太“干净”导致量化后的模型在测试集上分数很高一到线上就垮。因为 scale 是根据校准数据的分布定的线上数据只要稍微偏离误差就会成倍放大。我的做法是把校准集和验证集彻底分开验证集按时间或场景切分校准集用独立采样的线上抽样数据。上线前再用一版完全不参与校准的真实流量数据做一次性验证如果这版数据和校准数据的结果都正常才算真没问题。5.2 激活里有 outlierscale 被拉飞的典型表现有一个典型特征量化后模型在大部分输入上输出接近 FP32但一到某些特定输入就给出离谱的分数。这通常是激活 outlier 导致 scale 过大正常数值在量化后分辨率不足精度严重受损。处理方法前面已经说过核心是把校准范围从 max 改成高分位点同时配合逐层对比定位是哪些层在“爆”。遇到过 outlier 特别顽固的情况某一层怎么截都有问题那层直接提到 FP16 更省事不要跟单一层死磕。5.3 算子不支持量化图执行类型没对齐推理引擎通常支持大多数常见算子走 INT8但总有少数算子只支持 FP32 或 FP16 实现。如果模型里用了不太常见的算子比如某些自定义激活或较新的注意力变体这些算子在量化图里会被悄悄回退到 FP32。这类问题的排查很直接跑一遍量化分析器导出每一层的执行类型和执行时间找到 FP32 算子并看它们占总时间的比例。如果占比高就要么换掉这个算子要么把它合并到相邻层要么调整模型结构。我优化过一个模型量化后只快了 1.4 倍查下来发现一个高频的自定义算子占了 40% 执行时间始终走 FP32。换成引擎支持的原生算子后整体推理延迟直接降到原来的 55%。5.4 BN 折叠和激活函数的选择BN 层在量化前一定要折叠进卷积或全连接的权重里。折叠之后的模型在数值上等价但省掉了一整类算子的量化误差来源。很多框架在导出量化模型时会自动做这一步但如果你自己手写推理流程这里最容易漏。激活函数也值得挑。ReLU 的输出全是非负量化时映射到 0 到 127 就能充分利用全部刻度比较好量化ReLU6 虽然范围限定但能刚好卡在 0 到 6 的小区间GELU、SiLU 这类光滑激活在接近 0 的区域有细微弯曲量化误差更容易积累。如果结构允许在线上的量化模型里把 GELU 换成 ReLU 或其近似版本精度影响很小但对量化友好得多。5.5 上线之前必做的两次验证最后说一个流程上的经验。我每次上线量化模型前都会做两件事第一FP32 模型和量化模型在同一条线上跑同一批 golden data逐路对比输出定一个可接受的误差阈值超阈值的比例要在预期范围内。第二灰度放量先放 5% 流量跑两三天观察业务指标而不是只看推理延迟。这两个验证看着笨但能挡住大部分实际开量后才会暴露的问题。毕竟量化模型在离线和在线的表现差异很多时候不是算出来的是跑出来的。做量化这几年我最大的感受是别把它当成一个“导出按钮”。精度和速度的平衡本质上是一连串选择和验证的结果——选 PTQ 还是 QAT、选 max 还是分位点、选 per-tensor 还是 per-channel、选哪几层走混合精度。每一次调整背后都是对模型结构的理解和对线上数据的认知。把这个流程跑顺了手里的量化模型才能在精度和速度之间站得住。最后再分享一个个人习惯保存模型的时候我总会把 FP32 原始版本、量化版本、校准配置和校准集样本清单一起归档。后面线上出了问题回头排查的时候能少走很多弯路。