vLLM、柔軟なMoE推論向けAFDプラグイン発表
vLLM が発表した AFD プラグインは、アテンション層と FFN 層を分離することで、MoE モデルの柔軟な推論サービスとリソース最適化を可能にする重要な技術的進展である。
キーポイント
AFD プラグインの核心機能
アテンション（Attention）層とフィードフォワードネットワーク（FFN）層を物理的に分離し、それぞれを独立してスケール可能にする仕組みを提供する。
MoE モデルへの柔軟な対応
混合専門家（MoE）モデルにおいて、異なる専門家モジュールの組み合わせや配置を動的に調整し、推論効率を最大化する。
リソース最適化とコスト削減
計算リソースとメモリ使用量を分離管理することで、ハードウェア制約下でも大規模 MoE モデルの効率的な運用を実現し、推論コストを削減する。
重要な引用
Disaggregating Attention and FFN for Flexible MoE Serving
vLLM AFD Plugin
影響分析・編集コメントを表示
影響分析
この発表は、MoE モデルの運用において従来困難だったリソース割り当てとスケーラビリティの問題を解決する画期的なアプローチです。特に大規模モデルが普及する中で、コスト効率と推論速度の両立を求める現場にとって、実装レベルでの即効性のあるソリューションとなるでしょう。
編集コメント
MoE モデルの運用効率化において、アーキテクチャレベルでの分離という発想は非常に革新的です。特にリソース制約が厳しい現場でも大規模モデルを柔軟に扱えるようになるため、実務への導入加速が期待されます。
vLLM AFD Plugin の公開を発表します。これは、Attention-FFN Disaggregation (AFD) を vLLM に導入する実験的な外部プラグインです。
vLLM AFD Plugin は、Attention と FFN を独立したサービスとして分離することで、Mixture-of-Experts (MoE) モデルに AFD を実装します。既存の vLLM のリクエストライフサイクルや OpenAI 互換のサービングインターフェースを維持しつつ、Attention パスと FFN パスをそれぞれ独立してスケール可能にします。
本プロジェクトは現在、NVIDIA GPU と Ascend NPU、同期・非同期コネクタ、DeepSeek V2/V3 ファミリーモデル用ラッパー、そして明確に検証された範囲内での eager、graph、dual-batch 実行パスをサポートしています。
注: このプロジェクトはまだ実験段階であり、異なるハードウェアバックエンド間での大規模なテストが必要です。
なぜ Attention-FFN の分離が必要なのか
Mixture-of-Experts (MoE) 推論では、トランスフォーマーの各レイヤー内で非常に性質の異なる 2 つの処理が組み合わされます。Attention は状態を保持し、リクエストスケジューリングや KV キャッシュと密接に結合されています。一方、FFN またはエキスパートパスは、ルーティングされたエキスパート計算と all-to-all コミュニケーションによって支配されています。
両方のパスが同じワーカートポロジーを共有する場合、サービングシステムは非常に異なる要件を持つワークロードに対して、1 つのスケール設定と実行選択を行わなければなりません。
この分離を実用的なものにするには、いくつかのシステム設計上の課題に対処する必要があります:
アテンションとFFN（フィードフォワードネットワーク）は、それぞれ異なるスケーリング要件を持っています。アテンションのキャパシティはリクエストの状態、シーケンス長、KVキャッシュの負荷に依存します。一方、エキスパートのキャパシティはトークンのルーティングやエキスパートの負荷によって決まります。サービングシステムでは、両方のパスが異なるランクトポロジーを利用できるようにし、一つの共有レイアウトを強制するのではなく、独立したスケーリングをサポートする必要があります。
アテンションとFFNは、ランタイムにおける役割も異なります。アテンションにはスケジューリング、KVキャッシュの調整、サンプリングが必要です。一方、FFNの実行には活性化値、ルーティングメタデータ、そしてエキスパートからの出力を返す仕組みがあれば十分です。サービスを分割することで、FFN側は軽量なコネクタ駆動型のデーモンとして動作できるようになります。
通信方式はバックエンド固有のものです。CUDAやAscendでは、それぞれ異なる集合ライブラリ、グラフランタイム、最適化されたMoE演算子が提供されています。共通のコネクター契約を採用することで、モデル側のフローを安定させつつ、各バックエンドが自らのデータパスを管理できるようにします。
通信と計算は、重なり合うことで効果を発揮します。非同期ディスパッチやMoEのUBバッチ処理を活用すれば、アテンション経路にすべてのエキスパート作業を直列化するのではなく、独立したステージを並行して実行できます。
これら諸課題が、AFDのコアドザインゴールを定義しています。vLLMのリクエスト対応型アテンションパスはそのまま維持しつつ、FFNの実行をスケーリング・通信・実行を独立して行える狭いコネクタインターフェースの背後に移動させることです。
Inside the Architecture
image vLLM AFD プラグインのランタイムアーキテクチャ
本プラグインは、vLLM の vllm.general_plugins エントリーポイントおよび標準的な --additional-config チャンネルを通じて統合されます。vLLM のソースコードツリーを直接編集する必要はありません。
このランタイムには、主に以下の 3 つの構成要素があります。
- Attention サービス: Attention ワーカーは、vLLM が持つスケジューラ、KV キャッシュ、バッチ処理、モデルライフサイクル、サンプリングパスを引き継ぎます。プラグインが管理するモデルランナーは、AFD メタデータをフォワードコンテキストに埋め込み、データ並列化、ubatch、レイヤー、グラフの状態を FFN 側に公開します。
- FFN サービス: FFN ワーカーにはリクエストトラフィックやスケジューラ、KV キャッシュは存在しません。バックグラウンドループがメタデータと活性化値を受け取り、プラグイン管理のモデルラッパー上で
compute_ffn_output()を呼び出して計算結果を Attention 側に返します。すべてのリクエストは、Attention API サーバー宛てに送られます。
- コネクタ層: スプリットレイヤーごとに、コネクタは Attention の隠れ状態と FFN サービスが必要とする実行メタデータを転送し、計算された FFN 出力を戻り値として返します。このデータ交換はバックエンド非依存のコネクタインターフェースで定義されており、各バックエンドが独自の通信やランタイム最適化を実装できる余地を残しています。
この統合インターフェースは、あえて最小限に設計されています。vLLM は既存の抽象化が機能するサービング制御プレーンを引き続き管理し、プラグイン側では AFD ワーカー、モデルランナー、コネクタ、メタデータ、モデル分割ポイント、および少数のバージョン限定互換パッチの実装を担当します。
コネクタとバックエンドサポート
ConnectorBackendExecutionRecommended stageGraph support
P2pNcclAFDConnectorGPUSynchronous P2PDecodeFULL_DECODE_ONLY CUDA graph
CAMP2pAFDConnectorNPUSynchronous CAMP2P/HCCLDecodeFULL_DECODE_ONLY ACL graph
CAMAsyncAFDConnectorNPUAsynchronous CAMPrefillNot currently supported
コネクタ間で共有されるのは、高レベルのデータ交換パターンです。具体的には「アテンション出力を FFN へ、FFN 出力をアテンションへ戻す」という流れが共通しています。一方、バックエンドパッケージは独立して管理されているため、CUDA グラフや ACL グラフの動作、NCCL 通信、Ascend カスタム演算子が互いに混ざり合うことはありません。
サポート機能
- ネイティブな vLLM サービングインターフェース。既存の vLLM ユーザーは引き続き
vllm serveコマンドで起動し、OpenAI 互換エンドポイントへリクエストを送信し、--additional-configパラメータを通じてランタイムを設定できます。
- GPU および NPU 向けの実装。GPU ワーカーは vLLM v1 クラスを拡張し、NPU ワーカーは直接 vLLM-Ascend クラスを拡張します。共通の動作ロジックは、デバイス間の継承関係ではなく、設定、トポロジー、メタデータ、コネクタ契約によって統括されます。
- デコードスループットのための同期 AFD。P2pNcclAFDConnector と CAMP2pAFDConnector は、アテンション活性化値と FFN 出力を同期的に交換します。これにより、スループット指向のデプロイメントにおいて、2 つの役割が独立してスケール可能になります。現在のグラフパスは、それぞれ CUDA および ACL で「FULL_DECODE_ONLY」セマンティクスを使用しています。
- プレフィルのための非同期 AFD。CAMAsyncAFDConnector は、CAM の非同期ディスパッチおよび結合演算子を利用し、プレフィルのアテンションランクをエキスパートワーカーから切り離します。これに AFD 管理型の MoE ユバッチングを組み合わせることで、独立したアテンションと FFN のステージをオーバーラップさせ、パイプラインのストールを削減します。このパスは現在、プレフィル/デコード分離型デプロイメントにおけるプレフィルステージを対象としており、まだグラフ実行には対応していません。
- MoE モデルの統合。本プラグインは、DeepSeek V2/V3 系アーキテクチャ（DeepSeek V3.2 を含む）や GLM MoE DSA 向けのラッパーを登録します。このラッパーはアテンションと FFN の計算を分離して公開しつつ、上位レイヤーの実装を再利用します。
- グラフおよびユバッチングのパス。同期 GPU および NPU コネクターは、デコード専用グラフキャプチャをサポートしています。「Dual Batch Overlap」はちょうど 2 つのユバッチで利用可能であり、CAM の非同期側ではプレフィルパスに AFD 管理型の MoE ユバッチングを提供します。
パフォーマンスのスナップショット
CAMP2pAFDConnector を用いた同期 AFD デコードスループット
vllm-project/afd-plugin#67 に記載されている同期デコードのレシピでは、Ascend 910C 上で DeepSeek-V3.2 W8A8 を実行する際、従来の EP64 デプロイメントと CAMP2pAFDConnector ベースの AFD デプロイメントを比較しています。このベンチマークはオンラインサービスのレイテンシではなく、飽和状態におけるデコードのスループットを測定したものです。
| デプロイメント | 物理トポロジ | 総ダイ数 |
|---|---|---|
| EP64 | DP64, EP64, TP16 | 48 |
| A16F | 48 アテンションランク、16 FFN ランク | 64 |
| A64F | 64 アテンションランク、16 FFN ランク | 80 |
注記: これらは制御された環境での性能結果であり、精度や本番環境でのサービス結果ではありません。利用可能なマシンの制約により、物理的な 48A16F および 64A16F のデプロイメントは、論理的にはそれぞれ 192A64F と 256A64F のスケールを模擬しています。実験では、自然なルーティングによるエキスパート ID を、決定論的な強制バランスサイクルに置き換えています。これによりモデルの出力は変化します。AFDDecodeBenchConnector はデコード専用の KV 状態を提供し、AFD では DBO が有効化されています。
スループットは、展開されたダイの総数で正規化されます。
tokens/s/die = 集計された出力トークン スループット / 展開されたダイの総数
両方のワークロードでは、固定長の入力と、512 から 1,536 トークンの範囲で均一に分布する出力を使用しています。
16K 固定入力
imageDeepSeek-V3.2 の 16K デコード時のスループット（チップあたり）
EP64 は232.6 tokens/s/die、48A16F は220.3 tokens/s/die、そして 64A16F は258.9 tokens/s/dieを達成しました。EP64 を基準とすると、AFD の結果は 48A16F で-5.3%、64A16F では+11.3%となります。
固定入力 32K
imageDeepSeek-V3.2 の 32K デコード時のスループット（チップあたり）
EP64 は168.2 tokens/s/die、48A16F は151.4 tokens/s/die、64A16F は183.3 tokens/s/dieを記録しました。EP64 に対する AFD の結果は、48A16F で-10.0%、64A16F で+9.0%です。
両方の入力長において、48A16F は EP64 ベースラインを下回りましたが、64A16F が最も高い正規化スループットを示しました。具体的には 16K で+11.3%、32K で+9.0%の向上です。この結果は、アテンションと FFN の割り当てが重要であることを示しています。単に disaggregation（分離）しただけでは、スループットの向上は保証されないのです。
マシンの利用可能数が限られていたため、より高いアテンション対 FFN 比率を持つデプロイメントの評価は行いませんでした。観測された傾向からすると、テストした比率においては FFN ランクにまだ計算リソースの余裕があり、計算ボトルネックには至っていないと考えられます。したがって、アテンションランクの割合を増やすことで、さらなるスループットの向上が期待できるかもしれません。
CAMAsyncAFDConnector を用いた非同期 AFD プリフィルのパフォーマンス
本リポジトリには、DeepSeek V3.2 モデル（W8A8 版を 10 レイヤーに圧縮）を用いた Ascend 910C ノード 2 台での CAM アシンク実験の初期データが含まれています。比較対象は、強制エキスパートバランスを適用した DP4PCP8 TP1 のベースラインに対し、Attention 部分に DP3PCP8 TP1、FFN 部分に EP8 を割り当てた AFD レイアウトです。
imageCAM アシンク実験におけるメディアン TTFT の比較結果
測定したリクエストレート全体を通じて、AFD 構成は最初のトークン生成までの時間（TTFT）の中央値・P50 を短縮しています。具体的には、1 秒間に 12 リクエスト処理した場合、TTFT の中央値が15.1 秒から 8.0 秒へ低下し、約 47% の短縮効果が確認されました。1 秒間あたり 10 リクエストおよび 12 リクエストの両ケースで、測定された差は約 7.2 秒です。
注記: これらの数値は CAM アシンク実行パスに焦点を当てた検証であり、DeepSeek V3.2 の全体性能やあらゆる AFD トポロジーにおける一般論ではありません。パフォーマンス向上の度合いはワークロードによって変動する可能性があります。
始め方
現在の実装では Python 3.10〜3.13 が必要で、vLLM 0.19.1 を対象としています。
インストール
詳細については、README のインストール手順をご確認ください。
デプロイレシピ
デプロイコマンドは、バックエンド、コネクタ、モデル、およびランクトポロジーによって異なります。ここでは設定を重複して記載するのではなく、維持されている AFD Plugin レシピ をご活用ください。
- GPU の同期型 AFD：DeepSeek V2 Lite P2P NCCL レシピでは、デコード指向の colocated 環境やプリフェッチ/デコードを分離した展開、イーガー実行と CUDA グラフの実行、そして複数の DP/TP 構成に対応しています。
- NPU の非同期プリフェッチ AFD：DeepSeek V3.2 CAM の非同期レシピでは、必要な環境設定、トポロジー、AFD の構成方法、ベンチマークのセットアップ、および現在の制限事項が文書化されています。
最新のコネクタ行列、設定項目、完全な起動コマンドについては、リポジトリの README ファイルとレシピディレクトリを参照してください。
現在の範囲とロードマップ
本プロジェクトは、現状の制約をあえて明確に示しています。具体的には、vLLM の特定バージョンへの固定、モデルランナー v1 のみの対応、両方のロールにおけるフルウェイトの保持、デコード専用グラフモード、DBO における正確な 2 つの ubatch、そしてハードウェア依存のエンドツーエンドテストです。
開発の次のフェーズでは、以下の点に注力します：
- より広い vLLM 互換性とアップストリームへの統合：新しい vLLM リリースを追跡し、モデルランナー v2 の評価を行い、互換性パッチは最小限に抑えつつ、成熟した有用な抽象化をアップストリームへ貢献します。
- より柔軟な実行環境：グラフモードや ubatch 数、非同期ステージ、検証済みのランクトポロジーの拡張を行います。
- 本番規模での検証：フルモデルと現実的なワークロードにおいて、再現可能な精度、レイテンシ、スループット、安定性、マルチノードの結果を公開します。
モデルとコネクタの対応範囲を拡大し、既存のモデルラッパーおよびコネクタインターフェースを通じて MoE アーキテクチャやバックエンド転送プロトコルを追加しました。これに伴い、新たにサポートされた各モデルとコネクタに対応するデプロイレシピも用意しています。
マルチモーダル機能や vLLM-Omni との統合についても検討を進めています。AFD が自己回帰（AR）処理や拡散変換器（DiT）、あるいはアテンションと FFN の実行を独立してスケールできる他のステージにおいて、どのように組み込まれるかを探求します。
さらに、異なるアクセラレータタイプや相互接続間でのアテンションと FFN の役割分担による、異種ハードウェア環境での低遅延サービスの実現も目指しています。コネクタ設計、スケジューリング、配置最適化、計算と通信の重なり処理などを組み合わせることで、最初のトークン生成までの時間やトークン間の遅延を削減します。
vLLM AFD プラグインはまだ初期段階にあり、モデル・サービス・ハードウェア各コミュニティからのフィードバックが今後の方向性を形作っていきます。
- コードとドキュメント: github.com/vllm-project/afd-plugin
- ランタイム設計資料: GPU 用アテンション/FFN および Ascend 用アテンション/FFN の設計
- イシューと機能リクエスト: GitHub Issues
MoE サービングの未来を、よりコンポーザブルでハードウェアに意識的なものへと共に築いていきましょう。
原文を表示
We are excited to introduce vLLM AFD Plugin, an experimental external plugin that brings Attention-FFN Disaggregation (AFD) to vLLM.
vLLM AFD Plugin brings AFD into Mixture-of-Experts (MoE) models by separating Attention and FFN into independently deployed services. The plugin preserves vLLM's existing request lifecycle and OpenAI-compatible serving interface, while allowing the Attention and FFN paths to scale independently.
The project currently supports NVIDIA GPUs and Ascend NPUs, synchronous and asynchronous connectors, DeepSeek V2/V3-family model wrappers, and eager, graph, and dual-batch execution paths within clearly validated limits.
Note: This project is still experimental and needs more large-scale testing across different hardware backends.
Why Attention-FFN Disaggregation?
Mixture-of-Experts (MoE) inference combines two very different kinds of work inside every transformer layer. Attention is stateful and closely coupled to request scheduling and the KV cache, while the FFN or expert path is dominated by routed expert computation and all-to-all communication. When both paths share the same worker topology, the serving system must make one set of scaling and execution choices for workloads with very different requirements.
Making this separation practical requires addressing several system design challenges:
- Attention and FFN have different scaling requirements. Attention capacity follows request state, sequence length, and KV-cache pressure. Expert capacity follows token routing and expert load. The serving system should support independent scaling by allowing both paths to use different rank topologies, instead of requiring one shared layout.
- Attention and FFN have different runtime responsibilities. Attention needs scheduling, KV-cache coordination, and sampling. FFN execution only needs activations, routing metadata, and a way to return expert outputs. Splitting the services lets the FFN side run as a lightweight connector-driven daemon.
- Communication is backend-specific. CUDA and Ascend expose different collective libraries, graph runtimes, and optimized MoE operators. A common connector contract keeps the model-facing flow stable while allowing each backend to own its data path.
- Communication and computation benefit from overlap. Asynchronous dispatch and MoE ubatching can overlap independent stages instead of serializing all expert work behind the Attention path.
Together, these challenges define the core design goal of AFD: keep vLLM's request-facing Attention path intact, while moving FFN execution behind a narrow connector interface that can scale, communicate, and execute independently.
Inside the Architecture
The plugin integrates through vLLM's vllm.general_plugins entry point and the standard --additional-config channel. It does not require edits to the vLLM source tree.
The runtime has three main parts:
- Attention service. The Attention worker retains vLLM's scheduler, KV cache, batching, model lifecycle, and sampling path. A plugin-owned model runner installs AFD metadata into the forward context and publishes data-parallel, ubatch, layer, and graph state to the FFN side.
- FFN service. The FFN worker has no request traffic, scheduler, or KV cache. A background loop receives metadata and activations, invokes compute_ffn_output() on the plugin-owned model wrapper, and sends the result back to Attention. Requests are always sent to the Attention API server.
- Connector layer. At each split layer, the connector transfers Attention hidden states together with the execution metadata required by the FFN service, then returns the computed FFN outputs. A backend-neutral connector interface defines this exchange while allowing each backend to implement its own communication and runtime optimizations.
This integration surface is designed to be intentionally small. vLLM continues to own the serving control plane where its existing abstractions fit, while the plugin provides the implementations of AFD workers, model runners, connectors, metadata, model split points, and a small set of version-scoped compatibility patches.
Connector and backend support
ConnectorBackendExecutionRecommended stageGraph support
P2pNcclAFDConnectorGPUSynchronous P2PDecodeFULL_DECODE_ONLY CUDA graph
CAMP2pAFDConnectorNPUSynchronous CAMP2P/HCCLDecodeFULL_DECODE_ONLY ACL graph
CAMAsyncAFDConnectorNPUAsynchronous CAMPrefillNot currently supported
The same high-level exchange - Attention output to FFN, FFN output back to Attention - is shared across connectors. Backend packages remain separate so CUDA graph behavior, ACL graph behavior, NCCL communication, and Ascend custom operators do not leak into one another.
Supported features
- Native vLLM serving surface. Existing vLLM users still launch with vllm serve, send requests to an OpenAI-compatible endpoint, and configure the runtime through --additional-config.
- GPU and NPU implementations. GPU workers extend vLLM v1 classes, while NPU workers extend vLLM-Ascend classes directly. Shared behavior lives in configuration, topology, metadata, and connector contracts rather than cross-device inheritance.
- Synchronous AFD for decode throughput. P2pNcclAFDConnector and CAMP2pAFDConnector synchronously exchange Attention activations and FFN outputs, allowing the two roles to scale independently in throughput-oriented decode deployments. Their current graph paths use FULL_DECODE_ONLY semantics on CUDA and ACL, respectively.
- Asynchronous AFD for prefill. CAMAsyncAFDConnector uses CAM asynchronous dispatch and combine operators to decouple prefill Attention ranks from expert workers. Together with AFD-managed MoE ubatching, it overlaps independent Attention and FFN stages to reduce pipeline stalls. This path currently targets the prefill stage in a prefill/decode-disaggregated deployment and does not yet support graph execution.
- MoE model integration. The plugin registers wrappers for DeepSeek V2/V3-family architectures, including DeepSeek V3.2, and GLM MoE DSA. The wrapper exposes separate Attention and FFN computations while reusing upstream layer implementations.
- Graph and ubatching paths. The synchronous GPU and NPU connectors support decode-only graph capture. Dual Batch Overlap is supported with exactly two ubatches, and CAM async provides AFD-managed MoE ubatching for its prefill path.
A Performance Snapshot
Synchronous AFD Decode Throughput with CAMP2pAFDConnector
The synchronous decode recipe in vllm-project/afd-plugin#67 compares a conventional EP64 deployment with CAMP2pAFDConnector-based AFD deployments for DeepSeek-V3.2 W8A8 on Ascend 910C. The benchmark measures saturated decode throughput rather than online-serving latency.
DeploymentPhysical topologyTotal dies
EP64DP64, EP64, TP164
48A16F48 Attention ranks, 16 FFN ranks64
64A16F64 Attention ranks, 16 FFN ranks80
Note: These are controlled performance results, not accuracy or production-serving results. Due to limited machine availability, the physical 48A16F and 64A16F deployments simulate logical 192A64F and 256A64F scales. The experiment replaces natural routed expert IDs with a deterministic forced-balancing cycle, which changes model outputs. AFDDecodeBenchConnector supplies the decode-only KV state, and DBO is enabled for AFD.
Throughput is normalized by the total number of deployed dies:
Both workloads use fixed-length inputs and uniformly distributed outputs from 512 to 1,536 tokens.
16K fixed input
EP64 achieves 232.6 tokens/s/die, 48A16F achieves 220.3 tokens/s/die, and 64A16F achieves 258.9 tokens/s/die. Relative to EP64, the AFD results are -5.3% for 48A16F and +11.3% for 64A16F.
32K fixed input
EP64 achieves 168.2 tokens/s/die, 48A16F achieves 151.4 tokens/s/die, and 64A16F achieves 183.3 tokens/s/die. Relative to EP64, the AFD results are -10.0% for 48A16F and +9.0% for 64A16F.
Across both input lengths, 48A16F is below the EP64 baseline, while 64A16F delivers the highest normalized throughput: +11.3% at 16K and +9.0% at 32K. This result shows that the Attention-to-FFN allocation matters; disaggregation alone does not guarantee a throughput gain.
Due to limited machine availability, we did not evaluate deployments with higher Attention-to-FFN ratios. The observed trend suggests that, at the ratios tested, the FFN ranks still have compute headroom rather than being compute-bound. Increasing the proportion of Attention ranks may therefore reveal further throughput gains.
Asynchronous AFD Prefill Performance with CAMAsyncAFDConnector
The repository includes an early CAM async experiment on two Ascend 910C nodes using a DeepSeek V3.2 W8A8 model reduced to 10 layers. The comparison uses forced expert balancing and contrasts a DP4PCP8 TP1 baseline with an AFD layout consisting of Attention DP3PCP8 TP1 plus FFN EP8.
Across the measured request rates, the AFD configuration lowers median/P50 time to first token. At 12 requests per second, median TTFT decreases from 15.1 seconds to 8.0 seconds, a reduction of approximately 47%. At both 10 and 12 requests per second, the measured gap is about 7.2 seconds.
Note: These numbers are a focused validation of the CAM async execution path, not a general performance claim for full DeepSeek V3.2 or every AFD topology. The performance gains may also vary across workloads.
Getting Started
The current implementation requires Python 3.10–3.13 and targets vLLM 0.19.1.
Install
Check out the installation steps in our README for details.
Deployment Recipes
Deployment commands depend on the backend, connector, model, and rank topology. Instead of duplicating configurations here, use the maintained AFD Plugin recipes:
- GPU synchronous AFD: the DeepSeek V2 Lite P2P NCCL recipes cover decode-oriented colocated and prefill/decode-disaggregated deployments, eager and CUDA graph execution, and multiple DP/TP layouts.
- NPU asynchronous prefill AFD: the DeepSeek V3.2 CAM async recipe documents the required environment, topology, AFD configuration, benchmark setup, and current limitations.
Refer to the repository README and recipe directory for the latest supported connector matrix, configuration fields, and complete launch commands.
Current Scope and Roadmap
The project intentionally exposes its current boundaries: exact vLLM version pinning, model runner v1 only, full weights on both roles, decode-only graph modes, exactly two ubatches for DBO, and hardware-gated end-to-end testing.
The next phase of development will focus on:
- Broader vLLM compatibility and upstream alignment: track newer vLLM releases, evaluate model runner v2, keep compatibility patches minimal, and contribute generally useful abstractions upstream as they mature.
- More flexible execution: extend graph modes, ubatch counts, asynchronous stages, and validated rank topologies.
- Production-scale validation: publish repeatable accuracy, latency, throughput, stability, and multi-node results on full models and realistic workloads.
- Expanded model and connector coverage: add MoE architectures and backend transports through the existing model-wrapper and connector interfaces, together with corresponding deployment recipes for each newly supported model and connector.
- Multimodal and vLLM-Omni integration: explore how AFD can integrate with vLLM-Omni and heterogeneous multimodal pipelines, including its application within autoregressive (AR), Diffusion Transformer (DiT), and other stages that can benefit from independently scaled Attention and FFN execution.
- Heterogeneous hardware and low-latency serving: explore deploying Attention and FFN roles across different accelerator types and interconnects, together with connector, scheduling, placement, and computation-communication overlap optimizations that reduce time to first token and inter-token latency.
vLLM AFD Plugin is at an early stage, and feedback from model, serving, and hardware communities will shape its direction.
- Code and documentation: github.com/vllm-project/afd-plugin
- Runtime design docs: GPU Attention/FFN and Ascend Attention/FFN designs
- Issues and feature requests: GitHub Issues
Let's build a more composable and hardware-aware future for MoE serving together.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み