Announcing vLLM AFD Plugin: Disaggregating Attention and FFN for Flexible MoE Serving

发表时间: 2026-07 · Blog post by AFD Plugin Contributors (blog.vllm.ai)

原文: https://blog.vllm.ai/blog/2026-07-23-vllm-afd-plugin

作者/机构：AFD Plugin Contributors

速读

一句话结论
vLLM AFD Plugin 通过将混合专家模型中的注意力机制与前馈神经网络拆分为可独立扩展的服务，在保持原有服务接口不变的前提下，显著提升了长上下文解码吞吐量并降低了首字延迟。

要解决什么问题
在混合专家模型（MoE）的推理过程中，Transformer 层内的注意力机制（Attention）和前馈神经网络（FFN）具有完全不同的系统扩展需求与运行时特征，而现有的服务系统强制它们共享相同的计算节点拓扑，导致资源分配严重受限。具体而言，Attention 是有状态的，其显存和计算压力高度依赖于请求调度、序列长度以及 KV Cache 的占用；而 FFN（即专家路径）则是无状态的，其性能瓶颈主要在于路由专家的计算负载和节点间的全对全通信。当这两种机制绑定在同一组 worker 上时，系统无法为它们分别制定最优的并行策略。例如，随着上下文长度增加，Attention 需要更多的节点来分担 KV Cache 压力，但 FFN 并不需要同步扩容；反之，当专家数量增加时，FFN 需要更大的专家并行度，但这会无谓地增加 Attention 的通信开销。这种架构上的强绑定使得系统在面对不同负载时，只能做出妥协性的扩展选择，无法同时最大化两者的硬件利用率。

怎么做的
核心思路是引入注意力与前馈网络解耦架构（Attention-FFN Disaggregation，简称 AFD），将 Attention 和 FFN 剥离为两个独立部署、独立扩展的服务，并通过一个极窄的连接器接口进行通信。这种设计绕开了原有拓扑绑定的卡点，使得 Attention 节点可以根据 KV Cache 压力横向扩展，而 FFN 节点可以根据专家路由负载独立配置并行度。系统主要由三个关键部件构成。首先是 Attention 服务，它保留了 vLLM 原有的请求生命周期管理，全权负责调度器、KV Cache、批处理和采样逻辑；在执行前向传播时，插件注入的模型运行器会将激活值与 AFD 元数据打包。其次是 FFN 服务，它被设计为一个轻量级的后台守护进程，完全不处理外部请求，也没有调度器和 KV Cache，仅负责接收元数据和隐藏层状态，执行路由计算后将结果返回。最后是连接器层，它定义了两个服务之间的数据交换契约，允许不同硬件后端实现专属的通信优化。为了量化解耦后的资源效率，系统使用单芯片吞吐量作为核心评估指标：

$$ \text{tokens/s/die} = \frac{\text{aggregate output token throughput}}{\text{total deployed dies}} $$


此外，针对通信与计算的重叠问题，系统设计了同步和异步两种执行路径。在同步解码场景下，GPU 使用 P2pNcclAFDConnector，NPU 使用 CAMP2pAFDConnector，在层级别同步交换隐藏层状态；在异步预填充场景下，NPU 使用 CAMAsyncAFDConnector 结合 MoE 微批处理技术，将独立的 Attention 和 FFN 阶段重叠执行，从而消除流水线停顿。

效果如何
实验在 Ascend 910C 硬件上进行，测试模型为 DeepSeek-V3.2 W8A8。在同步解码吞吐量测试中，基线方法为传统的 EP64 部署（代表 Attention 和 FFN 共享 64 个芯片的常规路由路线）。在 16K 固定输入长度下，基线单芯片吞吐量为 232.6 tokens/s/die；当采用 64 个 Attention 节点与 16 个 FFN 节点的 AFD 部署（64A16F）时，吞吐量提升至 258.9 tokens/s/die（提升 11.3%）；在 32K 输入下，64A16F 同样比基线提升了 9.0%。在异步预填充性能测试中（使用裁剪至 10 层的模型），基线为 DP4PCP8 TP1 布局，对比的 AFD 布局为 Attention DP3PCP8 TP1 加上 FFN EP8。在每秒 12 个请求的压力下，AFD 将中位数首字延迟从 15.1 秒降至 8.0 秒，降幅达 47%。作者也坦诚了该方法的代价与局限性：解耦本身不保证性能提升（例如 48A16F 配置下的吞吐量反而下降了 5.3% 到 10.0%，说明 Attention 与 FFN 的配比至关重要）；当前实现处于实验阶段，强依赖 vLLM 0.19.1 版本；Attention 和 FFN 节点目前都需要加载完整的模型权重；图模式仅支持纯解码阶段；且为了在有限机器上模拟大规模部署，实验使用了强制专家负载均衡机制，这会改变模型的实际输出结果。

