4 比特量化到底让模型笨了多少？答案藏在每 16 个权重共用的那个缩放系数里

4 比特量化到底让模型笨了多少答案藏在每 16 个权重共用的那个缩放系数里先看两个数字。同一份 Qwen3.5-9B同一套 4 比特推理内核同一批校准数据。唯一变动的是「每 16 个权重共同使用的那个缩放系数该取多少」。结果GSM8K 数学推理一项一个版本 74.60另一个版本 80.89。差 6.3 分。而这两个版本在部署时的显存占用、算子吞吐、内核调度完全一样一个字节都没差。这就是 4 比特量化最反直觉的地方格式是硬件写死的真正决定模型笨不笨的是造 checkpoint 的时候你给每一小块权重挑了什么缩放系数。英伟达 Model Optimizer 团队上周把这件事的算法细节、以及一张可以逐项复算的对照表公开了官方博客代码在 NVIDIA/Model-Optimizer。先确认为什么非要压到 4 比特从 16 比特走到 4 比特权重体积直接变四分之一。而大模型 decode 阶段的瓶颈本来就不在算力而在把权重从显存里搬出来这一趟搬运——压缩精度等同于把带宽需求压下来。这不是纸面收益官方给的实测里550B 的 Nemotron 3 Ultra 做成 NVFP4 之后decode 密集场景吞吐比同为 FP4 的 754B 对照模型高 5.9 倍Qwen3.6-35B-A3B 走完 W4A4 量化加量化感知蒸馏QADvLLM 吞吐是 BF16 的 1.30 倍checkpoint 小 3.1 倍教程。代价是精度。问题在于代价到底由谁决定。NVFP4 的结构16 个权重共享一个尺度NVFP4 这个格式本身很简单两句话能说完每 16 个权重打包成一块块里的权重用 4 比特浮点E2M1存而 E2M1 能表示的值一共只有 16 个范围锁在 -6.0 到 6.0为了让这些权重尽量落在格点上每一块额外配一个 FP8 的块尺度用来把块内数值缩放回可表示范围Four Over Six 论文。关键全在那个尺度上。默认做法叫 max scaling看块内最大值直接拿它定尺度。听起来合理其实很浪费——块内最大值一旦偏大整块权重就被推到贴近 6.0 的位置剩下的 15 个格点几乎没人用等于把分辨率拱手让出去。于是有了更精细的挑法Four Over Six 从两个候选尺度里选一个Model Optimizer 自带的 MSE 算法则干脆穷举全部 126 个正的非零 FP8 尺度谁让权重误差最小就用谁。但对 9B 模型来说这两种「看起来更精细」的做法分别只把平均掉分从 5.10 拉到 4.75 和 3.87。原因很直接它们优化的都是权重自身的误差而官方明确说这个指标跟下游评测精度关联很差。权重差了 0.01落到输出上可能什么都不是权重几乎没差也可能正好压在模型做多步推理的路径上。换个目标函数把「输出误差」当尺子一层线性层写出来是 Y WX。量化之后权重带着误差 Δ 上场但模型感受到的不是 Δ而是 Δ 乘过输入 X 之后的输出误差E(s) ‖Δ·X‖² tr( Δ · (XXᵀ) · Δᵀ )那个 XXᵀ 就是输出误差的二阶导数矩阵的一半也就是 Hessian——它给每一个权重误差按「这个输入维度到底能推动输出多少」做加权。换句话说频繁被激活、且真正影响输出的那些维度权重误差要更被认真对待。麻烦在搜索空间。每个输出通道有 C_in/16 个块每块还有一堆候选尺度联合最优需要枚举出 M^(C_in/16) 种组合完全不可行。Local-Hessian 的做法是块对角近似承认块与块之间的量化误差相互作用可以忽略于是把问题拆成一块一块独立求解——每块涉及的都是 16×16 的小 Hessian仍然穷举 126 个候选尺度用 Triton kernel 一次把整层算完。数字摆出来在 Qwen3.5-9B 上除 lm_head 外全部层都做 NVFP4 权重量化和激活量化W4A4尺度算法GSM8KMMLU平均掉分WikiText PPLBF16 参照87.6478.690.009.20max 尺度默认74.6075.815.1010.08MSE 尺度76.7276.493.879.98Four-over-six 尺度76.4275.324.7510.02Local-Hessian 尺度80.8976.813.109.90值得盯的不是平均分而是结构默认做法下MMLU 这种知识问答只掉 2.9 分GSM8K 却掉了 13 分。4 比特真正伤的是多步推理和计算——而那些恰恰是最不容易靠「大致对」糊过去的任务。换一套尺度选法GSM8K 直接拉回 6.3 分平均掉分从 5.10 降到 3.10。还能再叠加一层局部 Hessian 只改尺度的算法GPTQ论文改的是舍入方式两者正交可以合用——叠加后平均掉分进一步降到 2.94。但这里有个诚实的细节在更大的 Qwen3.8-27B 上Local-Hessian 叠加 GPTQ 反而比单用 Local-Hessian 更差所以官方发布的 nvidia/Qwen3.8-27B-NVFP4 只用 Local-Hessian。没有万能配方只有逐模型验证。最后一点最实用这些尺度只在造 checkpoint 时算一次反复迭代校准集之后固化成文件部署时直接复用不引入任何额外开销。纯赚的精度。剩下的账交给混合精度就算尺度选得再好硬把每一层都压到 4 比特还是会疼。原因是模型本身不均匀少数层——注意力投影、网络的最后几层——对量化异常敏感而大多数层比如 MoE 的专家相当抗造。于是同一支团队做了 AutoQuantize用二阶泰勒展开的思路把「量化某一层会让 loss 涨多少」近似成输出误差乘上梯度的平方对角 Fisher 近似给每个算子打一个敏感度分再给每种精度格式估一个部署成本最后一句话归约成背包问题用整数线性规划在预算内挑出总敏感度最低的混合精度分配。以前这是逐模型做消融实验的苦活现在是一次前向加一次反向。想自己试装nvidia-modelopt在量化配置里把算法指定为local_hessian需要开启 layerwise然后照官方配方跑校准512 条校准样本、序列长度 2048产出的 checkpoint 可以直接喂给 vLLM、SGLang 或 TensorRT-LLM。如果你需要在多个模型之间做对比测试likeai520.cc 的 API 中转可以省掉不少折腾。回头看这条技术线的信号其实很清楚低精度推理过去两年的进步相当一部分不是来自新硬件而是来自「格式不变、只改怎么算」的工程空间。真正值得记住的动作只有两个——自己量化一版然后在 GSM8K 这类多步推理任务上验一遍。信「支持 FP4」这四个字风险比信一张自己跑出来的对照表大得多。参考来源NVIDIA Model Optimizer 官方博客Improving NVFP4 Accuracy with Local-Hessian Weight Scales · AutoQuantize 博客 · NVIDIA/Model-Optimizer 仓库 · Four Over Six 论文 · GPTQ 论文 · nvidia/Qwen3.8-27B-NVFP4