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

> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-09-11T08:25:54.058Z
> 分类: GPU
> 原文链接: http://117.50.162.249:3000/yun/articles/2783

---

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

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

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998210885107610-05c668d3f8118b27af4d49dc2f3887e3.jpg)

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

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

- 这个模型几张 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 型号，都会影响实际开销。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998210885107528-d4ae9aa9ed480fab3598ff8e2e0937ef.jpg)

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

### 坑 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 配置建议。

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998210885107478-639a673dd725f6033e57963db9bf8bd7.jpg)

### 典型使用步骤

- 打开 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 放大到远高于权重

![](https://ucloud-blog.cn-bj.ufileos.com/imagebed/0998210885107453-b67a495d7d5d143732417db6a6c70231.jpg)

一个 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 再返工更可靠，也更省成本。