## Memo ![[Pasted image 20251105164024.png]] ![[Pasted image 20251105164039.png]] ![[Pasted image 20251105164031.png]] ![[Pasted image 20251106100747.png|600]] ## Memo with LLM ### 論文情報 - 論文タイトル: Mycroft: Tracing Dependencies in Collective Communication Towards Reliable LLM Training - 著者と所属: Yangtao Deng (The Chinese University of Hong Kong, ByteDance), Lei Zhang (ByteDance), Qinlong Wang (ByteDance Seed), Xiaoyun Zhi (ByteDance Seed), Xinlei Zhang (ByteDance), Zhuo Jiang (ByteDance), Haohan Xu (ByteDance), Lei Wang (ByteDance), Zuquan Song (ByteDance Seed), Gaohong Liu (ByteDance Seed), Yang Bai (ByteDance), Shuguang Wang (ByteDance Seed), Wencong Xiao (ByteDance Seed), Jianxi Ye (ByteDance), Minlan Yu (Harvard University), Hong Xu (The Chinese University of Hong Kong) - カンファレンス/ジャーナル名: ACM SIGOPS 31st Symposium on Operating Systems Principles (SOSP) - 発表年: 2025 ### 論文概要 本論文は、大規模言語モデル(LLM)の訓練における信頼性問題を解決するための分散トレーシングと根本原因分析システム「Mycroft」を提案している。Mycroft は、集合通信ライブラリにおける隠れた信頼性問題を露出させ、制御依存性とデータ依存性を活用して、リアルタイムでアノマリーを検出し根本原因を特定する軽量システムである。ByteDance での本番環境での6ヶ月以上の運用実績により、90% のケースで15秒以内にアノマリーを検出し、60% のケースで20秒以内に根本原因を特定する高い性能を実現している。 ### 詳細解説 #### 問題設定 大規模な分散学習環境では、GPUクラスタで頻繁に障害が発生する。Microsoft は45分ごとに1件の障害報告、Meta は LLaMA 3 事前学習時に54日間で419件の中断、ByteDance は本番クラスタで少なくとも1日に1件の障害を観測している。特に困難なのは、集合通信ライブラリ(CCL: Collective Communication Libraries)が「ブラックボックス」として機能し、内部状態の詳細な可視化ができないことである。これにより、[[2017__HotOS__Gray Failure - The Achilles Heel of Cloud Scale Systems|Gray Failure]]silent timeouts、訓練が見かけ上ハング状態になる障害）やフェイルスロー（性能低下を伴う障害）が発生した際に、根本原因の特定が困難になる。 論文で対象とする問題は以下の通り： - **入力**: LLM 訓練時の集合通信層で発生するアノマリー（グレイフェイラーと性能低下） - **出力**: 障害が発生した場所（どのGPU、NIC、またはコンポーネント）と障害の種類 - **必要なデータ**: 集合通信操作の細粒度な実行状態（フロー単位、チャンク単位） #### 提案手法 Mycroft は以下の主要成分で構成される： **1. 集合通信レベル(Coll-level) のトレーシング** - **フロー単位トレーシング**: ネットワークフロー（Query Pair など）の粒度で追跡。同一 Coll Op 内のフロー毎に異なる NIC と経路を使用するため、Op 単位トレーシングでは検出不可能な局所的な問題（トラフィックスパイク、輻輳）を検出可能にする。 - **チャンク単位トレーシング**: データ伝送の最小単位（チャンク）の進行状況を追跡。CUDA kernel の実行、RDMA による送信、完了通知（CQE）の3段階におけるシステム状態を集約して記録。通常のカーネルレベルトレーシングのようにすべてのイベントを記録するのではなく、短時間ウィンドウ（例：100ms）内に各コンポーネントで処理されたデータ量を集約して記録することで、オーバーヘッドを最小化。 **2. 軽量計測と高速トレーシング** NCCL に対し1100行の C++ コードで計測を組み込み、以下の2種類のログを収集： - **完了ログ**: Coll Op 完了時にタイムスタンプ、伝送バイト数、NIC 情報などのメタデータを記録 - **リアルタイム状態ログ**: Coll Op 進行中に定期的（例：100ms 毎）に、GPU 準備完了のチャンク数、RDMA 送信完了のチャンク数、RDMA 完了確認のチャンク数などを記録 固定サイズの環形バッファ（512MB/ホスト）を使用し、別プロセスが非同期的にデータを読み出して Kafka 経由でクラウドデータベースに送信。ロックフリーなシステムのため、オーバーヘッドは無視できるレベル。 **3. 依存性に基づく根本原因分析** アルゴリズム 2 で示される多段階の分析プロセス： - ノード間依存性を利用して、影響を受ける通信グループを特定 - 細粒度トレースの原則に基づき、ルールテーブルで違反を検出 - チャンク単位: 各ランクが同じ量のデータを送信すべき（障害検出）、各コンポーネントが期待時間内に完了すべき（性能検出） - フロー単位: 各フローが完了すべき（障害検出）、すべてのフローが類似の実行時間であるべき（性能検出） - 表 4 のルールテーブルを用いて、ローカルおよびリモートの根本原因を特定 例えば、GPU_ready = RDMA_transmitted > RDMA_done という状態は「受信者が準備できていない」を示唆し、これはリモート障害の兆候となる。 **4. リアルタイムトリガー機構** サンプリング（少なくとも1 DP グループあたり1ランク、最大10ランク）により、大規模クラスタでのデータ量と分析時間を削減。トリガー条件： - **グレイフェイラー検出**: サンプルランクが操作中にリアルタイム状態ログを生成しているが完了ログがない場合 - **ストラグラー検出**: スループットが50%以上低下、または操作間隔が2倍以上になった場合 #### 新規性 先行研究との比較： - **Op 単位トレーシング**（Kineto、GREYHOUND など）: Coll Op 全体の開始/終了時刻のみ記録。Op 内の詳細な依存性、フロー毎の状態が見えない。 - **カーネル単位トレーシング**（Nsight、NPKit、NVRx など）: CUDA 実行の完全なトレースにより詳細情報を得るが、オーバーヘッドが大きい（NPKit は帯域幅を2/3低下）。リアルタイム分析が困難で、分散的な根本原因分析が弱い。 - **RDMA 単位トレーシング**（Aegis）: RDMA のメトリクスのみで、GPU 側の問題や粒度が不十分。 本論文の新規性： 1. **Coll レベルの新しい粒度**: フロー単位とチャンク単位のトレーシングは、Op やカーネルレベルでは不可見な依存性を露出させる初の試み 2. **低オーバーヘッド**: 固定サイズバッファと非同期送信で、オーバーヘッドを最小化しつつ、充分な細粒度情報を得る工夫 3. **依存性駆動の分析**: inter-node dependencies と intra-node dependencies を統一的に扱い、根本原因を自動特定 4. **本番環境での実績**: 6ヶ月以上 ByteDance で運用され、数万 GPU 規模での有効性を実証 #### 実験設定 **テストベッド**: - ハードウェア: 32 個の NVIDIA A100-80GB-SXM4 GPU（4マシン8GPU/マシン）、NVLink/PCIe で機内接続、ConnectX-6 RNIC で機間接続 - ワークロード: GPT（Megatron-LM）、ハイブリッドパラレリズム（TP=8、PP=2、DP=2） - ソフトウェア: CUDA 12.2、PyTorch 2.1.0 **評価項目**: 1. **障害検出能力**: 7種類の障害注入実験（NIC シャットダウン、NIC 帯域制限、PCIe ダウングレード、GPU パワーリミット、バックグラウンド計算、バックグラウンドトラフィック、NCCL 遅延） 2. **本番環境性能**: 2024年10月以来の運用データ、最大数万 GPU 規模の訓練ジョブ 3. **オーバーヘッド比較**: 既存システムとの比較 #### 実験結果 **障害検出能力**: - 7つの注入障害すべてに対して根本原因を正確に特定。例えば： - NIC シャットダウン: 異常ランクが DP グループ内で他より早く停止し、かつフロー完了がないことから NIC 問題と判定 - GPU パワーリミット: 異常ランクの完了時刻が最も遅く、GPU_ready が進まないことから GPU 問題と判定 - バックグラウンドトラフィック: GPU_ready = RDMA_transmitted > RDMA_done であることから、受信側の遅延（ネットワーク問題）と判定 **本番環境性能**: - **検出時間**: 異常を15秒以内に検出（90% のケース） - **根本原因特定時間**: 20秒以内にルート原因 GPU を特定（60% のケース） - **検出精度**: 100% の成功率で Coll レベルの問題を検出（2024年11月〜12月の運用で13,221件の中断を検出） - **リソース使用**: 単一サーバで 64 CPU コア未満、メモリ 100GB 未満で運用可能 - **データ量**: 1万 GPU で1日あたり約 3TB のトレースデータ（1日分を保持） **比較結果**: - Nsight Systems: 単一サーバのみ対応、単一マシンでの可視化に限定 - NPKit: 帯域幅を2/3低下させる過大なオーバーヘッド - NVRx: 結果取得に60秒要する（Mycroft は秒単位） **事例**: 図 5 で示される例では、DP グループ内の GPU 1 が遅く、この遅延が PP グループの GPU 4 に波及。Mycroft は、GPU 1 が kernel copy を遅く実行し、全体通信をブロックしていることを特定し、ヒューマンインタベンションなしに GPU 1 を根本原因として特定可能。 ### 論文の限界と今後の方向 **限界**: 1. 可視性が集合通信層に限定され、アプリケーション層全体の可視化ができない 2. ヒューリスティック（例：ストラグラー判定の1秒閾値）に依存し、モデル依存の調整が必要 3. ハードウェア障害（例：CPU 障害）などの深い根本原因は別途ツールが必要 **拡張性**: - NCCL 以外の CCL（RCCL、MSCCL など）への適応は、メトリクスの再定義とトレースポイント、分析ルールの調整で対応可能 - GPU SM copy が不要な場合はメトリクスを簡略化 --- ## Abstract 信頼性はLLM訓練の効率性確保に不可欠である。しかし、現実世界の多くの信頼性問題は解決が困難なままであり、リソースの浪費とモデル性能の低下をもたらしている。残念ながら、現在の[[集合通信]]ライブラリはブラックボックスとして機能し、効果的な根本原因分析に必要な重大情報を隠蔽している。本論文では、集合通信における隠れた信頼性問題に対処するために設計された軽量の分散トレーシングおよび根本原因分析システム「Mycroft」を提案する。Mycroft の基本的な考え方は、集合通信状態をトレースし、内部制御依存性およびデータ依存性を活用してLLM訓練の信頼性問題を解決することである。Mycroft はByteDance に6ヶ月以上デプロイされており、集合通信関連の問題をランタイムでデバッグするために使用されている。90% のケースで15秒以内にアノマリーを検出し、60% のケースで20秒以内に根本原因を特定した。