vLLM、柔軟なMoE推論向けAFDプラグイン発表

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のubatchingを活用すれば、独立したステージを直列化せずに並行処理でき、アテンション経路の背後にあるすべてのエキスパート作業を一括で待機させる必要がなくなります。

これらの課題こそが、AFDのコア設計目標を定義しています。vLLMのリクエスト対応型アテンションパスはそのまま維持しつつ、FFNの実行をスケーリング、通信、独立実行が可能な狭いコネクタインターフェースの背後に移動させることです。

アーキテクチャの詳細

このプラグインは、vLLM の vllm.general_plugins エントリーポイントと標準的な --additional-config チャンネルを通じて統合されます。vLLM ソースツリーへの編集は一切不要です。

ランタイムは主に 3 つの構成要素で成り立っています。

• Attention サービス：Attention ワーカーは、vLLM のスケジューラ、KV キャッシュ、バッチ処理、モデルライフサイクル、サンプリングパスをそのまま維持します。プラグインが管理するモデルランナーが AFD メタデータをフォワードコンテキストに埋め込み、データ並列性、ubatch、レイヤー、グラフの状態情報を FFN 側に公開します。

• FFN サービス：FFN ワーカーにはリクエストトラフィックもスケジューラも KV キャッシュも存在しません。バックグラウンドループがメタデータと活性化値を受け取り、プラグイン管理のモデルラッパー上で compute_ffn_output() を呼び出して結果を Attention 側に返します。すべてのリクエストは Attention API サーバー宛てに送られます。

• コネクタ層：各分割レイヤーにおいて、コネクタは FFN サービスが必要とする実行メタデータとともに Attention の隠れ状態を転送し、計算された FFN 出力を戻します。バックエンド非依存のコネクタインターフェースがこの交換を定義しつつ、各バックエンドが独自の通信やランタイム最適化を実装できるようにしています。

この統合インターフェースは、あえて最小限に設計されています。vLLM は既存の抽象化が機能するサービング制御プレーンを引き続き管理し、プラグイン側では AFD ワーカー、モデルランナー、コネクタ、メタデータ、モデル分割ポイント、およびバージョン固有の互換性パッチの実装を担当します。

コネクタとバックエンドサポート

アテンション出力から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 の非同期ディスパッチと結合演算子を活用し、事前処理の Attention ランクをエキスパートワーカーから切り離します。これにより、AFD が管理する MoE の ubatching と併せて、独立した Attention 段階と FFN 段階を並行実行可能となり、パイプラインのストールを削減できます。なお、このパスは現在、事前処理/デコードの非同期化デプロイメントにおける事前処理段階を対象としており、グラフ実行にはまだ対応していません。

MoE モデルの統合

本プラグインは、DeepSeek V2/V3 シリーズ（DeepSeek V3.2 や GLM MoE DSA など）向けのラッパーを登録します。これにより、アテンション計算と FFN 計算を分離して公開しつつ、上位レイヤーの実装を流用することが可能になります。

グラフ処理と ubatching パス

同期 GPU および NPU コネクタは、デコード専用のグラフキャプチャをサポートしています。Dual Batch Overlap は最大 2 つの ubatch で動作し、CAM async が AFD 管理による MoE の ubatching をプリフェッチパスで提供します。

パフォーマンスのスナップショット

CAMP2pAFDConnector を用いた同期 AFD デコードスループット

vllm-project/afd-plugin#67 に記載されているデコードレシピでは、Ascend 910C 上で DeepSeek-V3.2 W8A8 を用いた従来の EP64 デプロイメントと、CAMP2pAFDConnector ベースの AFD デプロイメントを比較しています。このベンチマークはオンラインサービスのレイテンシではなく、飽和状態におけるデコードスループットを測定するものです。

注：本稿は制御された環境での性能評価結果であり、精度や本番環境での運用実績を示すものではありません。利用可能な物理マシンの制約により、48A16F と 64A16F のデプロイメントは、論理的に 192A64F および 256A64F スケールを模擬しています。実験では自然なルーティングによる専門家 ID を置き換え、決定論的な強制負荷分散サイクルを採用したため、モデルの出力自体も変化します。AFDDecodeBenchConnector はデコード専用の KV 状態を提供し、AFD では DBO（Dynamic Batch Optimization）が有効化されています。

スループットは、展開されたダイ（チップ）の総数で正規化しています。

tokens/s/die = aggregate output token throughput / total deployed dies

両方のワークロードとも、固定長の入力と、512 トークンから 1,536 トークンの範囲で一様に分布する出力を使用します。

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 固定入力

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% です。

入力長が 16K と 32K の両方で、48A16F は EP64 ベースラインを下回りましたが、64A16F が最も高い正規化スループットを達成しました。具体的には、16K で +11.3%、32K で +9.0% の向上です。この結果は、アテンションと FFN（フィードフォワードネットワーク）の割り当てが重要であることを示しています。単に両者を分離しただけでは、スループットの向上が保証されないのです。

