量化的真实权衡：FP16、INT8 与 GGUF 在生产中按模型大小的实际分歧

量化内容分为两类，且两类都无法回答运行这些模型之一的操作员所提出的问题。

学术类别报告的是困惑度（perplexity）的增减或在一套与实际生产流量无关的任务上的平均基准分数。困惑度仅增加 0.2 分，或平均分数的微小变化，可能掩盖某个特定工作负载从可靠变为不可用的情况，而平均值中的其他指标保持不变。营销类别则只给出一个要点：“4 位、体积缩小 4 倍、质量不变。”质量不变的前提是什么？支撑该声明的基准套件将任务类型按与任何单一生产工作负载都不相符的比例混合在一起，因此得到的综合分数实际上回答的是没有人在问的问题。

以下是该特定模型目前可获得的最佳证据表明的情况：它没有上述民间说法那样戏剧化。RedHatAI 发布的 llama3.3-70b-instruct 的量化检查点（FP8‑dynamic、INT8 W8A8、INT4 W4A16）均以相同的 BF16 基线进行测量。在这三种精度中的每一种上，它们在 GSM8K（8‑shot CoT，严格匹配）、MMLU、MMLU‑CoT、HumanEval、HellaSwag、Winogrande、TruthfulQA 以及 OpenLLM v1 平均分上恢复了 BF16 精度的 98.3% 至 100.8%。ARC‑Challenge 是唯一的异常值，值得单独指出而不必将其纳入一个连续的范围。它在 INT8 下恢复了 97.6%，在 FP8 下恢复了 105.6%，这种波动更像是接近噪声底线的小基准的波动，而非真实能力的变化。这里将其标记为噪声，而不是将其平滑到上述范围内。由于它在这里不是被测量的任务之一，因此不会在下面的结果部分中重新出现。

具体来说，GSM8K 包含需要两到八步推理的问题，在这些任务上恢复了 99.8% 至 100.3%的 BF16 精度。如果问题是‘在 70B 模型上使用 8 位或 4 位仅权重量化是否会破坏数学推理能力’，那么对这个确切模型的直接测量答案是：不会，在该基准上不会。

• 在综合基准测试中，8 位或 4 位仅权重量化不会在 llama3.3-70b-instruct 上破坏数学推理能力：RedHatAI 发布的 FP8-dynamic、INT8 W8A8 和 INT4 W4A16 检查点在 GSM8K（8-shot CoT，严格匹配）上恢复了 BF16 精度的 99.8% 至 100.3%，在 OpenLLM v1 平均分上恢复了 98.3% 至 100.6%。这是目前最有力的反证，驳斥了“量化会损害推理”的民间说法。此处的探测运行是针对它进行测量，而不是假设来证实它。
• 在可直接比较的 70B 推理模型（DeepSeek-R1-Distill-LLaMA-70B，Liu 等人，2025）上，单个量化开关（仅权重 4 位、仅 KV 缓存 4 位或 8 位权重‑激活）在五项推理基准的平均得分上不会造成超过 1 分的下降。将三者同时堆叠为 4 位时会出现下降：AIME-120 大约下降 84% 至 90%（取决于方法），而在完全相同的配置下，GSM8K 仅下降 6% 至 8%。此处测试的风险是堆叠效应，而非位宽效应。

本文不再推导量化机制。DigitalOcean 已有三篇文章深入解释了这些内容：理解大语言模型中的模型量化 讲解了降精度数值格式的基础，LLM 推理优化 101 讲解了量化所交互的预填充/解码及内存受限动态，LLM 推理优化栈 第 1 部分 在介绍剪枝和蒸馏的同时概览了量化。本节陈述了以下结果所依赖的唯一理论片段：误差累积假设。

机制，一句话概括。 量化将权重或激活的连续值范围映射到更小的一组离散级别：INT8 对应 256 级，4‑bit 对应 16 级。每个值都会被四舍五入到最近的可表示级别，在每个权重上引入微小误差。对于单 token 的分类决策，该误差只有一次机会翻转输出：正确类别与亚军之间的 logit 差距要么在四舍五入噪声中幸存，要么被淹没。对于 2000 token 的思维链，同样的四舍五入噪声会出现在每一步生成过程中。早期的算术失误或对前提的误读会成为后续每一步的输入。误差不会在链上平均抵消，而是会累积，因为每一步都以（可能已经出错的）前一步输出为条件。

这是下文实验设计部分所构建评估旨在隔离的可检验命题：推理链的深度是否能更好地预测准确率保持何时失效，而不仅仅取决于任务的主题。

服务栈现实检查。 精度选择并非独立于硬件和服务引擎。下表故意只列出关键点：深层硅权衡将在《专用推理硬件》章节中详述（待发布后交叉链接）。但在阅读后续的结果、交互效应和决策框架章节之前，你需要了解精度选择会对下游产生哪些强制影响。

GGUF 和 GPTQ/AWQ 都能生成“4-bit”模型，但它们的机制根本不同，而不仅仅是不同的校准方法。GPTQ 和 AWQ 在整个模型中保持位宽固定，通过改变校准方式来实现：GPTQ 采用逐层方式，AWQ 采用激活感知方式。GGUF 的 k-quants 则采取了另一种做法：llama.cpp 的变体（Q4_K_M、Q4_0 等）在真正不同的位宽下存储不同的张量。这不仅仅是在统一宽度内的不同尺度精度。Q4_K_M 将注意力和 FFN 张量的一部分保留在 Q6_K（64 级别），其余部分保持在 Q4_K（16 级别）。这就是为什么“4-bit GGUF”在每个权重上的平均位数更接近 4.8 而不是 4，因为模型的一部分实际上并不是 4-bit。

(哪些具体张量获得哪种精度是在已发布的模型卡约定中记录的，而不是在正式规范中，并且在下文使用的地方会有相应标记。) 下面结果部分的 GGUF Nuance 小节衡量这种方案差异（位宽分配，而不仅仅是校准）在相同的名义位宽下是否会表现为精度差距，就在此次单次运行中。

本文采用按照假设敏感度排序的任务阶梯，而非使用 aggregate 基准分数，因为 aggregate 基准分数正是掩盖这里所测量偏差的因素。

任务阶梯

我执行了这六个阶梯中的一个，在两个难度级别：多步数学和逻辑（GSM8K，1,319 条，8-shot；MATH-500，500 条，4-shot；均在下文的结果部分）。其余五个——分类和标注、结构化抽取、摘要生成、代码生成以及长期代理工具使用——则没有。其中四个尚未具备所需基础设施；代码生成的差距不同。分类和抽取需要手工构建、去重的数据集，因为它们没有像 GSM8K 和 MATH-500 那样现成的标准公开划分可用来继承计数或来源。摘要生成需要具有人类一致性校准的裁判基础设施，而不仅仅是精确匹配评分。代理工具使用需要将 tau-bench 连接到每个分支的已部署 vLLM 端点，而不是使用托管的 API 调用。

代码生成没有这些缺失：HumanEval 是一个标准的、现成可用的基准（见本节下方的来源和披露说明），因此其差距在于范围和 GPU 时间，而不是基础设施。这是一个范围声明，而不是保留：我构建的检查点、硬件和测试套件仍然存在。

六种任务类型中的一种，在两个难度级别。其余五个阶梯被命名为后续范围，而不是已有的部分结果。

对剩余的五个阶梯使用与上面数学阶梯相同的配对显著性检验，这就是此设置所明确的后续步骤。

每个阶梯的可评分项目下限为 100 项。GSM8K 完整的 1,319 项测试集和 MATH-500 完整的 500 项测试集均超过此下限，而非被下采样至该下限；tau-bench 零售的 115 项任务也采用同样的规模，以便在执行 agentic 阶梯时使用。

评分。 任务 1、2、4 和 5 通过与真实答案或测试套件进行精确匹配或执行来评分：不使用 LLM 作为评判者，也不存在被评估模型与评估模型之间的循环依赖。任务 3（摘要）以及任务 6 的部分内容不可避免地需要评判者评分；在这种情况下，会在每个结果中单独披露，而不是将其混入精确匹配的数字中。所使用的任何评判者均来自与 llama3.3-70b-instruct 不同的模型系列（为自身系列评分的评判者有文献记载的自我偏好 bias），答案顺序随机化，并采用参考锚定的评分规则，而非开放式质量评分。应将评判者自身的人类一致性校准与其产生的分数一起报告，而不是将评判者分数直接当作真实值呈现，正如 Arena-Hard-Auto 所报告的与人类偏好排名的一致性达到 89.1%。

