> [!abstract] 概要(NSDI'24 abstract の日本語訳) > Large Language Model(LLM)は変革的タスクで印象的な性能を示してきた。しかし大規模クラスタ資源を LLM 開発のために効率的に活用するのは容易でなく、頻繁なハードウェア障害・込み入った並列化戦略・偏った資源利用率など多くの困難に直面する。本論文では、我々の GPU データセンター Acme で収集した 6 か月の LLM 開発ワークロードトレースに対する詳細な特徴づけ研究を提示する。具体的には、LLM と従来のタスク特化 Deep Learning(DL)ワークロードの差、資源利用パターン、各種ジョブ障害の影響を調べる。分析は、我々が遭遇した障害をまとめ、LLM 向けに最適化するシステム設計の機会を明らかにする。さらに、我々のシステムへの取り組みを紹介する: (1) fault-tolerant pretraining。LLM を巻き込んだ障害診断と自動復旧でフォールトトレランスを高める。(2) decoupled scheduling for evaluation。trial decomposition とスケジューリング最適化で性能フィードバックを迅速化する。 ## 論文情報 - タイトル: Characterization of Large Language Model Development in the Datacenter - 著者: Qinghao Hu(Shanghai AI Laboratory / S-Lab, NTU)・Zhisheng Ye(SHLAB / Peking U)・Zerui Wang(SHLAB / SJTU)・Guoteng Wang(SHLAB)・Meng Zhang・Qiaoling Chen(SHLAB / S-Lab, NTU)・Peng Sun(SHLAB / SenseTime Research)・Dahua Lin(SHLAB / CUHK)・Xiaolin Wang・Yingwei Luo(Peking U)・Yonggang Wen・Tianwei Zhang(NTU) - 媒体: 21st USENIX Symposium on Networked Systems Design and Implementation(NSDI '24), 2024-04-16〜18, Santa Clara, CA. ISBN 978-1-939133-39-7. ACM DL: 10.5555/3691825.3691864. pp. 709〜729(22 ページ + Appendix) - コード/データ: AcmeTrace(<https://github.com/InternLM/AcmeTrace>)、InternLM モデル(<https://huggingface.co/internlm>)、[[InternEvo]] フレームワーク(<https://github.com/InternLM/InternEvo>) ## 概要 [[Shanghai AI Laboratory]] の LLM 専用 GPU データセンター [[Acme]](Seren 2,288 + Kalos 2,416 = 4,704 A100、2023 年 3〜8 月)を、スケジューラログ・ハードウェア監視・ランタイムログ・プロファイリングの 4 系統で 6 か月分計測し、(a) LLM と従来 DL の差、(b) 資源利用率、(c) 障害の影響を定量化する。観測に基づき、[[InternEvo]] 上で 2 つのシステム——LLM ベース障害診断と自動復旧を持つ Fault-tolerant Pretraining、Trial Coordinator による Decoupled Scheduling for Evaluation——を実装し、それぞれ手動介入 ~90% 削減・チェックポイント 3.6〜58.7× 短縮、評価 makespan 1.3〜1.8× 短縮を達成する。 ## 問題設定 入力は LLM 専用 GPU クラスタの 6 か月分マルチモーダルトレース(ジョブログ・[[Prometheus]]/[[DCGM]]/IPMI のメトリクス・stdout/stderr ログ・1 ms 粒度の DCGM プロファイリング)。出力は LLM 開発ワークロードの特性化と、観測から導く 2 つの運用システム(障害復旧・評価スケジューリング)とその評価。前提として、対象は transformer decoder-only(7B〜123B)の事前学習・SFT・MLLM・評価・デバッグで、serving は別クラスタへ分離されているため対象外。 ## 提案手法 - **特性化方法**: 既存 DNN トレース研究([[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] の Philly・Helios・PAI)と同じ指標(ジョブ数・GPU 時間・実行時間・キュー遅延・GPU 利用率)で比較。さらに DCGM の PROF_SM_ACTIVE/PROF_PIPE_TENSOR_ACTIVE/DEV_FB_USED で SM/TC/メモリ・IPMI で電力を計測し、LLM 専用クラスタ特有の二極化・低 CPU/IB 利用・GPU が電力 65.7% を占める構造を定量化(図 8/9)。 - **Fault-tolerant Pretraining**(§6.1, 図 15)。3 モジュール構成: - **Asynchronous Checkpointing**: ホストメモリに非同期保存し、別スレッドで永続ストレージへフラッシュ。CPU メモリ余裕(§3.3)を活かして大規模モデルの保存遅延を分離。 - **Failure Diagnosis(LLM-assisted)**: (1) Real-time Log Compression — Filter Rules による正規表現フィルタを Log Agent(LLM)が動的に追記更新、self-consistency 投票で抽出規則の安定化、メタデータからの既存ルール流用で重複作業回避。(2) LLM-assisted Automated Diagnosis — 圧縮済みエラーログを ルール集合と照合、未一致なら埋め込みモデルでベクトル化して Vector Store に蓄積、Failure Agent(GPT-4)が Query Engine で検索し原因種別と user/infra の起因種別、緩和示唆を生成。診断結果から正規表現を逆生成して Rule-based Diagnosis へフィードバック(連続学習)。 - **Fast Fault Detection and Recovery**: NVLinkError 等のインフラ障害に対し 2 段階 NCCL allgather テスト(全ノードを 2 ノード一組のワールドに分割→失敗ペアを正常ノードと再ペアして犯人特定)。loss spike は直前の健全なチェックポイントへ巻き戻し、以後のバッチをバイパス。 - **Decoupled Scheduling for Evaluation**(§6.2, 図 16)。Trial Coordinator が以下を実施: - **Decoupling Remote Model Loading**: 評価データセット毎ではなくノード毎に precursor job でモデルをローカル共有メモリへ事前ロードし、評価本体は PCIe 経由でロード。リモートストレージ NIC 帯域(25 Gb/s)の競合を回避。 - **Decoupling Metric Computation**: GPU 推論完了直後に出力をファイルへダンプし、HumanEval / MBPP / GPT-4 API 等の重い検証は CPU ジョブへ分離。 - **Prior-based Elastic Scheduling**: データセット既知の実行時間に基づき各 GPU ワークロードを推定して round-robin 配分、CPU 検証時間の長い trial を先頭に置き、複数データセット間で柔軟に統合・分割。 ## 新規性 LLM 専用クラスタの最初期の本格的特性化として、Philly/Helios/PAI が示した DNN 訓練クラスタの観察(マルチテナント・ロングテール・低 GPU 利用)が LLM 開発では成立しないことを実データで示す。具体的には (1) GPU ジョブ中央値 2 分(DNN クラスタの 1/2.7〜1/12.8)、(2) 利用率の 0%/100% 二極化(Philly 48%・PAI 4% の中央値に対し 97%/99%)、(3) Pretraining が件数 0.9〜3.2% で GPU 時間 69.5〜94.0% を占める二重構造、(4) Evaluation が短ジョブにもかかわらず最長キュー遅延を持つ逆転現象。さらに、特性化に留まらず観測ベースで運用システム 2 件(Fault-tolerant Pretraining・Decoupled Scheduling)を InternEvo に統合・本番運用し、データセット([[AcmeTrace]])と実装を公開した点が新しい。 ## 実験設定 - **データセット**: Seren 368K CPU + 664K GPU jobs / Kalos 42K CPU + 20K GPU jobs(2023-03 〜 2023-08)。ハードウェア監視は 15 秒粒度、ピンポイントプロファイリングは DCGM 1 ms。Failure Analysis は Kalos 32,500 タスク(96.3% 推論・2.0% 事前学習・1.7% デバッグ)+ Seren 675 事前学習タスクのランタイムログ。 - **比較対象**: 過去 DNN トレース [[Philly]](Microsoft, 2017)・[[Helios]](SenseTime, 2020)・[[PAI]](Alibaba, 2020)。InternEvo V1 vs V2 を 123B モデル・2,048 GPU で SM 利用率比較(図 10)、評価 makespan を 7B・63 datasets で 1 node・4 node の 2 条件比較。 - **環境**: A100-SXM 80GB ×8/node, Intel Xeon Platinum 8358P ×2、NVLink/NVSwitch、Seren は 1×200Gbps IB、Kalos は 5×200Gbps IB(うち 1 つは storage 専用)。スケジューラは Seren=[[Slurm]]・Kalos=[[Kubernetes]]。全 NVMe 並列ファイルシステム。 ## 実験結果 - **ジョブ実行時間とキュー遅延**(図 2/6): Seren/Kalos 中央値 2 分(他クラスタの 1.7〜7.2× 短)。Evaluation は最短ジョブにもかかわらず最長キュー遅延、Pretraining 用に資源を予約しているため。 - **ワークロード分布**(図 4): Seren で件数 Eval 64.9%/Pretrain 0.9%、GPU 時間 Pretrain 69.5%/Eval 14.6%。Kalos で件数 Eval 92.9%/Pretrain 3.2%、GPU 時間 Pretrain 94.0%/Eval 0.8%。GPU 需要(図 5): Eval は <4 GPU が大勢、Pretrain は 100+ GPU。≥256 GPU の大規模ジョブが Kalos で GPU 時間の 96% 超を占める(図 3b)。 - **インフラ利用**(図 7/8/9): SM 中央値 ~40%(PAI の 2 倍)、Kalos で GPU メモリ ≥75%(60 GB)を半数が消費。CPU メモリ <50%・CPU・IB(60% 以上アイドル・最大帯域の 25% 未満)は余剰。GPU が 30% アイドルでも 60 W 消費、22.1%(Seren)/12.5%(Kalos)が 400 W(TDP)超で 600 W に達するものも。GPU は電力 65.7%・CPU 11.2%・PSU 9.6%。 - **プロファイリング**(123B / 2,048 GPU, 図 10〜12): InternEvo V1 の 3D parallelism は SM がアイドル区間を持つ一方、V2 の hierarchical ZeRO で SM 利用率が一段上がり ~16% 高速化。Pipeline rank 0〜3 で activation メモリが偏る(図 12)ため、partitioning の工夫が必要。 - **障害統計**(表 3): NVLinkError 54 件で GPU 時間 30.25%、CUDAError 21 件で 15.77%、NodeFailure 16 件で 14.30%、ECCError 12 件で 11.00%。これら Infrastructure 系合計で件数 ~11%・GPU 時間 82% 超。7B 訓練が Kalos で GPU 温度上昇を招き 2023 年 7 月(過去最高気温)に集中(§5.2)、室温は 5℃ 上昇。Evaluation の障害率は Kalos でわずか 6.7%、GPU/NVLink 障害はゼロ。 - **早期 vs 後期の Pretraining 回復**(図 14): 104B(3 月)は手動再起動と長い再ロード時間で進捗を大きく失う。123B(4 月)はチェックポイント間隔短縮 + graceful termination で安定するが、夜間も含む頻繁な再起動を要する。 - **デプロイ後の効果**: Async checkpointing で 7B・123B の checkpoint オーバーヘッドを 3.6〜58.7× 削減(interval=30 分、永続ストレージ書き込みは除外計測)。LLM ベース診断は手動介入を約 90% 削減(進化中の評価)。Trial Coordinator は 7B・63 datasets で 1 node・4 node の各条件で makespan を 1.3×・1.8× 短縮。 ## 考察 LLM クラスタを「DNN クラスタの延長」と見る既存スケジューラ設計は不適合で、GPU 共有・公平キュー・preemption(復旧コスト過大)はそのまま使えない。Pretraining のために大半の資源を確保せざるを得ず、それが Evaluation の長大キュー遅延と head-of-line blocking を生む構造的な逆転を生む。障害は件数より GPU 時間で評価すべきで、Infrastructure 障害は希少だが致命的、しかも一見クラッシュしない補助サービス(metric/log/alert)起因の Connection/Network 系も多発する。LLM ベース診断は規則と機械学習を橋渡しし、ログ多様性に強くなるが、現状 GPT-4 依存で自社 LLM へ移行予定。Evaluation の改善は GPU 占有時間そのものより「モデルロード分離 + CPU 検証分離 + 順序最適化」というスケジューラ設計で取れることが示された。 ## 強み / 弱点・課題 - **強み**: LLM 専用クラスタの 6 か月本番トレースを既存 DNN トレースと同一指標で並べた最初の研究で、AcmeTrace 公開により後続研究の参照点を提供。観測→システム実装→運用評価の連結が明示的で、Fault-tolerant Pretraining の 3 モジュール構成と Trial Coordinator は具体的な設計選択を示す。GPU 温度・電力・気象との相関(§5.2)は他研究で乏しい角度。 - **弱点・限界**(§7): (1) Serving は別クラスタゆえ対象外、(2) CPU ジョブの分析が薄い、(3) transformer decoder-only(GPT/LLaMA 系)中心で MoE は付録のみ、MLLM・diffusion・Mamba は対象外、(4) LLM-assisted Diagnosis の効果評価が「手動介入 ~90% 削減」と粗く、自社 LLM 置換後の頑健性は未検証、(5) 2-round NCCL test の偽陽性・偽陰性率の定量評価が薄い、(6) Trial Coordinator の評価が 7B 1 種・63 datasets に限定。