大模型推理显存怎么计算？从模型权重、KV Cache到并发容量规划
给出大模型推理显存的工程化估算方法：分别计算模型权重、KV Cache、运行时工作区与安全余量，并解释上下文、并发、GQA/MQA、量化和多GPU并行如何改变实际容量。
- Slug
llm-inference-vram-weight-kv-cache-capacity- 更新
- 2026-08-06
- 来源
- 4
- 关系
- 3
大模型推理显存由哪些部分组成
| 组成 | 主要由什么决定 | 是否随并发/上下文明显增长 |
|---|---|---|
| 模型权重 | 参数量、权重精度/量化格式、量化元数据 | 通常不随请求并发线性增长 |
| KV Cache | 层数、KV head、head dimension、序列长度、并发/Batch、缓存精度 | 是 |
| 其他模型状态/缓存 | 模型架构与推理策略，如部分Attention/SSM状态 | 取决于架构 |
| Runtime/工作区 | 推理框架、算子、CUDA/其他运行时、图捕获、临时Tensor | 随框架与配置变化 |
| 通信缓冲 | 张量/流水线/专家并行和通信库 | 随并行策略变化 |
| 碎片/安全余量 | 内存分配器、动态请求波动、服务策略 | 项目应预留但不宜套固定百分比 |
因此，把KV Cache统一写成“权重再加10%~30%”并不可靠：短上下文低并发时可能远小于这个比例，长上下文和高并发时也可能显著更高。
模型权重：可以先做理论下限，但不要把它当总显存
权重理论大小（Byte）≈ 参数量 × 权重位宽 ÷ 8
| 权重格式 | 理论字节/参数 | 70B参数仅权重的理论量级 |
|---|---|---|
| FP32 | 4 Byte | 约280 GB |
| BF16 / FP16 | 2 Byte | 约140 GB |
| FP8 / INT8 | 1 Byte | 约70 GB |
| 4-bit | 0.5 Byte | 约35 GB |
上表只是“理想化权重数据”的十进制理论量级。实际量化格式通常还会包含scale、zero-point、group信息或部分高精度参数，模型文件也可能包含额外Tensor；因此4-bit模型不能机械按0.5 Byte/参数直接当成部署显存。
对MoE模型，“每token激活多少参数”主要影响计算量；若部署时全部专家权重常驻GPU，权重容量仍要按实际加载的总权重计算。若框架使用专家分片、CPU/SSD offload或分层加载，则按真实放置策略重新计算。
KV Cache：为什么上下文和并发会快速吃掉显存
标准自回归Transformer会缓存Attention的Key和Value，避免每生成一个新token都重新计算整个历史序列。Hugging Face Transformers文档明确说明Dynamic Cache会随生成长度增长；Static Cache则可能按最大长度预分配，因此两种策略的显存曲线并不相同。
对采用常规多头/GQA缓存布局的模型，可用下式做第一轮估算：
KV Cache Byte ≈ 2 * 层数 * 并发序列数 * 缓存序列长度 * KV Head数 * Head Dimension * KV元素字节数
公式中的“2”对应Key和Value两份缓存。Hugging Face当前Cache API给出的典型Key/Value张量形状为 [batch_size, num_heads, seq_len, head_dim]；对GQA/MQA模型，应使用实际KV head，而不是机械套用query attention heads。
适用边界：滑动窗口/分块Attention会限制部分层缓存长度；量化Cache会改变每元素位宽；MLA、线性Attention、SSM等模型可能使用不同状态结构。因此公式用于容量初筛，最终以模型实现与框架实测为准。
示例：为什么不能用“KV Cache占权重20%”这样的固定比例
假设一个仅用于演示公式的Transformer配置：32层、8个KV heads、head dimension=128、KV采用BF16（2 Byte），同时有8条序列，每条缓存32768 tokens。则：
KV Cache = 2 × 32 × 8 × 32768 × 8 × 128 × 2 Byte = 34,359,738,368 Byte ≈ 32 GiB
如果并发从8增至16，其他条件不变，这部分缓存理论上近似翻倍；如果缓存长度翻倍，同样近似翻倍。这个示例不是某个具体模型的推荐配置，只用于展示容量与并发/长度之间的关系。
从“模型能放下”到“能服务多少并发”
- 先算权重基线：按真实checkpoint/量化格式确认加载后的权重占用。
- 建立请求长度分布：记录典型、P95和最大输入长度，以及计划的最大输出长度，不只看模型标称context window。
- 按框架缓存策略估KV：确认GQA/MQA、滑动窗口、Cache精度、分页/动态缓存等实现。
- 把SLA带入并发：并发提高会同时改变KV占用、Batch、TTFT/TPOT和吞吐，不能只用“剩余显存÷单请求KV”作为生产容量。
- 压测峰值显存：覆盖长输入、高并发、模型加载/热更新等最容易触达显存峰值的场景。
Hugging Face文档还提供KV Cache offload与quantized cache等节省GPU显存的策略，但官方也提示这些方法可能引入数据搬运或延迟权衡。因此它们属于架构选项，不是“零成本扩容”。
多GPU总显存为什么不能简单理解成一个“大显存池”
| 并行/放置方式 | 显存如何分布 | 容量规划重点 |
|---|---|---|
| Tensor Parallel | 同一层权重/计算在多GPU切分，KV与工作区也按实现分片 | 看每卡最高占用和跨卡通信 |
| Pipeline Parallel | 不同层分到不同GPU/阶段 | 看各stage是否均衡，不能只看总显存 |
| Expert Parallel | MoE专家分散在不同GPU | 看专家权重、路由与All-to-All通信 |
| Data Parallel/多副本 | 每个副本通常各持一份模型 | 总显存增加不等于单副本可装更大的模型 |
| CPU/SSD Offload | 部分权重/Cache不常驻GPU | 节省显存但增加主机内存与I/O/延迟压力 |
所以“8张80GB=640GB显存”只是物理容量相加。模型能否按需要跨8卡使用，取决于推理框架、并行方式、GPU拓扑、互联带宽和具体算子支持。
企业做LLM推理容量规划，建议形成这张计算表
| 输入 | 需要记录 | 输出 |
|---|---|---|
| 模型 | 版本、参数结构、权重格式、量化方案 | 权重基线 |
| 架构 | 层数、KV heads、head dim、Attention/Cache类型 | 单token/单序列缓存模型 |
| 流量 | 典型/P95/最大输入输出长度、到达率、并发 | 缓存与服务容量 |
| 框架 | 版本、并行、Cache策略、图/工作区配置 | 运行时额外显存 |
| 硬件 | 每卡显存、GPU数、互联拓扑 | 每卡可用容量与放置方案 |
| PoC | 峰值显存、TTFT、TPOT、吞吐、OOM/稳定性 | 最终安全并发与卡数 |
赋创可以在项目中提供哪些支持
赋创可结合客户的目标模型、业务任务、现有软硬件环境和机房条件，协助把公开规格转化为可验证的AI服务器/集群候选方案，并通过模型适配、容量计算、软硬件兼容与PoC确认最终边界。涉及性能、卡数、并发或迁移收益时，以明确测试条件和实测结果为依据，不把理论峰值、路线图或厂商样例直接等同于客户生产配置。
FAQ｜常见问题
70B模型BF16推理需要多少显存？
仅按70B参数×2 Byte计算，权重理论量级约140GB（十进制）；实际推理还要加入KV Cache、运行时/工作区、通信缓冲与余量，所以不能把140GB直接当成完整部署需求。
INT4模型是不是参数量乘0.5 Byte就够了？
只能作为理想化权重下限。实际4-bit量化通常还有scale、zero-point/group元数据或部分高精度参数，具体以量化格式和框架加载后的实际显存为准。
KV Cache一般占模型权重的多少？
没有通用固定比例。它取决于层数、KV heads、head dimension、缓存精度、序列长度、并发以及Attention/Cache实现；长上下文和高并发时可以成为主要显存消耗。
模型支持128K上下文，就应该按128K给每个并发预留KV吗？
不一定。容量规划应使用真实业务的典型/P95/最大长度分布和框架缓存策略；若采用Static Cache等预分配方式，则还要按实际最大缓存配置评估。
多张GPU显存可以直接相加吗？
物理容量可以相加统计，但模型实际可用方式由Tensor/Pipeline/Expert/Data Parallel、互联和框架决定。验收应看每卡峰值与并行效率，而不是只看总显存。
方案咨询
需要把方案落到实际配置？
联系赋创获取算力、软件栈和交付路径建议。