来源和披露。 数学/逻辑任务使用标准的 GSM8K 测试集（1,319 项），采用 8-shot 并结合思维链进行评分，对每个模型规模的每个臂（arm）同时报告 both strict-match 和 flexible-extract 两种精确匹配指标。strict-match 与 RedHatAI 公布的方法学保持一致，因此结果网格可以直接携带一个复制行。除了 strict-match 之外，还需要 flexible-extract，因为在此测试 harness 中，随着模型规模缩小，strict-match 与公布数值之间的差距会急剧扩大（大约在 70B 时为 2.1 分，8B 时为 6.4 分，3B 时为 10.7 分）。这一现象表明问题在于答案格式的可靠性而非模型能力：较小的模型更倾向于将最终答案以严格解析器无法识别的形式呈现。仅在 strict-match 上测量的量化 delta 会将格式退化误判为能力损失，从而产生并不真实的尺度依赖结论。因此，必须同时使用这两个指标才能将两者区分开来。

代码生成使用 HumanEval（164 道题，pass@1），在需要更严格检查时则使用 HumanEval+/EvalPlus，后者会为每道题运行 substantially 更多的测试用例。代理工具使用任务以 tau-bench 的零售领域（115 项任务）为主要集合，因为它是两个领域中实力更强的那个。航空领域（50 项任务）仅在零售领域出现值得确认的信号时才作为确认检查保留，而不是将昂贵的评估臂分割到两个领域，因为单靠任何一个领域都无法在统计上得出结论。分类、提取、摘要、代码生成和代理工具使用是根据上面的 Task Ladder 表格命名的后续工作的设计规范；这五项在这里均未运行，因此目前尚无可确认的采样或来源细节。

MATH-500 协议，数学/逻辑层级的第二难度级别。 此运行 lm_eval 的 minerva_math500 任务（500 项，HuggingFaceH4/MATH-500 测试划分），lm_eval 0.4.12，与上面用于 GSM8K 的工具版本相同。相较于 GSM8K 运行，这里有三项刻意的协议差异，已在此披露而非保持隐含：

• 试射次数。 minerva_math500 运行 4-shot Minerva 风格的思维链，其任务默认，相对 GSM8K 的 8-shot。每个任务使用其自身的默认模板；覆盖任意一方都会破坏该任务期望的提示结构。这一点不会影响这里得出的比较。结果部分的每一次比较都是在 内部 单个任务中测量的量化增量，而非直接在 GSM8K 和 MATH-500 之间进行 跨任务 的准确率比较。两个任务的绝对准确率数值不会相互比较；仅比较各自的量化增量。
• 采样。 我在温度 0、种子 42、单次通过的贪婪解码下运行 MATH-500，以匹配 GSM8K 的运行方式，而不是此方法论章节上面所述的多步数学的三种子采样政策。这是声明政策与执行协议之间的真实差异。我倾向于协议在两个数学任务之间保持一致，而不是追溯匹配在任务运行之前就已编写的政策。未来在采用种子采样的情况下重新运行 GSM8K 或 MATH-500 的过程应同时报告两者，并标明哪种协议产生了哪个数字。

生成和上下文限制是显式设置的，而不是保持 lm_eval 或 vLLM 默认值：--gen_kwargs max_gen_toks=2048 和 max_length=8192 在 --model_args 中。两个不明显的 harness 默认值使得这两个设置都是必要的；在复现此运行之前，请参阅下面 Harness 部分的警告。

可重复性下限（70B INT8）。 我在 H200 上的 CUDA / vLLM 0.27.x 环境下，以贪婪方式，完整的 1,319 条目，8-shot，两次评估了完全相同的 INT8 W8A8 配置：Session 1 写入 results/int8/.../results_2026-08-12T15-03-51.422301.json，严格匹配为 92.34%，灵活匹配为 92.87% ；Session 2 写入 results2/int8/.../results_2026-08-12T22-16-40.899161.json，严格匹配为 92.04%，灵活匹配为 93.56% 。Session 3 未重新运行 70B INT8 GSM8K。两次运行在严格匹配上相差 0.30 个百分点。这设定了此 harness 的可重复性下限：低于 0.30pp 的准确率差异不具意义，不管 bootstrap 标准误差如何建议。测量的 GSM8K 表格使用 Session 2（results2）的数字作为 H200 INT8 行。

校准混淆。 Liu 等人（2025）发现，校准数据的领域对 GPTQ 影响显著，而对 AWQ、KVQuant 或 FlatQuant 几乎没有影响。将 GPTQ 的校准集从通用文本切换到推理数据，使 1.5B 模型的平均得分提升了 9.8 分；而其他方法在此切换下仅提升了 0.2 到 1.8 分。这对本文的 4‑bit 臂直接相关：RedHatAI 用于对比的检查点基于 GPTQ，采用通用目的校准集（neuralmagic/LLM_compression_calibration），而非推理数据。在推理任务上评估这些检查点，容易把校准领域不匹配误认为是精度损失，而单次运行无法将两者区分开来。因此，本文的 4‑bit 臂默认使用 AWQ 而非 GPTQ；Liu 等人也基于同样的理由给出了相同的建议。

即使为了比较而运行 GPTQ 臂，结果表也会披露每个检查点的校准集。校准领域对照（同精度、通用文本校准 vs. 推理校准）会与其并行运行，而不是被当作纯粹的精度效应来解读。

污染。 GSM8K 和 HumanEval 在 Llama 系列训练数据中存在已知或疑似的污染。这对绝对分数是真实的限制，但不会在此比较中产生混淆。所比较的每个精度水平都源自同一基础检查点的量化，因此污染在此设定指定的所有臂中保持恒定，包括 FP16、FP8、INT8、GPTQ/AWQ 4‑bit、GGUF Q4_K_M 和 GGUF Q3_K_M，无论这些臂是否最终被测量。它会使所有数字均等增加，而不会偏向某一精度，这正是量化增益所衡量的内容。

确定性与抽样设计。 在实践中，温度为 0 的贪婪解码并非真正的确定性：常见的推理内核（RMSNorm、matmul、attention）缺乏批次不变性，因此请求的输出可能取决于服务器在运行时的批次组成，而这会随并发负载变化。一种办法是固定批次组成或使用批次不变的内核，参考 Thinking Machines Lab 的《Defeating Nondeterminism in LLM Inference》（2025 年 9 月），并保留贪婪解码以利用其在精确匹配任务上的简便性。另一种方法是 Liu 等人所采用的生产典型抽样（温度 0.6，top‑p 0.95），使用多个种子，对每个臂报告均值和标准差，而不是单一数字。使用种子进行抽样可以完全规避批次不变性问题，并且与生产环境中的工作负载运行方式一致。

这也使得这里的数字能够直接与该领域最强的现有论文相比较：Liu 等人的 AIME-120 标准差在 120 项基准上介于 0.5 到 5.5 分之间，这本身表明，在困难的推理任务上，若不引入方差带，微小的差距无论如何样本大小都无法被区分。这里的选择采用了混合方案，而不是对所有任务使用单一策略。分类、结构化抽取和代码生成采用温度 0 的贪婪解码，单次运行，并为每个臂固定并发度。输出较短（20–400 token），通过精确匹配或执行来评分；批次不变性漂移需要较长的生成才能累积，而在该长度下并不会显现，因此固定并发度可以覆盖剩余部分。

摘要生成、多步数学以及长代理工具使用采用温度 0.6、top-p 0.95，三个种子，以均值和标准差报告，这与 Liu 等人的自身协议一致：长依赖链是批次不变性漂移累积的场所，也是期望的差距足够小以至于需要方差带的地方。这种划分彻底消除了对批次不变内核的需求，因为原本需要贪婪确定性才能发挥作用的任务如今都改为采样运行。种子会在每次运行时记录，并与其余套件输出一起发布在 量化精度尺度。在推理任务上，任意两臂之间的差异若小于该任务报告的标准差，则不算作发现，也不予报告。实际上，我目前对数学/逻辑测量（GSM8K 和 MATH-500）均采用了贪婪解码、单次通过，而不是执行这里所述的三种子策略。

统计检验。 在配对二元任务上的逐项结果（精确匹配正确/错误，相同条目，两个精度级别）采用 McNemar 检验进行比较，而非直接使用准确率百分比差异。当某项声明跨越多个基准或任务类型时，应用多重比较校正（Bonferroni/Holm 或 Benjamini-Hochberg FDR），而非直接将每个配对差值视为成立。在评估集足够小以至于结果可能为噪声的任何比较中，应依照 Miller（Anthropic）《为评估添加误差棒》（arXiv:2411.00640）的框架，报告置信区间以及该样本量下的最小可检测效应。未能超过自身置信区间的质量差距不予作为发现报告。

并行性能测量

本文中每个精度级别的每一次质量运行均同时针对以下内容进行测量：

• 通过 nvidia-smi 测量显存占用
• 每秒处理的 token 数（包括 prefill、decode 以及用于成本比较的总计）
• 首 token 时间（TTFT）
• 在固定延迟目标下可实现的最大批次大小

