选型 指南 · 阅读需 10 分钟

# 实际该跑哪种量化格式。

推理服务栈首先要问的就是数字格式，而这个答案能让您的月度账单相差八倍之多。权重最小的格式，未必是能让模型整体占用最小的那个。

简短的答案

- **经验法则:** 权重会精确地按名称中的比例缩小 — BF16 / FP16 **2 B/param** · FP8 **1 B/param** · 4-bit (AWQ, GPTQ) **0.5 B/param**。其他部分则不会。
- **是否值得:** Qwen 3 32B需要[NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb)，全精度下每月**$1,091**，4-bit 则是[NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4)，每月**$125**。同一模型，同一上下文。
- **陷阱:** 键/值缓存不会跟着权重一起缩小。在 128k 上下文下，4-bit Llama 3.3 70B 中有 **53 %** 是缓存，只有 47 % 是权重。
- **4-bit 全面落后的场景:** Llama 3.1 8B在128k 处，4-bit 需要**23.0 GB**，而 FP8 只需**18.4 GB** — 显存更多，质量反而更差

## 从这里开始

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

**模型在全精度下，连同您的上下文，是否已经放得下？**那就用 BF16 运行，不必再往下读。量化是一种用更小的服务器换取同等效果的手段，而您已经买到了能用的那台。压缩一个本来就放得下的模型，没有任何好处。

**您的上下文很短，而模型很大吗？**这正是 4-bit 声名远扬的场景。权重占据了显存的大部分，把权重压缩到四分之一，几乎等于把所需服务器规模也压缩到四分之一。

**您的上下文很长，而模型较小吗？**请在支持 FP8 的显卡上使用 FP8。FP8 既能把权重减半，也能把缓存减半，超过某个长度后，真正起作用的是第二个减半—下表给出了它反超 4-bit 的确切临界点。

**您是在一台服务器上为一个人提供服务吗？**通过 Ollama 使用 GGUF 是迄今为止最省事的做法，您放弃的那部分吞吐量，本来单个用户也用不到。

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

## 三种格式，四个名称

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

**三种数字格式，以及每个字节数字各自对应的内容**

| 格式 | 每个权重的字节数 | 每个缓存元素的字节数 | 用途 |
|---|---|---|---|
| BF16 / FP16 原始发布的权重 | 2 | 2 | 公版品质 |
| FP8 由推理服务栈本身生成 | 1 | 1 | 接近公版，Hopper 与 Blackwell |
| 4-bit (AWQ, GPTQ) 预先准备好的权重文件 | 0.5 | 2 | 权重最小，缓存保持 FP16 |

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

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

### AWQ 与 GPTQ

殊途同归，都通向 4-bit。AWQ 通过观察激活值来判断哪些权重重要并加以保护；GPTQ 则逐层压缩，边压缩边修正误差。两者都会生成 vLLM 和 SGLang 可以直接加载的检查点，而且就同一个模型而言，二者之间的差距，小于其中任何一个与 16-bit 之间的差距。

### GGUF

llama.cpp 系列格式，也是 Ollama 底层所使用的格式。与其说它是单一方法，不如说是一种容器：一个文件可以容纳十几种精度中的任意一种权重，当显卡太小时，还会把部分层溢出到系统内存中。对于一台服务器上的单个用户来说无可匹敌，但在真实并发场景下，是三者中最弱的一个。

### FP8

与其说它是一种权重文件格式，不如说是一种模式。给推理服务栈提供 16-bit 权重，它会在加载时将其转换为 FP8，无需额外下载，也无需校准环节。它是这四种格式中唯一还能压缩缓存的一种，这也是它会出现在您意想不到之处的原因。

### BF16 与 FP16

作者发布时的原始权重，也是其他每一行都以此为基准来衡量的参照系。每个参数两个字节，无需校准集，无需检查内核支持，也无需就质量争论什么。只要放得下，它就是正确答案，本页其余内容都是多余的。

