# Tuning Collective Patterns to Alleviate Congestion in Shared AI Clusters > [!abstract] 概要 > 分散 AI 学習は、複数の GPU ノード対の間でのデータ交換を繰り返すラウンドから成る。1 本のフローが輻輳で遅くなるだけで、通信ラウンド全体が遅くなりうる。AI クラスタで輻輳を回避する現行の手法は、ワークロード全体に対する大域的な制御(例: 全ジョブのスケジュールの協調)を前提とするか、インフラ側の支援(例: スイッチの適応ルーティング)を前提とする。そのため、ある利用者の AI ジョブが、他の利用者のジョブや自身の制御が及ばないバックグラウンドトラフィックから外部輻輳を受けうる共有クラウド環境には適さない。本論文では、GPU ノード間で繰り返されるデータ交換のパターン(集団通信として知られる)を、輻輳に応じて調整するシステム REACT を構築する。REACT はアプリケーション(通信ライブラリ)層で動作し、容易に得られるフロー統計から実行時に輻輳を検知して、情報交換の意味(例: AllReduce ツリーでどのノードがデータを集約するか)を保ったまま、接続されるフローの集合を変更することで集団通信パターンを調整し、輻輳を緩和する。REACT は下位のネットワーク基盤による明示的な支援を必要とせず、共有クラウド環境で個々の利用者が単独で導入できる。REACT を NCCL 上のシム層としてプロトタイプ実装し、共有の学術 GPU クラスタで評価した。REACT を有効にすると、ネットワーク輻輳下で通信性能(アルゴリズム帯域)が 13%〜38% 向上する。さまざまな輻輳シナリオでのシミュレーションでは最大 75% の性能向上も確認され、手法の有効性が示された。 ## 論文情報 - タイトル: Tuning Collective Patterns to Alleviate Congestion in Shared AI Clusters - 著者・所属: Eashan Gupta(UIUC)、Yongzhou Chen(Meta)、Apoorve Mohan・Pavlos Maniotis・Abdullah Kayi(IBM Research)、Radhika Mittal(UIUC) - 媒体: arXiv:2609.04417v1 [cs.NI](2026-09-03) - 21 ページ(本文 12 ページ+参考文献・付録)。プロトタイプは PyTorch と NCCL 上のシム層として実装 ## 概要 共有クラウドの GPU クラスタでは、ある利用者の分散学習ジョブが他利用者のジョブやストレージ転送から外部輻輳を受ける。REACT は通信ライブラリ層だけで動き、数エポックごとに集めたフロー完了時間(FCT)から輻輳を検知し、集団通信パターン上のノードを意味を保ったまま入れ替えて輻輳フローを避ける。共有学術クラスタの実機で輻輳下のアルゴリズム帯域が 13〜38% 向上し、ns-3 シミュレーションでも一貫した改善が得られた。 ## 問題設定 - 分散学習は計算フェーズと通信フェーズを持つエポックの繰り返しであり、通信フェーズがエポック時間の 10〜90% を占める。同期バリアのため、1 本のフローの遅延が通信フェーズ全体を遅らせる。 - 集団通信ライブラリ(CCL: NCCL・Gloo・OpenMPI)は、ジョブ開始時に一度だけ集団通信パターン(データ交換の具体的な手順の並び)を決め、以後のエポックで使い回す。ネットワークの状態が変わると、この初期パターンは最適から外れる。 - 対象は、他利用者のジョブ・大きなファイル転送・同一ジョブ内のチェックポイントやデータコピーなどから、数百ミリ秒以上続く外部輻輳を受ける共有 GPU クラスタである。大規模 Clos から単一ラック星形まで、RDMA・TCP・独自プロトコル、ECMP・適応ルーティングを問わない。 - 設計上の制約は 3 点。(1) アプリケーション層のみを変更でき、ネットワーク支援や経路変更は使えない。(2) 他ジョブやネットワーク全体の情報は得られず、CCL 内のローカル情報だけを使う。(3) 数エポック内に反応できる低オーバーヘッドであること。 - 対象外: 1 エポック内で消える一過性の輻輳。すべてのリンクが輻輳している場合など、ノードの入れ替えで解消できない輻輳。REACT は最善努力のシステムである。 ## 提案手法 REACT は、各エポック終了時に全ノードが自分のフロー完了時間をリーダー(既定はランク 0)へ送り、B = 6 エポックごとにリーダーが輻輳検知と変換を行い、更新後のパターンを全ノードへ配布するフィードバックループである(図3)。 **Figure 3: REACT の状態遷移図** ![[_attachments/arxiv-2609.04417/fig03-feedback-loop-state.png]] (Figure 3. GPU 上の学習ワークロード(橙)が入力パターンで通信し、CPU 上の別スレッドが FCT 収集・制御ループ・新パターン探索・配布を担う。輻輳が検知されなければ現行パターンを維持し、検知されれば変換を適用して新パターンを配る。) ### 例: 二重二分木 AllReduce でのノード入れ替え NCCL の二重二分木 AllReduce は、偶数ランクが葉となる木(図1a)と奇数ランクが葉となる木(図1b)の 2 本でメッセージを 2 チャンクに分けて縮約する。16 ノード・単一 ToR の設定で、ノード 3 に p 本の外部フローが入ると、縮約フェーズのコストは無輻輳の 4α + (7/2)β·s から 4α + (3 + p/2)β·s に増える(α はリンク伝搬遅延、1/β はリンク容量、s はメッセージサイズ)。図1c は入れ替え前、図1d は輻輳ノード 3 とノード 2 を入れ替えた後の物理リンクを示し、輻輳リンクを避けられる。α = 4 µs、β = 1/(100 Gbps)、s = 2 MB、p = 2 では縮約時間が 576 µs から 656 µs に増えるが、入れ替えにより 576 µs へ戻り、著者は約 14% の改善とする。 **Figure 1: NCCL Tree-AllReduce で輻輳ノード 3 を 2 と入れ替える例** ![[_attachments/arxiv-2609.04417/fig01-tree-swap-example.png]] (Figure 1. Figure 1a と Figure 1b は Tree-AllReduce のノード間の論理フロー、Figure 1c と Figure 1d は入れ替えの前後で輻輳した物理リンクを避けられることを示す。赤と青の矢印は、1 と 5 から送られるチャンクの宛先が 3 から 2 に変わることを表す。) ### 表現: 時間展開ネットワーク(TEN) 集団通信パターンを時間展開ネットワークとして表す。頂点 (t, r) は論理時刻 t のランク r、有向辺は連続する時刻間で実行されるフローに当たる。二重二分木 AllReduce の TEN を図2に示す。図2a は偶数葉の木、図2b は奇数葉の木で、同色のノードが互いに入れ替え可能な等価集合である。Ring AllReduce と再帰倍化 AllGather の TEN は付録(図9)にある。 **Figure 2: NCCL 二重木 AllReduce の TEN** ![[_attachments/arxiv-2609.04417/fig02-dual-tree-ten.png]] (Figure 2. Figure 2a は偶数葉の木、Figure 2b は奇数葉の木。縮約とブロードキャストの両フェーズを含めて展開した TEN。同色のノードは位置等価スワップで自由に入れ替えられる等価集合を表す。) ### 輻輳の検知(§5.2) B エポック分のフロー完了時間から各フローの実効スループット b_f を求め、TEN の次数(入次数と出次数の最大値)が同じフローの平均と比べる。 - **定常輻輳**(ToR とサーバー間のリンクなど迂回できないリンクや、スパイン層全体の輻輳)は、p90(b_f) < mean(b_F(k_f))·(1 − δ1) で検知する。δ1 = 0.2 とし、輻輳時に少なくとも 20% の性能低下を想定する。 - **散発輻輳**(マルチパスのため一部のエポックでのみ当たる、スパインと ToR 間などの輻輳)は、スループットの正規化標準偏差が δ2 = 0.15 を超えるかで検知する。 - リンクの部分故障(100 Gbps が 30 Gbps に落ちるなど)も輻輳と同様に扱い、迂回不能リンクなら定常、それ以外なら散発とみなす。 ### 意味を保つ 3 つの変換(§5.3) | 変換 | 内容 | |---|---| | ① 大域置換スワップ | 「All」系の集団操作(AllReduce・AllGather など)はランクの置換に対して等価なので、TEN 上のデバイス x の全出現を y の全出現に入れ替える。ランクとデバイスの対応を変えることに相当する。 | | ② チャンク局所置換スワップ | パターンを独立なチャンクグラフに分け、影響を受けたチャンクだけに置換を適用する。二重木では、片方の木だけを変更できる。 | | ③ 位置等価スワップ | 各チャンクグラフで、入れ替えても集団操作の意味が壊れない位置の組を総当たりで求める。各ノードに 1 ビットだけ立てたビットベクトルを与え、幅優先探索で集団操作を模擬し、最終的な全ノードのビットが条件を満たすかを確かめる。 | - 計算量は一般には O(N^7) に達しうるが、Pareto 最適な代表的パターンでは |V| + |E| = O(N log N) となり、O((N log N)^3) である。ジョブ開始時に一度だけ生成し、実行時は参照する。 - 変更の粒度が細かいほど輻輳箇所に絞れるため、③ を ② を ① より優先する。 - 枝刈り: 変換後、全ランクの各時刻における次数が元の位置の次数を超える候補を除く。さらに、輻輳ノードの次数を下げる候補を優先し、ランダムに 1 つ選ぶ。次数を下げる候補で改善しなければ、他の候補を試す。 表1は、各変換が代表的パターンで解消できる輻輳の種類を示す。Tree AllReduce は 3 変換すべてが有効で、Ring AllReduce は主に大域置換が効く(チャンク内で位置を変えても次数が下がらないため)。再帰倍化は大域置換と位置等価スワップが効く。 **Table 1: 各変換が解消する輻輳の種類(Spine は Spine-ToR 輻輳、Failure はネットワーク故障、All は §5.2 の全種類、✘ は本論文の条件で効かないことを示す)** | 変換 | Ring | Recursive D. | Tree | |---|---|---|---| | ① | Spine, Failure | All | Spine, Failure | | ② | ✘ | ✘ | All | | ③ | ✘ | Spine, Failure | All | (Table 1. CA は集団通信アルゴリズム。Ring 系、再帰倍化 AllGather、Tree 系の 3 種を比較する。) ### 実行時フィードバックループ(§5.4) 1. B エポックの各辺に FCT で重みを付け、エポックごとと平均の重み付きグラフでクリティカルパス(総完了時間が最大の経路)を求める。クリティカルパス上にある輻輳ノードだけを入れ替え対象にする。 2. 輻輳フローを持つ頂点を数の多い順に並べ、定常輻輳を先に解消する。定常輻輳を解消したノードは、他の輻輳ノードの入れ替え先候補から外す。 3. 変換後の FCT を、過去の平均 FCT を新しい次数とメッセージサイズで補正して見積もる(過去データが無い新規フローは同次数の全フローの中央値)。更新後のクリティカルパスの平均時間が (1 + ε) 倍(ε = 5%)以上短くなる見込みのときだけ受理する。これにより、実際に走らせずに 1 エポック内で複数の変換を試せる。 4. 各バッチで適用する変換は最大 Kt = 15 回で、バッチごとに増やして探索空間を広げる。 5. 次のバッチで観測した通信時間が、前の (1 + τr) 倍(τr = 0.05)より短くなければ旧パターンへ戻す(解析モデルの見積もりではなく実測による検査)。 6. 探索は Emax = 5 ラウンド(B × 5 = 30 エポック)まで。改善が見つからなければ現行パターンに留まり、Emax ラウンドのあいだ探索しなかった場合は次のラウンドで再探索して局所解を避ける。H = 60 エポックより古い FCT データは捨てる。 ### 実装(§6) 図4のとおり、集団通信を実行するライブラリ RCollective と、実行時調整器 RTuner の 2 部から成る。 **Figure 4: REACT のアーキテクチャ** ![[_attachments/arxiv-2609.04417/fig04-architecture.png]] (Figure 4. アプリケーション層で、AllReduce・AllGather・Reduce などを提供する RCollective が FCT を RTuner に渡し、RTuner が新しい集団通信パターン(CP)を返す。下位のトランスポート層は hsn0(RDMA)と eth1(TCP)。) - **RCollective**: PyTorch の isend/irecv によるピアツーピア通信で任意の TEN を実装する。チャンクごとの部分グラフに別々の GPU ストリームを割り当て、全カーネルを最初に投入する。各ピアツーピア操作の前後にタイミングイベントを挿入してフロー完了時間を測る。 - **RTuner**: 別の CPU スレッドで動き、リーダーが収集・生成・配布を担う。制御メッセージは Gloo の gather/broadcast で、データ経路とは別の NIC(eth1)を使う。新パターンの合意を待たせないよう、主ジョブは旧パターンで 5 エポック余分に走る。 - **オーバーヘッド**: ストリームやイベントは一度だけ生成して使い回すため小さい。主な負荷は、新パターン配布時の NCCL 通信オブジェクトの再作成と、NCCL の持つバッファ管理最適化を使えない点である。NCCL の ext-net プロファイラで実装することも考えられたが、実験に使った Cray Slingshot はクラスタ固有のライブラリ(libfabric.so と ext-net プラグイン)を介するため、計測フックの挿入が難しかった。 付録 A.4 のパラメータは、B(エポックのバッチ数)、δ1・δ2(輻輳検知の閾値)、Kt(各ターンの試行回数)、ε(見込み改善の下限)、H(保持する過去データの長さ)、Emax(探索ラウンド数)、Amax(最大の探索試行数)、τr(性能劣化を測る巻き戻し閾値)である(表3)。 **Table 3: REACT のパラメータ** | パラメータ | 定義 | |---|---| | B | エポックのバッチの大きさ | | δ1 | 定常輻輳のパラメータ(§5.2) | | δ2 | 散発(不規則)輻輳のパラメータ(§5.2) | | Kt | 各ターンの試行回数 | | ε | 見込み性能改善の下限閾値 | | H | 保持する過去データの長さ | | Emax | 探索ラウンド数 | | Amax | 最大の探索試行数 | | τr | 性能劣化を測る巻き戻し閾値 | (Table 3. 付録 A.4。) ### 付録の補足 - **Ring AllReduce**: 全ノードが入次数 1・出次数 1 の環なので、0→1 のフローがサーバーと ToR 間で輻輳している場合はどの入れ替えでも次数が変わらず効かない。スパインと ToR 間の輻輳なら、ノード 1 と 2 の全出現を入れ替えれば回避できる(図9c)。チャンク内の入れ替えは次数を増やすため効果がない(図9a)。 - **再帰倍化 AllGather**: 後の時刻ほどメッセージが大きい。大域置換で低コストのフローを後段へ回し、チャンクグラフが 1 つなので ② は ① に含まれる。図9b の青と紫のノードは、③ で入れ替えられる 2 つの等価集合である。 - 図10は実験に使った学術クラスタの構成である。 **Figure 9: Ring・再帰倍化の集団通信パターンと大域置換スワップ** ![[_attachments/arxiv-2609.04417/fig09-ring-recursive-doubling.png]] (Figure 9. Figure 9a は Ring AllReduce の TEN、Figure 9b は再帰倍化 AllGather の TEN、Figure 9c は Ring AllReduce に対する大域置換スワップの例。赤スイッチ間で 0→1 が輻輳する場合、1 と 2 の入れ替えで緩和できる。) **Figure 10: 共有学術 GPU クラスタのノード内・ネットワーク構成** ![[_attachments/arxiv-2609.04417/fig10-cluster-topology.png]] (Figure 10. (a)ノード内トポロジ。サーバー内では 4 基の A100 が NVLink で接続される。Figure 10b は Slingshot ネットワークのトポロジ。ToR は互いに全結合し、各サーバーの hsn インターフェースは 1 つの ToR に接続される。青いノードは 4 ノードジョブの例、赤矢印は輻輳を模した外部フローである。) ## 新規性 - 既存の集団通信パターンは、NCCL のヒューリスティクスや Z3・Gurobi などのソルバー合成(TACCL ほか)により、ジョブ開始時に一度だけ生成される。ソルバーは反復実行に計算コストがかかり、リンク特性と全ワークロードの完全な知識も要る。REACT はこの事前生成パターンを入力に取り、実行時に最小限だけ調整する。 - 実行時に集団通信を適応させる先行研究に対して、対象と時間スケールが異なる。Plink は全対の経路を常時プローブし、二層階層木の根と葉の選択だけを変える。AdapCC は 500 エポック単位のプローブとソルバーによる再計算を行う。AutoCCL は NCCL のパラメータ(チャンクサイズ・チャネル数など)を調整するがパターン自体は変えない。REACT は明示的なプローブを使わず、FCT だけで数エポックの時間スケールで反応し、AdapCC が数百エポックごとに作るパターンを入力にして調整することもできる。 - 輻輳回避の他の系統と比べる。経路変更(適応ルーティング、ポート変更による送信元ルーティング、パケットスプレー)はインフラの支援を要し、迂回路のないリンク(ToR とサーバー間)には効かない。REACT はフローの始点と終点そのものを変えるので、そうしたリンクの輻輳も避けられる。Cassini(全ジョブの時間スケジュール)や Crux(経路・優先度の協調)は全ワークロードへの制御を前提とし、Crux はさらにネットワーク内テレメトリなどのインフラ支援を要する。通信と計算の重ね合わせ、圧縮・量子化、低情報パケットの破棄などのアプリケーション統合型手法は意味的に透過でなく、REACT の補完になる。 - 配置の工夫(近接ノードへの配置)とは直交し、配置を固定したまま拠点間輻輳を緩和する。トランスポートの輻輳制御やルーティング(ECMP・適応ルーティング)とも補完的である。 ## 実験設定 - **実機(§7.2)**: 全国規模の共有学術 GPU クラスタ。各サーバーに A100 が 4 基、200 Gbps の Cray Slingshot で接続され、適応ルーティングと GPU Direct RDMA が有効。4 GPU と 8 GPU の 2 ジョブで、異なるノードから GPU を 1 基ずつ確保し、二重二分木 AllReduce(メッセージ 100 MB)を 5,000 エポック走らせた。ノード配置はスケジューラが決めるため、配置ごとにベースラインと REACT を続けて走らせ、同じ配置の比で速度向上を測る。外部輻輳は、外部ノードの CPU から学習ランクの CPU への RDMA ピンポンフロー(1 GB を周期送信)で作り、外部フロー数 p = 0, 1, 2 とした。 - **シミュレーション(§7.3)**: ns-3 のパケットレベルシミュレータで、DCTCP の輻輳制御、スイッチ RED キューによる ECN マーキング(閾値 32 と 60)、バッファ 32 MB、ACK 優先、全リンク 100 Gbps・遅延 1 µs、ECMP。エポックごとにポートを変えて悪い経路に固定されるのを防ぐため、各フローに 4 本の接続(4 ポート)を用意し、エポックごとに 1 本をランダムに選ぶ。特記なき限り 8 ノード、100 エポック、メッセージ 20 MB とし、25 エポック以降の平均アルゴリズム帯域を測る。 - **トポロジ**: 実機は Slingshot(図10b)。シミュレーションは星形、128 サーバーの 3 層 Clos(Fat-tree)、Alibaba トレース由来の 720 サーバー構成(48 ToR、各 3 台の集約スイッチに接続、サーバーは 1 ToR に接続)。 - **輻輳の作り方**: (1) 集団通信に参加しないノードから参加ノードへ外部バックグラウンドフローを注入(輻輳度 p は各始点終点対の外部フロー数)。(2) 重なるノード数を変えた 2 ジョブの同時実行(資源の断片化とサーバー内競合の模擬)。(3) 共有ノードなしでネットワーク経路だけが重なる 2 ジョブ(ネットワーク単独の競合)。(2)(3) はシミュレーションのみ。 - **比較対象**: RCollective 上で REACT なしの実行(ベースライン)。付録では NCCL との比較も示す。 - **指標**: エポックごとの集団通信の完了時間と、メッセージサイズを完了時間で割ったアルゴリズム帯域。 - **対象の集団通信**: NCCL の二重二分木 AllReduce、Ring AllReduce、再帰倍化 AllGather。 ## 実験結果 ### 実機評価(§7.2) 輻輳下(p = 1, 2)で、平均のアルゴリズム帯域が 13〜38% 向上した(表2は、ベースライン対 REACT の完了時間の比。値が 1 より大きいほど REACT が速い)。無輻輳(p = 0)では 4% 未満の低下(平均で 0.964 と 0.963)にとどまり、原因は探索のオーバーヘッドと、輻輳がなくても新しい接続を張るコストとされる。 **Table 2: 実機での Tree AllReduce の速度向上(ベースライン対 REACT の平均・p95 完了時間の比)** | ノード数 | p | 平均 | p95 | 変更回数 | |---|---|---|---|---| | 4 | 0 | 0.964 | 0.999 | 34 | | 4 | 1 | 1.138 | 1.101 | 35.6 | | 4 | 2 | 1.348 | 1.145 | 33.2 | | 8 | 0 | 0.963 | 0.980 | 41.25 | | 8 | 1 | 1.180 | 1.165 | 40 | | 8 | 2 | 1.383 | 1.222 | 36.25 | (Table 2. 各条件でのノード数、輻輳度 p、REACT が行った変更回数。) 付録 C.1 の図11は、4 ノードの 1 回の実行におけるエポック時間の累積分布関数(CDF)である。REACT は p = 1, 2 の輻輳下で、無輻輳のベースラインに近い分布へ寄る。NCCL は外部輻輳の影響を受け、RCollective は p2p 通信子のオーバーヘッドにより多くの場合 NCCL より遅いが、p = 2 では REACT 付き RCollective が輻輳下の NCCL を過半のエポックで上回る。 **Figure 11: 共有 GPU クラスタでの Tree AllReduce のエポック時間 CDF** ![[_attachments/arxiv-2609.04417/fig11-testbed-epoch-cdf.png]] (Figure 11. (a)(b)は p = 1, 2 の輻輳下での REACT の効果。NCCL と RCollective について、無輻輳・輻輳下・REACT 有効の各条件を比べる。) ### 外部フロー数の掃引(§7.3.1) 3 層 Clos・20 MB で、外部フローを受けるノード数と輻輳度 p を変えた 10 通りの乱数シナリオを走らせた(図5)。 - p = 1 の低輻輳でも、最悪ケース(クラスタが特に悪い配置のとき)で最大 20% の改善(Tree と再帰倍化の両方)。 - p = 2, 4 の高輻輳で最大 60〜95% の改善。シナリオ平均は Tree で 35%、再帰倍化で 15%。 - 外部フローが 8 本のとき、Tree AllReduce では全ノードが輻輳し入れ替え先がない。再帰倍化はメッセージが大きい後段の経路距離を縮めてスパインと ToR 間の輻輳を避けられ、高輻輳でも改善できる。 **Figure 5: 乱数 10 シナリオでの平均アルゴリズム帯域の改善率(Fat-tree、20 MB)** ![[_attachments/arxiv-2609.04417/fig05-sweep-bw-improvement.png]] (Figure 5. 横軸は、それぞれ p 本の外部フローを起動する始点終点対の数。Figure 5a は 8 ノード二重木 AllReduce、(b)は 8 ノード再帰倍化 AllGather。p = 1, 2, 4 の 3 系列を示す。) ### テールレイテンシと ECMP(§7.3.2、付録 C.3) ECMP のポート数を増やすと輻輳が緩和されるが、背景フローがあれば集団通信の性能は依然として劣化し、REACT はどのルーティング設定でも改善した。REACT を使えば、多数の ECMP ポート(RDMA キューペア接続)を保つ必要が減り、NIC のメモリ負荷を抑えられる。図13は p95 のエポック時間を、ECMP のポート数(なし・4・8)と NCCL(輻輳なし・あり)、REACT(nccl Tree+CT と表記)で比べる。メッセージが 100 KB 以下では、低い p(図13c)では輻輳の影響が小さく、高い p(図13e)では REACT が改善する。 **Figure 13: p95 の場合の Fat-tree でのアルゴリズム帯域の改善(ECMP と集団通信の調整の効果の比較)** ![[_attachments/arxiv-2609.04417/fig13-tail-latency-ecmp.png]] (Figure 13. (a)〜(e)は 8 ノード NCCL Tree AllReduce の遅延。(a)20 MB・p = 1、(b)2 MB・p = 1、Figure 13c は 100 KB・p = 1、(d)20 MB・p = 4、Figure 13e は 100 KB・p = 4。ECMP のポート/QP 数の増加には追加のコストがかかるが、集団通信の調整は少ない QP 構成でも機能する。) 付録 C.2 の星形トポロジ(図12)では、経路が固定のため REACT がより良い判断でき、Fat-tree(図5a)より高い改善が得られる。 **Figure 12: 星形トポロジでの 8 ノード NCCL Tree AllReduce(20 MB)** ![[_attachments/arxiv-2609.04417/fig12-star-topology.png]] (Figure 12. 縦軸はアルゴリズム帯域の改善率(0〜175% まで目盛られる)、横軸は輻輳フロー数で、p = 1, 2, 4 の系列を示す。) ### 複数ジョブ(§7.3.3) 星形トポロジで Tree AllReduce と Ring AllReduce を同時に走らせ、重なるノード数を変えた(乱数 5 種、図6)。両ジョブが REACT を有効にした場合とベースラインを比べる。 **Figure 6: 重なりの度合いごとの改善率(両ジョブで REACT 有効)** ![[_attachments/arxiv-2609.04417/fig06-two-job-overlap.png]] (Figure 6. ジョブ 1 は 8 ノード NCCL Tree AllReduce、ジョブ 2 は Ring AllReduce。どちらも 20 MB、星形トポロジ。各重なりのシナリオで乱数 5 種を走らせた。) Alibaba トレース由来のトポロジで、ノードの重なりなしにネットワークだけを共有する 2 ジョブ(スパインと ToR 間の輻輳)を走らせた(図7)。ジョブ 1 だけ REACT を有効にすると両ジョブが大きく改善し、REACT は背景トラフィック側も助ける。両ジョブで有効にすると、ジョブ 1 のみの場合より改善が下がる。REACT が両ジョブで独立に働き、互いに悪い構成にはまるためである。ジョブ間で建設的に相互作用させる方法は今後の課題とされる。 **Figure 7: Alibaba トレース由来トポロジで 2 ジョブを同時実行(ネットワークのみ共有、スパイン-ToR 輻輳)** ![[_attachments/arxiv-2609.04417/fig07-alibaba-two-jobs.png]] (Figure 7. (a)Ring AllReduce 2 ジョブ。(b)再帰倍化と Ring の 2 ジョブ。REACT をジョブ 1 のみ有効にした場合と両ジョブで有効にした場合を、REACT なし(灰)と比べる。棒上の数値は各ベースラインからの変化率。) ### ネットワーク故障(§7.3.4) 3 層 Clos で、ランダムに選んだリンクの帯域を 30・50・80 Gbps に下げる部分故障を再現し、4 経路 ECMP のままで走らせた。最悪ケースで最大 20% の改善が得られる(図8)。 **Figure 8: 8 ノード NCCL Tree AllReduce(20 MB、Fat-tree)での部分リンク故障** ![[_attachments/arxiv-2609.04417/fig08-partial-link-failure.png]] (Figure 8. 故障リンク数と劣化後の帯域(80・50・30 Gbps)ごとのアルゴリズム帯域の改善率。) ## 考察 - 集団通信の「All」系操作がランクの置換に対して等価であることを利用し、意味を保ったまま輻輳フローを迂回できる。迂回路のないサーバーと ToR 間のリンクでも、同一次数の別位置へノードを移せば、輻輳したノードをクリティカルパスから外せる。 - 変換の効果は初期パターンと輻輳の種類に依存する(表1)。Ring では ToR-サーバー間の輻輳には効かず、Tree は最も柔軟である。 - 星形のように経路が固定されたトポロジでは、探索が有効に働く(図12)。ECMP のポート数を増やす手法と比べて、REACT は少ない接続で同等以上の効果を出せる(図13)。 - 階層的な集団通信(3D 並列化)は、各階層を独立ジョブとして REACT を適用できる。ストラグラーは遅いノードを後段の時刻へ移す形で、ホスト内輻輳はサーバー内の集団通信への拡張で扱えるとされるが、いずれも未評価である。 - NCCL への深い統合と RDMA 接続確立の高速化(UCM など)で、オーバーヘッドをさらに減らせると述べる。 ## 強み / 弱点・課題 **強み** - ネットワーク支援・大域情報・アプリ改変のいずれも要らず、個々の利用者が単独で導入できる。トランスポートの輻輳制御とルーティングとも補完的。 - 3 種の意味保存変換と、解析モデルによる事前評価・実測による巻き戻しの二段構えで、数エポックで収束する。 - 実機と ns-3 の両方で評価し、Tree・Ring・再帰倍化、複数ジョブ、部分故障を含む。 **弱点・課題** - 無輻輳時に 4% 未満の低下がある。新しい接続の確立と探索のオーバーヘッドが原因である。RCollective は NCCL のバッファ最適化を使えず、多くの場合 NCCL より遅い(図11)。 - 数エポック以上続く輻輳にしか反応できない最善努力型で、ほとんどのリンクが輻輳しているときは効かない。Tree の 8 ノード全輻輳では入れ替え先が残らない(図5)。 - 複数ジョブが独立に REACT を動かすと、互いに悪い構成にはまり、ジョブ 1 のみ有効の場合より改善が下がる(図7)。 - 実機評価は最大 8 GPU(異なるノードから 1 GPU ずつ)の Tree AllReduce ベンチマークで、実際の学習ジョブのエンドツーエンド時間は示されない。 - 数値の表記に揺れがある。抄録は実機で 13〜38%、結論は 13〜35% とし、シミュレーションの最大値は抄録・序論で 75%、§7.3.1 の本文は高輻輳の最悪ケースで 60〜95% と述べる。