在同一 GPU Droplet 上进行测量，因为降低精度的实际收益往往是“模型现在可以放在一张 GPU 上而不是两张”或“批量大小翻倍”，而不仅仅是原始的每秒 token 数。每项任务的成本是通过测得的吞吐量，使用来自 专用 GPU 上不同流量特征的 Token 经济学 中的有效每百万 token 成本公式得出的；此处引用该公式，未重新推导。

effective_cpm = (hourly_rate ÷ (peak_tps × 3600 × utilization)) × 1,000,000

TTFT 和 TPOT 的定义与 LLM 推理基准测试：衡量真正重要的指标 完全相同，因此这里的数字与 DO 基准内容其他部分保持内部一致，而不是为同一指标引入第二种定义。

测试框架

我在本文中于 2026 年 8 月 12 日至 14 日进行了 H200 的测量；设定上述 0.30pp 下限的两次 INT8 可重复性测试均在 2026 年 8 月 12 日完成。我为本文构建的异步基准测试框架延续了 Ornith 9B 微调：成本、延迟、服务开销 的模式，包括其并发处理和预热排除。该文揭示了 CUDA 图首次命中 TTFT 的伪影：服务器启动后的第一个请求会产生一次性图编译惩罚，若未将其排除在预热窗口之外，则会导致 TTFT 被人为抬高。出于同样的原因，我也排除了相同的预热窗口。

以下是代表性命令，而非完整运行日志：

按臂部署已发布的检查点：请勿在内部进行量化。 只有当此处的数字是对 RedHatAI 发布结果的实际复现时，上面的校准混淆注释才成立；因此我完全匹配了他们的检查点和校准集，而不是在同一标签下使用不同的校准数据重新量化。这也避免了为量化一个 70B 模型而耗费 GPU 小时。每个臂会拉取一个特定的版本化检查点：

# BF16 baseline: downloaded for reference. This harness's BF16 quality baseline
# ran on a single MI325X instead of H200 (see Results); it's the only checkpoint
# that would need two GPUs if served on H200, since it doesn't fit on one.
hf download meta-llama/Llama-3.3-70B-Instruct \
  --local-dir ./checkpoints/bf16

# FP8-dynamic, INT8 W8A8, INT4 W4A16: RedHatAI's published quantized checkpoints,
# record the exact revision SHA per arm in the results table, not just the repo name
hf download RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic \
  --local-dir ./checkpoints/fp8-dynamic
hf download RedHatAI/Llama-3.3-70B-Instruct-quantized.w8a8 \
  --local-dir ./checkpoints/int8-w8a8
hf download RedHatAI/Llama-3.3-70B-Instruct-quantized.w4a16 \
  --local-dir ./checkpoints/int4-w4a16

# Published AWQ checkpoint for the calibration-control comparison (see calibration-confound note above)
hf download lambdalabs/Llama-3.3-70B-Instruct-AWQ-4bit \
  --revision bc074e680d3729a86dc7fe901572ac1e0c73542a \
  --local-dir ./checkpoints/awq-4bit

# Published GGUF, including a sub-4-bit arm: bartowski's imatrix-calibrated quants
hf download bartowski/Llama-3.3-70B-Instruct-GGUF \
  --include "*Q4_K_M*" --local-dir ./checkpoints/gguf-q4km
hf download bartowski/Llama-3.3-70B-Instruct-GGUF \
  --include "*Q3_K_M*" --local-dir ./checkpoints/gguf-q3km

RedHatAI 的该模型公开目录基于 GPTQ，于是我从另一位维护者处获取了 70B AWQ 分支：lambdalabs/Llama-3.3-70B-Instruct-AWQ-4bit，修订版 bc074e680d3729a86dc7fe901572ac1e0c73542a，这是一个只包含一次提交的仓库。公开的量化配置是 {"zero_point": true, "q_group_size": 128, "w_bit": 4, "version": "GEMM"}。模型卡片未说明校准数据集；这里记为未指定，假设使用 AutoAWQ 的默认值。这正是 70B AWQ 检查点。两个 3B AWQ 分支使用完全不同的仓库，分别是 casperhansen/llama-3.2-3b-instruct-awq 和 RichardErkhov/meta-llama_-_Llama-3.2-3B-Instruct-awq，正如在结果出现的地方所述。

在单 GPU Droplet 上按端口区分的串行服务 DigitalOcean 的 H200 Droplet 仅提供单 GPU 或 8 GPU 配置，没有 2 GPU 选项。这对 BF16 来说是一个实际限制：llama3.3-70b-instruct 在 BF16 下仅权重就需要约 141 GB，单张 141 GB 的 H200 显卡已无剩余空间容纳 KV 缓存。在 H200 上运行 BF16 至少需要跨两个 GPU 的张量并行，而能提供两个 GPU 的最小 Droplet 是 8 GPU 机箱（决策框架的成本部分会详细说明这会产生什么费用）。我从未在 H200 上以该配置或其他任何方式运行 BF16：我在结果部分改用单张 MI325X 运行了 BF16 质量基线，每张 GPU 拥有 256 GB 显存，足以在不使用张量并行的情况下容纳 BF16。

我在每个 H200 分支上运行了 FP8-dynamic、INT8 W8A8、INT4 W4A16 以及 AWQ 校准控制分支，每次都使用单独的单 GPU H200 Droplet，一次只跑一个分支，整个过程中使用 --tensor-parallel-size 1。这些分支通过端口区分，而非 GPU 索引：INT8 在 8002 端口，W4A16 在 8003 端口，AWQ 在 8004 端口，依此类推（下文 FP8 的服务命令使用 8001 端口）。在该 harness 的日志中根本不出现 CUDA_VISIBLE_DEVICES，因为每个 Droplet 永远只有一个 GPU 可供选择；两份存档中的所有环境捕获均显示恰好一个 GPU（0, NVIDIA H200, 143771 MiB）。

这相比真正共享的 GPU 固定机箱提供的硬件隔离较弱：这些分支在不同时间运行，可能位于同一 SKU 的不同物理 Droplet 上，而非在完全相同的硅片、相同功耗和热条件下同时并排运行。这也更易于配置，正是我所采用的方式，因此在下面的数据中无需考虑共享机箱的 PCIe 或 NUMA 争用，因为根本不存在共享机箱。

值得一提的是，操作员可能采取的另一种方案，虽然我并未将其作为一个臂（arm）采用：AMD 的 MI300X 拥有 192 GB 内存，足以在单个 GPU 上以按需 $2.59/hr 的价格容纳 BF16 llama3.3-70b-instruct，这完全规避了 H200 两 GPU 最小数量的问题。这里没有使用它，因为 ROCm 是与我构建此测试架构所依赖的 CUDA 工具链不同的软件栈，将其混入会破坏本实验其余部分所依赖的相同驱动、相同工具链的隔离。

为每种精度提供服务并针对其运行评估阶梯。 主要的质量和吞吐量扫 sweep 在 --max-model-len 8192 下运行，这个上下文长度反映了典型的服务场景，而不是受 KV 缓存限制的边界情况。32768 的设置专门用于 Interaction Effects 部分的上下文长度探测，此时上下文是被测变量，而不是批量大小的意外约束。每个 serve 命令会为每个 arm 设置一个不同的 --served-model-name（如 llama3.3-70b-instruct-bf16、-fp8、-int8、-w4a16 等），而不是使用一个共享名称。如果在各 arm 之间使用共享名称，评估命令将完全相同，但同时也意味着端口/输出路径的错误会写出一个看似合理却标签错误的结果，而负载中没有任何内容可以捕捉到这一点。为每个 arm 使用不同名称意味着端口不匹配会立即以 model-not-found 失败，而不是静默成功：我们优先考虑 loudly 失败，而不是保持命令相同。

下面未展示 BF16：在此测试架构中，它从未在 H200 上运行过，无论是双 GPU 张量并行配置还是其他任何配置，因此这里没有可重现的 serve 命令。在 8-GPU 机箱上使用 --tensor-parallel-size 2 命令才是在 H200 上服务 BF16 所需的，但如果将该命令作为此配方的一部分呈现，会暗示我曾经运行过它，而实际上我并未运行。

# Every H200 arm ran on its own single-GPU Droplet, one at a time, port-differentiated.
# No CUDA_VISIBLE_DEVICES: each Droplet exposes exactly one GPU (device 0). vLLM
# infers the quantization method from the checkpoint's quantization_config, no
# --quantization flag needed, and none of these load the full BF16 weights first.
# Ports: FP8 8001, INT8 8002, W4A16 8003, AWQ 8004.
vllm serve ./checkpoints/fp8-dynamic \
  --served-model-name llama3.3-70b-instruct-fp8 \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --seed 42 \
  --host 0.0.0.0 --port 8001

成功加载会打印出 vLLM 选择的量化内核以及上述 VRAM 表所依赖的权重加载行。下面的代码块展示了该输出的形状（使用占位符值），它仅用来说明应捕获的格式，而非本次运行的实际测量结果：

