如果你最近在折腾大模型部署或者只是把 ResNet、BERT 之类的东西塞进生产环境大概率绕不开“量化”这个词。量化Quantization简单说就是把模型里 FP32、FP16 的参数和中间计算折算成 INT8 甚至更低精度的整数去跑换来的就是更低的显存占用、更快的推理速度和更低的功耗。这篇文章我会结合自己在实际项目里踩过的坑把 INT8 矩阵乘、校准、QAT 以及 LLM 量化这几个环节串起来讲尽量做到既有原理、能听懂又有可以直接抄走的实操步骤。这篇文章适合谁不管你是刚接触部署优化的新手还是已经在用 TensorRT、vLLM 但总被精度问题折磨的工程师都值得往下看。我会先用“算力账本”说清楚为什么要做量化再逐层拆开 INT8 矩阵乘的底层逻辑然后讲校准和 QAT 这两条主流路线最后专门聊一下大语言模型量化和传统 CNN 量化到底哪里不一样并给出一套完整的落地步骤和问题排查表。1. 为什么要做量化这是一笔算力账本很多人一听到量化第一反应是“用来省显存”。这话没错但只说对了一半。真正遇到瓶颈的时候你会发现显存只是表面背后的计算吞吐、内存带宽、功耗才是影响部署成本的关键量化恰好能把这三笔账同时算下来。1.1 从 FP32 到 INT8三种格式到底差在哪先过一遍基础。FP32 是 32 位浮点FP16 是 16 位浮点INT8 是 8 位整数。直观上看一个 FP32 的权重参数占 4 字节FP16 是 2 字节INT8 是 1 字节所以权重从 FP32 换成 INT8理论上模型体积直接缩到四分之一显存占用也近似跟着缩。对显存经常卡在边界上的部署场景这一步就能省出非常大的空间。更关键的是计算吞吐。GPU 里的 Tensor Core 对 INT8 的支持通常都是 FP16 的两倍甚至更多对 FP32 就更高倍率了。比如 NVIDIA 安培架构之后INT8 的矩阵乘吞吐基本能到 FP16 的两倍FP16 又能到 FP32 的两倍左右。换到支持 FP8 的 Hopper 和 Blackwell 架构情况会复杂一些但整数计算依然是省力不省功的路线。这也是为什么很多推理框架宁愿牺牲一点精度也要优先跑 INT8。还有一个经常被忽略的点是内存带宽。LLM 这类生成式模型在解码阶段是极其吃带宽的每个 token 都要把权重重新读一遍这个过程和算得快不快关系不大反而和“单位时间内能从显存搬到计算单元多少数据”强相关。权重从 16 位压到 8 位带宽压力直接减半解码速度自然跟着涨。1.2 量化的收益不只是“省显存”我做过一个相对极端的对比同一个 7B 参数量的开源模型FP16 版本在单张消费级显卡上大概需要 14GB 以上显存换成 INT8 版本之后就降到 7GB 左右同时解码的 token 生成速度提升明显。这里面的换算逻辑很简单显存占用变小意味着 batch size 可以开得更大带宽需求降低意味着每个请求的响应时间更短而能耗跟着降下来则是在线服务长期运营的一笔实打实的成本。要澄清的是量化的这些收益不是白拿的。精度会掉一点需要校准或者训练来补开发调试成本也会增加。绝大多数情况下收益远大于损失但前提是你要知道自己模型的精度底线在哪里。如果是一个误分类代价极高的医疗影像模型也许 INT8 就需要慎用或者必须配合 QAT 来保住指标如果是一个聊天机器人或者内容摘要系统INT8 乃至更低比特量化带来的收益往往非常可观。打个生活化的比方。你有一个书架放满了精装书FP32每本书都带大号字体和厚纸张。搬书架很累也很占地方。现在你把这些书全部改成小字号、薄纸张的简装版INT8内容还在清晰度略有下降但书柜容量翻了四倍搬运起来轻快得多。什么时候能接受简装版、什么时候必须保留精装版这就是量化部署决策的本质。2. INT8 矩阵乘的底层逻辑矩阵乘是神经网络的基本操作。量化能不能真正提速取决于底层的矩阵乘到底是怎么算的。这里我到算子层面讲清楚读完你自己也能判断什么场景适合 INT8。2.1 量化公式scale 和 zero-point先说核心公式。把一个浮点数 (r) 映射到整数 (q)通常用下面这个公式[ q round(\frac{r}{scale} zero_point) ]其中 scale 是一个正的浮点数zero_point 是整数偏移用于处理非对称分布。反量化则是[ r scale \times (q - zero_point) ]scale 和 zero_point 怎么来如果是 per-tensor 量化就拿整个张量的数值范围来算[ scale \frac{max_value - min_value}{255} ]zero_point 则是对应到浮点最小值被映射成哪个整数。如果我们做对称量化zero_point 固定为 0公式就简化为[ q round(\frac{r}{scale}) ]对称量化因为实现简单、不需要额外的加减偏移在很多推理引擎里是默认选项尤其是权重。非对称量化则更灵活在激活函数输出分布明显偏斜的时候更有效。你可能会觉得这些东西不就是几个数学公式吗有什么可讲的。但其实后面所有坑包括精度下降、算子不兼容、校准集选不好全都是这几个公式在不同场景下的连锁反应。理解公式就是理解所有问题的源头。2.2 对称量化 vs 非对称量化对称量化把浮点范围看成关于 0 对称的即 ([-max_abs, max_abs]) 映射到 ([-128, 127])。优点是乘法运算时不用处理 zero_point 带来的整数加减INT8 矩阵乘的实现会简单很多缺点是如果数据分布明显偏向一边比如激活值只在 [0, 6] 之间那对称量化会浪费一半的整数表示范围精度损失变大。非对称量化可以把 [0, 6] 映射到 [0, 255]把 256 个整数档位全部利用起来。代价是计算时需要多一步减去 zero_point 的操作在矩阵乘实现里会引入额外的整数运算效率略低。实际操作里我一般建议权重用对称量化激活值看分布情况选择。很多框架在 x86 上都支持得很完整TensorRT 的 INT8 默认也是对称式校准而某些移动端框架则更偏向非对称。选哪种不是拍脑袋决定的要用校准后的分布图来辅助判断。2.3 GEMM 里发生了什么一个标准的 INT8 矩阵乘输入是 INT8 的激活值和 INT8 的权重两者相乘要用 32 位整数累加器来累加。为什么不能用 INT8 做累加因为两个 INT8 相乘的结果最大是 (127 \times 127 16129)超过了 8 位能表达的范围所以硬件里都是把乘出来的结果累加在 INT32 里最后再一次性反量化为 FP32 输出给下一层。这个过程具体展开是输入激活 (A) 和权重 (W) 分别做量化得到 (A_{int8}) 和 (W_{int8})。在 INT32 精度下做矩阵乘累加得到 (Acc_{int32})。乘上 scale_factor ( scale_A \times scale_W)把 INT32 结果反量化回浮点。如果下一层还是 INT8就再量化一次如果输出需要给浮点算子就直接以 FP16/FP32 继续。所以你看到的推理框架日志里“quantize/dequantize 节点”其实就是为了在计算图上把这些 scale 转换串起来。现在 TensorRT、ONNX Runtime、openvino 等框架会自动插入这些节点但理解背后的流程排查问题时才不会一头雾水。2.4 一个直观的矩阵乘小算例为了把公式落到地上我们算一个极小的例子。假设某个矩阵的一行数值是 ([0.5, 2.0, 3.5])采用对称量化最大绝对值是 3.5scale 3.5 / 127 ≈ 0.02756。那么量化结果是0.5 → round(0.5 / 0.02756) ≈ 182.0 → round(2.0 / 0.02756) ≈ 733.5 → 127反算回去分别是 0.496、2.012、3.5精度损失在这个例子很小但如果你把 scale 换成某个对整体范围敏感的值比如数据里有个异常大的点 100其他点都分布在 1 附近那 1 量化后可能四舍五入变成 1 或 2损失就非常严重。这就是后面要讲校准方法存在的原因目的就是让 scale 既能覆盖动态范围又不浪费整数表示精度。3. 校准PTQ 的关键一步Post-Training QuantizationPTQ也就是训练后量化是最常见的量化方式。你不用重新训练模型只需要拿一批有代表性的数据跑一遍前向统计各层激活值和权重的数值分布然后算出合适的 scale 和 zero_point。这里最核心、最容易翻车的部分就是校准Calibration。3.1 校准集怎么选校准集不是验证集也不是测试集它是一小批用来“观察”模型中间层输出分布的数据。选得好不好直接决定量化后的模型精度。我踩过最典型的坑是拿 ImageNet 的验证集去校准一个用业务私有数据微调过的检测模型结果量化后 mAP 掉了 8 个点。后来换成了 500 张真实业务场景下的图片尤其是包含模型最容易出错的那类目标精度掉到了 1 个点以内。选校准集的核心原则是要和模型在真实部署时看到的数据分布一致。如果部署场景是医疗影像就别拿自然图片去校准如果是金融文本分类就别拿新闻语料。样本数量不需要多通常几百张到一千张就够了关键在于代表性。多样性能覆盖长尾情况但也不能为了多样性丢掉主要分布要平衡。还有一个常见误区把校准集当成训练集。校准过程不更新任何权重只是统计数据分布如果拿训练数据去校准会造成统计偏差让量化后的模型在训练集上表现好、在真实场景上表现差。那种“量化后准确率不降反升”的情况有时候就是因为校准数据本身泄漏了分布信息。3.2 校准方法MinMax、Percentile、KL 散度与 MSE选好数据之后要决定怎么从统计数据里算出量化范围。常用的方法有几种MinMax直接取整个张量的最小值和最大值作为量化范围实现最简单但容易受到异常点影响一个突发的大数值会让整体精度浪费。Percentile取分布里的某个百分位作为最大最小值比如 99.99%能剔除极端异常点。问题是百分位怎么选太低会截断有效范围太高又跟 MinMax 差不多。KL 散度让量化后的分布和原始浮点分布之间的 KL 散度最小。TensorRT 的经典默认方案就是基于这个思路它会尝试把浮点分布“裁剪”到不同边界然后选出 KL 散度最低的那个阈值。优点是自适应较好缺点是统计计算比较贵且依赖参考分布的质量。MSE用均方误差最小化来搜索最优截断阈值。这个思路更直接让量化前后的输出张量差异最小。实际效果通常不错但需要有足够多的校准样本才能稳定。没有绝对“最好”的方法。我在实际项目里的经验是对于大多数 CNN先用默认的 KL 或 MSE 就能拿到可用的结果如果精度出问题再回头调整校准集和百分位。对于 LLM 这种激活值有大量离群点的模型“一刀切”的校准方式经常不够用需要引入后面的 SmoothQuant、AWQ 这类方案这是第 5 章的内容。一个非常实用的排查技巧把校准集从 100 张加到 1000 张如果量化后精度没有明显变化那说明你的校准流程大概率是稳定的如果加了数据精度反而掉了那就要怀疑是不是校准集里混入了和部署场景差异较大的样本。3.3 Per-tensor、Per-channel 与 Per-group除了校准方法粒度也是决定精度的关键。per-tensor 就是整个张量共用一个 scale实现最简单但遇到权重不同通道数值范围差异较大时误差偏大。per-channel 就是对每个输出通道分别统计 scale精度提升明显某些硬件上会增加一点点开销但大多数框架都支持。per-group 更进一步对更小的块分别量化主要用于低比特场景比如 4bit 量化。一个直观的例子如果某一层权重 90% 的通道数值分布在 [-0.1, 0.1]剩下 10% 分布在 [-1.0, 1.0]per-tensor 量化会把 scale 拉大十倍前 90% 的通道全被压到几个整数档位上精度损失惨重。per-channel 量化后每个通道有自己的 scale就不会出现这种“为少数通道买单”的浪费。在 LLM 权重量化里现在最流行的做法是 per-group通常以 128 个元素为一组每个组独立计算 scale。这样做比 per-channel 更精细能在 4bit 下把模型质量保持得很好。代价是 scale 的数量变多显存和计算开销增加一点但综合收益显著。3.4 校准实操流程我这里给一个通用的校准流程适用于大多数 PyTorch 模型转 ONNX 再量化的场景准备一个有代表性的校准数据集通常 2001000 条样本存成 DataLoader。用浮点模型跑一遍前向同时把每层的激活值分布保存下来。如果框架支持自动校准这步就是调用 API。根据分布选择合适的校准算法算出每一层的 scale 和 zero_point。用验证集对比量化前后模型的精度和速度。如果精度低于预期按照“校准集 → 校准方法 → 量化粒度 → 层敏感度”这个顺序排查。我会在后面实操章节给出一个具体的代码风格示例但核心思路就是你得先让量化引擎“看见”你真实的数据分布否则什么高级配置都白搭。4. QAT量化感知训练PTQ 虽然省事但在某些模型上精度不够这时候要上 QATQuantization-Aware Training量化感知训练。QAT 的思路是在训练过程中模拟量化的误差让模型学会在整数精度下也能保持准确率。4.1 为什么 PTQ 有时不行PTQ 最怕两类情况一类是模型权重或激活值的分布特别“不配合”比如有大量离群点导致无论怎么选 scale 都会有很大误差另一类是模型本身对数值变化非常敏感比如某些小模型、注意力层多的模型、或者训练得过于紧凑的模型一点点误差就会被放大到结果层面。还有一个常被忽视的原因是BatchNorm 层在推理时会被折叠到卷积里但如果校准时的 BatchNorm 统计量和训练时不一致量化后误差会格外明显。PTQ 阶段模型没有机会“适应”这种变化而 QAT 可以通过训练把这些问题吸收掉。4.2 Fake Quant 与 STEQAT 的核心机制叫 Fake Quant翻译过来就是“伪量化”。在训练阶段前向传播时先用量化公式把数值转成 INT8 再转回浮点让模型尝到量化的“口感”但权重和梯度仍然以浮点形式保存和更新。这样反向传播里梯度可以使用浮点精度继续更新而不是被量化截断。这里有个关键难点量化过程中的 round 操作是不可导的梯度无法直接传回去。解决办法是用直通估计器STEStraight-Through Estimator把梯度绕过 round 操作直接传给前面的浮点权重。简单说就是前向走量化通道反向假装没有量化这回事。QAT 的过程可以理解成一个“带着沙袋训练”的过程。平时跑步不穿负重比赛才脱下成绩可能发挥不好训练时就穿沙袋比赛时换上轻装反而能跑出更好成绩。QAT 里的“沙袋”就是量化误差模型在训练阶段就不断适应这种误差最后转换到真正的 INT8 推理时自然比 PTQ 更稳。4.3 QAT 的训练细节与注意事项建议在预训练模型基础上做 QAT而不是从头训练。训练 epoch 可以很短比如 10%20% 的完整训练进度就够了训练太久反而可能过拟合到校准集或者造成精度震荡。学习率要比正常训练小很多通常用原始最大学习率的百分之一甚至更低。先冻结部分层比如先量化敏感度低的卷积层再逐步加入敏感层可以降低训练难度。用余弦退火学习率策略让模型在量化噪声下稳定收敛。训练时要保证有足够多的数据否则 QAT 效果会很差。数据量太小模型会把量化误差“背下来”真实场景一换数据就原形毕露。QAT 的代价显然比 PTQ 高需要训练资源、需要设计训练 pipeline、需要额外调试时间。因此我通常只在 PTQ 精度不达标时才上 QAT或者目标设备很特殊比如只有 INT8 加速、不接受 FP16以及模型精度要求极其严格时使用。4.4 什么时候值得用 QAT我总结一个决策逻辑模型对精度极其敏感PTQ 掉点超过你无法接受的范围。部署硬件只有 INT8 / 更低整数计算能力且没有 FP16 备用方案。你做的模型会在大量不同输入上被反复调用精度下降会被用户明显感知。你有充足的数据和算力团队能接受训练周期的延长。最近大模型领域针对少数关键层做“QAT 式微调”的做法也越来越常见核心思想其实一样让这些层在量化后依然保持鲁棒。它不一定叫 QAT但本质都是让模型“适配”量化误差。5. LLM 量化和传统 CNN 不太一样大语言模型量化在最近两年变成了一个非常火的主题因为它直接关系到我们能不能在有限算力下跑起更大的模型。LLM 量化有不少独特的难点和传统 CNN 的量化逻辑不完全一样。5.1 LLM 量化的难点激活值里的“异常点”LLM 的激活分布在特定通道上会出现非常离谱的大数值这些“离群通道”虽然数量少但数值幅度可能是其他通道的几十倍甚至上百倍。如果按 MinMax 或普通 KL 校准量化范围会被这些离群值占满其他通道被挤压到几乎没有区分度精度哗哗往下掉。这跟传统 CNN 完全不一样。CNN 激活值分布相对“老实”少量异常点不会造成那么大影响但 LLM 的隐藏层维度极大注意力头之间的数值尺度差异极大异常点的存在感特别强必须用专门手段处理。5.2 权重量化 vs 激活量化 vs KV Cache 量化理解 LLM 量化之前要区分几个量化对象权重量化只把模型权重转成 INT8 或更低精度激活仍然是 FP16。这种方案最简单不需要校准数据但收益有限因为解码阶段最占资源的权重读取带宽确实降了速度提升明显而计算部分没有充分利用 INT8 矩阵乘。动态量化运行时动态把激活量化到 INT8权重可以预先量化。这个方案能加速计算部分但需要在推理引擎里实现良好的融合算子复杂度更高。KV Cache 量化自回归生成阶段要缓存历史 token 的 key 和 value缓存越大内存带宽压力越大。把 KV Cache 压到 INT8 甚至 4bit能明显提升长文本场景下的吞吐。最近业界的部署趋势是能同时量化权重、激活和 KV Cache 的方案比如 GPTQ 做权重 4bitSmoothQuant 处理激活值再配合 KV Cache INT8 量化组件效果最好。5.3 GPTQ、AWQ 与 SmoothQuant 的基本思路GPTQ一种基于二阶梯度信息的训练后权重量化方法目标是让量化后的权重矩阵尽可能接近原矩阵的输出结果。它按列逐层量化利用 Hessian 信息补偿量化误差是目前权重 4bit 量化的经典方案。实际用起来就是拿一个校准集把每层权重“自适应”地压到 34bit效果在开源模型上普遍不错。AWQActivation-aware Weight Quantization从激活值的角度感知哪些权重通道更重要然后对重要通道做更精细的量化或者用缩放技巧降低重要通道的误差。思路很直观权重的重要性不是由权重本身决定的而是由它对应的激活大小决定的。把重要通道保护好整体精度就稳。SmoothQuant针对激活离群值问题巧妙的把激活值的波动“转移”到权重上。做法是在线层之间调节 scale让激活分布变得更平滑权重分布虽然变“参差”但可以通过 per-channel 权重量化来吸收。好处是激活可以真正量化到 INT8计算部分能跑起实数矩阵乘。这三者不是互斥的实际工程里经常搭配使用。举个常见的组合AWQ 做权重量化 SmoothQuant 做激活量化 KV Cache 用 INT8基本都是流水线配合。对于 GPTQ 和 AWQ 这类用校准集的方法校准集质量依然是生命线和前面讲 PTQ 时的原则一样。另一个要提到的方案是 GGUF/GGML 体系的量化格式q4_0、q8_0 等它在 llama.cpp 生态里非常流行本质上是针对 CPU 推理优化的一套量化方案。很多下载站会直接标明“q8_0 量化版”模型这类模型在“系统提示”里常出现说明量化在开源社区里已经是默认的基础能力了。它和硬件厂商的主导方案思路不同但底层原理都是围绕 scale、zero_point、group size 这些概念。5.4 部署集成vLLM、TensorRT-LLM 与 transformers到了工程落地层面你需要选推理框架。vLLM 对 GPTQ、AWQ、FP8 这些量化格式支持得比较完备你可以在启动时直接指定量化方式和参数比如--quantization awq。TensorRT-LLM 对 INT8 权重和激活的融合更彻底是做极致性能时绕不开的选择。transformers 自带bitsandbytes支持适合快速验证和低资源推理。我在实操中积累的体会是先用简单的框架验证量化的精度和收益确认值得之后再上重框架做极致优化。不要一上来就是 TensorRT-LLM 加各种自定义 kernel调试成本会非常高。你想要的只是一个能稳定跑起来、精度可接受、速度有明显提升的版本框架的复杂度由业务需要和硬件形态决定。6. 实操现场把一个开源 7B 模型量化到 INT8这一章我会带你走一个完整的实操以时下常见的开源 7B 模型为例展示从“拿到 FP16 权重”到“部署 INT8 版本”并验证效果的过程。不同模型、不同框架的细节有差异但整体思路完全通用。6.1 环境准备与模型下载你需要准备一台有 NVIDIA GPU 的机器显存建议至少 8GB。软件方面Python 3.10PyTorch 2.xTransformersvLLM 或 AutoGPTQ 这类推理库。如果使用国内网络可以设置 Hugging Face 镜像站的环境变量来加速模型下载比如把HF_ENDPOINT指向国内镜像或者直接从 ModelScope 平台下载开源模型。这一步不是因为模型特殊而是社区模型下载的基本操作。注意一点下载量化版模型时一定要看清量化格式。同样是 4bitGPTQ 的格式和 AWQ 的格式不通用GGUF 格式在 vLLM 里也需要特定支持。爆一个典型的坑我遇到过直接下载 q8_0 格式的 GGUF 想放到 TensorRT-LLM 里用结果完全不识别只能重新走一遍量化流程。6.2 用 GPTQ 做权重量化假设你想把一个 FP16 的 7B 模型量化为 GPTQ 4bit 或 8bit可以用 AutoGPTQ 这样的大致流程from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM model_name your-org/your-model-fp16 tokenizer AutoTokenizer.from_pretrained(model_name) calibration_samples [ 深度学习的模型部署需要注意量化关键技术, 量化就是把浮点数映射到整数区间尽量保持精度, # 准备 20200 条有代表性的文本越长越好 ] quantize_config { bits: 4, # 4bit 或 8bit group_size: 128, # 常用 128 或 32 desc_act: True, # 按敏感度排序处理列效果更好 damp_percent: 0.01, # 防止数值不稳定的阻尼参数 } model AutoGPTQForCausalLM.from_pretrained(model_name, quantize_configquantize_config) model.quantize(calibration_samples) model.save_quantized(your-org/your-model-gptq-4bit)这里校准样本的质量比数量重要。对 LLM 来说我建议从你真实业务场景的问题、指令、文档里采样数量在 100500 条就足够。覆盖范围要广但不能偏离模型的主要使用场景。desc_act 这个参数默认打开时精度更好但它会把权重列重排可能导致某些框架里性能略降如果实测速度有瓶颈可以关掉试一下。6.3 用 vLLM 部署量化模型量化完成后部署到 vLLM 就很简单from vllm import LLM, SamplingParams llm LLM( modelyour-org/your-model-gptq-4bit, quantizationgptq, max_model_len4096, gpu_memory_utilization0.9, ) output llm.generate([请用一句话解释量化], SamplingParams(max_tokens200)) print(output[0].outputs[0].text)启动时显存不足就调低gpu_memory_utilization并发上不去就调低max_num_seqs。这些参数没有绝对标准要根据你的显存、请求长度和吞吐要求实测调整。如果用的是 AWQ就把quantization参数换成awq如果用的是 FP8有些新框架会直接用fp8选项。关键是确保模型权重本身已经按对应格式做好不然参数填什么都是白搭。6.4 精度与性能对比实测量化完不能只“看着能跑”就收工必须对比量化前后在真实任务上的输出质量。我常用三种方式评价用固定 prompt 生成结果人工对比流畅度和语义一致性。用公开 benchmark比如 MMLU、GSM8K 之类跑一下精度分数。用业务自建的问题集统计准确率或满意度。性能上记录四个指标首 token 延迟、每 token 生成耗时、端到端吞吐tokens/s、显存峰值占用。下面是一组典型对比版本显存占用吞吐tokens/s端到端延迟200 tokensFP16约 14GB355.9sINT8 权重约 9GB504.1s4bit 权重约 7GB603.5s这不是一个绝对数字随硬件和实现差异会波动但趋势非常明确显存占用下降是因为权重体积变小吞吐提升是因为显存带宽压力降低延迟下降则是计算部分也受益。如果你发现“量化后速度反而变慢”大概率是框架没有跑上整数算子或者量化格式在该设备上没有加速支持。6.5 关于 FP8、FP16、INT8 和算力需求的一个现实观察最近很多人问 FP8 和 INT8 哪个快。这个话题没有一个简单的答案取决于硬件代数。举现实例子Hopper 架构的 GPU 提供了 FP8 支持但整数计算路径依然很强Blackwell 架构则引入了 NVFP4 这类低精度格式针对特定场景有巨大吞吐提升。实话实说部署优化这件事不能只看纸面算力要看推理框架是不是真的把算子接上了。我的建议是先跑 FP16 拿到基线再试 INT8最后根据硬件和任务需求测试 FP8。如果一个方向精度和速度都满意就没有必要升级到更别扭的低比特。量化的目标是“够用且最优”不是“越低越好”。7. 常见问题与排查技巧实录这一章全部来自实际经验我不列空泛理论都是真真实实会让你卡住的问题。7.1 量化后精度下降严重这是高频问题原因通常出在三处校准集和数据分布不匹配。检查校准集来源是否覆盖部署场景是否包含异常样本。量化范围选得不对。换成 percentile 或 KL 散度试试不同百分位。某些层对量化特别敏感。可以先做逐层敏感性分析定位掉点最严重的层把这层留在 FP16其他层用 INT8这叫混合精度量化。混合精度量化是排查阶段的强力手段。先把所有层都量化然后逐层替换回 FP16看精度恢复多少用最少的层恢复最大精度生产环境就能在“速度”和“精度”之间找到最佳平衡点。7.2 量化后速度不升反降主要原因有小模型或小 batch 下量化的算子调度开销盖过了计算收益。模型很小的时候瓶颈在 Python 调度、数据搬移而不是矩阵乘。目标硬件没有 INT8 Tensor Core或驱动、库版本太老。检查nvidia-smi、CUDA 版本、TensorRT 版本是否匹配。框架没有真正执行 INT8 kernel只是做了假的权重量化计算还是 FP16。查看 profiling 工具确认算子名字里带 INT8。7.3 量化支持的算子报错量化不是所有算子都支持。LayerNorm、Softmax、GeLU 这些通常在 FP16 下跑量化只覆盖线性层、卷积层这种矩阵乘密集的算子。遇到不支持的算子时检查计算图看哪里插入了 unsupported 的量化节点。用混合精度方案把不支持的算子留在高精度。换推理框架有些框架对某类算子的支持更完善。7.4 校准过程内存爆掉校准时要跑前向并缓存激活分布如果模型大、层多、校准数据多内存会吃紧。解决办法有缩小校准集规模比如从 1000 条降到 200 条。逐层校准把激活分布存到磁盘再聚合。用分块方式算子模块独立校准不要一次把整图跑完。7.5 量化模型的“幻觉”和指令遵循变差LLM 量化后确实可能出现格式混乱、回答变短或跑题。出现这种情况优先检查校准集是不是太单一了加一些带复杂指令的样本比如 JSON 输出、长文本摘要、多轮对话。如果校准集没问题可以考虑对关键层做 QAT 微调把格式稳定性拉回来。最后分享一个小技巧在写这篇文章的时候我脑子里一直回放着最初做量化的那段痛苦经历花了一个星期调校准集结果发现掉点原因是校准数据里混了一批和线上分布完全不同的旧样本。那之后我养成了一个习惯每次新建量化任务第一件事就是做数据分布分析把校准样本的 embedding 和线上真实请求的 embedding 画到一起看分布重叠度。分布对齐了量化就成了一大半。量化这个领域我个人的看法是它不是一个“调个参数就完事”的操作而是一条从数据、到模型、到硬件再到业务的完整链路。每个环节做到位量化就是性价比极高的一招任何一个环节偷懒后面的坑都得加倍还回去。如果你后面要玩更深入的东西可以从“逐层敏感性分析”和“混合精度自动化搜索”这两个方向扩展它们比漫无目的地调参效率高得多。希望这篇分享能让你的量化之路少踩几个我踩过的坑有任何问题也欢迎在评论区一起讨论。 模型量化完整指南：INT8、校准、QAT与LLM部署实操
如果你最近在折腾大模型部署或者只是把 ResNet、BERT 之类的东西塞进生产环境大概率绕不开“量化”这个词。量化Quantization简单说就是把模型里 FP32、FP16 的参数和中间计算折算成 INT8 甚至更低精度的整数去跑换来的就是更低的显存占用、更快的推理速度和更低的功耗。这篇文章我会结合自己在实际项目里踩过的坑把 INT8 矩阵乘、校准、QAT 以及 LLM 量化这几个环节串起来讲尽量做到既有原理、能听懂又有可以直接抄走的实操步骤。这篇文章适合谁不管你是刚接触部署优化的新手还是已经在用 TensorRT、vLLM 但总被精度问题折磨的工程师都值得往下看。我会先用“算力账本”说清楚为什么要做量化再逐层拆开 INT8 矩阵乘的底层逻辑然后讲校准和 QAT 这两条主流路线最后专门聊一下大语言模型量化和传统 CNN 量化到底哪里不一样并给出一套完整的落地步骤和问题排查表。1. 为什么要做量化这是一笔算力账本很多人一听到量化第一反应是“用来省显存”。这话没错但只说对了一半。真正遇到瓶颈的时候你会发现显存只是表面背后的计算吞吐、内存带宽、功耗才是影响部署成本的关键量化恰好能把这三笔账同时算下来。1.1 从 FP32 到 INT8三种格式到底差在哪先过一遍基础。FP32 是 32 位浮点FP16 是 16 位浮点INT8 是 8 位整数。直观上看一个 FP32 的权重参数占 4 字节FP16 是 2 字节INT8 是 1 字节所以权重从 FP32 换成 INT8理论上模型体积直接缩到四分之一显存占用也近似跟着缩。对显存经常卡在边界上的部署场景这一步就能省出非常大的空间。更关键的是计算吞吐。GPU 里的 Tensor Core 对 INT8 的支持通常都是 FP16 的两倍甚至更多对 FP32 就更高倍率了。比如 NVIDIA 安培架构之后INT8 的矩阵乘吞吐基本能到 FP16 的两倍FP16 又能到 FP32 的两倍左右。换到支持 FP8 的 Hopper 和 Blackwell 架构情况会复杂一些但整数计算依然是省力不省功的路线。这也是为什么很多推理框架宁愿牺牲一点精度也要优先跑 INT8。还有一个经常被忽略的点是内存带宽。LLM 这类生成式模型在解码阶段是极其吃带宽的每个 token 都要把权重重新读一遍这个过程和算得快不快关系不大反而和“单位时间内能从显存搬到计算单元多少数据”强相关。权重从 16 位压到 8 位带宽压力直接减半解码速度自然跟着涨。1.2 量化的收益不只是“省显存”我做过一个相对极端的对比同一个 7B 参数量的开源模型FP16 版本在单张消费级显卡上大概需要 14GB 以上显存换成 INT8 版本之后就降到 7GB 左右同时解码的 token 生成速度提升明显。这里面的换算逻辑很简单显存占用变小意味着 batch size 可以开得更大带宽需求降低意味着每个请求的响应时间更短而能耗跟着降下来则是在线服务长期运营的一笔实打实的成本。要澄清的是量化的这些收益不是白拿的。精度会掉一点需要校准或者训练来补开发调试成本也会增加。绝大多数情况下收益远大于损失但前提是你要知道自己模型的精度底线在哪里。如果是一个误分类代价极高的医疗影像模型也许 INT8 就需要慎用或者必须配合 QAT 来保住指标如果是一个聊天机器人或者内容摘要系统INT8 乃至更低比特量化带来的收益往往非常可观。打个生活化的比方。你有一个书架放满了精装书FP32每本书都带大号字体和厚纸张。搬书架很累也很占地方。现在你把这些书全部改成小字号、薄纸张的简装版INT8内容还在清晰度略有下降但书柜容量翻了四倍搬运起来轻快得多。什么时候能接受简装版、什么时候必须保留精装版这就是量化部署决策的本质。2. INT8 矩阵乘的底层逻辑矩阵乘是神经网络的基本操作。量化能不能真正提速取决于底层的矩阵乘到底是怎么算的。这里我到算子层面讲清楚读完你自己也能判断什么场景适合 INT8。2.1 量化公式scale 和 zero-point先说核心公式。把一个浮点数 (r) 映射到整数 (q)通常用下面这个公式[ q round(\frac{r}{scale} zero_point) ]其中 scale 是一个正的浮点数zero_point 是整数偏移用于处理非对称分布。反量化则是[ r scale \times (q - zero_point) ]scale 和 zero_point 怎么来如果是 per-tensor 量化就拿整个张量的数值范围来算[ scale \frac{max_value - min_value}{255} ]zero_point 则是对应到浮点最小值被映射成哪个整数。如果我们做对称量化zero_point 固定为 0公式就简化为[ q round(\frac{r}{scale}) ]对称量化因为实现简单、不需要额外的加减偏移在很多推理引擎里是默认选项尤其是权重。非对称量化则更灵活在激活函数输出分布明显偏斜的时候更有效。你可能会觉得这些东西不就是几个数学公式吗有什么可讲的。但其实后面所有坑包括精度下降、算子不兼容、校准集选不好全都是这几个公式在不同场景下的连锁反应。理解公式就是理解所有问题的源头。2.2 对称量化 vs 非对称量化对称量化把浮点范围看成关于 0 对称的即 ([-max_abs, max_abs]) 映射到 ([-128, 127])。优点是乘法运算时不用处理 zero_point 带来的整数加减INT8 矩阵乘的实现会简单很多缺点是如果数据分布明显偏向一边比如激活值只在 [0, 6] 之间那对称量化会浪费一半的整数表示范围精度损失变大。非对称量化可以把 [0, 6] 映射到 [0, 255]把 256 个整数档位全部利用起来。代价是计算时需要多一步减去 zero_point 的操作在矩阵乘实现里会引入额外的整数运算效率略低。实际操作里我一般建议权重用对称量化激活值看分布情况选择。很多框架在 x86 上都支持得很完整TensorRT 的 INT8 默认也是对称式校准而某些移动端框架则更偏向非对称。选哪种不是拍脑袋决定的要用校准后的分布图来辅助判断。2.3 GEMM 里发生了什么一个标准的 INT8 矩阵乘输入是 INT8 的激活值和 INT8 的权重两者相乘要用 32 位整数累加器来累加。为什么不能用 INT8 做累加因为两个 INT8 相乘的结果最大是 (127 \times 127 16129)超过了 8 位能表达的范围所以硬件里都是把乘出来的结果累加在 INT32 里最后再一次性反量化为 FP32 输出给下一层。这个过程具体展开是输入激活 (A) 和权重 (W) 分别做量化得到 (A_{int8}) 和 (W_{int8})。在 INT32 精度下做矩阵乘累加得到 (Acc_{int32})。乘上 scale_factor ( scale_A \times scale_W)把 INT32 结果反量化回浮点。如果下一层还是 INT8就再量化一次如果输出需要给浮点算子就直接以 FP16/FP32 继续。所以你看到的推理框架日志里“quantize/dequantize 节点”其实就是为了在计算图上把这些 scale 转换串起来。现在 TensorRT、ONNX Runtime、openvino 等框架会自动插入这些节点但理解背后的流程排查问题时才不会一头雾水。2.4 一个直观的矩阵乘小算例为了把公式落到地上我们算一个极小的例子。假设某个矩阵的一行数值是 ([0.5, 2.0, 3.5])采用对称量化最大绝对值是 3.5scale 3.5 / 127 ≈ 0.02756。那么量化结果是0.5 → round(0.5 / 0.02756) ≈ 182.0 → round(2.0 / 0.02756) ≈ 733.5 → 127反算回去分别是 0.496、2.012、3.5精度损失在这个例子很小但如果你把 scale 换成某个对整体范围敏感的值比如数据里有个异常大的点 100其他点都分布在 1 附近那 1 量化后可能四舍五入变成 1 或 2损失就非常严重。这就是后面要讲校准方法存在的原因目的就是让 scale 既能覆盖动态范围又不浪费整数表示精度。3. 校准PTQ 的关键一步Post-Training QuantizationPTQ也就是训练后量化是最常见的量化方式。你不用重新训练模型只需要拿一批有代表性的数据跑一遍前向统计各层激活值和权重的数值分布然后算出合适的 scale 和 zero_point。这里最核心、最容易翻车的部分就是校准Calibration。3.1 校准集怎么选校准集不是验证集也不是测试集它是一小批用来“观察”模型中间层输出分布的数据。选得好不好直接决定量化后的模型精度。我踩过最典型的坑是拿 ImageNet 的验证集去校准一个用业务私有数据微调过的检测模型结果量化后 mAP 掉了 8 个点。后来换成了 500 张真实业务场景下的图片尤其是包含模型最容易出错的那类目标精度掉到了 1 个点以内。选校准集的核心原则是要和模型在真实部署时看到的数据分布一致。如果部署场景是医疗影像就别拿自然图片去校准如果是金融文本分类就别拿新闻语料。样本数量不需要多通常几百张到一千张就够了关键在于代表性。多样性能覆盖长尾情况但也不能为了多样性丢掉主要分布要平衡。还有一个常见误区把校准集当成训练集。校准过程不更新任何权重只是统计数据分布如果拿训练数据去校准会造成统计偏差让量化后的模型在训练集上表现好、在真实场景上表现差。那种“量化后准确率不降反升”的情况有时候就是因为校准数据本身泄漏了分布信息。3.2 校准方法MinMax、Percentile、KL 散度与 MSE选好数据之后要决定怎么从统计数据里算出量化范围。常用的方法有几种MinMax直接取整个张量的最小值和最大值作为量化范围实现最简单但容易受到异常点影响一个突发的大数值会让整体精度浪费。Percentile取分布里的某个百分位作为最大最小值比如 99.99%能剔除极端异常点。问题是百分位怎么选太低会截断有效范围太高又跟 MinMax 差不多。KL 散度让量化后的分布和原始浮点分布之间的 KL 散度最小。TensorRT 的经典默认方案就是基于这个思路它会尝试把浮点分布“裁剪”到不同边界然后选出 KL 散度最低的那个阈值。优点是自适应较好缺点是统计计算比较贵且依赖参考分布的质量。MSE用均方误差最小化来搜索最优截断阈值。这个思路更直接让量化前后的输出张量差异最小。实际效果通常不错但需要有足够多的校准样本才能稳定。没有绝对“最好”的方法。我在实际项目里的经验是对于大多数 CNN先用默认的 KL 或 MSE 就能拿到可用的结果如果精度出问题再回头调整校准集和百分位。对于 LLM 这种激活值有大量离群点的模型“一刀切”的校准方式经常不够用需要引入后面的 SmoothQuant、AWQ 这类方案这是第 5 章的内容。一个非常实用的排查技巧把校准集从 100 张加到 1000 张如果量化后精度没有明显变化那说明你的校准流程大概率是稳定的如果加了数据精度反而掉了那就要怀疑是不是校准集里混入了和部署场景差异较大的样本。3.3 Per-tensor、Per-channel 与 Per-group除了校准方法粒度也是决定精度的关键。per-tensor 就是整个张量共用一个 scale实现最简单但遇到权重不同通道数值范围差异较大时误差偏大。per-channel 就是对每个输出通道分别统计 scale精度提升明显某些硬件上会增加一点点开销但大多数框架都支持。per-group 更进一步对更小的块分别量化主要用于低比特场景比如 4bit 量化。一个直观的例子如果某一层权重 90% 的通道数值分布在 [-0.1, 0.1]剩下 10% 分布在 [-1.0, 1.0]per-tensor 量化会把 scale 拉大十倍前 90% 的通道全被压到几个整数档位上精度损失惨重。per-channel 量化后每个通道有自己的 scale就不会出现这种“为少数通道买单”的浪费。在 LLM 权重量化里现在最流行的做法是 per-group通常以 128 个元素为一组每个组独立计算 scale。这样做比 per-channel 更精细能在 4bit 下把模型质量保持得很好。代价是 scale 的数量变多显存和计算开销增加一点但综合收益显著。3.4 校准实操流程我这里给一个通用的校准流程适用于大多数 PyTorch 模型转 ONNX 再量化的场景准备一个有代表性的校准数据集通常 2001000 条样本存成 DataLoader。用浮点模型跑一遍前向同时把每层的激活值分布保存下来。如果框架支持自动校准这步就是调用 API。根据分布选择合适的校准算法算出每一层的 scale 和 zero_point。用验证集对比量化前后模型的精度和速度。如果精度低于预期按照“校准集 → 校准方法 → 量化粒度 → 层敏感度”这个顺序排查。我会在后面实操章节给出一个具体的代码风格示例但核心思路就是你得先让量化引擎“看见”你真实的数据分布否则什么高级配置都白搭。4. QAT量化感知训练PTQ 虽然省事但在某些模型上精度不够这时候要上 QATQuantization-Aware Training量化感知训练。QAT 的思路是在训练过程中模拟量化的误差让模型学会在整数精度下也能保持准确率。4.1 为什么 PTQ 有时不行PTQ 最怕两类情况一类是模型权重或激活值的分布特别“不配合”比如有大量离群点导致无论怎么选 scale 都会有很大误差另一类是模型本身对数值变化非常敏感比如某些小模型、注意力层多的模型、或者训练得过于紧凑的模型一点点误差就会被放大到结果层面。还有一个常被忽视的原因是BatchNorm 层在推理时会被折叠到卷积里但如果校准时的 BatchNorm 统计量和训练时不一致量化后误差会格外明显。PTQ 阶段模型没有机会“适应”这种变化而 QAT 可以通过训练把这些问题吸收掉。4.2 Fake Quant 与 STEQAT 的核心机制叫 Fake Quant翻译过来就是“伪量化”。在训练阶段前向传播时先用量化公式把数值转成 INT8 再转回浮点让模型尝到量化的“口感”但权重和梯度仍然以浮点形式保存和更新。这样反向传播里梯度可以使用浮点精度继续更新而不是被量化截断。这里有个关键难点量化过程中的 round 操作是不可导的梯度无法直接传回去。解决办法是用直通估计器STEStraight-Through Estimator把梯度绕过 round 操作直接传给前面的浮点权重。简单说就是前向走量化通道反向假装没有量化这回事。QAT 的过程可以理解成一个“带着沙袋训练”的过程。平时跑步不穿负重比赛才脱下成绩可能发挥不好训练时就穿沙袋比赛时换上轻装反而能跑出更好成绩。QAT 里的“沙袋”就是量化误差模型在训练阶段就不断适应这种误差最后转换到真正的 INT8 推理时自然比 PTQ 更稳。4.3 QAT 的训练细节与注意事项建议在预训练模型基础上做 QAT而不是从头训练。训练 epoch 可以很短比如 10%20% 的完整训练进度就够了训练太久反而可能过拟合到校准集或者造成精度震荡。学习率要比正常训练小很多通常用原始最大学习率的百分之一甚至更低。先冻结部分层比如先量化敏感度低的卷积层再逐步加入敏感层可以降低训练难度。用余弦退火学习率策略让模型在量化噪声下稳定收敛。训练时要保证有足够多的数据否则 QAT 效果会很差。数据量太小模型会把量化误差“背下来”真实场景一换数据就原形毕露。QAT 的代价显然比 PTQ 高需要训练资源、需要设计训练 pipeline、需要额外调试时间。因此我通常只在 PTQ 精度不达标时才上 QAT或者目标设备很特殊比如只有 INT8 加速、不接受 FP16以及模型精度要求极其严格时使用。4.4 什么时候值得用 QAT我总结一个决策逻辑模型对精度极其敏感PTQ 掉点超过你无法接受的范围。部署硬件只有 INT8 / 更低整数计算能力且没有 FP16 备用方案。你做的模型会在大量不同输入上被反复调用精度下降会被用户明显感知。你有充足的数据和算力团队能接受训练周期的延长。最近大模型领域针对少数关键层做“QAT 式微调”的做法也越来越常见核心思想其实一样让这些层在量化后依然保持鲁棒。它不一定叫 QAT但本质都是让模型“适配”量化误差。5. LLM 量化和传统 CNN 不太一样大语言模型量化在最近两年变成了一个非常火的主题因为它直接关系到我们能不能在有限算力下跑起更大的模型。LLM 量化有不少独特的难点和传统 CNN 的量化逻辑不完全一样。5.1 LLM 量化的难点激活值里的“异常点”LLM 的激活分布在特定通道上会出现非常离谱的大数值这些“离群通道”虽然数量少但数值幅度可能是其他通道的几十倍甚至上百倍。如果按 MinMax 或普通 KL 校准量化范围会被这些离群值占满其他通道被挤压到几乎没有区分度精度哗哗往下掉。这跟传统 CNN 完全不一样。CNN 激活值分布相对“老实”少量异常点不会造成那么大影响但 LLM 的隐藏层维度极大注意力头之间的数值尺度差异极大异常点的存在感特别强必须用专门手段处理。5.2 权重量化 vs 激活量化 vs KV Cache 量化理解 LLM 量化之前要区分几个量化对象权重量化只把模型权重转成 INT8 或更低精度激活仍然是 FP16。这种方案最简单不需要校准数据但收益有限因为解码阶段最占资源的权重读取带宽确实降了速度提升明显而计算部分没有充分利用 INT8 矩阵乘。动态量化运行时动态把激活量化到 INT8权重可以预先量化。这个方案能加速计算部分但需要在推理引擎里实现良好的融合算子复杂度更高。KV Cache 量化自回归生成阶段要缓存历史 token 的 key 和 value缓存越大内存带宽压力越大。把 KV Cache 压到 INT8 甚至 4bit能明显提升长文本场景下的吞吐。最近业界的部署趋势是能同时量化权重、激活和 KV Cache 的方案比如 GPTQ 做权重 4bitSmoothQuant 处理激活值再配合 KV Cache INT8 量化组件效果最好。5.3 GPTQ、AWQ 与 SmoothQuant 的基本思路GPTQ一种基于二阶梯度信息的训练后权重量化方法目标是让量化后的权重矩阵尽可能接近原矩阵的输出结果。它按列逐层量化利用 Hessian 信息补偿量化误差是目前权重 4bit 量化的经典方案。实际用起来就是拿一个校准集把每层权重“自适应”地压到 34bit效果在开源模型上普遍不错。AWQActivation-aware Weight Quantization从激活值的角度感知哪些权重通道更重要然后对重要通道做更精细的量化或者用缩放技巧降低重要通道的误差。思路很直观权重的重要性不是由权重本身决定的而是由它对应的激活大小决定的。把重要通道保护好整体精度就稳。SmoothQuant针对激活离群值问题巧妙的把激活值的波动“转移”到权重上。做法是在线层之间调节 scale让激活分布变得更平滑权重分布虽然变“参差”但可以通过 per-channel 权重量化来吸收。好处是激活可以真正量化到 INT8计算部分能跑起实数矩阵乘。这三者不是互斥的实际工程里经常搭配使用。举个常见的组合AWQ 做权重量化 SmoothQuant 做激活量化 KV Cache 用 INT8基本都是流水线配合。对于 GPTQ 和 AWQ 这类用校准集的方法校准集质量依然是生命线和前面讲 PTQ 时的原则一样。另一个要提到的方案是 GGUF/GGML 体系的量化格式q4_0、q8_0 等它在 llama.cpp 生态里非常流行本质上是针对 CPU 推理优化的一套量化方案。很多下载站会直接标明“q8_0 量化版”模型这类模型在“系统提示”里常出现说明量化在开源社区里已经是默认的基础能力了。它和硬件厂商的主导方案思路不同但底层原理都是围绕 scale、zero_point、group size 这些概念。5.4 部署集成vLLM、TensorRT-LLM 与 transformers到了工程落地层面你需要选推理框架。vLLM 对 GPTQ、AWQ、FP8 这些量化格式支持得比较完备你可以在启动时直接指定量化方式和参数比如--quantization awq。TensorRT-LLM 对 INT8 权重和激活的融合更彻底是做极致性能时绕不开的选择。transformers 自带bitsandbytes支持适合快速验证和低资源推理。我在实操中积累的体会是先用简单的框架验证量化的精度和收益确认值得之后再上重框架做极致优化。不要一上来就是 TensorRT-LLM 加各种自定义 kernel调试成本会非常高。你想要的只是一个能稳定跑起来、精度可接受、速度有明显提升的版本框架的复杂度由业务需要和硬件形态决定。6. 实操现场把一个开源 7B 模型量化到 INT8这一章我会带你走一个完整的实操以时下常见的开源 7B 模型为例展示从“拿到 FP16 权重”到“部署 INT8 版本”并验证效果的过程。不同模型、不同框架的细节有差异但整体思路完全通用。6.1 环境准备与模型下载你需要准备一台有 NVIDIA GPU 的机器显存建议至少 8GB。软件方面Python 3.10PyTorch 2.xTransformersvLLM 或 AutoGPTQ 这类推理库。如果使用国内网络可以设置 Hugging Face 镜像站的环境变量来加速模型下载比如把HF_ENDPOINT指向国内镜像或者直接从 ModelScope 平台下载开源模型。这一步不是因为模型特殊而是社区模型下载的基本操作。注意一点下载量化版模型时一定要看清量化格式。同样是 4bitGPTQ 的格式和 AWQ 的格式不通用GGUF 格式在 vLLM 里也需要特定支持。爆一个典型的坑我遇到过直接下载 q8_0 格式的 GGUF 想放到 TensorRT-LLM 里用结果完全不识别只能重新走一遍量化流程。6.2 用 GPTQ 做权重量化假设你想把一个 FP16 的 7B 模型量化为 GPTQ 4bit 或 8bit可以用 AutoGPTQ 这样的大致流程from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM model_name your-org/your-model-fp16 tokenizer AutoTokenizer.from_pretrained(model_name) calibration_samples [ 深度学习的模型部署需要注意量化关键技术, 量化就是把浮点数映射到整数区间尽量保持精度, # 准备 20200 条有代表性的文本越长越好 ] quantize_config { bits: 4, # 4bit 或 8bit group_size: 128, # 常用 128 或 32 desc_act: True, # 按敏感度排序处理列效果更好 damp_percent: 0.01, # 防止数值不稳定的阻尼参数 } model AutoGPTQForCausalLM.from_pretrained(model_name, quantize_configquantize_config) model.quantize(calibration_samples) model.save_quantized(your-org/your-model-gptq-4bit)这里校准样本的质量比数量重要。对 LLM 来说我建议从你真实业务场景的问题、指令、文档里采样数量在 100500 条就足够。覆盖范围要广但不能偏离模型的主要使用场景。desc_act 这个参数默认打开时精度更好但它会把权重列重排可能导致某些框架里性能略降如果实测速度有瓶颈可以关掉试一下。6.3 用 vLLM 部署量化模型量化完成后部署到 vLLM 就很简单from vllm import LLM, SamplingParams llm LLM( modelyour-org/your-model-gptq-4bit, quantizationgptq, max_model_len4096, gpu_memory_utilization0.9, ) output llm.generate([请用一句话解释量化], SamplingParams(max_tokens200)) print(output[0].outputs[0].text)启动时显存不足就调低gpu_memory_utilization并发上不去就调低max_num_seqs。这些参数没有绝对标准要根据你的显存、请求长度和吞吐要求实测调整。如果用的是 AWQ就把quantization参数换成awq如果用的是 FP8有些新框架会直接用fp8选项。关键是确保模型权重本身已经按对应格式做好不然参数填什么都是白搭。6.4 精度与性能对比实测量化完不能只“看着能跑”就收工必须对比量化前后在真实任务上的输出质量。我常用三种方式评价用固定 prompt 生成结果人工对比流畅度和语义一致性。用公开 benchmark比如 MMLU、GSM8K 之类跑一下精度分数。用业务自建的问题集统计准确率或满意度。性能上记录四个指标首 token 延迟、每 token 生成耗时、端到端吞吐tokens/s、显存峰值占用。下面是一组典型对比版本显存占用吞吐tokens/s端到端延迟200 tokensFP16约 14GB355.9sINT8 权重约 9GB504.1s4bit 权重约 7GB603.5s这不是一个绝对数字随硬件和实现差异会波动但趋势非常明确显存占用下降是因为权重体积变小吞吐提升是因为显存带宽压力降低延迟下降则是计算部分也受益。如果你发现“量化后速度反而变慢”大概率是框架没有跑上整数算子或者量化格式在该设备上没有加速支持。6.5 关于 FP8、FP16、INT8 和算力需求的一个现实观察最近很多人问 FP8 和 INT8 哪个快。这个话题没有一个简单的答案取决于硬件代数。举现实例子Hopper 架构的 GPU 提供了 FP8 支持但整数计算路径依然很强Blackwell 架构则引入了 NVFP4 这类低精度格式针对特定场景有巨大吞吐提升。实话实说部署优化这件事不能只看纸面算力要看推理框架是不是真的把算子接上了。我的建议是先跑 FP16 拿到基线再试 INT8最后根据硬件和任务需求测试 FP8。如果一个方向精度和速度都满意就没有必要升级到更别扭的低比特。量化的目标是“够用且最优”不是“越低越好”。7. 常见问题与排查技巧实录这一章全部来自实际经验我不列空泛理论都是真真实实会让你卡住的问题。7.1 量化后精度下降严重这是高频问题原因通常出在三处校准集和数据分布不匹配。检查校准集来源是否覆盖部署场景是否包含异常样本。量化范围选得不对。换成 percentile 或 KL 散度试试不同百分位。某些层对量化特别敏感。可以先做逐层敏感性分析定位掉点最严重的层把这层留在 FP16其他层用 INT8这叫混合精度量化。混合精度量化是排查阶段的强力手段。先把所有层都量化然后逐层替换回 FP16看精度恢复多少用最少的层恢复最大精度生产环境就能在“速度”和“精度”之间找到最佳平衡点。7.2 量化后速度不升反降主要原因有小模型或小 batch 下量化的算子调度开销盖过了计算收益。模型很小的时候瓶颈在 Python 调度、数据搬移而不是矩阵乘。目标硬件没有 INT8 Tensor Core或驱动、库版本太老。检查nvidia-smi、CUDA 版本、TensorRT 版本是否匹配。框架没有真正执行 INT8 kernel只是做了假的权重量化计算还是 FP16。查看 profiling 工具确认算子名字里带 INT8。7.3 量化支持的算子报错量化不是所有算子都支持。LayerNorm、Softmax、GeLU 这些通常在 FP16 下跑量化只覆盖线性层、卷积层这种矩阵乘密集的算子。遇到不支持的算子时检查计算图看哪里插入了 unsupported 的量化节点。用混合精度方案把不支持的算子留在高精度。换推理框架有些框架对某类算子的支持更完善。7.4 校准过程内存爆掉校准时要跑前向并缓存激活分布如果模型大、层多、校准数据多内存会吃紧。解决办法有缩小校准集规模比如从 1000 条降到 200 条。逐层校准把激活分布存到磁盘再聚合。用分块方式算子模块独立校准不要一次把整图跑完。7.5 量化模型的“幻觉”和指令遵循变差LLM 量化后确实可能出现格式混乱、回答变短或跑题。出现这种情况优先检查校准集是不是太单一了加一些带复杂指令的样本比如 JSON 输出、长文本摘要、多轮对话。如果校准集没问题可以考虑对关键层做 QAT 微调把格式稳定性拉回来。最后分享一个小技巧在写这篇文章的时候我脑子里一直回放着最初做量化的那段痛苦经历花了一个星期调校准集结果发现掉点原因是校准数据里混了一批和线上分布完全不同的旧样本。那之后我养成了一个习惯每次新建量化任务第一件事就是做数据分布分析把校准样本的 embedding 和线上真实请求的 embedding 画到一起看分布重叠度。分布对齐了量化就成了一大半。量化这个领域我个人的看法是它不是一个“调个参数就完事”的操作而是一条从数据、到模型、到硬件再到业务的完整链路。每个环节做到位量化就是性价比极高的一招任何一个环节偷懒后面的坑都得加倍还回去。如果你后面要玩更深入的东西可以从“逐层敏感性分析”和“混合精度自动化搜索”这两个方向扩展它们比漫无目的地调参效率高得多。希望这篇分享能让你的量化之路少踩几个我踩过的坑有任何问题也欢迎在评论区一起讨论。