企业官网建设流程全解析

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 量化加量化感知蒸馏（QAD），vLLM 吞吐是 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）：

值得盯的不是平均分，而是结构：默认做法下，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