Output
INFO [fp8.py] Using Fp8LinearMethod for FP8 W8A8 quantization.
INFO [model_runner.py] Loading model weights took [X] GB
INFO [worker.py] Memory profiling results: total_gpu_memory=[X] GiB initial_memory_usage=[X] GiB peak_torch_memory=[X] GiB kv_cache_size=[X] GiB gpu_memory_utilization=0.90
INFO [gpu_executor.py] # GPU blocks: [X], # CPU blocks: [X]
INFO:     Started server process [pid]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)

记录您在每个 arm 上运行时的 Loading model weights took [X] GB 行和 kv_cache_size 行；这两个数字就是下面性能回报表中 VRAM 足迹列的来源。

# lm-evaluation-harness against the served endpoint. Port, model name, and output
# path all change per arm and must move together; get any one wrong and the
# command fails with model-not-found instead of scoring the wrong checkpoint.
lm_eval --model local-completions \
  --model_args base_url=http://localhost:8001/v1/completions,model=llama3.3-70b-instruct-fp8 \
  --tasks gsm8k \
  --output_path ./results/fp8/gsm8k

lm_eval 在评分结束后会同时打印两个过滤器。请为每个臂报告两列；在比较不同模型规模时不要丢弃 flexible-extract：

Output
|Tasks|Version|Filter           |n-shot|Metric     |Value |  |Stderr|
|-----|------:|-----------------|-----:|-----------|-----:|--|-----:|
|gsm8k|      3|flexible-extract|     8|exact_match|0.7938|± |0.0111|
|     |       |strict-match    |     8|exact_match|0.7763|± |0.0115|

在每次运行时同时测量 VRAM。

nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 5

nvidia-smi 会先输出一个 CSV 头部，然后每个轮询间隔输出一行。下面是典型 H200 GPU 显存大小下的示例形状，仅作示意：

Output
memory.used [MiB], memory.total [MiB]
71232 MiB, 143771 MiB

I 为每次运行固定了版本、配置、种子和采样参数，并将它们发布在 量化精度尺度，旁边还有 harness 脚本、serve 日志以及每个样本的评估结果。vLLM 的当前稳定版本是 0.27.0（2026 年 8 月 10 日）；请锁定此版本或更高版本。AutoAWQ 和 AutoGPTQ 均已在 2025 年归档且不再维护：请使用 vLLM 的 llm-compressor 进行 AWQ/FP8 量化，以及使用 GPTQModel（维护中的继任者，截至 2026 年 7 月为 v7.3.1）进行 GPTQ 量化。这与 RedHatAI 用来生成这些结果所对齐检查点的工具链相匹配。我在一个自报为 0.1.0-dev 的 llama.cpp 构建（提交 84e908c）上运行了 GGUF 分支。llama.cpp 使用滚动构建标签而非语义版本，因此用于复现的标识是提交哈希，而不是构建字符串。

在花费 70B 预算之前，先在玩具模型上验证管道。 在小模型上先跑两种精度的完整端到端链（下载、服务、评估、VRAM 捕获、结果路径、不同的服务名称），比如在 RTX 4000 Ada 上的 Llama 3.2 3B，成本为每小时 0.76 美元。此方法部分纠正的每个命令级别的错误（错误端口、错误服务名称、错误上下文长度）在这里只需几美元就会显现。否则，这些错误会在运行 70B 模型时才暴露出来——每小时成本显著更高，且故障显现时间更长。不要为了省时间而跳过这一步；这是此实验中最便宜的保险。

捕获此试运行的实际 vllm serve 启动日志和实际的 nvidia-smi 输出，并按原样粘贴以替换本节前面的重建占位符输出块；这些占位符仅用于在真实数字出现之前展示输出的形状。

已测量的 GSM8K（严格匹配和灵活提取）

所有数值均为在完整1,319项GSM8K测试集（8-shot，贪心解码）上的exact_match。除非另有说明，H200量化及小模型分支均来自Session 2至3测试框架（CUDA，vLLM 0.27.1）。Stderr为同一指标上lm-eval的自助法标准误。请阅读两个过滤器上的量化差异，并将低于0.30个百分点可复现性下限（见方法论）的任何差距视为无意义。

Llama 3.3 70B Instruct：

我在 在 ROCm 下的 MI325X 使用 vLLM 0.23.1.dev1 和 lm_eval 0.4.12（完整 1,319 条，8-shot，贪婪）下测量了 BF16，并在 在 CUDA 下的 H200 使用 vLLM 0.27.1 上运行了量化分支。准确度在不同厂商之间被视为可比；吞吐量则不然，且未进行跨厂商吞吐量比较。INT8 与 BF16 的严格指标完全相同（92.04%），这是在可重复性下限上的巧合：会话 1 在相同的 H200 检查点上运行 INT8 得到 92.34% 的严格指标（results/.../results_2026-08-12T15-03-51.422301.json）；会话 2 得到 92.04%（results2/.../results_2026-08-12T22-16-40.899161.json）。会话 3 未重新运行 70B INT8。此表中的 GGUF Q4_K_M 也跨越了引擎：它通过 llama.cpp 服务，而不是 vLLM；llama.cpp 与 vLLM 在采样器实现和 RoPE 处理上有所不同，因此其在此表中其他行上的准确度差异并非纯粹的量化效应。

Llama 3.1 8B Instruct（BF16 在 :8014 上单独测量；量化分支来自过夜并发批次，受下面的争用控制许可：跨进程 GPU 负载变化仅影响墙钟时间，不影响贪婪输出）：

W4A16 在 8B 时的下降是能力问题，而非格式问题。 在这些表格中，除了 W4A16 之外的所有其他方案在所有规模上，灵活提取减去严格匹配的得分提升在 +1.1 到 +2.5 点之间：放宽提取过滤器可以恢复那些正确但格式错误的条目，这正是该过滤器的目的。在 8B 时，W4A16 从这种放宽中几乎没有恢复任何内容（+0.08 点），而其相对于 BF16 基准的灵活提取增益（-8.42 points）比其严格匹配增益（-6.75 points）更差。格式解释预测了相反的结果：放宽过滤器应当缩小差距。但实际上并未如此，因此此方案产生的是错误答案，而不仅仅是格式不佳的正确答案。如果你在自己的运行中看到类似的下降，那么灵活提取与严格匹配的对比就是你应该使用的诊断方法。

Llama 3.2 3B Instruct:

我在 3B 上两次运行 BF16，一次单独运行，一次在与量化方案相同的过夜并发批次中运行，以测试跨进程 GPU 竞争是否会改变贪婪输出，而不仅仅影响墙钟时间。两次运行在全部 1,319 条条目上完全一致，没有不一致，尽管墙钟时间相差 2.8 倍（并发 1,112秒 对比 单独 393秒）；上面的单个 BF16 行同时涵盖了这两种情况。

机制：每个 vLLM 服务器实例都有自己的请求调度器，因此跨进程竞争会争夺 GPU 计算周期，但在同一服务器内不会争夺批次槽。到达该服务器的请求序列在单独运行和并发运行之间是完全相同的，因此它形成的批次也是相同的，因而贪婪输出也是相同的；竞争仅影响墙钟时间。这不仅是一个观察到的容忍度，而是一种机制，正是它授权了此测试套件中的所有并发准确率测量，包括上面的 8B 量化分支。这也意味着您可以以同样的方式批处理自己的准确率测试，而不会破坏贪婪输出。

我运行了第六个 3B 分支，并从此表中移除它：来自 richarderkhov 检查点的 AWQ 在两个过滤器上均得分恰好为 0.00%，即在 1,319 个样本中答对 0 题。这不是一个退化衡量。一个真正损坏的 4 位模型仍然有可能在 GSM8K 上答对一些题目；在所有题目上得分恰好为零意味着根本没有输出任何可解析的内容，这表明是检查点损坏、聊天模板错误或分词器不匹配，而不是量化效果。在此保留计算中未使用它。（校准注释，针对所使用的分支：casperhansen 的卡片未给出校准集；richarderkhov 的卡片给出 WikiText-2，共 128 条序列，每条 2048 个标记。）

70B 平坦网格是否真实？配对显著性检验

我使用 McNemar 的精确二项检验对配对的逐项结果进行了重新测试，因为保留百分比是一个平均值，无法判断差距是真实存在还是噪声。每个量化分支都在相同的 1,319 个样本上与其自身规模的 BF16 基线进行比较，并在所有十一次比较上进行 Holm 校正。

在十一项比较中，有两项达到显著性，且两者均为低于 70B 的 4‑bit 权重仅量化。如果你只从这张表中取一个数字，就取这个：你所管理的风险是低于 70B 的 4‑bit 量化，而非量化本身。

70B 网格经受住了检验。 所有五个 70B 臂均不显著，Holm 调整后 p 值为 1.000. 不一致计数显示了机制：AWQ 的 -0.91% 来源于 112 个不一致项中丢失 62 项、获得 50 项，这在 1,319 项集合上接近抛硬币的行为。这不是方向性信号。

