# 並列化戦略 ## 定義 並列化戦略は、単一デバイスに収まらない LLM の計算・メモリ・通信を複数の GPU/アクセラレータに分割する方式の総称。[[Efficient Training of Large Language Models on Distributed Infrastructures]] §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]]。 ## 子概念 - [[LLM分散学習]] - [[LLM推論設計空間探索]] - [[Prefill-Decode分離]] - [[ZeROパラメータシャーディング]] - [[Zero Bubble]] - [[アクティベーションオフロード]] - [[ストラグラー]] - [[チェックポイント]] ## 横断的知見 - **並列化の実践は、抽象的な分割方式より前に「何を作るか」と専用ハードウェアの境界を決める**: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]]は、用途ごとに異なる計算機を設計する考え方と、FLATS・SIGMA-1・GRAPE-DRの製作経験を示す。[[@2004__SC__GPU Cluster for High Performance Computing]]が GPU クラスタでサブドメイン分割と通信/計算の重なりを最適化したのに対し、前者は専用計算機そのものを設計空間に含める。現代の data/tensor/pipeline parallelism は既製アクセラレータ上の分割を主対象とするが、両者を並べると、並列化戦略は分割後のスケジュールだけでなく、計算機アーキテクチャの選択まで含む連続した設計問題として見える。(Source: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]], [[@2004__SC__GPU Cluster for High Performance Computing]]) - **3D parallelismの実装では、並列化方式と低レベルの数値・スケジュール設計が結合する**: [[PLaMo-100B]]はデータ・テンソル・パイプライン並列を組み合わせ、Zero Bubbleでパイプラインバブルを削減した。一方、投機的更新はデバッグ容易性とgradient clippingの挙動を理由に採用されなかったため、並列化の理論効率だけで実運用の構成を決められない。(Source: [[@2024__Preferred Networks__1,000億パラメータ規模の独自LLM「PLaMo-100B」の事前学習]]) - **並列化戦略は「計算の分割」だけでなくスケジューラの配置制約にもなる**: 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)**: [[Efficient Training of Large Language Models on Distributed Infrastructures]] §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: [[Efficient Training of Large Language Models on Distributed Infrastructures]], [[@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]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **通信オーバーラップは並列化次元ごとに固有の設計を要する**: 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]], [[Efficient Training of Large Language Models on Distributed Infrastructures]]) - **同一レール相互接続がハイブリッド並列の通信ボトルネックを外す**: [[@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]]) - **Data Parallelism の通信オーバーラップは「全同期を隠す」から「同期そのものを層単位に分解する」へ一段深化する**: MegaScale は DP の all-gather を prefetch でバックグラウンド化することで既存の全パラメータ同期を計算の影に隠すが、同期の粒度(全パラメータを一括)自体は変えない。[[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]](DreamDDP)は Local SGD の文脈で、同期対象そのものを層単位に分割し異なるイテレーションへ配分する partial synchronization を提案し、DFS スケジューラで「どの層をどのイテレーションで同期するか」を最適化する。オーバーラップ設計が「固定された同期単位を計算の影に隠す」段階から「同期単位そのものを再設計してオーバーラップの機会を作り出す」段階へ進んだ事例であり、低帯域の地理分散環境ほど効果が際立つ(ASC-WFBP 比 1.73〜5.22×)。(Source: [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **同期頻度 H によるメモリ↔通信トレードオフの軸に、DreamDDP は「層単位の同期スケジュール」という第三の軸を加える**: Data Parallelism は従来 sharding factor F(全複製〜full sharding)で通信量とメモリのトレードオフを制御してきたが、DreamDDP は Local SGD の同期頻度 H を固定したまま、どの層をどのタイミングで同期するかという配置問題を追加の最適化軸として導入する。ZeRO/FSDP の F 軸・Local SGD の H 軸に対し、DreamDDP の「層×イテレーションのスケジューリング」軸は独立に組み合わせ可能であり、通信量を増やさずに収束(モデル乖離 Γ_r)と wall-clock 時間の両方を改善する。(Source: [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]], [[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]]) - **推論では Prefill と Decode で最適な並列化次数が体系的に異なり、本番規模でフェーズ別チューニングが実施された**: 既存ソース群は訓練文脈での TP/PP/DP/EP の通信局所性・bubble・耐障害性を論じ、[[SGLang]] の推論展開はハードウェアアラインメント制約による層別並列化を扱うが、[[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta)は同一モデル内でも**フェーズ(Prefill/Decode)ごとに独立して最適並列化次数が変わる**ことを本番規模の実測で示した。Prefill(70B、GPU-A)では PP4-TP2 が SLO ヘッドルームを活かしつつ QPS を最大化する(TP4PP2 はレイテンシは低いが QPS は20%低い)のに対し、Decode(70B、GPU-C)では TP8・大バッチが最適になる。この非対称性は [[Prefill-Decode分離]] がフェーズ別に独立した資源プールを持つことで初めて活用可能になり、継続的バッチングでは単一の並列化設定を両フェーズで共有せざるを得ないため活かせない。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **並列化構成の探索は組合せ爆発する空間を、実測ベンチマーク駆動の軽量シミュレータで体系的に走査するアプローチへ産業実装された**: Auto Parallelism(Alpa の inter/intra-operator 探索等)が理論的な自動探索を扱うのに対し、Meta の実装は「5次元並列化だけで約1,000通り、モデル・ハードウェアと掛け合わせ100万超」という具体的な組合せ規模を報告し、演算子マイクロベンチマーク(ハードウェアあたり10万件超)の区分線形補間で実機比±5%精度のシミュレータを構築、数分でこの空間を走査した。→ [[LLM推論設計空間探索]]。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **異種ハードウェアへのフェーズ割当は並列化戦略の意思決定と不可分であることが本番規模で定量化された**: Prefill は計算バウンド(高 FLOPs アクセラレータが有利)、Decode はメモリ帯域バウンド(高 HBM 帯域アクセラレータが有利)という資源特性の違いから、Meta は405Bモデルの分離推論で異なるアクセラレータ種を Prefill/Decode に割り当て、同種構成と同等のQPSを15〜25%低いTCOで達成した。これは並列化次数(P)の選択だけでなく、ハードウェア選択(H)自体もフェーズ別に最適化すべき変数であることを示し、並列化戦略の議論をハードウェア異種性の次元へ拡張する。最適な Prefill:Decode アクセラレータ比は組み合わせごとに大きく変わる(GPU-A/A で0.88、GPU-A/B で3.14)。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **EP=#Experts・ES=TP のデフォルト前提から独立させる decoupled parallelism が、モデル並列次数の探索空間を co-design ツールで定量評価された**: 既存の知見は TP/PP/DP/SP の配置局所性・通信オーバーラップ・耐障害性を扱うが、[[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]] の [[Calculon-MoE]] は MoE 特有の EP(エキスパート並列)と ES(エキスパートシャーディング)を非 MoE 側の TP/PP から独立させる制約式 $DP_{non\text{-}MoE} \times TP \times PP = DP_{MoE} \times EP \times ES \times PP$ を提案し、NeMo・DeepSpeed の慣習(EP=#Experts、ES=TP)から外れる構成が GPT4-1.8T の MFU を 75.96%→83.66% に改善することを実証した。SAKURAONE や MegaScale が dense モデルの TP/PP/DP 配分を通信局所性の観点から最適化するのと同じ発想を、MoE 特有の EP/ES 次元に拡張した事例である。(Source: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]], [[Mixture-of-Experts]]) - **系列長の並列化次元は「分割の粒度」自体が最適化対象になる**: 既存の知見群は TP/PP/DP/SP/EP という並列化「次元」の配置・通信局所性を論じるが、[[@2026__ICS__SPPO - Making Million-Token LLM Training Practical on Modest GPU Clusters]] は Sequence Parallelism/Pipeline Parallelism を固定次元として扱うのではなく、系列を何個の「部分系列(subsequence)」に割るか(粒度 N)そのものを、[[アクティベーションオフロード]]比率とヒューリスティックソルバーで動的に最適化する。長系列を単一ブロックとして扱う既存手法(活性化再計算・CPU オフロード・分散並列化)は「粒度ミスマッチ」により転送が粗すぎて隠蔽できずバブルが生じるという診断は、MegaScale・SAKURAONE が示す「並列化次元の配置」レベルの最適化とは異なる、「分割粒度そのもの」という一段細かい最適化軸を並列化戦略の議論に追加する。128台の GPU で 7B モデルを400万トークンまで訓練可能にし、Megatron-LM・DeepSpeed-Ulysses 比最大 3.38 倍のスループット改善を達成した。(Source: [[@2026__ICS__SPPO - Making Million-Token LLM Training Practical on Modest GPU Clusters]]) - **マルチモーダルLLMでは「並列化次元の選択」がサブモデル単位で分岐し、同一GPU集合を時間多重化する**: 既存の知見群は単一モデル(dense/MoE)内でのTP/PP/DP/SP/EPの配置局所性を論じるが、[[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]] はMLLMのencoderとLLMバックボーンという**2つの異質なサブモデル**に対し、根本的に異なる並列化戦略を選ぶ(encoderはDP+Ulysses SPを時間的にシフトするLong-Short Sequence Parallelism、LLMはTP/PP/SP/EPを含むfull-fledged 5D parallelism)。さらにこの2つの並列化ドメインを**空間的に分離配置(disaggregation)せず同一GPU集合上でコロケーションし、EncoderAnchorという抽象化でLLMパイプラインスケジュールに時間的にオンデマンド挿入する**。Calculon-MoEがMoEのEP/ESをTP/PPから独立させる「次元の分離」であるのに対し、MegaScale-Omniは「資源(GPU)の分離」そのものを行わず時間軸で多重化するという、質的に異なる decoupling を提示する。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]], [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]]) - **静的な encoder-LLM disaggregation は動的ワークロードで再びボトルネックに直面する——並列化配置は「一度決めれば終わり」ではない**: DistMM/DistTrain のような encoder-LLM disaggregation(encoderとLLMを別モデルとして別の固定資源・並列化戦略に静的分離)は、MegaScale が確立した「通信局所性に基づく静的配置」の系譜にあるが、[[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]] はモダリティ混合比率とサンプル長分布が訓練フェーズを通じて連続的にシフトする(§2.2)ため、固定資源配分では encoder 資源が不足すれば LLM パイプラインバブル、過剰であればデバイスアイドルが交互に生じると指摘する。単一モデル内の並列化構成は Auto Parallelism(Alpa)を除き概ね訓練を通じて固定される、という既存知見群の暗黙の前提を、MLLM という「複数サブモデルが動的に相対ワークロードを変える」設定が突き崩す。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]]) - **並列化方式ごとの通信特性・主な通信ドメイン・ボトルネックを一枚の対応表に整理すると、Scale Up/Scale Out という物理ネットワーク境界と並列化次元の対応が明確になる**: [[@2025__SpeakerDeck__AIインフラを考える]] は Data/Pipeline/Tensor/Expert/3D Parallel を「通信特性(All-Reduce/Send-Recv/ReduceScatter-AllGather/all2all)」「主な通信ドメイン(Scale Up/Scale Out)」「ボトルネック(ノード間帯域/Pipeline Bubble/レイテンシ)」の3軸で整理し、Tensor Parallel のみが Scale Up と Scale Out の両方にまたがることを明示した。これは既存知見が示す「TP はノード内、DP/PP はノード間」という通信局所性原則(MegaScale・SAKURAONE)を、AIインフラ設計者向けにネットワークドメインの言葉で言い換えたものであり、「基本的にネットワークが遅いと何をやっても遅い」という同資料の結論は、並列化戦略の性能上限がアプリケーション層ではなくインターコネクト層にあるという既存知見と符合する。(Source: [[@2025__SpeakerDeck__AIインフラを考える]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **実務書の教科書的整理は、既存サーベイ・実装論文が確立した通信局所性原則を「改善効果の視座」という別の軸で再配列する**: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 3 パフォーマンス改善]] はデータ・テンソル・パイプライン・コンテキスト・エキスパートの5並列を「合計プロセス数=5並列数の総積」(式3.10)として整理し、テンソル並列はノード内高帯域が前提・パイプライン並列数は最小限にとどめるという方針を示す。これは MegaScale・SAKURAONE が実測で裏付けた「TP はノード内、DP/PP はノード間」という通信局所性原則([[並列化戦略]]既存知見)と同じ結論だが、実務書は測定データではなく「視座の高さ(アプリケーション近接度)から改善に着手する」という別の説明原理からこれを導出しており、研究文献の実測知見と実務教科書の説明原理が独立に同じ配置原則へ収束することを示す。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 3 パフォーマンス改善]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **推論書籍は「TPをノード内に収め、PPは最小限、EPを最大化、DPでスループットをスケール」という優先順位付きの経験則を提示し、既存知見の通信局所性原則(MegaScale・SAKURAONE)を推論文脈の意思決定手順として明文化する**: 『AI Systems Performance Engineering』第15章は、TP→PP→EP→DP(→CP)の順で並列化次元を適用する優先順位を明示し、NVL72ラック(72GPU、NVLink Switch経由で最大8ラック576GPU)というハードウェアスケールに対応づける。既存知見は訓練文脈で「TPはノード内、DP/PPはノード間」という配置原則を実測(MegaScale・SAKURAONE)や理論(Megatron-LM論文)から導出してきたが、この書籍は推論サービングの文脈で同じ原則を「どの順で並列化次元を足すか」という手順に落とし込み、TPドメインの拡張がNVLink Switch Systemsのラック間接続にも及ぶという最新ハードウェア世代固有の数値を追加する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **推論のコンテキスト並列化(CP)は、既存知見が扱うシーケンス並列化(訓練文脈のring/Ulysses系)と同じ「系列次元の分割」を推論のprefillレイテンシ削減という異なる目的で再利用する**: 第15章は、数万〜数百万トークンの超長文脈prefillに対しCPが近似線形の速度向上とKVキャッシュのGPU間分割を実現するが、decode段階の逐次生成には寄与せず短いプロンプトでは通信オーバーヘッドが不利になると整理する。これは既存知見が[[シーケンス並列化]]をring self-attention・DeepSpeed-Ulyssesとして訓練の長コンテキスト対応に位置づけるのと同じ技術的発想だが、書籍は推論のTTFT最適化という応用先を明確に切り分けており、同一の並列化次元(系列分割)が訓練と推論で異なる性能指標(スループット対TTFT)を最適化する例を示す。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]]) - **第15章の「TP→PP→EP→DPの静的優先順位」は、第19章では「リクエスト特性に応じた実行時アダプティブ切り替え」へ一段進化する**: 第15章はTP/PP/EP/DPを適用する優先順位を固定的な経験則として提示するのに対し、[[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]] は同じ並列化次元(TP・PP・エキスパート並列)を、リクエストのシーケンス長・GPUメモリ使用率・並行リクエスト数という実行時メトリクスに基づき動的に選択する決定関数(`choose_worker_pool`)として実装する。事前にTP専用・TP+PPハイブリッドなど複数のシャーディング済みモデルインスタンスをワーカープールとして維持し、リシャーディングのコスト(GPUキャッシュへの悪影響、メモリ/ネットワーク圧)を避ける設計は、第15章の静的な優先順位ヒューリスティックが「単一の推論インスタンス構成をどう決めるか」を扱うのに対し、「複数構成を同時に維持しリクエストごとに動的に選ぶ」という質的に異なる運用モデルを提示する。DeepSeek-R1(256エキスパート中top-9)の8×B200サーバでの具体例では、通常は4-way TPで4GPUを使い、超長文脈(>100万トークン)が到着した場合のみ2段パイプラインへ動的に拡張する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]], [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]]) - **NVL72ラックの輻輳認識・トポロジ認識スケジューリングは、通信局所性原則(TPはノード内、DP/PPはノード間)を「配置の静的最適化」から「テレメトリ駆動の実行時再配置」へ拡張する**: MegaScale・SAKURAONEが確立した通信局所性原則は訓練時の固定配置を前提とするが、第19章のNVTAGS(Topology-Aware GPU Selection)は同じNVLink/NVSwitchトポロジを対象に、リンク使用率テレメトリ(NVML)に基づいてプロセス-GPUマッピングを推論実行中に動的に再割当てする。MoEエキスパート再配置(頻繁に共起するエキスパートを同一GPU/ノードへ再配置)も同様に、静的な配置問題(Calculon-MoEのEP/ES分離)をランタイムの通信統計に基づく反復的最適化問題へ拡張する。ただしエキスパート移動はGB単位の重み転送を伴うため、書籍はメンテナンスウィンドウでの低頻度実行を推奨しており、訓練文脈のホットブロック複製(Mooncakeの発想に近い)ほど頻繁には行えない。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]]) - **同一ハードウェア・同一ワークロードでも訓練フレームワークごとにベストチューニング後の最適構成は構成空間上の異なる点にあり、他フレームワークへの転用は最大3倍の性能損失を生む**: 既存知見はTP/PP/DP/EPの配置局所性・通信オーバーラップ・耐障害性という「並列化次元をどう設計するか」を論じるが、[[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]はLLMエージェントベースの構成探索ツールCCL-Searchを用いてLlama-3.1-8B(16 Perlmutter GPU)上で[[TorchTitan]]と[[Megatron-LM]]をそれぞれ15イテレーション探索し、TorchTitanの最良構成(TP=1, DP=4, PP=4、step time 1.50s)とMegatron-LMの最良構成(TP=4, DP=1, PP=4、0.44s)が3.4倍のstep time差を持つ異なる点にあることを実証した。TorchTitanの最適構成をMegatron-LMへ適用すると1.3s(Megatron-LM自身の最適比で3倍遅い)であり、「並列化構成の最適解はフレームワーク実装に強く依存し単純に転移しない」という、次元設計の議論では捉えられない実装依存性を追加する。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) - **compute-communication overlapを増やす並列化選択(小さいEP次数)が、通信トラフィック量自体を増加させてstep timeを悪化させることがある——overlap率という単一指標は並列化の良し悪しを誤って示しうる**: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]は、DeepSeek-V3-16B MoE訓練(TP=4, DP=2, PP=1)でEP=4(GPU数に対し相対的に小さいEP次数)がEP=8よりも高いcompute-comm overlapを示すにもかかわらずstep timeが11.98s(EP=8は3.67s)と大幅に悪化することを発見した。原因は、小さいEPドメインがデータ並列ドメインをまたいでエキスパートを複製し、fully-sharded data parallelismによる重み収集・勾配同期(ReduceScatter・AllGather)を追加で必要とするためであり、これらは部分的にオーバーラップ可能だが追加通信量がオーバーラップの利益を上回る。MegaScaleが「通信オーバーラップを増やせば効率が上がる」という前提でオーバーラップ技術を実装したのに対し、CCL-Benchはexpert parallelismとdata parallelismの協調最適化が不十分だとオーバーラップそのものが誤誘導指標になりうることを示す。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) - **並列化戦略の最適化は、構成を決める前の探索だけでなく実行後の性能診断と改善提案まで含む**: [[Zoomer]] は tensor、pipeline、data、expert parallelism の相互作用を可視化し、数千 rank の GPU 効率ヒートマップ、通信パターン、ストラグラー、クリティカルパスを同じ分析基盤で扱う。[[MegaScale]] や SAKURAONE が並列化と通信局所性を設計時に協調するのに対し、Zoomer は実行トレースから構成固有の不均衡や通信ボトルネックを見つけ、改善ノートブックや再実行へつなぐ運用時のフィードバックを追加する。(Source: [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **同じ 3D Parallelism/ZeRO の中核機能を共有するフレームワークでも、周辺機能の束ね方が実務上のフレームワーク選択を左右する**: 既存の知見は DeepSpeed の ZeRO 実装差(PMBS の `use_multi_rank_bucket_allreduce` 指摘)や Megatron-LM の TP/PP 通信局所性(PTD-P)など、個々のフレームワークの内部実装を深掘りするのに対し、[[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] の Table 2 は [[DeepSpeed]]・[[Megatron-LM]]・[[Colossal-AI]]・[[Nanotron]]・[[MegaBlocks]]・[[FairScale]]・[[Pax]]・[[Composer]] という学習/微調整対応 8 フレームワークを横並びにし、3D Parallelism または ZeRO/FSDP という並列化の中核機能は共有しつつ、Expert Parallelism(8 中 5 フレームワークのみ)・SSM 対応(Nanotron のみ)・RLHF(DeepSpeed・Colossal-AI のみ)という周辺機能の有無で差が付くことを示す。MegaBlocks が汎用フレームワークとしてではなく MoE 専用コンポーネントとして Megatron・vLLM への統合を前提に設計されているのは、この機能束が「単一フレームワークで全部揃える」方向だけでなく「専用コンポーネントを組み合わせる」方向にも分岐しうることを示す一例である。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]], [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]) - **RLHF のモデル異種性は並列化戦略上「訓練/推論の混在」という第 4 の分岐軸を追加する**: 既存の知見は data/tensor/pipeline/sequence/expert という並列化「次元」の配置局所性を論じるが、[[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 4 Parallelism Schemes for LLM Training]] §4.3.2 が扱う RLHF の PPO 訓練段階は、actor/critic/reward/reference という複数モデルが同一イテレーション内で推論プロセス(応答生成・スコア計算)と訓練プロセス(重み更新)を切り替えるという、単一モデルの並列化とは異なる構造を持つ。DeepSpeed-Chat の Hybrid Engine はこれに対応し、推論時は tensor parallelism でスループットを、訓練時は ZeRO/LoRA でメモリ効率を優先するというモデル分割の動的切り替えを実装する。これは [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] の Table 2 が「RLHF 対応」を DeepSpeed・Colossal-AI のみが持つ周辺機能として位置づけていることと符合する——RLHF 対応フレームワークは 3D Parallelism/ZeRO という共通核に加え、訓練/推論間でのモデル分割切り替えという追加の実装複雑性を引き受けている。(Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 4 Parallelism Schemes for LLM Training]], [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]]) - **訓練時の Heterogeneous Hardware(混在デバイス種別の並列化)と推論時のフェーズ別異種ハードウェア割当は、異なる粒度で同じ「デバイス種の使い分け」問題を扱う**: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 4 Parallelism Schemes for LLM Training]] §4.3.1 の HetPipe・AccPar・AMP 等は、単一の訓練ジョブ内で混在する GPU 世代・専用アクセラレータの計算/メモリ/帯域差を、tensor 分割比率やパイプライン stage 配置で吸収する(デバイス単位の粒度)。一方 [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]] が示す Prefill/Decode 別アクセラレータ割当(TCO 15〜25%改善)は、同一モデルの実行フェーズ単位でハードウェア種を使い分ける(フェーズ単位の粒度)。両者は「異種ハードウェアに何を割り当てるか」という共通の問題を、訓練は物理層(デバイス)、推論はワークロード層(フェーズ)という異なる分割単位で解いており、粒度の違いが解法(動的計画法によるテンソル分割 対 実測ベンチマーク駆動のシミュレータ)の違いにも反映されている。(Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 4 Parallelism Schemes for LLM Training]], [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) ## 未解決の問い - 専用計算機を自ら設計・製作する場合のアーキテクチャ選択と、既製アクセラレータ上で並列化方式を選ぶ場合の設計空間を、性能・開発期間・教育効果・再利用性の共通指標で比較できるか。([[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]]) - 『AI Systems Performance Engineering』第15章の「TP→PP→EP→DP」優先順位の経験則は、Metaの実測([[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]])が示す「Prefill=PP4-TP2・Decode=TP8+大バッチ」というフェーズ別最適解とどう整合するか。書籍の経験則は単一の推論インスタンス全体を想定しているが、Prefill-Decode分離環境ではフェーズごとに優先順位そのものが変わりうるか。 - SPPO の部分系列粒度の動的最適化(ヒューリスティックソルバーによる N・PP・SP の同時決定)は、Calculon-MoE の decoupled parallelism や Auto Parallelism(Alpa)の探索空間とどう統合できるか。分割「次元」の探索と分割「粒度」の探索は独立に扱えるか、それとも結合探索が必要か。 - Calculon-MoE の decoupled parallelism(EP≠#Experts、ES≠TP)は、MegaScale・SAKURAONE が確立した「TP はノード内、DP/PP はノード間」という通信局所性原則と、EP/ES をどう組み合わせるのが最適か。EP・ES それぞれに固有の局所性原則があるのか、他の並列化次元と共有できるのか。 - Auto Parallelism(Alpa の inter/intra-operator 2 階層、FlexFlow の SOAP 探索空間など)は、手作業設計の 3D parallelism をどこまで置換できるか。探索コストと得られる戦略の質のトレードオフは。 - Table 2([[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]])が示す学習対応フレームワークの機能束(3D Parallelism/ZeRO の共通核 + Expert Parallelism・SSM・RLHF などの周辺機能)は、どの組み合わせが実運用で支配的になるか。MegaBlocks のような MoE 専用コンポーネント化と、DeepSpeed・Colossal-AI のような全部乗せフレームワーク化は、今後どちらが優勢になるか。 - 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 の大きさはどこで均衡するか([[チェックポイント]])。 - DreamDDP の層単位部分同期(PLSGD)は現在 Local SGD(H イテレーションごとの同期)を前提とする。ZeRO/FSDP のような毎イテレーション同期する Data Parallel 手法にも、同様の「同期対象を層単位に分解しスケジューリングする」発想は適用できるか。毎イテレーション同期では H=1 に相当し PLSGD のスケジューリング上の自由度(H イテレーションにまたがる配分)が失われるため、別の設計が必要になる可能性がある。(Source: [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]]) - DreamDDP は Expert Parallelism との統合を「基本的に両立可能」と述べるが、実験では全エキスパートをローカル複製する pure DP 構成のみで評価している。EP を用いた MoE 訓練で、エキスパートごとに異なる負荷・通信パターンを持つ場合、DFS スケジューラの層単位プロファイリング前提(層ごとの BP・通信時間が事前に安定して測定できる)はどこまで成立するか。(Source: [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]]) - MegaScale-Omni の encoder-LLM multiplexing(時間多重化コロケーション)は、FlashRecovery のようなデータ並列複製ベースの障害復元(同一 DP グループ内の正常デバイスから復元)とどう両立するか。同一 GPU に encoder と LLM の 2 つの並列化ドメインが時間軸で共存する場合、チェックポイント境界や障害復元時の「どちらの状態を復元するか」の切り分けは複雑化しうる。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) - MegaScale-Omni の EncoderAnchor(データフローを pp_schedule という JSON 形式で手動記述)は、動的ワークロードのシフトに応じて挿入位置を自動的に再最適化できるか。Auto Parallelism(Alpa)のような自動探索と組み合わせられるか、それとも on-demand insertion の「LLM 計算が必要とする直前に計算する」というオンライン的性質が事前探索と相性が悪いか。 - 第19章の実行時アダプティブ並列化切り替え(複数プリシャード済みインスタンスのワーカープール)は、Metaの実測([[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]])が示すPrefill/Decodeフェーズ別最適構成とどう統合すべきか。フェーズごとに最適並列化次数が異なるうえ、リクエストごとにも系列長で最適並列化が変わるとすると、ワーカープールの数(維持すべきシャーディング済みインスタンスの組み合わせ数)は現実的な上限に達するか。 - NVTAGSのようなプロセス-GPU動的再マッピングと、MoEエキスパート再配置(GB単位の重み転送を伴う)は、どちらも「通信ホットスポットの実行時解消」を目的とするが移動コストの桁が大きく異なる。両者を単一のトポロジ最適化ループへ統合する場合、再配置の意思決定にどのような優先度・頻度の階層を設けるべきか。 ## 関連 - ソース: [[@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]] / [[Efficient Training of Large Language Models on Distributed Infrastructures]] / [[@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]] / [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]] / [[@2026__ICS__SPPO - Making Million-Token LLM Training Practical on Modest GPU Clusters]] / [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]] / [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]] / [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]] / [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] - 概念: [[LLM分散学習]] / [[Mixture-of-Experts]] / [[オープンネットワーキング]] / [[GPUクラスタ運用]] / [[ストラグラー]] / [[集合通信]] / [[チェックポイント]] / [[性能可搬性]] / [[ZeROパラメータシャーディング]] / [[テンソル並列]] / [[Prefill-Decode分離]] / [[LLM推論設計空間探索]] / [[AIデータセンタートポロジ]] / [[パイプライン並列化]] / [[シーケンス並列化]] / [[アクティベーションオフロード]] / [[ビジョン言語モデル]] / [[LLM基盤ベンチマーク]] - エンティティ: [[Shanghai AI Laboratory]] / [[MegaScale]] / [[Megatron-LM]] / [[SAKURAONE]] / [[NCCLX]] / [[CTran]] / [[FlashRecovery]] / [[DeepSpeed]] / [[NCCL]] / [[Yanli Zhao]] / [[SGLang]] / [[DeepEP]] / [[Calculon-MoE]] / [[ByteDance Seed]] / [[TorchTitan]] / [[CCL-Bench]] / [[CCL-Search]] / [[Colossal-AI]] / [[Nanotron]] / [[MegaBlocks]] / [[FairScale]] / [[Pax]] / [[Composer]] - 関連 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% 高速化) - [[Efficient Training of Large Language Models on Distributed Infrastructures]](§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) - [[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]](Local SGD の層単位部分同期(PLSGD)・DFS ベーススケジューラによる通信-計算オーバーラップ最適化・地理分散低帯域環境での ASC-WFBP 比 1.73〜5.22× 高速化) - [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta、推論のフェーズ別並列化最適化。Prefill=PP4-TP2・Decode=TP8+大バッチという非対称最適解の本番実測、異種ハードウェアのフェーズ別割当で TCO 15〜25%改善、軽量シミュレータによる100万超構成の体系的探索、MLSys 2026 Industry Track) - [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]](Calculon-MoE。EP/ES を非 MoE 側の TP/PP から独立させる decoupled parallelism で GPT4-1.8T の MFU を 75.96%→83.66% に改善。EP=#Experts・ES=TP のデフォルト前提が最適でないことを定量実証) - [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]](§4 encoder-LLM multiplexing:LSSP・full-fledged 5D parallelism・EncoderAnchor・workload-resilient pipeline。§5 decentralized grouped reordering・adaptive sharding。4ベースライン比1.27×〜7.57×のスループット改善、数千GPU本番運用) - [[@2025__SpeakerDeck__AIインフラを考える]](並列化方式別の通信特性・主な通信ドメイン(Scale Up/Scale Out)・ボトルネックの対応表) - [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 3 パフォーマンス改善]](5次元並列の教科書的整理、式3.10、視座の高さに基づく改善順序付け) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 19 Dynamic and Adaptive Inference Engine Optimizations]](実行時アダプティブ並列化切り替え:`choose_worker_pool`決定関数、複数プリシャード済みインスタンスのワーカープール、NVTAGSによるプロセス-GPU動的再マッピング、MoEエキスパート再配置) - [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]](Table 2:学習/微調整対応 8 フレームワークの機能比較。3D Parallelism/ZeRO の共通核と Expert Parallelism・SSM・RLHF などの周辺機能の分布)