部署大模型到底要买几张 GPU？我的判断标准：别只看参数量，先算 KV Cache

结论先说：评估“大模型要几张 GPU”时，不能只看 7B、70B、100B 这种参数量，也不能只问 4090、H200、B200 能不能跑。真正影响上线稳定性的，是“模型权重 + KV Cache + 运行开销”三部分显存，尤其是 KV Cache。

我的判断标准很简单：先按真实业务场景确定模型、精度、上下文长度、并发数和 batch size，再计算显存需求，最后再讨论 GPU 型号和张数。只凭经验报卡数，很容易出现两种结果：要么买多了浪费预算，要么买少了上线 OOM。

一、问题背景：为什么“几张卡跑得动”不是一个好问题

很多团队在做大模型部署选型时，第一反应是问：

• 这个模型几张 4090 能跑？
• 换成 H200 或 B200 要几张？
• 7B、70B、100B 模型分别需要多少显存？

这些问题不是不能问，而是问得太早了。

因为大模型推理的显存消耗不是一个固定值。模型权重相对固定，但上线后并发请求、上下文长度、batch size、推理框架开销都会影响显存。低并发 demo 能跑，不代表生产环境能跑。

最典型的情况是：测试时单用户、短上下文，一切正常；上线后真实用户并发上来，长文档、长对话、RAG 请求变多，显存突然被打满，最终 OOM。

所以，显存规划更适合按照“问题—计算—验证”的方式来做：

• 先明确业务场景和真实请求规模；
• 再计算模型权重、KV Cache 和运行开销；
• 最后用工具和压测结果验证 GPU 配置。

二、核心痛点：真正容易被低估的是 KV Cache

大模型推理显存通常可以拆成三部分：模型权重、KV Cache 和运行开销。这个拆分方式适用于多数 Transformer 架构大语言模型的推理部署场景。

显存组成 含义 是否随并发变化 主要影响因素 模型权重 模型参数本身占用的显存 否 参数量、精度类型 KV Cache 推理过程中保存的 Key/Value 缓存 是 上下文长度、并发数、模型结构 运行开销 激活、中间状态、CUDA 上下文、显存碎片等 部分相关 推理框架、batch size、硬件与调度方式

1. 模型权重：相对固定的成本

模型权重是显存中的固定成本。简单理解，就是参数量乘以每个参数占用的字节数。它和并发请求数没有直接关系。

以 7B 模型为例，FP16 精度大约占 14 GB，INT8 大约占 7 GB，INT4 大约占 3.5 GB。量化确实可以明显降低权重占用，但它解决的是固定成本问题，不会自动消除并发和长上下文带来的 KV Cache 压力。

2. KV Cache：生产环境最容易失控的变量

KV Cache 是推理过程中保存注意力计算里 Key 和 Value 的缓存。每处理或生成一个 token，系统都需要保存对应的 K/V 信息，后续 token 才能复用上下文。

可以把 KV Cache 粗略理解成：

单 token 的 KV 占用 × 上下文长度 × 并发请求数

这意味着：

• 并发翻一倍，KV Cache 通常也会随之增长；
• 上下文长度翻一倍，KV Cache 也会随之增长；
• 长上下文和高并发叠加时，显存压力会非常明显。

长文档问答、长对话、代码理解、知识库问答、RAG 等场景，都不能只按 2K 或 4K 上下文做估算。如果业务实际可能跑到 32K、100K，甚至更长上下文，就必须按真实上限来规划。

3. 运行开销：要留安全边界

除了权重和 KV Cache，还要给运行开销留空间。运行开销包括中间激活、CUDA 上下文、显存碎片、推理框架自身占用等。

经验上，初步估算时可以预留模型权重的 15% 到 20%，再额外预留 1 到 2 GB。这个值适合作为容量规划的安全边界，但不能当作所有场景的绝对标准。

不同推理框架、batch size、并行策略和 GPU 型号，都会影响实际开销。

三、手算显存时最容易踩的三个坑

坑 1：只算权重，忘了 KV Cache

只看模型参数量，会明显低估线上显存需求。

一个模型在单请求、短上下文下能跑，不代表它能承受真实并发。尤其在高并发推理场景中，KV Cache 会随着请求数增长，最后可能成为显存消耗的主体。

