SGLang Pipeline Parallelism：100万トークンコンテキスト拡張とパフォーマンスブレイクスルー

TL;DR

SGLangは超長コンテキスト推論の課題に対応するため、高度に最適化されたPipeline Parallelism (PP)実装を発表しました。Chunked Pipeline Parallelism、Asynchronous P2P Communication、そしてシンプルで効果的なDynamic Chunkingメカニズムを統合することで、このPP設計は他の並列戦略、PD Disaggregation、HiCacheとのシームレスな互換性を保ちながら、業界トップレベルのパフォーマンスを実現しています。マルチノードH20クラスタ上で、PP4 TP8構成（chunked prefill sizeを12Kに設定）を採用した場合、DeepSeek-V3.1のPrefillスループットはTP8と比較して3.31倍向上し、TP32ソリューション（2.54倍）を30.5%上回り、クロスノード大規模スケーリングにおけるPPのアーキテクチャ上の優位性を際立たせています。さらに、この実装はTTFTを最大67.9%削減し、強スケーリング効率は82.8%に達し、兆パラメータモデルの超長コンテキストに効率的なオープンソースパスを提供します。

H20上でのDeepSeek-V3.1のPrefillスループット（Batch Size = 1、高いほど良い）
注：DCK 12288 (σ=0.65) はDynamic Chunkingを有効化、初期chunked prefill sizeが12K、スムージング係数が0.65を示す。

はじめに

大規模言語モデル（LLMs）が兆パラメータアーキテクチャと「無限」コンテキストウィンドウへと拡張する中、サービングインフラストラクチャは、より細粒度のクロスノード並列戦略への転換が必要です。KVキャッシュ技術は冗長な計算を削減できますが、超長シーケンスの初期入力トークン長（ITL）がもたらす高いTime to First Token（TTFT）の問題は解決できません。Tensor Parallelism（TP）はノード内スケーリングに適していますが、マルチノード展開では通信ボトルネックに直面することが多いです。従来のPipeline Parallelism（PP）は通信量を削減しますが、巨大なプロンプトを処理する際にリソース利用率の低下とバブルオーバーヘッドの問題に直面します。

SGLangは、オープンソースイノベーションと学術研究から着想を得て、非同期通信と動的チャンク化プリフィルを備えた最適化されたPP実装を導入し、パイプラインバブルを効果的に最小化しています。超長プロンプト処理を高スループット、計算スケーラブルなストリーミングワークフローに再構築しました。実測では、このPPはPP4スケーリングで80%以上のスケーリング効率を維持し、Qwen3-235B-A22B-FP8をH20上でPP8展開した際、超長プロンプトのTTFTが81%削減されました。

背景：なぜPipeline Parallelismなのか？

長コンテキストプリフィルにおけるPPの必要性を検証するため、Tensor Parallelism（TP）とContext Parallelism（CP）を比較しました。通信量、バブル比率、実装の複雑さの理論的・実証的分析を通じて、PPはマルチノードスケーリングにおいて独自の最適な位置を占めています。

1. 通信量とスケーラビリティ分析

分散推論スケーリングの主なボトルネックはデバイス間通信です。モデルの深さとシーケンス長が増加するにつれて、転送データ量が制限要因となり、特に大規模マルチノード展開では顕著です。

Bをバッチサイズ（超長コンテキストでは通常1）、Sを総シーケンス長、Hを隠れ状態の次元、Lを総レイヤー数、Mをマイクロバッチサイズ、アクティベーション精度をFP8（1バイト）と仮定します。異なる戦略の通信量分析は以下の通りです：

• TP：単一レイヤー内で重みテンソルを分割し、Attention BlockとMLP Block後に同期が必要。All-Reduce通信はレイヤー数に比例して線形に増加し、帯域幅に制限されます。
  通信量(TP) ≈ 4 · B · S · H · L · bytes（リング型All-Reduceは各操作で2倍のデータ、各レイヤーで2回のAll-Reduce）。
• CP：各レイヤーでAll-GatherによりKV状態を集約、帯域幅制限環境では遅延が高い。
  通信量(CP) ≈ 2 · B · S · H_KV · L · bytes（Ring-Attention方式、GQAではH_KVが小さい）。
• PP：パイプラインステージ境界のみで転送、集団操作ではなくP2Pを使用。通信頻度はステージ数Pで決定（P ≪ L）。
  通信量(PP) = B · S · H · (P-1) · bytes（マルチノードでは通信量が約1桁削減）。

2. バブル比率のトレードオフ

PPは通信を最適化しますが、パイプラインバブル（デバイスのアイドル待機）を導入します。TP/CPの理論的バブル率は0で、すべてのデバイスが並列に計算します。

PPのバブル比率：バブル比率 = (P - 1) / (P - 1 + M)。長コンテキストプリフィルではM ≫ Pのため、比率は極小で、通信の利益が損失を大幅に上回ります。パフォーマンス影響セクションでStrong Scaling Efficiencyを評価します。

純粋な高次PPは推奨されません（バブルはPとともに増加）。ノード内のバブルフリーTP/CP（NVLink高帯域幅）と組み合わせることが望ましいです。

3. 実装の複雑さとアーキテクチャの汎用性

オープンソースシステムは実装の簡潔性と汎用性を重視します。

• TP：実装が容易で広くサポートされていますが、大規模TPは量子化（MoE FFN重み）と互換性がなく、マルチノードでの制限があります。
• CP：複雑で、アテンションメカニズムへの侵入的な修正（Ring Attentionなど）が必要です。