DeepSeek-V3/R1 推理系统完全拆解：跨节点专家并行、双批重叠与负载均衡

稠密模型时代的服务账本，在 MoE 上不成立了#

先回顾稠密 Transformer 的推理账本。解码阶段每生成一个 token，需要读取全部激活参数并做一次前向计算：参数量为 $P$、按 $w$ 字节存储（BF16 为 2 字节），则每 token 读取 $P \cdot w$ 字节、执行约 $2P$ 次浮点运算。以 70B 稠密模型为例：每 token 读 140 GB、算 140 GFLOPs。这个”算力需求 : 带宽需求”的比例是固定的，与并发请求数无关——因此只要把很多请求塞进同一批（batch），一次读取的参数就能被所有请求共享，带宽成本被摊薄，GPU 的算力就能被填满。这正是 Orca 的连续批处理（迭代级调度）能成为推理服务地基的原因：它把”每个请求独占一次权重读取”变成了”整批共享一次权重读取”。

MoE 模型打破了这条账本的对称性。DeepSeek-V3 是 671B 总参数的稀疏模型，每层 256 个路由专家加 1 个共享专家，top-2 路由每 token 只激活 8 个路由专家，加上共享专家，每 token 激活参数约 37B。稀疏性带来了两个稠密时代不存在的服务问题。

问题一：专家级别的 batch 太小，矩阵乘法效率上不去#

假设整体并发为 $B$（一次批处理中的 token 总数），每层激活 $k$ 个路由专家，共有 $N_{\text{exp}}$ 个专家，那么平均每个专家在一层中收到的 token 数为：

代入 V3 的参数（$k=8$、$N_{\text{exp}}=256$）：

也就是说，整体 batch 需要达到 256，每个专家平均才能分到 8 个 token。而 GPU 上矩阵乘法的效率与 batch 大小（矩阵乘的 M 维）强相关：batch 太小，Tensor Core 的乘累加阵列根本喂不满。如果像稠密模型那样用 TP（张量并行）把模型摊到几块卡上，整个集群的并发 token 都挤在少数几块卡上，每个专家拿到的 batch 可能只有个位数——矩阵乘效率惨不忍睹。官方文档的原话是：“模型的高度稀疏性决定了 DeepSeek 必须采用很大的 overall batch size，才能给每个专家提供足够的 expert batch size，从而实现更大的吞吐、更低的延时。“大 batch 不是可选项，是 MoE 推理的刚需。

问题二：解码是内存带宽受限，算力利用率只有 0.16%#

再算解码的带宽账。每生成一个 token，理论上需要读取全部激活参数（37B 个，BF16 下 74 GB）做计算。单请求独占一张 H800（HBM3 带宽 3.35 TB/s）时，每步的带宽开销：

对应单请求解码速度上限约 45 tokens/s。而算力侧的需求呢？每 token 约 $2 P_{\text{act}} = 74$ GFLOPs，按官方线上平均输出速率 20~22 tps 计算，需要的算力是：

H800 的 FP8 峰值算力约 990 TFLOPS，利用率只有千分之一点六。结论非常反直觉：解码阶段算力几乎完全闲置，瓶颈是”每次都要把激活参数从 HBM 读一遍”。要压榨带宽，唯一的办法还是 batch：$B$ 个并发请求共享一次权重读取，每 token 摊销的带宽成本从 $P_{\text{act}} \cdot w$ 降到 $(P_{\text{act}} \cdot w)/B$，吞吐随 batch 线性上升：

于是两个问题指向同一个答案：MoE 推理系统必须能支撑极大的整体 batch。而大 batch 需要两样东西：足够的显存放 KV Cache（每张卡都要能容纳大量并发请求的缓存），以及足够大的并行规模把专家摊开。这就是跨节点专家并行（Expert Parallelism，EP）登场的理由。

