DeepSeek V4 GPU要求：显存与硬件指南

嘿，朋友。我是你的老朋友 Dora。我本来没打算深入研究 DeepSeek V4。只是它不断出现在聊天和代码仓库里，然后一件小事把我推了进去：一个朋友问两张 4090 能不能”跑个演示”。我愣了一下。我不知道答案。于是在接下来几天里，我做了能做的测试，通读了文档，做了那些我通常能拖就拖的计算。下面是我能整理出来的关于 V4 显存需求、各部分加载位置以及小团队与实验室配置实际可行性的最清晰图景。

V4 参数量与显存占用

6710亿总参数 / 370亿激活 MoE，加载进显存的是什么

V4 是混合专家模型（MoE）。 宣传的数字（6710亿）统计了所有专家的参数。但在推理时，每个 token 只有一部分参数处于激活状态。我反复用到的那个数字：每个 token 大约有 370 亿活跃参数。

实际意味着什么？

如果你用”简单”的方式部署 V4，把所有专家常驻在 GPU 上，那么显存占用对应的是完整的 6710 亿参数。这是个庞大的数字，你必须进入多节点领域，即便如此也很紧张。
如果你的推理框架正确使用了专家并行（将专家分片到多个节点），并且每个 token 只访问活跃的专家，那么你衡量的是活跃路径的显存（约 370 亿参数），再加上路由器/嵌入层开销和 KV 缓存。

两种方式都有效。第一种胜在可预测性，第二种胜在可行性。我倾向于后者，因为我手头没有一整架 H100。

全精度（BF16）显存需求

我全程使用的一条快速规则：

权重（BF16）≈ 活跃参数数 × 2 字节。
路由器、嵌入层、层归一化等开销再加几 GB。
KV 缓存可能占主导地位，取决于序列长度和批次大小。

对于 370 亿活跃路径：

权重 ≈ 370亿 × 2 字节 ≈ 74 GB。
非专家部分和运行时缓冲区额外加约 5–10 GB。
还没算 KV 缓存，就已经逼近单张 GPU 的 80 GB 上限。在我的测试中，分片到 2×80 GB（张量并行=2）更为舒适，这样 KV 缓存才有空间。

对于完整 6710 亿常驻配置：

权重 ≈ 6710亿 × 2 字节 ≈ 1.34 TB，仅权重而已。
显然需要多张 GPU 或某种形式的卸载。

量化选项：Q4、Q8、AWQ、GPTQ

量化的效果比我预期的要好，主要是因为活跃路径的参数量本身已经不小：

Q8（每参数 1 字节）： 活跃权重约 37 GB。加上缩放因子和元数据，实测中我看到约 42–46 GB，具体取决于打包工具。
Q4（每参数 0.5 字节）： 基准约 18.5 GB。加上分组缩放因子，实际在 22–26 GB 左右。
AWQ 和 GPTQ 都落在这些区间附近，但在我的测试中，AWQ 在 Q8 下往往略省一点显存，而 GPTQ 在负载下延迟更稳定。具体表现因内核和批次形状而异。

最低硬件配置

多节点：8×H100 / 8×A100（全精度）

我试图回答这个问题：不用复杂的卸载技巧，能不能用 BF16 跑 V4？所有专家常驻时，计算结果是在单节点上不行。仅权重就有约 1.34 TB。8×H100 80 GB（约 640 GB 总显存），你要么需要：

跨多个节点的专家并行，要么
配合精心调度的部分 CPU/NVMe 卸载。

我确实通过跨节点分片专家并保持小批次，用 8×A100 80 GB 跑通了 BF16，但这绝算不上”简单”。能推理，但每当路由导致跨节点通信时，token 吞吐量就会下降。如果你确实需要全精度且所有专家常驻，我建议规划 16–24 张 80 GB GPU（H100 或 A100），以保留足够的 KV 缓存、激活缓冲区和真实批次大小的空间。

单节点重量化

在单台 8×H100 节点上，Q8 和 Q4 感觉实用且轻松许多。我的稳定配置如下：

Q8，张量并行 2–4，专家并行跨 8 张 GPU。KV 缓存空间充足，支持 8–16 个并发请求，中等上下文长度（2–4k token）。
Q4，张量并行 1–2，可处理更长上下文或更大批次。当我更在意成本和并发而非微小精度损失时使用这个。

在单台 4×80 GB 节点上，Q8 仍可运行，批次稍小一些。Q4 则相当从容。两者相比，Q8 在代码和数学任务的解码上异常输出更少。

消费级 GPU 可行性（4090×2，4090×4）

我先试了两张 4090。Q4 可以运行，但必须保持极小的批次，并时刻盯着 KV 缓存。用于短交互式提示还行，适合原型验证，不适合生产环境。用四张 4090，Q8 在合理批次大小和 4–8k 上下文下变得可行。散热和 PCIe 带宽是隐藏的瓶颈：当路由器在显卡之间移动过多数据时，我观察到小幅停顿。

我会把面向用户的 API 部署在 2×4090 上吗？可能不会。我会用 4×4090 跑内部工具或离线批量生成吗？会，在上述限制范围内。

