NCCLに頼らないallreduce──SGLangがBlackwell世代のFlashInfer MNNVLワークスペースを使い回す最適化

複数GPUで1つの大規模モデルを動かす際、各GPUが計算した結果を合算する「allreduce」という通信処理は、避けて通れないボトルネックの1つだ。推論エンジンSGLangのv0.5.18（2026年8月22日公開）は、このallreduce処理の一部を、通信ライブラリNCCLから、FlashInferが持つMNNVLワークスペースへと切り替える最適化を追加した。実装したのはPR #30700で、2026年8月11日にマージされている。

3行まとめ

1. SGLang v0.5.18は、PR #30700（2026年8月11日マージ、7ファイル・+476/-6行）で、RowParallelLinear・attention出力のフォールバック・MoE TPフォールバックが行う「融合されていないallreduce」をFlashInferのMNNVLワークスペース経由に切り替えた。
2. Blackwell世代GPU・DeepSeek-V4-Flash・TP4構成のデコード処理で、小バッチ時に最大+6.9%の性能向上を確認したとリリースノートは報告している。
3. DeepSeek-V3/V3.2/V4では自動的に有効化され、それ以外のモデルでは--enable-flashinfer-pure-allreduceフラグでの明示的な有効化が必要。FlashInferのワークスペースが未初期化・入力が2次元連続でない場合などは自動的にNCCLへフォールバックする設計になっている。

NCCLへのフォールバックをやめて、既存のワークスペースを再利用する

公式リリースノートの説明はこうだ。

"FlashInfer MNNVL for pure allreduce: Non-fused allreduce sites now reuse the FlashInfer MNNVL workspace instead of falling back to NCCL. DeepSeek-V4-Flash TP4 decode on Blackwell gains up to +6.9% at small batches. Auto-enabled for DeepSeek-V3/V3.2/V4; elsewhere --enable-flashinfer-pure-allreduce"

（純粋なallreduce向けのFlashInfer MNNVL：融合されていないallreduce処理の箇所が、NCCLにフォールバックする代わりに、FlashInferのMNNVLワークスペースを再利用するようになった。Blackwell世代GPU上のDeepSeek-V4-Flash・TP4構成のデコード処理では、小バッチ時に最大+6.9%の性能向上が得られる。DeepSeek-V3/V3.2/V4では自動的に有効化され、それ以外のモデルでは--enable-flashinfer-pure-allreduceで有効化する）

「Non-fused（融合されていない）allreduce」というのは、他の演算と一体化（融合）されずに単独で実行されるallreduce処理を指す。PR #30700の説明（Motivation）によれば、SGLangはDeepSeek-V3/V4向けにすでにFlashInfer経由の「融合された」allreduce（kARResidualRMSNorm：allreduce・残差接続・RMSNormを1つのカーネルにまとめる処理）をサポートしている。だがRowParallelLinear（行方向に分割された線形層）・attention出力のフォールバック処理・MoE(専門家混合)のTPフォールバック処理が行うallreduceは「融合されていない（pure）」ため、FlashInferのMNNVL／TensorRT-LLM用ワークスペースがすでに初期化済みで使える状態であっても、常にNCCLまたはカスタムallreduce実装にフォールバックしていた、とPRは説明している。

今回のPRは、この「融合されていないallreduce」の呼び出し箇所を、AllReduceFusionPattern.kAllReduceという既存のFlashInfer機構経由に振り向け、追加のメモリコストなしに既存のワークスペースを再利用する。実装はflashinfer_comm_fusion.pyに新しいflashinfer_allreduce()関数を追加する形で行われ、(1)FlashInferが使えない、または_flashinfer_commが未初期化、(2)入力が2次元の連続配列でない（3次元の語彙埋め込み出力など）、(3)ワークスペースが未初期化またはバッファが小さすぎる、のいずれかに該当する場合はNoneを返し、既存のca_comm（カスタムallreduce）→pymscclpp→NCCLという順のフォールバック連鎖に自動的に戻る設計になっている。parallel_state.py側では、_TP・_ATTN_TP・_MOE_TP・_MOE_EPという各グループコーディネータに_fi_workspace_hintという属性をスタンプし、GroupCoordinator.all_reduce()がこのヒントを見て新しい経路を優先的に試す仕組みが追加されている。PR全体の変更規模は7ファイル・追加476行・削除6行だった。DeepSeek-V4-Flashが自動有効化の対象になる仕組みについては、後述の「PRの実コード差分を読んで分かったこと」で確認できた内容を記載している。

PR本文の記述を整理すると、この最適化に関わる要素は次のようにまとめられる。

「小バッチ時に」という条件付きの改善

+6.9%という数字には「at small batches（小バッチ時に）」という条件が付いている。バッチサイズが大きくなるほど、通信のオーバーヘッドは計算全体の時間に対して相対的に小さくなる傾向があるため、この最適化が効くのは、GPUの計算負荷がまだ十分に埋まっていない小バッチ・低レイテンシ重視のシナリオだと考えられる。逆に言えば、大バッチでのスループット重視の運用では、この最適化の恩恵は限定的である可能性がある。

対応モデルは自動有効化、それ以外はフラグが必要