顺带一提，KV Cache 本身的读取也在消耗带宽。每输出 token 的平均 KV 长度是 4989（官方统计），如果用标准 MHA，每 token 每层要存 2 个投影后的 K、V（128 头 × 128 维 × 2 字节 × 2 ≈ 64 KB/层），61 层累计近 4 MB/token，一份 4989 token 的 KV 有约 20 GB。解码每步的带宽账是”权重 74 GB + 本卡所有并发请求的 KV”：官方每节点输出 14.8k tps，除以 8 卡得每卡约 1.85k tps，再除以单请求的带宽上限约 45 tps，可估算每卡约有 41 个并发请求同时在解码——这个量级下，MHA 的 KV 读取每步约 820 GB，直接压过权重读取成为主导开销；而 DeepSeek 用 MLA 把每 token 每层的 KV 压到 576 维（512 压缩潜在向量 + 64 维 RoPE 解耦向量），一份 4989 token 的 KV 只有约 350 MB，同样并发下每步 KV 读取约 14 GB，在总带宽中的占比从 92% 降到约 16%。MLA 不只是省显存，它直接决定了这套带宽受限的解码系统能不能跑起来——这也是本站 MLA 完全拆解 那篇文章里”KV 缩减 93.3%“的推理侧意义。

专家并行的本质#

EP 的思路是把 MoE 层的 256 个专家分布到集群的多张 GPU 上，每张卡只持有少量专家。每个 token 经过注意力层后，按路由结果把 token 的隐藏状态**dispatch（分发）到负责其激活专家的 GPU 上，由目标卡的专家做 FFN 计算，再把结果combine（回收）**回原卡。整个 MoE 层就是一次跨节点的 All-to-All 通信加上一次分布式矩阵乘。

为什么 MoE 选 EP 而不是 TP？对比两种并行的通信量：TP 把单个矩阵乘切到多卡，每层计算前后都要做 All-Reduce 之类的规约，通信量与激活参数量成正比、且每一层都要做；EP 则只需要把”被激活专家对应的 token”搬过去，通信量与每 token 激活的专家数 × 隐藏维度成正比，而且 MoE 层只占 Transformer 的一部分。对 V3 这种 256 选 8 的极端稀疏模型，EP 的通信量比 TP 小一个数量级。更重要的是显存账：TP 需要每卡持有全部专家权重，EP 下每卡只持有 1~2 个专家，省下的显存全部可以用于 KV Cache——显存越多，能容纳的并发请求越多，batch 越大。官方对 EP 收益的概括只有两句话：EP 显著放大 batch，提升矩阵计算效率与吞吐；专家分散到不同 GPU，每卡只计算少量专家（更少的访存需求），从而降低延迟。

两套并行配置：prefill 与 decode 分而治之#

因为采用了 prefill-decode 分离架构（详见后文），DeepSeek 给两个阶段配置了完全不同的并行度。以 2025 年 3 月官方概览的口径为准：

为什么两个阶段差这么多？因为两个阶段的工作特征完全不同：

• Prefill 是计算密集、吞吐导向。一次 prefill 处理整段 prompt，单步的 token 数巨大（batch 大），EP32 下每个专家分到的 token 已经足够把矩阵乘喂满；把并行度压到 4 节点，是为了把跨节点的 All-to-All 通信限制在很小的范围（4 节点间 IB 直连，节点内 NVLink 转发）。
• Decode 是带宽密集、延迟敏感。每步每个请求只产生 1 个 token，官方数据是每专家 batch 通常不超过 256 token。要让每个专家拿到足够的 batch，就必须把 256 个专家摊到 144 张卡上（EP144），把”专家的 batch 池”从单机扩大到整个集群；同时每卡只持有 2 个专家，每步只读 2 个专家的权重（几百 MB 量级），解码延迟对权重读取的依赖被降到最低。

