GPU显存怎么选？4步算清权重与KV Cache占用

先别急着看卡型参数表，GPU显存怎么选，答案要从你的负载反推：把模型权重、KV Cache、中间张量和框架常驻开销分开算，再加一层引擎版本与显存碎片的余量，最后才落到具体显存规格。vLLM v0.27.0 在 2026 年 8 月的更新里，就同时改写了 KV Cache 的字节宽度和启动期的显存占用，说明同一模型在不同引擎版本下显存账并不固定，这也正是选显存必须留余量的原因。

推算前先问清三件事：模型多大、上下文多长、并发多少

显存推算的三个输入变量缺一不可：模型参数量、目标上下文长度、并发请求数。脱离后两者谈“7B模型需要多少显存”必然算错，因为 KV Cache 随上下文与并发几乎线性放大。动手前先收集这几项：模型权重文件大小（可据此反推参数量与精度）、线上预期的上下文长度（比如 8K 还是 32K tokens）、同时推理的最大并发请求数。

第一笔账：权重显存怎么算，FP16/FP8/INT4 三档精度换算

权重显存 = 参数量 × 每参数字节数。FP16 每个参数占 2 字节，FP8 占 1 字节，INT4 占 0.5 字节。以 7B 模型为例，FP16 权重约 14GB，FP8 约 7GB，INT4 约 3.5GB。注意这只是权重部分，还没算 KV Cache 和框架开销。下表给出常见规模的量级参考，方便你代入自己的模型：

模型参数量	FP16 权重	FP8 权重	INT4 权重
1B	~2GB	~1GB	~0.5GB
7B	~14GB	~7GB	~3.5GB
13B	~26GB	~13GB	~6.5GB
70B	~140GB	~70GB	~35GB

表中数值为按参数量×字节宽度推导的权重量级，不含 KV Cache、激活值与框架开销，也不代表任何具体型号的实测占用。

第二笔账：KV Cache 与上下文长度、并发数的乘法关系

KV Cache 的单 Token 基础推算公式是：2 × 层数（Layers）× KV头数（KV_Heads）× 头维度（Head_Dim）× 每参数字节数。这个值乘以序列长度再乘以并发数，就是 KV Cache 的总占用。该单 Token 推算式为 vLLM 官方文档给出的基础形式。上下文长度增加，KV Cache 会线性增长；并发数翻倍，KV Cache 也翻倍。FP16 与 FP8 的差别在这里同样体现：FP8 KV Cache 每个参数少 1 字节，整块缓存显著缩小。vLLM v0.27.0 在 Blackwell SM100 上深化了 FlashAttention 4 FP8 KV Cache 支持，意味着同一模型同一上下文，用 FP8 缓存能省出可观显存。

GPU显存四笔账：权重、KV Cache、中间张量、框架开销

第三、四笔账：中间张量与框架/引擎常驻开销为什么必须预留

除了权重和 KV Cache，推理过程中还有激活值、通信缓冲、CUDA 上下文等中间张量，以及显存碎片。vLLM 官方将 gpu_memory_utilization 默认设为 0.9，意思是只使用 90% 的总显存，预留约 10% 给碎片和运行时分配。关于 gpu_memory_utilization 的实际配置，可参考 vLLM部署的完整流程。这说明“可用显存”并不等于卡上标称显存。例如 24GB 的卡，实际可用约 21.6GB。因此，你算出来的理论占用必须小于这个可用值，否则容易触发 CUDA out of memory。

四步推算法完整走一遍：从模型规模到目标显存区间

GPU显存怎么选，落到操作上就是把四笔账按顺序算完：

算权重：参数量 × 每参数字节数。
算 KV Cache：单 Token KV Cache × 上下文长度 × 并发数。
算中间张量与框架开销：一般按总显存的 10%~20% 预留，或根据引擎文档设定。
加总得到理论下限，再乘 1.1~1.2 作为实际需求区间。

这样你会得到一个显存区间而不是单点数值。区间的下沿对应刚好够用但风险偏高，上沿对应更安全但可能浪费。以 7B 模型 FP16、上下文 8K、并发 4 为例（按 32 层 / 8 个 KV 头 / 头维度 128 的 GQA 结构估算）：权重约 14GB + KV Cache 约 4GB + 中间张量与框架开销约 3GB ≈ 21GB，加余量后需求落在 24GB~28GB，24GB 卡处于临界（需压低并发或上下文），稳定线上建议 32GB 及以上。注意，若换成 32 头 MHA 结构（KV 头数由 8 升到 32），单 Token KV Cache 由约 128KB 升到约 0.5MB，KV Cache 约 16GB，总需求约 33GB，加余量后建议 48GB 档位或多卡。若并发继续提升，还需考虑多卡并行，可参考 GPU集群方案。

