做推理和部署优化这些年量化是我绕不开的话题。尤其是到了大模型阶段大家都想要8位整数计算带来的那点吞吐红利——模型显存减半MatMul直接走Tensor Core看着就很香。但真上手才会发现W8A8这四个字写起来容易跑起来全是坑。前阵子我在某个70B级别的开源模型上试水权重按通道量化、激活按token量化常规流程老老实实走一遍困惑度直接掉了一两个点。一开始还以为是校准数据量不够加了两千条还是老样子。后来换了几种方案折腾才意识到问题根本不是工程细节而是激活值本身没法量化。SmoothQuant解决的就是这个僵局。它没有靠更高阶的量化算法硬扛而是用一个数学上完全等价的变换把量化难度从激活值搬家到权重上。这个思路出来之后W8A8在大模型上的精度才算真正站住了。这篇文章我不打算复述论文重点讲三件事SmoothQuant到底在做什么、怎么做才能在自己模型上复现出效果、以及单节点塞下超大模型时那些实打实的部署账。1. W8A8量化到底难在哪从分布不均说起1.1 量化基础回顾精度、粒度与硬件支持先对齐一下概念。我们说的W8A8是指权重Weight和激活值Activation都量化为8位整数。8位量化意味着每个数只有256个离散档位浮点数的连续取值要被映射到这些档位上。映射做得好不好直接决定模型精度损失多少。量化粒度是第一个关键选择。最粗糙的是per-tensor整层权重共用一个scale实现最简单但精度最差。好一点的是per-channel每个输出通道单独一个scale这几乎是权重量化的标配。到了激活值情况就复杂了——激活是一个形状为[batch, seq_len, hidden_dim]的大矩阵我们既可以对整个矩阵用一个scaleper-tensor也可以对每个token单独用一个scaleper-token还有per-channel按特征通道统计的方案。硬件层面的现实是主流GPU的INT8 Tensor Core原生支持W8A8矩阵乘但对per-channel和per-token这种细粒度scale的支持程度不同。A100之后的架构在INT8算力上非常可观前提是你的GEMM kernel能把各种scale处理好。所以从工程角度讲W8A8是性价比最高的目标格式——INT4精度通常撑不住FP8又受限于部分硬件的支持成熟度只有W8A8能稳定吃到Tensor Core的加速且不牺牲太多精度。1.2 大模型激活值里藏着系统性离群点真正让大模型W8A8翻车的不是权重是激活值。很多人第一次做LLM量化时会拿小模型的经验套结果发现完全不是一回事。我在一个70B模型上做激活值分布分析时画出来的直方图让人头皮发麻绝大多数激活值集中在很小的数值范围内但少数几个通道上的绝对值能比中位数大几十倍甚至上百倍。这些离群点不是偶然噪声而是系统性的——它们固定在特定的特征通道上几乎每个token都会在这些通道产生很大的值。论文里的说法是约1%的通道承载了很大比例的量级。这跟CNN的激活分布完全不同CNN的激活值相对均匀per-tensor或per-token量化就能应付。但 transformer 架构里某些通道对应的特征本身就具有大动态范围比如部分attention score前的线性投影就会持续产出大数值。为什么这些离群点是致命的做对称量化时scale由最大绝对值决定。只要一个通道有一个极端大值整个per-tensor的scale就被拉大其他99%的通道被挤到极低的量化分辨率上精度自然崩盘。per-token会好一点因为它把每个token单独归一化了但这只能解决token间的动态范围差异解决不了通道间的差异——每个token里那些离群通道依然存在。1.3 之前那些方案为什么卡在原地在大模型量化这个方向上之前比较有代表性的方案是混合精度保留离群值思路是检测出离群通道让它们留在FP16里计算其余走INT8。这个方法在小规模上有效但有几个硬伤检测离群通道本身有额外开销混合精度导致矩阵乘无法完整走INT8 Tensor Core一部分计算回退到FP16加速比打折更麻烦的是检测逻辑在批量推理时会干扰kernel流水线工程集成很难做漂亮。另一个方向是直接放弃8位退到4位。INT4权重确实把模型压得更小但激活值仍然是16位甚至32位GEMM的输入精度不一致Tensor Core支持W4A8或W4A16的矩阵乘效率远不如W8A8。而且从实测看超大模型在INT4下的精度损失通常比INT8高一个台阶不是所有业务都能接受。所以这个僵局的本质是激活值的离群通道让8位量化在数学上很难成立而所有绕开它的方案都要牺牲计算效率或精度。SmoothQuant的聪明之处在于它不去想办法处理离群点而是直接把产生离群点的负担转移到权重侧——既然数学上完全等价为什么不选一个更好量化的路径来走2. SmoothQuant的破局点一次数学上完全等价的搬家2.1 一个不起眼的恒等式SmoothQuant的核心操作说穿了就是一个初中生都看得懂的恒等式对任意激活矩阵X和权重矩阵W它们的矩阵乘可以写成 X·W (X·s)·(W/s)其中s是一个逐通道的正数向量。这里的关键词是等效——这不是近似不是用某种技巧逼近原始结果而是数学上的恒等变换。只要s选择得当X·s和W/s在量化后的精度损失可以和原始X、W直接量化时的损失完全不同。第一次看到这个变换时我的第一反应是就这矩阵乘两边乘同一个对角阵的逆这不是线性代数里最基础的操作吗。但细想就明白了这个变换的意义在于它给了我们一个自由度我们可以自由地在激活值和权重之间分配量化难度。原本激活值一方独扛所有的离群压力现在可以把一部分压力借给权重来承担。权重为什么有空间承担因为权重的分布相对均匀逐通道的scale能很好地适配。而且权重是静态的我们可以花很多时间做精细的预处理它不需要像激活值那样在推理时实时计算scale。换句话说激活值量化是在线难题权重量化是离线难题SmoothQuant做的就是尽量把难点从在线挪到离线。2.2 把量化负担从激活搬到权重具体怎么搬关键在于s的构造方式。如果单纯给所有通道一个固定值变换没有意义。SmoothQuant的s是按输入通道分别设置的构造原则是激活值里那些又大又集中的离群通道分配给它们较大的s让X·s把这些通道的数值压扁对应的W/s里这些通道的数值会被拉大量化难度转移到权重上。用一句话概括哪里难量化就给哪里乘以一个合适的系数把它压下去同时用一个具有互补效应的除法作用在另一个因子上。最终效果是激活值变得平滑了权重虽然变粗糙了一点但权重的量化基准本身就更宽容两边的误差重新达到平衡。实际操作中s的取值通常基于激活通道最大值和权重通道最大值的统计来算。经典的构造方式是取两者的幂平均比例——对第j个通道统计校准集上激活值的最大绝对值记为m_X_j统计权重矩阵第j个输入通道的最大绝对值记为m_W_j然后令s_j (m_X_j)^α / (m_W_j)^(1-α)这里的α在0到1之间。α0时s全为1等于什么都没做回到原始的W8A8α1时激活的离群值被最大程度压平但权重会变得极其不均匀权重量化本身开始变难。SmoothQuant最妙的地方在于这个调节旋钮是连续的我们可以找到一个中间点让激活和权重都落在各自舒适的量化区间内。2.3 alpha参数的直觉与选法论文里推荐α取0.5这个数字不是拍脑袋定的。我自己的理解是0.5相当于在激活量化和权重量化之间做均等的风险分配——两边各扛一半压力。在绝大多数开源大模型上这个默认值表现都很好是一个闭着眼睛用也不会太差的起点。但绝不建议直接把0.5当万能钥匙。我在实际项目里遇到过一些模型某些层的激活离群程度特别剧烈0.5压不住需要把α调到0.6甚至0.7。也有个别模型权重本身的分布比一般模型更敏感α稍微调大一点权重量化误差就明显上升这种情况下反而要往0.4方向退。实操中的调法是对每层单独做网格搜索在校准集上选一小段数据把α在0.2到0.8之间按0.05的步长遍历评估量化后模型输出的困惑度或下游任务指标找到每层的最佳值。需要注意的是评估指标要选对——困惑度对整体分布敏感但某些业务更关心特定任务的精度最好两个都看。逐层搜索的收敛速度很快因为每层的评估是独立的可以并行跑几分钟就能出结果。3. 手把手实操把SmoothQuant接到现有推理流程3.1 校准集合与统计量的选择SmoothQuant的scale构造离不开激活值的统计这就要选校准集。我见过不少人在这一步翻车最典型的错误是随手拿几百条新闻文本就去统计。校准集的领域和上线场景差太多统计出来的最大值分布就不准推理时一遇到真实流量里的长尾输入直接截断报错或精度骤降。我的建议是校准集至少覆盖三类来源一是训练数据里随机抽样的部分二是上线场景的典型输入采样三是加入一些合成的高难度样本比如超长文本、密集数字、代码片段用来模拟极端分布。数据量不用贪多几百到一两千条就够重点是把分布的上下界摸准。统计量本身也要讲究。直接取最大值(max)对离群点特别敏感如果校准集里混入一两条极端样本整个通道的scale都会被带偏。更稳的做法是用高分位数比如99.99%分位数或者对最大值做截断处理只统计校准集上多次forward中最稳定的那些通道值。3.2 scale计算与权重的平滑处理拿到激活统计和权重统计之后具体流程是这样的。用PyTorch伪代码可以写得很清楚# 假设拿到了校准集上的激活输出 activations: [num_samples, seq_len, hidden_dim] # 权重矩阵: weight: [in_features, out_features] # 1. 按输入通道统计激活的最大绝对值 act_max activations.abs().amax(dim(0, 1)) # [hidden_dim] # 2. 按权重的输入通道统计最大绝对值 weight_abs_max weight.abs().amax(dim1) # [in_features] weight_abs_max torch.clamp(weight_abs_max, min1e-8) # 3. 计算平滑因子 alpha 0.5 scale (act_max ** alpha) / (weight_abs_max ** (1 - alpha)) scale torch.clamp(scale, min1e-4) # 4. 平滑权重每行除以对应scale smoothed_weight weight / scale.unsqueeze(1) # 5. 保存精度的同时也要保存scale后续GEMM要用这里有三个细节要注意。第一scale是针对权重矩阵的输入通道维度也就是hidden_dim方向不是输出通道。第二平滑后的权重不要直接存成INT8——先以FP16/BF16保存平滑后的权重推理时再对平滑权重做常规的per-channel量化这样才能确保权重量化误差和激活量化误差是分别叠加的而不是一步到位把误差搞混。第三对embedding层和最后的lm_head层通常不做平滑这两层不参与GEMM的量化收益保持原样反而省事。3.3 融合到LayerNorm的落地技巧这是SmoothQuant在工程上非常值钱的一个技巧。直接按公式实现的话每层矩阵乘前都要对激活矩阵做一次逐元素乘法乘以s这多了一次访存和一次kernel调用对推理延迟不友好。但SmoothQuant的构造允许我们把这次乘法藏进前一层的LayerNorm或RMSNorm里。原理很简单LayerNorm的输出是逐通道仿射变换y gamma * x_norm beta。如果我们要让这一层的输出乘以s只需要把gamma换成gamma * s把beta换成beta * s。这样一来前向计算走完LayerNorm后激活值天然就是平滑过的GEMM前的逐元素乘法就整个消失了。RMSNorm更简单没有beta项只改gamma就行。我在实际项目里强烈建议做这个融合尤其是吃显存带宽的decode阶段少一次全量逐元素乘对整个token吞吐都有可感知的提升。融合实现不复杂就是在导出模型时把scale乘进LayerNorm的gamma和beta后面量化逻辑完全不用感知scale的存在。3.4 W8A8 GEMM的运行时实现要点平滑做完之后推理时的矩阵乘里其实有两套scale在起作用一套是权重per-channel量化带来的反量化scale另一套是激活per-token量化带来的反量化scale。INT8 GEMM计算完得到的是INT32累加结果需要乘上这两套scale的外积才能回到精度正确的FP16/BF16数值。这部分的实现细节直接决定性能。粗暴的做法是把INT32结果写回显存再单独做一次FP16矩阵乘来scale那等于把INT8省下的时间又还回去了。正确的做法是在GEMM的epilogue阶段直接融合scale校正——用CUTLASS可以自定义epilogue或者在集成到推理引擎时确保kernel支持per-channel和per-token两种scale的融合。主流推理框架对这块的支持已经比较成熟比如FasterTransformer和TensorRT-LLM都内置了SmoothQuant的集成方案。我的建议是能不用自己写kernel就别自己写先用现成实现跑通效果确认精度和性能都达标之后再考虑要不要为特殊场景定制。自己造轮子在这个领域成本极高因为INT8 GEMM的优化涉及寄存器调度、shared memory布局和Tensor Core指令对齐没有几个月的迭代很难追上成熟方案。4. 单节点扛起530B工业部署的账本与收益4.1 显存账怎么算标题里说的单节点承载530B巨无霸不是营销话术是W8A8最实打实的收益。530B参数在FP16下需要约1.06TB显存8张A100 80GB的整节点也只有640GB物理上就装不下。而INT8量化后权重只要530GB8张80GB卡合计640GB扣除权重后还剩约110GB给KV cache、激活值、临时buffer和计算碎片——单节点单机塞下530B从算显存账的角度看是成立的。具体到部署这笔账还要算细一点。权重虽然只有530GB但多卡切分时要注意每个GPU能拿到的权重分片是均匀的避免出现某张卡显存吃满、其他卡闲着的情况。110GB留给KV cache和运行时开销batch size和序列长度都要做限制但至少给了项目一个单机可跑的机会。要是换成INT4权重能压到265GB显存更宽裕但前面说过INT4带来的精度风险和kernel支持成本在超大规模场景下会让很多团队望而却步。4.2 KV cache量化长序列场景的第二块大蛋糕权重只是显存支出的一半另一半大头是KV cache。以常见的65B级别开源模型为例80层结构batch开到16、序列长度2048时FP16的KV cache总量可以到80GB左右——在单卡上这已经是一个巨大包袱。而KV cache的量化和权重量化一样吃的是SmoothQuant同样的红利。KV cache里的K和V本身就是激活值同样存在离群通道问题。SmoothQuant论文里对KV cache的处理是按通道维度统计scale并量化到INT8推理时动态写入和读取都走INT8需要的计算量几乎不增加。KV cache面积直接减半意味着同样的显存预算下batch可以翻倍或者序列长度可以拉长一倍。对长文本场景比如万字级别的文档分析这个收益比权重本身减半还要明显。不过KV cache量化有一个额外的坑在线推理时新token逐个生成没法像训练时那样对整条序列做per-token统计。所以KV cache的scale通常是离线校准阶段统计好的固定值推理时直接套用。这意味着校准集对KV cache分布的代表性更关键上线前最好用目标场景的长文本采样多验证几轮。4.3 为什么这个场景下W8A8比INT4更实用很多人会问既然要极致压显存为什么不用INT4我在几个项目里对比过W8A8在实际部署中的整体收益往往优于INT4。原因有三点。第一是精度。4位量化在没有额外微调的情况下对超大模型的伤害是显著的尤其当业务对生成质量敏感时差距会体现在事实准确性和流畅度上。INT8配上SmoothQuant可以把各种规模的模型都拉回到接近FP16的水平这种无痛属性在快速迭代的项目里太重要了。第二是计算。W8A8的GEMM可以完整走INT8 Tensor Core长度吞吐非常可观。INT4权重配上FP16激活矩阵乘需要反复做反量化Tensor Core的利用率反而上不去。在很多基准里W4A16的实际吞吐并不比W8A8快甚至更慢。第三是生态。INT8推理在主流推理引擎里已经有了充分的算子覆盖和稳定支持INT4的支持则分散在不同的量化方案中质量和性能参差不齐。对生产环境来说稳定性和可维护性的权重远大于单位显存的极致压缩。4.4 吞吐与延迟的实测收益方向最后说说量化之后实际能拿到多少性能收益。权重INT8带来的最直接的改变是显存占用减半这释放了两个红利一是模型可以整体驻留显存省去了跨节点通信的开销二是KV cache能放到更大或者batch可以开得更大总吞吐随之上升。在decode阶段性能瓶颈主要是带宽而非算力。显存占用减半意味着每生成一个token需要读取的字节数减半相同带宽下token吞吐理论上能提升接近一倍。实际测试中配合成熟的INT8 kernel端到端吞吐提升通常在1.4到1.8倍之间。首token延迟不一定有明显下降因为prefill阶段是算力密集型INT8算力的提升会被软件栈开销抵消一部分。但长期跑在线服务吞吐上的收益是实打实的直接关系到单卡每秒钟能服务多少用户。5. 常见问题与避坑实录5.1 校准集选不好上线就崩这个问题我踩过太多次了。第一次给某个代码生成模型做SmoothQuant拿了一堆通用新闻文本去校准离线测试困惑度看着不错上线后用户输入代码片段直接出现大量乱码式输出。原因就是代码文本的激活值动态范围比新闻大得多校准集没覆盖到scale偏小上线激活被截断。从那以后我的校准集选择原则是三份样本混合业务真实流量占大头公开通用语料补充分布多样性再掺一点目标任务的极端样本。校准完还要做一个对抗测试——故意构造一些高动态范围的输入比如超长文本、密集数字、大量重复token确认量化后的输出没有明显恶化才敢上线。5.2 alpha不是0.5就万事大吉0.5在大多数模型上都不错但我在两类模型上翻过车。一类是很深的模型超过100层深层的激活累积后离群点更严重统一0.5会导致深层精度下降需要逐层调高alpha。另一类是经过特定训练策略的模型比如强化学习微调过的聊天模型它们的激活分布和基座模型差异很大最好重新做校准和alpha搜索。逐层调alpha还有一个容易忽略的点搜索的评估数据不能太短。用几十条评测样本得出的最优alpha很不稳定至少要几百条并且每层搜索时固定其他层的alpha不动否则会陷入联合调优的组合爆炸。5.3 平滑参数必须跟着模型一起保存这是个工程细节但能坑到人。SmoothQuant做完之后LayerNorm的参数改掉了权重也改了这些改动必须和scale向量一起作为模型资产保存。如果只保存了平滑后的权重而丢掉scale推理时反量化的数值就完全对不上输出直接崩溃。我建议的保存格式是把scale和权重打包在一起每次加载模型时统一恢复。多卡推理时尤其要注意每张卡都要拿到对应的scale分片我曾经因为shard逻辑里漏了scale的切分导致8卡里7卡正常1卡乱算查了半天才发现问题。5.4 小模型与多模态适配的注意点最后说个方向SmoothQuant在大模型上效果好但小模型低于1B上未必有明显优势。小模型的激活值离群现象没那么严重常规的W8A8已经能撑住SmoothQuant的收益有限反而引入额外复杂度。所以在小模型上我一般直接走标准per-channel/per-token量化省事。多模态模型是另一个场景。视觉编码器和文本decoder的激活分布完全不同做好对文本部分做独立的SmoothQuant校准视觉部分单独评估。另一个常见做法是只对decoder做平滑视觉塔保持FP16因为视觉塔的计算量占比不高省不了多少显存不值得冒险牺牲精度。6. 一些实战后的体会SmoothQuant最让我觉得漂亮的一点是它没有发明任何新的量化运算法则只是重新分配了已有的误差预算。这种从数学恒等式里找自由度的思路在工程优化里特别有借鉴价值。很多时候我们盯着一个难点死磕不如退一步看看这个难点能不能搬到更合适的位置上去解决。实际操作中我建议不要一上来就追求端到端性能最大化。先把SmoothQuant跑通、精度达标再做alpha调优和kernel层面的优化。很多人第一步就卡在校准集或者scale计算上花了太长时间其实只要流程理顺了一天之内就能把一套70B模型的W8A8方案跑起来。最后分享一个小技巧上线前除了看困惑度和下游指标多留意一下量化模型生成文本的风格漂移——有时数字指标没变但模型输出的标点习惯、句式长度都有细微变化这种变化在业务侧可能被感知为模型变了。量化不是免费的SmoothQuant让代价变得很小但该做的质量回归测试一步都不能省。
做推理和部署优化这些年量化是我绕不开的话题。尤其是到了大模型阶段大家都想要8位整数计算带来的那点吞吐红利——模型显存减半MatMul直接走Tensor Core看着就很香。但真上手才会发现W8A8这四个字写起来容易跑起来全是坑。前阵子我在某个70B级别的开源模型上试水权重按通道量化、激活按token量化常规流程老老实实走一遍困惑度直接掉了一两个点。一开始还以为是校准数据量不够加了两千条还是老样子。后来换了几种方案折腾才意识到问题根本不是工程细节而是激活值本身没法量化。SmoothQuant解决的就是这个僵局。它没有靠更高阶的量化算法硬扛而是用一个数学上完全等价的变换把量化难度从激活值搬家到权重上。这个思路出来之后W8A8在大模型上的精度才算真正站住了。这篇文章我不打算复述论文重点讲三件事SmoothQuant到底在做什么、怎么做才能在自己模型上复现出效果、以及单节点塞下超大模型时那些实打实的部署账。1. W8A8量化到底难在哪从分布不均说起1.1 量化基础回顾精度、粒度与硬件支持先对齐一下概念。我们说的W8A8是指权重Weight和激活值Activation都量化为8位整数。8位量化意味着每个数只有256个离散档位浮点数的连续取值要被映射到这些档位上。映射做得好不好直接决定模型精度损失多少。量化粒度是第一个关键选择。最粗糙的是per-tensor整层权重共用一个scale实现最简单但精度最差。好一点的是per-channel每个输出通道单独一个scale这几乎是权重量化的标配。到了激活值情况就复杂了——激活是一个形状为[batch, seq_len, hidden_dim]的大矩阵我们既可以对整个矩阵用一个scaleper-tensor也可以对每个token单独用一个scaleper-token还有per-channel按特征通道统计的方案。硬件层面的现实是主流GPU的INT8 Tensor Core原生支持W8A8矩阵乘但对per-channel和per-token这种细粒度scale的支持程度不同。A100之后的架构在INT8算力上非常可观前提是你的GEMM kernel能把各种scale处理好。所以从工程角度讲W8A8是性价比最高的目标格式——INT4精度通常撑不住FP8又受限于部分硬件的支持成熟度只有W8A8能稳定吃到Tensor Core的加速且不牺牲太多精度。1.2 大模型激活值里藏着系统性离群点真正让大模型W8A8翻车的不是权重是激活值。很多人第一次做LLM量化时会拿小模型的经验套结果发现完全不是一回事。我在一个70B模型上做激活值分布分析时画出来的直方图让人头皮发麻绝大多数激活值集中在很小的数值范围内但少数几个通道上的绝对值能比中位数大几十倍甚至上百倍。这些离群点不是偶然噪声而是系统性的——它们固定在特定的特征通道上几乎每个token都会在这些通道产生很大的值。论文里的说法是约1%的通道承载了很大比例的量级。这跟CNN的激活分布完全不同CNN的激活值相对均匀per-tensor或per-token量化就能应付。但 transformer 架构里某些通道对应的特征本身就具有大动态范围比如部分attention score前的线性投影就会持续产出大数值。为什么这些离群点是致命的做对称量化时scale由最大绝对值决定。只要一个通道有一个极端大值整个per-tensor的scale就被拉大其他99%的通道被挤到极低的量化分辨率上精度自然崩盘。per-token会好一点因为它把每个token单独归一化了但这只能解决token间的动态范围差异解决不了通道间的差异——每个token里那些离群通道依然存在。1.3 之前那些方案为什么卡在原地在大模型量化这个方向上之前比较有代表性的方案是混合精度保留离群值思路是检测出离群通道让它们留在FP16里计算其余走INT8。这个方法在小规模上有效但有几个硬伤检测离群通道本身有额外开销混合精度导致矩阵乘无法完整走INT8 Tensor Core一部分计算回退到FP16加速比打折更麻烦的是检测逻辑在批量推理时会干扰kernel流水线工程集成很难做漂亮。另一个方向是直接放弃8位退到4位。INT4权重确实把模型压得更小但激活值仍然是16位甚至32位GEMM的输入精度不一致Tensor Core支持W4A8或W4A16的矩阵乘效率远不如W8A8。而且从实测看超大模型在INT4下的精度损失通常比INT8高一个台阶不是所有业务都能接受。所以这个僵局的本质是激活值的离群通道让8位量化在数学上很难成立而所有绕开它的方案都要牺牲计算效率或精度。SmoothQuant的聪明之处在于它不去想办法处理离群点而是直接把产生离群点的负担转移到权重侧——既然数学上完全等价为什么不选一个更好量化的路径来走2. SmoothQuant的破局点一次数学上完全等价的搬家2.1 一个不起眼的恒等式SmoothQuant的核心操作说穿了就是一个初中生都看得懂的恒等式对任意激活矩阵X和权重矩阵W它们的矩阵乘可以写成 X·W (X·s)·(W/s)其中s是一个逐通道的正数向量。这里的关键词是等效——这不是近似不是用某种技巧逼近原始结果而是数学上的恒等变换。只要s选择得当X·s和W/s在量化后的精度损失可以和原始X、W直接量化时的损失完全不同。第一次看到这个变换时我的第一反应是就这矩阵乘两边乘同一个对角阵的逆这不是线性代数里最基础的操作吗。但细想就明白了这个变换的意义在于它给了我们一个自由度我们可以自由地在激活值和权重之间分配量化难度。原本激活值一方独扛所有的离群压力现在可以把一部分压力借给权重来承担。权重为什么有空间承担因为权重的分布相对均匀逐通道的scale能很好地适配。而且权重是静态的我们可以花很多时间做精细的预处理它不需要像激活值那样在推理时实时计算scale。换句话说激活值量化是在线难题权重量化是离线难题SmoothQuant做的就是尽量把难点从在线挪到离线。2.2 把量化负担从激活搬到权重具体怎么搬关键在于s的构造方式。如果单纯给所有通道一个固定值变换没有意义。SmoothQuant的s是按输入通道分别设置的构造原则是激活值里那些又大又集中的离群通道分配给它们较大的s让X·s把这些通道的数值压扁对应的W/s里这些通道的数值会被拉大量化难度转移到权重上。用一句话概括哪里难量化就给哪里乘以一个合适的系数把它压下去同时用一个具有互补效应的除法作用在另一个因子上。最终效果是激活值变得平滑了权重虽然变粗糙了一点但权重的量化基准本身就更宽容两边的误差重新达到平衡。实际操作中s的取值通常基于激活通道最大值和权重通道最大值的统计来算。经典的构造方式是取两者的幂平均比例——对第j个通道统计校准集上激活值的最大绝对值记为m_X_j统计权重矩阵第j个输入通道的最大绝对值记为m_W_j然后令s_j (m_X_j)^α / (m_W_j)^(1-α)这里的α在0到1之间。α0时s全为1等于什么都没做回到原始的W8A8α1时激活的离群值被最大程度压平但权重会变得极其不均匀权重量化本身开始变难。SmoothQuant最妙的地方在于这个调节旋钮是连续的我们可以找到一个中间点让激活和权重都落在各自舒适的量化区间内。2.3 alpha参数的直觉与选法论文里推荐α取0.5这个数字不是拍脑袋定的。我自己的理解是0.5相当于在激活量化和权重量化之间做均等的风险分配——两边各扛一半压力。在绝大多数开源大模型上这个默认值表现都很好是一个闭着眼睛用也不会太差的起点。但绝不建议直接把0.5当万能钥匙。我在实际项目里遇到过一些模型某些层的激活离群程度特别剧烈0.5压不住需要把α调到0.6甚至0.7。也有个别模型权重本身的分布比一般模型更敏感α稍微调大一点权重量化误差就明显上升这种情况下反而要往0.4方向退。实操中的调法是对每层单独做网格搜索在校准集上选一小段数据把α在0.2到0.8之间按0.05的步长遍历评估量化后模型输出的困惑度或下游任务指标找到每层的最佳值。需要注意的是评估指标要选对——困惑度对整体分布敏感但某些业务更关心特定任务的精度最好两个都看。逐层搜索的收敛速度很快因为每层的评估是独立的可以并行跑几分钟就能出结果。3. 手把手实操把SmoothQuant接到现有推理流程3.1 校准集合与统计量的选择SmoothQuant的scale构造离不开激活值的统计这就要选校准集。我见过不少人在这一步翻车最典型的错误是随手拿几百条新闻文本就去统计。校准集的领域和上线场景差太多统计出来的最大值分布就不准推理时一遇到真实流量里的长尾输入直接截断报错或精度骤降。我的建议是校准集至少覆盖三类来源一是训练数据里随机抽样的部分二是上线场景的典型输入采样三是加入一些合成的高难度样本比如超长文本、密集数字、代码片段用来模拟极端分布。数据量不用贪多几百到一两千条就够重点是把分布的上下界摸准。统计量本身也要讲究。直接取最大值(max)对离群点特别敏感如果校准集里混入一两条极端样本整个通道的scale都会被带偏。更稳的做法是用高分位数比如99.99%分位数或者对最大值做截断处理只统计校准集上多次forward中最稳定的那些通道值。3.2 scale计算与权重的平滑处理拿到激活统计和权重统计之后具体流程是这样的。用PyTorch伪代码可以写得很清楚# 假设拿到了校准集上的激活输出 activations: [num_samples, seq_len, hidden_dim] # 权重矩阵: weight: [in_features, out_features] # 1. 按输入通道统计激活的最大绝对值 act_max activations.abs().amax(dim(0, 1)) # [hidden_dim] # 2. 按权重的输入通道统计最大绝对值 weight_abs_max weight.abs().amax(dim1) # [in_features] weight_abs_max torch.clamp(weight_abs_max, min1e-8) # 3. 计算平滑因子 alpha 0.5 scale (act_max ** alpha) / (weight_abs_max ** (1 - alpha)) scale torch.clamp(scale, min1e-4) # 4. 平滑权重每行除以对应scale smoothed_weight weight / scale.unsqueeze(1) # 5. 保存精度的同时也要保存scale后续GEMM要用这里有三个细节要注意。第一scale是针对权重矩阵的输入通道维度也就是hidden_dim方向不是输出通道。第二平滑后的权重不要直接存成INT8——先以FP16/BF16保存平滑后的权重推理时再对平滑权重做常规的per-channel量化这样才能确保权重量化误差和激活量化误差是分别叠加的而不是一步到位把误差搞混。第三对embedding层和最后的lm_head层通常不做平滑这两层不参与GEMM的量化收益保持原样反而省事。3.3 融合到LayerNorm的落地技巧这是SmoothQuant在工程上非常值钱的一个技巧。直接按公式实现的话每层矩阵乘前都要对激活矩阵做一次逐元素乘法乘以s这多了一次访存和一次kernel调用对推理延迟不友好。但SmoothQuant的构造允许我们把这次乘法藏进前一层的LayerNorm或RMSNorm里。原理很简单LayerNorm的输出是逐通道仿射变换y gamma * x_norm beta。如果我们要让这一层的输出乘以s只需要把gamma换成gamma * s把beta换成beta * s。这样一来前向计算走完LayerNorm后激活值天然就是平滑过的GEMM前的逐元素乘法就整个消失了。RMSNorm更简单没有beta项只改gamma就行。我在实际项目里强烈建议做这个融合尤其是吃显存带宽的decode阶段少一次全量逐元素乘对整个token吞吐都有可感知的提升。融合实现不复杂就是在导出模型时把scale乘进LayerNorm的gamma和beta后面量化逻辑完全不用感知scale的存在。3.4 W8A8 GEMM的运行时实现要点平滑做完之后推理时的矩阵乘里其实有两套scale在起作用一套是权重per-channel量化带来的反量化scale另一套是激活per-token量化带来的反量化scale。INT8 GEMM计算完得到的是INT32累加结果需要乘上这两套scale的外积才能回到精度正确的FP16/BF16数值。这部分的实现细节直接决定性能。粗暴的做法是把INT32结果写回显存再单独做一次FP16矩阵乘来scale那等于把INT8省下的时间又还回去了。正确的做法是在GEMM的epilogue阶段直接融合scale校正——用CUTLASS可以自定义epilogue或者在集成到推理引擎时确保kernel支持per-channel和per-token两种scale的融合。主流推理框架对这块的支持已经比较成熟比如FasterTransformer和TensorRT-LLM都内置了SmoothQuant的集成方案。我的建议是能不用自己写kernel就别自己写先用现成实现跑通效果确认精度和性能都达标之后再考虑要不要为特殊场景定制。自己造轮子在这个领域成本极高因为INT8 GEMM的优化涉及寄存器调度、shared memory布局和Tensor Core指令对齐没有几个月的迭代很难追上成熟方案。4. 单节点扛起530B工业部署的账本与收益4.1 显存账怎么算标题里说的单节点承载530B巨无霸不是营销话术是W8A8最实打实的收益。530B参数在FP16下需要约1.06TB显存8张A100 80GB的整节点也只有640GB物理上就装不下。而INT8量化后权重只要530GB8张80GB卡合计640GB扣除权重后还剩约110GB给KV cache、激活值、临时buffer和计算碎片——单节点单机塞下530B从算显存账的角度看是成立的。具体到部署这笔账还要算细一点。权重虽然只有530GB但多卡切分时要注意每个GPU能拿到的权重分片是均匀的避免出现某张卡显存吃满、其他卡闲着的情况。110GB留给KV cache和运行时开销batch size和序列长度都要做限制但至少给了项目一个单机可跑的机会。要是换成INT4权重能压到265GB显存更宽裕但前面说过INT4带来的精度风险和kernel支持成本在超大规模场景下会让很多团队望而却步。4.2 KV cache量化长序列场景的第二块大蛋糕权重只是显存支出的一半另一半大头是KV cache。以常见的65B级别开源模型为例80层结构batch开到16、序列长度2048时FP16的KV cache总量可以到80GB左右——在单卡上这已经是一个巨大包袱。而KV cache的量化和权重量化一样吃的是SmoothQuant同样的红利。KV cache里的K和V本身就是激活值同样存在离群通道问题。SmoothQuant论文里对KV cache的处理是按通道维度统计scale并量化到INT8推理时动态写入和读取都走INT8需要的计算量几乎不增加。KV cache面积直接减半意味着同样的显存预算下batch可以翻倍或者序列长度可以拉长一倍。对长文本场景比如万字级别的文档分析这个收益比权重本身减半还要明显。不过KV cache量化有一个额外的坑在线推理时新token逐个生成没法像训练时那样对整条序列做per-token统计。所以KV cache的scale通常是离线校准阶段统计好的固定值推理时直接套用。这意味着校准集对KV cache分布的代表性更关键上线前最好用目标场景的长文本采样多验证几轮。4.3 为什么这个场景下W8A8比INT4更实用很多人会问既然要极致压显存为什么不用INT4我在几个项目里对比过W8A8在实际部署中的整体收益往往优于INT4。原因有三点。第一是精度。4位量化在没有额外微调的情况下对超大模型的伤害是显著的尤其当业务对生成质量敏感时差距会体现在事实准确性和流畅度上。INT8配上SmoothQuant可以把各种规模的模型都拉回到接近FP16的水平这种无痛属性在快速迭代的项目里太重要了。第二是计算。W8A8的GEMM可以完整走INT8 Tensor Core长度吞吐非常可观。INT4权重配上FP16激活矩阵乘需要反复做反量化Tensor Core的利用率反而上不去。在很多基准里W4A16的实际吞吐并不比W8A8快甚至更慢。第三是生态。INT8推理在主流推理引擎里已经有了充分的算子覆盖和稳定支持INT4的支持则分散在不同的量化方案中质量和性能参差不齐。对生产环境来说稳定性和可维护性的权重远大于单位显存的极致压缩。4.4 吞吐与延迟的实测收益方向最后说说量化之后实际能拿到多少性能收益。权重INT8带来的最直接的改变是显存占用减半这释放了两个红利一是模型可以整体驻留显存省去了跨节点通信的开销二是KV cache能放到更大或者batch可以开得更大总吞吐随之上升。在decode阶段性能瓶颈主要是带宽而非算力。显存占用减半意味着每生成一个token需要读取的字节数减半相同带宽下token吞吐理论上能提升接近一倍。实际测试中配合成熟的INT8 kernel端到端吞吐提升通常在1.4到1.8倍之间。首token延迟不一定有明显下降因为prefill阶段是算力密集型INT8算力的提升会被软件栈开销抵消一部分。但长期跑在线服务吞吐上的收益是实打实的直接关系到单卡每秒钟能服务多少用户。5. 常见问题与避坑实录5.1 校准集选不好上线就崩这个问题我踩过太多次了。第一次给某个代码生成模型做SmoothQuant拿了一堆通用新闻文本去校准离线测试困惑度看着不错上线后用户输入代码片段直接出现大量乱码式输出。原因就是代码文本的激活值动态范围比新闻大得多校准集没覆盖到scale偏小上线激活被截断。从那以后我的校准集选择原则是三份样本混合业务真实流量占大头公开通用语料补充分布多样性再掺一点目标任务的极端样本。校准完还要做一个对抗测试——故意构造一些高动态范围的输入比如超长文本、密集数字、大量重复token确认量化后的输出没有明显恶化才敢上线。5.2 alpha不是0.5就万事大吉0.5在大多数模型上都不错但我在两类模型上翻过车。一类是很深的模型超过100层深层的激活累积后离群点更严重统一0.5会导致深层精度下降需要逐层调高alpha。另一类是经过特定训练策略的模型比如强化学习微调过的聊天模型它们的激活分布和基座模型差异很大最好重新做校准和alpha搜索。逐层调alpha还有一个容易忽略的点搜索的评估数据不能太短。用几十条评测样本得出的最优alpha很不稳定至少要几百条并且每层搜索时固定其他层的alpha不动否则会陷入联合调优的组合爆炸。5.3 平滑参数必须跟着模型一起保存这是个工程细节但能坑到人。SmoothQuant做完之后LayerNorm的参数改掉了权重也改了这些改动必须和scale向量一起作为模型资产保存。如果只保存了平滑后的权重而丢掉scale推理时反量化的数值就完全对不上输出直接崩溃。我建议的保存格式是把scale和权重打包在一起每次加载模型时统一恢复。多卡推理时尤其要注意每张卡都要拿到对应的scale分片我曾经因为shard逻辑里漏了scale的切分导致8卡里7卡正常1卡乱算查了半天才发现问题。5.4 小模型与多模态适配的注意点最后说个方向SmoothQuant在大模型上效果好但小模型低于1B上未必有明显优势。小模型的激活值离群现象没那么严重常规的W8A8已经能撑住SmoothQuant的收益有限反而引入额外复杂度。所以在小模型上我一般直接走标准per-channel/per-token量化省事。多模态模型是另一个场景。视觉编码器和文本decoder的激活分布完全不同做好对文本部分做独立的SmoothQuant校准视觉部分单独评估。另一个常见做法是只对decoder做平滑视觉塔保持FP16因为视觉塔的计算量占比不高省不了多少显存不值得冒险牺牲精度。6. 一些实战后的体会SmoothQuant最让我觉得漂亮的一点是它没有发明任何新的量化运算法则只是重新分配了已有的误差预算。这种从数学恒等式里找自由度的思路在工程优化里特别有借鉴价值。很多时候我们盯着一个难点死磕不如退一步看看这个难点能不能搬到更合适的位置上去解决。实际操作中我建议不要一上来就追求端到端性能最大化。先把SmoothQuant跑通、精度达标再做alpha调优和kernel层面的优化。很多人第一步就卡在校准集或者scale计算上花了太长时间其实只要流程理顺了一天之内就能把一套70B模型的W8A8方案跑起来。最后分享一个小技巧上线前除了看困惑度和下游指标多留意一下量化模型生成文本的风格漂移——有时数字指标没变但模型输出的标点习惯、句式长度都有细微变化这种变化在业务侧可能被感知为模型变了。量化不是免费的SmoothQuant让代价变得很小但该做的质量回归测试一步都不能省。
