DeepSeek 开源周第 6 天彩蛋 – DeepSeek-V3/R1 推理系统概览

原文：Day 6: One More Thing, DeepSeek-V3/R1 Inference System Overview

通过以下方式优化吞吐量和时延： 🔧 基于跨节点 EP 的批量扩展
🔄 计算与通信重叠
⚖ 负载均衡

DeepSeek 在线服务统计数据：
⚡ 每个 H800 节点每秒输入/输出分别达 73.7k/14.8k token
🚀 成本利润率 545%

💡 希望本周的分享能为社区带来帮助，也期待与大家一起推进通用人工智能（AGI）的目标。
📖 深度解读请见：https://bit.ly/4ihZUiO

第 6 天：另一个彩蛋，DeepSeek-V3/R1 推理系统概览

系统设计原则

在服务 DeepSeek-V3/R1 的推理任务时，我们的优化目标是：更高的吞吐量（throughput）与更低的时延（latency）。

为实现这两个目标，我们采用了跨节点的 Expert Parallelism（EP）策略。

  • 首先，EP 显著提升了批量大小，从而提升了 GPU 矩阵计算效率，并带来更高的吞吐量。

  • 其次，EP 将专家分布到多个 GPU，每块 GPU 仅处理一小部分专家（减少内存访问需求），从而降低时延。

然而，EP 同时也会带来更高的系统复杂度，主要体现在两个方面：

  1. EP 引入了跨节点通信。为了实现高吞吐，需要在计算流程中精心设计，让计算与通信相互重叠。

  2. EP 涉及多个节点，因此必须结合数据并行（DP）策略，并且需要在不同的 DP 实例之间进行负载均衡。

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

  • 采用 EP 扩大批量规模，

  • 将通信时延隐藏在计算过程之后，

  • 并且进行负载均衡。

大规模跨节点 Expert Parallelism（EP）

由于 DeepSeek-V3/R1 模型含有大量专家（expert），且每层仅激活 256 个专家中的 8 个，模型存在极高的稀疏度，需要极大规模的整体批量才能保证单个专家的批量规模充足，从而实现更高吞吐量和更低时延。大规模的跨节点 EP 因此至关重要。

我们采用了预填充（prefill）与解码（decode）分离的架构，并在两个阶段使用不同的并行度：

  • 预填充阶段 [Routed Expert EP32, MLA/Shared Expert DP32]：每个部署单元由 4 个节点组成，包含 32 个重复的路由专家（routed experts），其中每个 GPU 处理 9 个路由专家和 1 个共享专家。

  • 解码阶段 [Routed Expert EP144, MLA/Shared Expert DP144]：每个部署单元由 18 个节点组成，包含 32 个重复的路由专家，其中每个 GPU 处理 2 个路由专家和 1 个共享专家。

计算与通信重叠

大规模跨节点 EP 会产生较大的通信开销。为降低通信对性能的影响，我们采用了“双批次（dual-batch）重叠”策略，将一个批次切分为两个微批（microbatch），在预填充阶段，这两个微批交替执行，其中一个微批的通信过程与另一个微批的计算过程重叠，从而隐藏通信开销并提升整体吞吐。

Communication-Computation Overlapping during Prefilling Phase.png


预填充阶段的通信与计算重叠示意

在解码阶段，由于不同阶段执行时长并不均衡，我们将注意力层（attention layer）进一步拆分为两个步骤，并使用 5 阶段流水线，保证通信与计算在更细粒度上进行无缝重叠。

Communication-Computation Overlapping during Decoding Phase.png


解码阶段的通信与计算重叠示意

更多关于我们通信与计算重叠机制的细节，可参见：https://github.com/deepseek-ai/profile-data

实现最佳负载均衡

大规模并行（包括 DP 和 EP）带来的一个核心问题是：如果某一张 GPU 在计算或通信负载上过重，就会变成整个系统的性能瓶颈，从而导致其他 GPU 空闲，无法充分利用资源。为最大化资源使用率，我们需要让所有 GPU 在计算和通信的负载方面尽可能平衡。