坑 2：用 demo 上下文长度估算生产环境

很多 demo 环境只跑 2K 或 4K 上下文，看起来显存很宽裕。但生产环境里，长文档、长对话、RAG 检索增强生成等场景，经常需要更长上下文。

KV Cache 和上下文长度是线性相关的。用短上下文结果去推断长上下文部署，很容易得到错误的 GPU 数量。

坑 3：把量化当成唯一解法

INT4、INT8 等量化方式能降低模型权重显存，这一点没问题。

但高并发下，KV Cache 仍然会继续增长。量化省下的是权重部分显存，不能单独解决长上下文和高并发带来的缓存压力。

四、不同估算方案怎么选

企业做 GPU 采购或部署方案评估时，常见有三种方式。

方案 优点 风险 适合场景 按经验估算 快，沟通成本低 容易忽略上下文、并发和 KV Cache 非正式预估、早期讨论 手动套公式计算 可解释性强，能理解显存构成 模型结构参数容易填错，维护成本高 技术团队内部验证 使用显存计算工具 可以直接调整模型、并发、上下文和精度 结果仍需结合压测验证 采购评估、上线前容量规划、方案对比

我的建议是：早期可以用经验做粗估，但进入采购和上线前评估时，应该用工具把模型权重、KV Cache、运行开销和 GPU 张数都算清楚。

原因很现实：手算公式并不复杂，难点在于参数容易填错。不同模型的层数、KV 头数、隐藏维度不一样，手动查参数再代入公式，很容易产生偏差。模型也在持续更新，只按宣传口径或旧参数估算，落地时可能和真实结构不一致。

五、为什么我会用 UCloud LLM 显存计算器做初步判断

UCloud 提供了一个免费的 LLM 显存计算器，访问地址是：https://playground.ucloud.cn/#apps 。

它比较适合用在几个阶段：

• 模型选型；
• GPU 采购前评估；
• 上线前容量规划；
• 长上下文能力评估；
• 推理成本测算；
• 多种 GPU 方案对比。

这个工具的价值不在于“替你做最终决定”，而是把几个关键变量放在同一个计算流程里：模型、精度、上下文长度、并发数、batch size、权重显存、KV Cache、总显存和 GPU 配置建议。

典型使用步骤

• 打开 UCloud LLM 显存计算器：https://playground.ucloud.cn/#apps 。
• 选择需要部署的大模型。
• 设置精度类型，例如 FP16、FP8、INT8 或 INT4。
• 按真实业务输入上下文长度、并发数和 batch size。
• 查看模型权重、KV Cache、总显存占用和 GPU 配置建议。
• 对比 4090、5090、L40S、A100、H100、H200、B200 等硬件方案。

工具输出的信息怎么用

输出项 价值 权重显存 判断模型固定显存成本 KV Cache 显存 判断并发和上下文带来的动态压力 总显存 评估部署是否会 OOM GPU 张数建议 辅助采购和部署规划 模型下载量与提交信息 辅助判断模型热度与来源 优化信息 辅助判断模型是否适合实际部署

这里要强调一点：显存计算器更适合做容量评估和方案比较，不等于最终性能承诺。吞吐、延迟和稳定性，仍然要靠真实压测验证。

六、实际案例：并发会把 KV Cache 放大到远高于权重

一个 753B 大模型，在 FP8 精度、100 万 token 上下文条件下，UCloud LLM 显存计算器给出的总显存需求为 902 GB。对应推荐配置为 6 张 B200 或 8 张 H200，同时也会列出 4090、5090、L40S、A100、H100、H200 等 GPU 的所需数量。

另一个更能说明并发影响的场景是 101B 模型。当并发设置为 50、上下文长度设置为 100 万 token 时，KV Cache 达到 5,231 GB，而模型权重为 325 GB。此时总显存达到 6,025 GB，KV Cache 约为权重的 16 倍。

这组结果很能说明问题：真实部署不能只看模型大小。并发和上下文长度一旦进入生产级规模，KV Cache 可能成为决定 GPU 数量的核心因素。

七、企业选型时，我会重点看这几个问题

