部署 DeepSeek 大模型时，最常见的失误是把“显存要求”当成一个固定数字：查一下参数量，乘以 2 字节，然后直接下单 GPU。实际运行时，模型能加载，但一开长上下文就 OOM；或者显存看着够用，用户端依然首响应慢、流式输出断续。
先给结论：DeepSeek 大模型的显存要求不是单一数值，而是一张随业务负载变化的预算表。 权重显存取决于参数量与精度，KV 缓存随上下文长度与并发数近似线性增长，推理框架还要预留运行时开销；因此实际选卡时，应在权重显存的 1.5～3 倍范围内取档，并以目标负载实测验证，而不是照抄参数表。
一、显存占用的三段构成，一句话记住
先明确三块显存的来源，后面的定档才有依据：
> 总显存预算 ≈ 模型权重显存 + KV 缓存 + 运行时开销
- 权重显存：
参数量（B）× 每参数字节数。FP16/BF16 约 2 字节，INT8 约 1 字节，INT4 约 0.5 字节。这是硬门槛——放不进去就无法加载。 - KV 缓存：
2 × 层数 × KV头数 × head_dim × 每值字节数，再乘以目标上下文长度与并发请求数。这是长对话、大文档场景的主要变量。 - 运行时开销：调度、激活缓冲、CUDA 上下文等，随推理框架与注意力实现不同而变化，通常按权重的 0.5～2 倍预留。
一个值得注意的点：DeepSeek 的部分模型采用 MoE（混合专家）架构。每次推理只激活一部分专家，影响的是计算量，而权重显存取决于完整模型是否常驻显存。判断 MoE 版本的显存需求时，应以官方模型卡的权重格式、推荐部署配置和社区实测为准，不要用激活参数量套公式。
二、三种业务负载，对应三档显存预算
真正决定显存档位的不是模型名字，而是你的业务怎么用它。下面这张表按典型负载给出取档参考，数值以“权重显存 + 建议总显存”呈现，总显存已含 KV 缓存与运行时余量，具体以模型版本、框架与量化方式实测为准。
| 业务负载 | 典型配置 | 权重显存参考 | 建议总显存 | 下单前必须验证的指标 |
|---|---|---|---|---|
| 个人调试、Prompt 验证 | 7B 级 INT8 | 约 7 GB | 16～24 GB | 能否加载、短上下文稳定回复 |
| 内部问答、轻量知识库 | 14B 级 INT8 或 FP16 | 约 14～28 GB | 24～48 GB | 4K～8K 上下文下的显存峰值 |
| 公网 API、中低并发服务 | 14B～32B 级，INT8/FP16 | 约 28～64 GB | 48～80 GB 或多卡 | 并发 4～8 时的排队与首 Token 延迟 |
| 长上下文、高并发生产 | 32B+ 或 600B 级 MoE，FP8/量化 | 64 GB 以上或数百 GB | 160 GB 或多卡集群 | 峰值并发下显存余量是否 ≥20% |
读表时要区分两件事：“模型能跑起来”和“模型能承载你的并发”是两个不同的达标线。调试场景向下取档没有问题；面向公网的付费服务则应向上取档，因为 KV 缓存会随并发近似线性增长——测试时单用户一切正常、上线后集体 OOM，几乎都发生在这一步。
如果业务允许，还可以在显存预算内反向调参：限制最大上下文长度、启用请求队列、按优先级调度，用确定性的容量换取稳定的用户体验。
三、显存达标但推理仍慢，瓶颈通常在哪
显存核算无误后，问题往往转移到算力、调度和网络三个层面，排查顺序建议如下。
算力与显存带宽。 推理要把数据持续喂给计算核心，GPU 算力不足拉长生成时间，显存带宽不足则限制 Token 输出速度。典型表现是模型加载正常、但首响应慢、流式吞吐低——这类问题加显存解决不了，选型时必须同时核对 GPU 型号的算力与带宽。
推理框架与调度。 单请求串行处理无法利用 GPU 并行能力。支持连续批处理的推理框架可以在同一块显存上并发服务多个请求，把“显存够但吞吐低”的问题转成可优化的调度问题；量化与高效注意力实现还能同步降低显存与读写压力。
跨境网络回程。 如果模型部署在海外、用户在国内，网络会直接进入关键路径：往返时延拉长首 Token 响应，丢包与抖动导致流式输出断续，带宽不足则拖慢模型文件传输与批量任务。对实时交互型 AI 应用，线路质量与显存容量同等重要，这是选型时最容易被忽略的隐性要求。部署位置本身也很关键，可先回答数据敏感度与算力波动这两个问题——本地、云端还是混合，思路可参考《我该把AI模型部署在哪里？从0到1的完整决策框架》。
四、下单前的定档清单
在提交配置或扩容前，逐项确认以下内容，可以显著降低选错硬件的概率：
- 明确模型版本与权重格式：确认 FP16/FP8/INT8/INT4 与实际文件体积，而不是只看参数量
- 确认目标上下文长度：用 KV 缓存公式估算单请求占用，再乘以期望并发数
- 按权重显存的 1.5～3 倍取总预算：短上下文低并发取低值，长上下文高并发取高值
- 在目标负载下实测：记录显存峰值、排队情况与首 Token 延迟，而不是只验证能否加载
- 核对 GPU 算力与显存带宽：避免“显存够、吞吐不足”
- 评估用户地理分布：国内用户访问海外节点时，验证回程线路的延迟、抖动与丢包
- 预留扩容路径：业务增长后是加卡纵向扩展，还是多节点分布式推理，提前决定可避免迁移成本
- 区分阶段需求：测试、原型、商用推理对显存和网络的要求完全不同
阶段取舍上，项目初期可以先用低成本 VPS 验证功能与 Prompt 效果，再升级到 GPU 服务器承接真实负载；两类算力的适用边界可参考《个人开发者/初创企业部署大模型：VPS与GPU服务器怎么取舍》。如果模型版本或目标并发尚未确定，也可以先用《AI模型部署怎么选？本地 / 云端 / 混合部署完整选型指南》中的判断维度收敛需求，再回到本文的显存预算表定档。
常见问题
DeepSeek 7B 模型最少需要多少显存？
以 INT8 量化做单用户调试，权重约需 7 GB，加上运行时开销后 16 GB 左右通常可以启动；若要支持 FP16 精度与中等并发，24 GB 以上更稳妥。注意这只是启动门槛，不等于生产环境的可用容量。
上下文长度翻倍，显存是否也翻倍？
KV 缓存部分近似如此：上下文长度与缓存占用基本呈线性关系。但总显存不线性翻倍，因为权重与框架开销是固定项，实际变化幅度取决于 KV 缓存在整个预算中的占比。
量化能带来多少显存收益？
量化最直接的收益是权重显存下降：INT8 约为 FP16 的一半，INT4 约为四分之一，同时也能减少 KV 缓存占用。代价是输出质量可能有可感知的下降，建议用业务真实 Prompt 做质量对比后再决定精度档位。
显存够用但用户仍反馈卡顿，应先升级什么？
先归因：GPU 利用率持续接近满载且显存经常耗尽，瓶颈在显存或算力；GPU 利用率不高、但首响应慢且网络测试显示高延迟高丢包，瓶颈更可能在回程线路或调度层。盲目加卡解决不了网络问题，反之亦然。
结论
DeepSeek 大模型的显存要求可以被精确核算，但核算必须放进具体业务场景：权重显存看参数量与精度，KV 缓存看上下文与并发，运行时开销看框架与负载特征。真正的难点是把三者合进同一张预算表，并在显存之外一起验证算力、带宽、调度与网络。
建议按本文的三档方法先写出自己的显存预算表，再带着模型版本、目标并发与用户分布去核对具体配置——这样选出来的 GPU 才真正匹配业务，而不是只匹配参数表。