主要贡献

混合专家（Mixture-of-Experts, MoE）模型的推理在Transformer层中结合了两种截然不同的计算工作负载：Attention（注意力机制）是状态相关的，与请求调度和KV Cache紧密耦合；而FFN（前馈神经网络）或专家路径则主要由路由专家计算和全对全（all-to-all）通信主导。当这两条路径共享相同的Worker拓扑结构时，服务系统必须为具有完全不同需求的负载做出统一的扩展和执行选择，这导致了效率的妥协。

为了解决这一问题，本文推出了vLLM AFD Plugin（vLLM AFD插件），这是一个实验性的外部插件，旨在将Attention与FFN解耦（Attention-FFN Disaggregation, AFD）引入vLLM生态。该插件通过将Attention和FFN分离为可独立部署的服务，在保留vLLM现有的请求生命周期和兼容OpenAI的服务接口的同时，允许Attention和FFN路径独立进行扩展。目前该项目支持NVIDIA GPU和Ascend NPU，提供同步和异步连接器，支持DeepSeek V2/V3系列模型封装，并在明确验证的限制范围内支持Eager模式、图模式以及双批处理（dual-batch）执行路径。

背景知识与设计原则

实现Attention与FFN的解耦需要解决多个系统设计层面的挑战，这些挑战和观察构成了AFD的核心设计原则：

  • Attention与FFN具有不同的扩展需求：Attention的容量需求紧随请求状态、序列长度以及KV Cache的压力变化；而专家（Expert）的容量需求则取决于Token路由和专家的负载情况。服务系统应当通过允许这两条路径使用不同的Rank拓扑结构来实现独立扩展，而不是强制要求它们采用一种共享的布局。
  • Attention与FFN具有不同的运行时职责：Attention阶段需要处理调度、KV Cache协调以及采样等复杂任务。相比之下，FFN的执行仅仅需要激活值（activations）、路由元数据以及一种返回专家输出结果的机制。将这两个服务拆分后，FFN端可以作为一个轻量级的、由连接器驱动的守护进程（daemon）运行。
  • 通信机制具有后端特异性：CUDA和Ascend（昇腾）平台暴露了完全不同的集合通信库、图运行时（graph runtimes）以及优化的MoE算子。通过建立一个通用的连接器契约（connector contract），可以在保持面向模型的流程稳定的同时，允许每个硬件后端拥有并优化其专属的数据路径。
  • 通信与计算的重叠收益：异步分发（Asynchronous dispatch）和MoE微批处理（ubatching）能够重叠独立的执行阶段，而不是将所有专家的工作序列化地阻塞在Attention路径之后。

综合上述挑战，AFD确立了其核心设计目标：保持vLLM原有面向请求的Attention路径完好无损，同时将FFN的执行转移到一个狭窄的连接器接口之后，使得FFN能够独立地进行扩展、通信和执行。

方法细节

vLLM AFD插件的运行时架构设计保持了极小的侵入性。插件通过vLLM的vllm.general_plugins入口点和标准的--additional-config通道进行集成，完全不需要修改vLLM的源代码树。

vLLM AFD插件运行时架构
vLLM AFD插件运行时架构

运行时的核心架构由以下三个主要部分组成：

  • Attention服务（Attention service）：Attention Worker保留了vLLM原有的调度器、KV Cache、批处理机制、模型生命周期管理以及采样路径。由插件所有的模型运行器（model runner）负责将AFD元数据安装到前向传播的上下文中，并将数据并行（data-parallel）、微批处理（ubatch）、层级（layer）以及图状态（graph state）发布给FFN端。
  • FFN服务（FFN service）：FFN Worker不处理任何请求流量，也没有调度器或KV Cache。它通过一个后台循环接收元数据和激活值，在插件所有的模型封装器上调用compute_ffn_output()函数，随后将计算结果发送回Attention端。所有外部请求始终只发送给Attention API服务器。
  • 连接器层（Connector layer）：在每一个分割层（split layer），连接器负责传输Attention的隐藏状态（hidden states）以及FFN服务所需的执行元数据，然后返回计算出的FFN输出。该架构定义了一个与后端无关的连接器接口来规范这种数据交换，同时允许每个后端实现其特定的通信和运行时优化。