引擎版本会改写显存账：FP8 KV Cache 与启动期优化带来的余量变化

这一节是重点：推理引擎的版本会直接改变显存账单。据 vLLM v0.27.0 官方 Release Notes（2026 年 8 月），该版本针对 DeepSeek-V4 引入了序列并行与路由优化，通过跳过空的 c128 启动节省了 448 MiB 显存，并将端到端首字延迟（E2E TTFT）降低 3.4%。同时，该版本在 Blackwell SM100 架构上深化了 FlashAttention 4 FP8 KV Cache 与 headdim-256 支持。这些优化意味着：同样的模型和硬件，升级引擎版本后显存占用可能降低。但注意，448 MiB 是 DeepSeek-V4 特定模型、特定场景下的结果，不能外推为通用节省比例。所以当你评估显存时，必须明确自己所使用的引擎版本，并在理论值基础上多留一些余量以应对版本差异。

用按量GPU实例实测显存峰值

把显存区间映射到卡型档位：什么时候单卡够用，什么时候必须上多卡

算出显存区间后，再对照卡型。常见档位有 24GB、48GB、80GB 及以上。触发换更大显存或多卡并行的信号有：长上下文（如 32K 以上）、高并发（同时几十路请求）、KV Cache 超过权重量级等。24GB 档位的典型单卡是 RTX 4090，可参考 RTX 4090云服务器的规格说明，适合 7B 级模型在中短上下文、低并发下做验证与轻量线上。若并发提升到 16，KV Cache 会翻倍，24GB 铁定 OOM，此时解法是降精度到 FP8/INT4、缩短上下文，或上 48GB 及以上档位/多卡并行。GPU显存怎么选的最后一步，是把推算区间对齐到最接近且高于上沿的显存档位，而不是卡着理论值买。

用按量资源实测显存峰值：观测指标、压测步骤与检查清单

理论推算完成后，强烈建议用真实负载验证。步骤如下：

选定目标上下文长度与并发数。
在按量计费的 GPU 实例上部署模型，跑一轮推理。
观察显存峰值、波动以及是否出现 CUDA out of memory。
记录 OOM 边界，即显存不够时的上下文或并发阈值。

NexGPU 提供多档 GPU 型号与按量计费，你可以先用小规格跑通流程，再逐步增加负载实测显存峰值，避免一次性买高或买低。这种验证成本低，且能拿到真实数据。检查清单包括：是否出现 OOM、显存利用率是否超过 90%、延迟是否满足要求。

五个常见误判：只算权重、忽略并发、把理论值当上限

误判一：只算权重，忽略 KV Cache。比如 7B 模型 FP16 权重 14GB，以为 16GB 卡够用，结果跑长上下文直接 OOM。
误判二：按单请求估容量，忽略并发。实际生产环境并发高，KV Cache 成倍增长。
误判三：不留碎片余量。直接用标称显存，忽略框架预留的 10%。
误判四：忽略引擎版本差异。升级 vLLM 后显存占用可能下降，但旧版本可能更耗显存，选型时必须绑定版本。
误判五：精度切换只改权重，不改缓存。FP16 换 FP8 时，KV Cache 同样要改，否则省不下预期显存。

先按本文四步法算出区间，再在 NexGPU 的按量实例上用预制模型/应用模板快速起环境跑一轮压测，确认档位后再决定长期占用。

常见问题

7B模型需要多少显存？

以 7B 模型、FP16、上下文 8K、并发 4 为例（假设 32 层、8 个 KV 头、头维度 128，GQA 结构），权重 14GB，KV Cache 按公式单 Token 约 128KB，8K 上下文约 1GB，并发 4 约 4GB，加上中间开销约 3GB，总需求约 21GB。加余量后需求落在 24GB~28GB，24GB 卡处于临界（需压低并发或上下文），稳定线上建议 32GB 及以上。若采用 32 头 MHA 结构，KV Cache 约为 GQA 的 4 倍（约 16GB），总需求约 33GB，建议 48GB 起。

KV Cache占多少显存怎么算？

以下为按公式代入的示例推算，非实测数据。按公式 2×层数×KV头数×头维度×每参数字节数，再乘以序列长度和并发数。例如，32 层、8 个 KV 头（GQA）、头维度 128、FP16，单 Token 约 128KB，8K 上下文约 1GB，并发 4 则约 4GB。FP8 可减半。若用 32 头 MHA 结构，则单 Token 约 0.5MB，约为 GQA(8 KV 头) 的 4 倍，相应增大。