如果是企业内部做部署方案评审，我建议不要直接讨论“买几张卡”，而是先把下面几个问题问清楚。

1. 模型到底是哪一个版本

不要只说“百亿模型”或“某某系列模型”。不同模型结构不同，KV Cache 的计算结果也会不同。最好明确到具体模型名称和版本。

2. 精度类型是什么

FP16、FP8、INT8、INT4 对权重显存影响很大。量化能降低固定成本，但也要评估精度、性能和部署框架支持情况。

3. 最大上下文长度按什么口径

不能只按 demo 长度。要看业务真实上限，比如客服对话、知识库问答、长文档分析、代码仓库理解等场景分别需要多长上下文。

4. 并发数是否接近真实线上峰值

平均并发和峰值并发差异很大。显存规划至少要覆盖关键业务峰值，否则上线后最容易出问题。

5. batch size 和推理框架怎么设

batch size、调度方式、并行策略、推理框架都会影响显存和吞吐。显存够用只是第一步，最终还要看延迟和吞吐表现。

八、适合和不适合的场景

适合使用显存计算器的场景

UCloud LLM 显存计算器更适合这些场景：

• GPU 采购前评估；
• 模型上线前容量规划；
• 多模型选型比较；
• 长上下文能力评估；
• 推理成本预算；
• 研发、算法、运维和采购团队共同讨论配置边界。

研发团队可以用它判断模型是否具备部署可行性；运维团队可以估算显存水位；采购团队可以对比不同 GPU 方案的成本边界。

不适合把它当成唯一依据的场景

显存计算结果不等于最终吞吐性能。

真实上线还会受到很多因素影响，包括推理框架、并行策略、网络、CPU、存储、调度策略和请求分布。因此，显存估算应该和压测结果一起使用。

如果目标是确定生产环境 SLA，比如首 token 延迟、平均延迟、P99 延迟、吞吐量和稳定性，就不能只看显存，还要做完整压测。

九、我的决策流程：先算显存，再谈 GPU 数量

下一次评估“大模型需要几张卡”时，我不建议直接凭经验报数。更稳妥的流程是：

• 明确模型名称、参数量和精度类型；
• 明确最大上下文长度，而不是只看 demo 场景；
• 明确真实并发请求数和 batch size；
• 计算模型权重、KV Cache 和运行开销；
• 对比不同 GPU 型号所需张数；
• 用压测验证吞吐、延迟和稳定性。

这个流程主要降低两类风险：

• 买少了，上线后 OOM；
• 买多了，GPU 预算被浪费。

显存估算越接近真实业务，部署方案越容易落地。

FAQ

Q1：为什么 7B 模型看起来很小，上线后还是可能 OOM？

因为 7B 的权重占用只是固定成本。上线后，KV Cache 会随着并发数和上下文长度增长。并发越高、上下文越长，KV Cache 越容易成为主要显存消耗。

Q2：INT4 量化能不能解决显存不足？

INT4 能降低模型权重占用，但不能单独解决 KV Cache 增长。高并发或长上下文场景下，仍然需要计算 KV Cache 和运行开销。

Q3：为什么要按真实线上上下文长度计算？

KV Cache 与上下文长度线性相关。用 2K 上下文估算 32K 或 100 万 token 场景，会明显低估显存需求。

Q4：UCloud LLM 显存计算器适合哪些人使用？

它适合大模型部署工程师、算法工程师、架构师、运维团队和 GPU 采购决策人员。它可以帮助团队在上线前快速评估显存需求和 GPU 配置。

Q5：显存够了是否代表部署一定成功？

不一定。显存够用只是部署成功的前提之一。真实生产环境还需要验证吞吐、延迟、稳定性、并行策略和推理框架效率。

总结建议

大模型部署的 GPU 数量，不能只靠参数量或经验判断。模型权重、KV Cache 和运行开销都要进入显存预算，其中 KV Cache 会被并发和上下文长度快速放大。

UCloud 免费 LLM 显存计算器把模型选择、并发调整、上下文设置和 GPU 配置建议放在同一个流程里。部署前先用真实业务参数计算一次，通常比上线后 OOM 再返工更可靠，也更省成本。