这种集成界面的设计被刻意保持在最小范围。vLLM继续负责其现有抽象所适用的服务控制平面，而插件则提供AFD Workers、模型运行器、连接器、元数据、模型分割点以及少量受版本范围限制的兼容性补丁的实现。

连接器与后端支持
相同的顶层数据交换逻辑（将Attention输出发送给FFN，将FFN输出返回给Attention）在所有连接器之间共享。为了防止CUDA图行为、ACL图行为、NCCL通信以及Ascend自定义算子相互泄漏，不同的后端包被严格保持独立。当前支持的连接器矩阵如下：

  • P2pNcclAFDConnector：基于GPU后端，采用同步P2P执行模式，推荐用于Decode阶段，支持FULL_DECODE_ONLY的CUDA图。
  • CAMP2pAFDConnector：基于NPU后端，采用同步CAMP2P/HCCL执行模式，推荐用于Decode阶段，支持FULL_DECODE_ONLY的ACL图。
  • CAMAsyncAFDConnector：基于NPU后端，采用异步CAM执行模式，推荐用于Prefill阶段，目前暂不支持图模式。

支持的核心特性

  • 原生的vLLM服务接口：现有的vLLM用户仍然可以通过vllm serve启动服务，向兼容OpenAI的端点发送请求，并通过--additional-config配置运行时。
  • GPU与NPU实现：GPU Workers扩展了vLLM v1的类，而NPU Workers则直接扩展了vLLM-Ascend的类。共享的行为逻辑被放置在配置、拓扑、元数据和连接器契约中，避免了跨设备的继承。
  • 用于提升Decode吞吐量的同步AFD：P2pNcclAFDConnector和CAMP2pAFDConnector同步交换Attention激活值和FFN输出，允许这两个角色在面向吞吐量的Decode部署中独立扩展。它们当前的图路径分别在CUDA和ACL上使用FULL_DECODE_ONLY语义。
  • 用于Prefill的异步AFD：CAMAsyncAFDConnector利用CAM异步分发和合并算子，将Prefill阶段的Attention Ranks与专家Workers解耦。结合AFD管理的MoE微批处理，它能重叠独立的Attention和FFN阶段，从而减少流水线停顿。该路径目前主要针对Prefill/Decode解耦部署中的Prefill阶段，暂不支持图执行。
  • MoE模型集成：插件为DeepSeek V2/V3系列架构（包括DeepSeek V3.2）和GLM MoE DSA注册了封装器。该封装器暴露了独立的Attention和FFN计算逻辑，同时复用了上游的层级实现。
  • 图模式与微批处理路径：同步的GPU和NPU连接器支持仅Decode的图捕获（graph capture）。双批处理重叠（Dual Batch Overlap, DBO）支持精确的两个微批处理，且CAM异步模式为其Prefill路径提供了由AFD管理的MoE微批处理。

实验环境与结果

同步AFD Decode吞吐量评估（基于CAMP2pAFDConnector）

  • 实验环境：基于Ascend 910C硬件环境，测试模型为DeepSeek-V3.2 W8A8。
  • 实验设置：对比了传统的EP64部署架构与基于CAMP2pAFDConnector的AFD部署架构。物理拓扑包括：EP64（DP64, EP64, TP1，共64个Die）、48A16F（48个Attention Ranks, 16个FFN Ranks，共64个Die）、64A16F（64个Attention Ranks, 16个FFN Ranks，共80个Die）。由于机器数量限制，物理上的48A16F和64A16F部署用于模拟逻辑上的192A64F和256A64F规模。实验将自然的路由专家ID替换为确定性的强制平衡循环（这会改变模型输出，因此仅为性能测试），由AFDDecodeBenchConnector提供仅Decode的KV状态，并为AFD启用了DBO。
  • 评估指标：测量的是饱和Decode吞吐量，公式为：$tokens/s/die = \text{aggregate output token throughput} / \text{total deployed dies}$。输入长度固定，输出分布在512到1,536个Token之间。

16K固定输入长度结果：
DeepSeek-V3.2 16K每个Die的Decode吞吐量
EP64基线实现了232.6 tokens/s/die，48A16F实现了220.3 tokens/s/die，而64A16F实现了258.9 tokens/s/die。相对于EP64，48A16F的性能下降了-5.3%，而64A16F的性能提升了+11.3%。

