vLLM AFD Plugin：为 MoE 推理实现 Attention 与 FFN 解耦

vLLM 发布了 vLLM AFD Plugin，这是一个实验性的外部插件，为混合专家模型 (MoE) 实现了 Attention-FFN 解耦 (Attention-FFN Disaggregation, AFD)。该架构将 Attention 和 Feed-Forward Network (FFN) 组件分离为独立部署的服务，使它们能够根据各自的资源需求进行扩展，而无需更改 vLLM 的请求生命周期或 OpenAI 兼容的推理接口。

Attention-FFN 解耦的原理

在 MoE 推理中，Attention 和 FFN 路径具有根本不同的运行需求。Attention 是有状态的，与请求调度和 KV cache 管理紧密相关；而 FFN (专家) 路径则由路由计算和 all-to-all 通信主导。

AFD 解决了四个主要的系统设计挑战：

• 独立扩展： Attention 容量取决于序列长度和 KV-cache 压力，而专家容量取决于 token 路由和负载。AFD 允许这些路径使用不同的 rank 拓扑结构。
• 运行时职责： 通过拆分服务，FFN 端可以作为一个轻量级的连接器驱动守护进程运行，从而消除了专家端对调度和 KV-cache 协调的需求。
• 后端特定通信： 通用的连接器契约允许不同的硬件后端（例如 CUDA 和 Ascend）实现其各自优化的数据路径和集合通信库。
• 计算与通信重叠： 异步分发和 MoE ubatching 可以使独立阶段重叠，防止 Attention 路径被所有的专家工作序列化。

系统架构

vLLM AFD Plugin 通过 vllm.general_plugins 入口点和 --additional-config 渠道进行集成，无需修改 vLLM 源码树。运行时由三个核心组件组成：

1. Attention Service

保留 vLLM 的调度器、KV cache、批处理、模型生命周期和采样路径。插件拥有的 model runner 会将 AFD 元数据安装到 forward context 中，并将状态（data-parallel, ubatch, layer, and graph）发布到 FFN service。

2. FFN Service

在没有请求流量、调度器或 KV caches 的情况下运行。它运行一个后台循环，接收元数据和 activations，通过插件拥有的 model wrapper 执行 compute_ffn_output()，并将结果返回给 Attention service。

3. Connector Layer

作为每个拆分层的桥梁，将隐藏状态 (hidden states) 和执行元数据从 Attention 传输到 FFN，并返回计算后的输出。

Connector 与后端支持矩阵

Connector	Backend	Execution	Recommended Stage	Graph Support
P2pNcclAFDConnector	GPU	Synchronous P2P	Decode	FULL_DECODE_ONLY CUDA graph
CAMP2pAFDConnector	NPU	Synchronous CAMP2P/HCCL	Decode	FULL_DECODE_ONLY ACL graph
CAMAsyncAFDConnector	NPU	Asynchronous CAM	Prefill	Not supported

性能基准测试

同步 Decode 吞吐量 (Ascend 910C 上的 DeepSeek-V3.2 W8A8)

基准测试将传统的 EP64 部署与使用 CAMP2pAFDConnector 的 AFD 部署进行了比较。结果显示，Attention 与 FFN ranks 的比例会显著影响归一化吞吐量 (tokens/s/die)。

• 16K 固定输入： 64A16F 配置（64 Attention, 16 FFN ranks）实现了 258.9 tokens/s/die，比 EP64 基准 (232.6 tokens/s/die) 提升了 11.3%。48A16F 配置的表现较差，为 220.3 tokens/s/die (-5.3%)。
• 32K 固定输入： 64A16F 配置实现了 183.3 tokens/s/die，比 EP64 基准 (168.2 tokens/s/die) 提升了 9.0%。48A16F 配置比基准低 10.0%。

这些结果表明，单靠解耦并不能保证收益；Attention 和 FFN 之间具体的 rank 分配至关重要。

异步 Prefill 性能 (Ascend 910C 上的 DeepSeek V3.2 W8A8)

使用 CAMAsyncAFDConnector 在一个 10 层缩减模型上进行的早期实验，将 DP4PCP8 TP1 基准与 AFD 布局（Attention DP3PCP8 TP1 + FFN EP8）进行了比较。

在每秒 12 个请求的请求率下，中值首字延迟 (TTFT) 从 15.1 秒降低到 8.0 秒，降幅约为 47%。

实现与路线图

当前支持

• 模型： DeepSeek V2/V3 系列（包括 DeepSeek V3.2）和 GLM MoE DSA 的封装。
• 硬件： NVIDIA GPUs 和 Ascend NPUs。
• 执行路径： 支持 eager、graph 和 dual-batch 执行；同步连接器支持 decode-only graph capture。
• 要求： Python 3.10–3.13 和 vLLM 0.19.1。

未来发展

• 上游对齐： 跟进最新的 vLLM 版本并评估 model runner v2。
• 执行灵活性： 扩展 graph 模式、ubatch 数量和异步阶段。
• 生产验证： 在全量模型和真实工作负载上发布稳定性、准确性和延迟结果。
• 扩大覆盖范围： 增加更多 MoE 架构和后端传输方式。
• 多模态集成： 探索 AFD 在 vLLM-Omni 中自回归 (AR) 和 Diffusion Transformer (DiT) 阶段的应用。
• 异构硬件： 研究在不同加速器类型上部署 Attention 和 FFN 角色，以降低 TTFT 和 token 间延迟。