注意到 144 × 2 = 288 = 256 + 32，这 32 个”冗余路由专家”正是负载均衡的产物：V3 的 256 个专家并非均匀热门，少数高负载专家会被复制多份部署，让它们的负载分散到多张卡上（对应 EPLB 的复制策略，详见后文）。V3 技术报告补充了冗余策略的实现细节：基于在线服务统计的专家负载，周期性（约每 10 分钟）调整冗余专家集合；prefill 阶段在确定冗余专家后，会在节点内仔细重排专家位置，在不增加跨节点 All-to-All 通信的前提下尽量平衡各卡负载。报告还披露了一个”动态冗余”的探索方向：每卡托管 16 个专家但每步只激活其中 9 个，每层 All-to-All 开始前在线计算全局最优路由方案——prefill 阶段计算量大，路由方案的计算开销几乎可以忽略。

下面这张是官方公开的在线推理系统整体架构图，可以对照着理解上面所有组件的位置关系：

图：DeepSeek 在线推理系统架构示意（图片来源：DeepSeek-V3/R1 Inference System Overview，open-infra-index 仓库）

图中可以看到系统的基本骨架：Prefill 池与 Decode 池各自是独立的最小部署单元（4 节点与 18 节点），单元内 GPU 通过 NVLink 互联、单元之间（以及 prefill 与 decode 之间）通过 InfiniBand 全互联；请求进入系统后由负载均衡器（图中的 Balancer 组件）分派到具体的 DP 实例上，prefill 完成后 KV Cache 交给 decode 池继续生成。需要说明的是，V3 技术报告（2024 年 12 月）给出的早期口径与此略有不同：报告里 decode 阶段的最小部署单元是 40 节点 320 卡（EP320），每卡只托管 1 个路由专家，另有 64 张卡专门托管冗余专家与共享专家。两版配置是不同时间点的快照——报告发布时 R1 尚未上线，3 月概览则是 V3 与 R1 合并服务后的最终形态，本文以概览口径为主，报告细节作为补充。

通信量到底有多大#

跨节点 EP 的代价是通信。先粗略估算一下通信量级：V3 的隐藏维度 $h=7168$，decode 阶段把共享专家也视作路由专家（每 token 每层激活 9 个专家），dispatch 时每个 token 要发给 9 个目标专家、每份数据是 7168 维 FP8（2 字节）；combine 时每个专家回传 7168 维 BF16（2 字节）。每层每个 token 的通信量：

61 层合计，每个输出 token 要搬约 16 MB（dispatch 与 combine 各约 7.9 MB）。单请求 20 tps 时只有约 320 MB/s，听起来不大；但按官方每节点 14.8k tokens/s 的输出吞吐换算到每卡约 1.85k tps，每卡需要约 29 GB/s 的通信带宽，已经逼近单口 400 Gbps InfiniBand（50 GB/s）的六成。这还是理想分摊后的数字——通信不是平滑流动的，而是在每个 MoE 层集中爆发，如果串行执行，通信时间会直接叠加到每步延迟上。所以官方文档明确指出：“多机多卡的专家并行会引入比较大的通信开销，因此使用双 batch 重叠来掩盖通信开销，提高整体吞吐。“

Prefill：双 batch 交错#

双 batch（dual-batch）重叠的思路很直接：把一个批次的请求拆成两个计算负载相近的 micro-batch，让它们交错执行——一个 micro-batch 在做计算时，另一个 micro-batch 的通信（dispatch/combine）正好在网络上进行；下一轮两者互换。V3 报告的原话是：prefill 阶段同时处理两个计算量相近的 micro-batch，把其中一个的 attention 与 MoE 计算和另一个的 dispatch 与 combine 重叠起来。

图：Prefill 阶段的计算-通信重叠（图片来源：同上，官方概览 Figure “Communication-Computation Overlapping during Prefilling Phase”）

这张图是典型的流水线时间轴示意：横轴是时间，两个 micro-batch（图中不同颜色）的块交替出现，每个 batch 的通信块落在另一个 batch 的计算块下方。通信是”同步发生”的——它藏在计算背后，不占用额外的墙钟时间，前提是两个 micro-batch 的计算时间足够长、足以覆盖彼此的通信时间。prefill 阶段单步计算量巨大，天然满足这个条件。DeepSeek 还在 deepseek-ai/profile-data 仓库开源了这套重叠机制的 profiling 数据，包括各 kernel 的时间线，是研究通信隐藏的宝贵一手材料。

