# 並列化戦略 ## 定義 並列化戦略は、単一デバイスに収まらない LLM の計算・メモリ・通信を複数の GPU/アクセラレータに分割する方式の総称。[[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] §4 は 3 系統に大別する:(1)**Hybrid Parallelism**——手作業で設計した複数の並列化次元を組み合わせる方式で、data + tensor + pipeline の組は **3D parallelism** とも呼ぶ、(2)**Auto Parallelism**——膨大な分割選択肢から最適戦略を自動決定、(3)**Heterogeneous Parallelism**——異種ハードウェア・異種モデル(RLHF 等)向け。data/model/sequence parallelism は SPMD(Single Program Multiple Data)を、pipeline parallelism 等は MPMD を採るのが基本。 主要な並列化次元(Hybrid の構成要素): - **Data Parallelism**: 入力 batch を分割し各デバイスがモデル複製で処理、勾配を集団通信で集約。sharding factor F でメモリ↔通信のトレードオフを制御(F=1:全複製 PyTorch-DDP/Horovod、F=W:full sharding ZeRO-3/FSDP)。 - **Tensor Parallelism**(層内): 層のパラメータテンソルを分割(Megatron-LM の 1-D、Optimus の 2-D、Tesseract の 2.5-D、3-D)。中間アクティベーションを通信するため高帯域が必要でノード内利用が一般的。 - **Pipeline Parallelism**(層間): 層を stage に分割し GPU 集合へマップ。課題は **pipeline bubble**(GPipe の fill-drain、PipeDream の 1F1B、Zero Bubble 等のスケジューリングで削減)と **memory imbalance**(BPipe/Chimera/V-Shape 等で解消)。 - **Sequence Parallelism**: 長いコンテキストへの対応。入力を sequence 次元で分割(Megatron-SP)。アテンションは ring ベース(Ring Self-Attention/DistFlashAttn/Striped Attention)や head 分割(DeepSpeed-Ulysses)で分散。 - **Expert Parallelism**: → [[Mixture-of-Experts]]。 ## 横断的知見 - **並列化戦略は「計算の分割」だけでなくスケジューラの配置制約にもなる**: Jeon 2019 は、データ並列の DNN 訓練が各 GPU のワーカーを同時に動かし、イテレーション末尾で parameter server や MPI/NCCL によって勾配を同期するため、ギャングスケジューリングと局所性制約を必要とすると述べる。現代 LLM の TP/PP/DP/SP/EP はより複雑だが、並列化方式が通信パターンを決め、その通信パターンが配置局所性とスケジューリング制約に落ちる構図は Philly から MegaScale/SAKURAONE まで連続する。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **taxonomy(サーベイ)対 本番システムの具体構成(MegaScale)**: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] §4 が data/tensor/pipeline/sequence の 4 次元を Hybrid Parallelism として体系化するのに対し、[[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] はその 4 次元すべてを実際に組み合わせた本番構成(175B で TP=8/PP=8、530B で TP=8/PP=35、残りを DP)を開示する。サーベイが「TP は AllReduce をノード内、DP/PP はノード間」と述べる通信局所性を、MegaScale も同じ理由で TP を単一ノード内に閉じ、DP group を PP より優先して cross-minipod 通信を緩和する(§2 末尾)——taxonomy の設計原則が本番でそのまま採用されている。(Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **pipeline bubble 削減はスケジューリングだけでなく batch size でも効く**: サーベイ §4 は pipeline bubble 削減を GPipe→1F1B→Zero Bubble の **スケジューリング** 改良として整理するが、MegaScale は interleaved 1F1B を保ったまま LAMB optimizer で batch size を 4 倍にし、bubble を 87.5% 削減する(§3.1)。並列化スケジュールと optimizer 設計(=アルゴリズム側)の協調設計という、taxonomy の並列化軸単独では見えない削減経路を示す。(Source: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **通信オーバーラップは並列化次元ごとに固有の設計を要する**: MegaScale は DP(all-gather の prefetch)・TP/SP(FFN path の Linear と fuse し GEMM を chunk 化)・PP(send/receive の分離)で別々のオーバーラップ技術を実装し、アブレーションで TP/PP/DP overlap が累計 +6.2% MFU と最大の寄与(§3.2, 表3)。並列化を「分割方式」として論じるサーベイ taxonomy に対し、各次元の通信パターンに固有の隠蔽設計が効率を決めるという実装視点を補う。(Source: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **同じ 3D parallelism でも実装世代で pipeline bubble と通信クリティカルパスの影響が変わる**: [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]] は [[InternEvo]] V1 が [[Megatron-LM]] に近い 3D parallelism と階層的 ZeRO を使う一方、通信と pipeline bubble がクリティカルパスに乗り、123B LLM・2,048 GPU のプロファイルで V2 が約 16% 高速化したと報告する。MegaScale が各並列化次元の通信オーバーラップを協調設計で詰めるのに対し、Acme は同じ問題が研究所内フレームワークの世代更新として現れる実例である。(Source: [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **同じ GPT-3 175B でも 3D 構成の配分は組織で異なるが、通信局所性の原則は共通**: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] が 175B で TP=8/PP=8 を採るのに対し、[[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は GPT-3 175B で PP=16 を厚く取り、ノード数に応じ TP=4→8・DP=4→8→6・VP=6 を可変にする(§6.6 表9)。配分は異なるが、SAKURAONE の PyTorch Profiler は PP の SendRecv が NCCL 時間の 91.2% を占め TP の集団通信はノード内 NVLink に留まる(表10)と実測し、サーベイ/MegaScale の「TP をノード内、DP/PP をノード間」という通信局所性の原則が別組織・別インターコネクト(open Ethernet)でも成立することを裏付ける。(Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **PP を厚くすると cross-pod トポロジが通信比率に直接効く**: SAKURAONE は 64 ノードで 2 pod を spine 経由でまたぐと、communication share が 16.4%→19.3%、comm-comp overlap が 72.3%→67.2% に悪化し MFU の頭打ち(96 ノードで 35.9% へ低下)を招く(§6.6 表10)。並列化構成(PP=16)と物理トポロジ(rail-optimized leaf–spine、§4.2/[[オープンネットワーキング]])の協調設計が、taxonomy の並列化軸単独では見えない効率制約を与える。(Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **並列化構成そのものがストラグラーの発生源になる**: [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] は、パイプライン並列(PP)のステージ分割不均衡(最終 PP ステージの損失層が Transformer 層の約 9 倍の計算量を要し、39.3% のジョブで最終ステージが ≥50% のスローダウン寄与)と、シーケンス長不均衡(self-attention の計算量が $O(\sum s_i^2)$ のため、21.4% のジョブが平均スローダウン 1.34)という、ハードウェア障害ではなくアルゴリズム的な負荷不均衡が支配的な浪費源だと示す。貪欲法によるシーケンス再分配で 23.9% のスループット改善。並列化の「分割の仕方」が性能均一性を直接左右し、サーベイや MegaScale が並列化軸を「分割方式・通信隠蔽」として論じるのに対し、分割の不均衡そのものを浪費源として定量化する視点を補う。(Source: [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **同一レール相互接続がハイブリッド並列の通信ボトルネックを外す**: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] は tier-2 まで同一レール相互接続を広げ単一レールで最大 8K GPU を集団通信可能にし、全階層同一帯域(オーバーサブスクリプションなし)で並列化次元の通信を隠蔽する。ストラグラー論文が「専用広帯域クラスタでは通信の影響は軽微で計算が主因(浪費の約 80%)」と観測する(§オペレーション種別帰属)のは、まさに Astral 型の高品質 interconnect を前提にした並列化での帰結であり、2 ソースは「通信を潰すと残るのは計算側の不均衡」という補完関係を示す。(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]], [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) - **集合通信ライブラリ側が並列化次元ごとにトランスポートを作り分ける**: MegaScale が並列化次元ごとに固有のオーバーラップ技術を実装したのと表裏で、[[@2025__arXiv__Collective Communication for 100k+ GPUs]](NCCLX)は[[集合通信]]ライブラリ自体を Llama4 の並列化に合わせて作り分ける——パイプライン並列にはゼロコピー/SM フリーの send-recv、テンソル並列には RMA Put、HSDP(最外殻のデータ並列)にはフォールトトレラント AllReduce、推論には GPU 常駐コレクティブを充てる。並列化を「分割方式」として論じる taxonomy に対し、各次元の通信要件(同期粒度・レイテンシ・耐障害性)に応じてトランスポート層を選び分けるという、ライブラリ側からの並列化最適化の視点を補う。(Source: [[@2025__arXiv__Collective Communication for 100k+ GPUs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **並列構成の選択は実効性能だけでなく「予測可能性」のトレードオフも生む**: [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] ではバランス型モデル並列が最も予測しやすく、データ並列偏重・深いパイプラインが精度を下げる。(Source: [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]]) - **バックエンド移行時の重み layout 変化が性能回帰を招く**: バックエンド移行(FSDP→Megatron)時の FFN 重み layout 変化が Tensor Core の 128B アラインメント不適合を招き FLOPS 65.3% 低下という、並列化次元の変更が引き起こす性能回帰の具体例がある。(Source: [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - **外部観測のみから並列化戦略を逆推定できる**: DP は大容量・可変サイズの集団通信、PP は小容量・一貫サイズの点対点通信という通信フットプリントの差が、外部観測のみからの並列化戦略の逆推定を可能にする。(Source: [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - **ZeRO/FSDP 系のシャーディングは DDP 比 1.5× の通信量を FlatParameter + 通信オーバーラップで隠蔽する**: [[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel|PyTorch FSDP]]([[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]])は FSDP ユニット内の全パラメータを 1 次元の FlatParameter に連結・シャードし、均等サイズの大きな AllGather を 1 回発行する。これはデータ並列の「モデル複製のコスト」と「モデルシャーディングの通信増加」のトレードオフを、通信オーバーラップ設計で実用化した代表例である。T5-11B で 128 A100 上の 159 TFLOPS/GPU を達成し、128–512 GPU で near-linear スケーラビリティを実証した。(Source: [[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]]) - **データ並列の冗長性が耐障害の資源になる——並列化の選択が復旧設計と結合する**: data parallelism は従来「メモリ↔通信のトレードオフ」(sharding factor F)として論じられ、複製は勾配同期の通信コストとして扱われてきた。[[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] はこの複製を**障害復元の冗長コピー**として再解釈する——データ並列度 N のとき各デバイスに N−1 個のモデル状態の複製があり、障害時は同一データ並列グループの正常デバイスから集合通信で復元してチェックポイントを不要化する([[チェックポイント]])。同時全滅確率は $0.001^N$(N=4 で $10^{-12}$)で、**データ並列度が大きいほど複製による復旧が堅牢になる**。MegaScale が「DP group を PP より優先して cross-minipod 通信を緩和する」(配置の通信最適化)のと対照的に、FlashRecovery は同じデータ並列構造を耐障害資源として使い、並列化戦略の選択が効率だけでなく**復旧設計と結合する**ことを示す。(Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **並列化戦略の実務的探索空間は TP/PP/DP の次数だけでなく ZeRO stage・batch・通信プリミティブまで含む**: 既存ソースは主に TP/PP/DP/SP/EP の大域的な分割と通信局所性を扱うが、[[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]] は同じ ZeRO-DP 系でも Stage 1/2/3、batch size、gradient accumulation、DeepSpeed の all-reduce/reduce-scatter 既定実装の違いが性能を左右すると示す。Model-2 では 3 プラットフォームすべてで ZeRO Stage 2・batch_size 128・grad_acc 2 が最良で、Stage 1 の batch_size 128 は out-of-memory になる。したがって並列化戦略は「モデルをどう分割するか」だけでなく、「その分割をフレームワークが実際にどの通信プリミティブで実行するか」まで含めて測る必要がある。(Source: [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **1 兆パラメータ MoE の訓練で PP+EP+ZeRO-1 DP 構成が DualPipe を排して選択された**: [[Kimi K2]](1.04T, 384 エキスパート)は 16-way PP + 16-way EP + ZeRO-1 DP の並列化構成で H800 クラスタ上で訓練された。DeepSeek-V3 が採用した DualPipe(双方向パイプラインで bubble をほぼゼロ化)を採用せず、interleaved 1F1B を選択した。論文は DualPipe の運用複雑性と障害復旧の困難さを理由として挙げており、MegaScale が interleaved 1F1B + LAMB で bubble を 87.5% 削減した知見と整合する。並列化戦略の選択が MFU 最大化(DualPipe)と運用上の復旧容易性(interleaved 1F1B)のトレードオフになる産業的判断を示す。(Source: [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]] §4, [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **DeepSeek-V3 の DualPipe は双方向パイプラインで bubble を $(PP/2 - 1)$ オーダーに圧縮し、テンソル並列を不要化した**: MegaScale が interleaved 1F1B + LAMB で bubble を 87.5% 削減し、Kimi K2 が運用復旧容易性から DualPipe を不採用としたのに対し、[[@2024__arXiv__DeepSeek-V3 Technical Report]] は [[DualPipe]] でフォワードとバックワードの計算チャンクを再配置し、All-to-All と PP 通信を計算中に完全に隠蔽した。DeepSeek-V3 の並列化構成（PP16 + EP64 + ZeRO-1 DP）は MegaScale（TP8 + PP8/35 + DP）と異なりテンソル並列を使わない。DualPipe が通信を隠蔽するためノード内の高帯域 TP が不要になるからであり、並列化構成の選択がパイプラインスケジューリングの設計と不可分であることを示す。代償はパラメータのコピー 2 倍だが、EP64 使用時のメモリ増加は軽微。(Source: [[@2024__arXiv__DeepSeek-V3 Technical Report]], [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **並列化マッピングは同一の並列化次数でも通信オーバーヘッドの分布を大きく変える——予測が可能かつ事前設計が有効**: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]] は GPT-3B/32 GPU で並列化戦略 (p=4,t=2,d=4) のまま DeepSpeed デフォルト対カスタムマッピング(TP・PP をノード内に閉じ DP をノード間に割り当て)を比較し、TP オーバーヘッドは同じながら PP が減少・DP が増加するという異なるプロファイルを得た。さらに、論理的な (p,t,d) と物理マッピングが定まれば通信マトリクス(どの GPU ペアが通信するか)は**実行前に計算できる**。これは SAKURAONE の「PP=16 を cross-pod にまたがせると通信比率が悪化する」という実測知見と整合する——並列化構成とトポロジの協調設計が事前シミュレーションで評価可能であることを実証する。(Source: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **推論サービングでは、並列化の選択がハードウェアの行列演算アラインメント制約によって層ごとに逆転する**: 訓練文脈のソース群は TP/PP/DP/EP を通信局所性・bubble・耐障害性のトレードオフとして論じるのに対し、[[SGLang]] の 96 H100 GPU 推論展開([[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]])は、密な FFN 層で TP でなく DP を選ぶ理由をハードウェアアラインメントに求める——中間次元 18,432 を TP32 で分割すると 576 単位になり 128 バイトアラインメントに非対応となるため、メモリ最適な TP 値は 3〜6 に留まり DP(通信コストは TP の 2 回 all-reduce から 1 回 reduce-scatter+all-gather へ 50% 削減)が有利になる。訓練では「TP はノード内高帯域が前提」([[テンソル並列]])という配置原則で TP が選ばれるのに対し、推論では次元数の割り切れなさそのものが並列化方式を規定するという、訓練側のソースには現れない制約軸を追加する。(Source: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]], [[@2019__arXiv__Megatron-LM Training Multi-Billion Parameter Language Models Using Model Parallelism]]) ## 未解決の問い - Auto Parallelism(Alpa の inter/intra-operator 2 階層、FlexFlow の SOAP 探索空間など)は、手作業設計の 3D parallelism をどこまで置換できるか。探索コストと得られる戦略の質のトレードオフは。 - ZeRO-DP 系の実装差(DeepSpeed Stage 2 既定 all-reduce、`use_multi_rank_bucket_allreduce=false` による reduce-scatter 化)は、他のフレームワーク(FSDP、Megatron、GPT-NeoX)でも同様に「論文上の通信量」と「実際の通信プリミティブ」がずれるか。 - 並列化次元ごとに通信パターンが異なる(TP は AllReduce をノード内、DP/PP はノード間)。この通信局所性を前提にした rail-optimized topology(§7 冒頭・§3.2)は、どの並列化構成で最も効くか。 - sequence parallelism の各手法(ring 系 対 Ulysses 系)は、コンテキスト長・head 数・帯域のどの領域で優位が入れ替わるか。LoongTrain/USP のような統合手法が一般解になるか。 - 手作業設計の 3D parallelism(MegaScale)が達成する MFU を、Auto Parallelism は同規模(12,288 GPU)で上回れるか。MegaScale は探索を使わず固定構成で 55.2% MFU を出しており、自動化の費用対効果の実証が要る。 - PP を厚く取る構成(SAKURAONE の PP=16)は cross-pod 通信に敏感。rail-optimized topology・pod 分割と並列化配分をどう協調設計すれば、ノード増(96)での MFU 低下を抑えられるか。SAKURAONE は 96 ノードのプロファイリングを future work とし精緻な帰属を残している(§6.6)。 - PP ステージ分割・シーケンス長分配の自動均衡化(vocabulary size との兼ね合い、語彙層=損失層の重さ)を、並列化プランナに組み込めるか。ストラグラー論文はステージ分割不均衡の根本解決を未解決とし手動チューニングの難しさを残している(§5.2)。`[[ストラグラー]]` に詳述。 - TP/PP/DP 次数の変更に伴う layout 回帰を移行前に静的予測できるか。([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - sequence/expert 並列(MoE 含む)が混在する場合、フローサイズの mode 判定だけで DP/PP を区別できるか。([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - FlashRecovery の複製冗長による復旧は、データ並列を持つ構成(vanilla DP・ZeRO/FSDP)を前提とする。テンソル並列・パイプライン並列を主体としデータ並列度 N が小さい(あるいは N=1 の)構成では、同一グループ内に復元元の複製が存在しない。テンソル/パイプライン並列主体の構成で、複製冗長に相当する障害復元の冗長性をどう確保するか(隣接ステージからの再計算、別軸の冗長化など)。 - 同時全滅耐性は $0.001^N$ でデータ並列度 N に強く依存する。効率最適化(通信局所性・bubble 削減)が要求する並列化配分と、耐障害性が要求する大きな N が衝突する場合、両者をどう同時最適化するか。複製冗長のメモリコストと N の大きさはどこで均衡するか([[チェックポイント]])。 ## 関連 - ソース: [[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]] / [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]] / [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] / [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] / [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] / [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] / [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] / [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]] - 概念: [[LLM分散学習]] / [[Mixture-of-Experts]] / [[オープンネットワーキング]] / [[GPUクラスタ運用]] / [[ストラグラー]] / [[集合通信]] / [[チェックポイント]] / [[性能可搬性]] / [[ZeROパラメータシャーディング]] / [[テンソル並列]] / [[Prefill-Decode分離]] - エンティティ: [[Shanghai AI Laboratory]] / [[MegaScale]] / [[Megatron-LM]] / [[SAKURAONE]] / [[NCCLX]] / [[CTran]] / [[FlashRecovery]] / [[DeepSpeed]] / [[NCCL]] / [[Yanli Zhao]] / [[SGLang]] / [[DeepEP]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]](InternEvo V1/V2、3D parallelism、階層的 ZeRO、123B LLM 2,048 GPU、約 16% 高速化) - [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]](§4 Parallelism Schemes:4.1 Hybrid / 4.2 Auto / 4.3 Heterogeneous) - [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]](§2.1 data parallelism と勾配同期, §2.3 gang scheduling/locality, §3 locality awareness) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](§2 Background, §3.1 Algorithmic Optimizations, §3.2 Communication Overlapping) - [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]](§6.6 MLPerf Training:Table 9 並列化構成 / Table 10 通信プロファイル) - [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]](§5.2 ステージ分割不均衡:損失層が Transformer 層の約 9 倍・39.3% のジョブで最終ステージが過半のスローダウン / §5.3 シーケンス長不均衡:$O(\sum s_i^2)$・21.4% のジョブ平均 1.34・貪欲法で 23.9% 改善 / 図5 計算が浪費の約 80%・通信は軽微) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§2.1 tier-2 同一レール相互接続・単一レール最大 8K GPU・全階層同一帯域) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](Llama4 向け並列化別トランスポート:PP ゼロコピー/TP RMA Put/HSDP FTAR/推論 GPU 常駐) - [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]](データ並列の複製を障害復元の冗長コピーとして再解釈・同時全滅確率 $0.001^N$・vanilla DP と ZeRO/FSDP 双方に対応) - [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]](ZeRO stage・batch size・gradient accumulation・DeepSpeed 通信プリミティブの実測チューニング) - [[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]]（§4 16-way PP + 16-way EP + ZeRO-1 DP、interleaved 1F1B の選択と DualPipe 不採用の理由） - [[@2024__arXiv__DeepSeek-V3 Technical Report]](§3.2.1 DualPipe: 双方向パイプライン・計算通信完全オーバーラップ、PP16 + EP64 + ZeRO-1 DP・テンソル並列不使用) - [[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]](FlatParameter 設計・後退/前向きプリフェッチ・レートリミッター・ハイブリッドシャーディング。T5-11B 159 TFLOPS/GPU @128 A100、GPT-175B 186 TFLOPS/GPU @512 A100) - [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]](GPT-3B/32GPU での並列化マッピング比較・通信マトリクスの事前計算可能性・TP が PTD-P 通信量の約 99% を占める実測・プロトコル(RoCEv2 vs TCP)の PP/DP への非対称な効果) - [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]](PTD-P 提案・インターリーブドスケジュール (p-1)/(m·v) のバブル削減・スキャッター・ギャザー通信最適化(IB 通信を 1/t に削減)・「TP はノード内・PP はノード間」原則の初の系統的実証・1T パラメータ 3072 GPU 502 PF/s MFU 52%) - [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]](96 H100 GPU 推論展開: Attention=DP Attention、密FFN=DP(TP32 のアラインメント非対応が理由)、疎FFN=EP、LM Head=DP という層別並列化。PD Disaggregation・DeepEP・DeepGEMM・EPLB・Two-batch Overlap)