この機能は、DeepSeek-V3・V3.2・V4という特定のモデルファミリーでは自動的に有効になる一方、それ以外のモデルで使う場合は--enable-flashinfer-pure-allreduceという起動フラグを明示的に付ける必要がある。「対応が確認できているモデルは既定でオン、それ以外は手動オプトイン」という段階的な展開方針は、同じv0.5.18に含まれる他の最適化（overlapped checkpoint stagingなど、明示的なフラグが必要な機能）とも共通する慎重さがうかがえる。

Blackwell世代GPUでの計測が続く

このリリースノートでは、TP LMHead All-to-Allの最適化（DeepSeek-V4-Pro・B200）でもBlackwell世代GPUが計測対象になっていた。今回のFlashInfer MNNVL allreduceの最適化も同じくBlackwell世代を対象にしており、SGLangの開発チームが最新世代のNVIDIA GPU向けの通信最適化に継続的に取り組んでいることがうかがえる。MNNVL（Multi-Node NVLink）自体が、複数のサーバーノードをNVLinkで直結する構成を前提とした技術であり、単一サーバー内の複数GPUというより、より大規模なマルチノードクラスタでの運用を意識した最適化だと考えられる。

確保済みのリソースを使い回すという保守的な選択

筆者は自分でマルチノードのGPUクラスタを運用した経験はないが、「すでに確保済みのリソース（ここではMNNVLワークスペース）を、別の処理でも再利用することで、新たな通信ライブラリの呼び出しコストを避ける」という設計方針は、ソフトウェア一般に通じる最適化の型だと感じる。NCCLという業界標準のライブラリを使わない、という判断自体が一見大胆に見えるが、実際には「すでに確立された自前の通信経路を、用途を広げて使い回す」という保守的な選択でもある。

PRの実コード差分を読んで分かったこと

https://github.com/sgl-project/sglang/pull/30700.diffを取得し、実際に変更された7ファイルのコード差分を読んだ。分かったことは次の通り。

• 呼び出し箇所は2か所ある：GroupCoordinator.all_reduce()内に_can_use_flashinfer_allreduce()の判定が2か所追加されている。1つはtorch.compiler.is_compiling()（torch.compile・CUDA graphキャプチャ中）の分岐内、もう1つはpynccl経由のallreduceが使えないと判定された後の通常実行パス。つまりこの最適化はtorch.compile使用時に限らず、通常の実行パスでも動く設計になっている。
• 新規カスタムopとして登録：parallel_state.pyに追加されたflashinfer_allreduce()関数には@register_custom_op(out_shape="tensor")が付与されている。docstringには「Dynamo（torch.compileのグラフトレーサ）に対して不透明なopとして登録することで、piecewise CUDA graphの内部でも動作できるようにした」という設計意図が明記されている。
• _FLASHINFER_ALLREDUCE_FUSION_ARCHSへの追加は、このPR自身が行っている：v0.5.18タグ時点のoverrides.py（raw.githubusercontent.comで直接取得・確認）を見ると、このリストは実在し、DeepseekV3ForCausalLM・DeepseekV32ForCausalLM・DeepseekV4ForCausalLMを含む計17アーキテクチャ（GptOss系・GLM MoE系・Qwen3 MoE系・KimiK2.5・NemotronH系など）が登録されている。このうち DeepseekV4ForCausalLM の1行は、PR #30700 自身が追加したものだった（2026年9月4日に github.com/sgl-project/sglang/pull/30700.diff を取得したところ、diffの先頭が overrides.py で + "DeepseekV4ForCausalLM", が入っている）。PRのコメント欄でも Collaborator の nvpohanh 氏が「SGLang only supported FlashInfer MNNVL AR for DSV3 but not DSV4. This PR adds that support for DSV4」と説明しており、V4対応の追加がこのPRの内容であることと整合する。自動有効化には、アーキテクチャの一致に加えて「flashinfer_allreduce_fusion_backendが未設定」「SM90かSM100のGPU」「tp_size > 1」「DPアテンションが無効」「単一ノードまたはSM100」「moe_a2a_backendがnone」という6条件がすべて揃う必要があると、overrides.py内の_flashinfer_allreduce_fusion_auto_enable関数のコードから確認できた。
• リリースノートのフラグ名とソースコード上のフラグ名が一致しない：公式リリースノートは--enable-flashinfer-pure-allreduceという名前を挙げているが、v0.5.18タグのserver_args.pyをこの文字列で検索しても該当箇所は見つからなかった。今回のPRが実際に参照しているのは既存のflashinfer_allreduce_fusion_backend（CLIでは--flashinfer-allreduce-fusion-backend、選択肢はauto/trtllm/mnnvl）で、bootstrap.pyの変更はこの値がNoneでなければ新機能を有効にする、という条件分岐になっている。リリースノート本文の記載とソースコード上のフラグ名がなぜ一致しないのかは、本記事の範囲では原因を特定できていない。

「+6.9%」という数値がどのバッチサイズ範囲で測定されたものか、具体的な閾値は今回確認したリリースノート本文にもPR #30700の本文にも記載がなかった。DeepSeek-V4-Flash・TP4以外の並列化構成（TP8など）や、Blackwell以外のGPU世代（Hopperなど）での実測値についても、公式リリースノート・PR本文の範囲では確認できていない。SGLangを自分の環境で動かし、この最適化のオン・オフで実際に速度差が出るかを検証したわけでもない。

関連記事

• ローカルLLMとは何か──自分のPCでAIを動かす仕組み・利点・始め方を解説
• LLMベンチマークの読み方──MMLU・HumanEval・Arenaの注意点【2026年版】