百度百舸面向 DeepSeek V3 系列模型 AE 分离框架的实战

本文整理自 2025 年 12 月 14 日的「百度百舸 X SGLang Meetup 北京站」的同名主题分享。在公众号回复「AI Infra」，可以获得此次 Meetup 下半场的 3 个演讲主题材料。📝

面对 DeepSeek-V3 等 MoE 模型部署中 FFN 计算密度不足、GPU 利用率低的痛点，百度百舸创新性地将 AF 分离（AFD，Attention-FFN Disaggregation，注意力 - 前馈网络解耦）方案落地业务实践：通过分离部署 A 实例（Self-Attention 阶段）与 F 实例（FFN 阶段），支持 FFN 配置更大输入 batch 以解决计算密度问题；再以 3BO 多级流水调度消除 A 实例 GPU 空等，用两阶段跨机通信将 RDMA 传输量降低 4-8 倍破解带宽瓶颈，最终在 100ms SLO 场景实现最高 19% 的吞吐提升。

备注：AF 分离业界亦别称 AE（Attention-Expert） 分离。

在百度智能云的线上服务场景中，针对 DeepSeek-V3/R1/V3.1/V3.2 模型，我们通常采用「DP-Attention + EP」的部署方案。

该部署方案的核心特点在于，在模型的 self-attention 阶段运用 DP 并行（数据并行）策略，而在 FFN 阶段则采用 EP 并行（专家并行）策略。具体而言，DP 并行的 self-attention 实现方式与采用 latent 方式存储请求在 transformer 层中的 KV Cache 的 MLA 架构高度适配，这种适配性带来了显著的显存空间节省效果。在 MLP 计算环节，MoE 架构的引入使得模型参数量大幅增加，为避免因 TP 切分导致输入量成倍复制，我们选择将多个专家部署在不同的 EP rank 上。

在此之前，DeepSeek 模型在部署过程中，FFN 计算密度不足的问题始终未能得到有效解决。这一问题的产生，主要有两方面原因：其一，采用 PD 分离的部署架构，使得 Decode 实例的单一请求在一轮推理中涉及的 token 数量相对较少；其二，MoE 的稀疏架构进一步降低了分摊到每个专家上的平均输入 token 数。受线上部署的 SLO（Service-Level Objective，服务级别目标）限制，以及 self-attention 阶段计算强度几乎恒定的特性影响，我们无法贸然增大 batch size 来直接解决这一问题。

换个角度思考，既然我们已经察觉到 self-attention 和 FFN 这两个阶段在 GPU 的访存模式和计算模式上存在明显差异，那么是否有可能将这两个阶段分别部署在不同型号甚至不同架构的 GPU 上，以此提高各阶段芯片的利用率，进而提升系统吞吐量或降低成本呢？答案是肯定的。

这也正是我们今天要深入探讨的部署技术——AFD（Attention-FFN Disaggregation，注意力-前馈网络解耦）技术，该技术旨在将 self-attention 和 FFN 这两个阶段分拆部署到不同节点上。无论采用异构部署与否，我们都期望通过调整两者的规模比例，获取更高的 FFN 阶段计算密度。

从逻辑层面来看，将 DeepSeek-V3 模型前向架构拆解为独立的注意力（Attention，以下简称 A 实例）和前馈神经网络（Feed-Forward Network，以下简称 F 实例），并非一项复杂的任务。

我们将 MLP 计算从推理网络中剥离出来，转而部署在额外的 F 实例上完成前向计算。在 MoE 层中，模型设置了一个共享专家。无论输入的 token 如何选择专家（即专家路由机制），该共享专家都会参与到前向计算过程中。我们选择将这个共享专家的计算保留在 A 实例中完成。

从图中不难发现，这一架构拆分面临着两大主要挑战。

其一，由于 MLP 计算被放置在 F 实例中，在同一时刻，A 实例会处于闲置状态，这无疑会降低对 A 实例所使用 GPU 的利用率。为了填补这一时间空缺，我们需要多个推理批次（我们习惯称其为微批次，即 micro batch）来构成多级前向流水

其二，传统的 EP 部署方式采用 DeepEP 通信库来完成 dispatch 或 combine 通信算子的操作，其通信语义呈现出「每个 EP rank 均参与发送和接收」的对称特性。然而，在 AFD 场景下，通信模式转变为在二分图语义下，数据仅从一个方向（子图）向另一个方向（子图）传递。这就要求我们重新审视该场景下的通信模式需求，并妥善处理可能出现的带宽瓶颈问题。

在最新版的 SGLang 框架中，两个 micro batch 交叠前向推理（2BO，Two-Batch Overlap）的调度技术已发展得颇为成熟。在输入环节，我们会把一个完整的 batch 拆分成两个规模相近的 micro batch，通过交叠前向推理的方式，让这两个 micro batch 相互掩盖彼此 batch 的通信时延。

然而，在 AFD 场景下，2BO 仍无法满足 AFD 部署的实际需求。