32K固定输入长度结果：
DeepSeek-V3.2 32K每个Die的Decode吞吐量
EP64基线实现了168.2 tokens/s/die，48A16F实现了151.4 tokens/s/die，而64A16F实现了183.3 tokens/s/die。相对于EP64，48A16F的性能下降了-10.0%，而64A16F的性能提升了+9.0%。

结论分析：在两种输入长度下，48A16F的表现均低于EP64基线，而64A16F提供了最高的归一化吞吐量（16K时+11.3%，32K时+9.0%）。这表明Attention与FFN的分配比例至关重要，仅仅进行解耦并不能保证吞吐量的提升。观察到的趋势暗示，在测试的比例下，FFN Ranks仍然具有计算余量，并未成为计算瓶颈。因此，进一步增加Attention Ranks的比例可能会带来更多的吞吐量提升。

异步AFD Prefill性能评估（基于CAMAsyncAFDConnector）

  • 实验环境：在两个Ascend 910C节点上进行早期CAM异步实验，使用裁剪至10层的DeepSeek V3.2 W8A8模型。
  • 实验设置：使用强制专家平衡，对比了基线DP4PCP8 TP1与由Attention DP3PCP8 TP1加上FFN EP8组成的AFD布局。
CAM异步实验的TTFT中位数对比
CAM异步实验的TTFT中位数对比
  • 实验结果与分析：在所有测量的请求速率下，AFD配置均降低了首Token时间（TTFT）的中位数/P50。在每秒12个请求的速率下，TTFT中位数从15.1秒降至8.0秒，降幅约为47%。在每秒10个和12个请求的速率下，测得的时间差距均约为7.2秒。这验证了CAM异步执行路径在降低延迟方面的有效性。

结论与未来展望

vLLM AFD插件通过解耦Attention和FFN，为MoE模型提供了更灵活的扩展和部署方式。项目目前的边界被有意限制在：精确绑定vLLM版本（0.19.1）、仅支持model runner v1、双端均加载完整权重、仅支持Decode图模式、DBO固定为两个微批处理，以及受硬件限制的端到端测试。

未来的开发路线图将聚焦于以下几个方面：

  • 更广泛的vLLM兼容性与上游对齐：跟进较新的vLLM版本，评估model runner v2，保持最小化的兼容性补丁，并在抽象成熟时将其贡献给上游。
  • 更灵活的执行模式：扩展图模式、微批处理数量、异步阶段以及经过验证的Rank拓扑。
  • 生产规模的验证：在完整模型和真实工作负载上发布可重复的准确性、延迟、吞吐量、稳定性以及多节点结果。
  • 扩大模型与连接器的覆盖范围：通过现有的模型封装器和连接器接口添加更多MoE架构和后端传输协议，并提供相应的部署配方。
  • 多模态与vLLM-Omni集成：探索AFD如何与vLLM-Omni及异构多模态流水线集成，包括其在自回归（AR）、Diffusion Transformer（DiT）等能从独立扩展中受益的阶段中的应用。
  • 异构硬件与低延迟服务：探索跨不同加速器类型和互连部署Attention和FFN角色，并结合连接器、调度、放置以及计算-通信重叠优化，以降低TTFT和Token间延迟。

补充细节

环境依赖与安装
当前实现要求使用Python 3.10–3.13环境，并明确指定针对vLLM的0.19.1版本。详细的安装步骤需要参考代码仓库中的README文件。

部署配方（Deployment Recipes）
部署命令高度依赖于后端、连接器、模型以及Rank拓扑结构。项目维护了专门的AFD插件配方目录供用户参考：

  • GPU同步AFD：DeepSeek V2 Lite P2P NCCL配方涵盖了面向Decode的共址（colocated）部署、Prefill/Decode解耦部署、Eager及CUDA图执行模式，以及多种DP/TP布局。
  • NPU异步Prefill AFD：DeepSeek V3.2 CAM异步配方记录了所需的运行环境、拓扑结构、AFD配置、基准测试设置以及当前的已知限制。

社区参与
vLLM AFD插件目前处于早期阶段，极其依赖来自模型、服务和硬件社区的反馈来塑造其发展方向。相关的代码、文档（包括GPU和Ascend的详细设计文档）、Issue追踪和功能请求均已在GitHub开源（github.com/vllm-project/afd-plugin），旨在共同构建一个更具组合性且硬件感知的MoE服务未来。