利用可能なマシンの制約により、より高いアテンション対 FFN 比率を持つデプロイメントの評価は行いませんでした。観測された傾向から判断すると、テストした比率においては、FFN ランクにはまだ計算リソースの余裕があり、計算ボトルネックに陥っているわけではありません。したがって、アテンションランクの割合を増やすことで、さらなるスループット向上が期待できる可能性があります。

CAMAsyncAFDConnector を用いた非同期 AFD プリフィルのパフォーマンス

本リポジトリには、DeepSeek V3.2 の W8A8 モデルを 10 レイヤーに圧縮し、Ascend 910C ノード 2 台で実施した CAM アシンク実験の初期データが含まれています。比較は強制的なエキスパートバランスを用いており、DP4PCP8 TP1 のベースラインと、アテンションを DP3PCP8 TP1、FFN を EP8 に配置した AFD 構成を対比しています。

測定されたリクエストレート全体において、AFD構成は初回トークンまでの時間（TTFT）の中央値/P50を短縮します。1 秒あたり 12 リクエストの場合、中央値 TTFT は 15.1 秒から 8.0 秒に低下し、約 47% の削減となります。1 秒あたり 10 リクエストおよび 12 リクエストの両方で、測定された差は約 7.2 秒です。

注意: 本稿の数値は、CAM 非同期実行パスに焦点を当てた検証結果であり、DeepSeek V3.2 の全体性能やすべての AFD トポロジにおける一般論ではありません。また、ワークロードによってパフォーマンス向上の度合いが異なる場合があります。

Getting Started

現在の実装では、Python 3.10〜3.13 が必要で、vLLM 0.19.1 を対象としています。

Install

詳細は、README のインストール手順をご覧ください。

Deployment Recipes

デプロイコマンドは、バックエンド、コネクタ、モデル、およびランクトポロジによって異なります。設定をここに重複して記載するのではなく、維持されている AFD Plugin recipes をご利用ください。

• GPU 同期 AFD: DeepSeek V2 Lite P2P NCCL recipes では、デコード指向の colocated デプロイメントやプリフィル/デコード非同期デプロイメント、イーグル実行と CUDA グラフ実行、複数の DP/TP レイアウトをカバーしています。

• NPU 非同期プリフィル AFD: DeepSeek V3.2 CAM async recipe では、必要な環境、トポロジ、AFD 設定、ベンチマークセットアップ、および現在の制限事項が文書化されています。

最新のコネクタマトリックス、設定フィールド、完全な起動コマンドについては、リポジトリの README とレシピディレクトリを参照してください。

Current Scope and Roadmap

本プロジェクトは、現在の制約を意図的に明確にしています。具体的には、vLLM のバージョン固定、モデルランナー v1 への限定、両方のロールにおけるフルウェイトの要求、デコード専用グラフモード、DBO（Disaggregated Batch Optimization）における正確な 2 つの ubatch、そしてハードウェアに依存したエンドツーエンドテストです。

開発の次のフェーズでは、以下の点に注力します：

• より広い vLLM の互換性とアップストリームへの統合：新しい vLLM リリースを追跡し、モデルランナー v2 を評価。互換性パッチは最小限に抑えつつ、成熟した有用な抽象化をアップストリームへ貢献します。

• より柔軟な実行環境：グラフモードや ubatch カウントの拡張、非同期ステージの実装、検証済みのランクトポロジーのサポート強化。

• 本番環境規模での検証：フルモデルと現実的なワークロードにおいて、再現可能な精度、レイテンシ、スループット、安定性、マルチノード結果を公開します。

• 対応モデルとコネクタのカバー範囲拡大：既存のモデルラッパーおよびコネクタインターフェースを通じて MoE アーキテクチャやバックエンド転送プロトコルを追加。新たにサポートされる各モデルとコネクタに対応するデプロイレシピも用意します。

• マルチモーダルおよび vLLM-Omni との統合：AFD が vLLM-Omni や、不均質なマルチモーダルパイプラインとどのように連携できるかを探求。特に、自己回帰（AR）や Diffusion Transformer（DiT）、および独立してスケーリング可能なアテンションと FFN 実行の恩恵を受けられる他のステージでの応用について検討します。

異種ハードウェアと低遅延推論

アテンション（Attention）とFFN（Feed-Forward Network）の役割を異なるアクセラレータや相互接続に分散して展開し、コネクタ、スケジューリング、配置、計算と通信の重なりなどの最適化を組み合わせることで、最初のトークン生成までの時間やトークン間遅延を削減する可能性を探ります。

vLLM AFD Plugin はまだ初期段階にあります。モデル開発者、推論サービス担当者、ハードウェアコミュニティからのフィードバックが、今後の方向性を形作っていくことになります。

• コードとドキュメント: github.com/vllm-project/afd-plugin

• ランタイム設計ドキュメント: GPU Attention/FFN および Ascend Attention/FFN の設計

• 課題と機能リクエスト: GitHub Issues

MoE 推論のための、より柔軟でハードウェアに配慮した未来を一緒に築いていきましょう。