本来以为DeepSeek开源周连续五天的开源项目已经结束了，万万没想到DeepSeek还有one more thing ，补了一个王炸开源项目第六弹：深度揭秘DeepSeek V3/R1 推理系统背后的秘密
本号第一时间给大家划个重点
V3/R1系统设计原则：效率至上！
DeepSeek V3/R1 推理系统的核心目标非常明确：更高吞吐量，更低延迟！ 为了实现这两个目标，DeepSeek 团队祭出了一个大招 —— 跨节点专家并行 (Expert Parallelism, EP)！
专家并行 (EP) 是什么神仙操作？
简单来说，EP就像是“多人协作”，把模型中的“专家”分散到多张 GPU 上进行计算。这样做有两大好处：
-
• 大幅提升 Batch Size，榨干 GPU 算力！ ???? 更大的 Batch Size 意味着 GPU 矩阵运算效率更高，推理吞吐量自然水涨船高！ -
• 专家分散，降低内存压力，更快响应！ ⚡️ 每个 GPU 只需处理一小部分专家，减少了内存访问需求，延迟也就降下来啦！
当然，EP 也不是完美无瑕的，它也带来了新的挑战：
-
1. 跨节点通信！ ???? 专家分散在不同节点，节点间的通信就成了性能瓶颈。DeepSeek 团队必须精心设计计算流程，让通信和计算“无缝衔接”，最大化效率！ -
2. 多节点数据并行 (DP) + 负载均衡！ ⚖️ EP 本身就涉及多节点，再加上数据并行，负载均衡就显得尤为重要！必须保证所有 GPU 都“吃饱喝足”，避免出现“木桶效应”。
硬核技术揭秘！如何应对 EP 带来的挑战？
DeepSeek 团队为了解决 EP 带来的复杂性，可谓是下足了功夫！他们主要从以下几个方面入手：
1.规模化跨节点专家并行 (Large-scale Cross-node Expert Parallelism (EP))
DeepSeek V3/R1 模型参数量巨大，专家数量也相当惊人 (256个专家中只有8个被激活！)。这种高稀疏性决定了模型需要 超大的 Batch Size 才能充分发挥性能。 因此，大规模跨节点 EP 是必然选择！
为了适应预填充 (prefill) 和解码 (decode) 阶段的不同特点，DeepSeek 采用了不同程度的并行策略：
-
• 预填充阶段 [Routed Expert EP32, MLA/Shared Expert DP32]： 每个部署单元跨越 4 个节点，拥有 32 个冗余路由专家。每张 GPU 管理 9 个路由专家和 1 个共享专家。 -
• 解码阶段 [Routed Expert EP144, MLA/Shared Expert DP144]： 每个部署单元扩展到 18 个节点，依然是 32 个冗余路由专家。每张 GPU 管理 2 个路由专家和 1 个共享专家。 -
• 计算-通信重叠 (Computation-Communication Overlapping)
大规模跨节点 EP 引入了巨大的通信开销。为了解决这个问题，DeepSeek 采用了 双批次重叠策略 (dual-batch overlap strategy)。 简单来说，就是把一个大的请求 Batch 分成两个 Micro-Batch，交替执行。这样，一个 Micro-Batch 的通信开销就可以巧妙地隐藏在另一个 Micro-Batch 的计算过程中！
以下是预填充阶段的计算-通信重叠示意图：
解码阶段也采用了类似的策略，但更加精细，将 Attention 层进一步细分为两步，使用了 五阶段流水线 (5-stage pipeline)，实现更流畅的通信-计算重叠
想了解更多计算-通信重叠的细节？ 猛戳这里：https://github.com/deepseek-ai/profile-data (DeepSeek 官方性能分析数据仓库)
2.最优负载均衡 (Optimal Load Balancing) ⚖️
大规模并行 (DP + EP) 带来的另一个挑战就是 负载均衡。 一旦某个 GPU 成为瓶颈，整个系统的性能都会被拖累。为了最大化资源利用率，DeepSeek 团队在负载均衡方面也做了很多优化，主要包括以下三个方面：
a. 预填充负载均衡器 (Prefill Load Balancer)
-
• 关键问题： 不同 DP 实例的请求数量和序列长度不同，导致核心注意力计算和分发发送负载不均衡。 -
• 优化目标：
* 平衡 GPU 之间的核心注意力计算负载 (核心注意力计算负载均衡)。
* 均衡每个 GPU 的输入 Token 数量 (分发发送负载均衡)，防止特定 GPU 成为性能瓶颈。
b. 解码负载均衡器 (Decode Load Balancer)
-
• 关键问题： 不同 DP 实例的请求数量和序列长度不均，导致核心注意力计算 (与 KVCache 使用量相关) 和分发发送负载差异。 -
• 优化目标：
* 平衡 GPU 之间的 KVCache 使用量 (核心注意力计算负载均衡)
* 均衡每个 GPU 的请求数量 (分发发送负载均衡)
c. 专家并行负载均衡器 (Expert-Parallel Load Balancer)
-
• 关键问题： 对于 MoE 模型，存在一些天生高负载的专家，导致不同 GPU 上的专家计算负载不均衡。 -
• 优化目标：
* 平衡每个 GPU 上的专家计算负载 (即，最小化所有 GPU 的最大分发接收负载)。
系统架构一览!DeepSeek 在线推理系统概览
整个 DeepSeek 在线推理系统架构清晰明了，各个组件协同工作，保证了高性能和稳定性。
硬核数据说话!) DeepSeek 在线服务性能统计
DeepSeek V3/R1 推理服务全部部署在 H800 GPU 上，并采用了与训练一致的精度策略：
-
• 矩阵乘法和分发传输** 使用 FP8 格式 -
• 核心 MLA 计算和组合传输** 使用 BF16格式
保证了最佳服务性能！
根据统计数据 (UTC+8 02/27/2025 12:00 PM to 02/28/2025 12:00 PM)：
单 H800 节点平均吞吐量： 预填充阶段约 73.7k tokens/s (输入，包含缓存命中)，解码阶段约14.8k tokens/s (输出)！
-
• 成本利润率高达 545%！ 这简直逆天！ -
其他关键数据：
-
• 总输入 Tokens：608B，其中 342B (56.3%) 命中 On-disk KV 缓存 -
• 总输出 Tokens：168B。 -
• 平均输出速度：20-22 tokens/秒。 -
• 平均每个输出 Token 的 KVCache 长度：4,989 tokens
DeepSeek 还根据白天和晚上的服务负载动态调整推理节点数量，实现资源的最优利用！
写在最后：
DeepSeek V3/R1 推理系统通过 跨节点专家并行 (EP)、计算-通信重叠 和 精细的负载均衡策略，实现了惊人的性能和效率！ 这不仅展现了 DeepSeek 强大的技术实力，也为大模型推理系统的优化提供了宝贵的经验
只能说deepseek太牛了，再让我震惊一会！
参考：
本文来源：AI寒武纪，原文标题：《one more thing！DeepSeek王炸开源第六弹：全面揭秘V3/R1推理系统秘密》