调用这几种格式，各自只需一个参数标志。这些正是[vLLM 指南](https://gpuserver.io/zh/guides/serve-llama-70b)中详细介绍的那些选项；这里想说明的只是它们之间的差异有多小。

同一台服务器，四种方式

```
# 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 下、[配置器](https://gpuserver.io/zh/configure)提供的每个上下文长度对应的情况—权重与缓存的对比。

**4-bit 70B 模型的权重与缓存，按上下文长度**

| 上下文 | 权重 | KV 缓存 | 缓存占比 |
|---|---|---|---|
| 4k token | 35.0 GB | 1.3 GB | 3 % |
| 8k token | 35.0 GB | 2.5 GB | 7 % |
| 32k token | 35.0 GB | 10.0 GB | 22 % |
| 128k token | 35.0 GB | 40.0 GB | 53 % |

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

**在 128k 时，4-bit Llama 3.3 70B 中有 53 % 是缓存。** 您把权重压缩到四分之一大小，但所需的服务器规格几乎没变，因为您压缩的那部分本来就不是问题所在。仅凭权重数字来估算长上下文部署规模的人，配置至少会少估一半以上。

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

**按模型和上下文长度列出，FP8 与 4-bit 的总显存对比**

| 模型 | 4k | 8k | 32k | 128k |
|---|---|---|---|---|
| Llama 3.1 8B 8 B 参数 · 32 层 · 8 个 KV 头 | 5.24-bit，相差 4.3 GB | 5.84-bit，相差 4.0 GB | 9.24-bit，相差 2.3 GB | 23.0FP8 胜出 — 18.4 GB |
| Qwen 3 32B 32 B 参数 · 64 层 · 8 个 KV 头 | 19.54-bit，相差 17.8 GB | 20.74-bit，相差 17.2 GB | 27.64-bit，相差 13.8 GB | 55.2不相上下 |
| Llama 3.3 70B 70 B 参数 · 80 层 · 8 个 KV 头 | 41.74-bit，相差 39.5 GB | 43.14-bit，相差 38.8 GB | 51.74-bit，相差 34.5 GB | 86.34-bit，相差 17.2 GB |

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

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

## 您的显卡实际能做到什么

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

**产品目录中的显卡，按代次列出及其 FP8 支持情况**

| 生成 | 我们出租的显卡 | FP8 |
|---|---|---|
| Ampere | NVIDIA RTX A6000 48GB, NVIDIA A100 PCIe 40GB, NVIDIA A100 PCIe 80GB, NVIDIA A100 SXM4 80GB | 硬件层面不支持—解包为 16-bit |
| Ada Lovelace | NVIDIA L4 24GB, NVIDIA RTX 4090 24GB, NVIDIA L40S 48GB | 在张量核心中—权重与缓存 |
| Hopper | NVIDIA H100 PCIe 80GB, NVIDIA H100 SXM5 80GB, NVIDIA H200 SXM5 141GB | 在张量核心中—权重与缓存 |
| Blackwell | NVIDIA RTX 5090 32GB, NVIDIA B200 SXM6 180GB | 在张量核心中—权重与缓存 |

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

**在 Ampere 显卡上，FP8 只能节省下载体积，仅此而已。** NVIDIA RTX A6000, NVIDIA A100 PCIe和NVIDIA A100 SXM4 的张量核心没有 FP8 通路。如果您原本打算在这类显卡上把缓存减半，那是做不到的—上面 FP8 列中的显存数字，在这类硬件上根本达不到。请按先卡后格式的顺序，把两者放在一起选择。

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

## 速度上的收益

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

**8B 模型在各显卡、各格式下的单流生成速率**

| 显卡 | 带宽 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|---|
| NVIDIA L4 24 GB · 每月$125 | 300 GB/s | 约 8 token/秒 | 约 17 token/秒 | 约 34 token/秒 |
| NVIDIA RTX A6000 48 GB · 每月$286 | 768 GB/s | 约 22 token/秒 | 约 43 token/秒 | 约 86 token/秒 |
| NVIDIA L40S 48 GB · 每月$714 | 864 GB/s | 约 24 token/秒 | 约 49 token/秒 | 约 97 token/秒 |
| NVIDIA RTX 4090 24 GB · 每月$193 | 1008 GB/s | 约 28 token/秒 | 约 57 token/秒 | 约 113 token/秒 |
| NVIDIA A100 PCIe 40 GB · 每月$392 | 1555 GB/s | 约 44 token/秒 | 约 87 token/秒 | 约 175 token/秒 |
| NVIDIA RTX 5090 32 GB · 每月$335 | 1792 GB/s | 约 50 token/秒 | 约 101 token/秒 | 约 202 token/秒 |
| NVIDIA A100 PCIe 80 GB · 每月$1,091 | 1935 GB/s | 约 54 token/秒 | 约 109 token/秒 | 约 218 token/秒 |
| NVIDIA H100 PCIe 80 GB · 每月$1,469 | 2000 GB/s | 约 56 token/秒 | 约 113 token/秒 | 约 225 token/秒 |

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

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

## 它会让您付出什么

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

**FP8 足够接近原始精度，因而不存在争议。**它仍然是一种浮点格式—指数和尾数都保留，只是位数更少—而不是像 4-bit 权重文件那样，必须按分组比例映射到整数网格上。这就是它退化如此轻微、也无需校准环节的原因。大多数团队不做评测就直接采用它，而且大多数情况下都相安无事。

**4-bit 是一种真实的取舍，而且影响并不均匀。**平均基准分数通常变化很小。真正受影响的是长尾能力：长链推理、精确运算、稀有语言、严格的输出格式。一个在选择题测试中依然表现良好的模型，可能会开始生成格式错误的 JSON。

**模型越大，越能吸收这种损失。**在 70B 模型上使用 4-bit 是常规部署。而在 8B 模型上（每个参数承载的信息更多），效果下降才会变得明显—而且根据上表，这也是它收益最小的地方。

**校准数据比方法名称本身更重要。**AWQ 和 GPTQ 都是针对样本语料进行压缩的。一份用英文散文校准、却拿去处理代码的权重文件，表现会比该方法本应达到的水平更差，而这一点，任何基准测试表都不会告诉您。

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

**按成本最低的顺序依次测试。** 只要放得下，就先从 BF16 开始，因为它是您其他测试所需要的基准。接下来降到 FP8—同一份权重文件，只需一个参数标志，无需额外下载。只有在前两者都因显存不足而被排除后，才考虑 4-bit 权重文件，而且到那时，请拿它与 FP8 运行结果对比，而不是与您的预期对比。

## 换算成哪台服务器

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

**按格式列出，完整容纳各模型的最便宜服务器**

| 模型 | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 需要 19.5 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 需要 9.8 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 需要 5.8 GB |
| Qwen 3 32B | [NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) $1,091/月 · 需要 75.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) $286/月 · 需要 37.9 GB | [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) $125/月 · 需要 20.7 GB |
| Llama 3.3 70B | [4 × NVIDIA B200 SXM6](https://gpuserver.io/zh/gpu/b200) $11,790/月 · 需要 163.9 GB | [4 × NVIDIA H200 SXM5](https://gpuserver.io/zh/gpu/h200) $8,405/月 · 需要 81.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) $286/月 · 需要 43.1 GB |

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

**横向读中间一行：$1,091 对 $125，约为 9×。** 同样的 Qwen 3 32B，同样的 8k 上下文，同样的单张卡，同样的 root 权限—区别只在于数字格式。这就是量化在商业上的全部意义，也是为什么它值得您花一晚上实测，而不只是花一下午阅读。

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

## 把格式和服务器放在一起选。

配置器会在您付款之前，报告您的模型在各精度下的需求，以及哪些节点能用单张卡容纳它。

[打开配置器](https://gpuserver.io/zh/configure) [阅读指南](https://gpuserver.io/zh/guides)

## 其他指南

- [选型 · 10 分钟 运行混合专家模型 总参数决定该租用哪台服务器，激活参数决定生成速度。本文说明 DeepSeek V3 与 Qwen 3 235B 各自需要多少显存，以及应该为它们租用哪种节点。 阅读指南](https://gpuserver.io/zh/guides/mixture-of-experts)
- [成本 · 6 分钟 何时月付比按小时计费更划算 基于真实数字计算出的盈亏平衡点、按小时计价直到账单才会显现出的三项隐藏成本，以及让估算数字翻上三倍的闲置时间陷阱。 阅读指南](https://gpuserver.io/zh/guides/monthly-vs-hourly)
- [成本 · 9 分钟 自托管对比按 token 计费的 API 按 token 计费的 API 与租用 GPU 之间的盈亏平衡点，基于我们自己的价格与吞吐量计算得出——以及这套算法遗漏的四件事。 阅读指南](https://gpuserver.io/zh/guides/api-vs-self-hosting)

---

来源：https://gpuserver.io/zh/guides/awq-vs-gptq-vs-fp8/。本文件由与网站相同的数据生成；如果此处的数字与页面不一致，以页面为准，本文件视为过期——权威来源是 https://gpuserver.io/。