生产环境下的自托管 LLM：没人告诉你的 GPU 显存计算公式

大多数决定自托管 LLM 的工程师都会从同样的计算开始：模型有 70B 参数，FP16 每参数 2 字节，所以是 140 GB。他们检查发现两块 A100-80GB GPU 能容纳 160 GB，感到很满意，于是订购了硬件。然后进入生产环境，却发现还没服务一个真实用户，显存（VRAM）就已经耗尽了。

模型权重只是故事的一部分。让几乎每个团队都感到意外的部分是 KV 缓存（KV cache）—— 理解它会改变你的每一个决定，从量化选择到推理框架，再到你实际需要的 GPU 数量。

推理时 GPU 显存中究竟有什么

推理期间的总显存由四个部分组成：

模型权重 + KV 缓存 + 激活值 (activations) + 框架开销

模型权重是大家熟悉的部分。在 FP16 精度下，一个 70B 参数的模型占用 140 GB。量化到 INT4，占用下降到 35 GB。INT8 为 70 GB。FP8 已成为现代数据中心 GPU 的生产平衡点，在几乎无损精度的情况下占用 70 GB。

KV 缓存是预估出错的地方。每个自回归解码步骤都需要访问激活序列中所有先前 token 的键（key）和值（value）向量。公式如下：

KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 序列长度 × Batch 大小 × 每个元素的字节数

对于 Llama 3.1 70B（80 层，8 个 KV 头，128 头维度），在 BF16 精度下，激活序列中的每个 token 大约消耗 0.31 MB。这听起来很小。但乘以上下文长度和并发请求数，它会爆炸式增长：

• 一个具有 128K 上下文的单一请求仅 KV 缓存就消耗约 40 GB
• 在该上下文长度下的四个并发请求需要 160 GB —— 这仅仅是缓存，还没算模型权重

在更典型的 8K 上下文和 8 个并发请求的情况下，70B FP16 模型的 KV 缓存仍消耗约 80 GB。在大多数消费级硬件配置中，这比权重本身还要大。

幼稚的容量规划错误是先为模型规划显存，然后把剩下的作为余量。正确的框架恰恰相反：先为 KV 缓存做计划，然后看模型能塞进哪里。

量化：INT4、FP8 和 FP16 之间的真实权衡

大多数团队将量化视为一个二元选择 —— “我们要不要压缩？” —— 而实际上，它是三种具有不同失效模式的截然不同的运行方案。

FP16/BF16 是基准。完整权重，无近似误差，兼容性最高。当准确性不可妥协时 —— 如医疗推理、法律文件分析、金融建模 —— 或者当你不受显存限制且不想处理量化 Bug 时，它是正确的选择。

FP8 已成为运行现代数据中心 GPU 的团队的生产平衡点。H100、H200 和 B200 具有原生 FP8 Tensor Core，在相同的内存布局下提供约 2 倍于 FP16 的吞吐量，且精度近乎无损。Meta 的 Llama 3.3-70B 使用 FP8 量化后，相对于 FP16 基准显示出 99% 以上的质量恢复，且延迟降低 30%，吞吐量提高 50%。如果你在 H100 或更新的设备上运行，推理时默认使用 FP8 几乎总是正确的。

INT4 是最受关注的格式，因为它能让大型模型适配消费级硬件 —— 一个 70B 模型压缩到约 35 GB，可以运行在带有 KV 缓存空间的单块 A100-80GB 上。GPTQ 和 AWQ 等现代量化方法恢复了 4 位压缩损失的大大部分质量，通常能保留 95% 以上的基准性能。权衡在于精度下降是不均匀的。模型往往会先在边缘情况、复杂的多步推理和稀有 token 上失去精度。如果你的应用失效案例正好集中在这些领域，INT4 会以难以在综合评估（evals）中捕捉到的方式悄悄降低质量。

2026 年一种日益流行的模式是格式混合：在注意力层（数值敏感度较高）使用 FP8，在 MLP 模块（压缩容忍度较高）使用 INT4。这让你可以用更少的 GPU 容纳 70B 模型，同时保护架构中对舍入误差最敏感的部分。

关于量化，团队发现的另一件事是：KV 缓存也有自己的量化。在 70B 模型上运行 FP8-KV 缓存量化，可以达到运行两倍张量并行（tensor parallelism）的 FP16 模型的延迟 —— 这意味着你可以用一半的 GPU 达到同等速度。这种优化在 vLLM 中可用，并显著改变了长上下文工作负载的成本计算。

在 vLLM、TGI 和 llama.cpp 之间做出选择

选择推理框架的错误方法是仅对单用户吞吐量进行基准测试就完事了。服务特性在并发情况下会发生剧烈分歧，你为个人助手选择的框架与为面向客户的产品选择的框架是不同的。

vLLM 是多用户生产环境的默认选择。其 PagedAttention 显存管理借鉴了操作系统的虚拟内存概念，通过管理固定大小的块，将 KV 缓存浪费从 60–80%（朴素预分配）降低到 4% 以下。仅这一项改进就能在固定硬件上使并发请求容量翻倍或翻三倍。基准测试数据：在 7B 模型的 100 个并发请求下，vLLM 达到每秒约 15,000 个 token，而 TGI 为 4,100 —— 具有 3.7 倍的优势，在极端负载下这一优势会扩大到 24 倍。与 llama.cpp 相比，vLLM 在峰值时的请求吞吐量交付超过 35 倍。由于调度器能高效处理队列压力，从 1 到 64 个并发用户的首字延迟（TTFT）几乎保持平稳。

权衡点：在高并发下，vLLM 的 token 间延迟会略有增加，因为对于任何单个请求，大批处理量在每一步计算中都需要更长时间。对于感知响应速度与吞吐量同样重要的交互式应用，这值得去实测而不是凭空假设。

加载中…