TL;DR ：三位独立研究者把 9B--20B 开源模型在 vLLM/SGLang 上量化的全部公开实测翻了个底朝天，发现所有计时都能用一条「内存带宽 vs 计算」的规则解释：小 batch 时 4-bit 量化提速约 2 倍，大 batch 时增益几乎归零，这时候 FP8 才是还能打的配方。同时，大量被广泛引用的「量化掉点」数字（包括所有 HumanEval 差值）其实落在基准的采样噪声里。文末附 7 条量化评测报告清单，建议部署前对照。
资源
- 论文：arxiv.org/abs/2611.04...
- HTML 全文：arxiv.org/html/2611.0...
先问一个可能正戳中你的问题：你们团队要把一个 14B 的开源模型放上 vLLM 或 SGLang 自托管，老板问「量化能省多少卡」，算法同学提醒「量化会不会掉点」------然后你去搜资料，得到的是一堆互相打架的答案：模型卡说 AWQ 提速 2.8 倍几乎无损，某基准报告说 GPTQ 掉了 4 分，还有帖子说量化根本没用。
谁对？最近挂在 arXiv（AILET Vol. 1110）上的一篇 letter 给出了目前最接近「标准答案」的东西：Twice as Fast, Until It Isn't: Quantized Serving of Mid-Size Open LLMs。三位独立研究者（Kadvani、Faujdar、Tallam）把截至 2026 年 10 月 5 日能核实的公开测量全部收拢，逐条对照原始来源核验，得出了一些可能让你意外的结论。
为什么要盘这件事？
Qwen2.5-14B、Qwen3-14B、Gemma 3 12B、Phi-4、Mistral NeMo、gpt-oss-20b......这一参数段的模型有个共同点：BF16 能塞进一张数据中心 GPU，量化后能塞进一张消费级 GPU，所以是自托管部署的绝对主力。
部署团队选量化配方（recipe），本质上只需要两个数字：
- 相对 BF16 提速多少；
- 掉多少精度。
听起来很简单？作者的发现是：公开记录只能「拼凑式」地回答。有的来源只报速度不报精度；有的精度分数没有同 harness 的 BF16 基线，根本没法比；这一参数段里 AMD 和 Intel Gaudi 一条计时都没有；FP4 也没有任何对照 BF16 的计时。唯二「速度+精度」双全的 checkpoint，是两个 Gemma 3 12B 的 INT4 构建------而它们的精度分只覆盖一个 MMLU 哲学子集，还恰好是 AWQ 校准时用过的题（没错，校准题混进了考卷，这测评多少有点自嗨成分）。
他们是怎么盘的？
先说收录标准，这决定了这份盘点的可信度。作者给计时定的门槛是：来源必须写明引擎、GPU、checkpoint、workload 四要素 ，缺一个不要；给精度定的门槛是：同一来源用同一 harness 报告 BF16 基线分，没有基线的分数无法判断「掉了多少」。
搜索范围覆盖 vLLM、SGLang、AMD ROCm、Intel Gaudi 官方文档，模型官方和量化发布方（Red Hat AI、PyTorch、腾讯 AngelSlim）的模型卡，基准报告和 arXiv，每个模型名 × 每种配方（FP8 / INT8 / AWQ / GPTQ / INT4 / NVFP4 / MXFP4）× 每个引擎组合式检索。AI 编码助手帮忙收集和抽取，但每个数字最后都人工对照原始来源核验过。
这套「四要素 + 同基线」的严格标准筛下来，剩下的计时全部集中在一张表里。
一条规则解释所有计时
这是全文最漂亮的部分。所有公开计时------四组引擎×GPU 组合，不同模型不同指标------都能被一条**内存带宽 vs 计算（roofline）**的规则解释干净：
小 batch 时，解码受内存带宽限制。 batch 1 的情况下，每生成一个 token 都要把全部权重从显存读一遍，耗时由「搬多少字节」决定。4-bit 权重只搬 BF16 四分之一的字节，所以提速接近理论值 4 倍的下限------实测 1.35 到 2.12 倍。为什么到不了 4 倍？因为反量化开销、attention 计算、KV cache 读取都不随权重位宽缩小。
大 batch 时，GPU 变成计算受限。 batch 256 的情况下，一次权重读取就能服务 256 条序列，瓶颈从「搬数据」转移到「做计算」。而 W4A16（4-bit 权重）的矩阵乘反量化后还是在 16-bit 硬件上算------计算部分一点没省。结果就是 Gemma 3 12B 在 batch 256 下 INT4 只有 1.02 倍增益，基本等于白量化。
看看实测数字有多吻合：
vLLM 0.6.3，A100 80GB，Qwen2.5-14B-Instruct，batch 1，tokens/s（输入 1 / 30720）
| 配方 | tokens/s | 加速比 | 显存 |
|---|---|---|---|
| BF16（基线） | 46.30 / 37.18 | 1.00 | 28.08 GB |
| GPTQ-Int8 | 70.40 / 49.23 | 1.52 / 1.32 | 16.11 GB |
| AWQ (INT4) | 92.66 / 59.01 | 2.00 / 1.59 | 9.79 GB |
| GPTQ-Int4 | 98.02 / 60.91 | 2.12 / 1.64 | 9.94 GB |
vLLM benchmark_latency，H100，Gemma 3 12B，延迟秒（batch 1 / 256）
| 配方 | 延迟 | 加速比 |
|---|---|---|
| BF16（基线） | 3.73 / 14.07 | 1.00 |
| TorchAO INT4 | 2.73 / 13.81 | 1.37 / 1.02 |
| AWQ-INT4 | 2.76 / 13.93 | 1.35 / 1.01 |
SGLang 0.4.6.post1，H20 96GB，Qwen3-14B，吞吐/s（输入 1 / 30720）
| 配方 | 吞吐 | 加速比 |
|---|---|---|
| BF16（基线） | 47.10 / 525.80 | 1.00 |
| FP8 (W8A8) | 97.11 / 880.72 | 2.06 / 1.68 |
| AWQ-INT4 | 96.49 / 744.74 | 2.05 / 1.42 |
三条曲线一个故事：batch 1 时 INT4 全员 2 倍上下；batch 256 时 W4A16 直接躺平（1.02×）；而 FP8 因为 Hopper tensor core 的 FP8 算力本来就是 BF16 的两倍，大 batch 下依然保有 1.68 倍。长 prompt 同理------A100 上 INT4 增益从 2.12×（输入 1 token）跌到 1.64×（输入 30720 token），因为 prefill 也是计算密集的。
那 gpt-oss-20b 呢？它是 MoE（20.9B 总参数、3.6B 激活），专家权重原生 MXFP4 训练，情况特殊：唯一在带的计时比较的是引擎而非配方------默认设置下 vLLM 吞吐是 SGLang 的 2.93 倍（16,494 vs 5,627 tokens/s，H100，1000 条 ShareGPT prompt）。作者还补了一句有意思的：MXFP4 数值在 BF16 里可以精确表示，所以一份 BF16 拷贝理论上精度相同------但没人测过它的 BF16 基线。
精度：一大半「掉点」都在噪声里
速度的规律清楚了，那精度呢？作者的第二个发现可能更扎心：多数已发布的精度差值，比基准本身的采样噪声还小。
论文没找到任何来源报告标准误，于是自己补了把尺子：单次运行的标准误约为 p(1−p)/n 。套到主流基准上------
- HumanEval（n=164）：约 ±3.9 分；
- GSM8K（n=1319）：±0.8--1.3 分；
- 完整 MMLU（n=14042）：±0.34--0.39 分。
用这把尺子量公开数据：HumanEval 上所有量化差值（−3.05 到 +6.10，折合 ±5--10 道题）全部落在噪声里，根本无法区分哪个配方更好。你看到的「AWQ HumanEval +6.10」大概率只是运气。
那哪些掉点是「真的」？表里最明确的两处真实损失都在 GSM8K：AWQ 在 Qwen3-14B 上掉 4.17 分、GPTQ 在 Mistral NeMo 上掉 4.02 分，都超过三个标准误。数学推理能力对量化权重确实更敏感。8-bit 配方则整体安全------完整 MMLU 上所有 8-bit 差值不超过 0.77 分。
还有一个容易被忽略的因素：评测 harness 的影响不亚于配方本身。同为 Qwen3-14B 的 W4A16 量化，腾讯 AngelSlim 测出 GSM8K −1.06，Red Hat AI 测出 +3.94------不仅方向相反，两组 BF16 基线本身就差了 20.77 分。看到这种数字打架，先查评测工具再怪配方。
证据分级：哪些话敢说，哪些不敢
作者把每条结论按「独立来源数 × 模型数 × GPU 数」标了置信度，这个诚实的分级值得全文抄录：
| 问题 | 公开记录显示 | 置信度 |
|---|---|---|
| batch 1 速度 | W4A16 提速 1.35--2.12×；H20 上 FP8 与 AWQ 打平 | 中 |
| 大 batch 速度 | W4A16 无增益；FP8 未测 | 低 |
| 长 prompt 速度 | FP8 胜 AWQ（1.68× vs 1.42×） | 低 |
| 8-bit 精度 | MMLU 差 ≤0.77 分 | 中--高 |
| INT4 精度 | MMLU 0.43--1.43 分；GSM8K 最高约 4 分 | 中 |
| gpt-oss-20b 引擎 | vLLM 默认设置 2.93× SGLang | 低 |
| AMD / Gaudi 速度、FP4 加速 | 无在带测量 | 无 |
最后那几行「无」相当醒目------2026 年了，AMD 和 Intel Gaudi 在最主流的部署参数段上，连一条公开计时都没有。
泼点冷水
这篇论文本身也有局限，作者在文末交代得很坦率：
- Table 1 的四组计时来自不同实验：引擎版本从 vLLM 0.6.3 跨到 0.11.0（约两年的迭代），GPU、指标口径都不同，不是同一个 benchmark，只能组内比较。
- 标准误标尺假设题目独立、单次运行；已有研究（Dutta et al. 2024）指出两次运行间「答案翻转集合」是比总分更敏感的量化影响度量，但没有来源报告这个。
- Qwen3-14B 那条 FP8 计时用的 checkpoint 激活 scale 没标明 static 还是 dynamic，没法对应到精度表------讽刺的是，「计时与精度用同一个 checkpoint」正是作者自己清单的第一条。
- 全部证据来自厂商/项目页面，内容会变动，最后核验日期 2026-10-05。
换句话说，这是一篇没有自己实验的元分析------它的价值在于指出「大家引用的数字有多不可靠」，而不是提供更可靠的数字。
那到底怎么选？
把论文的结论翻译成部署决策：
- 延迟敏感、batch 小（单用户、低并发）：选 W4A16（AWQ 或 GPTQ-INT4），提速 1.35--2.12×，MMLU 约掉 1 分，但要盯紧 GSM8K------数学能力最多可能掉 4 分。
- 吞吐敏感、batch 大（高并发服务） ：INT4 基本白量化，FP8 才是 roofline 认可的配方------但注意 Ampere 卡（A100）上 FP8 checkpoint 只能按 weight-only 跑，Hopper（H100/H20）才能满血。
- 只为省显存：INT4 把 14B 模型从约 28 GB 压到 10 GB，一张消费级卡就能装，这个收益与 batch 无关，永远成立。
- 引用任何「量化提速 X 倍」的说法之前，先过一遍论文给出的 7 条报告清单：checkpoint ID 与 revision、引擎版本与非默认 flag、GPU 型号、输入输出长度与 batch、同栈 BF16 基线、harness 细节附标准误、校准数据与评测集不相交。目前没有任何一条公开测量满足全部 7 条。
说到底，这篇 letter 讲的道理很简单：「快多少」取决于你的负载落在带宽受限还是计算受限区，「掉多少」取决于你有没有把噪声算进去。下次再看到「量化无损提速 4 倍」的宣传，先问一句：什么卡？什么引擎？batch 多大？和谁比的？
这大概就是一份好的测量综述能给行业的东西------不是新数字，而是一副看清旧数字的眼镜。