1. 量化到底在压缩什么一次把收益算明白做模型部署的人应该都有过这种经历训练好的模型明明在离线评测里表现不错一上生产环境就被“内存超限”打回来。一个标准的 FP32 模型光权重就占 4 字节/参数几千万参数就是几百 MB再加上激活值、梯度、中间缓存设备端往往连模型都装不下。于是大家开始聊模型压缩而压缩的手段无非三类剪枝、蒸馏、量化。剪枝是把不重要的连接或通道去掉蒸馏是让小模型模仿大模型量化则是从“数值表示”层面下手——把连续浮点用更少的比特位来近似。这三者不冲突甚至可以叠加但真要说工程落地性价比量化一定排在前面。我为什么强调性价比因为量化不改变模型结构不需要重新训练整个任务大部分场景下甚至不需要动训练代码。你只需要把 FP32 的权重和激活值按一定规则映射到 INT8 的整数范围推理时用整数运算替代浮点运算。存储从 4 字节变 1 字节参数内存直接降到原来的四分之一计算上整数乘加指令在多数芯片上比浮点指令吞吐更高还更省电。一个典型的检测模型在端侧设备上做完 INT8 量化后推理延迟常常能压到原来的 60% 甚至更低模型体积也从几百 MB 降到几十 MB。适合谁来参考这篇内容如果你是刚接触模型压缩的算法工程师想搞明白量化到底怎么选、怎么做或者你已经在做部署遇到“量化后精度掉点”“推理没提速”这类问题都可以照着下面的思路排查一遍。我会把原理讲得尽量直白也会把实操里那些文档不会写清楚的坑直接摆出来。1.1 FP32 模型“重”在哪神经网络的计算本质上就是大量矩阵乘法。训练阶段我们用 FP32 甚至 FP16 的精度来保证数值稳定因为反向传播对误差很敏感梯度稍微不准参数更新就可能跑偏。但推理阶段不一样我们只需要前向计算。前向计算对数值精度的容忍度比训练高得多原因在于神经网络的权重和激活值通常都落在一个比较集中的分布区间里不是均匀铺满整个浮点范围。举个例子某两层卷积网络的权重分布绝大多数值集中在 -0.1 到 0.1 之间真正的大值很少。FP32 用 32 位去表示这么小的范围其实有大量比特位在“描述空气”。量化做的事就是用一小段整数刻度去覆盖这个真实的有效范围把那些用不上的精度丢掉。这样做能省多少单个参数从 4 字节变 1 字节是确定的模型体积直接打到 25%。但更关键的是内存带宽在线服务的吞吐瓶颈很多时候不在计算而在访存参数变小后加载权重的时间缩短缓存命中率提升推理请求的吞吐量也跟着上去。这一点在做大批量并发服务时感受尤其明显。1.2 INT8 推理为何能加速量化带来的加速主要有三个来源一是内存带宽压力降低二是计算指令更高效三是缓存更友好。很多人在讨论量化加速时只盯着“整数计算比浮点快”其实不全对。在部分硬件上FP32 和 INT8 的单次运算延迟差距没那么夸张真正的差距体现在并行度上一个时钟周期能塞进去的整数运算往往远多于浮点运算。也就是说单位时间能处理的矩阵元素更多。另外量化后的激活值也变成了 INT8中间特征图占用的内存大幅缩小。对卷积这类计算密集算子来说特征的搬运成本有时候比计算本身还高。激活从 4 字节变 1 字节意味着片上缓存能装下更多中间结果数据复用更好内存访问次数降低速度自然就上来了。这也是为什么很多量化方案会强调“激活量化”而不只是“权重量化”。如果你部署的目标是专用的 AI 加速芯片INT8 往往还是硬件的“主赛道”不少芯片甚至只对 INT8 做了高吞吐的定制单元FP32 反而要靠通用核来跑。这种情况下量化与否直接决定了你的模型能不能跑在硬件最强的算力上。1.3 量化收益的直观对比拿一个虚构的典型项目来说一个 50 MB 的 FP32 图像分类模型部署在某嵌入式设备上推理延迟约 80 ms内存占用约 180 MB。做 INT8 权重量化加激活量化后模型文件约 13 MB推理延迟约 45 ms内存占用约 70 MB。精度从 92.1% 掉到 91.6%属于可接受范围。项目FP32 基线INT8 量化后变化模型体积50 MB约 13 MB减少约 74%单次推理延迟80 ms约 45 ms缩短约 44%峰值内存180 MB约 70 MB减少约 61%准确率92.1%91.6%下降 0.5%当然这只是理想情况。如果你的模型本身很小、算子碎片化严重、部署环境对 INT8 支持又不好收益就没这么大甚至可能出现“理论省内存、实际没提速”的情况。这个我放到后面“实操问题”章节详细说。2. 方案选型先跑通再往细里抠量化不是只有一个招数。按“是否需要训练”来划分常见的有两大类训练后量化PTQPost-Training Quantization和量化感知训练QATQuantization-Aware Training。这两条路的成本、精度和适用场景差别很大选错会走很多弯路。2.1 训练后量化最快的“无痛瘦身”PTQ 的思路很粗暴模型训练好之后喂一小批校准数据统计每一层激活值的数值范围然后据此算出缩放系数把 FP32 权重和激活直接转成 INT8。整个过程不需要反向传播也不需要重新训练通常几十分钟就能搞定。为什么可以这么省事因为模型的权重已经收敛了权重的分布是固定的我们只需要找到合适的映射关系。唯一的麻烦是激活值它依赖于输入数据所以必须有校准数据去“预演”前向过程观察激活的取值范围。校准集选得好不好直接影响量化精度。PTQ 适合两类场景一类是模型比较大重训成本太高比如语言模型或者多模态模型重新训练一轮可能要几周另一类是项目周期紧需要快速验证量化方案的效果。我见过不少团队会把 PTQ 作为第一优先级先看掉点是否可接受再决定要不要上更重的方案。PTQ 的局限也很明显它完全依赖训练好的权重分布如果前后推理时的输入分布和校准集差太多量化误差会被放大。另外当模型对数值误差特别敏感时PTQ 往往压不住精度这时候只能靠 QAT。2.2 量化感知训练精度不足时的第二张牌QAT 的核心思路是在训练过程中就“模拟”量化的效果。具体做法是在网络里插入伪量化节点前向传播时把权重和激活先量化再反量化让浮点模型暂时背上一层“噪声”反向传播时再用直通估计器让梯度绕过量化的不可导部分。听起来复杂其实可以打个比方你训练时让模型提前适应“被人为降低精度”后的状态这样真正部署到 INT8 环境时模型不会因为数值变化而措手不及。精度通常能比 PTQ 高很多尤其在检测、分割这类对细节敏感的任务上。代价也很直接你得准备训练数据和完整的训练流程训练时间变长调参难度增加。伪量化节点会占用额外显存训练中断恢复也可能遇到状态不一致的问题。更麻烦的是QAT 对训练超参数比较敏感学习率策略稍微不对精度反而比 PTQ 还差。2.3 两者怎么选一张表讲清楚对比维度PTQQAT是否需要训练数据只需要少量校准数据需要完整训练数据与训练流程实施周期几十分钟到几小时几天到几周精度表现大模型通常可接受小模型波动大大多比 PTQ 好尤其对敏感层工程复杂度低基本不动训练代码高需要改动训练逻辑适用场景快速验证、大模型、迭代频繁精度要求高、小模型、敏感任务我的建议是不差时间的话先做 PTQ量化后测一轮精度。如果掉点在可接受范围内直接上线如果掉点明显再针对性做混合量化或 QAT。跳过 PTQ 直接上 QAT 属于“用力过猛”很多情况下浪费人力不说收益还不一定对等。3. 绕不开的数学scale、zero point 与三种量化细则理解了方案还得把量化本身的数学搞明白。很多人看到公式就头疼但量化的公式真的不多核心就两个量化公式、反量化公式。搞懂它们你就能看懂所有量化配置的含义。3.1 量化与反量化公式设原始浮点值为 r量化后的整数为 q缩放系数为 S零点为 Z。那么q round(r / S) Z r ≈ (q - Z) * SS 的作用是把浮点范围映射到整数范围。举例来说某层激活值的范围是 [0.0, 6.0]要量化为无符号 INT8整数范围是 [0, 255]。那么 S (6.0 - 0.0) / (255 - 0) ≈ 0.0235Z 0。浮点值 3.0 量化后是 round(3.0 / 0.0235) ≈ 128反量化回来是 128 * 0.0235 ≈ 3.008误差不到 0.3%。这里有一个新手常犯的误解S 不是随便取的它是由浮点范围与整数范围共同决定的。浮点范围取多大直接决定了量化的分辨率。范围取得太大小的浮点值容易被“淹没”在量化噪声里范围取得太小超出范围的值会被截断同样带来误差。找到那个能平衡“截断误差”和“舍入误差”的临界范围就是量化校准的核心工作。3.2 对称 vs 非对称量化对称量化把浮点范围按原点对称扩展即范围取 [-max(|r_min|, |r_max|), max(|r_min|, |r_max|)]Z 固定为 0。这样实现最简单反量化时不需要考虑零点偏移推理引擎在很多硬件上可以直接用更精简的指令去计算。非对称量化允许浮点范围整体偏移Z 可以不为 0能更精细地覆盖非对称分布。激活值经过 ReLU 之后通常都是非负的最小值是 0用非对称量化可以把整数刻度全部用在有效范围上分辨率更高。对比维度对称量化非对称量化零点固定为 0根据范围计算可非 0实现复杂度低硬件友好稍高多一次减法适用范围权重分布接近对称激活ReLU 后非负分布精度表现对权重好对激活好实操里的常见做法是权重用对称量化激活用非对称量化。原因很简单训练好的网络权重正负分布往往比较对称强行非对称化收益不大而激活值几乎都是非负的用对称量化等于白白浪费一半整数刻度非对称量化更划算。3.3 逐张量 vs 逐通道 vs 逐组除了对称与非对称量化粒度也影响精度。最简单的是 per-tensor整层所有数据共用一个 S 和 Z。实现最简单计算开销最小但一旦该层某个通道的值域特别大整个层的量化分辨率都会被拉低。进阶一点是 per-channel每一个输出通道单独算 S 和 Z。卷积的每个卷积核都可以有自己独立的缩放系数相当于把“量程”切得更细精度明显更好。代价是缩放系数变多部分硬件上实现起来要处理额外数据布局。再细还有 per-group把通道再分组每个组单独量化。这在一些大规模语言模型的权重量化里很常见因为逐通道对极端离群值依然不够精细。实际选型时我建议先看硬件支持如果推理引擎支持逐通道优先用逐通道如果不支持再考虑用更大的校准手段去弥补逐张量的精度损失。4. 手把手实操把一个浮点模型压到 INT8前面讲的是理论这一章进入真正动手的环节。我会用一套通用的流程来讲具体接口每个框架不一样但思路是通用的。整个过程可以拆成四步准备校准集、校准统计、参数转换、精度回归。4.1 准备校准集别在这步省时间很多人量化翻车第一步就栽在校准集上。校准集的作用是统计激活值的分布范围所以它必须能代表线上真实输入。常见误区有三种只用训练集前几百张图、只挑简单的样本、类别不平衡。我的建议是校准集样本数量在 500 到 2000 条之间比较合适太少统计不准太多边际收益递减。取样时要覆盖所有类别的典型情况最好加上线上真实采集的数据。如果业务场景是动态变化的比如光照、环境噪声差异很大校准集里要尽量包含这些变化。这里有个小技巧如果条件允许把线上真实请求的输入采样一轮作为校准集。训练集是离线数据分布和线上往往有偏差用线上数据校准能让量化模型更贴近实际情况。4.2 校准与转换的完整流程下面这段是典型的 PTQ 校准流程伪代码# 伪代码训练后量化校准流程接口以实际框架为准 def ptq_calibrate(model, calib_loader, quant_config): model.eval() # 1. 注册钩子记录每个量化算子的输入/输出激活分布 hooks register_activation_hooks(model, quant_config) # 2. 前向跑一遍校准集只统计分布不更新权重 with no_grad(): for batch in calib_loader: _ model(batch) # 3. 汇总每层激活的 min/max 或直方图 ranges collect_activation_ranges(hooks) # 4. 根据配置计算 scale 和 zero_point scales, zero_points compute_quant_params(ranges, quant_config) # 5. 把参数写入量化模型中 apply_quant_params(model, scales, zero_points) return model核心就是“观察分布、确定范围、计算参数”三步。其中第四步的计算方法有多种最简单的是 min/max直接用观察到的极值作为范围更稳一点的是 percentile把极端的 0.01% 离群点忽略掉还有基于 KL 散度或 MSE 的算法会遍历多种截断位置找让原始分布和量化后分布最接近的那个点。我个人的习惯是先用 min/max 跑一版精度可接受就先用着毕竟简单可靠如果掉点明显改成 percentile 或 MSE 再试。不要一上来就上复杂算法否则出问题时很难判断是校准算法的问题还是模型本身的问题。4.3 精度回归与性能基线量化完成后第一件事不是测速度而是测精度。用和浮点模型完全相同的评测集跑一遍量化模型的准确率。如果掉点在预定的阈值内比如 1% 以内才能进入性能测试环节。性能测试要注意对照条件一致同一台设备、同一个输入尺寸、同一套推理框架配置。分别记录浮点模型和量化模型的内存占用、单次推理延迟、吞吐量。我建议多跑几轮取平均值第一轮预热的数据不能要因为缓存和指令页还未就绪结果会偏高。另一个容易忽略的点是模型体感变快不等于吞吐变快。有的模型单请求延迟下降了但服务器并发处理时量化的缓存优势会被掩盖。所以性能评估应该以端到端压测为准而不是只看单次推理。4.4 端侧部署必须注意的算子融合如果你的目标是移动端或嵌入式设备还有一个额外重点算子融合。量化后的 INT8 算子如果还是逐个调用通用算子库每次运算都可能伴随数据格式转换反而比浮点更慢。常见做法是把量化反量化操作融合到上下算子中或者把连续的卷积、批量归一化、激活函数融合成一个算子。一个典型的融合链是“卷积 批量归一化 ReLU”合成一个算子。批量归一化在训练时是一层独立计算部署时它的参数可以直接折进卷积权重里ReLU 则可以被量化节点吸收。融合之后数据在寄存器里的流转次数减少INT8 的优势才能真正发挥出来。所以部署前一定要确认推理引擎对目标算子的融合支持情况。有些算子比如某些动态形状的算子不支持 INT8引擎会把它们保留在 FP32这种情况会出现“模型变小了但推理没快多少”的现象因为计算热点根本没走到 INT8 上去。5. 实战问题库掉点、变慢、没效果这部分是我最想写的。量化方案原理不难难的是在生产环境里遇到各种莫名其妙的问题时能有一条清晰的排查思路。下面几个问题是我在实际项目中反复遇到的每个都附上排查路径。5.1 精度掉了先别急着上 QAT遇到量化后准确率明显下降第一反应不应该是“我要用 QAT”而是先定位“哪一层在掉点”。做法是逐层量化测试只量化第一层其他层保持浮点跑一遍精度再只量化第二层跑一遍精度。这样扫描一轮通常能找到那么一两层是“精度黑洞”。这一两层往往就是敏感层它们的激活值分布可能极其不均匀或者包含大量离群值。针对敏感层有两个选择一是对该层不做量化保留 FP32 精度这就是混合量化二是改用 per-channel 或更细致的量化粒度。这两种方案都比全模型 QAT 成本低得多。我见过一个项目模型量化后准确率掉了 8 个点逐层测试后发现是某一个特定层的激活值有几个极端大的离群点把量化范围整体拉大导致大量正常值被压缩到低分辨率区。后来把校准算法从 min/max 换成 percentile忽略掉那 0.01% 的离群点掉点直接回到 1.5% 以内。所以掉点时先问校准算法再问量化粒度最后才考虑训练方案。5.2 校准集“看起来正常”却掉点还有一种情况更隐蔽校准集数量、类别都平衡跑出来的激活分布也合理但量化模型在真实数据上就是明显掉点。后来排查发现是校准集和线上数据的分布有偏差。具体来说某个语音唤醒项目训练数据都是清晰室内环境线上却经常有嘈杂背景声。校准集里没有包含这些噪声特征激活分布统计自然偏向“安静场景”。模型量化后对噪声输入特别脆弱。解决办法有两个层面最直接的是在部署环节采集线上真实样本补充进校准集另一个是把特征分布做一下预处理比如做标准化、限制动态范围让模型对输入变化的敏感度降低。这类问题很难从单次评估里发现我建议量化评估时除了整体准确率还要按类别、按场景切分统计看掉点是否集中在某个子集上。5.3 量化后推理不加速反而变慢这大概是让人最沮丧的问题模型文件小了精度也没怎么掉但推理延迟一点没降有时还变慢。常见原因有以下几种。第一种计算热点不在被量化的算子上。比如一个网络里有一个大矩阵乘法但它没走量化算子而是走了 FP32 的通用实现真正占时间的小算子反而被量化了整体收益自然不明显。排查方法是看性能 profile识别热点算子。第二种算子碎片化导致的数据转换开销。如果量化算子和非量化算子交替出现引擎在每次边界都要做 FP32 到 INT8 的格式转换这个转换本身有成本。层数越多转换开销越明显甚至覆盖掉量化省下的计算时间。解法是算子融合前面提到过。第三种硬件指令集不支持。部分 CPU 虽然能跑 INT8 指令但默认调度没开或者推理引擎没开启对应的指令优化。检查一下部署环境的低精度指令开关有时候一个配置没打开量化就白做了。我把精度和性能问题的排查要点整理成一张速查表现象可能原因排查方向精度掉点明显校准算法不合理改用 percentile 或基于分布的校准精度掉点集中某类校准集偏差补充线上真实样本按类别统计敏感层导致掉点个别层对误差敏感逐层测试敏感层混合量化激活值有极端离群点范围被拉大截断离群值、放宽范围推理不加速热点算子未量化性能 profile 定位热点推理变慢算子碎片化做算子融合减少格式转换推理不变引擎配置未开低精度检查低精度指令开关5.4 我踩过的一些坑再分享几个日常操作层面的经验都是常规文档不会写的。第一个校准集批次大小要固定。同样的数据用批次 32 和批次 1 统计出来的激活分布是有差别的因为批量归一化层在统计模式下的行为会受输入批次的统计特征影响。校准和部署时必须用相同的批次大小否则可能引入偏差。第二个千万别把量化模型再次放到训练模式里。量化模型里的伪量化节点在训练和推理模式下行为完全不同。有些人直接在训练脚本里顺手把量化模型又喂了一轮迭代结果精度莫名其妙地下降还以为量化方案有问题。第三个多版本模型管理要留痕。量化是一套独立的配置组合校准集、校准算法、量化粒度、混合量化策略每一组都可能产生一颗不同的量化模型。我在项目里吃过亏几周后想复现一个结果却发现已经不记得当时用的是哪套校准集了。建议每次量化都记录下配置参数和对应的精度、性能数据这比记代码还重要。6. 量化往后的扩展思路量化做完之后还有几个方向可以继续挖。一个是“量化剪枝”的组合先剪掉冗余通道再量化两者叠加的内存收益经常能到 10 倍以上。另一个是“量化蒸馏”用一个高精度大模型做教师蒸馏一个量化学生模型在端侧场景很常见。我个人的看法是量化不是一个“做完一次就结束”的工作。当业务数据变化时校准集的分布也要跟着更新硬件平台升级时量化参数可能需要重新调优。把它当成一个持续维护的工程流程比当成一个一次性任务踩坑的概率会小很多。最后再分享一个小习惯我每次做量化都会先建立一份“精度基线文档”把浮点模型的各场景准确率、延迟、内存逐项记下来。这样后续不管改了校准集还是换了部署环境都能快速看出差异出现在哪一环。这个习惯救过我不少次。