Decode：attention 拆两段，拼出五级流水线#

decode 阶段的情况更棘手：各阶段执行时间极不均衡——attention 在解码中占比很大（要读全部 KV），而 dispatch 很短。简单双批会导致流水线气泡。DeepSeek 的解法是把attention 层拆成两个子阶段，加上 dispatch、MoE 专家计算、combine，构成一条五级流水线，两个 micro-batch 在流水线上交错推进：

图：Decode 阶段的计算-通信重叠（图片来源：同上，官方概览 Figure “Communication-Computation Overlapping during Decoding Phase”）

图中可以看到流水线的五个阶段依次排开，batch 1 的 attention 计算与 batch 2 的 dispatch+MoE+combine 同时进行——通信被 attention 的长时间计算完全遮蔽。V3 报告还补充了几个 decode 阶段的工程细节：

• 每专家 batch 通常 ≤256 token，专家 FFN 的瓶颈是内存访问而非计算。因为每张卡只持有 1~2 个专家，每步只需读几百 MB 专家权重，访存开销很小，用少量 SM 就能跑完，不会拖慢 attention。
• 把 dispatch+MoE+combine 只分配到少量 SM 上执行。H800 有 132 个 SM，DeepSeek 专门划出约 20 个 SM 承担通信相关任务（IB 与 NVLink 域间的数据转发、IB 流量聚合），避免通信 kernel 与 attention kernel 抢计算单元——这也呼应了报告 3.5 节对芯片厂商的建议：通信占用的 SM 太多，Tensor Core 在通信期间完全闲置。
• dispatch/combine 走 IB 点对点直传，并用了 NVIDIA 的 IBGDA 技术（InfiniBand GPUDirect Async）。

IBGDA 值得单独解释一下：它是 NVIDIA 2022 年随 NVSHMEM 2.6.0 发布的通信机制。传统 InfiniBand 通信需要 CPU 代理线程在主机侧维护连接、把网卡的工作队列（Work Queue）放在 CPU 内存里，GPU 发数据要先经 CPU 转发，CPU 成了吞吐瓶颈（现代网卡每微秒可处理几十万条消息，CPU 代理跟不上）。IBGDA 把工作队列和 doorbell 记录直接放进 GPU 显存：GPU 的 SM 直接把网卡工作描述符写进队列，写 doorbell 寄存器通知网卡，网卡通过 GPUDirect RDMA 直接从显存取数据，完成后再写回完成队列——整个收发路径上 CPU 完全消失。NVIDIA 的测试数据是：消息小于 1 KiB 时 NVSHMEM 块式 put 的吞吐最高提升 9.5 倍，2 KiB 消息即可达到峰值带宽。对 decode 这种每 token 只搬几千字节的小消息、且每步都要做的场景，IBGDA 恰好治本。

为什么长尾负载会杀死整个集群#

大规模并行系统有个冷酷的规律：最慢的那张卡决定每一步的墙钟时间。EP + DP 的集群里，各 GPU 是同步协作的（每层 All-to-All 是全局同步点），某张卡计算或通信负载过重，所有其他卡都要等它；其他卡因等待而空转，整体利用率直线下降。而不均衡的来源是天然的：请求到达时间随机、prompt 长度随机、专家热度天然不均。官方文档把这件事放在与 EP 同等重要的位置，专门设计了三个负载均衡器。

三个均衡器各管一段#

1. Prefill Load Balancer

• 核心问题：不同 DP 实例上的请求个数、长度不同，导致 core-attention 计算量（与 token 数相关）和 dispatch 发送量也不同
• 优化目标：各 GPU 的计算量尽量相同（core-attention 计算负载均衡）；各 GPU 的输入 token 数量尽量相同（dispatch 发送量负载均衡），避免部分 GPU 处理时间过长

2. Decode Load Balancer