1. 预填充负载均衡器（Prefill Load Balancer）

  • 主要问题：不同 DP 实例内的请求数量和序列长度各不相同，导致核心注意力计算（core-attention）和发送（dispatch send）负载不平衡。

  • 优化目标：

    • 平衡各 GPU 之间的核心注意力计算量（core-attention 计算负载均衡）。

    • 确保每个 GPU 接收到的输入 token 数量大致相同（dispatch send 负载均衡），避免个别 GPU 处理时长过久。

2. 解码负载均衡器（Decode Load Balancer）

  • 主要问题：不同 DP 实例内的请求数量和序列长度各不相同，导致核心注意力计算（与 KVCache 使用量相关）和发送（dispatch send）负载不平衡。

  • 优化目标：

    • 平衡各 GPU 的 KVCache 使用量（核心注意力计算负载均衡）。

    • 使每个 GPU 接收到的请求数大致相同（dispatch send 负载均衡）。

3. 专家并行负载均衡器（Expert-Parallel Load Balancer）

  • 主要问题：对于某些 MoE（Mixture of Experts）模型，部分专家的调用量先天较高，导致专家之间的计算负载存在不平衡。

  • 优化目标：

    • 使各 GPU 的专家计算负载相对均衡（即尽量降低所有 GPU 的最大专家处理负载）。

DeepSeek 在线推理系统示意图

Diagram of DeepSeek's Online Inference System.jpg


DeepSeek 在线推理系统示意图

DeepSeek 在线服务统计数据

DeepSeek-V3/R1 的推理服务均基于 H800 GPU，并使用与训练一致的精度。具体而言，矩阵乘法和专家分发（dispatch）均采用与训练相同的 FP8 格式，而核心 MLA 计算和合并（combine）阶段则使用 BF16 格式，以保证服务性能的最优表现。

此外，考虑到白天负载高、夜间负载低，我们在白天高峰期会在所有节点上部署推理服务，夜间负载较低时则减少推理节点数量，将部分资源用于研究和训练。在过去 24 小时（UTC+8 2025/02/27 中午 12:00 至 2025/02/28 中午 12:00）的统计中，V3 和 R1 推理服务最高同时占用 278 个节点，平均占用为 226.75 个节点（每个节点包含 8 张 H800 GPU）。假设每张 H800 GPU 的租用成本为每小时 2 美元，则单日总成本约为 87,072 美元。

H800 Node Count For Inference Service.jpg


H800 推理服务节点使用情况

在这 24 小时的统计周期（UTC+8 2025/02/27 中午 12:00 至 2025/02/28 中午 12:00）里，V3 和 R1 的数据如下：

  • 总输入 token 数：6080 亿，其中 3420 亿 token（占比 56.3%）命中磁盘 KV 缓存。

  • 总输出 token 数：1680 亿。平均输出速度为 20–22 token/s，平均每个输出 token 对应的 kvcache 长度为 4989 个 token。

  • 每个 H800 节点在预填充阶段平均可实现约 73.7k token/s 的输入吞吐量（包含缓存命中的部分），在解码阶段平均可实现约 14.8k token/s 的输出吞吐量。

上述数据包含所有来自网页、APP 及 API 的请求。如果将所有 token 均按照 DeepSeek-R1 的计费标准(*) 来计费，则每日理论收入为 562,027 美元，成本利润率达 545%。

(*) R1 收费标准：输入 token（缓存命中）0.14/M、输入 token（缓存未命中）0.55/M、输出 token $2.19/M。

但我们的实际收入显著低于此估算，原因包括：

  • DeepSeek-V3 的定价远低于 R1，

  • 只有部分服务会收费（网页和 APP 访问目前免费），

  • 夜间低负载时段会自动启用折扣。

Cost And Theoretical Income.jpg


成本与理论收入示意图

See all posts