实际该跑哪种量化格式。

从这里开始

本页大部分内容都是运算，所以先说结论。四个问题就能决定格式，之所以按这个顺序提问，是因为每一个都有可能单独终结讨论。

接下来的内容会解释这四个答案为何如此，并给出数字，供您用自己的模型而非我们的模型去核对。如果您还没算清楚自己的模型到底需要多少显存，那部分运算属于另一篇指南，应该先看那一篇。

三种格式，四个名称

用于推理的常见数字格式其实只有三种，它们的区别只在一点：每个参数占用多少字节。其余的一切—AWQ、GPTQ、GGUF、bitsandbytes—都只是生成这三种格式之一的方法，而不是第四种格式。

把这两个数字列当成一对来看。它们在前两行相等，在第三行并不相等，正是这一处不对称，造成了本页下文的大多数意外之处。

您在模型仓库中实际会遇到的这四个名称，与上表的对应关系如下。

调用这几种格式，各自只需一个参数标志。这些正是vLLM 指南中详细介绍的那些选项；这里想说明的只是它们之间的差异有多小。

# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin

不会缩小的那一半

把权重量化为 4 位，并不会量化键/值缓存。AWQ 和 GPTQ 只压缩权重，仅此而已；缓存会保持在 16 位，除非您另外要求使用 FP8 缓存，而在 4-bit 权重文件上，大多数人从不这样做。这正是上表的第三列，也是下面的运算结果不如任何人预期的原因。

这一后果在单个模型上最容易看清楚。下面是 Llama 3.3 70B 在 4-bit 下、配置器提供的每个上下文长度对应的情况—权重与缓存的对比。

权重那一列始终不变—这正是量化权重的全部意义所在。缓存那一列则随上下文线性增长，到最后一行时，缓存甚至比它所属的模型本身还要大。

把这个过程推得足够远，4-bit 就会彻底失去优势。FP8 把两部分都减半；4-bit 只把其中一部分压缩到四分之一，另一部分原封不动。因此，对每个模型而言，都存在一个两者交叉的上下文长度，模型越小，这个交叉点到来得越早—因为小模型能节省的权重本就不多，而每个 token 带来的缓存增长却是相同的。

数字以 GB 为单位，取两种格式中较小的一个，落败的格式名称标注在下方。请从左往右读，您会看到随着上下文变长，4-bit 一列的优势逐渐消失。

最后一行的领先优势始终保持，因为 700 亿参数意味着有大量权重可以节省。中间一行打成平手：在 128k 时，Qwen 3 32B 无论用哪种格式，花费完全相同，这时您应该为了质量而选择 FP8。第一行则完全反转 at 128k：4-bit 所需的显存反而多于 FP8，同时精度还更差。这种情况—显存更多，输出更差—正是我们见过最常见的量化失误，如果您只看权重文件的大小，根本发现不了。

您的显卡实际能做到什么

FP8 首先是一项硬件特性，其次才是软件特性。张量核心不支持 FP8 的显卡，依然能加载 FP8 权重文件—推理服务栈会在做乘法运算前，把权重解包为 16 位—但您只能保留下载体积上的节省，却得不到速度上的好处，而且完全用不上 FP8 缓存。4-bit 则恰恰相反：它到处都能运行，因为无论如何，权重在参与运算前都要先解包为 16 位。

那一列描述的是芯片本身，这和「FP8 在哪里才是明智之选」并不完全是同一个问题。产品目录中该格式旁边的备注列出了 Hopper and Blackwell，这说的是推理服务栈，而不是张量核心：那些代次的 FP8 内核和 FP8 缓存，经过的实战最多，踩过的坑最少。Ada Lovelace 能运行它。而如果部署要依赖它，我们会选择 Hopper 或 Blackwell。

在选卡之前，还有一件事值得了解。Llama 3.3 70B 在 FP8、8k 上下文下需要 81.9 GB，而一张 80 GB 显卡—其中包括 NVIDIA A100 PCIe—还差 1.9 GB。在电子表格上看不出明显差距，但在实际服务器上足以导致失败。能独立满足需求的是再高一档的显卡，配置器会在您付款之前，而不是之后，告诉您那是哪一款。

速度上的收益

生成一个 token，意味着从显存中读取一次活跃权重。每个权重占用的字节数越少，需要读取的字节就越少，也就意味着每秒能生成更多 token—而在未经批处理的单流上，这种关系几乎是线性的，因为显卡没有别的事情可等。这正是每 token 成本指南用来做除法的那同一个显存带宽上限，而且刻意取得保守。下面把它应用到一个足够小、能在我们出租的每台单卡服务器上运行的模型，这样格式和显卡就能在同一张表里对照着读。

Llama 3.1 8B放在单张显卡上，一次一条流。表中列出的每台服务器都能以全部三种格式容纳它，因此各行既可以横向比较，也可以纵向比较 — 而且每一行里三栏之间的比例都相同，因为这只由每个权重占用的字节数决定，别无其他。

阅读这张表时有两点需要留意。第一，它描述的是一次一个请求的情形，而几乎没有人是这样提供服务的：在连续批处理下，权重对整批请求只读取一次，因此限制因素变成了算力而非显存，两列之间的比例也会随之收窄。第二，反量化本身是有代价的。4-bit 权重在参与乘法运算前必须先解包，在小模型、低批次规模下，这一解包过程可能会吃掉「读取量更小」所带来的部分收益中相当明显的一份。这张表所指示的方向是可靠的，但具体的倍数并不是承诺。

它会让您付出什么

这是整个主题中，最应该对「言之凿凿的数字」保持怀疑的部分，包括我们自己给出的数字。量化误差在很大程度上取决于模型本身，而不是量化方法，公开发表的对比结果之所以彼此矛盾，是因为它们测的是不同模型、不同任务。能够诚实说出口的，只是这种误差的大致走向。

这比任何表格（包括这一张）都更靠谱 — 这也是我们宁愿给您公式，而不是给您一个分数的原因。这就引出本页唯一一条不是算出来的建议：两种都跑一遍。您租用的服务器带 root 权限，也没有任何计量收费，把同一个模型在两个端口上各起一份，各自跑上百条您自己的提示词，只需一个晚上，得到的结论也是针对您自己的工作负载，而不是别人的。

换算成哪台服务器

这一切之所以重要，归根结底是账单问题。下面是我们产品目录中，能在三种格式下，于 8k 上下文中完整容纳各模型的最便宜服务器—「完整」指放在一张卡上，不做拆分，因为一旦模型跨卡拆分，就会牵涉到互联问题，那是另一篇指南的内容。

以 8k 上下文、在我们实际出租的服务器上为准。当某个单元格列出多张卡时，指的是该卡所在的最小节点规格，而不是拆分后的模型：最大的几款卡以四卡、八卡为单位出售，因此要在全精度下避免拆分 70B 模型，最便宜的办法就是买下四张卡、只用其中一张。这正是量化存在的意义：避免付出这笔账单。

善用这张表格和被它误导，区别在于两个习惯。按您实际会用到的上下文量估算，而不是按模型的最大上下文 — 本页第二张表格，说的正是把两者混为一谈的后果。下单前先核对格式是否符合显卡，而不是下单后才核对：无论传哪个参数，NVIDIA RTX A6000, NVIDIA A100 PCIe和NVIDIA A100 SXM4都给不出 FP8 的数据。配置器会针对每个节点和每种格式，在您付款之前报告所需显存，以及能否放入单张显卡。如果您权衡的是租用与按 token 付费调用 API 之间的取舍，那笔收支平衡另有专门测算，而量化会让天平大幅倒向硬件这一边。