6月24日、AMD ROCmが「DP Attention and TBO for DeepSeek-V4 on MI355X」と題した記事を公開した。AMD Instinct MI355X GPU上でDeepSeek-V4推論をDP AttentionとTwo-Batch Overlap（TBO）によって最適化するATOMフレームワークの技術的詳細を解説している。
なぜ今この話題か
DeepSeek-V4はMoE（Mixture of Experts）アーキテクチャを採用しており、推論時のGPU間通信がボトルネックになりやすい。業界の主流アプローチはExpert Parallel（EP）＋DeepEPのようなall2allバックエンドだが、専用カーネルやトポロジー前提、エキスパート配置の最適化など複雑な要件を伴う。
AMDのATOMはその前提に対し、DP Attention + TP MoEという構成に標準的なcollective通信（all_gather/reduce_scatter）を組み合わせる代替アプローチを示した。
最大の見どころ：AG/RSへのTBO拡張
既存フレームワークとの最大の差分がここだ。
vLLMのDBO（Disaggregated Batch Overlap）やSGLangのTBOは、いずれもall2all系バックエンド（DeepEPなど）にしかオーバーラップを適用できない。all2allはdispatchとcombineの2フェーズに分割できるため非同期化しやすい一方、all_gather/reduce_scatterはアトミック——gatherが完全に完了しないと後続のcomputeを開始できず、vLLMの現行抽象ではAG/RSパスのDBO有効化は明示的にブロックされている：
# vllm/model_executor/layers/fused_moe/modular_kernel.py:1126-1130
if not self.prepare_finalize.supports_async():
assert not dbo_enabled() # NaiveDPEP hits this — no DBO allowed
ATOMのアプローチは、yield点をall2allの内部ではなくAG/RSのcollective境界に置くことだ。マイクロバッチをub0とub1に分割し、ub0のRS通信とub1のMoEコンピュートをオーバーラップさせ、ub1のAG通信とub0のコンピュートをオーバーラップさせる。
図：DeepSeek V4の実際のプロファイルトレース。下段ストリームのAG/NCCL通信カーネルが、上段のattention・MoE・GEMMカーネルと並行して動作している。
このオーバーラップパターンはCUDA Graphでキャプチャ・リプレイも可能なため、デコードステップごとのCPUスケジューリングオーバーヘッドも回避できる。
フレームワーク比較をまとめると：
| 機能 | vLLM DBO | SGLang TBO | ATOM TBO |
|---|---|---|---|
| EP/All2Allオーバーラップ | Yes（DeepEP） | Yes（DeepEP, MORI） | Yes（MORI） |
| AG/RSオーバーラップ | No | No | Yes |
| オーバーラップ単位 | MoEバックエンドの非同期prepare/finalize | MoEステージレベルのパイプライン | マイクロバッチ＋collective境界 |
もう一つの柱：PrefillDelayer
DP Attentionでは、8つのDPランクが同じフェーズ（全員prefillまたは全員decode）にいることが効率の前提となる。ランク4だけがprefill（〜1024トークン）で残り7ランクがdecode（〜16トークン）という状況になると、all_gatherは全ランクを最大次元（1024）にパディングする。**パディング無駄率は86%**に達する。
図：1ランクがprefillに入ると、他のdecodeランクがeager decodeにフォールバックし、MoE gatherでprefill長にパディングされる。
PrefillDelayerはこの問題をスケジューリングで解決する。あるランクがprefill可能になっても即座に移行させず、全ランクの状態を観察して一斉にprefillに入れるか、タイムアウト・低水位マークのロジックで強制許可する。
TBOのマイクロバッチ分割改善
既存のTBO実装はリクエスト境界でマイクロバッチを分割していた。例えば合計16384トークンの3リクエスト[7003, 6928, 2453]を境界で分割すると7003 / 9381トークンとなり、ub1がub0の1.34倍のサイズになる。オーバーラップウィンドウが非対称になり、効率が落ちる。
ATOMは代わりにトークン数が均等になる中間点で分割し、リクエストをまたぐ場合はそのリクエストを前後に切断する（合計16384トークンなら両ubatchがちょうど8192トークン）。分割されたリクエストの後半部分は、前半部分のKVをプレフィックスキャッシュとして扱う——チャンクprefillと同様のアイデアだ。
MI355X上での性能
SemiAnalysis InferenceXのオープンソースベンチマーク（8K/1Kワークロード）によるDeepSeek V4 ProのMI355X上のスループットフロンティアは以下のとおりだ（2025年6月18日時点）：
図：MI355X上のDeepSeek V4 Proスループットフロンティア。PrefillDelayerとTBO（AG/RS）の組み合わせで推移を示す。
PrefillDelayer＋TBO（AG/RS）により、専用all2allバックエンドなしで競合水準のDeepSeek-V4推論性能を実現している。
意義
ATOMが示すのは、「高性能MoE推論にはEP＋専用all2allが必須」という業界の前提に対し、標準的なcollective通信と通常のインターコネクトでも同等の性能を狙える代替アプローチが存在するという点だ。専用ライブラリへの依存、エキスパート配置の最適化、トポロジー前提といった複雑さを回避できる可能性を示している。DP Attention + TP MoEという構成は、任意のインターコネクトで動作する。
詳細はDP Attention and TBO for DeepSeek-V4 on MI355Xを参照していただきたい。