配对检验相比直接比较准确率百分比更敏感，但在 70B 处仍未发现任何显著差异。 以项目难度为条件（而非对其求平均）比原始百分点差距更具检验力，这排除了“评估缺乏检测能力”的质疑：在 70B 上采用了更敏感的检验，所有单臂均返回空结果。

应同时报告不一致的两个单元格，而不仅仅是损失。 在 70B 处，量化将项目翻转为正确的频率与翻转为错误的频率相当；仅报告损失会夸大损害。INT8 是一个清晰的示例：丢失 38 项，获得 38 项，净变化为零。在将任何 delta 解释为损害之前，值得在你自己的不一致计数上运行同样的对称性检查。

尺度依赖：低于 70B 时 4‑bit 会失效，8‑bit 不会

在上面表格中的每个规模，8‑bit 是干净的：FP8 和 INT8 在所有地方都与基线相差在 1.6 个百分点以内，而在 3B 两者都略高于基线。断点仅出现在 4‑bit 且仅低于 70B。如果你的部署低于 70B，这是证据行，表明在量化到 4‑bit 前应先进行验证。

GSM8K 严格匹配增量随模型大小与 BF16 的对比。空心标记表示不显著；实心标记表示显著（Holm 校正）。AWQ 和 W4A16 在不同规模下是不同的检查点，这是因为并非每种方法在每种规模下都有公开的检查点。

以下两点适用于此比较，且均非可选：

4 位方法在不同规模下并不相同。 70B 规模下可用的检查点同时包含 AWQ 和 W4A16；8B 仅有 W4A16；3B 仅有 AWQ，这是因为 RedHatAI/Llama-3.2-3B-Instruct-quantized.w4a16 不存在。上述曲线混合了不同方法，而不是进行一次受控的扫描。由于两种方法在 70B 处结果一致，这成为信任曲线方向的依据，尽管方法随规模而变化。

规模混合了不同代的 Llama。 3.2-3B、3.1-8B 和 3.3-70B 的检查点并不是同一模型的三种缩放方式：不存在 Llama 3.2 8B，且 RedHatAI 的 8B 量化检查点是基于 3.1 构建的。上述每个臂均相对于其同代的 BF16 基线进行测量，因此同规模内的比较成立，但跨规模曲线并非在单一模型族上的纯净缩放实验。

考虑到上述两点限制，此处独立复现了 Lee 等人的尺度主张，使用了两种不同的量化方法（AWQ 和基于 GPTQ 的 W4A16），它们指向同一方向。在将其迁移到自己的模型族时，应信任曲线的方向而非确切的增量。

测量的 MATH-500：同一层级上的更难任务

上述所有测量均基于 GSM8K，推理步骤为两到八步，这是 Introduction 中所提及的 AIME 与 GSM8K 对比中的较易一侧。我将 MATH-500 作为同一层级上的更难的双胞胎加入。MATH-500 测试的是上述尺度依赖章节中发现的在 70B 以下就会失效的同一 4 位开关，这次是在匹配模型规模下的更难任务上进行。结果部分验证了这一点，这属于诚实的解读，而非更强的断言。

与 GSM8K 的协议差异（射次数、采样和主要指标）已在上述实验设计部分中披露；若未设置，两个 harness 默认值会静默截断此任务，这一点已在 Harness 部分中标出。下方的头条数字以 math_verify 为主要指标，并同时报告 exact_match 作为格式检查。

Llama 3.1 8B Instruct：

McNemar 精确检验，在完全相同的样本上配对：delta -5.20pp，不一致项中有 62 项被 BF16 正确而 W4A16 错误，36 项相反，p = 0.0112。这一结果本身就达到显著水平，并且落在同一臂上——即之前在 GSM8K 族中已经是唯一显著的 8B 结果的 8B W4A16。如果你在 4-bit 精度下运行 8B 模型，那么现在有两个不同难度的任务都指向同一臂。

截断混淆因素已通过两种独立方式排除。 在 2,048 token 的提示+生成预算内（参见上面的 Harness 警告），某些臂上的 500 项中有 22 项达到该上限。如果这里真的是截断产物，那么我们应该怀疑上面的 delta 而不是把它当作发现来报告；因此我进行了检查，而不是直接假设它不存在。

首先，不一致项的组成：在 BF16 正确而 W4A16 错误的 62 项中，只有 8 项（12.9%）根本没有产生可解析的最终答案。其余 54 项给出了自信且可解析但只是错误的最终答案。

其次，干净子集：我将比较限制在两臂都产生可解析最终答案的 402 项上，这样就排除了任一臂可能因截断而受影响的每一项。

在移除所有受截断影响的项目后，delta 基本保持不变。两项独立检验得出相同结论，这才使得该发现具有可辩护性，而不仅仅是一种断言。在你信任自己可能受截断影响的结果上的 delta 之前，请先运行这两项检查。

Llama 3.3 70B Instruct：

BF16 在 MI325X 上测量（ROCm, vLLM 0.23.1.dev1），与上面的 GSM8K 70B 表格使用相同的基准硬件；量化的臂在 H200 上运行（CUDA, vLLM 0.27.1）。准确性在供应商之间被视为可比较，基础同上面的 GSM8K 表格；未进行吞吐量比较。

没有一个量化臂达到显著性。在 GSM8K 上发现的平坦 70B 网格在更难的任务中仍然成立。 MATH-500 的基准水平为 65%，而非 92%，这为真实的量化效果留出了更大的空间，但在此样本规模下并未出现。对于您而言，这意味着 70B 的全部通过并不依赖于 GSM8K 过于简单以至于无法显示效果。

这是其自身的 Holm 家族，与上面的十一比较 GSM8K 家族独立：仅运行了三个 MATH-500 比较（70B FP8、70B W4A16、8B W4A16），而非完整的十一臂矩阵。我在此刻意跳过了五个臂：8B INT8、8B FP8、70B INT8、70B AWQ 和 70B GGUF Q4_K_M。GSM8K 已经在所有测试规模上展示了 8 位无误，并且两种 4 位方法在 70B 时相互收敛，相差仅 0.7 个百分点。我将 MATH-500 的范围聚焦在深度问题上：更难的任务是否会扩大 GSM8K 较简单项目可能掩盖的差距？这比在第二难度级别重复完整网格的问题范围更窄。

不可解析的最终结果在每个臂上均保持稳定，这表明问题出在任务的模板上，而不是模型退化。不可解析最终的计数在所有测试的臂上从 49 到 73（共 500），在所有规模和精度下均如此，包括 70B BF16 基线自身的 60。这种稳定性表明，大多数失败是由于撞到了 Minerva 刚性的 “Final Answer: The final answer is X. I hope it is correct.” 模板，而不是模型在精度下降时输出结构的退化。这也意味着该指标部分地在测量模板遵从性，同时也测量数学能力，这是任务本身的局限，而不是某个特定臂的问题。在您自行运行时查看不可解析最终计数之前，请牢记这一点，以免将其误认为是模型退化。

深度依赖，与 Liu 等人的发现相一致

Liu 等人报告在堆叠 4 位配置下，AIME-120 相比 GSM8K 有大约 4 倍的放大。本文的比较范围更窄（单个 4 位调节，GSM8K 相比 MATH-500），并且它发现的效果大小取决于所使用的基础，因此给出了两个基础的数据，而不是挑选一个以突出效果。

在更难的任务上，绝对点损失实际上更小，而不是更大。相对损失（即该增量占基线的比例）更大，大约是 1.3x 到 1.5x，这取决于使用完整的 500 项还是清理后的 402 项作为分母。这两个相对数字使用了不同的项目集和不同的分母；它们不应被混合在一起或在未说明使用哪一个的情况下被引用。

诚实的读法：损伤显然随规模变化，而在此难度范围内仅弱随深度变化。 从 GSM8K 到 MATH-500 的难度跃升是真实的，但远不及 GSM8K 到 AIME-120 的跨度，因此这既不能证实也不能否定 Liu 等人在其难度范围内的结论；它检验的是一个更接近、更典型的生产场景。它所显示的，是引言中提出的累积机制在生产工作负载更可能遇到的难度水平下并不能直接再现。

在该范围内，模型规模对损伤的预测能力远强于任务深度：相同的 W4A16 调节在 MATH-500 上的 70B 模型最多仅花费 1.40 分（不显著），而在 GSM8K 上的 8B 模型则花费 6.75 分（显著）。这一规模差距远大于上文测得的 1.3x 到 1.5x 的深度效应。这表明：在此范围内，深度的影响不如规模大，因此在评估任务难度之前，请先检查模型规模。

本文测量了什么，以及未测量的内容

