官方详解 DeepSeek-V3 / R1 推理系统：理论利润率达 545%

IT之家 3 月 1 日报道，DeepSeek 官方在知乎上发布了题为《DeepSeek-V3 / R1 推理系统概览》的文章，深入探讨了如何通过大规模的跨节点专家并行（Expert Parallelism / EP）来扩大 batch size，降低传输延迟，并实现负载均衡。

官方指出，DeepSeek-V3 / R1 推理系统的优化目标是提高吞吐量，降低延迟。

以下是 IT之家为您整理的 DeepSeek 提出的方案：

大规模跨节点专家并行（Expert Parallelism / EP）

鉴于 DeepSeek-V3 / R1 具备众多专家，且每层有 256 个专家中仅激活 8 个，模型的高度稀疏性促使 DeepSeek 必须采用大量的 overall batch size，以便为每个专家提供足够的 expert batch size，从而实现更高的吞吐量和更低的延迟。因此，大规模跨节点的专家并行（EP）显得至关重要。

DeepSeek 通过多机多卡的专家并行策略，实现了以下目标：

• Prefill：路由专家 EP32、MLA 和共享专家 DP32，其中一个部署单元包含 4 节点，32 个冗余路由专家以及每张卡的 9 个路由专家和 1 个共享专家

• Decode：路由专家 EP144、MLA 和共享专家 DP144，部署单元由 18 节点组成，配备 32 个冗余路由专家，每张卡包含 2 个路由专家和 1 个共享专家

计算与通信的重叠

多机多卡的专家并行会引入较大的通信开销，因此使用双 batch 重叠技术来掩盖这些开销，从而提升整体吞吐量。

在 prefill 阶段，两个 batch 的计算和通信过程交替进行，从而使得当一个 batch 进行计算时，能够掩盖另一个 batch 的通信开销；

在 decode 阶段，由于不同阶段的执行时间存在差异，因此将注意力部分拆分为两个阶段，共同形成 5 个阶段的流水线，以实现计算和通信的重叠。

有关更多双 batch 重叠的详细信息，请访问其 GitHub 仓库：https://github.com/deepseek-ai/profile-data。

优化负载均衡

由于实施了大规模并行（包括数据并行和专家并行），若某个 GPU 的计算或通信负担过重，将会成为性能瓶颈，影响整体系统的效率，同时其他 GPU 会因为等待而闲置，从而导致整体利用率下降。因此，必须为每个 GPU 提供均衡的计算和通信负载分配。

Prefill 负载均衡器

• 主要问题：不同数据并行（DP）实例上的请求数量和长度差异，造成 core-attention 计算与 dispatch 发送量的不方衡

• 优化目标：尽可能使各 GPU 的计算量接近于相同（core-attention 计算负载均衡）、输入的 token 数目接近（dispatch 发送量负载均衡），以防止某些 GPU 处理时间过长。

  Decode 负载均衡器

• 核心问题：不同数据并行（DP）实例的请求数和长度相异，导致 core-attention 计算量（与 KVCache 使用量相关）和 dispatch 发送量的差异。

• 优化目标：确保各 GPU 的 KVCache 使用量尽可能相同（core-attention 计算负载均衡）、请求数量尽量接近（dispatch 发送量负载均衡）。

  专家并行负载均衡器

• 关键问题：在特定的 MoE 模型中，一些专家（expert）可能会自然而然地造成计算负荷不均

• 优化目标：达到每个 GPU 上的专家计算量均匀分布（即最小化所有 GPU 的 dispatch 接收量的最大值）。

参考架构图

线上系统的性能统计

DeepSeek V3 和 R1 的服务均使用 H800 GPU，采用与训练一致的精度，矩阵计算和 dispatch 传输使用与训练相同的 FP8 格式，而 core-attention 计算及 combine 传输则使用 BF16，这样尽可能确保了服务的效果。此外，由于白天负载较高，晚间负载较低，所以 DeepSeek 建立了一套机制：

• 白天负载高时，使用所有节点提供推理服务。

• 晚上负载低时，减少推理节点，将其用于研究和训练。

  在最近的 24 小时内（时间范围：2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3 和 R1 的推理服务总共占用的节点数，峰值时为 278 个节点，平均占用为 226.75 个节点（每个节点包含 8 个 H800 GPU）。假设 GPU 租赁费用为每小时 2 美金，总费用为 $87,072 / 天。

在这24小时统计期间，DeepSeek V3 和 R1 的数据如下：

• 总输入 token 数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。

• 输出 token 总数为 168B，平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度为 4989。

• 每台 H800 的平均吞吐量：在 prefill 任务中，输入吞吐约 73.7k tokens / s（包括缓存命中）；在 decode 任务中，输出吞吐约 14.8k tokens。以上统计涵盖了网页、APP 和 API 的所有负载。如果所有 tokens 按照 DeepSeek R1 的定价来计算，理论上一天的总收入将达到 $562,027，成本利润率为 545%。

“不过，实际收入并不会如此庞大，因为 V3 的定价相对较低，并且收费服务涵盖的只是部分，此外，夜间还会享有折扣。”

DeepSeek R1 的定价结构为：$0.14 / 百万输入 tokens（缓存命中），$0.55 / 百万输入 tokens（缓存未命中），$2.19 / 百万输出 tokens。

广告声明：文中提供的外部链接（包括不限于超链接、二维码、口令等形式）旨在传递更多信息，帮助用户更快选择，结果仅供参考。