从 2 batch 交叠子图可以看出，单层的 micro batch 在实际完整的向前传播路径中，需要依次经历 self-attention 计算、token 分发（dispatch）、MLP 计算以及数据汇聚（combine）过程。这些操作串行完成，并且构成下一层输入的前置依赖。

由于 F 实例的计算时延与通信总时延之和，超过了一个 micro batch 的 self-attention 计算时延。这就导致不可避免地出现这样的情况：A 实例在虚线框所标注的时间窗口内，只能保持闲置等待状态。要解决这一问题，就需要引入至少一个额外的 micro batch，即采用 3BO（Three-Batch Overlap）方式，构建 3 batch 交叠子图所示的交叠前向推理流程，从而全面覆盖可能出现的 GPU 空等窗口。

基于单请求出字速度需求，我们需要将整个模型网络的前向时延，以及每一层中完整 batch 的前向时延，都严格、均摊地控制在合理范围内。

当我们从 2BO 迁移至 3BO 的逻辑流程时，可用于 self-attention 计算的时延窗口也会相应缩减至原来的三分之二。

此外，为保证算力得到充分利用，还需要在 micro batch 的内部阶段套用以下限制：

• self-attention 计算时延大于等于 F 侧的 MLP 计算时延；

• self-attention 计算时延大于总通信时延（即一次 token dispatch 加上一次 combine 的时延）。

这两种策略共同确保了 A 实例计算不会因其他阶段而产生流水气泡。

为确保与 SGLang 框架代码的兼容和复用，我们采用原生设计思路，从现有的交叠框架中拓展出了全新的 3BO 算子阶段与调度框架。

针对每一个能够应用于 3BO 流程的 transformer 层，我们为其明确声明完成完整前向传播所需的算子列表，也就是框架内的操作集（operations）。在该操作集中，可以穿插若干个 YieldOperation 标志，此标志用于标识算子阶段（stages）的边界。

算子阶段本质上同样属于算子集合，这些算子阶段共同构成了参与算子调度的合集。与操作集有所区别的是，算子阶段是由上述提及的分界标志划分得到的，且如图的第二个阶段所示，可能包含不同层的算子集合。

在调度执行阶段，首先将所有 micro batch 的算子阶段呈横向排列，再将多个 micro batch 纵向排列。调度器会按照自左向右、自上向下的顺序，依次调度执行各个算子阶段，从而完成整个完整 batch 在 3BO 模式下的前向推理过程。

我们在 3BO 算子与调度框架下，完成了 DeepSeek-V3 模型架构的推理流程实现。尽管 A 实例所涉及的算子数量更多，但其在交叠排列方面的复杂度却相对较低：我们在整个推理流程中巧妙地穿插了一个分界标志，并且在实际的算子阶段中，精心构造出一个跨层的算子阶段，该阶段从 shared（共享专家计算）起始，至 dispatch（token 分发）结束。

与之形成鲜明对比的是 F 实例，它所包含的算子集合数量较少，然而分界标志的数量却更多。不仅如此，F 实例还额外引入了初始 delay（空阶段）以及每个操作集中结尾的 nop 阶段（显式空阶段）。这些空阶段作为透传操作，用于在排列顺序上占位而不触发实际计算。

结合下图来看，在现有的调度逻辑框架下，这两种空阶段分别发挥了特定作用，分别确保了：

• 图中 [2] 处标识的 dispatch 操作超前于图中 [3] 处标识的 combine 操作；

• 图中 [2] 处标识的 dispatch 操作滞后于图中 [1] 处标识的 combine 操作；

我们将在后续针对通信展开的分析与设计工作中，进一步深入阐释如此设计的背后动机。

此前，我们提及了一个至关重要的 3BO 交叠限制条件，该条件要求在 self-attention 的计算过程中，计算时延应大于等于通信时延。然而，通过对实际业务推理时序进行采样分析，我们发现这一限制在现有的通信模式下难以得到满足。

EP 通信库为 Decode 推理角色提供了直传模式的通信语义。具体而言，所有 token 会依据自身在 A 侧完成的门控（gating）操作以及专家路由结果，经由 RDMA 网络直接传输至目的 FFN rank。

由于每个 token 都对应着 topk 个（在 DeepSeek 模型中，topk 等于 8）目标 GPU，在此情况下，传输量可用 DP batch 规模乘以 topk 因数的复杂度来衡量，而这直接成为了 3BO 模式下的带宽瓶颈所在。

根据我们的数值计算，在 DeepSeek-V3 系列模型中，当 32 路 DP-Attention 并行实例处理规模为 128 token 的 micro batch 时，若采用直传模式向 EP16 FFN 实例传递 token 和元数据，且确保带宽利用率达到 80%，那么至少需要约 550us 用于 dispatch + combine 操作。而在 50ms SLO 的约束下，这一数字已超过 400us 的时延预算。

为解决上述问题，我们将通信库设计为两阶段模式，具体如下：

