# FaultSense: Fault Localization in Large-Scale Mixture-of-Experts Model Serving Infrastructure > [!abstract] 概要 > Mixture-of-Experts(MoE)モデルは数百 GPU にわたって LLM サービングをスケールさせる一方、all-to-all 通信への依存によりグレイ障害(gray failure、例: GPU ストラグラー)の影響を受けやすく、これは明示的なエラーを伴わずにサービング遅延を増大させるため、障害箇所特定(fault localization)を複雑にする。本論文では、ホスト計装なしに MoE モデルサービングのレプリカにおいて故障した GPU と通信経路を特定する、アプリケーション層のアプローチである FaultSense を提示する。FaultSense は軽量な MoE プローブモデルのプロトタイプと、二段階の階層的な障害箇所特定アルゴリズムを導入する。クラスタを GPU 通信グラフとしてモデル化し、(1) 少数のプローブ集合ですべての GPU と通信経路をテストする大域的被覆によって疑わしい構成要素を識別し、その後 (2) 疑わしい構成要素へのdrill-downによって故障 GPU または通信経路を特定する、という 2 つを実行する。我々の設計は、低メモリオーバーヘッドを維持しつつ、すべての構成要素を個別にテストする場合と比較して診断テスト数を削減する(最大 20 倍)。 ## 論文情報 - タイトル: FaultSense: Fault Localization in Large-Scale Mixture-of-Experts Model Serving Infrastructure - 著者: Harish S A, Vignesh S(equal contribution の共同筆頭著者、IIT Hyderabad)、Ashwin Kurella(Microsoft Research, India)、Rohan Gandhi(Microsoft Research, India)、Praveen Tammana(IIT Hyderabad) - 媒体: 17th ACM SIGOPS Asia-Pacific Workshop on Systems(APSys '26)、2026-09-17〜18、Bangkok, Thailand。全8ページ。 - DOI: 10.1145/3838177.3841737。arXiv 版・コードリポジトリの記載なし。Microsoft Research 公開ページ経由で PDF を取得した(`.raw/papers/apsys26-final121.pdf`)。 ## 概要 MoE モデルサービングは all-to-all 通信への依存によりグレイ障害(GPU ストラグラーなど)の影響を受けやすいが、既存のインフラ側監視(NCCL のメトリクスやスイッチログ等)は特権的なホストテレメトリを要求し、マルチテナント環境ではアプリケーションチームがアクセスできないことが多い。FaultSense は、本番トラフィックと同じアプリケーション層のカーネル・collective 演算を経由する軽量な MoE プローブモデルを使い、レイテンシ信号だけから GPU クラスタ(通信グラフ)上の障害箇所を二段階のグループテストで特定する。 ## 問題設定 - **目標**: アプリケーション層から、特権的なインフラテレメトリやサービングスタックの変更なしに、大規模 MoE サービングレプリカにおける故障 GPU・通信経路(TTFT/TBT の悪化として現れる)を検知・特定すること。 - **要件**: - [R1] Fault-agnostic detection: 明示的なエラー信号や大規模なログ解析に頼らず、hard failure・gray failure の両方をエンドツーエンドレイテンシ(TTFT/TBT)の悪化から検知する。 - [R2] Low instrumentation: NVIDIA/AMD 等の異種ハードウェアや vLLM/HuggingFace TGI 等の複数サービングスタックに対応するため、カーネルフック・シム層・ランタイム改変なしに動作する。 - [R3] Agile, Precise and Lightweight localization: 本番サービングへのオーバーヘッドを最小に保ちながら、健全な構成要素と故障構成要素を迅速かつ正確に区別する。 - **背景**: MoE 層はトークンごとに top-k エキスパートをルータで選択し、選ばれたエキスパート間で all-to-all 通信を行う(図1)。 ![[fig01-moe-routing.png]] GPU クラスタのグレイ障害(サーマルスロットリング、メモリエラー、PCIe/NVLink 劣化、輻輳など)は数時間単位で持続しうるが明示的なエラーを出さず、単一の遅い GPU や劣化した通信経路が同期実行全体に連鎖してレイテンシを増大させる。 - **既存アプローチの限界(§3)**: (1) 本番モデルへのテストプロンプト送信は、リクエストがレプリカ内のほぼ全 GPU・通信経路を跨ぐため局所化能力に乏しい。(2) ペアワイズのネットワークプローブ(ping 等)は実際の LLM サービングカーネルや collective 通信挙動を経由せず、アプリケーション固有のボトルネックを見逃す上、100-GPU レプリカで4950回のペアワイズテストが必要になりスケールしない。(3) アプリケーション対応のペアワイズテストは忠実度こそ確保できるが、GPU ペアごとに診断モデルをロードする必要がありコンピュート・メモリオーバーヘッドが大きい。 ## 提案手法 FaultSense は次の3つの技術要素で構成される(§4)。 1. **軽量 MoE プローブモデル**: OLMoE-1B-7B の第1 MoE 層のみを残し、self-attention の出力重みをゼロ化して埋め込みをルータへ直接渡し、学習済みゲーティング行列を単位行列に置換する。これにより i 番目の埋め込み次元が直接エキスパート i を選択するようになり、任意のスパース埋め込み(例: top-4 ルーティングで `[0,1,0,1,0,1,1,0,...]` はエキスパート {1,3,5,6} を決定的に活性化)を与えることで、サービングスタックやランタイムを変更せずに任意の GPU 部分集合とその通信経路を狙い撃ちできる([R2] を満たす)。プローブモデルは本番モデルと同一 GPU 上に同居し、同じストリーム上で同種のエキスパート計算・all-to-all collective を実行する。 2. **トポロジ抽象化と二段階の階層的グループテスト(§4.2–4.3)**: レプリカを無向完全グラフ G=(V,E) として抽象化する(頂点=GPU、辺=GPU 間の論理通信経路、図2a、図2b)。n-GPU レプリカでは |E|=n(n-1)/2 となる。1 つのプローブは k 個の頂点(GPU)と、それらの間の k(k-1)/2 本の辺を同時にテストする。図2は n=8, k=4 の例でグローバル被覆から drill-down までの流れを示す。 ![[fig02-fault-localization-example.png]] - **Phase 1(グローバル被覆、Algorithm 1)**: 最適な被覆探索は NP-hard であるため、貪欲アルゴリズムで全頂点・全辺を最小限のサイズ-k プローブ集合で被覆する(未被覆の接続辺が最多の頂点から始め、辺被覆を最大化する頂点を逐次追加。O(n²k) のオフライン一回限りの計算。例: n=8, k=4 で6プローブに被覆できる、図2c)。プローブのレイテンシ Ti が Phase 1 プローブの中央値レイテンシ T̃ に対して Ti > αT̃(α は設定可能)なら疑わしいと判定する。中央値ベースの相対閾値は、障害が疎であるという前提(健全なプローブが中央値を支配する)のもとで負荷変動や動的バッチングによる一様なレイテンシシフトにも自動的に追従する。 - **Phase 2(適応的 drill-down、Algorithm 2)**: Phase 1 で疑わしいと判定された頂点・辺それぞれについて、既知の健全な頂点だけを付加してサイズ-k のプローブを構成し、その後の失敗が疑わしい頂点/辺を確定的に特定する(疑わしいグループ 1 つあたり最大 k(k-1)/2 + k 回のプローブ、複雑度 O(Cs・k²)。例: n=8, k=4 の疑わしいグループ1つを10回のプローブで辺(3,4)まで特定、図2d)。単純な疑わしいプローブ集合どうしの交差だけでは、無関係な2つの障害が誤って共通要素に帰属する恐れがあるため、この drill-down が必要になる。 - **設計上の限界**: FaultSense はハードウェアの根本原因(具体的なインターコネクトリンクや NVSwitch、PCIe 等)そのものを特定するのではなく、オペレータが GPU を退避したり通信経路を迂回させたりできる粒度で障害箇所を特定することを目標とする。KV キャッシュミスやルータの不均衡のような過渡的なソフトウェア障害は将来課題とし、数時間持続する永続的なグレイ障害に焦点を当てる。 ## 新規性 - **アプリケーション層かつ非侵入的な障害箇所特定**: 特権的なインフラテレメトリ(スイッチキュー、PCIe/NVLink エラー統計等)やサービングランタイムの変更を必要とせず、テナント権限の範囲内でエンドツーエンドレイテンシ信号のみから GPU/通信経路の障害箇所を特定する。既存のインフラ側診断(NCCL メトリクス等)は collective 通信レベルの集約値しか見えず、遅い GPU に起因する遅延を特定の GPU や通信経路に帰属できないのに対し、FaultSense はこの可視性ギャップを埋める。 - **MoE のスパースルーティングを診断プリミティブへ転用**: 密なモデルでは全 GPU が常に活性化されるため GPU 単位の選択性を持てないのに対し、MoE の top-k ルータが持つスパース性を逆手に取り、ルーティングを乗っ取って任意の GPU 部分集合だけを決定的に活性化するプローブモデルを構築した点が新しい。単一層構成は、ルータ・all-to-all・エキスパート計算という本番実行パターンを再現する最小単位でありながらメモリを無視できる水準に抑える。 - **GPU クラスタの障害箇所特定へのグループテスト理論の応用**: レプリカを完全グラフとして抽象化し、適応的グラフ制約付きグループテスト(adaptive graph-constrained group testing)の考え方をアプリケーション層の GPU/通信経路の障害箇所特定に適用した点、および貪欲被覆(Phase 1)と健全頂点によるパディング drill-down(Phase 2)を組み合わせた二段階アルゴリズムを新たに設計した点。 ## 実験設定 - **シミュレーション**: 80コア Intel Xeon サーバ上で完全グラフトポロジ(§4.2)をシミュレートし、実運用の MoE レプリカ規模を参考にレプリカサイズ n を25〜325 GPUで変化させ、プローブサイズ k∈{4,8}、同時障害数 d∈{1,2,4}(頂点・辺・両方に一様ランダムに発生)の組み合わせで、各フェーズで正確な故障特定に要するプローブ数を評価した。 - **GPU 実機テストベッド**: 4-GPU(各 GPU が別ホスト、1Gbps Ethernet 接続、RTX A5000 × 3 + RTX 4500 ADA × 1、各24GB VRAM)上で vLLM v0.21.0 と Ray v2.55.1 によるエキスパート並列(expert parallelism)構成を用い、プローブモデルのメモリフットプリントと、本番モデル(DeepSeek-MoE-16B-Chat)への5 RPSベースライン負荷に対するプローブトラフィック干渉(0〜10 RPSまで注入)を測定した。 - 検証した3つの問い: (1) FaultSense のプローブスケーラビリティは素朴なペアワイズテストとどう比較されるか、(2) プローブモデルのメモリオーバーヘッドはどの程度か、(3) プローブトラフィックは本番モデルのレイテンシに影響するか。 ## 実験結果 - **プローブスケーラビリティ**: 図3(レプリカサイズ対フェーズ別プローブ数)のうち、Phase 1 のプローブ数は理論的最小値にほぼ従い(図3a)、300-GPU レプリカで全数対テストより22倍以上少ないプローブ数で済む。Phase 2 のプローブオーバーヘッド(図3b, 図3c)はレプリカサイズではなく障害数に応じてスケールする(疑わしい構成要素だけを狙うため)。図4(レプリカサイズ対フェーズ1+2合計プローブ数)では図4bの通信経路障害を含め、合計では約20倍のプローブ削減となり、シミュレーションではすべての障害を正しく localize できた。ただし、大規模 GPU クラスタ実機での localization 精度の評価と、通信コストを正規化した比較は将来課題として残されている。 ![[fig03-probes-vs-replica-size.png]] ![[fig04-total-probes.png]] - **メモリオーバーヘッド**: プローブモデルの GPU あたりメモリ使用量は、単一 GPU で1820MBだったのに対し4-way のエキスパート並列でシャーディングすると834MBまで低下し、クラスタ規模が大きいほど GPU あたりの実測フットプリントは反比例的に減少した(図5a)。この傾向を本番規模のレプリカへ外挿すると、GPU あたりのフットプリントは無視できる水準になる。 - **プローブトラフィック干渉**: 図5(GPU 実機テストベッドでの評価)のうち、本番モデル(DeepSeek-MoE-16B-Chat)に5 RPSのベースライン負荷をかけた状態でプローブトラフィックを0から10 RPSまで注入しても、TTFT の劣化は最大約1%、TBT の増加はほぼ観測されず(図5b)、プローブがアクティブなユーザトラフィックを妨げずに並行実行できることを確認した([R3] を部分的に裏付ける)。 ![[fig05-testbed-eval.png]] ## 考察 - 本論文は、FaultSense の中核原理(スパースなアクティベーション選択性を利用した診断プロービングと、グラフ制約付きグループテストによる階層的な障害箇所特定)は MoE アーキテクチャに限らず、構造化された通信パターンを持つ密なモデルにも一般化できると述べているが、具体的な適用方法や評価は示していない。 - 著者らは、FaultSense がハードウェアの根本原因診断を置き換えるのではなく、インフラ側の診断ツールを補完し、アプリケーションチームが迅速にトラフィックを再ルーティングしてサービングを継続できるようにすることを目的とすると明示している(§6 Related work: インフラ側の障害診断・耐障害性のあるモデルサービングとの関係)。 - 実験は主にシミュレーション(スケーラビリティ)と小規模実機(4-GPU、メモリ・干渉)に限られており、大規模実クラスタでの localization 精度(偽陽性・偽陰性率)の定量評価、および通信コストを正規化した比較は明示的に将来課題とされている。 ## 強み / 弱点・課題 - **強み**: - ホスト計装や特権テレメトリを一切必要とせず、テナント権限の範囲内(アプリケーション層)だけで動作するため、マルチテナント・マネージド環境でも展開しやすい。 - MoE のスパースルーティングを転用した単層プローブモデルという設計は、メモリオーバーヘッドを無視できる水準に抑えながら本番同様の compute+communication 結合パターンを再現するという、フィデリティとコストのトレードオフを巧みに両立させている。 - グラフ抽象化と二段階グループテストの組み合わせにより、全数ペアワイズテストに対して約20倍という大幅なプローブ数削減を理論・シミュレーション双方で示している。 - **弱点・課題**: - 大規模 GPU クラスタ実機での localization 精度(偽陽性率・偽陰性率)の評価が未実施であり、著者ら自身も将来課題として明記している。 - GPU 単体の compute ストラグラーとエッジ(通信経路)障害の切り分けは可能だが、共有ボトルネック(複数エッジが同時に劣化する場合)はオペレータがトポロジ知識を用いて手動で交差を取る必要があり、自動化されていない。 - トランジェントなソフトウェア障害(KV キャッシュミス、ルータの不均衡)は明示的にスコープ外とされており、持続的なグレイ障害のみを対象とする。 - 密モデルへの一般化は原理レベルの主張に留まり、具体的な設計・実験による裏付けがない。