我以完全的统计严谨性运行了任务阶梯的六个阶梯中的一个，在两个难度级别上：多步数学和逻辑。GSM8K（70B、8B、3B，均采用配对 McNemar 显著性检验）位于上文的“已测 GSM8K”以及“70B 平坦网格是否真实”章节中；MATH-500（70B、8B，带有其自身的 Holm 家族）位于上文的“已测 MATH-500”章节中；它们之间的规模与深度比较位于上文的“深度依赖”章节中。分类/标注、结构化抽取、摘要、代码生成以及长期 agentic 工具使用未被运行，原因如前文“任务阶梯”章节所述：每项任务都需要评估基础设施（手工构建的题集、评判打分或 agentic 线束布线），而我并未构建这些设施。没有任务类型与精度的网格来替代这五个未运行的阶梯。一个有五行空白的表格会显得未完成；此部分的诚实版本就是上面的范围声明。这不是一个带括号的占位符。

超越保留百分比的故障剖析

保留率百分比表明推理任务变差了，但未说明链条在哪里断裂。本文将此视为独立的分析：通过标注的失败转录，展示量化模型的思维链在哪个确切 token 或步骤偏离了 BF16 基准，以及这种偏离是早期步骤的算数失误还是晚期步骤的逻辑漂移。我在此未进行该分析。每个 GSM8K 和 MATH-500 分支的逐项样本文件已归档，因此基于现有资料可以进行该分析；只是尚未执行。

GGUF 的细微差别

从业者常把“4-bit”视为一种设置。但在本文测量的多步数学/逻辑阶梯上，情况并非如此：GGUF Q4_K_M（91.96%）、基于 GPTQ 的 W4A16（91.58%）和 AWQ（91.13%）是在同名位宽下的三种不同方案。在这套测具的 0.30pp 可再现性底线之外，这三者彼此之间以及相对于 BF16 均没有显著差异，上文的 McNemar 检验已证实其对 BF16 无显著差异。GGUF 在此阶梯上略微获得最高的 4-bit 得分，这颠覆了这样的假设：混合每张量方案（模型部分在 Q6_K，部分在 Q4_K，如前文机制章节所述）相较于 GPTQ/AWQ 的固定宽度校准会牺牲质量。实际上在此阶梯、此规模下并非如此。如果你曾因质量顾虑而回避 GGUF，此阶梯不会给你继续回避的理由。

方案之间的差异是真实存在的，但根据这些证据，它表现为吞吐量的差距而非质量的差距：请参见下文的 Performance Payoff 小节，在同一批次大小、同一 GPU 上，GGUF 的并发模型相较于 FP8 产生了 7.4 倍的 tok/s 差异。其余任务阶梯的其他阶段仍然悬而未决；此比较仅在 GSM8K 上得到确认。

性能收益，伴随每个质量指标

Hardware isolation. I ran every H200 arm, FP8, INT8, AWQ, and W4A16, on its own single-GPU H200 Droplet, one arm at a time, --tensor-parallel-size 1 throughout, differentiated by port instead of GPU index (see the Harness section above). That’s identical silicon, driver, and toolchain across arms, but serial instead of simultaneous: arms ran at different times, possibly on different physical Droplets of the same SKU, not side by side on a shared chassis. I never served BF16 on H200; its quality baseline ran on a single MI325X instead (Measured GSM8K and Measured MATH-500 above). Its row below is a stated limitation for that reason. It isn’t a pending measurement. If a quantized arm is re-run on H100 for the single-GPU-fit story, that’s reported as a separate comparison.

VRAM footprint here is derived, not a raw nvidia-smi reading: it’s the weight-loading line plus the KV cache the server reserved at --gpu-memory-utilization 0.90 on a 140.4 GiB card, per the two serve-log lines the methodology section says to capture, and it is not the same measurement as the weight-only footprints cited in the FAQ. BF16’s row is a stated limitation, not a pending number, for the reason given above: no BF16-on-H200 run exists to measure, in a two-GPU configuration or any other, and reproducing one would mean provisioning the pricier 8-GPU chassis to use just two of its GPUs, which was outside the scope here. INT8’s VRAM footprint closes from the same serve log every other arm uses: 67.72 GiB of weights plus 55.0 GiB of reserved KV cache.

Its throughput cell doesn’t: INT8 was quality-tested at every model size (Measured GSM8K and Measured MATH-500 above), but its saturated-throughput sweep never ran, because I scoped the throughput sweeps to the arms bracketing the FP8-versus-4-bit crossover (FP8, AWQ, W4A16), and INT8 sits outside that comparison.

此表最初还有两列：固定 P95 TTFT 目标下的最大批次大小以及每百万 token 的成本，且每个单元格都有占位符。某列在所有行中均无数据并不是待办工作，而是本实验未覆盖的维度，因此我直接删除了这两列，而不是留下一堆空括号。我并未在延迟目标下测量最大批次大小或每 token 成本，因为我在吞吐量扫描中记录了固定并发级别下的聚合输出 tok/s，而不是受延迟限制的容量；而每 token 成本需要本实验未确定的利用率假设。决策框架的成本部分仍保留着成本公式和固定的 H200 速率；消失的是声称从此表中计算出每臂每百万 token 成本的说法。

此处直接测量了 FP8 与 4-bit 权重仅量化之间的交叉点。 输出 tok/s，70B，vLLM 臂，提示按并发级别缩放（输入 1024，输出 1024，启用 CUDA 图）：

输出 tok/s，70B，单张 H200，vLLM。4-bit 仅在 c=32 时获胜；在 c=64 和 c=128 时，FP8 领先 13% 到 28%。从 c=64 开始，两个 4-bit 臂的结果相互收敛，误差在 0.7% 以内。

此表支持以下三个发现：

• 交叉点位于 c=32 和 c=64 之间，且不在低并发情况下出现。 4‑bit 仅在 c=32 时胜出（AWQ 达到 FP8 的 106.2%，W4A16 达到 103.9%）。在此之后，FP8 的领先并非平坦：在 c=64 时大约领先 28%（超过 AWQ 28.1%，超过 W4A16 28.2%），在 c=128 时收窄至 13‑14%（超过 AWQ 13.8%，超过 W4A16 13.0%）。两条 4‑bit 曲线在两个并发水平上紧密追随，这进一步验证了下文的收敛结论。从 c=32 到 c=64 的缩放步骤是机制的证据：FP8 提升 73.4%，而两条 4‑bit 曲线在此同一步骤中仅提升 27‑30%。这是因为 FP8 的 W8A8 张量核路径在 GEMM 变为计算受限时拉开差距，而 W4A16 和 AWQ 则均需反量化到 FP16 并运行相对较慢的内核。
• 在 c=1 时 4‑bit 失败，这与常见的单流声明相矛盾。 通常认为权重仅 4‑bit 在单流场景下优势最大，因为解码是内存受限的。实际测试结果却不是这样：FP8 为 46.42 tok/s，AWQ 为 46.21 tok/s，W4A16 为 43.50 tok/s。在 batch=1 时，反量化处于关键路径且没有其他批次可用来摊销，这抵消了 4‑bit 本应具备的内存流量优势。其实际适用范围是中等批次，而非低批次。
• 随着并发增加，两条 4‑bit 曲线趋于收敛：在 c=64 时相差 0.0%，在 c=128 时相差 0.7%，在 c=256 时相差 0.6%。 虽然它们由不同的维护者负责，采用不同的算法（AWQ 采用激活感知校准，而 W4A16 基于 GPTQ），并且使用不同的校准集合。它们在 c=1 时大约相差 6%，随后趋于一致。这种收敛表明上述 4‑bit 上限是架构层面的特征：两种方法共享的反量化然后 FP16 GEMM 路径，而非某一方实现的副产物。这就为把 “4‑bit 权重仅” 视为一个吞吐量类别提供了依据，而不是两个无关的数字。

对你而言，实际的建议是：在决定使用 FP8 还是 4‑bit 之前，先确定你的生产并发所在的位置，因为胜者会在单个部署可能覆盖的范围内翻转。

并发上限由 KV 算术预测得出，而不仅仅是观察到的。 以下是 140.4 GiB 显卡在 0.90 利用率下的服务日志：

在约 2048-token 上下文中的最大并发序列数。公式（可用 KV 内存除以每请求 KV 成本）在所有三个方案上将测量的上限预测在 1.5% 到 5.6% 的范围内。

KV 算术得到的预测与实际测量值的误差在 1.5% 到 5.6% 之间，足以让我们把上限表述为一个公式（在给定序列长度下，可用 KV 内存除以每请求 KV 成本），而不仅仅是事后观察到的现象。这也解释了上面表格中 c=256 行的情况：在此并发水平下，所有方案已经超过了各自的上限，因此吞吐量会下降而不是继续上升。你可以在进行任何扫描之前，先从自己的服务日志中运行同样的算术。

在 c=256 时，4‑bit 方案能够承载更多流量。代价体现在尾部延迟上，而平均延迟却未受影响。