• 在第一阶段，通信范围被限制在从 A 到 F 的所有同号卡之间。例如，两个 A 实例节点的 GPU 0 会将 DP batch 中的 token A 和 C 分别通过 RDMA 网络直接传输至同样是 0 号 GPU 的 FFN rank 上；

• 在第二阶段，通信过程将在 F 节点内部完成。此时，token 进一步通过机内 scale up 网络中转至其在路由阶段所选中的专家所处的 GPU rank 上。

在两阶段通信模式下，传输量的因数转变为 FFN 节点的数量，进而实现了 4 到 8 倍的 RDMA 传输量降低，成功消除了通信阶段的带宽瓶颈。

为确保实现极致的通信性能，我们要求交叠模式下的两阶段 token 转发工作在紧密的流水模式中。具体而言，当部分 token 到达后，能够以流水式的方式立即启动转发，而非等待所有 token 完整到达后再以瀑布式的方式启动转发。

这一需求使得 F 侧的编程模式被严格限定在双算子流模式。

从通信流算子的语义层面来看，我们期望 dispatch 算子能够完成 token 的 hidden states 以及其它关联数据的传输与转发。同时，出于内存管理的需求，该算子还需接收数量信息，以便 F 节点能够知晓缓存中每一个源 rank 的 token 数量。对于 combine 算子，其功能是反向完成专家结果在机内的转发、规约（依据机内有效的 topk 选择结果）以及将这些结果传回 A 实例。

计算流上，我们让 MLP 算子的调度顺序等同于每一个 dispatch 的调度顺序，从而匹配地及时开始对应的计算任务。

在推理优化过程中，保证精度和提升性能是最为重要的两项任务。

精度上，我们需要确保每一个 micro batch 内部的通信和计算互相依赖。具体地，需要实现以下两个跨算子流的状态同步：

• MLP 计算需等待 dispatch 完成；

• combine 需等待 MLP 计算完成。

性能上，为了极限挖掘交叠模式下的双流性能，我们发现可以安全地将一个 dispatch 算子超前于前一个 micro batch（若存在）的 combine 算子调度。

按照上述依赖关系和交叠时序来放置单独的 micro batch 算子并进行叠加，可得到如图下方所示的双流交叠时序。进一步而言，只要确保相邻两个 combine + dispatch 算子的执行时延小于 MLP 计算用时，就能使计算流始终处于忙碌状态，从而保证 GPU 的利用率。正是为了实现这样的交叠时序，我们在前文提及的 3BO 算子阶段排列中引入了首发 delay 空阶段和操作集中的显式空阶段。

在完成 AFD 系统的架构设计以及对关键问题的深入分析与解答后，我们成功构建了整个推理链路所需的框架、通信库，并开发了增量 AFD 算子，同时对系统性能开展了评估。

在基线部署模式方面，我们选用 4x8 卡 GPU 节点，将其部署在 DP32 + EP32 的并行策略之下；而在 AFD 模式中，我们分别采用同样的 4 节点与 2 节点，部署了 DP32 并行的 A 实例以及 EP16 并行的 F 实例。

在输入维度设置上，我们选取了取自线上服务并经过脱敏的低时延场景数据集和近线场景数据集，同时增加了一组利用 benchmark 工具生成的随机数据集，以此构成三组具有不同输入输出长度以及 SLO 限制的测试场景。

实测结果表明，AFD 部署方案在低时延场景下，其性能表现与基线部署方案相当；而在 100ms SLO 场景中，AFD 部署方案分别实现了至多 19% 的性能提升。

经过集中分析与实践，我们现有的 AFD 方案已成功达成概念验证目标，切实证实了其收益点。

从架构层面来看，AFD 无论是在差异化部署方面，还是在提升 FFN 阶段计算强度上，均通过提高不同推理阶段对芯片计算和存储性能的适配度，达成了提升吞吐量或降低成本的目的。

然而，在真实系统中，AFD 推理架构的落地面临一些挑战。

其一，在 A 实例上，我们发现因算子量提升导致的 CUDA graph launch 时延变长。通过同步使能 MTP + 异步调度特性，不仅消除了这一问题，还解决了 batch 间隙带来的性能损失。目前，该特性已在百度百舸内部上线，我们也关注到社区也在同步跟进该特性。

其二，多 micro batch 的交叠模式，对现有框架处理和上层调度基础设施提出了更高要求。为此，我们已着手改造特定场景下具备多 micro batch 交叠感知能力的调度平台，期望在细粒度的 DP micro batch 层面获取极致的均衡性。

其三，在 FFN 阶段，为在更严格的时延要求下满足对 EP 均衡性的更高要求，我们正积极跟进解决现有框架中冗余专家和专家重排等 EP 阶段策略与独立部署 FFN 产生的冲突。

最后，基于我们对 DeepSeek-V3 模型在 AFD 部署模式适配性上的剖析，AFD 有望在更低 MoE 稀疏度的模型上取得更显著的收益，拓展对这些模型的支持也是扩充 AFD 应用场景的重要任务之一。