先给结论：没有统一配置，但有统一算法
直接回答搜索意图：DeepSeek 部署要多大显存的 GPU，取决于模型版本、精度、任务类型和并发上下文四项，把这四项定下来，配置区间就基本确定了。
- 蒸馏版 1.5B–70B 做推理：单卡 16–24GB 可起步，32B/70B 往往要 24GB 以上或双卡。
- 全量 V3 / R1 约 671B MoE：显存需求是数百 GB 量级，属于多卡 80GB 集群工程。
- 微调/训练：要在推理之外再为梯度、优化器状态和激活值留空间，通常上浮一到两个档次。
- 长上下文、高并发是第二只手：KV 缓存随上下文和批量增长，很多"显存够了却跑不动"的问题出在这里。
一、你部署的是哪一个 DeepSeek？这一步定配置量级
采购语境里的"DeepSeek 大模型"至少指两类东西，显存需求差一个数量级：
| 模型类别 | 常见规格 | 架构 | 推理显存量级（估算） | 硬件形态 |
|---|---|---|---|---|
| 蒸馏版 Distill | 1.5B / 7B / 8B / 14B / 32B / 70B | 密集结构 | 约 2GB–40GB（随精度浮动） | 单卡或双卡 |
| 全量版 V3 / R1 | 671B 总参数、约 37B 激活 | MoE 混合专家 | 数百 GB 级 | 8×80GB 以上，多机并行 |
| 微调 / 训练 | 任意规格 | 需梯度与优化器状态 | 通常是推理的 2–5 倍 | 多卡 + 高速互联 |
表中是基于参数量与精度的估算区间，不是承诺值。实际占用取决于权重格式（FP8/INT4/AWQ/GGUF）、推理框架（vLLM、SGLang、llama.cpp 等）和并发设置，下单前要以 config.json 参数和真实压测为准。
采购失误的根源，多半是把"我要部署 DeepSeek"当成一句话需求。请先写下三行字：模型版本、精度格式、推理还是微调。
二、显存怎么算：权重 + KV 缓存 + 余量，三段缺一不可
权重显存最好算：FP16/BF16 约每参数 2 字节，FP8/INT8 约 1 字节，INT4 约 0.5 字节（量化元数据会让实际值略高）。以 7B 为例，INT4 约 3.5GB，INT8 约 7GB，FP16 约 14GB。这就是同一张 24GB 卡能跑 INT4 的 32B，却跑不动 FP16 的 14B 的原因。
KV 缓存是上下文长度与并发的函数，粗略可按下面思路估算：
> KV 缓存 ≈ 2 × 层数 × KV 头维度 × 上下文长度 × 批量并发 × 每元素字节数
它带来三个后果：上下文从 4K 拉到 128K 可能翻数十倍；并发用户越多占用越大，"单用户跑得动、十人就 OOM"很常见；长上下文还有性能漂移风险——字节 Seed 团队的研究观察到超长上下文下注意力偏移、输出异常，硬件资源不足会加剧这一现象，相关分析见长上下文性能漂移的说明。
余量至少留 20%–30%，用于计算中间态、CUDA 上下文和框架开销。显存"刚好等于估算值"是典型的踩坑配置。
> 目标显存 = 权重显存 + KV 缓存（按目标上下文与峰值并发）+ 20%–30% 余量
三、精度怎么定：量化不是免费午餐
| 精度 | 显存占用 | 质量表现 | 适用判断 |
|---|---|---|---|
| FP16/BF16 | 高 | 最接近原始效果 | 精度敏感、有评测能力的场景 |
| FP8/INT8 | 约 FP16 一半 | 通常损失很小 | 多数生产推理的平衡点 |
| INT4 | 约 FP16 四分之一 | 可能损失部分能力 | 资源受限、内部工具、批处理 |
判断标准不是"量化好不好"，而是你的业务能否检测到质量下降。输出直接面向客户且难以人工校验的，优先保守精度并做 A/B 评测；内部工具与批任务，INT4 性价比通常更高。
四、为什么显存之外还要看带宽、互联和线路
GPU 配置不只是容量问题，还有三类容易被忽略的约束：
- 显存带宽决定推理吞吐。同容量下，带宽更高的卡在 tokens/s 和首字延迟上通常更稳。
- 卡间互联决定多卡效率。张量并行对互联带宽敏感，用低速互联硬凑多卡，实际加速比会明显打折。
- 网络线路决定用户体感。用户在中国大陆而服务在海外时，跨境延迟与丢包会放大长文本推理的卡顿观感；面向国内访问可优先考虑 CN2 类优化线路，面向本地用户则 BGP 多线更合适。公开的 AI API 还需要 DDoS 防护，避免攻击流量挤占推理资源。
部署位置同样影响配置取舍：数据敏感、负载稳定的业务适合独享物理资源；流量波动大、需要快速试错的阶段更适合弹性实例，本地、云端、混合的判断框架可参考部署位置决策框架。
五、三档配置清单（估算区间，下单前需压测验证）
| 档位 | 典型场景 | 模型与精度 | GPU 显存建议 | 配套要点 |
|---|---|---|---|---|
| 最小可跑 | 学习、原型、内部测试 | 蒸馏 1.5B–7B，INT4/INT8 | 单卡 12–24GB | 32GB 内存、NVMe |
| 生产稳跑 | 知识库、对外 API、中高并发 | 蒸馏 14B–70B，INT8 或量化 | 24GB×N 或 80GB×N | 64GB+ 内存、上下文截断、弹性扩容 |
| 集群级 | 全量 V3/R1 推理、微调训练 | 671B MoE 或全参数微调 | 80GB×N，多机 | 高速互联、checkpoint 存储、专业运维 |
微调可优先考虑 LoRA 等参数高效方法降低门槛，但激活值显存仍要预留；全量训练需要数据、张量、流水线并行的编排，不能套用推理配置。
对中小团队，一条务实路径是：先用轻量实例跑通原型，业务验证后再上独享 GPU 资源。比如 RakSmart 的 VPS 与 GPU 服务器产品线就覆盖了从低并发测试到多卡微调的不同阶段，判断口径仍是上面的显存与并发核算，而不是只看价格。VPS、裸机与 GPU 的取舍细节可参考两类算力的对比。
六、下单前自检清单
- 模型版本：蒸馏版还是全量 MoE？具体参数量是多少？
- 精度格式：FP16、FP8、INT8 还是 INT4？是否做过量化校验？
- 任务类型：推理、微调还是训练？峰值并发与目标上下文长度是多少？
- 显存核算：权重 + KV 缓存 + 20%–30% 余量，是否留出冗余？
- 配套核算：内存、CPU、NVMe 是否与 GPU 匹配，有没有木桶短板？
- 网络核算：用户在哪、机房在哪、线路与延迟是否满足实时交互？
- 扩展核算：流量高峰能否快速扩容？是否需要资源隔离与防护？
- 验证核算：是否有小规模压测数据支撑采购，而不是凭参数量拍板？
常见问题
只跑 DeepSeek 蒸馏版做内部测试，最低什么配置？
7B 级 INT4/INT8 模型，单张 16–24GB 显存的卡通常能跑通基础推理，配套 32GB 内存和 NVMe。这是"能跑"的下限，多用户并发或长上下文要按 KV 缓存公式重新核算。
671B 全量模型能用几张消费级显卡硬跑吗？
不建议。全量 MoE 权重本身就是数百 GB 量级，消费级显卡的显存与卡间互联都难以支撑，通常需要多张 80GB 专业卡并配合多机并行框架。商用场景应按集群方案评估成本与运维。
显存刚好够权重、不够 KV 缓存会怎样？
典型表现是单请求正常、并发一高就 OOM 或频繁抢占。解决顺序是：降低上下文长度或并发批量、启用 PagedAttention 类显存管理、再考虑加卡，而不是直接换更贵的机器。
长上下文输出不稳定，换更高配 GPU 能彻底解决吗？
不能。硬件只能缓解资源不足带来的加剧效应，性能漂移本身还涉及模型特性，业务侧仍需做长文本分片、上下文截断与检索优化，配置与优化要同时做。
只调用 DeepSeek API，本地还需要买 GPU 吗？
不需要。调用方的关注点是网络稳定性、超时重试与并发限流；GPU 配置是模型服务提供方要解决的问题。
结论
把配置算准的路径是固定的：确认模型版本 → 按精度算权重显存 → 按上下文与并发算 KV 缓存 → 加 20%–30% 余量 → 再校验内存、存储与网络。走完这条链，剩下的只是在独享硬件与弹性实例之间做成本取舍。
建议先用最小可跑档位打通推理闭环，拿到真实的显存占用、吞吐与延迟数据，再决定加卡、换卡还是调参数。如果你正准备评估海外 GPU 节点或需要面向国内用户提供服务，可以带着模型版本、精度、并发和目标地域这几项参数去核对具体机型与线路，选型会更有依据。