模型量化这事儿最折磨人的不是把模型压小也不是让它跑得更快而是每次一量化就觉得精度要崩了但指标没掉多少心里那块石头又放不下。这几年我做AI模型部署量化从一开始的“敢不敢上”变成了“必备流程”——显存不够、时延超标、带宽打满几乎每个要上线的模型最终都要走一遍量化这条路。而做得多了就会发现量化真正难的不是“会量化”而是精度和延迟之间那杆秤怎么摆。本文把我踩过的坑、调过的手段、以及衡量精度与延迟这套方法论做个系统整理适合正在做模型上线、推理加速、或者被“压缩率翻倍但效果不掉”这种KPI逼过的朋友参考。1. 量化方案的选型逻辑先搞清楚为什么精度会掉1.1 量化为什么能同时影响精度和延迟模型量化说白了就是把 FP32 的浮点权重和激活值用更低比特位宽的整数比如 INT8、INT4来表示。内存占用能降到原来的 1/4 甚至 1/8计算单元在处理低精度数据时吞吐更高所以延迟和显存压力一起降下来。但代价是数值从连续分布变成了有限几个离散的台阶信息量丢了一截精度掉一点是必然的。但这里有一个最容易被人忽略的事实延迟提升的真正来源未必是计算变快而是内存搬运变少。很多大模型特别是 LLM 类的推理瓶颈在显存带宽和缓存命中率权重变小之后加载权重的时间大大缩短延迟才有质的改善。这也是为什么有些模型量化后计算速度没怎么变但整体时延反而明显下降——它省的是 IO 的时间不是算术单元的时间。理解这一点才会明白为什么在有些场景下 INT8 比 INT4 还划算因为 INT4 虽然更省内存但反量化开销和精度损失可能把收益吃掉了大半。1.2 量化对象怎么选只压权重还是连激活一起压先说说只做权重量化的场景。如果激活值每条数据差异都很大或者硬件对激活的整数计算支持有限只量化权重是稳妥的第一步。这种方式最简单精度损失通常很小内存减少一半以上但延迟收益相对有限因为激活值还在用 FP16/FP32 计算。要追求更低延迟就得做权重和激活都量化的“全量化”。激活量化最难的地方在于校准——激活值的分布不是静态的它随输入变化尤其是有 BatchNorm 或者 attention 结构的模型激活值分布带有明显的“尖峰”特征直接按均匀分布去量化误差会集中在峰值附近经常一掉就是十几个点。还有一类是 KV Cache 量化。在做长序列生成类任务时KV Cache 占的显存是个大头把它从 FP16 压到 INT8显存占用立刻降低而且不会增加计算延迟反而因为 cache 数据量小、读写更快整体吞吐能提升不少。KV Cache 量化在模型部署中经常被当成“白嫖”项目因为它不直接改权重和计算的数值路径精度损失通常比全量化小得多。1.3 数据格式与量化粒度对称还是非对称、按层还是按通道量化格式的选择直接影响精度表现。对称量化简单、硬件友好但它的零点固定在 0如果数据分布整体偏移比如激活值全为正对称量化会浪费大量档位。非对称量化用 zero-point 来修正偏移精度更好但计算时候要多一次移位操作速度稍微吃亏。量化粒度的选择同样关键。Per-tensor 量化整层用一个 scale计算最简单但如果层里不同通道的数据范围差异大卷积层的权重很常见小数值的通道容易直接被压成 0信息全丢。Per-channel 量化每个输出通道单独算 scale精度恢复明显代价是存储 scale 的额外开销和计算时的稍微复杂化。我的经验是权重量化直接上 per-channel 基本无脑收益激活量化先用 per-tensor 看结果掉点严重再细化到 per-group。别一上来就堆组量化参数量大了排查起来会很头痛。1.4 校准数据集精度的大半条命都在这里很多人量化效果好与不好第一个怀疑模型第二个怀疑算法却忘了校准数据集可能早就埋了雷。校准集的作用是用一小批真实输入数据统计激活值的分布以此确定 scale 和 zero-point。它根本不需要带标签但一定要能代表真实线上输入的分布。我见过最典型的错误是用训练集做校准。训练集样本来自批量增强后的分布和真实部署时遇到的输入往往有偏差。更合理的做法是从一条线上采样日志里抽几百到一两千条样本覆盖各种极端情况比如空输入、超长文本、超亮图片、高噪声音频。校准集长度与批量大小也有讲究一般建议在校准时固定 batch size比如 64 或 128让统计到的分布更稳定。批量太大会抹平峰值batch size 太小则噪声太大scale 跳动很厉害。2. 精度评估与延迟测量的正确姿势没有测量就没有平衡2.1 精度评估的三个层次不只是看平均指标量化效果好不好不能只看最终任务指标比如准确率、BLEU 分数有没有掉。任务指标太宏观它会掩盖很多局部问题。我建议分成三个层次去评估。第一层是任务级指标这个必须有但只作为过门槛标准。比如分类任务 Top-1 掉不超过 0.5%生成任务指标掉不超过 2%这只是“能不能上线”的下限不是“好不好”的标准。第二层是中间层特征对比。把量化模型的中间激活和原始模型做余弦相似度对比哪里相似度掉得多哪里就是敏感层。这个穿层对比相当好用它能帮你把掉点归因到具体的 block 或 head 上而不是笼统地“量化掉点了”。第三层是分布可视化。把量化前后的输出分布画出来重点看有没有太多的“离群值”被截断在量化范围之外。很多掉点其实只发生在长尾分布的少数极端输入上但那些极端输入往往是短视频、高分辨率图这类对体验权重高的场景不能光看平均指标糊弄过去。2.2 延迟测量里的坑warm-up、batch size 与统计口径延迟听起来简单实际上报数时稍有不慎数据就变得不可信。首先必须做 warm-up前几十次推理是在加载权重、建立缓存、初始化 CUDA context不算数。等运行稳定后再开始采样。我自己习惯用前 100 次作为 warm-up 不参与统计之后至少测 1000 次。batch size 的影响也很大。batch size 1 时测到的主要是算子和 IO 的串行延迟适合衡量单请求的响应时间。调大 batch 后测到的是吞吐和饱和计算能力。部署时候如果你的服务是单请求模式却拿大 batch 的吞吐报给业务方那是找骂。反过来你想压榨硬件最高利用率却拿 batch1 的延迟数据说话同样没意义。统计口径建议同时报 P50、P95 和 P99。P50 反映大多数请求的水平P99 反映最差的尾部延迟。量化对 P50 的影响通常小于对 P99 的影响因为 P99 往往来自输入长度过长的请求激活尺度溢出在长序列上更容易发生。2.3 精度和延迟之外显存、功耗、吞吐的联动仅盯精度和延迟两个指标容易漏掉一些“后知后觉”的问题。显存是其中一个。量化后模型体积变小但 KV Cache 可能还是大头尤其长上下文场景。量化方案发布后建议把显存峰值也固化进测试报告因为线上显存不足会导致 OOM 重启延迟直接飙到秒级精度再好也没意义。功耗在移动端和边缘设备上同样关键。INT8 和 INT4 的推理计算功耗可能相差 30% 以上。手机端电池续航天差地别模型量化后 CPU/GPU 占用下降发热减少用户的体感差距比几个毫秒更明显。如果做嵌入式设备功耗甚至比延迟还要优先考虑。3. 实操过程与核心环节实现从基线到收益落地3.1 第一步建立一套可信的基线我在做量化之前一定先建立一个完整的基线评估流程。这里有几个固定的动作选定评估数据集、确定评估指标、固定硬件环境和推理配置、测出 FP32/FP16 的延迟、吞吐、显存、功耗和精度指标。这些数据是后面所有比较的锚点一旦锚点不牢靠后面说什么都是空中楼阁。实际操作时我通常用一个脚本统一完成这五件事保证可重复。硬件环境要固定到具体型号、具体驱动版本和特定推理后端因为换一个后端或者换一个编译优化选项延迟和量化行为都完全不一样。基线建立后记得归档后面所有实验都拿新量化模型和这组基线比对别每次重测一套新基线不然不同批次的测试数据混在一起根本没法归因。3.2 第二步从最保守的方案开始跑通整条链路第一次上手量化我强烈建议不要直接挑战最低 bit 的极限。先用权重 INT8 激活 INT8 这种最成熟的方案跑通高质量校准、评估和部署的全链路。这一步不是为了拿到极限性能而是为了确认工具链没有大坑、数据通路没有丢精度、推理引擎能正常加载与执行量化模型。我曾经做过一个模拟项目一开始就直接上 INT4 权重量化结果模型跑起来精度掉得很厉害我花了一整天排查最后发现是推理引擎对 INT4 的 kernel 支持不够充分某些算子回退到 FP16精度和延迟都没达到预期。后来老实从 INT8 开始链路通了之后再看哪些算子是真正“值得”压成 INT4 的。从保守起步可以帮你把“工具链问题”和“量化方案问题”分开。3.3 第三步逐层分析精度损失定位敏感算子全量化跑通后精度可能掉了 1% 到 3%这时候就需要做敏感度分析。我用过两种高效的方法。一种是逐层替换法把量化模型某一层的权重换成 FP16 原始权重看最终指标能恢复多少。恢复得越多说明这一层对量化越敏感。用这个方法遍历所有层原则上就能得出敏感层排序。缺点是遍历成本高、耗时久适合模型层数不多的场景。另一种是代理指标法也就是前面提到的中间激活余弦相似度。跑一遍原始模型和量化模型逐层输出中间特征算相似度相似度低于 0.9 的层优先处理。这个速度快一次跑完能覆盖所有层缺点是不能完全反映最终任务指标的变化。实际中我会把两种方法结合先用代理指标全量扫描按敏感度排序取 Top 10 层再对 Top 10 做逐层替换验证这样速度和准确度都能兼顾。定位到敏感层后优先检查它是不是 attention 的 Q/K/V 投影层或者归一化层。这几个位置在多数模型里是量化最容易掉点的地方。我的经验是如果 Q/K/V 的权重量化掉点严重可以先试 per-channel 粒度不行就把该层改成混合精度保留 FP16通常能拿回大部分精度损失。3.4 第四步延迟数据的系统化采集与分析延迟测试建议单独做一个脚本包含 warm-up 多次采样 多 batch 测试。我常用的配置是 batch size 从 1、8、32 三个档位分别测量输出帧P50、P95、P99。有一个经验值是如果 INT8 的延迟比 FP16 只提升不到 5%先别怀疑量化没用去看是不是“内存墙”被顶到了。小模型或 IO 密集型算子在 INT8 下计算很快但数据加载反而可能变成瓶颈。这时候要从算子层面看每个 OP 在做什么找到真正耗时的那几个 kernel看量化前后的耗时对比重点看矩阵乘、归一化这类计算密集型的算子有没有吃到低精度的红利。另外延迟测试必须和精度测试是“同一份数据分布”下的结果。有的优化手段会在某些输入分布上表现好换个输入分布就拉胯。所以在延迟报告里同时标注测试输入的长度分布和复杂度属性这个细节能帮后面排查线上问题省很多功夫。3.5 第五步迭代调优——混合精度、敏感层保护与重校准当敏感层定位完成之后就进入了迭代调优阶段。核心思路是用最小的精度代价换取最大延迟收益。混合精度是这一步的核心策略。拿整个模型做 INT4 量化精度可能掉 5%但只把 20% 的敏感层留在 INT8其余 80% 全部压成 INT4精度可能只掉 1.5%而延迟改善几乎和全 INT4 持平。所以别迷信“全模型统一 bit 位”这种省事的做法混合精度才是量化工程里的真正价值点。重校准也是常用技巧。在量化过程中尝试不同的校准方式有的训练框架支持每个算子单独做校准有的可以选不同校准集。有时候换一个校准集就能把精度拉回 1 到 2 个点。我印象很深刻的是模拟项目 X我之前用 uniform 校准集激活量化掉点 2%改成 power law 采样校准集后掉点直接降到 0.8%。另外如果模型里有 BatchNorm 层可以先 bn 融合再量化。融合后的卷积层数值分布更稳定量化误差会明显减少。这是一个性价比非常高的步骤强烈建议先做再说。3.6 验收与回归量化方案上线前必须过这四关精度关在保留的评估集上确认任务指标掉点在预设阈值内。延迟关在真实部署硬件上测出的 P50/P95/P99 均达标。显存关峰值显存不超过分配份额长序列场景下也不爆显存。稳定性关连续跑 24 小时或者跑满 10 万次看有没有累积误差和内存泄漏。这四关缺一不可。我之前遇到过一个案例精度、延迟、显存都过了但上线不到一周就频繁报错查了半天是量化模型中某个算子对长尾输入触发处理分支时异常属于边界情况稳定性问题。所以稳定性测试还是别省量化模型的边界行为比稠密模型更难预判。4. 常见问题与排查技巧实录4.1 精度掉点大幅度从三个方向入手遇到掉点超过预期先别急着换更宽的位宽先按以下顺序排查第一校准集是不是有问题。置信度最高的嫌疑对象通常是校准数据与真实数据分布偏差太大比如线上是短视频封面图校准集却用了大量高清风景图。先把校准集换成贴近线上分布的数据说不定问题直接消失。第二激活值有没有越界。打印量化后各层的 scale看激活值 max 是否集中在几个离群点上。偶尔出现的超大值会把 scale 拉大后面的正常数值全被压缩到低精度档位精度损失不只是几个点的事。这时候用截断策略把百分位在 99.99% 以上的离群点直接截掉效果往往立竿见影。第三敏感层有没有被“一刀切”。如果统计结果显示某几个 block 的精度贡献极高那就别把全部层压到同一 bit 位。混出混合精度方案把敏感层保留在更高精度这一条前面已经详细说过是实战里最有效的保护手段。4.2 延迟不降反升为什么量化后反而更慢了量化后延迟增加主要有两个原因一是某些算子不支持低精度计算运行时回退到 FP16/FP32还要额外做一遍反量化相当于“多走一步”二是小算子在低精度下的 kernel 实现本身效率不高尤其是一些形状不规整、channel 数很小的层在大 batch 下收益为正小 batch 下反而更慢。排查办法是分阶段测耗时。先测整个模型的端到端延迟再用 profiling 工具按算子逐层看耗时。如果发现某个算子在量化后耗时反而变长了直接把它保护成高精度算子或者换一种推理后端看有没有更高效的 kernel 实现。有时候换一个 tensor 布局比如 NHWC 与 NCHW也能明显改观。还要提一句如果是为了低延迟而上 INT4但业务场景里输入长度变化剧烈INT4 的加速在长序列下有优势在短序列下可能被预处理和反量化开销抵消。这时候可以考虑只在长序列分支里启用 INT4短序列留在 INT8做成动态路由方案。4.3 校准集过拟合与静态校准的局限性静态校准的原理是用一小批统计分布代表线上所有情况局限性很明显遇到分布之外的输入量化误差就会变大。实践中常出现校准集里表现很好、真实场景精度却拉胯的情况。要降低过拟合风险可以动态校准。动态校准思路是运行时按输入 batch 的实际范围动态计算 scale。开销比静态校准大一些但精度有保障尤其适合输入分布特别分散的场景。如果你的硬件和推理引擎支持动态量化值得在敏感场景下测一轮。也有人用“多组校准量取平均”的办法比如准备三组不同来源的校准集分别生成 scale最后取合适的统计值融合。这比单组要稳但复杂度也上来了。我倾向于先看单组校准下的表现不够再加强制性更强的多组方案。4.4 输入形状变化与动态 shape 兼容模型部署时经常遇到动态 shape 请求尤其是 NLP 类模型输入长度不定。动态 shape 对量化影响很大激活值的 scale 如果是针对固定长度校准的遇到超长输入时超出部分的数值分布没被统计到量化误差就会显著增大。一个方案是在校准阶段引入不同长度的样本生成更泛化的 scale。另一个方案是设置分档短序列用一组 scale长序列用另一组。如果推理引擎支持 shape 变长时的 scale 动态切换优先用这种机制。最省事的方案反而是“限制线上请求长度”服务端对过长输入做截断或切片既守护量化精度也守住延迟天花板虽然不是最优雅的解法但最可靠。4.5 硬件适配差异同样的量化模型在不同平台上效果不同同样的 INT8 模型在某家 GPU 上跑得很好换到另一家 GPU 或者 CPU、NPU、手机端上结果可能天差地别。原因在于不同硬件 IP 对低精度运算的处理方式不同有的原生支持 INT4 乘加有的要先转成 FP16 做计算再转回 INT4有的在反量化上有专用电路单元有的全靠软实现。所以量化方案必须与目标硬件绑定来选型。做手机端优先考虑对端侧 NPU 支持最好的量化格式和算子做服务端以 GPU 上的 tensor core 支持能力为准。同一个模型如果要部署到多个平台建议为每个平台各做一套专用量化配置而不是强行用一套统一配置打天下。我在实际项目中吃过这个亏模型在测试服务器上量化后延迟降了 40%信心满满部署到生产环境后延迟反而比 FP16 还高。查下来的原因是生产机器的驱动版本较旧新的低精度 kernel 没有及时支持。最后把新驱动升级完才恢复正常。所以在做延迟对比时驱动版本和推理引擎版本必须列在测试报告里作为重要的复现参数。写在最后量化调优的几个个人习惯做了这么久量化几个习惯一直保留着所有实验前先写死随机种子保证校准过程可复现每次修改都留下完整配置记录方便定位是哪一步导致精度波动任何一次优化都必须同时附上精度和延迟两种数据不然只报一个指标等于白做。另外我越来越觉得量化调优不是一次性工程。模型上线后线上的输入分布会随业务变化而漂移。有条件的话定期用最新线上数据重新校准一次比上了线就放着不管靠谱得多。最后再分享一个我常用的“压箱底”小技巧将几个关键敏感层量化后如果精度还是不达标可以试试把它们单独做成一个小算子插到模型外面做后处理或者用量化模型的输出去微调一个小的精调头。这种土办法看起来不够“正经”但在紧急上线场景中救过我好几次。量化的方法论重要但解决问题的灵活性才是每个做落地部署的人最该积累的资产。
模型量化这事儿最折磨人的不是把模型压小也不是让它跑得更快而是每次一量化就觉得精度要崩了但指标没掉多少心里那块石头又放不下。这几年我做AI模型部署量化从一开始的“敢不敢上”变成了“必备流程”——显存不够、时延超标、带宽打满几乎每个要上线的模型最终都要走一遍量化这条路。而做得多了就会发现量化真正难的不是“会量化”而是精度和延迟之间那杆秤怎么摆。本文把我踩过的坑、调过的手段、以及衡量精度与延迟这套方法论做个系统整理适合正在做模型上线、推理加速、或者被“压缩率翻倍但效果不掉”这种KPI逼过的朋友参考。1. 量化方案的选型逻辑先搞清楚为什么精度会掉1.1 量化为什么能同时影响精度和延迟模型量化说白了就是把 FP32 的浮点权重和激活值用更低比特位宽的整数比如 INT8、INT4来表示。内存占用能降到原来的 1/4 甚至 1/8计算单元在处理低精度数据时吞吐更高所以延迟和显存压力一起降下来。但代价是数值从连续分布变成了有限几个离散的台阶信息量丢了一截精度掉一点是必然的。但这里有一个最容易被人忽略的事实延迟提升的真正来源未必是计算变快而是内存搬运变少。很多大模型特别是 LLM 类的推理瓶颈在显存带宽和缓存命中率权重变小之后加载权重的时间大大缩短延迟才有质的改善。这也是为什么有些模型量化后计算速度没怎么变但整体时延反而明显下降——它省的是 IO 的时间不是算术单元的时间。理解这一点才会明白为什么在有些场景下 INT8 比 INT4 还划算因为 INT4 虽然更省内存但反量化开销和精度损失可能把收益吃掉了大半。1.2 量化对象怎么选只压权重还是连激活一起压先说说只做权重量化的场景。如果激活值每条数据差异都很大或者硬件对激活的整数计算支持有限只量化权重是稳妥的第一步。这种方式最简单精度损失通常很小内存减少一半以上但延迟收益相对有限因为激活值还在用 FP16/FP32 计算。要追求更低延迟就得做权重和激活都量化的“全量化”。激活量化最难的地方在于校准——激活值的分布不是静态的它随输入变化尤其是有 BatchNorm 或者 attention 结构的模型激活值分布带有明显的“尖峰”特征直接按均匀分布去量化误差会集中在峰值附近经常一掉就是十几个点。还有一类是 KV Cache 量化。在做长序列生成类任务时KV Cache 占的显存是个大头把它从 FP16 压到 INT8显存占用立刻降低而且不会增加计算延迟反而因为 cache 数据量小、读写更快整体吞吐能提升不少。KV Cache 量化在模型部署中经常被当成“白嫖”项目因为它不直接改权重和计算的数值路径精度损失通常比全量化小得多。1.3 数据格式与量化粒度对称还是非对称、按层还是按通道量化格式的选择直接影响精度表现。对称量化简单、硬件友好但它的零点固定在 0如果数据分布整体偏移比如激活值全为正对称量化会浪费大量档位。非对称量化用 zero-point 来修正偏移精度更好但计算时候要多一次移位操作速度稍微吃亏。量化粒度的选择同样关键。Per-tensor 量化整层用一个 scale计算最简单但如果层里不同通道的数据范围差异大卷积层的权重很常见小数值的通道容易直接被压成 0信息全丢。Per-channel 量化每个输出通道单独算 scale精度恢复明显代价是存储 scale 的额外开销和计算时的稍微复杂化。我的经验是权重量化直接上 per-channel 基本无脑收益激活量化先用 per-tensor 看结果掉点严重再细化到 per-group。别一上来就堆组量化参数量大了排查起来会很头痛。1.4 校准数据集精度的大半条命都在这里很多人量化效果好与不好第一个怀疑模型第二个怀疑算法却忘了校准数据集可能早就埋了雷。校准集的作用是用一小批真实输入数据统计激活值的分布以此确定 scale 和 zero-point。它根本不需要带标签但一定要能代表真实线上输入的分布。我见过最典型的错误是用训练集做校准。训练集样本来自批量增强后的分布和真实部署时遇到的输入往往有偏差。更合理的做法是从一条线上采样日志里抽几百到一两千条样本覆盖各种极端情况比如空输入、超长文本、超亮图片、高噪声音频。校准集长度与批量大小也有讲究一般建议在校准时固定 batch size比如 64 或 128让统计到的分布更稳定。批量太大会抹平峰值batch size 太小则噪声太大scale 跳动很厉害。2. 精度评估与延迟测量的正确姿势没有测量就没有平衡2.1 精度评估的三个层次不只是看平均指标量化效果好不好不能只看最终任务指标比如准确率、BLEU 分数有没有掉。任务指标太宏观它会掩盖很多局部问题。我建议分成三个层次去评估。第一层是任务级指标这个必须有但只作为过门槛标准。比如分类任务 Top-1 掉不超过 0.5%生成任务指标掉不超过 2%这只是“能不能上线”的下限不是“好不好”的标准。第二层是中间层特征对比。把量化模型的中间激活和原始模型做余弦相似度对比哪里相似度掉得多哪里就是敏感层。这个穿层对比相当好用它能帮你把掉点归因到具体的 block 或 head 上而不是笼统地“量化掉点了”。第三层是分布可视化。把量化前后的输出分布画出来重点看有没有太多的“离群值”被截断在量化范围之外。很多掉点其实只发生在长尾分布的少数极端输入上但那些极端输入往往是短视频、高分辨率图这类对体验权重高的场景不能光看平均指标糊弄过去。2.2 延迟测量里的坑warm-up、batch size 与统计口径延迟听起来简单实际上报数时稍有不慎数据就变得不可信。首先必须做 warm-up前几十次推理是在加载权重、建立缓存、初始化 CUDA context不算数。等运行稳定后再开始采样。我自己习惯用前 100 次作为 warm-up 不参与统计之后至少测 1000 次。batch size 的影响也很大。batch size 1 时测到的主要是算子和 IO 的串行延迟适合衡量单请求的响应时间。调大 batch 后测到的是吞吐和饱和计算能力。部署时候如果你的服务是单请求模式却拿大 batch 的吞吐报给业务方那是找骂。反过来你想压榨硬件最高利用率却拿 batch1 的延迟数据说话同样没意义。统计口径建议同时报 P50、P95 和 P99。P50 反映大多数请求的水平P99 反映最差的尾部延迟。量化对 P50 的影响通常小于对 P99 的影响因为 P99 往往来自输入长度过长的请求激活尺度溢出在长序列上更容易发生。2.3 精度和延迟之外显存、功耗、吞吐的联动仅盯精度和延迟两个指标容易漏掉一些“后知后觉”的问题。显存是其中一个。量化后模型体积变小但 KV Cache 可能还是大头尤其长上下文场景。量化方案发布后建议把显存峰值也固化进测试报告因为线上显存不足会导致 OOM 重启延迟直接飙到秒级精度再好也没意义。功耗在移动端和边缘设备上同样关键。INT8 和 INT4 的推理计算功耗可能相差 30% 以上。手机端电池续航天差地别模型量化后 CPU/GPU 占用下降发热减少用户的体感差距比几个毫秒更明显。如果做嵌入式设备功耗甚至比延迟还要优先考虑。3. 实操过程与核心环节实现从基线到收益落地3.1 第一步建立一套可信的基线我在做量化之前一定先建立一个完整的基线评估流程。这里有几个固定的动作选定评估数据集、确定评估指标、固定硬件环境和推理配置、测出 FP32/FP16 的延迟、吞吐、显存、功耗和精度指标。这些数据是后面所有比较的锚点一旦锚点不牢靠后面说什么都是空中楼阁。实际操作时我通常用一个脚本统一完成这五件事保证可重复。硬件环境要固定到具体型号、具体驱动版本和特定推理后端因为换一个后端或者换一个编译优化选项延迟和量化行为都完全不一样。基线建立后记得归档后面所有实验都拿新量化模型和这组基线比对别每次重测一套新基线不然不同批次的测试数据混在一起根本没法归因。3.2 第二步从最保守的方案开始跑通整条链路第一次上手量化我强烈建议不要直接挑战最低 bit 的极限。先用权重 INT8 激活 INT8 这种最成熟的方案跑通高质量校准、评估和部署的全链路。这一步不是为了拿到极限性能而是为了确认工具链没有大坑、数据通路没有丢精度、推理引擎能正常加载与执行量化模型。我曾经做过一个模拟项目一开始就直接上 INT4 权重量化结果模型跑起来精度掉得很厉害我花了一整天排查最后发现是推理引擎对 INT4 的 kernel 支持不够充分某些算子回退到 FP16精度和延迟都没达到预期。后来老实从 INT8 开始链路通了之后再看哪些算子是真正“值得”压成 INT4 的。从保守起步可以帮你把“工具链问题”和“量化方案问题”分开。3.3 第三步逐层分析精度损失定位敏感算子全量化跑通后精度可能掉了 1% 到 3%这时候就需要做敏感度分析。我用过两种高效的方法。一种是逐层替换法把量化模型某一层的权重换成 FP16 原始权重看最终指标能恢复多少。恢复得越多说明这一层对量化越敏感。用这个方法遍历所有层原则上就能得出敏感层排序。缺点是遍历成本高、耗时久适合模型层数不多的场景。另一种是代理指标法也就是前面提到的中间激活余弦相似度。跑一遍原始模型和量化模型逐层输出中间特征算相似度相似度低于 0.9 的层优先处理。这个速度快一次跑完能覆盖所有层缺点是不能完全反映最终任务指标的变化。实际中我会把两种方法结合先用代理指标全量扫描按敏感度排序取 Top 10 层再对 Top 10 做逐层替换验证这样速度和准确度都能兼顾。定位到敏感层后优先检查它是不是 attention 的 Q/K/V 投影层或者归一化层。这几个位置在多数模型里是量化最容易掉点的地方。我的经验是如果 Q/K/V 的权重量化掉点严重可以先试 per-channel 粒度不行就把该层改成混合精度保留 FP16通常能拿回大部分精度损失。3.4 第四步延迟数据的系统化采集与分析延迟测试建议单独做一个脚本包含 warm-up 多次采样 多 batch 测试。我常用的配置是 batch size 从 1、8、32 三个档位分别测量输出帧P50、P95、P99。有一个经验值是如果 INT8 的延迟比 FP16 只提升不到 5%先别怀疑量化没用去看是不是“内存墙”被顶到了。小模型或 IO 密集型算子在 INT8 下计算很快但数据加载反而可能变成瓶颈。这时候要从算子层面看每个 OP 在做什么找到真正耗时的那几个 kernel看量化前后的耗时对比重点看矩阵乘、归一化这类计算密集型的算子有没有吃到低精度的红利。另外延迟测试必须和精度测试是“同一份数据分布”下的结果。有的优化手段会在某些输入分布上表现好换个输入分布就拉胯。所以在延迟报告里同时标注测试输入的长度分布和复杂度属性这个细节能帮后面排查线上问题省很多功夫。3.5 第五步迭代调优——混合精度、敏感层保护与重校准当敏感层定位完成之后就进入了迭代调优阶段。核心思路是用最小的精度代价换取最大延迟收益。混合精度是这一步的核心策略。拿整个模型做 INT4 量化精度可能掉 5%但只把 20% 的敏感层留在 INT8其余 80% 全部压成 INT4精度可能只掉 1.5%而延迟改善几乎和全 INT4 持平。所以别迷信“全模型统一 bit 位”这种省事的做法混合精度才是量化工程里的真正价值点。重校准也是常用技巧。在量化过程中尝试不同的校准方式有的训练框架支持每个算子单独做校准有的可以选不同校准集。有时候换一个校准集就能把精度拉回 1 到 2 个点。我印象很深刻的是模拟项目 X我之前用 uniform 校准集激活量化掉点 2%改成 power law 采样校准集后掉点直接降到 0.8%。另外如果模型里有 BatchNorm 层可以先 bn 融合再量化。融合后的卷积层数值分布更稳定量化误差会明显减少。这是一个性价比非常高的步骤强烈建议先做再说。3.6 验收与回归量化方案上线前必须过这四关精度关在保留的评估集上确认任务指标掉点在预设阈值内。延迟关在真实部署硬件上测出的 P50/P95/P99 均达标。显存关峰值显存不超过分配份额长序列场景下也不爆显存。稳定性关连续跑 24 小时或者跑满 10 万次看有没有累积误差和内存泄漏。这四关缺一不可。我之前遇到过一个案例精度、延迟、显存都过了但上线不到一周就频繁报错查了半天是量化模型中某个算子对长尾输入触发处理分支时异常属于边界情况稳定性问题。所以稳定性测试还是别省量化模型的边界行为比稠密模型更难预判。4. 常见问题与排查技巧实录4.1 精度掉点大幅度从三个方向入手遇到掉点超过预期先别急着换更宽的位宽先按以下顺序排查第一校准集是不是有问题。置信度最高的嫌疑对象通常是校准数据与真实数据分布偏差太大比如线上是短视频封面图校准集却用了大量高清风景图。先把校准集换成贴近线上分布的数据说不定问题直接消失。第二激活值有没有越界。打印量化后各层的 scale看激活值 max 是否集中在几个离群点上。偶尔出现的超大值会把 scale 拉大后面的正常数值全被压缩到低精度档位精度损失不只是几个点的事。这时候用截断策略把百分位在 99.99% 以上的离群点直接截掉效果往往立竿见影。第三敏感层有没有被“一刀切”。如果统计结果显示某几个 block 的精度贡献极高那就别把全部层压到同一 bit 位。混出混合精度方案把敏感层保留在更高精度这一条前面已经详细说过是实战里最有效的保护手段。4.2 延迟不降反升为什么量化后反而更慢了量化后延迟增加主要有两个原因一是某些算子不支持低精度计算运行时回退到 FP16/FP32还要额外做一遍反量化相当于“多走一步”二是小算子在低精度下的 kernel 实现本身效率不高尤其是一些形状不规整、channel 数很小的层在大 batch 下收益为正小 batch 下反而更慢。排查办法是分阶段测耗时。先测整个模型的端到端延迟再用 profiling 工具按算子逐层看耗时。如果发现某个算子在量化后耗时反而变长了直接把它保护成高精度算子或者换一种推理后端看有没有更高效的 kernel 实现。有时候换一个 tensor 布局比如 NHWC 与 NCHW也能明显改观。还要提一句如果是为了低延迟而上 INT4但业务场景里输入长度变化剧烈INT4 的加速在长序列下有优势在短序列下可能被预处理和反量化开销抵消。这时候可以考虑只在长序列分支里启用 INT4短序列留在 INT8做成动态路由方案。4.3 校准集过拟合与静态校准的局限性静态校准的原理是用一小批统计分布代表线上所有情况局限性很明显遇到分布之外的输入量化误差就会变大。实践中常出现校准集里表现很好、真实场景精度却拉胯的情况。要降低过拟合风险可以动态校准。动态校准思路是运行时按输入 batch 的实际范围动态计算 scale。开销比静态校准大一些但精度有保障尤其适合输入分布特别分散的场景。如果你的硬件和推理引擎支持动态量化值得在敏感场景下测一轮。也有人用“多组校准量取平均”的办法比如准备三组不同来源的校准集分别生成 scale最后取合适的统计值融合。这比单组要稳但复杂度也上来了。我倾向于先看单组校准下的表现不够再加强制性更强的多组方案。4.4 输入形状变化与动态 shape 兼容模型部署时经常遇到动态 shape 请求尤其是 NLP 类模型输入长度不定。动态 shape 对量化影响很大激活值的 scale 如果是针对固定长度校准的遇到超长输入时超出部分的数值分布没被统计到量化误差就会显著增大。一个方案是在校准阶段引入不同长度的样本生成更泛化的 scale。另一个方案是设置分档短序列用一组 scale长序列用另一组。如果推理引擎支持 shape 变长时的 scale 动态切换优先用这种机制。最省事的方案反而是“限制线上请求长度”服务端对过长输入做截断或切片既守护量化精度也守住延迟天花板虽然不是最优雅的解法但最可靠。4.5 硬件适配差异同样的量化模型在不同平台上效果不同同样的 INT8 模型在某家 GPU 上跑得很好换到另一家 GPU 或者 CPU、NPU、手机端上结果可能天差地别。原因在于不同硬件 IP 对低精度运算的处理方式不同有的原生支持 INT4 乘加有的要先转成 FP16 做计算再转回 INT4有的在反量化上有专用电路单元有的全靠软实现。所以量化方案必须与目标硬件绑定来选型。做手机端优先考虑对端侧 NPU 支持最好的量化格式和算子做服务端以 GPU 上的 tensor core 支持能力为准。同一个模型如果要部署到多个平台建议为每个平台各做一套专用量化配置而不是强行用一套统一配置打天下。我在实际项目中吃过这个亏模型在测试服务器上量化后延迟降了 40%信心满满部署到生产环境后延迟反而比 FP16 还高。查下来的原因是生产机器的驱动版本较旧新的低精度 kernel 没有及时支持。最后把新驱动升级完才恢复正常。所以在做延迟对比时驱动版本和推理引擎版本必须列在测试报告里作为重要的复现参数。写在最后量化调优的几个个人习惯做了这么久量化几个习惯一直保留着所有实验前先写死随机种子保证校准过程可复现每次修改都留下完整配置记录方便定位是哪一步导致精度波动任何一次优化都必须同时附上精度和延迟两种数据不然只报一个指标等于白做。另外我越来越觉得量化调优不是一次性工程。模型上线后线上的输入分布会随业务变化而漂移。有条件的话定期用最新线上数据重新校准一次比上了线就放着不管靠谱得多。最后再分享一个我常用的“压箱底”小技巧将几个关键敏感层量化后如果精度还是不达标可以试试把它们单独做成一个小算子插到模型外面做后处理或者用量化模型的输出去微调一个小的精调头。这种土办法看起来不够“正经”但在紧急上线场景中救过我好几次。量化的方法论重要但解决问题的灵活性才是每个做落地部署的人最该积累的资产。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
