> [!abstract] 概要(arXiv abstract の日本語訳) > 今日の大規模言語モデル(LLM)訓練は、数千 GPU に及ぶクラスタ上で実行される。この規模はモデルの急速な進歩を可能にする一方、訓練フレームワークの開発・デバッグ・性能チューニングは必然的に複雑かつ高コストになる。これは、エンジニアが障害を診断したり最適化を評価したりするために本番挙動を再現する必要がしばしばあり、そのために本番規模のクラスタへの頻繁な、場合によっては排他的なアクセスが求められるためである——そして GPU の大半が既に本番ワークロードに割り当てられている現状では、これはますます困難になっている。シミュレーションは維持が難しい複雑な性能モデルに依存し、縮小規模の実験はスケール依存の挙動を捉え損ねることが多い。 > 我々は、大規模実行を大規模クラスタへのアクセスの必要性から切り離す PrismLLM を提案する。これにより、エンジニアはわずか数個の GPU を用いて、関心のあるランクを忠実な大規模挙動のもとで実行・観測できる。PrismLLM は、対象規模の計算・通信・依存関係を捉えるスライシングベースの手法により高忠実度の実行グラフを構築する。そして PrismLLM は、選択したランクが元のプログラムを実行し、残りのランクが仮想参加者としてリプレイされるハイブリッドエミュレーションを実行する。 > 大規模 LLM 訓練ワークロードでの実験により、PrismLLM は性能とメモリ挙動を正確に再現し、反復時間の平均誤差 0.58%、ピーク GPU メモリ使用量の誤差 0.01% 未満を達成することが示された。PrismLLM は、元のデプロイに必要な物理 GPU の 1% 未満を用いて、最大 8192 GPU のクラスタをエミュレートできる。 ## 論文情報 - タイトル: A Few GPUs, A Whole Lotta Scale: Faithful LLM Training Emulation with PrismLLM - 著者: Shaoke Xi(Alibaba Group, equal contribution)・ChonLam Lao(Alibaba Group / Harvard University, equal contribution)・Boyi Jia(Alibaba Group / Shanghai Jiao Tong University, equal contribution)・Jiaqi Gao(Alibaba Group, equal contribution)・Zhipeng Zhang(Alibaba Group)・Jiamin Cao(Alibaba Group)・Brian Sutioso(Harvard University)・Erci Xu(Shanghai Jiao Tong University)・Minlan Yu(Harvard University)・Kui Ren(Zhejiang University)・Yong Li(Alibaba Group)・Zhengping Qian(Alibaba Group)・Ennan Zhai(Alibaba Group)・Jingren Zhou(Alibaba Group) - 媒体: arXiv プレプリント(cs.DC) - 発表年: 2026 年(投稿日 2026-05-15、arXiv ID から推定) - arXiv ID: 2605.15617 - コード: 論文はオープンソース化を宣言(具体的なリポジトリ URL は本文に記載なし) ## 概要 PrismLLM は、数千 GPU 規模の本番 LLM 訓練の実行挙動(反復時間・ピークメモリ・スケジューリング挙動)を、わずか数個の物理 GPU で忠実に再現するエミュレーションシステムである。既存のシミュレーション手法(SimAI・Phantora 等)がモデルの忠実度維持のために継続的な再実装コストを要し、縮小規模実験(downscaling)が並列化戦略や通信構造そのものを変えてしまう問題に対し、PrismLLM は「関心のあるランクだけを物理 GPU 上で実行し、残りは論理的に維持する」という選択的実行のアイデアで応える。 ## 問題設定 - **入力**: 任意の大規模 LLM 訓練ジョブ(例: 256 GPU、PP=4/TP=4/DP=16 のような並列化構成)を、変更なしのコードのまま与える。 - **出力**: 対象規模で走らせた場合の反復時間・GPU メモリ使用量・カーネルレベルのタイミングなど、性能・実行挙動の高忠実度な推定値。 - **前提条件**: 訓練プログラムが対象 GPU プラットフォーム上で実行可能であること(未発売ハードウェアへのフォワードプランニングは不可)。GPU ワークロードが反復間で周期的であること(distillation のように教師モデル数が反復ごとに変わるワークロードは代表的な 1 ワークロードのみエミュレート可能)。 - **必要なデータ**: 対象規模の訓練ジョブそのもの(グラフ収集フェーズで少数 GPU 上に多重化して実行するため、大規模クラスタへの継続アクセスは不要)。 ## 提案手法 - **アーキテクチャ**: 2 フェーズ構成。(1) グラフ準備サブシステム(§5)が全ランクの高忠実度実行グラフ(PrismTrace)を構築し、(2) ハイブリッドエミュレーションサブシステム(§6)がそのグラフを使って関心のあるランクをサンドボックス GPU 上で実行しつつ、残りをアシスタント GPU 上で仮想ランクとしてリプレイする。最小構成では 2 台の GPU マシン(サンドボックス用・アシスタント用)で動作し、アシスタント GPU 数はサンドボックス GPU 数と 1:1 にしてネットワーク帯域を確保する。 - **PrismTrace 実行グラフ(§5.1)**: ノード(計算スパンまたは通信イベント、id と duration を持つ)とエッジ(依存関係: directional/synchronization の 2 種)からなるグラフ。PyTorch Profiler(Chakra・Meta HTA 併用)は 128GPU Qwen3 訓練で最大 20.04% の反復時間増を引き起こすオーバーヘッドがあるため採用せず、リプレイに必要な通信タイミングと大規模依存関係のみを粗粒度(マイクロバッチ単位)で記録する。GPU 側の通信タイミングのみを記録し、CPU 側イベントは無視する(実際の通信タイミングは GPU 実行が決めるため)。 - **Stage 1: コンテキストスイッチによるグラフ収集(§5.2)**: 中央集権的なコーディネータが、限られた数 𝑁 の GPU 上に多数の論理ランクを多重化する。あるランクが通信点(collective 等)でブロックすると、その実行状態・通信コンテキストを CPU メモリへ退避し GPU を解放、コーディネータは collective を解除できる別のランク群を優先的にスケジューリングする(§Appendix A)。全参加者が揃うと collective を CPU 上で実行し出力を生成、ブロックされたランクを再開する。これを全ランクが 1 反復を完了するまで繰り返し、タイミングを伴わない「bare graph」(何が・どの順で実行されるか)を得る。1024 ランク・4 GPU の例では 256 ラウンドを要するが、DP グループ間でグラフが同一になる性質を利用して 1/𝑁(𝑁 = DP サイズ)に削減できる。 - **Stage 2: タイミング充填とスライス間キャリブレーション(§5.3)**: 訓練ジョブをスライスに分割し、各スライスで一部のランクを実 GPU 上で実行(アシスタント GPU が残りを仮想リプレイ)することで局所的に正確なタイミングを得る(スライスごとのタイミング充填)。スライスをラウンドロビン(例: 0–7, 8–15, …)で実行し、全ランクが最低 1 回は「実ランク」として走る。次に、実行グラフの依存関係情報(例: スライス 1 の受信はスライス 0 の送信に依存する)を使ってスライス間のタイムスタンプを整合させる(スライス間キャリブレーション)ことで、大域的に整合した高忠実度グラフを再構成する。 - **ハイブリッドエミュレーション(§6.1)**: サンドボックス GPU が実プログラムを実行し、アシスタント GPU が多数の仮想ランクをリプレイする。仮想ランクは実計算を行わず、事前収集した実行グラフのタイミングと依存関係を辿って計算ノードでは記録時間だけ待機し、通信ノードでは実際にサンドボックスと通信する。ランタイムプリフェッチパイプラインが今後の collective 用テンソルをアイドル通信期間に先読みし、GPU バッファプールが不足すれば CPU バッファプールへ段階的に退避する。512-GPU ジョブでアシスタント GPU 1 台あたり 100GB 超のバッファ空間を確保できる。 - **仮想ランク初期化の最適化(§6.2)**: 数千の仮想ランクを素朴にホストすると、通信グループ(DP/TP/PP 等)ごとの通信子・バッファ(グループあたり約 500MB)が GPU メモリを枯渇させ、初期化が部分的に直列化して数時間かかる。PrismLLM は NCCL グループ削減により、サンドボックスと重なるグループのみを仮想ランクとしてインスタンス化する(2,000 仮想ランクのエミュレーションでアクティブ NCCL グループ数を 8,617 から 82 へ削減)。さらに、リング/ツリーの collective アルゴリズムにおいて直接通信するのは近傍ランクのみである性質を利用し、非近傍の仮想ランクをプルーニングする。TCPStore ベースのバリアでは、アシスタントランクのリーダーが非近傍参加者の代わりにリクエストを発行することで、world size を変えずに初期化バリアを完了させる。 - **ランタイム通信プルーニング(§6.3)**: プルーニングにより変化する collective の通信パターンに対し、NCCL のデータ転送ロジックを改変して数値的正しさを保証する。reduction(各ランクは自身が担当するチャンクの正しさのみ保証すればよい)と broadcast の 2 primitive に分解し、最も左の仮想ランクが刈り込まれたランクの寄与分を事前に補正した値を用意することで、サンドボックスが観測する最終値の正しさを保つ(リング all-reduce で説明、ツリーは Appendix §D で同原理)。 ## 新規性 - 既存のシミュレーションベース手法(vTrain・dPRO・DistSim・ASTRA-sim・SimAI 等)は、プロファイリングやトレース収集からオフラインで性能モデルを構築するため、フレームワーク・コンパイラ・カーネル・ネットワーク・ハードウェア世代が急速に進化する中で維持コストが増大し、実際のシステム挙動(バグ・性能異常)の再現が難しい。Phantora は元の訓練プログラムを CUDA/NCCL バックエンドの置き換えで実行するが、置き換えたコンポーネントは実物ではないため完全には忠実でなく、NCCL のバッファ移動やオーバーラップの複雑さがシミュレーション精度をさらに下げ、CUDA 以下のメモリ断片化やアロケータ挙動も捉えられない。 - 縮小規模実験(downscaling)は、world size・並列化戦略・バッチサイズ・スケジューリング選択という「まさにエンジニアが観察したい挙動」自体を変えてしまう。パイプライン並列の中間ステージ間の通信・計算オーバーラップを観察したい場合、GPU 数を削減すると VPP 度数やグローバルバッチサイズなど多数のパラメータを再構成する必要があり、本番デプロイに有用な結論を得にくい。 - PrismLLM の新規性は、「関心のあるランクだけを物理 GPU 上で実行し、それ以外は論理的に維持する」という選択的実行のアイデアを、(1) 少数 GPU 上でも大規模実行グラフを収集できるコンテキストスイッチ機構と、(2) 収集したグラフを低コストで仮想リプレイするハイブリッドエミュレーション機構の 2 つに具体化した点にある。「規模を見るために規模が要る」というチキンアンドエッグ問題(Challenge 1)と、「物理並行性が失われても大規模時の相互作用パターンを保つ」という課題(Challenge 2)の双方に、record-and-replay の単純な拡張ではなく、スライス単位のタイミング充填 + キャリブレーションという二段階設計で応えている。 ## 実験設定 - **実験環境**: 2,048-GPU テストベッド(1 ノードあたり 8 GPU)。オープンソース Megatron-LM 実装による Qwen3 MoE 事前学習を用いる。 - **モデル構成**: 235B-A22B(M.1)・503B-A20B(M.2)・1.01T-A43B(M.3)の 3 規模。 - **並列化戦略**: TP・PP・EP サイズおよび勾配累積ステップを変えた S.A–S.D の 4 構成(詳細は Appendix §E)。 - **比較対象**: シミュレータとして Phantora・SimAI(NSDI 25)。Phantora は PP・MoE 非対応のため小規模タスク(32-GPU テストベッド、Qwen3 4B、TP=4)でのみ比較。 - **評価指標**: 反復時間(Megatron-LM が報告する 1 ステップの計算・通信込み経過時間、85 反復平均)。ピーク GPU メモリ(PyTorch の `max_memory_allocated`、10 反復以上のウォームアップ後 3–10 反復のピークを計測)。MoE モデルはトークンルーティングの Balanced(Megatron Core による均等分散)/Imbalanced(モック router で偏りを注入)の 2 ケースを評価。 ## 実験結果 - **反復時間予測**: 512/1024/2048 GPU の 3 スケール×3 モデル×2 並列化戦略で、平均誤差 0.58%、最大誤差 1.98%(Figure 7)。 - **ピークメモリ予測**: 全構成で誤差 0.01% 未満、OOM の再現にも成功(Figure 8)。 - **エミュレーション効率**: PP を 4→64 に拡張し 512→8,192 GPU までスケールさせても、アシスタントノード数を対象規模に比例させることで、エミュレーション全体時間を 80 分未満に安定させる。比例スケーリングをしない場合(1,024-GPU をアシスタントノード 1 台で処理)は 125 分とほぼ倍増する。8,192-GPU クラスタのエミュレーションは物理ノード 32 台(アシスタント 16・サンドボックス 16)、対象 GPU の 0.4% 未満、99% 超の資源削減で完了する(Figure 9)。 - **実行忠実度**: カーネルレベルの絶対偏差比較で、1024-rank スケールの全構成においてエミュレーション分散が自然なハードウェア分散の範囲内に収まる(Figure 10)。相対起動時刻の最大誤差は 3.64%(Figure 12)。 - **ブートストラップ最適化**: Vanilla(標準 NCCL)は 512 ランクで CPU メモリ 544.5GB・GPU メモリ 103.7GB を消費し 756.0 秒を要し、1024 ランク以上で OOM に至る。PrismLLM は論理クラスタ規模に依らず一定の資源フットプリントを保ち、8192-ランクのエミュレーションを 44.3 秒・GPU あたり 5.4GB で完了する(Figure 11)。 - **通信プルーニング**: プルーニングなしの Vanilla は最大 148 倍の通信レイテンシ膨張を起こすが、PrismLLM は実行ベースラインに対して最大誤差 0.2% に収まる(Figure 13)。 - **スライス間キャリブレーションの効果**: キャリブレーション前の反復時間推定は 5.7s から 5.13s へ急落し、適切な整合がない場合の誤差が 10% を超えうることを示す。 - **シミュレータとの比較**: Phantora は典型ケースで 12% 誤差だが、シーケンス長が短くなり GPU 側計算負荷が下がると誤差が 64% まで悪化する(生カーネル継続時間の近似・CPU 競合の見落としが原因)。SimAI は平均誤差 77.2% で、パイプライン並列の通信バブルや MoE 特有の演算(gating・permute・dispatch・combine)を捉え損ねる(Figure 14)。 - **チューニング事例(Table 1)**: Flash Attention off・P2P overlap off・optimizer offload・recompute の 4 種の最適化について、反復時間・ピークメモリの両方でベースラインに近い推定値を得ている。 - **本番ユースケース**: サーマルスロットリング(GPU グラフィクス周波数 900MHz へダウンクロック)による訓練速度低下(5.63s→6.38s、14% 増)を、PrismLLM 上での対再現(5.70s→6.40s)で確認できたと報告する。 ## 考察 - PrismLLM の高忠実度は、「実プログラムを実 GPU 上で実行する」という点をコアに据え、シミュレーションが避けられない性能モデル化(カーネル継続時間の推定・ネットワーク挙動の近似)を排したことに由来する。Phantora・SimAI との比較は、この違いが特に MoE のような複雑なワークロード・短いシーケンス長のような GPU 負荷が軽いケースで顕著になることを示す。 - チューニング・計画・クラスタヘルスチェックといったユースケース(§9)は、いずれも「本番クラスタを占有せずに大規模挙動を観測する」という DevOps 上の制約(§3.1)への直接的な回答になっている。特にサーマルスロットリングの再現例は、小規模ヘルスチェックでは機器を十分に追い込めないという downscaling の限界(§3.3)への具体的な反証事例である。 ## 強み / 弱点・課題 - **強み**: シミュレーションモデルの継続的な再実装コストなしに、コード再利用(既存訓練コードを無改変で実行)・低資源フットプリント・高忠実度を同時に満たす。8192 GPU を 1% 未満の物理 GPU でエミュレートできるスケーラビリティを実証。 - **弱点・課題(論文が明記する Limitation)**: 訓練プログラムが対象 GPU プラットフォーム上で実行可能であることを前提とするため、未発売ハードウェアの性能を事前予測する forward planning はできない。また、GPU ワークロードが反復間で周期的であることを仮定しており、distillation のように反復ごとにアクティブな教師モデル数が変わるワークロードでは、代表的な 1 ワークロードのみしかエミュレートできない。 ## 図表 **Figure 1: システム全体像** ![[_attachments/arxiv-2605.15617/fig01-system-overview.png]] (Figure 1. System overview. Stage 1(グラフ収集)で全ランクの bare graph を少数 GPU 上のコンテキストスイッチで収集し、Stage 2(タイミング充填とキャリブレーション)でスライスごとに実行してタイミングを補完・整合させ、Emulation フェーズでサンドボックス/アシスタント GPU に分けてハイブリッドエミュレーションを実行する。①〜⑩ の番号は §4 本文の処理ステップに対応。Source: Figure 1.) **Figure 7: 反復時間推定の精度** ![[_attachments/arxiv-2605.15617/fig07-iteration-time-accuracy.png]] (Figure 7. End-to-end iteration time estimation results. 512/1024/2048 GPU の 3 スケールで、235B/503B/1.01T モデル×2 戦略(S.A–S.D)ごとにベースラインと PrismLLM の反復時間を比較し、誤差(-1.98%〜+0.85%)を各バーに表示。Source: Figure 7.) **Figure 8: ピークメモリ推定の精度** ![[_attachments/arxiv-2605.15617/fig08-memory-accuracy.png]] (Figure 8. End-to-end peak memory allocation estimation results. MoE Balance/Imbalance × Baseline/PrismLLM の正規化メモリを比較。全推定誤差は 0.01% 未満で、OOM も正しく再現される。Source: Figure 8.) **Figure 11: ブートストラップとメモリオーバーヘッドの削減** ![[_attachments/arxiv-2605.15617/fig11-bootstrap-memory-overhead.png]] (Figure 11. Memory usage reduction and bootstrap acceleration of large-scale emulation in PrismLLM. (a) CPU メモリ・(b) GPU メモリはスケール(64–8192)に対して Vanilla が線形増加し 1024 ランク以上で OOM するのに対し PrismLLM は一定。(c) バリア完了時間も PrismLLM が Vanilla に対して大差で安定。Source: Figure 11.) **Figure 12–14: 実行忠実度とシミュレータ比較** ![[_attachments/arxiv-2605.15617/fig12-14-fidelity-and-simulator-comparison.png]] (Figure 12. Kernel launch deviation: 1024-rank スケールでのカーネル起動時刻の相対偏差が自然なハードウェア分散(Natural Variance)の範囲内に収まる。Figure 13. Latency overhead: 通信プルーニングありの PrismLLM がベースラインの通信レイテンシに近い値を保つのに対し、プルーニングなしの Vanilla は最大 148 倍に膨張する。Figure 14. PrismLLM compared with Simulators: Phantora(4B モデル、seqlen 4096/1024)は誤差 -12.64%/-64.29%、SimAI(235B、scale 512/1024/2048)は誤差 -79.39%/-79.37%/-79.93% で、PrismLLM の誤差(-1.15%/-0.45%、-0.62%/-0.37%/+0.85%)より大きく悪化する。Source: Figure 12, 13, 14.)