多模型推理服务的 GPU 显存计算：为什么大多数团队会过度配置 3 倍资源

大多数运行 LLM 推理的团队将 GPU 配置视作一场猜谜游戏。他们看到模型在 FP16 精度下需要 “140 GB”，便感到恐慌，于是申请四张 A100-80GB 显卡，然后就觉得万事大吉了。他们没有计算的是 KV 缓存、并发和量化是如何相互作用并决定实际显存占用的——而这种误算通常意味着他们多支付了 3 倍的冤枉钱。

这套计算并不复杂。但在签署云服务合同之前，几乎没有人去计算。本文将详细介绍这些精确的公式，揭示隐藏的显存黑洞，并解释装箱（bin-packing）策略，让你能在原本只够运行一个模型的硬件预算下服务四个模型。

大多数人都会搞错的显存公式

初始公式很简单：显存 = 参数量 × 每个参数的字节数。一个拥有 70B 参数的模型在 FP16 精度下（每个参数 2 字节）仅权重就需要 140 GB。在 INT8 精度下，这一数字降至 70 GB。在 INT4 精度下，则为 35 GB。

以下是流行模型的显存占用情况：

模型	参数量	FP16	INT8	INT4
Mistral 7B	7B	~14 GB	~7 GB	~3.5 GB
Llama 3.1 70B	70B	~140 GB	~70 GB	~35 GB
Llama 4 Scout (MoE)	109B (17B 活跃)	~218 GB	~109 GB	~55 GB

但这仅仅是模型权重。大多数团队的计算到此为止。在生产环境中，权重往往占总显存占用的不到一半。其余部分来自三个来源，它们随你的流量而非模型规模而变化。

在推理过程中，激活显存消耗模型权重大小的 5–10%。来自 vLLM、TGI 或你的服务栈的框架开销会再增加 10–15%。接着就是 KV 缓存——这是在并发负载下主导一切的显存组件。

KV 缓存：吞噬 GPU 的显存组件

模型处理的每个 token 都会生成键（key）和值（value）张量，这些张量必须存储起来用于注意力计算。公式如下：

每个 token 的 KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 每个元素的字节数

以 Llama 3.1 70B 为例，它有 80 层、8 个 KV 头（分组查询注意力）以及 128 维度的头，在 BF16 精度下，每个 token 大约占用 0.31 MB。

听起来微不足道。但它累积得很快：

上下文长度	KV 缓存 (1 个请求)	KV 缓存 (16 个并发)
2K tokens	~0.6 GB	~10 GB
8K tokens	~2.5 GB	~40 GB
32K tokens	~10 GB	~160 GB
128K tokens	~40 GB	~640 GB

在 128K 上下文和 16 个并发请求下，仅 KV 缓存（640 GB）就是模型权重（140 GB）的 4 倍以上。这就是过度配置陷阱所在。团队根据模型权重加上一个模糊的缓冲来确定 GPU 规模，结果发现他们要么只能服务长上下文，要么只能服务高并发——但无法两者兼顾。

核心洞察：**KV 缓存随上下文长度和批次大小线性增长。**如果你将其中任何一个翻倍，缓存就会翻倍。如果两个都翻倍，缓存就会变成原来的四倍。你的容量规划必须基于实际的流量分布——即 P95 上下文长度乘以你的目标并发量——而不是模型理论上支持的最大上下文长度。

静态分配：无声的浪费

大多数服务框架会根据支持的最大序列长度静态预分配 KV 缓存。如果你的模型支持 128K token，但你的中位数请求仅使用 2K，那么你为每个请求槽预留的显存是典型流量实际需求的 64 倍。

vLLM 的 PagedAttention 通过按需分配固定大小块的 KV 缓存来解决这个问题，类似于虚拟内存分页。它不再为每个请求预留 128K token 的缓存，而是随着序列的增长分配页面。仅此一项就能在相同硬件上实现 2–4 倍的并发请求。

实际影响：一个在 4×A100-80GB 上运行 Llama 3.1 70B 并使用简单静态分配的团队，在 8K 上下文下可能只能支持 8 个并发请求。而使用 PagedAttention，同样的硬件在相同的上下文长度下可以服务 20–30 个并发请求，因为从过度分配的槽位中释放出来的显存可以用于额外的序列。

如果你的服务栈不支持分页分配，你几乎肯定处于过度配置状态。对于大多数推理部署来说，这是投资回报率最高的一项优化。

真正重要的量化-质量权衡曲线

量化是降低显存需求最有效的手段。但团队通常引用的基准测试——Wikitext-2 上的困惑度（perplexity）——并不能说明全部问题。以下是与生产相关的评估情况：

各方法的质量保持情况（基于 Llama 的模型）：

方法	困惑度 (Wikitext-2)	HumanEval Pass@1	显存节省
FP16 (基准)	6.56	56.1%	—
BitsandBytes INT8	6.67	51.8%	~50%
AWQ INT4	6.84	51.8%	~75%
GGUF Q4_K_M	6.74	51.8%	~75%
GPTQ INT4	6.90	46.3%	~75%

各种量化方法之间的困惑度差异很小——都在基准值的 6% 以内。但 HumanEval 反映了不同的情况：GPTQ 使代码生成准确率下降了近 10 个百分点，而 AWQ 和 GGUF 在相同的 4-bit 压缩下保持了与 BitsandBytes 相当的水平。

**吞吐量的情况甚至更令人惊讶。**量化模型不仅体积更小——如果有合适的内核（kernel），它们还会更快：

| 方法 | 输出吞吐量 | 对比 FP16 基准 |

加载中…