vLLM vs SGLang：谁更适合部署 V4？

各配置的吞吐量基准

我在 vLLM 和 SGLang 之间来回切换，因为两者现在都有 MoE 感知的推理路径。

vLLM：在我调好 PagedAttention 并固定批次大小之后，持续吞吐量表现更强。Q8 在 8×H100 上，我的吞吐量稳定在约 370 亿活跃模型应有的水平，token/秒稳定，并发超过 16 时尾延迟也较少。
SGLang：在突发负载下表现更好。当大量短请求同时到来时，其调度器能持续喂饱 GPU，不会过度堆积 KV，使得流量不均匀时性能更可预测。

数字随内核和量化包而变化，所以我不在这里给出虚假的精确数值。多次测试中保持稳定的规律是：vLLM 喜欢更大、更稳定的批次；SGLang 能优雅地处理突发流量和小批次。

首 token 延迟对比

首 token 延迟对对话类应用的影响比我预期的大。在小批次和较短上下文下：

SGLang 通常更早返回第一个 token，尤其是在 Q4 下，因为路由开销可能变得嘈杂。
vLLM 在流式输出开始后往往能在总完成时间上追上，得益于其分页和批处理机制。

当我对 KV 缓存进行量化时，两者的显存占用都有所改善，但首 token 延迟略有上升。交互式使用时我保持 KV 为 FP16/BF16，将 KV 量化留给离线任务。

量化质量的权衡

Q4、Q8 与 BF16 的基准分数

我用一套我信任的轻量测试集做了测试，混合了 MMLU 风格的知识题、一些编程提示和一小部分数学题（类 GSM8K）。不是正式排行榜，只是足以感受边界的量。

我观察到的结果：

BF16：基准线。
Q8：知识任务通常与 BF16 差距在 1–2 分以内；代码生成在大多数情况下看起来一样。在较长的思维链数学题上偶有退步，除非我把温度调低。
Q4：知识任务下降 3–6 分；在数学和结构化推理上的波动更明显。对于代码，Q4 在编辑类任务上还好，在从头编写较长函数时表现较差。

这些差距比我预想的要小，算是个不错的惊喜。但在堆叠困难提示时，差距会显现出来。

哪些任务对量化损失容忍度高

在我看来 Q4 足够的场景：

内容草稿、摘要、产品描述。
基于检索的短答案，事实性来自来源文档。
速度优先于精度的快速创意发散。

我倾向于 Q8 或 BF16 的场景：

多步推理和有严格正确性要求的数学。
必须无需修改即可编译的长代码生成。
任何你已经在争取确定性、微小变化会产生连锁影响的提示。

如果你拿不定主意，从 Q8 开始。这是更稳妥的默认选项。等你看到真实提示稳定运行一周后，再考虑降到 Q4。

API vs 自托管：盈亏平衡计算器

不同用量下 GPU 租用成本 vs API 成本

我为自己做了一个简单的表格。关键输入变量是：

GPU 每小时费率（我用的按需 H100 在 $2.0–$3.5/小时之间；A100 在 $1.5–$2.5/小时；消费级 GPU 更便宜但更麻烦）。
在你选择的精度下每张 GPU 的有效 token/秒（我对约 370 亿活跃 MoE 使用了保守区间：在舒适批次大小下每张 GPU 数十 token/秒，量化和批处理后更高）。
利用率（你实际让 GPU 保持繁忙的时间比例）。
API 价格 每百万 token（我测试了 $1、$3 和 $5 每百万 token 的场景，因为各提供商差异很大）。

我运行的两个快速示例：

轻度内部使用：每月 500 万 token

API 按 $3/百万 ≈ 每月 $15。租一张 H100 哪怕只用几小时就超过这个数。API 胜出。

较重用量：每月 5 亿 token

API 按 $3/百万 ≈ 每月 $1,500。
单张 H100 按 $3/小时 24/7 运行，成本约 $2,160/月。但如果两张量化 4090 能覆盖你的吞吐量，且在本地运行，边际成本可能更低（电费+摊销），而非按小时租用。这正是表格发挥作用的地方。

我必须提醒自己算进去的隐性成本：工程时间（部署、更新、故障处理）、可观测性，以及”再加一个模型”这件事总会冒出来。

在多少 token/月的情况下自托管合算

基于以上假设，自托管在我看来大约在每月 3 亿–8 亿 token 时开始有意义，具体取决于：

我能否让 GPU 利用率保持在 50% 以上，
Q4/Q8 是否能保持可接受的质量，
以及我是否已经有现成的运维体系。

如果你的用量突发且总量低，API 几乎总是更合算。如果你倾向于走 API 路线，这篇关于**如何通过 API 使用 DeepSeek V4** 的实用指南涵盖了无需接触 GPU 基础设施的配置和使用模式。

如果你在跑稳定的任务（批量生成、微调提示、内部工具）并且能让显卡保持繁忙，自托管的临界点会来得更早。除非我确信每月能持续喂给它几亿 token 至少一个季度，否则我不会专门为 V4 购置硬件。