> [!abstract] 概要(arXiv abstract の日本語訳) > ChatGPT に代表される数千億〜数兆パラメータの大規模言語モデル(LLM)は、様々な分野に大きな影響を与えている。しかし、超大規模パラメータを持つ LLM の訓練には、高性能な大規模 GPU クラスタと数か月に及ぶ長期の訓練期間が必要である。大規模クラスタにおけるハードウェアおよびソフトウェアの障害は避けられないため、中断のない長時間訓練を維持することは極めて困難である。その結果、訓練時間の相当部分が、タスクのチェックポイント保存・読み込み、タスクの再スケジューリングと再起動、タスクの手動異常確認に費やされ、全体の訓練効率を大きく損なっている。これらの課題に対処するため、我々は新しい耐障害 LLM 訓練システムである TRANSOM を提案する。本研究では 3 つの主要サブシステムを設計する。すなわち、訓練パイプラインの自動フォールトトレランスと復旧機構である Transom Operator and Launcher(TOL)、訓練タスクの多次元メトリック自動異常検知システムである Transom Eagle Eye(TEE)、訓練チェックポイントの非同期アクセス自動フォールトトレランスと復旧技術である Transom Checkpoint Engine(TCE)である。TOL は訓練タスクのライフサイクルを管理し、TEE はタスクの監視と異常報告を担当する。TEE は訓練の異常を検知して TOL に報告し、TOL は自動的にフォールトトレランス戦略に入って異常ノードを排除し訓練タスクを再起動する。そして TCE が提供する非同期チェックポイント保存・読み込み機能により、フォールトトレランスのオーバーヘッドが大幅に短縮される。実験結果は、TRANSOM が大規模クラスタでの LLM 訓練効率を大幅に向上させることを示す。具体的には、GPT3-175B の事前訓練時間が 28% 短縮され、チェックポイントの保存・読み込み性能が 20 倍向上した。 ## 論文情報 - タイトル: TRANSOM: An Efficient Fault-Tolerant System for Training LLMs - 著者: Baodong Wu, Lei Xia(責任著者), Qingping Li(責任著者), Kangyu Li, Xu Chen, Yongqiang Guo, Tieyao Xiang, Yuheng Chen, Shigang Li - 所属: [[SenseTime Research|SenseTime]] / [[Huazhong University of Science and Technology]] / [[Beijing University of Posts and Telecommunications]] - 媒体・発表年: arXiv プレプリント、2023 年(v1: 2023-10-16、v3: 2023-10-18) - arXiv ID: 2310.10046v3 [cs.DC] - コード URL: 記載なし(本文・abstract に公開リポジトリへの言及なし) ## 概要 TRANSOM は、数百〜数千 GPU 規模で数週間〜数か月続く LLM 事前訓練において、頻発するハードウェア・ソフトウェア障害への対応(チェックポイント保存/読み込み、タスク再スケジューリング、手動異常確認)に訓練時間の大半が費やされる問題に対し、プロセスレベルの自動フォールトトレランス(TOL)、ハイブリッド異常検知(TEE)、非同期チェックポイントエンジン(TCE)の 3 サブシステムを組み合わせて解決する。GPT3-175B・512 A800 GPU での実運用実験で、事前訓練期間を 118 日から 85 日へ 28% 短縮したと報告する。 ## 問題設定 - **入力**: LLM 訓練ジョブ(ユーザ定義の訓練スクリプト)と、訓練中に継続的に生成されるログ・メトリクスデータ(GPU 使用率・ネットワークトラフィック等)。 - **出力**: 障害発生時に異常ノードを自動検知・隔離し、健全なノードで訓練を再開する自動化された訓練実行パイプライン。 - **前提条件**: Kubernetes 上での動作を前提とする。訓練フレームワークは Megatron-LM・DeepSpeed の組み合わせ、ネットワークは 200Gbps InfiniBand + 25Gbps Ethernet。 - **著者らが分類した SenseCore クラスタの障害統計(2023年5〜7月、Table I)**: Storage Read/Write Errors 34件、Network Communication Errors 43件、Node Hardware and Software Errors 66件、User Code and Training Environment Errors 179件、Others(原因不明のハングやexit code -9等)55件。ストレージサーバの同期異常によるタイムアウト、IB カード誤挿入・RoCE スイッチ誤設定、GPU ECC エラー・OOM・イメージプルタイムアウトなど、原因ごとに復旧戦略が異なる点を課題として挙げる。 ## 提案手法 - **アーキテクチャ**: 図1が示すように、従来型(左半分)はいずれかの worker が失敗すると全 worker を kill し、手動で確認・再投入する。TRANSOM(右半分)では各 Host に launcher が配置され、warmup → worker 実行 → checker のサイクルを回しつつ、Metrics/logs を AnomalyDetector(cleaning → training → detection)に流し込む。異常検知時は該当ホストのみを kill し、他ホストは訓練継続または新ノードの参加を待つ。 **Figure 1: TRANSOM のアーキテクチャ** ![[_attachments/arxiv-2310.10046/fig01-architecture.png]] (Fig. 1. 左が従来方式(いずれかの worker 障害で全 worker を kill し手動で確認・再投入)、右が TRANSOM(launcher が warmup/worker/checker のライフサイクルを管理し、AnomalyDetector が Metrics/logs から異常ノードを特定して当該ホストのみを再作成する)。Source: 本論文 Figure 1。) - **TOL(Transom Operator and Launcher)**: 訓練タスク管理ツール「transom-launcher」とフォールトトレラントなタスクオーケストレーションコントローラ「transom-operator」から成る。launcher はリーダー選出でマスター/ワーカー役割を分担し、マスターは Infrastructure Warm-up Task(ディスクチェック・GPU バーンイン・接続性チェック・NCCL テスト・異常ノード検知)→ User Training Task → Error Checking Task の順にタスクを配布する。異常検知時はマスターが異常ノードのプロセスを終了し transom-server へ報告、operator が異常ノードを避けるノードアンチアフィニティを設定して新しい launcher を作成する。異常ノードがなければローカル再起動、あれば異常ノードを除いた再構成で再起動する(§IV-A、図2)。 - **TEE(Transom Eagle Eye)**: オフライン訓練サブシステム(ログ・メトリクスの収集・前処理・モデル訓練)とオンライン検知サブシステム(訓練済みモデルのロードと定期実行)から成る(図3)。ログベース検知はスライディングウィンドウ内のエラーログ件数が閾値を超えたら異常と判定し、最初にエラーログを出したノードを異常ノード候補とする。メトリックベース検知は 3 種の手法を組み合わせる: (1) ランク間の統計的一貫性を捉える KNN(Dynamic Time Warping でクラスタリング)、(2) 個別ランクの周期性を捉える KNN Matrix Profile(単純な Matrix Profile より精度が高いとして採用)、(3) タイムスタンプごとの多次元メトリクスの外れ値検知に LOF(Local Outlier Factor、Isolation Forest より局所異常の検出に優れるとして選択)。3 モデルのうち 2 つ以上が異常と判定したタスクを最終的に異常と扱う(図4、Algorithm 1)。 **Figure 3: TEE のモジュール構成** ![[_attachments/arxiv-2310.10046/fig03-tee-modular.png]] (Fig. 3. オフライン訓練サブシステム(log/metric データソース → controller → storage → trainer → validation → update model)とオンライン検知サブシステム(user → query service/detecting service → TSDB)から成る。Source: 本論文 Figure 3。) - **TCE(Transom Checkpoint Engine)**: チェックポイントの保存・読み込みリクエストを transom-server に転送し、インメモリキャッシュへ即座に書き込んでから非同期に永続ストレージへフラッシュする(図5)。フォールトトレランスのため、各ノードの TCE サーバは次のノードランクへ RDMA 経由で非同期・耐久的にキャッシュをバックアップする(2. backup)。メモリ利用の柔軟性のため、メモリ使用量上限指定と最大キャッシュサイクル数指定という 2 種のキャッシュ削除戦略を用意する。IPC には従来の共有メモリではなく Linux の memfd 機構を採用し(コンテナ内共有メモリ容量の制約回避、ユーザソフトウェアスタックとの競合回避、hugepage 利用の簡便化)、最終状態一貫性のため Kubernetes の宣言的管理原則に着想を得た C++ 版 Kubernetes operator 相当のロジックを実装する。 **Figure 5: TCE のモジュール構成とワークフロー** ![[_attachments/arxiv-2310.10046/fig05-tce-workflow.png]] (Fig. 5. Host 1/Host 2 それぞれで training process → server → host memory(2. save)→ SQL DB(4. save metadata)→ storage SDK → storage(persistent)の非同期永続化経路と、server 間の RDMA バックアップ(2. backup)を示す。Source: 本論文 Figure 5。) - **理論的性能解析**: 175B パラメータ・Adam・ZeRO・FP16 訓練を例に、チェックポイント保存量の理論式 `max(Ssave) = (DP + 6)P / 4N`(式1)、性能向上比 `Gsave = Bmem / Bnas`(式2、Bmem はメモリ書込帯域、Bnas はネットワークアタッチトストレージ書込帯域)、読み込みレイテンシ `Tload`(式3、DP ≤ 8 と DP > 8 で場合分けし RDMA 帯域 Brdma を利用)を導出する。イーサネット帯域(典型10Gbps)対 DDR4 メモリ帯域(約20GBps)の差、および TCE がノード数増加に対してもランクあたりのデータ読み書き量が減るためスケールするほど有利になる点を根拠とする。 ## 新規性 - **ModelArts との比較**: 著者らは、ModelArts のフォールトトレランスはジョブレベルで動作するのに対し、TRANSOM はプロセスレベルで動作するためより効率的だと主張する。また ModelArts の異常検知は IO と GPU 使用率のみでスタック異常を検知し、検知結果がフォールトトレランス機能と統合されていないのに対し、TRANSOM はメトリクスとログを併用して問題ノードを特定し、検知結果を直接フォールトトレランスツールに連携させる(§II)。 - **既存フレームワークとの比較(Table II)**: DeepSpeed(フォールトトレランス×・異常検知×・チェックポイント最適化○)、PyTorch Elastic(○・×・×)、Horovod Elastic(○・×・○)、Singularity(○・×・○)、DeepFreeze(×・×・○)、Alibaba PAI(○・×・×)、ModelArts(○・○・×)、Azure(×・×・○)に対し、TRANSOM は 3 項目すべて○として位置づけられる。 - **他手法との非侵襲性**: MaTEx-Caffe・PyTorch Elastic・Pollux 等の既存耐障害/弾性訓練研究の多くはディープラーニングフレームワークに侵入的な変更を要するのに対し、TRANSOM は異常検知とエラーチェックの両機能を持ちながらフレームワークに対して非侵襲的な立場を保つ(§II)。 ## 実験設定 - **実行環境**: SenseCore AI クラウド。各計算ノードは 112 コア CPU・1024GB DRAM・NVIDIA A800-80GB × 8、200Gbps InfiniBand + 25Gbps Ethernet で接続。PyTorch 2.0、CUDA 11.8。 - **モデル・データセット**: NVIDIA Megatron-LM + Microsoft DeepSpeed の組み合わせで GPT3-7B・GPT3-175B を事前訓練。データセットは約 1,560 億トークンの C4 データセット。 - **比較対象**: Kubeflow(Google 製 OSS の ML/MLOps プラットフォーム)、torch.save/torch.load(PyTorch 標準のチェックポイント手法)、LOF(密度ベース異常検知の代表手法)、Nebula(Microsoft Azure Container for PyTorch のチェックポイントツール、SOTA として比較)。 - **評価指標**: エンドツーエンド訓練時間(タスク投入から 300B トークンデータセットでの訓練完了までの経過時間)、タスク再起動平均時間、チェックポイント保存・読み込みレイテンシ、異常検知の正解率・エラータイプカバレッジ。 ## 実験結果 - **エンドツーエンド性能(図6)**: 512 台の A800-80GB GPU で GPT3-175B を訓練し、TRANSOM なしでは 118 日、TRANSOM ありでは 85 日で完了(28% 改善)。TRANSOM なしの場合、週末・休日を中心に復旧に 48〜72 時間かかるケースがあったと報告する。 - **TEE の検知能力(図7)**: SenseCore の実運用タスク 1 か月分(正常データ13件、異常データ11件)を用いた評価で、LOF と NProfile(KNN Matrix Profile)を組み合わせた検知は 11 件の異常タスクすべてを検知した。ただし TEE は GPU 使用率・ネットワークトラフィックの高いタスクにのみ適用可能であり、それ以外の特性を持たないタスク(例: sleep タスク)は誤って異常と判定されうる限界を認める。 - **TCE の性能(図8・図9)**: GPT2-7B・GPT3-175B のチェックポイント保存・読み込み性能を PyTorch 標準手法と比較した結果、GPT3-7B(1×8 GPU)では保存性能が約10倍、読み込み性能が7.5倍向上。GPT3-175B(16×8 GPU)では読み込み性能が20倍、保存性能が16倍向上した。図8 の実測値では、175B の保存が 255秒→16秒、読み込みが171秒→7.8秒、7Bの保存が84.2秒→8.7秒、読み込みが197秒→26秒。実運用では128ランク・DP=8の175Bモデルの一般チェックポイント保存が、SenseCoreファイルストレージで約4.5分(平均書込帯域約71.1MB/s/rank)かかっていたところ、TCEでは同規模の操作を10秒で完了し27倍の性能向上を達成したと報告する(§VI-A)。GPT2/GPT2-large/GPT2-xl での Nebula 比較(図9)では、TRANSOM は 1.3〜3.4 倍の保存性能向上を示し、モデルサイズが大きいほど改善幅が拡大する傾向を確認した。 - **本文結論部での要約数値**: 実験(実クラスタとシミュレーション両方)を通じて、GPT3-175B の実行時間を 33 日短縮し、一般的な LLM 訓練異常の認識率は 100% 超(コメント: 原文 "over 100%" は "100%超"であり、複数モデルの多数決による過検知を含む可能性がある。§VII)、チェックポイント平均読み書きオーバーヘッドを 255秒から16秒へ削減したとまとめている。 **Figure 6: TRANSOM 有無での GPT3-175B 訓練の loss 推移** ![[_attachments/arxiv-2310.10046/fig06-end-to-end-perf.png]] (Fig. 6. 横軸は175B GPT3訓練タスクの経過時間(単位:10分)、縦軸はloss。TRANSOM なし(赤破線)は118日、TRANSOM あり(青実線)は85日で訓練完了に到達する。Source: 本論文 Figure 6。) **Figure 8: GPT3 チェックポイント性能(PyTorch 標準 vs TRANSOM)** ![[_attachments/arxiv-2310.10046/fig08-checkpoint-perf.png]] (Fig. 8. 7B(1×8 GPU)・175B(16×8 GPU)それぞれの保存・読み込み時間(秒)。175B保存は255秒→16秒、175B読み込みは171秒→7.8秒。Source: 本論文 Figure 8。) ## 考察 - TEE のログベース検知は「最初にエラーログを出したノードが実際の異常ノードであることが多い」という経験則に依拠しており、根本原因の深い診断ではなく異常ノードの迅速な特定に軸足を置く。これは同時期以降の[[耐障害LLM訓練]]研究群([[ByteRobust]]の「正確な箇所特定より迅速な隔離」)と同じ設計思想を先取りしている。 - TCE の RDMA バックアップは「近接ノードの同時障害はまれである」という仮定に立脚しており、著者ら自身「実際にはほぼすべてのインフラ障害は単一ノード規模の事象であり、複数ノードにまたがる損傷はラック・ルーム・データセンターレベルでのみ発生する比較的まれな事象」と述べる(§IV-C)。この仮定が崩れる大規模同時障害への耐性は評価されていない。 - 異常検知の評価データセットは正常13件・異常11件と小規模であり、統計的な信頼区間や誤検知率(precision/recall)の定量評価は示されていない。「異常検知率70%」という数値は本文の結論部と結果部で言及が一致しない箇所があり(結果部は「11件全て検知」、結論部は「70%」および「100%超のカバレッジ」)、記述の精度にばらつきがある。 ## 強み / 弱点・課題 - **強み**: - TOL・TEE・TCE の三本柱で「検知」「隔離・復旧」「チェックポイント高速化」を一つのシステムに統合し、ジョブレベルでなくプロセスレベルで異常ノードのみを排除する設計により、健全なノードの計算資源を無駄にしない。 - RDMA を活用したインメモリチェックポイントバックアップにより、ディスク I/O とネットワークストレージのボトルネックを回避し、20〜27倍のチェックポイント性能向上を実測ベースで示した。 - Golang 静的コンパイルによる OS 互換性、DeepSpeed へのモンキーパッチによるユーザ側変更不要な統合など、実運用を意識した実装上の工夫が具体的に記述されている。 - **弱点・課題(著者らが明言する限界と読み取れる懸念)**: - TEE は GPU 使用率・ネットワークトラフィックが高い訓練タスクにのみ適用可能で、それ以外の特性のタスクは誤検知しうると著者ら自身が認めている(§VI-C)。 - 「TEE がエラーの根本原因を診断する能力は現状限定的であり、異常なノード/ランクをユーザに示すことしかできず、詳細情報を提供できない」と明記されている(§IV-B)。 - 評価データセットが小規模(正常13件・異常11件)であり、大規模・多様な障害パターンへの一般化可能性は未検証。 - RDMA バックアップは近接ノード同時障害を想定しておらず、ラック/ルーム/データセンター規模の同時障害への耐性は議論のみで実証がない。