4‑bit 方案的 KV 池更大，能够容纳更多并发请求，因此平均等待时间降低（44‑46秒，而 FP8 为 74秒），但尾部延迟激增至约 145秒，相比之下 FP8 为 98秒。FP8 在过载时会平稳降级；而 4‑bit 方案则会出现厚尾降级。如果你采用 P99 延迟 SLO 而非平均延迟目标，那么哪种精度在过载时更安全就会反过来，尽管在此并发级别下 4‑bit 方案仍然在原始可接受吞吐量上占优。

GGUF 的吞吐量在单独的表格中。它不是上面表格的额外列。 GGUF 通过 llama.cpp 提供服务，这是一个与 vLLM 批处理成熟度不同的独立引擎：将 llama.cpp 的 tok/s 数字放在与 vLLM 数字同一列并不构成比较，而是在同一个单元格中回答了两个不同的问题。上面的 Measured GSM8K 表格中给出了 GGUF Q4_K_M 的准确率数字，它们可以与 vLLM 提供的方案进行公平的质量比较；GGUF 的吞吐量不应放在 vLLM 的吞吐量旁边。在准确率方面还需注意：llama.cpp 与 vLLM 在采样器实现和 RoPE 处理上存在差异，因此该表格中 GGUF 行与 vLLM 提供方案行之间的小幅交叉引擎准确率差异并非纯粹由量化效果造成。

Q4_K_M 的 VRAM 足迹未被捕获，也不是因为没有尝试：服务日志（05-serve-gguf-q4km-s3.log）记录了 n_slots = 8 和 n_ctx_slot = 8192，但没有 weight-buffer 行，因而无法像 vLLM 臂的日志那样推导出足迹。该日志仅包含的内存数字是 prompt-cache 驱逐大小，它们衡量的是缓存抖动，而不是权重足迹。之前的一次会话确实捕获到了一个数字，43,357 MiB，但那是在每槽 1,024 的上下文配置下得到的；该数字与上文报告准确度所使用的每槽 8,192 的配置不可比，因此我不在这里把它当作可比的数字报告。

我并未在质量或吞吐量方面对 Q3_K_M 进行服务或评估，尽管我在上文 Harness 部分下载了它 alongside Q4_K_M。这是一个已声明的限制。低于 4 位的吞吐量和质量运行是 Decision Framework 下方提出的 3 位悬崖问题的自然伴侣，并且在那里被命名为 open，而不是在这里暗示为进行中。

Q4_K_M 的吞吐量扫描：

从 c=8 开始的三个几乎相同的值，这是因为 --parallel 8 让 llama-server 拥有恰好 8 个槽；超过槽数的每个并发级别衡量的是客户端队列深度，而不是额外的服务器容量。出于这个原因，我在 c=32 之后截断了扫描：c=64 和 c=128 将需要大约额外六小时的 GPU 时间来再次得到两次相同的 87 token/秒。

值得进行的比较：在 c=16 时，FP8 在相同 GPU 上提供 645.51 token/秒，而 GGUF 提供 87.06 token/秒，相差 7.4 倍。原因在于 llama-server 的槽数和引擎设计，而非量化格式：GGUF 自身的质量数字（上文所示）与其他每种 4 位方案具有竞争力。将这一差距归因于 “GGUF 是一种慢速格式” 将是不准确的；正确的说法是，llama.cpp 的批处理成熟度在此槽配置下远落后于 vLLM 的，独立于检查点使用的每位权重的位数。

作为比较，社区基准测试表明，70B GGUF 在消费级 GPU 上大约只有 1 到 2 token/秒，这完全是另一类硬件。上文的 H200 数字就是这里的测量结果。它们并不是那个轶事的比较基准。

上面测量的每个质量增量都位于其所带来的收益旁边。纸上看来可以忽略不计的质量下降，也必须先通过此表的评估，才能抵消因切换精度而产生的运营开销。您最可能获得的回报是硬件适配（“只占一张卡而不是两张”）或能够容纳更多批次空间的并发上限。单纯的峰值 tok/s 列无法捕捉这一点。

预先承诺零结果

我在对任何臂进行评分之前，就已经预先承诺了如何报告空结果。引言部分修订后的论点预测，单调节结果（FP8、INT8 以及 GPTQ/AWQ 4‑bit）在 llama3.3-70b-instruct 上基本保持平坦。在多步数学/逻辑这一档次上，在两个难度级别进行测量时，结果在两个级别上都保持干净。在 GSM8K 上的每个单调节 70B 臂（INT8、FP8、W4A16、AWQ、GGUF Q4_K_M）相较于 BF16 均不显著，Holm 调整后的 p 值在所有五个情况下均为 1.000。在更难的 MATH-500 上测试的两个 70B 臂（FP8、W4A16）同样不显著。第二个、更难的任务不仅仅是复现了空结果，而且是在有更大容错空间的情况下做到的：MATH-500 的 70B 基准得分为 65%，而 GSM8K 的为 92%，这留下了更大的空间让真实的量化效果显现出来，但却没有任何效果出现。

这就是在该模型规模下，该推理基准上的单调节量化所被夸大的民间说法——实际上是在同一任务类型的两个难度级别上进行测量而得出的结论，而非假设。这尚未是整个梯队的结论，也不是我们在此所主张的：空结果仅在多步数学/逻辑上得到证实，且仅在两个难度级别。在上面的 Task Ladder 小节中，分类、提取、摘要、代码生成以及代理式工具使用被列为后续任务。它们并不是被假设为未经测试就能延续的空结果。

本文的决策框架是可引用的有效载荷。如果您来这里是为了做决定而不是阅读完整的方法论，那么它的轮廓如下：引言部分验证过的证据并不支持“在推理任务中保持全精度”。在相当规模的 70B 模型上，单拨盘 4‑bit 仅权重量化的代价是 0.8 个百分点，而 8‑bit 权重‑激活量化的代价是 0.1 个百分点（基于五项推理基准的平均值）。您需要牢记的警告比这更狭窄，并且它与任务类型所在的轴不同。

1. INT8 量化是否会损害生产 LLM 工作负载的准确性？

影响不大，因此您可以将 INT8 视为安全的默认选择，至少在此处的综合基准或多步数学测试中是这样。RedHatAI 发布的用于 llama3.3-70b-instruct 的 INT8 W8A8 检查点在 MMLU 上恢复了 BF16 精度的 99.5%，在 GSM8K 上恢复了 99.8%（8-shot CoT，严格匹配），这两者均在引言部分报告的恢复范围内。此处的测试套件证实，在所有测试的模型规模上，INT8 在 GSM8K 上相较于 BF16 的影响不显著（70B、8B、3B 均如此）（参见“70B 平坦网格是否真实”部分）。在此处未对 MATH-500 进行 INT8 测试，因为 GSM8K 已在所有规模上展示了其良好表现，而 MATH-500 的范围仅限于 4 位的深度问题（参见“测量的 MATH-500”部分）；分类、提取、摘要、代码生成以及长代理工具使用均未进行测试（参见“任务阶梯”部分）。

因此，如果您的工作负载是多步数学，那么这些结果已经适用于您；如果它属于那五种其他任务类型之一，则应将‘影响不大’视为对您的情况尚未验证，直至您亲自针对该工作负载运行阶梯测试。

2. 在生产环境中服务量化模型的最快方式是什么？

这取决于您的并发情况。服务速度取决于精度、服务栈和并发的综合作用，而不仅仅是精度。FP8 和 INT8 在支持 GPU tensor-core 的 vLLM 和 TensorRT-LLM 中原生运行。GPTQ 和 AWQ 4-bit 检查点通过 vLLM 运行（使用 llm-compressor 对 AWQ 进行量化，或使用 GPTQModel 对 GPTQ 进行量化；AutoAWQ 和 AutoGPTQ 已于 2025 年被存档且不再维护）。GGUF 是 llama.cpp 家族的路径，如果您在 CPU 或混合 CPU/GPU 上服务，而不是纯 GPU vLLM 部署，那么它是正确的选择。在相同的 70B 模型和相同的 H200 上，最快的单 vLLM 方案取决于并发：当并发达到 64 及以上时，FP8 表现最佳（峰值达 1703.90 tok/s，而 AWQ 为 1496.91 tok/s，W4A16 为 1508.14 tok/s）。在并发为 32 时，4-bit 权重仅量化的 AWQ 和 W4A16 暂时领先（AWQ 达到 951.60 tok/s，而 FP8 为 896.24 tok/s）。

FP8 在并发为 1 时也表现获胜，尽管民间智慧认为 4-bit 应该胜出。GGUF 则是另一个问题：在相同并发下，它比 FP8 慢 7.4 倍（87.06 tok/s 对比 645.51 tok/s，c=16），这并非由于量化格式本身慢，而是因为 llama-server 的槽位数量和批处理成熟度在测试配置下不及 vLLM（参见 Performance Payoff 小节）。因此，“最快”对于 vLLM 方案是取决于并发的答案，而对于 GGUF 则取决于引擎；在选择之前，请先了解您所处的服务 regime。