• 核心问题：不同 DP 实例上的请求数量、长度不同，导致 core-attention 计算量（与 KV Cache 占用量相关）和 dispatch 发送量不同
• 优化目标：各 GPU 的 KV Cache 占用量尽量相同（core-attention 计算负载均衡）；各 GPU 的请求数量尽量相同（dispatch 发送量负载均衡）

3. Expert-Parallel Load Balancer

• 核心问题：给定 MoE 模型，存在一些天然的高负载专家，导致不同 GPU 的专家计算负载不均衡
• 优化目标：每个 GPU 上的专家计算量均衡，即最小化所有 GPU 的 dispatch 接收量的最大值

注意三个均衡器在”均衡什么”上微妙的差异：prefill 和 decode 均衡器管的是计算侧（core-attention 的计算量、token 数、KV 占用、请求数），因为这两个阶段的关键路径在 attention；而专家均衡器管的是通信侧——把”所有 GPU 的 dispatch 接收量最大值”最小化，即让最忙的那张卡收的数据最少。这再次印证了前面的规律：MoE 系统里通信量和计算量是两条独立的瓶颈轴，哪条轴出现长尾，哪条轴就是系统的天花板。

这套机制在开源世界里的对应物是开源周的 EPLB（Expert-Parallel Load Balancer） 项目：它以工作负载均衡为目标（把高负载专家复制多份、把专家在节点内重排），与文档中”32 个冗余路由专家”的策略一一对应；而 All-to-All 通信的底层实现对应 DeepEP 项目（支持 NVLink 与 RDMA 的低延迟/高吞吐 all-to-all kernel，FP8 dispatch）。在线概览里这三个均衡器是调度系统的一部分，运行在集群调度层，与 PagedAttention 的块表、连续批处理 的迭代级调度不在一个层面——后者解决”单实例内的内存与算力效率”，前者解决”整个集群的长尾均衡”，两者是叠加上去的关系。

为什么 prefill 和 decode 必须分开#

把这套系统串起来的骨架是 prefill-decode 分离（PD Disaggregation）：prefill（处理 prompt、生成 KV Cache）和 decode（逐 token 生成）跑在完全不同的 GPU 池上。动机前面已经埋了伏笔：prefill 是计算密集、吞吐导向，decode 是带宽密集、延迟敏感，两者混跑会互相抢占资源——一条长 prompt 的 prefill 会把同卡上所有正在解码的请求的 token 间隔（ITL）拖出尖刺。学术脉络上，这是 2023 年 Splitwise（按相位拆分 GPU 池）与 OSDI 2024 DistServe（以 goodput 为目标的分离部署）确立的思路；社区里与之互补的还有 chunked prefill——把长 prefill 切成小块与 decode 同批执行，vLLM 的实现是优先调度所有 decode，再用剩余 token 预算喂 prefill 块（见 vLLM 文档）。DeepSeek 的做法是分离到物理实例池，再在 prefill 内部用双 micro-batch 交错（本质上也是一种”切块”），并把 chunked prefill 的思想用在 decode 的双批流水线上。

分离还带来一个工程副产品：KV Cache 要跨池移交。prefill 池算好的 KV Cache 要传给 decode 池（经高速网络），这也是为什么 decode 池的 MLA/共享专家用 DP144——每张 decode 卡都要能接收并持有任意请求的 KV。DeepSeek 更进一步把 KV Cache 做到了磁盘缓存：共享前缀（如系统提示词）的 KV 直接落盘复用，官方 24 小时统计里 56.3% 的输入 token 命中了磁盘 KV 缓存——这部分请求连 prefill 计算都省了，也解释了 prefill 吞吐统计中”含缓存命中”的 73.7k tokens/s 为何如此之高。

昼夜动态调配#

最后一块拼图是资源调度：白天服务负荷高，所有节点部署推理服务；晚上负荷低，缩减推理节点，腾出的 GPU 用于研究和训练。这套”白天服务、晚上训练”的昼夜轮换机制听起来朴素，实际是集群级调度系统才能支撑的弹性能力——也是理解 DeepSeek”低成本”叙事的重要一环：同样一批 GPU，白天产生推理收入，晚上产生模型能力，资源永远在产出。