## Memo - Shanghai AI LabのデータセンターAcme（Serenクラスタ: 2,288 A100 GPU、Kalosクラスタ: 2,416 A100 GPU） - 6ヶ月間（2023年3〜8月）の168K GPUジョブトレースを分析 - 事前学習ジョブはわずか3.2%だがGPUリソースの94.0%を消費、評価ジョブは92.9%のジョブ数で0.8%しかリソースを使わない - 提案：（1）非同期チェックポイント＋LLM診断による故障耐性事前学習、（2）モデルロードと評価指標計算を切り離す分離スケジューリング ## Memo with LLM ### 論文情報 - **タイトル**: Characterization of Large Language Model Development in the Datacenter - **著者・所属**: Qinghao Hu, Zhisheng Ye, Zerui Wang, Guoteng Wang, Meng Zhang, Qiaoling Chen, Peng Sun, Dahua Lin, Xiaolin Wang, Yingwei Luo, Yonggang Wen, Tianwei Zhang（Shanghai AI Laboratory, S-Lab/Nanyang Technological University, Peking University, Shanghai Jiao Tong University, SenseTime Research, CUHK） - **カンファレンス**: 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI '24), Santa Clara, CA, pp. 709–729 - **発表年**: 2024 ### 論文概要 GPUデータセンターAcmeから収集した6ヶ月間のLLM開発ワークロードトレース（168KのGPUジョブ）を詳細に分析し、従来のDLワークロードとの相違点、リソース利用パターン、ジョブ障害の影響を明らかにする。これらの知見に基づき、LLM向けに最適化した2つのシステム改善（故障耐性事前学習と評価向け分離スケジューリング）を提案・実装し、それぞれチェックポイント速度3.6〜58.7倍向上と評価makespanの1.3〜1.8倍短縮を達成している。 ### 詳細解説 #### 問題設定 **入力・前提**: - 大規模GPUクラスタ上でのLLM事前学習・評価・ファインチューニングを含む開発ワークロード全体 - 複数の並列化戦略（3D parallelism、ZeRO）を組み合わせた数百億〜千億パラメータ規模のモデル **課題**: - ハードウェア障害（NVLink断、CUDA/ECCエラー等）が頻発し、再開に2.8〜592分かかる - 事前学習ジョブ（3.2%）がGPUリソースの94%を占有し、評価ジョブが長時間キューイング - チェックポイント書き込みが学習を数十分ブロックする（従来の同期方式） - 評価ジョブではモデルロード・指標計算にGPU時間の約50%が無駄になる #### 提案手法 ##### アーキテクチャ **故障耐性事前学習（Fault-Tolerant Pretraining）**の3コンポーネント： 1. **非同期チェックポイント（Asynchronous Checkpointing）** - バックグラウンドスレッドでチェックポイントを永続化し、学習をブロックしない - 余剰のホストメモリ（CPUメモリ：使用率<50%）を一時バッファとして活用 - 複数チェックポイントをメモリに保持してからリモートストレージへ非同期書き込み 2. **LLMによる障害診断（LLM-Assisted Failure Diagnosis）** - **ログ圧縮**：動的フィルタルールで初期化ログ・メトリクス・デバッグ情報を除去し数百MBを圧縮 - **障害検出**：圧縮エラーログをヒストリカルルールと照合。未マッチはembeddingモデルでベクトル化→GPT-4で診断・対処法を生成 - ルールベースと学習モデルの2段階。新規障害は新たなregexパターンとして追加（継続学習） - インフラ障害（回復可能）とスクリプトエラー（非回復）を自動分類 3. **高速障害検出・回復（Fast Fault Detection and Recovery）** - NCCLの2ラウンドテスト（allgather）で障害ノードをペアリング特定 - loss spikeは正常なチェックポイントに戻り、問題バッチをスキップして再開 - **~90%のマニュアル介入を削減** **評価向け分離スケジューリング（Decoupled Scheduling for Evaluation）**の3手法： 1. **リモートモデルロードの分離** - 課題：60以上の評価データセットが同時にロードするとNIC（25Gb/s）が輻輳し、ロード速度が~1000 MB/s→~200 MB/sに低下 - 解決：Precursorジョブがモデルをリモートから共有メモリに先読み。評価ジョブはPCIe経由でアクセスし、ストレージ輻輳ゼロ 2. **指標計算の分離** - 課題：コード正確性テストやGPT-4 API呼び出しでGPUが最大30分アイドル化 - 解決：GPU推論完了後に出力をファイル保存して評価ジョブを終了、CPU専用ジョブが非同期に指標計算 3. **事前情報に基づく弾力的スケジューリング** - ベンチマークごとの実行時間の履歴を活用 - 複数データセットを1トライアルにまとめてモデルロードオーバーヘッドを削減 - 大規模データセットを分割してGPU負荷を均衡化 - 長いCPU指標計算を先行して投入しGPUとCPUをオーバーラップ #### 新規性 **既存研究の課題**: - 従来のDCトレース研究（Philly 2017等）はタスク固有DLを前提とし、中央値12分超のジョブ時間、GPU使用率4〜48%という特性を報告 - LLM開発ではこれらの前提がすべて崩れており、既存のスケジューラ・チェックポイント戦略・障害対策はLLMに不適切 **本研究の貢献**: - LLM開発ワークロードの最初の大規模・長期トレース公開（AcmeTrace） - ジョブの二極化（事前学習：超長時間・大規模 vs 評価：超短時間・小規模）の定量的実証 - 従来手法が機能しない理由の原因分析と、LLM固有の最適化機会の特定 #### 実験設定 **実験環境**: - Serenクラスタ：286ノード × 8 A100-SXM 80GB = 2,288 GPU、CPUメモリ128GB/node、200Gb/s IB × 1 - Kalosクラスタ：302ノード × 8 A100-SXM 80GB = 2,416 GPU、CPUメモリ2TB/node、200Gb/s IB × 5 - 分散ストレージ：all-NVMe並列ファイルシステム - ソフトウェア：InternEvo（FlashAttention・3D parallelism・ZeRO統合フレームワーク） **データセット**: - 期間：2023年3〜8月（6ヶ月） - Serenジョブ数：CPUジョブ368K + GPUジョブ664K - Kalosジョブ数：CPUジョブ42K + GPUジョブ20K - 総計：1.09Mジョブ - メトリクス収集：Prometheus（CPU/メモリ/ネットワーク、15秒間隔）、NVIDIA DCGM（GPU、1ms〜15秒間隔）、IPMI（電力） **比較対象**: - Philly 2017（Microsoft、タスク固有DLトレース）、HELIOS 2021（GPU DCトレース）と定量比較 - 事前学習手法：InternEvo V1（3D parallelism）vs InternEvo V2（hierarchical ZeRO） **評価指標**: - ジョブ時間、GPU利用率（SM activity）、GPUメモリ、ネットワーク帯域、CPU/メモリ使用率 - チェックポイント所要時間（秒） - 評価makespan（秒） - マニュアル介入回数 #### 実験結果 **定量的評価**: | 指標 | Acme（本研究） | 先行研究（Philly等） | |---|---|---| | 中央値ジョブ時間 | 2分 | 12.8倍長い | | GPU SM使用率中央値 | 97〜99% | 4〜48% | | GPUメモリ使用率 | 75%（60GB） | 10% | | ホストメモリ使用率 | <50% | - | | ネットワーク使用率 | アイドル60%以上、最大25%未満 | - | **ワークロード分布**（Kalosクラスタ）: - 事前学習：ジョブ数3.2% → GPU時間94.0% - 評価：ジョブ数92.9% → GPU時間0.8% **障害分析**（31,293推論タスク + 647事前学習タスク）: - インフラ障害：GPU時間82%喪失、再起動時間2.8〜592分 - NVLinkエラー：54件、585,683 GPU分喪失（最大） - CUDAエラー：21件 - ノード障害：16件 - ECCエラー：12件 - フレームワークエラー：GPU時間16%喪失 - スクリプトエラー：件数最多だがGPU時間<2% **提案システム性能**: - 非同期チェックポイント：7Bモデルで3.6倍、123Bモデルで58.7倍の高速化 - 評価makespan：シングルノード1.3倍、4ノード環境で1.8倍短縮（63データセット評価） - マニュアル介入：~90%削減 **アブレーションスタディ（評価スケジューリング）**: - モデルロード分離のみ：1.2倍短縮 - 指標計算分離のみ：GPU アイドル時間を~19%→ほぼ0に削減 - 弾力的スケジューリングのみ：バランス改善 - 3手法組み合わせで最大1.8倍 #### 考察 **結果の解釈**: - GPU使用率の二極化（0%か100%）はTransformerアーキテクチャの均質性を反映。タスク固有DLと異なりGPU共有技術が不適切である理由 - ホストメモリとネットワーク帯域の著しい低利用は、LLM向け最適化の余地として非同期チェックポイントや先読みに活用できる - NVLinkエラーがGPU時間損失の最大要因（30.25%）であり、次世代GPUのNVLink信頼性向上が急務 **優位性の根拠**: - 非同期チェックポイントが大きな効果を発揮するのは、123Bモデルではチェックポイントサイズが巨大（数百GB）でストレージ書き込みが学習律速となるため - 評価分離スケジューリングの効果が大きいのは、63データセット評価では共有ボトルネック（NIC輻輳、CPU指標計算）が繰り返し発生するから **限界と例外**: - AcmeはShanghai AI Lab固有の環境。GPU・ノード構成やソフトウェアスタックが異なるDCでは特性が異なる可能性 - 2023年7月の猛暑によるGPU過熱障害は環境固有の事象 - GPT-4を障害診断に使用するため、診断品質がAPIの可用性とコストに依存 #### 強み - 6ヶ月・1.09Mジョブという大規模・長期のリアルトレースを公開（AcmeTrace） - LLMワークロードの定量的特性評価と先行研究との比較が明確 - 実際の本番システムで検証された2つの実用的な解決策を提示 - チェックポイント・障害診断・評価スケジューリングの各最適化が補完的で、LLM開発全体をカバー #### 弱点・課題 - 単一組織・単一フレームワーク（InternEvo）のトレースのため一般化に制限あり - GPT-4 APIを障害診断に使用することで、外部サービス依存・コスト・プライバシーの課題が生じる - 評価スケジューリングのベースラインが単純な先着順（FCFS）のみで、より高度な既存スケジューラとの比較がない - NVLinkなどインフラ障害の抜本的な予防策ではなく、発生後の回復に焦点を当てている ## Abstract 大規模言語モデル（LLM）は、様々な変換タスクにおいて目覚ましい性能を発揮している。しかし、LLMを開発するために大規模なクラスタリソースを効率的に活用することは容易ではなく、頻繁なハードウェア障害、複雑な並列化戦略、リソースの不均衡な利用など、多くの課題に悩まされている。本論文では、我々のGPUデータセンターAcmeから収集した6ヶ月間のLLM開発ワークロードトレースについて詳細な特性評価研究を示す。具体的には、LLMと以前のタスク固有の深層学習（DL）ワークロードとの間の相違点を調査し、リソース利用パターンを探り、様々なジョブ障害の影響を特定する。我々の分析は、直面した障壁を要約し、LLM向けにカスタマイズされたシステムを最適化する潜在的な機会を明らかにする。さらに、我々のシステムの取り組みを紹介する：（1）故障耐性事前学習：LLMが関与する障害診断と自動回復により故障耐性を強化する；（2）評価のための分離スケジューリング：試行分解とスケジューリング最適化によりタイムリーな性能フィードバックを実現する。