一句话结论
同一张 A100-SXM4-80G 上，把 Qwen-7B 从 BF16 换成 Int4，显存从 16.99 GB 降到 8.21 GB（−52%），吞吐从 40.93 tokens/s 升到 50.09 tokens/s（+22.4%）；但在缺少原生低比特矩阵乘单元的消费级显卡上，同为 4 位的权重在批大小（batch size，一次并行处理的请求数）为 1 的解码场景反而比 FP16 慢 1.3–2.2 倍。
显存收益可以按位宽直接推算，吞吐收益不能——它由你的卡、批大小和推理引擎内核共同决定。做 GPU 选型 时把这两笔账分开算，是本文想给出的第一条判断依据。
关键数据表
表 1：数据中心卡上的权重精度对比
测试条件：A100-SXM4-80G 单卡（72B 为 2×A100）、PyTorch 2.0.1、CUDA 11.8、Flash-Attention 2。来源为 Qwen 官方量化基准，2026 年 9 月检索。显存单位 GB，吞吐单位 tokens/s（每秒生成 token 数），均为该来源标注的实测值。
| 模型 | 精度 | 显存占用 | 吞吐 (tokens/s) | 显存 vs BF16 | 吞吐 vs BF16 |
|---|---|---|---|---|---|
| Qwen-7B | BF16 | 16.99 GB | 40.93 | 基线 | 基线 |
| Qwen-7B | Int8 | 11.20 GB | 37.47 | −34% | −8.5% |
| Qwen-7B | Int4 | 8.21 GB | 50.09 | −52% | +22.4% |
| Qwen-14B | BF16 | 30.15 GB | 32.22 | 基线 | 基线 |
| Qwen-14B | Int8 | 18.81 GB | 29.28 | −38% | −9.1% |
| Qwen-14B | Int4 | 13.01 GB | 38.72 | −57% | +20.2% |
| Qwen-72B | BF16 | 144.69 GB（2×A100） | 8.48 | 基线 | 基线 |
| Qwen-72B | Int8 | 81.27 GB（2×A100） | 9.05 | −44% | +6.7% |
| Qwen-72B | Int4 | 48.86 GB | 11.32 | −66% | +33.5% |
表里有两点值得单独拎出来：Int8 在 7B 与 14B 两档上吞吐低于 BF16；而 Int4 在三档上全部高于 BF16。所以「量化一定更快」不成立，「量化一定更省显存」才成立。72B 那一行还有个额外信息——Int4 之后显存降到 48.86 GB，单张 80 GB 卡装得下，而 BF16 需要两张卡，这是从 2 卡降到 1 卡的整数级变化，比百分比更值钱。
表 2：消费级单卡上的 GGUF 档位
模型 Llama 3.1 8B。困惑度（perplexity，衡量模型预测能力的指标，越低越好）测试基于 wikitext-2 语料、上下文长度 512；速度为 llama.cpp 量化说明文档（build b9297）标注的消费级单卡实测值，2026 年 9 月检索。文件体积单位 GiB，速度单位 tokens/s。
| 格式 | 每权重比特 | 文件体积 | 显存估算 | 困惑度增量 | 生成 t/s | 预填充 t/s |
|---|---|---|---|---|---|---|
| Q4_K_M | 4.89 | 4.58 GiB | ~6 GB | ~+0.18 | 71.9 | 821.8 |
| Q5_K_M | 5.70 | 5.33 GiB | ~6.5 GB | ~+0.06 | 67.2 | 758.7 |
| Q6_K | 6.57 | 6.14 GiB | ~8 GB | ~+0.03 | ~62 | ~790 |
| Q8_0 | 8.50 | 7.95 GiB | ~10 GB | ~+0.01 | 50.9 | 865.1 |
| F16 | 16.00 | 14.96 GiB | ~18 GB | 基线 | 29.2 | 923.5 |
显存估算列为按文件体积上浮 10%–20% 的经验值（来源给出的估算方法），因为实际占用还要加上键值缓存（KV cache，推理时缓存历史 token 的中间状态）与框架开销。
分点论证
1. 显存下降接近线性，但别按权重体积直接下单
FP16 → INT8 约为 2× 压缩，FP16 → INT4 约为 4× 压缩，这是理论值。落到整卡占用上会被稀释：表 1 中 7B 的 Int8 只降了 34% 而不是 50%，因为激活、KV cache 和框架开销不随权重位宽缩小。做显存预算时，把权重体积乘以 1.1–1.2 再叠加 KV cache，才不会在长上下文时踩坑。这也是我们建议把显存与量化 放在同一张预算表里算的原因——只看权重会系统性低估。
2. 解码阶段是显存带宽瓶颈，这解释了表 2 里的速度排序
自回归解码每生成一个 token，都要把全部权重从显存读一遍。位宽越低，每 token 需要搬运的字节越少，速度越高。表 2 里 F16 生成只有 29.2 tokens/s，Q4_K_M 达到 71.9 tokens/s，约 2.5×，这个差距几乎完全由带宽解释，而不是算力。
3. 预填充阶段是算力瓶颈，量化基本不省时间
预填充（prefill，处理输入提示词、一次性并行计算）是矩阵乘密集型。表 2 里 Q8_0 的预填充 865.1 tokens/s 反而略高于 Q4_K_M 的 821.8 tokens/s，因为 INT8 在这条路径上有优化过的计算内核可以吃满算力。结论很实际：如果你的负载是长文摘要、RAG 检索问答这类「读多写少」场景，量化带来的端到端延迟改善会远小于生成密集型场景。
4. 硬件是否原生支持低比特，决定收益能否兑现
vLLM 官方文档的兼容表给出的能力门槛是：Marlin 内核（覆盖 GPTQ/AWQ/FP8/FP4）从 Turing（SM 7.5）起支持，而 FP8 的 W8A8 方案从 Ada（SM 8.9）起，Ampere（SM 8.0/8.6）与更早的卡不在列。原因不复杂：卡上没有低比特张量核，内核就得先把 INT4 权重现场还原成 FP16 再算，字节省下来了，计算没省，还多付一次解包开销。这正是消费级卡上出现性能倒挂的机制。
5. KV cache 是第二块显存，且对长上下文更敏感
KV cache 的量化收益常被低估。FP8/INT8 的 KV cache 每个元素占 1 字节，相较 FP16/BF16 的 2 字节约省一半。vLLM 官方博客给出的实测（2026 年 4 月 22 日发布，H100，150 个请求、并发 8、输入约 20K token / 输出约 2K token）是：输出吞吐从 BF16 的 450.3 tokens/s 升到 FP8 的 517.5 tokens/s（+14.9%），中位相邻 token 间隔（ITL）下降 14.8%。收益不来自算术变快，而来自省下的显存能塞进更多并发请求。上下文越长，这笔账越划算。
6. 质量退化不是线性的，悬崖位置比想象中低
表 2 显示，Q8_0 的困惑度只比 F16 高 0.01，Q4_K_M 高约 0.18，Q4 到 Q8 的整体差距约 2%–3%。真正的断崖出现在 Q3 与 Q4 之间，到 Q2_K 时困惑度增量已达 +15.3%，来源明确标注为「不推荐」。另一条更容易被忽视的风险在 KV cache：vLLM 博客记录，Hopper 架构上 FP8 KV cache 在 128K 上下文的大海捞针任务中，准确率曾从 BF16 的 91% 掉到 13%，引入两级累加修复后回到 89%——仍略低于基线。KV cache 量化的精度风险高于权重量化，这一点在多数选型讨论中被漏掉了。
7. 把吞吐折算成 Token 成本，才算完成 GPU 选型
租用价格用 Silicon Data 的 Neo-Cloud 指数（2026 年 5 月 4 日至 7 月 27 日，美元/卡/小时）：H100 从 2.57 升至 2.75，H200 从 2.70 升至 3.09，H200 相对 H100 的溢价 7 月均值为 12.1%。
用中位数价格做一次折算（估算值，方法如下）：按 2.75 美元/卡/小时计，若某配置稳定输出 500 tokens/s，每小时产出 1.8M token，折合约 1.53 美元/百万 token；若只有 200 tokens/s，则约 3.82 美元/百万 token。该估算未计入预填充耗时、空闲与并发折损，仅用于横向比较不同卡型与量化档位的相对关系。同一张卡上把吞吐从 200 提到 500 tokens/s，单位 token 成本降到 40%——这就是量化在成本侧的杠杆所在。
适用边界与反例
反例一：消费级卡 + 批大小为 1，INT4 可能明显更慢。 一个公开的量化性能剖析项目在 RTX 4060 Laptop（8 GB）上跑 Qwen2.5-1.5B-Instruct，512 token 提示词、128 步解码：bitsandbytes 的 4 位方案峰值显存从 FP16 的 3271.3 MB 降到 1423.5 MB（省 56.5%），但解码延迟上升 47.7%，吞吐从 12.04 tokens/s 掉到 8.15 tokens/s。该项目明确写道：「压缩本身并不保证更快的核（Compression alone therefore does not guarantee a faster kernel）」，并指出未排除解包、指令混合、占用率等成因。这与 IEEE Computer Architecture Letters 2026 年一篇针对消费级显卡的研究方向一致：在缺少原生 INT4 张量核的 RTX 3090 上，AutoGPTQ 4 位在批大小 1 时比 FP16 慢 1.3–2.2 倍，显存则省约 2.4 倍；但换用优化过的 GGUF 后端后，同一位宽的吞吐提升 1.65 倍——差距主要来自内核工程，不是硬件天花板。
反例二：预填充密集的长上下文负载，量化收益有限。 见表 2，Q8_0 与 Q4_K_M 的预填充速度几乎持平。若你的 P95 延迟由长输入决定，优先做前缀缓存与批调度，而不是降位宽。
反例三：滑窗注意力的混合模型，KV cache 量化几乎不划算。 vLLM 博客提到，对 gpt-oss-20b 这类滑窗仅 128 token 的模型，量化滑窗层收益接近于零（FP8 的 ITL 斜率是 BF16 的 96%），官方为此提供了 --kv-cache-dtype-skip-layers 参数跳过这些层。
反例四：显存够用时，不要为量化牺牲质量。 表 2 的责任来源给出一条明确判断：在显存允许的前提下，更大的模型配 Q4 通常优于更小的模型配 Q8——13B 的 Q4_K_M 在质量上「几乎总是」胜过 7B 的 Q8_0。量化的定位是「让装不下变成装得下」，不是无条件提速。
数据边界说明：以上所有数字来自不同模型、不同显卡、不同批大小与不同软件版本，横向不可直接相减；同一来源内部的对比（如表 1 同一模型的三行）才具备严格可比性。价格数据只覆盖 Neo-Cloud 层级，不含超大规模云厂商报价。
行动建议
- 先算显存，再谈速度。 权重体积 × 1.1–1.2，加上 KV cache，再对照目标卡容量选档。留不出 15% 余量就不要上长上下文。
- 按卡的代际决定量化档位。 Ada/Hopper 及更新的卡优先 FP8 或成熟 INT4 内核（AWQ/GPTQ-Marlin）；Ampere 及更早的卡先跑 FP16 基线，再决定是否量化，不要默认「4 位一定更快」。
- 实测你自己的负载，而不是照搬榜单。 至少要量三个数：预填充 tokens/s、解码 tokens/s、以及显存峰值。三者中哪一个先撞墙，决定了你的优化方向。
- 长上下文场景单独验证 KV cache 量化的精度。 在 32K 以上的真实检索或摘要任务上做一次对照测试，不要只看困惑度。
- 把速度折算成单位 Token 成本再决策。 租用价格是分子，吞吐是分母，两者一起看才能支撑 GPU 选型 的结论。
以上判断均基于公开来源的实测数据，不同软件版本与内核实现会显著改变结果，建议以自有环境复测为准。
相关阅读
作者：IDCToken 发布日期：2026 年 9 月 16 日