# AIインフラにおけるストラグラー問題 停止せずに動き続けながら性能だけが落ちる要素、いわゆるフェイルスロー（fail-slow）は、同期型の大規模分散学習において1台の遅延が全体のスループットを律速する。 本サーベイは、この現象をクラウドストレージ領域の一般理論からAI/MLインフラ特有の検知システム、事後学習、強化学習(RL)への波及まで、24本の文献を横断して整理する。 出典は末尾の番号引用で示し、参照文献で確認できない主張は「記載なし」または「未解決の問い」として明示する。 **読み方の指針**: 座標系だけを知りたいなら第2章。原因の分類を知りたいなら第3章、第4章。検知システムを比較したいなら第5章、第6章の表。組織別の実装を知りたいなら第9章。 --- ## 本サーベイのスコープ 本サーベイが扱うのは、同期分散学習(事前学習と、事後学習、強化学習の同期ロールアウト)において、停止せず稼働し続けながら性能を劣化させるノード、リンク、GPU、すなわちストラグラー(フェイルスロー)問題である。 LLM学習インフラ全体の運用プレイブックとは対象が重なるが、本サーベイはストラグラー問題の原因、検知設計、学習フェーズ横断の波及、組織別実装に焦点を置く。 扱う範囲は次の4点である。 - **原因の体系化**。「遅いワーカー=壊れたマシン」という直観がどう覆されたか(第3章、第4章)。 - **検知手法の設計原理の対比**。なぜピアベース比較なのか、なぜマルチシグナル融合なのか、なぜ常時稼働ではなく間欠稼働を選ぶのかという設計判断の理由(第5章、第6章)。 - **学習フェーズ横断の波及**。事前学習と事後学習RLでストラグラーの性質がどう変わるか(第8章)。 - **組織別実装の詳細比較**(第9章)。 教科書側が既に持つ「主要診断システムの比較表」「信号源による分類」の基礎的な整理と重複する記述は参照に留める。 サイレントデータ破損(SDC、正確性の問題であり性能劣化そのものではない)は本サーベイのスコープ外とする。 SDCとストラグラーの交差点(SDCが誘発する性能劣化)は第11章の未解決の問いで扱う。 --- ## 第1章 なぜこの問題が構造的に不可避か 同期分散学習は embarrassingly parallel ではない。 モデルをGPU間で分割し、GPUは密に通信する。 単一ジョブが数万GPUを占有するため、1つのストラグラーがジョブ全体を減速させる。 スケジューラ側でもジョブはギャングスケジューリングの意味論を持ち、1タスクの失敗がジョブ全体の再割当を引き起こす[1]。 規模も時間も、通常のソフトウェアシステムとは桁が違う。 ByteDanceの本番LLM学習クラスタでは、5か月、3,079ジョブのうち42.5%が10%以上スローダウンし、全GPU時間の10.4%がストラグラーで浪費された[2]。 Tencentのデータセンターインフラ Astral は、フェイルスローを含む障害分類のうちフェイルスローが13%、診断が難しいフェイルハングが17%を占めると報告する[3]。 MegaScaleは、約0.5%のマシンが顕著に遅い計算ストラグラーとなり、除去によりMFUが0.7%改善したと報告する[4]。 ARGUSは、4096GPUの訓練ジョブ1件でフェイルスローにより約23,758GPU時間(総計算量の7%)が浪費された実例を報告する[5]。  **図1-1**: 4096GPU訓練ジョブでのフェイルスロー。上段は反復時間のスパイク、下段は期待される累積進捗(点線)と実際の累積進捗(実線)の乖離を示す。乖離が時間とともに開き続ける様子が、上記の23,758GPU時間の浪費に対応する。 [5]（図1） 障害の内訳を見ても、GPU関連が突出する。 TSLocが6か月、100タスクの本番Kubernetesクラスタから収集した98件の障害事例では、GPU関連52%、ネットワークカード/ケーブル18.3%、マシンクラッシュ13.2%、PCIe劣化9.1%という構成であり、うち14件がフェイルスロー、84件がフェイルストップに分類される[6]。 この現象自体は、AI/MLインフラに固有ではない。 クラウドストレージ領域では、フェイルスローハードウェア(FSH)バグの研究が2023年から2026年にかけて先行して進んだ。 JIRA課題データベースから収集された48件のFSHバグの分析では、根本原因の81.2%が非並行性(無期限ブロッキング、不具合のある内部チェッカ等)であり、89.6%が単一のフェイルスローハードウェアで発現することが示されている[7]。 AlibabaのPERSEUSは、ストレージデバイスのレイテンシ対スループット分布がノード単位でのみ均質になるという発見に基づき、25万台規模のドライブ運用へ本番展開された[8]。 これらの一般理論は2023年から2026年にかけて確立され、ML特化の実態解明(2025年のOSDI論文)、本番検知システム(2025年から2026年にかけてのMLSys、NSDI、ASPLOS、ICDCS)がそれに続くという年代の流れが見える。 **文献系譜の注意** クラウドストレージのFSH研究とAI/MLインフラのストラグラー研究は、**独立した文献系譜**である。 参照文献群の精読では、TOCS、login;、FASTのいずれのページにもGPU、アクセラレータ、分散学習ジョブへの直接の言及は見当たらなかった(記載なし)。 両者の接続は、「単一の劣化コンポーネントが全体を律速する」「単一視点の検知では不十分」「局所性(ノード単位でのみ均質)」という構造的なアナロジーにとどまり、実証的な接続は参照文献に記載がない。 --- ## 第2章 分類の4軸 母集団24本の文献を配置する座標系として、4つの軸を立てる。 ### 軸1: 根本原因 | 値 | 内容 | 代表文献 | |---|---|---| | ハードウェア劣化 | GPU個体差、サーマルスロットリング、ECC/GSP/NVLinkエラー、ストレージ、NIC個体の劣化 | [9]、[10]、[11] | | ソフトウェア、データ起因 | パイプラインステージ分割不均衡、シーケンス長不均衡、Python GC、JITコンパイルストール | [2]、[12]、[5] | | ネットワーク、集合通信起因 | リンク劣化、輻輳、集合通信の透過的リルート、ECMPの非効率経路選択 | [13]、[3] | | 環境、電源要因 | 電力供給不安定、サーマルスロットリング | [10] | ### 軸2: 検知の信号源と粒度 | 値 | 内容 | 代表文献 | |---|---|---| | ステップ時間(秒) | 学習ステップの反復時間を一次シグナルとする | [10]、[14] | | ホストメトリクス(秒) | CPU/GPU利用率、PFCカウンタ等をマシン間比較 | [15] | | 集合通信、トラフィックトレース(us〜ms) | NCCLトレース、RDMAトラフィック計測 | [16]、[17]、[18] | | カーネル、フェーズ統計(us〜分) | CUPTIカーネルトレース、統計圧縮 | [5] | | 事後の統計分析 | 本番トレースからのwhat-if分析、実測変動の統計特性化 | [2]、[9] | ### 軸3: 学習フェーズ | 値 | 内容 | 代表文献 | |---|---|---| | 事前学習(同期データ/パイプライン並列) | ハードウェア確率的故障、演算不均衡がストラグラーを生む | 第3章、第4章の全文献 | | 事後学習、RL(同期ロールアウト) | マルチターン対話の軌跡長ばらつきが最遅軌跡を生む | [19]、[20] | ### 軸4: データ出自 | 値 | 内容 | 代表文献 | |---|---|---| | 本番大規模テレメトリ | 数千から10万GPU超規模の実運用データ | [2]、[14]、[3] | | 制御実験、小規模実測 | HPCセンターでの統制されたベンチマーク | [9]、[21] | | 合成、障害注入 | ChaosBlade等による人工的な障害生成 | [22]、[17]、[18] | 軸の被覆を確認すると、軸1の「環境、電源要因」は文献1本(Guard内の一節)にしか値を持たない。 これは主題として独立に扱うには薄く、第3章でハードウェア劣化の一種として扱う。 --- ## 第3章 原因分類:ハードウェア起因のフェイルスロー ### 一般理論としてのフェイルスローハードウェア クラウドストレージ領域の研究は、フェイルスローハードウェアの本質を「粒度」に見出す。 粗粒度の障害(完全停止)は既存のフェイルストップ機構で検知できるが、細粒度の障害(部分的な劣化)は、冗長、フォールトトレランス機構そのものが症状を隠す逆説を生む。 ZooKeeperのフェイルスローNIC事例では、heartbeatが別I/O経路を通るため障害の影響を受けず、クラスタは健全と見なされ続け、診断に5か月を要した[7]。  **図3-1**: ZooKeeperのLeader-Follower間レプリケーション。緑のHeartbeatは別経路のため健全に見え続けるが、赤のデータ複製経路がフェイルスロー NICで詰まる。冗長機構(Heartbeat)そのものが症状を隠す逆説を示す。 [7]（図1） Lu ら(上海交通大学)の実測では、100万台超のNVMe SSDを4か月監視した結果、平均1.41%が影響を受けていた[7]（内の引用、著者の所属は[8] 内の同一著者グループの記載に基づく）。 Gunawi ら(University of Chicago)の調査(2018年)では、分単位で検知できたのは全ケースのわずか1%だったとされる[7]（内の引用、著者の所属はHaryadi S. Gunawi（University of Chicago）による）。 これら一般理論とAI/MLインフラの接続は、構造的なアナロジーの域を出ない。 参照文献群のいずれにもGPUやアクセラレータへの直接の言及はなく、この点は確認できない。 ### GPUハードウェアの個体差と劣化 TPDS論文は、同一型番のGPU(A100、GH200)間にも実測可能な性能変動があることを示す。 GEMM実行時間のばらつきは、Tensor Coresで3.7%から8.8%、CUDA Coresで0.1%から8.2%(いずれも外れ値を除く、5データ型範囲)である[9]。 単一の最遅GPUをGPT 19Bの3D並列訓練(8台構成)に混入させるだけで、配置(DP/PP/TPのどの位置か)に関わらず一貫して8.0%から8.5%のスループット低下が生じる[9]。  **図3-2**: Tensor Cores(上)とCUDA Cores(下)における精度別のvariability(棒)とCV(数値)。FP64ではTensor Coresで最大8.8%、CUDA Coresで最大8.2%に達し、本文のばらつき幅と対応する。 [9]（図3） Guardは、サーマルスロットリングによりGPU温度が50℃から77℃へ上がるとコア周波数が1.93GHzから1.38GHzへ低下する事例を報告する[10]。 電力供給が不安定な場合、クラスタ平均比で10%から15%低い消費電力でFLOPS利用率が低下する[10]。 **見かけ上の矛盾** OSDI論文の主張(第4章)は「ストラグラーの主因はハードウェアではなく計算オペレーションのスローダウンである」というものである。 TPDS論文は同じ問いに対し、ハードウェア個体差だけでも同期訓練を有意に減速させることを実証する。 本サーベイでは両者を「両立する」と整理する。 OSDI論文は主因の統計的多数派(何が最も多くのジョブでスローダウンを説明するか)を論じ、TPDS論文は統計的少数派でも実害の大きい経路(ハードウェア個体差だけでも8%前後の低下を生む)を実証しており、問いの立て方が異なるため両者は矛盾しない[2][9]。 GPU世代交代でも、信頼性は単調に改善しない。 NCSAのDelta HPCでの2.5年、1,170万GPU時間の実測比較では、H100はメモリレジリエンスがA100より低下する(訂正不能ECCメモリエラーのper-GPU MTBEがA100比3.2分の1)一方、GSP、NVLink、PMU SPIといった重要ハードウェアコンポーネントの障害は劇的に減少している[11]。 A100はGSPエラー3,857件、NVLinkエラー1,922件を記録したのに対し、H100はGSPエラーがわずか3件、NVLink、PMU SPI、Fallen Off the Busは観測ゼロだった[11]。 GPUエラーの大半はアプリケーション側で回復されずジョブ失敗に至るため、著者らは大規模運用に約5%のオーバープロビジョニングが必要だと試算する[11]。 ### ネットワークリンクの劣化 Astralのフェイルスロー実例では、NCCLタイムラインで通信遅延ノードを特定し、ミリ秒級のQPレート監視でリンク帯域が50%未満に低下していることを検出し、sFlowパスとINTヒートマップで各ホップの遅延を測定して集約-ToR下りリンクの輻輳を特定、最終的にECMPの非効率な経路選択が根本原因と判明した事例が示されている[3]。 C4は、集合通信が限られた長寿命フローから成るという予測可能性を利用し、通信遅延行列の行、列の偏りからslow connectionをリンク単位で特定する[13]。 Titanスーパーコンピュータでの多数ペアI/O実験は、ハードウェアの恒常的な故障を仮定しなくても、健全な多数のノードの中で一時的に最遅になったペアが集約帯域を律速することを示す。 336ペア全使用時、200ペアではEAB(有効帯域)が期待値の40%未満に低下し、全ストラグラーを除く反実仮想では90%の試行が47.75%超改善した[21]。 低性能ラベルのシーケンスの70%以上が1分以内に正常に戻るという観測は、ストレージ層のストラグラーが短命であることを示唆する[21]。  **図3-3**: クライアント数(50から336)に対するEABの箱ひげ図。クライアント数の増加とともに中央値が低下し、200クライアントで中央値は0.2程度(期待値の40%未満)まで下がる。本文の「200ペアでEABが期待値の40%未満に低下」に対応する。 [21]（図18） --- ## 第4章 原因分類:ソフトウェア、データ起因 ### 「遅いワーカー=壊れたマシン」の反証 OSDI論文は、ByteDance本番クラスタの5か月、3,079ジョブのトレースをWhat-if分析(ストラグラーが存在しない代替タイムラインをシミュレートし、実トレースと対比する手法)で解析し、直観を覆す結論に至った。 最も遅い3%のワーカーがスローダウンの過半を説明するジョブは、ストラグラージョブ全体のわずか1.7%にすぎない[2]。 支配的な根本原因は次の3つである。 - **パイプラインステージ分割の不均衡**。39.3%のジョブで最終パイプラインステージが過半のスローダウンを引き起こす。9層構成では最終ステージのforward/backward-computeが平均ステージの2.07倍、1.41倍に達する[2]。 - **シーケンス長の不均衡**。21.4%のジョブで影響し、平均スローダウン比は1.34である[2]。 - **Pythonのstop-the-worldガベージコレクション**。全ワーカー同期のGCタイミングのずれがスローダウンを生む[2]。  **図4-1**: 左は全ストラグラージョブのforward-backward相関のCDF(0.9で全体の78.6%に達する)、右はGCストラグラーの代表的なタイムライン(DPランク0から2が異なるステップでGCを起こし、互いを待たせる)。左は本文のシーケンス長不均衡(相関係数0.9以上を閾値とする21.4%)、右はPython GCによるスローダウンの機構に対応する。 [2]（図11, 図13） 緩和策も具体的である。 貪欲法によるシーケンス再分配で23.9%(32Kトークンの最大シーケンス長のジョブ限定)、計画的なガベージコレクション(500ステップごと)で12.6%(128 DPランクのジョブ限定)のスループット改善を得た[2]。 MegaScaleも独立に同種の現象を報告する。 集合通信(reduce-scatter)のlaunch時刻ズレに起因するMFUの漸進的な低下は、GC等が原因であり、該当コードセグメントの除去で解消したと述べている[4]。 ### XPUTimer/Flareが観測した本番のソフトウェア起因スローダウン Ant Groupの6,000GPU超クラスタでの8か月以上の運用データから、著者らは表形式で複数の性能回帰事例を報告している。 | 原因 | 規模、モデル | 低下率 | |---|---|---| | GPUアンダークロック | 480 GPU、Llama-65B | 14%低下 | | バックエンド移行 | 1,856 GPU、Llama-80B | 33.3%低下 | | ネットワークジッタ | 928 GPU | 10〜20%低下 | | Python GC | 2,048 GPU、Llama-80B | 10%低下 | | 不要なGPU同期 | 256 GPU、Llama-20B | 2.66%低下 | | hugepage起因の高sysload | 1,344 GPU、Llama-176B | 19%低下 | | データローダ | 512 GPU、Llama-80B | 41%低下 | [12] これらはいずれも、単一GPUの計算能力を見るマイクロベンチマークでは検出できず、issue latency distribution(カーネル発行から実行開始までの遅延分布)やvoid percentage(GPUの空き時間比率)という新規のマイクロメトリクスで初めて特定できたと著者らは述べる[12]。 ### 集合通信が障害を隠す ARGUSのケーススタディ5(12,960GPUのMoE学習)では、演算ストラグラーの遅延がエキスパート並列の集合操作へ伝播した結果、他ランクのReduceScatterがむしろ短縮するという逆パターンが観測され、アウトオブバンド監視は「サーバーポートダウン」と誤って通信障害を報告した。 ARGUSはフェーズレベル分析で、実際には計算専用オペレータのみの異常であり通信は正常であることを示し、この誤診断を防いだ[5]。 ケーススタディ3では、パイプライン並列のランク3760の逆伝播計算が正常ランクの約1.9倍に達しながら、パイプライン依存によるバブル転送と勾配同期のアライメント効果という2つのマスキング機構により自動検知が失敗し、手動でのL4トレース解析が必要だった[5]。 ケーススタディ4では、FlashAttentionのJITコンパイルによる断続的なストールが、プロセス再起動でキャッシュが消えるたびに繰り返し発生し、原因確定には手動解析を要した[5]。 --- ## 第5章 検知手法の分類 ### 一般理論からの系譜 クラウドストレージ領域の検知手法は、失敗した設計の教訓の積み重ねとして進化してきた。 PERSEUSの開発チームは3つの試行を経ている。 (1) 閾値フィルタリング: レイテンシがワークロードに強く左右され、緩い/厳しい閾値のトレードオフに直面。 (2) ピア評価: 適応的閾値は得られるが、経験的パラメータのチューニングが別クラスタに通用しない(300ノード規模でオンサイトエンジニアが2時間を要した)。 (3) IASOベースモデル: ソフトウェアタイムアウトを直接使えず代替指標で不満足な性能。 最終的にノード単位のレイテンシ対スループット分布への多項式回帰という設計へ収斂した[8]。  **図5-1**: レイテンシ対スループット(LvT)分布の集約レベル別比較。クラスタ単位(a)、ノード単位(b)では複数の分布が混在するが、同一ノード内ドライブ(c)でのみ分布が重なる。ノード単位でのみ均質になるという発見の直接的根拠。 [8]（図3） 後発のSlowSightは、時間視点(履歴からの逸脱)とピア視点(コンポーネント間の乖離)のどちらか単独では不十分だという先行研究の教訓(Attempt2: permanent フェイルスローに弱い、Attempt3: 異常がピア集団の大部分に及ぶと効力低下)を統合し、両視点を候補区間レベルで組み合わせる設計を採った[22]。 ### AI/MLインフラでの信号源と粒度 AI/MLインフラの検知システムは、計測点の違いによって取りこぼす障害クラスが異なるという構造を持つ。 | 計測点の層 | 代表システム | 得意な範囲 | 構造的な死角 | |---|---|---|---| | ステップ時間、ホストメトリクス | Guard、Minder、C4 | ノード単位の粗い箇所特定 | マイクロ秒級の症状は見えない | | NIC/RDMAトラフィック | Pulse | inter-node集合通信のマシン単位局所化 | NVLink等scale-upネットワークは監視外 | | NCCL API/RDMA WR | Mycroft、MEGATRACE | 秒未満の高速な検知、ステージレベル識別 | ソフトウェアスタックへの直接計装依存(移植性の制約) | | カーネル、CPUスタック | ARGUS、XPUTimer/Flare | 全スタック横断、根本原因の深掘り | 常時稼働には統計圧縮が必須 | | 劣化トリガー時のみの重い計装 | EROICA | オフラインプロファイラ並みの粒度を全ワーカーで実現 | 瞬間的な劣化や訓練外プロセスの競合は対象外 | [10][15][13][17][16][18][5][12][14] 「集合通信層 vs. トラフィック層 vs. 訓練スタック全体」という計測点の三層構造は、それぞれが取りこぼす障害クラスを分ける。 Pulseは意図的にNIC上のトラフィック計測に踏みとどまりCCLに一切触れない設計を取るため、inter-node collectiveのマシン単位ストラグラー特定に強い一方、NVLink等のscale-upネットワークとCollNet/NVLSは監視対象外であることを著者自身が認めている[17]。  **図5-2**: 上段の表は障害タイプ別の典型原因(太字がPulseの評価対象)、下段はOP-level(1ms粒度)とsub-OP-level(32us粒度)でのストラグラー観測の違い。OP-levelではストラグラーランクと正常ランクの通信オペレータの実行時間がほぼ同一に見えるが、sub-OP-levelでは正常ランクの送信ギャップ(Gaps)が明瞭に観測できる。表中の「NIC-GPU cross NUMA binding」のような太字項目は、上表のPulseの信号源(NIC/RDMAトラフィック)がマイクロ秒粒度でなければ捉えられない障害クラスにあたる。 [17]（表2、 図1） Mycroftは逆にNCCLソフトウェアスタックへの直接トレースポイント追加に依存し、これが新しいNCCLバージョンや他CCLへの移植性の制約になっている[16]。 ### 教師あり(既知パターン)と教師なし(逸脱検知) 計測点の層とは別に、検知アルゴリズムが過去の障害ラベルに依存するかどうかという軸がある。 Minderは決定木で障害感度順にメトリクスをランク付けするが、この決定木は過去の障害チケットで訓練されており、訓練データに存在しない新規障害型への汎化ができないという閉世界仮定を抱える[6]。 TSLocはこの閉世界仮定を取り除くため、障害ラベルを一切使わない教師なし逸脱検知として問題を再定式化する。 健全ノードは同一コード、同一データ分割を実行するため正常な同期挙動には強い群コンセンサスが成立するという前提に立ち、共有Mixture-of-Expertsの時系列エンコーダで空間逸脱(ノード間距離)と時間的volatility(埋め込みの時刻間変化)を学習し、Reciprocal Rank Aggregationで異種メトリクスを横断集約する[6]。 この設計により、新しい監視メトリクスが追加されてもモデル全体の再訓練なしにダウンストリームのエキスパート重みが自動適応するというday-oneサポートを得る[6]。 --- ## 第6章 検知システム各論 以下は本サーベイが扱う主要な検知システムの一覧である。 | システム | 組織 | 信号源 | 診断段階 | 主要な精度指標(評価条件付き) | |---|---|---|---|---| | Guard | Amazon | DCGM+サイドカー(GPU/ネットワーク)+ステップ時間 | ピア比較→多信号融合→時間フィルタ→段階的緩和 | FPR 12.4%、FNR 7.8%(条件記載: 詳細な母集団条件記載なし)。MTTF 6.6h→16.7h(2.5倍) | | Minder | ByteDance | 秒単位のホストメトリクス20種 | マシン間類似度+連続性判定 | precision 0.904、F1 0.893(9か月、150障害インスタンス) | | C4 | Alibaba | BSP同期点+集合通信到達タイミング | 通信遅延行列でslow connection特定 | エラー誘発ダウンタイム31.19%→1.16%(30ヶ月本番展開) | | Mycroft | ByteDance | NCCL proxy(completion log/state log) | トリガー→依存性駆動根本原因分析 | 検知90%が15秒以内、根本原因60%が20秒以内 | | Pulse | Nanjing University/Infrawaves | RNIC上のマイクロ秒級トラフィック計測 | operator分割→マシン単位診断 | machine-level 12中10、precision>90%、recall100%(64 H200テストベッド) | | NIXT | UC Riverside/NVIDIA | NCCL Inspectorプラグイン出力 | SQLベースの4種相関分析 | ログ削減26倍(最大2,048 GPU、Nemotron-4) | | XPUTimer/Flare | Ant Group | Python API+CUDAカーネル+issue latency distribution | ハング診断→スローダウン診断→協業 | 真陽性81.8%、偽陽性1.9%(113件本番回帰候補) | | ARGUS | Tencent | CPUスタック+セマンティクス+CUPTIカーネル | L1〜L5の5段階(自動L1-L3、手動L4-L5) | オーバーヘッド2%未満(本番10,000GPU超、6か月) | | EROICA | Alibaba | Torch Profiler+nsysの間欠稼働(20秒窓) | 期待値/ピア差分距離の2指標 | 本番80件中97.5%診断成功(既存監視は29.6%止まり) | | MEGATRACE | Beihang University/Infrawaves | NCCL API+RDMA WR | クリティカルパス分析でマスキング除去 | ハングF1=1.00、スローダウンF1=0.95 | | PERSEUS | Alibaba(ストレージ) | ノード単位LvT分布への多項式回帰 | 外れ値検知+リスクスコア累算 | precision 0.99、recall 1.00、MCC 0.99(公開データセット) | | Sieve | Huazhong University of Science and Technology | 同期、タイムアウト保護I/Oの静的解析 | 障害注入によるバグ再現 | 未知バグ7件検出(3システム、2,000テスト実行) | | SlowSight | (匿名) | 時間視点+ピア視点の統合 | 知識駆動フィルタ+パターン中心ラベリング | F1 0.851(Huawei Cloud本番)、ラベリング時間90%超削減 | | TSLoc | CNIC(中国科学院)/StepFun | 共有MoE時系列エンコーダによる空間逸脱+時間的volatility | 教師なし逸脱検知(決定木不使用)+Reciprocal Rank Aggregation | Acc@5=0.908、平均応答4.2秒(6か月、100タスク、障害98件) | いくつかの設計判断は、システム間で対照的である。 **なぜマルチシグナル融合か**。 Guardは学習ステップ時間を一次シグナル、ハードウェアメトリクスを補助シグナルとする明確な階層構造を持ち、「ハードウェアエラーカウンタのみでノードを故障と判定しない」と明記する[10]。 一方Minderは、メトリクスを単一モデルへ統合すると相互干渉で誤誘導されるとして、あえてメトリクスごとに独立モデルを作り、決定木で障害感度順にランク付けして順に検査する「分解+順序探索」戦略を取る[15]。 TSLocはこのMinderの決定木を名指しで批判し、決定木が過去の障害チケットで訓練される以上、訓練データに無い障害型やday-oneの新規メトリクスには対応できないと指摘する[6]。 Minder(教師あり、決定木)とTSLoc(教師なし、逸脱検知)は同じホストメトリクスの群を対象にしながら、既知パターンへの依存を許容するか排除するかで設計が分岐する。  **図6-1**: 左(図1)はタスク規模別の1日あたり故障頻度、右(図2)は手動診断時間のCDF。手動診断は90%のケースで数十分から100分超を要し、長い裾では600分に達する。Minderの平均検知時間3.6秒(手動比99%短縮)は、この裾の長さに対する改善である。 [15]（図1、 図2） **検知の出力粒度**。 Minderはマシン単位の箇所特定に明示的に限定し、根本原因(コンポーネント種別)の同定には追加の人手が必要だと自認する[15]。 Guardはオンライン検知をノード単位のスコアに留めつつ、オフラインノードスイープで根因(CPU設定、通信経路劣化、GPU演算性能劣化)まで診断的に分析する[10]。 C4は通信遅延行列によりslow connection(リンク単位)まで特定し、3者の中で最も細かい出力粒度を持つ[13]。 NIXTも同様に、通信子(communicator)単位までストラグラーを局所化する。  **図6-2**: 混在AllGather(24MiB)における通信子ごとの正規化帯域幅の分布。健全run(左)は通信子0が高帯域で安定するのに対し、ストラグラーrunのStraggler-A(中央)は帯域が低下しばらつきも増加、Straggler-B(右)は通信子2のみが影響を受ける。通信子単位での局所化が可能であることを示す。 [23]（図16） MEGATRACEは、ハングとスローダウンの両方でSOTA比の精度改善を報告する。  **図6-3**: ハング検知(左、青)とスローダウン検知(右、赤)のF1スコア比較。MEGATRACEはハングでF1=1.00、スローダウンでF1=0.95を達成し、比較対象のJIT、C4、Holmes、Minder、MegaScaleをいずれも上回る。上表の精度指標と対応する。 [18]（図7） **フェイルスローは依然として検知が難しい**。 TSLocは障害種別ごとにAcc@5を報告しており、フェイルストップのAcc@5=0.952に対しフェイルスローはAcc@5=0.643に落ちる[6]。 教師なし逸脱検知という新しい設計でもこの差が残ることは、フェイルスローの検知の難しさが特定の検知アルゴリズムの限界ではなく、現象そのものの性質(明示的なエラーを出さず、症状が緩やかにしか現れない)に起因することを示唆する。 **常時稼働か間欠稼働か**。 Mycroft、ARGUS、MEGATRACE、Pulse、NIXTは常時計装によりトレース量を圧縮(環形バッファ、KDEクラスタリング、DuckDB削減、per-QPレート集約)して低オーバーヘッド(2%未満から0.16%)を実現する。 対してEROICAは逆に、劣化検知時のみ20秒間、オフラインプロファイラ級の重い計装を全ワーカー同期実行するという差分オブザーバビリティ戦略を取る。 著者らは、オフラインプロファイリングを常時展開すると10,000GPUで約1TB/秒に達し不可能になると述べている[14]。 ARGUSは表1でMegaScale、EROICA、FLAREを「細粒度だが常時デプロイ不可(5%から30%オーバーヘッド)」に分類しており[5]、これはEROICA自身の主張と部分的に緊張関係にある。 ただしEROICAの重い計装は劣化検知後の20秒間だけ動くため、両者の記述だけからこの緊張が実質的な矛盾かどうかは確定できない。 **評価指標の注意** 精度指標(F1、precision、recall等)は評価母集団が全く異なるため、表の数値を単純に横並び比較してはならない。 Pulseは64GPU研究室テストベッドの12種注入障害、MEGATRACEは256サーバの注入障害、EROICAは既存手法で解決できなかった本番の難問80件、XPUTimer/Flareは1週間の本番実ジョブ113件が母集団である。 特にEROICAとXPUTimer/Flareは「既存手法が解決できなかった/見逃した」問題を評価対象に選んでおり、構造的に高い成功率が出やすい評価設計になっている(この点は両論文とも明記していない)。 --- ## 第7章 緩和策 緩和策は、検知の出力粒度に対応して階層化されている。 **段階的緩和(ノード単位)**。 Guardは異常スコアに応じて3段階の対応を取る。 10%未満は監視継続、10%から20%は次回チェックポイントまで待機して緩和、20%以上は即座にプールから除外、再起動する。 1週間以内に3回入ったノードは恒久不良と判定する。 著者ら自身が、これらの閾値は経験則であり理論的裏付けは示していないと明記する[10]。 **ネットワーク経路の動的再構成(リンク単位)**。 Astralはソフトボンディング(single-port RNIC前提で主系、予備系を事前設定し、PCIeスイッチ跨ぎ、root complex跨ぎ、NUMA跨ぎのコストで予備を選ぶ)、動的チャネル再平衡(予備RNICを共有してストラグラー化したチャネルを無効化し健全チャネルへ再分配)、NVLink経由の中継GPU(小規模通信グループ向けにPCIeボトルネックを回避)という3つの技術要素を用いる[3]。 これら緩和策とフルスタック監視を組み合わせた結果、フェイルスローの障害箇所特定時間(MTTLF)は本番運用で約5倍短縮された[3]。  **図7-1**: 監視システム導入後の安定性改善。フェイルストップ(a)、フェイルハング(b)、フェイルスロー(c)それぞれで、時間経過とともに障害件数(棒)が増える一方、MTTLF(折れ線)は低下し続ける。フェイルスロー(c)のMTTLF低下が本文の「約5倍短縮」に対応する。 [3]（図10） **アルゴリズム的な再分配(ソフトウェア起因)**。 OSDI論文の緩和策は、シーケンス再分配(貪欲法)と計画的ガベージコレクションであり、それぞれ23.9%と12.6%のスループット改善を報告する(限定条件付き、第4章参照)[2]。 **復旧オーバーヘッドの経済コスト化**。 HPCA論文はETTR(生産的実行時間/壁時計時間)という指標でチェックポイント間隔、再起動オーバーヘッド、障害率を単一の設計空間に統合し、10万GPU級では約2分のチェックポイント間隔と約2分の再起動時間が必要だと導出する[1]。 レモンノード(過去の除外回数、XID数、修理チケット等を特徴量とする故障疑いノード)の検知は85%超の精度を達成し、512以上のGPUを使う大規模ジョブの失敗率を14%から4%へ低減した[1]。 SC論文は可用性とMTTR(平均復旧時間、A100 0.88時間、H100 2.2時間)から必要オーバープロビジョニング率を導出し、復旧時間を5分短縮すればオーバープロビジョニングを2%(2.5倍削減)にできると試算する[11]。 両者とも「復旧時間短縮 → 必要な冗長リソース削減」という同型の定量トレードオフを、異なる指標(ETTR vs. オーバープロビジョニング率)で表現している。 --- ## 第8章 学習フェーズ横断の波及 ### 事前学習と事後学習RLでのストラグラーの構造的な異同 同期バリア型ストラグラーは、事前学習と事後学習RLでは全く異なる時間スケール、原因構造で発生する。 事前学習(第3章、第4章で扱った系)では、ハードウェア故障というランダムかつ稀な事象(MTTF数時間から数十日、MTBE数万時間)が起点になる。 一方、事後学習RLの同期ロールアウトでは、マルチターン対話の軌跡長のばらつきという決定論的、恒常的な要因が同期バリアのストラグラーを生む。 SWE-RL論文は「同期パイプラインはストラグラー問題(最遅軌跡がボトルネック)を抱える」と明記し、AgentRL論文は「同期的ロールアウトでは長い軌道がGPUアイドルを生む」と明記する[19][20]。 ハードウェア故障のような低頻度イベントへの言及は、この2論文のどちらにも見当たらない(記載なし)。  **図8-1**: SWE-RLの同期RLパイプライン1反復。Rollout Generation(オレンジ、CPU律速)がworker 1からNまで並列実行された後、Verification Process(オレンジ)、Dataset preparation、Training(緑、GPU律速)へ直列に進む。全workerの完了を待つRollout Generationの構造が、最遅軌跡によるボトルネックを生む。 [19]（図4） ### 非同期化という解決策と、そのコスト 事前学習側のストラグラー対策(レモンノード検知、適応ルーティング、チェックポイント間隔最適化)は、同期実行モデルを維持したまま故障頻度、復旧時間を下げるアプローチである。 これに対しRL側は、同期実行モデル自体の放棄を志向する。 AgentRLは完全非同期の生成、訓練パイプライン(ロールアウトと訓練を独立リソースグループで実行)により、14BモデルのWebshopタスクで同期パイプライン比1.7倍から1.9倍のスループット向上を報告する[20]。  **図8-2**: AgentRLのアーキテクチャ。上段(Asynchronous Pipeline)はTrainingとRolloutが独立に進行し、Paramsは実線、Dataは破線で流れる。下段はController配下の複数Hostによる環境管理と、交差方策サンプリング(Cross-Policy Sampling)、タスクアドバンテージ正規化を示す。SWE-RL(図8-1)の直列構造との対比になる。 [20]（図2） ただし非同期化は新たなコストを伴う。 SWE-RL論文は、同期パイプライン内部でさえvLLMアップグレードによりtop-k/min-pフィルタが暗黙有効化され、ロールアウト分布と真の方策が乖離し、重要度サンプリング比が不正確になって5から10反復後に性能が劣化した事例を報告する[19]。 AgentRLは、非同期パイプラインで動的バッチサイズとデータキューの最大サイズ制限によりオフポリシーの偏りを抑制し、さらに交差方策サンプリング(一部のロールアウトエンジンを「陳腐化エンジン」としてパラメータ更新を複数ステップ遅延させる)で方策バージョンのずれを制御する設計を採る[20]。 交差方策サンプリングを除去するアブレーションでは、成功率が65.0%から60.7%へ低下する[20]。 同期、非同期いずれの構成でも、ロールアウト方策と学習方策のずれの制御が中心課題として現れる点は、事前学習側の文献には存在しない論点である。 ### 検知システムはRLの役割異質性を前提していない 第5章、第6章で扱った検知システムは、いずれも均質なワーカー群の中から外れ値を探すという前提に立つ。 Guardのピア比較もMinderのマシン間類似度も、TSLocの群コンセンサスも、同じ役割のノードが同じ負荷を分担することを暗黙の前提としている(第6章)。 この前提は、RLの非同期パイプラインでは崩れる。 TSLocを700台超の本番クラスタで運用した際、失敗した4件の障害特定に共通するパターンとして、RLタスクの異種サブタスク(軽量な推論ノードと重い訓練更新ノードが混在する構成)がリソース消費パターンの違いにより、正常な低負荷推論ノードを「異常」と誤判定させる事例が確認された[6]。 これは、AgentRLのController配下でHostごとに異なる役割(図8-2)を持たせる設計や、SWE-RLのRollout GenerationとVerification Processが異なる負荷特性を持つ構造(図8-1)と、同じ「役割の異質性」を指している。 第3章から第6章で扱った検知システムはいずれも事前学習の均質ワーカー群を評価環境としており、RLのような役割が構造的に異なるノード群への適用実績は参照文献からは確認できない。 TSLoc自身も、この誤判定への対処としてrole-aware modeling(役割を考慮した比較)を今後の課題に挙げるにとどまる[6]。 --- ## 第9章 組織別実配備状況 | 組織 | システム | 一次指標 | 規模 | 主要な成果 | |---|---|---|---|---| | Amazon | Guard | ステップ時間分散、MFU | 数千GPU、8GPU/ノード | ステップ時間分散20%→1%、MFU最大1.7倍 | | ByteDance | Minder、Mycroft、MegaScale、OSDI what-if分析 | ホストメトリクス類似度、依存性トレース、MFU | 最大12,288GPU(MegaScale)、9か月、150障害(Minder) | Minder検出3.6秒(手動比500倍高速)、MegaScale MFU 55.2%(12,288GPU) | | Alibaba | C4、EROICA、PERSEUS | BSP同期点、期待値/ピア差分距離、ストレージLvT分布 | 10,000GPU超(C4)、~100,000GPU(EROICA)、25万台ドライブ(PERSEUS) | C4エラー誘発ダウンタイム30倍削減、EROICA本番80件中97.5%診断成功 | | Tencent | Astral、ARGUS | 4層階層相関、KDE圧縮カーネル統計 | 128K→512K GPU目標(Astral)、10,000GPU超、6か月(ARGUS) | Astral MTTLF最大25倍短縮、ARGUSオーバーヘッド2%未満 | | Meta | Zoomer | rank間実行タイムライン比較 | 数十万GPU規模 | Ads関連モデルで訓練時間75%短縮(評価条件の詳細記載なし) | | Ant Group | XPUTimer/Flare | issue latency distribution、void percentage | 6,000GPU超、8か月以上 | 真陽性診断精度81.8%、チーム協業頻度63.5%減少 | | Huawei | SlowSight | 時間視点+ピア視点統合ラベリング | 実運用ストレージ(D1)、公開データセット(D2) | ラベリング時間90%超削減(F1 0.851) | | Nanjing University/Infrawaves | Pulse、MEGATRACE | RNICトラフィック計測、NCCL API+RDMA WR | 64H200テストベッド(Pulse)、256サーバ+3840GPU本番実績(MEGATRACE) | Pulse machine-level 12中10特定、MEGATRACEハングF1=1.00 | | NVIDIA/UC Riverside | NIXT | NCCL Inspectorプラグイン出力のSQL分析 | 最大2,048GPU(Nemotron-4) | ログ削減26倍、既知ストラグラーホストの局所化 | | CNIC(中国科学院)/StepFun | TSLoc | 共有MoEエンコーダの空間逸脱+時間的volatility | 16〜5,000超GPU、6か月、100タスク | Acc@5=0.908、平均応答4.2秒、長尾障害23件中Acc@5=0.826 | 一次指標として何を掲げるかは、組織、文書の性格によって分かれる。 ByteDance系(MegaScale)はMFU(観測スループット÷理論ピークFLOPsの比)を効率の一次指標に据える[4]。 Tencent系(Astral)は訓練効率スケーリングとMTTLF(障害箇所特定時間)を一次指標とし、MFUという語は参照文献の抽出範囲には現れない[3]。 Meta(Zoomer)はさらに異なり、QPS改善率、訓練時間短縮率、電力削減率という下流の運用指標で語る[24]。  **図9-1**: Zoomerの三層アーキテクチャ。最下層のInfrastructure and Platform Layer(GPU Hosts、CPU Hosts、DCGM等)から、Analytics and Insights Engine Layerでrank間比較によるストラグラー分析等を行い、最上層のVisualization and UI Layerでユーザーへ提示する。ストラグラー分析は中段の分析エンジン層に位置づけられる。 [24]（図1） 同じ「ストラグラー対策」でも、測定の単位系が「モデル計算効率」「インフラ障害特定時間」「運用コスト」の3層に分かれ、横並び比較が本質的に難しい。 なお、AstralはMegaScale(ByteDance、10K GPU規模)とMeta(32K GPU規模)を自らの先行事例として引用しており[3]、「単一ジョブ規模(MegaScale)→単一Pod/データセンター規模(Astral)→数十万GPUの推論、GenAI規模(Zoomer)」という段階的な規模拡大の系譜が読み取れる。 --- ## 第10章 横断的発見 **発見1: 「遅いワーカー=壊れたマシン」は、計算層、ストレージI/O層、ハードウェア層の3層で独立に反証される。** OSDI論文は計算層で、上位3%のワーカーが主因のジョブはわずか1.7%だと示す。 TOS論文はストレージI/O層で、健全な多数のノードの中で一時的に最遅になったペアが集約帯域を律速することを実測する。 TPDS論文はハードウェア層で、単一の最遅GPUが配置に関わらず一貫してスループットを下げることを実証する。 規模がGPU 8台からノード18,688台まで2桁以上異なるにもかかわらず、3文献は独立に「少数の遅延要素が不釣り合いに大きな性能損失を生む」という非線形性を確認している[2][21][9]。 **発見2: 「単一シグナルでは不十分」という設計原則が、クラウドストレージとAI/MLインフラの両系譜で独立に到達されている。** PERSEUSはピア評価単独がクラスタ間で通用しないと結論し、ノード単位の統計回帰という単一の解に収斂した。 SlowSightは時間視点単独とピア視点単独の双方に固有の弱点があるとし、両視点の統合に至った。 Guardは学習ステップ時間を一次シグナルとする階層構造、Minderはメトリクスごとの独立モデルによる順序探索という、同じ「マルチシグナル」でも異なる設計に到達している[8][22][10][15]。 **発見3: ステージレベル(計算か通信のどのプリミティブか)の識別が、2025年から2026年にかけて複数の独立したシステムで共通の新規性として追求された。** MEGATRACEは「既存手法はwhen/which serverには答えるがwhich stageに答えない」と明示的に批判する。 Pulseは別レイヤ(NICトラフィック)から同じ課題に到達し、XPUTimer/FlareはCUDA-GDBのintra-kernel inspectingでステージを絞り込む。 3システムが独立に同じ課題を新規性として主張していることは、この課題が期間中の共通の未解決課題として認識されていたことを示唆する[18][17][12]。 **発見4: GPU世代交代は、コンポーネント種別ごとに信頼性トレンドが分岐し、単純な「新世代は信頼性が高い」という仮説を否定する。** H100はメモリレジリエンスがA100より悪化する一方、GSP、NVLink、PMU SPIなどのハードウェアエラーはほぼ消滅した(第3章参照)。 HPCA論文が「H100/GB200世代への一般化には追加検証が要る」と自ら限界として述べた直後に、SC論文がまさにその追加検証を行い、非単調な結果を示した点は、両論文を並べて初めて見える[1][11]。 **発見5: 復旧オーバーヘッドの経済コスト化という定量枠組みは事前学習側にのみ存在し、事後学習RL側には対応する枠組みがない。** HPCA論文のETTRとSC論文のオーバープロビジョニング率は、いずれも「復旧時間短縮 → 必要な冗長リソース削減」を定量化する。 一方、SWE-RL論文とAgentRL論文には、ストラグラーによる訓練スループット損失をコストや必要リソース量に換算する定量枠組みは記載がなく、定性的な記述にとどまる[1][11][20][19]。 **発見6: 評価母集団の選択バイアスが、高い成功率の一因になっている可能性がある。** EROICAとXPUTimer/Flareは、いずれも「既存手法が解決できなかった/見逃した」問題を評価対象に選んでおり、これは構造的に高い成功率が出やすい評価設計である。 この選択バイアスの存在は両ページとも明記していない[14][12]。 **発見7: フェイルスローの検知困難性は、検知アルゴリズムの学習パラダイムを問わず一貫する。** Astralはフェイルスロー(13%)とフェイルハング(17%)が明示的な診断ログを出さないため特定が難しいと述べ、これは決定木ベース(Minder)やピア比較(Guard)といった教師ありまたはルールベースの手法を念頭に置いた指摘である。 教師なし逸脱検知という別の学習パラダイムに立つTSLocでも、同じ非対称性が独立に現れる。 フェイルストップのAcc@5=0.952に対しフェイルスローはAcc@5=0.643に落ちる。 2つの異なる設計思想が同じ非対称性に独立に到達したことは、フェイルスローの検知困難性が特定のアルゴリズム設計の欠陥ではなく、現象そのものの性質(症状が緩やかで、単一時点のスナップショットでは健全ノードと区別しにくい)に起因することを示唆する[3][6]。 --- ## 第11章 未解決の問い - **ヘテロジニアス、輻輳環境でのOSDI結論の一般化可能性**。「ストラグラーの主因は計算オペレーションであり、ハードウェア障害ではない」というOSDI論文の結論は、ByteDance特有の均質ハードウェア、広帯域、専用クラスタに基づく。ヘテロジニアス環境や輻輳ネットワーク下でこの結論が成立するかは、著者ら自身が「不明」と認めており、参照文献からは確認できない[2]。 - **TP/CPグループ内ストラグラーの観測手法の欠如**。OSDI論文はTP/CPグループ内のストラグラーが、使用したプロファイラの粗粒度プロファイリングでは分析不能(遅いマイクロバッチとして現れ理想時間が推定できない)と明記する。Pulseも同様に、TP-groupの内部詳細特定には対応していない。両者を埋める手法は参照文献には見当たらない[2][17]。 - **複数同時フェイルスロー障害への対応**。Sieveは単一障害注入に絞る設計上、複数の同時発生障害(10.4%)を扱えない。複数障害を効率よく扱う注入戦略は、参照文献では未設計である[7]。 - **検知と再現のフィードバックループの欠如**。PERSEUS(統計的検知)の検知結果をSieve(因果的再現)の注入テストのシード選定へつなぐ統合は、両研究では試みられていない[7][8]。 - **完全な計算、通信オーバーラップ時の通信ストール見落とし**。EROICAは、通信が計算と完全にオーバーラップする実装ではクリティカルパスに通信ストールが現れず見落とす可能性を自ら認めている。ただし本番では完全オーバーラップは実証されていないとも付記しており、実害の程度は参照文献からは確認できない[14]。 - **サイレントデータ破損(SDC)との交差点**。本サーベイはSDCをスコープ外としたが、SDC由来のGPU劣化が性能劣化(ストラグラー化)を伴うかどうかは、参照文献群では扱われておらず、参照文献からは確認できない。 - **ハードウェア世代交代がストラグラー特性そのものに与える影響**。第10章の発見4はH100/A100間のエラー種別の変化を示すが、この変化がストラグラー検知システムの設計(閾値、信号源の選択)にどう影響するかは、参照文献群のいずれも扱っておらず未検証である。 - **役割が異質なノード群への検知システムの一般化**。第8章で見たように、TSLocは均質ワーカー群を前提とした群コンセンサス検知が、RLの異種サブタスク(推論ノードと訓練更新ノード)混在下で誤検知を起こす事例を報告し、role-aware modelingを今後の課題とするに留める。GuardやMinderのようなピア比較型の検知システムが同様の環境でどう振る舞うかは、参照文献群のいずれも評価しておらず、参照文献からは確認できない[6]。 --- ## 付録 ### A. 用語集 - **ストラグラー**：分散処理の他のワーカーより遅く、同期点で全体を待たせる要素。 - **フェイルスロー（fail-slow）**：停止せずに稼働し続けるが、性能だけが劣化する障害。 - **フェイルストップ（fail-stop）**：要素が明確に停止し、既存の障害検知機構で扱いやすい障害。 - **フェイルハング（fail-hang）**：処理が停止または長時間応答しない状態。 - **グレーノード**：機能検査は通過するが、実ワークロードで性能が劣化しているノード。 - **集合通信**：AllReduceやReduceScatterなど、複数GPUが協調して行う通信。 - **MFU**（Model FLOPs Utilization）：理論ピークに対する実効的なモデル計算性能の比率。 - **MTTLF**（Mean Time To Localize Failure）：障害の発生から障害箇所の特定までの平均時間。 - **ETTR**（Effective Time To Recovery）：障害と復旧のオーバーヘッドを含めた実効的な回復指標。 - **what-if分析**：ストラグラーが存在しなかった反実仮想の実行時間を推定し、実測値と比較する分析。 - **ピア比較**：同じ役割のノード群を相互比較し、相対的な外れ値を検知する方法。 - **RL**（Reinforcement Learning）：強化学習。ここでは主に同期または非同期のロールアウトを伴う事後学習を指す。 ### B. 参考文献 [1] Apostolos Kokolis ほか. "Revisiting Reliability in Large-Scale Machine Learning Research Clusters." *HPCA 2025*, IEEE, 2025. https://ieeexplore.ieee.org/document/10946752 [2] Jinkun Lin ほか. "Understanding Stragglers in Large Model Training Using What-if Analysis." *OSDI 2025*, USENIX, 2025. https://www.usenix.org/conference/osdi25/presentation/lin-jinkun [3] Qingkai Meng ほか. "Astral: A Datacenter Infrastructure for Large Language Model Training at Scale." *SIGCOMM 2025*, ACM, 2025. https://dl.acm.org/doi/10.1145/3718958.3750521 [4] Ziheng Jiang ほか. "MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs." *NSDI 2024*, USENIX, 2024. https://www.usenix.org/conference/nsdi24/presentation/jiang-ziheng [5] Jiasheng Zhou ほか. "ARGUS: Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters." arXiv:2606.20374, 2026. https://arxiv.org/abs/2606.20374 [6] Quan Zhou ほか. "TSLoc: Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters." *KDD 2026*, ACM, 2026. https://doi.org/10.1145/3770855.3818499 [7] Gen Dong ほか. "Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems." *ACM Transactions on Computer Systems*, 2026. https://doi.org/10.1145/3838187 [8] Ruiming Lu ほか. "Detecting Fail-Slow Failures in Large-Scale Cloud Storage Systems." *login:*, USENIX, 2023. https://www.usenix.org/publications/loginonline/detecting-fail-slow-failures-large-scale-cloud-storage-systems [9] Michael Mogilevsky ほか. "Quantifying Performance Variability in GPU Clusters." *IEEE Transactions on Parallel and Distributed Systems*, 2026. https://doi.org/10.1109/TPDS.2026.3684387 [10] Guanliang Liu ほか. "Guard: Scalable Straggler Detection and Node Health Management for Large-Scale Training." *Proceedings of Machine Learning and Systems 8 (MLSys 2026)*, 2026. https://arxiv.org/abs/2605.17879 [11] Shengkun Cui ほか. "Characterizing GPU Resilience and Impact on AI/HPC Systems." *SC 2025*, 2025. https://arxiv.org/abs/2503.11901 [12] Weihao Cui ほか. "XPUTimer / Flare: Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale." arXiv:2502.05413, 2025. https://arxiv.org/abs/2502.05413 [13] Jianbo Dong ほか. "Enhancing Large-Scale AI Training Efficiency: The C4 Solution for Real-Time Anomaly Detection and Communication Optimization." *HPCA 2025*, IEEE, 2025. https://ieeexplore.ieee.org/document/10946823/ [14] Yu Guan ほか. "EROICA: Online Performance Troubleshooting for Large-scale Model Training." *NSDI 2026*, USENIX, 2026. https://www.usenix.org/conference/nsdi26/presentation/guan-yu [15] Yangtao Deng ほか. "Minder: Faulty Machine Detection for Large-scale Distributed Model Training." *NSDI 2025*, USENIX, 2025. https://www.usenix.org/conference/nsdi25/presentation/deng [16] Yangtao Deng ほか. "Mycroft: Tracing Dependencies in Collective Communication Towards Reliable LLM Training." *SOSP 2025*, ACM, 2025. https://arxiv.org/abs/2509.03018 [17] Yibo Xiao ほか. "Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement." *ASPLOS 2026*, ACM, 2026. https://dl.acm.org/doi/10.1145/3779212.3790163 [18] Fangzheng Jiao ほか. "MEGATRACE: Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters." *ICDCS 2026*, IEEE, 2026. https://doi.org/10.1109/2575-8411.2026.00049 [19] Alexander Golubev ほか. "Training Long-Context, Multi-Turn Software Engineering Agents with Reinforcement Learning." arXiv:2508.03501, 2025. https://arxiv.org/abs/2508.03501 [20] Hanchen Zhang ほか. "AgentRL: Scaling Agentic Reinforcement Learning with a Multi-Turn, Multi-Task Framework." arXiv:2510.04206, 2025. https://arxiv.org/abs/2510.04206 [21] Bing Xie ほか. "Characterizing Output Bottlenecks of a Production Supercomputer: Analysis and Implications." *ACM Transactions on Storage*, 2020. https://doi.org/10.1145/3335205 [22] Yongxin Zhao ほか. "Labeling the Invisible: A Scalable Framework for Labeling Fail-Slow Failures in Cloud Storage Systems." *FAST 2027*, USENIX, 2027. https://www.usenix.org/conference/fast27/presentation/zhao [23] Ziyang Jia ほか. "NIXT: A NCCL Inspector Exporter Tool for Observability of Collective Communication in Large Model Training." arXiv:2608.01449, 2026. https://arxiv.org/abs/2608.01449 [24] Prashant Gupta. "Zoomer: Powering AI Performance at Meta’s Scale Through Intelligent Debugging and Optimization." Meta Engineering, 2025. https://engineering.fb.com/2025/11/21/data-infrastructure/zoomer-powering-ai-performance-meta-intelligent-debugging-optimization/