生产环境下的自托管 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 间延迟会略有增加，因为对于任何单个请求，大批处理量在每一步计算中都需要更长时间。对于感知响应速度与吞吐量同样重要的交互式应用，这值得去实测而不是凭空假设。

TGI (Text Generation Inference) 于 2025 年 12 月进入维护模式。Hugging Face 现在建议为新的生产部署选择 vLLM 或 SGLang。已经在运行 TGI 的团队应该规划迁移路径，尤其是当模型架构的变化开始在没有上游修复的情况下破坏兼容性时。

llama.cpp 是当便携性比吞吐量更重要时的正确工具。它可以在任何硬件上运行 —— NVIDIA、AMD、Intel Arc、Apple Silicon、仅 CPU —— 无需框架依赖且启动速度快。在 RTX 3090 上运行 Q4 量化 8B 模型的单用户交互应用，每秒可获得约 120 个 token，这已经足够快了。问题出现在你增加并发用户的那一刻。llama.cpp 使用简单的顺序队列：请求在处理前排队等待。响应时间随并发量呈指数级增长，使其在结构上不适合服务多个同时在线用户的应用。它也没有提供类似的 PagedAttention，因此在混合长度的工作负载下，KV 缓存浪费很高。

SGLang 值得一提，它是结构化生成和多模态工作负载中备受关注的框架。如果你的用例涉及高吞吐量的受限解码（constrained decoding）、函数调用或 JSON 输出，SGLang 的 RadixAttention（在共享公共前缀的请求之间缓存 KV）在这些特定模式下的表现可以显著优于 vLLM。

实践中的决策矩阵：

• 单用户或开发者工作站：llama.cpp
• 基于 NVIDIA 数据中心 GPU 的生产多用户服务：vLLM
• 高吞吐结构化生成或前缀密集型工作负载：SGLang
• 现有的 TGI 部署：迁移到 vLLM 或 SGLang

真实的盈亏平衡计算

支持私有化部署的理由通常被表述为“云端 API 的单位 token 成本太高”。这个计算逻辑没错，但并不完整。一个实际的 70B 规模生产环境配置每月成本约为 20,000 美元：包括两个冗余 GPU 节点、监控基础设施、网络，以及 20% 的机器学习基础设施工程师的时间。最后这一项正是各团队经常忘记计入的成本。

云供应商收取的合规溢价也日益增长。数据驻留保证和零保留协议会为企业级 API 合同增加 20–40% 的成本。一些供应商仅针对“仅限美国境内处理”这一项就会收取倍数级的费用。对于医疗（HIPAA）、金融（SOX/PCI-DSS）、政府（FedRAMP）等受监管行业的团队来说，云端 API 的合规成本可能高到足以降低私有化部署的盈亏平衡点。

尽管如此，LLM API 的价格在 2025 年到 2026 年间下降了约 80%。在 2024 年的业务量下让私有化部署显得极具吸引力的单位 token 成本，在目前的费率下已不再适用。盈亏平衡的阈值大致如下：

• 每月 API 支出低于 2 万美元：留在托管服务。私有化部署的运维开销将超过节省的成本。
• 每月支出 2 万至 8 万美元：优先优化路由。将高频、低风险的请求发送给较小的模型，通常可以在不增加基础设施负担的情况下实现同样的成本节省。
• 每月支出超过 8 万美元：根据你的实际流量分布进行详细的混合方案分析。将高频工作负载进行私有化部署，同时保留尖端模型（Frontier Model）的接入以处理极端情况，通常能实现最佳的经济效益。
• 有数据驻留要求：无论用量多少，针对这些特定的工作负载进行私有化部署。

模型质量差距是这项计算中隐藏的考量因素。如果你的用例中哪怕只有 20% 需要尖端水平的推理能力——即只能从最大的专有模型中获得的那种能力——你最终还是得维护一套混合基础设施。私有化部署节省的成本需要根据运行两套推理栈（而非一套）的负担来重新计算。

实际容量规划流程

在规划私有化 LLM 部署的容量时，请按以下步骤操作：

首先，确定你的模型权重内存。根据你的质量要求选择合适的精度——如果你使用的是现代数据中心 GPU，选择 FP8；如果你受限于显存且你的用例可以接受折中，选择 INT4；如果准确性不容妥协，选择 FP16。

其次，估算你的 KV 缓存（KV Cache）需求。取预期的上下文长度，乘以该模型在你选定精度下的单位 token KV 成本，再乘以你的峰值并发请求数。额外增加 30–50% 的冗余空间。这个数字通常会让人们感到惊讶。

第三，加上框架开销（通常为 2–4 GB 用于 CUDA 驱动和 PyTorch 内核，外加占剩余 GPU 显存 5–20% 的 vLLM 安全缓冲区）。

第四，将总显存（VRAM）需求与可用的 GPU 配置进行对比。如果单个 GPU 无法容纳这些数字，在假设需要双倍硬件之前，先评估张量并行（Tensor Parallelism）的开销。

最后，在真实的负载下进行验证。单次请求的基准测试具有误导性。在生产环境中真正重要的指标是在实际 P99 并发下的首字延迟（TTFT）和 Token 间延迟，而非合成的峰值吞吐量数据。

大多数团队容易犯的错误

最常见的错误是根据模型大小而非工作负载来规划容量。一个团队如果将 70B 模型部署在两块显存冗余充足的 A100-80GB GPU 上，当用户第一次打开一份长文档时，他们就会遇到显存溢出（OOM）错误，因为没人计算过 50 个 4K 上下文的并发请求会对 KV 缓存消耗产生什么影响。

第二个错误是将推理框架视为以后再解决的实现细节。PagedAttention 与朴素的 KV 缓存预分配并非微小的优化——在相同的硬件上，它是服务 8 个并发用户与 24 个并发用户之间的区别。这个决策应该属于架构阶段。

第三个错误是在所有层上运行 INT4 量化，并假设质量下降是均匀的。事实并非如此。注意力机制比 FFN（前馈网络）权重更敏感。采用混合量化方案（注意力机制使用 FP8 或 INT8，其余部分使用 INT4）的团队，通常可以在保留显存优势的同时，挽回大部分全 INT4 量化带来的质量损失。

私有化部署 LLM 是一门基础设施学科，而不仅仅是模型部署。成功的团队会将 KV 缓存视为需要管理的一等资源，根据并发配置文件而非单用户基准测试来选择推理框架，并诚实地记录在大规模环境下运行可靠推理所需的工程开销。