3. 在相同位宽下，GGUF 是否比 GPTQ 或 AWQ 更慢或质量更低？

它们是在相同名义位宽下的不同量化方案，而不仅仅是同一方法换了个名字；在此测量中，这两种差异并未出现在民间预期的位置，因此应在右轴上进行选择。在质量方面，它们没有分歧：GGUF Q4_K_M（91.96%）、基于 GPTQ 的 W4A16（91.58%）以及 AWQ（91.13%）均落在此套件在 GSM8K 上 70B 参数时的 0.30pp 可重复性底线之内，GGUF 在三者中略占优势（参见 GGUF Nuance 小节）。在吞吐量方面，它们则出现明显分歧：当 llama-server 的槽位数被饱和时，GGUF 会遇到 87.06 tok/s 的硬上限，而在同等并发下 FP8 达到 645.51 tok/s，相差约 7.4 倍。这一差距源于引擎和槽位数的行为，而非量化方案本身：在此规模下，GGUF 的混合每张量位宽不会牺牲质量，其吞吐量上限主要取决于 llama.cpp 的批处理成熟度相较于 vLLM。

如果您的部署仅使用 GPU 且吞吐量是关键，那么这个上限就是 GGUF 的一个实际限制，在相较于 GPTQ 或 AWQ 之前进行选择时应予以考虑。

4. 量化是否会对多步骤推理造成比简单任务更大的退化？

现有最强的证据来自一个相当的 70B 推理模型，表明不存在这样的问题，因此如果您仅凭民间说法来选择精度级别，可以将其视为非决定因素：Liu et al. (2025) 发现，单个量化开关（仅权重 4-bit、仅 KV 缓存 4-bit，或 8-bit 权重+激活）在五项基准推理平均分上的损失不会超过一分，而将三者同时叠加到 4-bit 时则会。实际下降是堆叠效应导致的。本文的更细粒度测试（在 GSM8K 上对比更难的 MATH-500，两者均为不同难度的多步数学，见 Results 小节）仅发现深度效应的弱确认。相同的 4-bit 开关在更难任务上的相对准确度损失比简单任务大 1.3 倍到 1.5 倍，远低于 Liu et al. 在堆叠配置下 AIME-120 与 GSM8K 差距大约 4 倍的情况。

模型大小在测试的难度范围内比深度更能预测损害：相同的拨号在 70B 时最多只需 1.40 分（不显著），而在 8B 时需 6.75 分（显著），在两个任务上均如此。在两个测试的难度级别上，零结果路径在 70B 处成立；到目前为止测量的规模和难度范围内，该模型的民间说法被夸大了。以上内容仍然属于同一任务类型——多步数学，在两个难度级别上。如果您的工作负载是分类、提取、摘要、代码生成或代理式工具使用，那么这就是任务阶梯部分中提到的后续工作，而它们尚未经过测试，因此在它们被测试之前，请将此答案视为对您情况的未验证结果。

5. 量化 Llama 3.3 70B 能节省多少显存？

在大多数情况下，这足以改变部署所需的 GPU 规模。仅权重占用随着精度的提升而急剧下降：llama3.3-70b-instruct 在 BF16 下大约需要 141 GB，在 FP8 或 INT8 下大约需要 70 GB，在 4-bit GPTQ 或 AWQ 下大约需要 35–40 GB。GGUF 的 k-quants 处于同一数量级，但具有各自特定的大小：bartowski 的 Q4_K_M 编译版本为 42.52 GB，Q3_K_M 编译版本为 34.27 GB，这两者都反映了之前所述的混合每张量位宽，而不是简单的 4 位或 3 位计算。这仅是权重，负载下的总占用更高，因为它还包括激活、CUDA 图缓冲区以及服务配置的上下文长度和批次大小对应的 KV 缓存，因此不要仅凭权重数量来确定 GPU 规模。Performance Payoff 表已经给出了 FP8、INT8、AWQ 和 W4A16 的更完整数字。

所有四种配置在此测试平台的 H200 上，在 8192-token 上下文下均约占 123 GiB，权重和服务器保留的 KV 缓存大致各占一半；不同的上下文长度或批次大小会相应地改变 KV 缓存的占比。GGUF Q4_K_M 不在该统计范围内：用于推导该数值的服务日志从未记录过 weight-buffer 行，仅记录了 prompt-cache 驱逐大小，因此未捕获该数字（参见结果部分的 GGUF 表注释）。BF16 也不是待定数字；请参阅同一表的注释，以了解为何未进行专门的 BF16 测量。

6. 推理时量化是否等同于 QLoRA？

不，混淆两者会让你找错教程。本文介绍的推理时量化会压缩已经训练好的模型的权重和/或激活值，以降低内存占用并提升服务时的吞吐量。QLoRA 在微调过程中对基础模型进行量化，以降低训练成本，随后通常以不同精度服务该结果。它们在模型生命周期的不同阶段解决不同的问题，因此如果你的目标是微调而不仅仅是服务，那么本文介绍的技术并不是你需要的。想了解训练时的量化技术，请参阅 在预算内微调 LLMs（QLoRA/PEFT）。

本文旨在回答量化通常会为你规避什么内容：不是量化是否平均会损害质量，而是它首先在哪里失效，以任务阶梯而非综合基准分数来衡量。它得到的答案并非引言中所期待的，这也改变了你在发布量化模型前应检查的内容。首次失效的是模型规模，而非任务类型。在 llama3.3-70b-instruct 上的单 dial 量化在所有测试的臂（FP8、INT8、GPTQ/AWQ 4‑bit、GGUF Q4_K_M）上在 70B 规模下表现平坦，覆盖两个多步数学难度水平，这一点通过配对显著性检验得到证实，而非可能掩盖真实效果的原始准确率比较。

在 70B 规模下表现平坦的单 4‑bit dial（W4A16，以及单独的 AWQ）相较于 8B 规模下的 BF16（W4A16）会损失 6.75 个显著点，而在 3B 规模下的 AWQ（由于不存在 RedHatAI 3B W4A16 检查点，这里用 AWQ 代替）则损失 3.64 个显著点。如果你在 4‑bit 精度下运行任何小于 70B 的模型，这个数值就是你需要与自身容忍的准确度进行权衡的参考。保持 8‑bit 能让所有测试的规模保持干净，这使其成为缩小较小模型时的低风险默认选择。任务深度也会影响结果，但影响远小于前述因素。同样的 dial 在更难的 MATH-500 上的相对损失仅比 GSM8K 大 1.3 到 1.5 倍，而 Liu 等人的研究表明在堆叠配置（未在此测试）下 AIME 与 GSM8K 的差距大约是 4 倍。

在本文的所有比较中，规模是更强的预测因子；这意味着在你决定验证难度时，模型规模应比任务难度更具决定性。GGUF 还提供了一个值得直说的第二个发现：在 4-bit 精度下，它在质量上与 GPTQ/AWQ 持平，但在吞吐量方面表现糟糕，在相同并发下比 FP8 慢 7.4 倍；原因在于 llama-server 的槽位数量，而非量化格式本身，因此仅凭质量考量不应在仅限 GPU、对吞吐敏感的部署中决定采用 GGUF。本文直接测得了 FP8 与 4-bit 在吞吐量上的交叉点，该点位于并发数 32 与 64 之间；4-bit 的真实优势出现在中等并发而非民间智慧所期望的低并发。在决定采用哪种方案前，请先检查自己的流量相对于该交叉点的位置。

基于这些证据，对你作为运营者而言，精度选择首先是模型规模的决策，其次是任务类型的决策，这适用于本文尚未触及的五个层级。本文表明，在所有测试的规模下，8-bit 的单 dial 量化是安全的；而在 4-bit 下，仅在 70B 规模时得到证实安全，更低规模尚未得到确认。你在实际部署中需要真正警惕的是：堆叠多个 dial、降至 4-bit 以下，或在低于 70B 的规模下运行单个 4-bit dial——这里给出了三个不同置信度的“悬崖”。其中，低于 70B 的悬崖是在本文中直接测得的，而堆叠和低于 4-bit 的悬崖则来源于文献，尚未在此独立复现。本文所述的 eval ladder 方法让你能够在自己的模型规模和任务组合上运行相同的测试，而不必盲信引言中通过否定而提出的两种流派。

至于此决策的硬件方面（哪些硬件代码原生支持哪些精度），请参阅《专用推理硬件》一文（将在发布后交叉链接）。关于这里测得的 VRAM 和吞吐量收益背后的成本计算，请参阅 专用 GPU 上不同流量配置的 Token 经济学。关于将堆叠 dial 或低于 4-bit 的配置路由至经过验证的安全精度，同时将其他所有工作负载保持在更廉价的单 dial 默认配置下，请参阅 借助推理路由器实现多模型 API 成本治理。