DeepSeek-V3/R1 Visión general de los sistemas de razonamiento (DeepSeek Open Source Week Day 6)

系统设计原则

DeepSeek-V3/R1 推理服务的优化目标是：更高的吞吐量和更低的延迟。

为了优化这两个目标，DeepSeek 采用的解决方案是跨节点专家并行 (EP)。

• 首先，EP 显著扩大了批处理大小，提高了 GPU 矩阵计算效率并提升了吞吐量。
• 其次，EP 将专家分布在多个 GPU 上，每个 GPU 仅处理一小部分专家 (减少内存访问需求)，从而降低延迟。

然而，EP 增加了系统复杂性，主要体现在两个方面：

1. EP 引入了跨节点通信。为了优化吞吐量，必须设计适当的计算工作流程以将通信与计算重叠。
2. EP 涉及多个节点，因此本身需要数据并行 (DP)，并且需要在不同的 DP 实例之间进行负载均衡。

本文重点介绍 DeepSeek 如何通过以下方式应对这些挑战：

• 利用 EP 来扩展批处理大小，
• 将通信延迟隐藏在计算之后，以及
• 执行负载均衡。

大规模跨节点专家并行 (EP)

由于 DeepSeek-V3/R1 中专家数量众多 (每层 256 个专家中只有 8 个被激活)，模型的高稀疏性需要极大的总批处理大小。这确保了每个专家有足够的批处理大小，从而实现更高的吞吐量和更低的延迟。大规模跨节点 EP 至关重要。

由于 DeepSeek 采用了预填充-解码分离架构，因此在预填充和解码阶段采用了不同程度的并行性：

• 预填充阶段 [路由专家 EP32，MLA/共享专家 DP32]：每个部署单元跨越 4 个节点，具有 32 个冗余路由专家，其中每个 GPU 处理 9 个路由专家和 1 个共享专家。
• 解码阶段 [路由专家 EP144，MLA/共享专家 DP144]：每个部署单元跨越 18 个节点，具有 32 个冗余路由专家，其中每个 GPU 管理 2 个路由专家和 1 个共享专家。

计算-通信重叠

大规模跨节点 EP 引入了显著的通信开销。为了缓解这种情况，DeepSeek 采用双批处理重叠策略，通过将一批请求分成两个微批处理来隐藏通信成本并提高整体吞吐量。在预填充阶段，这两个微批处理交替执行，一个微批处理的通信成本隐藏在另一个微批处理的计算之后。

预填充阶段的计算-通信重叠

在解码阶段，不同阶段的执行时间不均衡。因此，DeepSeek 将注意力层细分为两个步骤，并使用 5 阶段流水线来实现无缝的计算-通信重叠。

解码阶段的计算-通信重叠

有关 DeepSeek 计算-通信重叠机制的更多详细信息，请访问 https://github.com/deepseek-ai/profile-data.

实现最佳负载均衡

大规模并行性 (包括 DP 和 EP) 带来了一个关键挑战：如果单个 GPU 因计算或通信过载，它将成为性能瓶颈，降低整个系统的速度，而其他 GPU 则处于空闲状态。为了最大化资源利用率，DeepSeek 努力平衡所有 GPU 上的计算和通信负载。

1. 预填充负载均衡器

• 关键问题：DP 实例之间不同的请求数量和序列长度导致核心注意力计算和调度发送负载不平衡。
• 优化目标：
  • 平衡 GPU 之间的核心注意力计算 (核心注意力计算负载均衡)。
  • 均衡每个 GPU 的输入 Ficha 数量 (调度发送负载均衡)，防止特定 GPU 上的处理时间过长。

2. 解码负载均衡器

• 关键问题：DP 实例之间不均匀的请求数量和序列长度导致核心注意力计算 (与 KVCache 使用相关) 和调度发送负载的差异。
• 优化目标：
  • 平衡 GPU 之间的 KVCache 使用 (核心注意力计算负载均衡)。
  • 均衡每个 GPU 的请求数量 (调度发送负载均衡)。

3. 专家并行负载均衡器

• 关键问题：对于给定的 MoE 模型，存在固有的高负载专家，导致不同 GPU 之间的专家计算工作负载不平衡。
• 优化目标：
  • 平衡每个 GPU 上的专家计算 (即，最小化所有 GPU 上的最大调度接收负载)。

DeepSeek 在线推理系统示意图

DeepSeek 在线推理系统示意图

DeepSeek 在线服务统计数据

所有 DeepSeek-V3/R1 推理服务均在 H800 GPU 上提供，精度与训练保持一致。具体来说，矩阵乘法和调度传输采用与训练一致的 FP8 格式，而核心 MLA 计算和组合传输使用 BF16 格式，确保最佳服务性能。

此外，由于白天服务负载高，夜间负载低，DeepSeek 实施了一种机制，在白天高峰时段在所有节点上部署推理服务。在夜间低负载时段，DeepSeek 会减少推理节点并将资源分配给研究和训练。在过去 24 小时内 (UTC+8 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00)，V3 和 R1 推理服务的峰值节点占用总数达到 278 个，平均占用 226.75 个节点 (每个节点包含 8 个 H800 GPU)。假设一台 H800 GPU 的租赁成本为每小时 2 美元，则每日总成本为 87,072 美元。

H800 推理服务节点数

在 24 小时统计期内 (UTC+8 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00)，V3 和 R1：

• 总输入 Token：608B，其中 342B Token (56.3%) 命中磁盘上的 KV 缓存。
• 总输出 Token：168B。平均输出速度为每秒 20-22 个 Token，每个输出 Token 的平均 kvcache 长度为 4,989 个 Token。
• 每个 H800 节点在预填充期间提供平均约 73.7k Token/s 的输入吞吐量 (包括缓存命中)，或在解码期间提供约 14.8k Token/s 的输出吞吐量。

以上统计数据包括来自 Web、APP 和 API 的所有用户请求。如果所有 Token 都按照 DeepSeek-R1 的定价 (*) 计费，则每日总收入为 562,027 美元，成本利润率为 545%。

() R1 定价：输入 Token (缓存命中) 0.14 美元/M，输入 Token (缓存未命中) 0.55 美元/M，输出 Token 2.19 美元/M。*

然而，DeepSeek 的实际收入远低于此，原因如下：

• DeepSeek-V3 的定价远低于 R1，
• 只有部分服务是收费的 (Web 和 APP 访问仍然免费)，
• 夜间折扣会在非高峰时段自动应用。

成本和理论收入