@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting

# Splitwise: Efficient Generative LLM Inference Using Phase Splitting > [!abstract] 概要(arXiv abstractの日本語訳) > 生成型大規模言語モデル(LLM)アプリケーションの急速な増加は、高価で電力消費の大きいGPUの大規模展開を招いている。われわれのLLM推論の特性評価によれば、推論リクエストには2つの主要フェーズがある。計算集約的なプロンプト計算フェーズと、メモリ集約的なトークン生成フェーズであり、それぞれレイテンシ・スループット・メモリ・電力の特性が異なる。最先端のバッチング・スケジューリングを用いても、トークン生成フェーズは計算資源を十分に活用できない。プロンプト計算とは異なり、トークン生成は最新GPUの計算能力を必要とせず、より低い電力・コストで実行できる。 > これらの知見に基づき、われわれはSplitwiseを提案する。これはLLM推論リクエストの2フェーズを別々のマシンに分割するモデルデプロイメント・スケジューリング手法である。Splitwiseは各フェーズに適したハードウェアを用いたフェーズ別の資源管理を可能にする。リクエスト状態は、今日のGPUクラスタで利用可能な高速バックプレーン相互接続上の最適化されたネットワークライブラリを用いてマシン間で効率的に転送される。Splitwiseを用いて、スループット・コスト・電力それぞれに最適化された同種・異種のLLM推論クラスタを設計する。既存の設計と比較して、Splitwiseクラスタは最大1.4倍高いスループットを20%低いコストで達成する。あるいは、同じ電力・コスト予算のもとで2.35倍多いスループットを提供できる。 ## 論文情報 - タイトル: Splitwise: Efficient Generative LLM Inference Using Phase Splitting - 著者: Pratyush Patel(University of Washington、Microsoftインターンとして一部実施)、Esha Choukse、Chaojie Zhang、Aashaka Shah、Íñigo Goiri、Saeed Maleki、Ricardo Bianchini(Microsoft Azure) - 媒体: 2024 ACM/IEEE 51st International Symposium on Computer Architecture (ISCA 2024) - arXiv ID: 2311.18677(v1: 2023-11-30、v2: 2024-05-20) - DOI: 10.1109/ISCA59077.2024.00019 - コード: [vLLM実装PR](https://github.com/vllm-project/vllm/pull/2809)、[SplitwiseSim](https://github.com/Mutinifni/splitwise-sim)、アーティファクト DOI: 10.5281/zenodo.11003049 - データ: [Azure LLM Inference Trace 2023](https://github.com/Azure/AzurePublicDataset) ## 概要 LLM推論の1リクエストはプロンプト計算(計算集約)とトークン生成(メモリ帯域・容量集約)という性質の異なる2フェーズからなるが、両者を同一マシンで混在バッチ実行すると資源利用が非効率になる。本論文はこの2フェーズを別マシンプールに分離し、フェーズごとに最適なハードウェアと資源管理を割り当てるSplitwiseを提案する。KVキャッシュはレイヤー単位でパイプライン転送することで分割コストをほぼ隠蔽し、Azureの実運用トレースに基づくクラスタシミュレーションで、既存の同種クラスタ設計に対しスループット・コスト・電力のいずれかの軸で明確な優位を示す。 ## 問題設定 LLM推論はトークンを逐次生成する自己回帰プロセスであり、1リクエストのフォワードパスは(1)全入力トークンを並列処理して最初の出力トークンとKVキャッシュを生成する**プロンプト計算フェーズ**と、(2)直前トークンとKVキャッシュを入力に1トークンずつ生成する**トークン生成フェーズ**に分かれる。 **Figure 1: LLM推論の例(プロンプトフェーズとトークン生成フェーズ)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig01-llm-inference-example.png]] (Fig. 1. "Is tomato a fruit?" という入力プロンプトに対し、プロンプトフェーズでKVキャッシュを生成した後、トークン生成フェーズが"Yes, it is"を1トークンずつ生成しEOSで終了する様子を示す。) プロンプトフェーズは高FLOPsを要する計算バウンドな処理である一方、トークン生成フェーズは並列性に乏しくメモリ帯域・容量バウンドになる。両フェーズを同一マシンで任意にバッチ実行すると、E2Eレイテンシが不安定になり、厳しいSLOを満たすためにGPUを過剰プロビジョニングせざるを得ない。さらにNVIDIA H100はA100比でTFLOPsが3.43倍・電力が1.75倍に増えた一方、HBM帯域は1.64倍にしか伸びておらず(Table I)、メモリ律速なトークン生成フェーズには最新GPUの計算能力が不要という資源のミスマッチが生じている。 ## 特性評価(Characterization) Azureの2つの実運用LLM推論サービス(coding・conversation、2023年11月11日の20分間トレース)を用いて、BLOOM-176B・Llama2-70BをvLLM上でDGX-A100/H100を用いて特性評価した。 **Figure 2: バッチング機構(request-level / continuous / mixed)がプロンプト・トークンフェーズのレイテンシに与える影響** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig02-batching-mechanisms.png]] (Fig. 2. request-levelバッチングは待機中リクエストのTTFT・E2Eレイテンシを悪化させ、continuousバッチングはプロンプトがトークンフェーズをプリエンプトしTBTのテールを悪化させ、mixedバッチングはプロンプト・トークンを同一イテレーションで混在実行してTBTへの影響を緩和する。以降の実験では特記なき限りmixedバッチングを用いる。) **Figure 3: プロンプト入力トークン数・生成出力トークン数の分布** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig03-prompt-output-length-dist.png]] (Fig. 3. codingサービスは入力プロンプト中央値1500トークンに対し出力は中央値13トークンと少なく、conversationサービスは入力中央値1020トークン・出力中央値129トークンとほぼ双峰分布を示す。**Insight I**: 推論サービスによってプロンプト・トークン分布は大きく異なる。) **Figure 4: 各バッチサイズでの実行時間の累積分布** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig04-active-batch-size-cdf.png]] (Fig. 4. mixed continuousバッチングでは、conversationの60〜70%の時間がアクティブトークン20個以下で実行され、codingはトークン生成フェーズの20%以上が単一トークンで実行される。**Insight II**: mixed continuousバッチングはトークンフェーズのアクティブトークン数がごく少ない状態で大半の時間を過ごす。) **Figure 5: BLOOM-176B・Llama-70BのTTFT・TBT・E2Eレイテンシ** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig05-ttft-tbt-e2e-latency.png]] (Fig. 5. TTFTはプロンプトトークン数にほぼ線形に増加する(計算バウンドのため)。TBTはバッチサイズ64でも2倍程度しか悪化しない。バッチ無しでのE2Eレイテンシは、BLOOM-176Bにおいてプロンプト1500トークンの処理時間が出力6トークンのトークンフェーズと同等であることを示す。**Insight III**: ほとんどのリクエストでE2E時間の大半はトークン生成フェーズが占める。) **Figure 6: バッチングがスループットに与える影響** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig06-throughput-batching.png]] (Fig. 6. プロンプトフェーズは2048トークンを超えるとスループットが低下するが、トークンフェーズはメモリ枯渇まで(バッチサイズ64まで)スループットが伸び続ける。**Insight IV**: プロンプトフェーズのバッチサイズは制限すべきだが、トークン生成フェーズのバッチングには欠点がない。) **Figure 7: バッチングに伴うメモリ使用量** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig07-memory-utilization.png]] (Fig. 7. バッチ内トークン数の増加に伴いKVキャッシュ用メモリ容量が増加する。**Insight V**: プロンプトフェーズのバッチングは計算バウンド、トークンフェーズはメモリ容量に律速される。) **Figure 8: バッチサイズを変えた際の最大・平均電力使用量(TDP正規化)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig08-power-utilization.png]] (Fig. 8. プロンプトフェーズはバッチサイズ増加とともに電力使用が増えるが、トークンフェーズの電力使用はバッチサイズによらずほぼ一定。**Insight VI**: プロンプトフェーズはGPUの電力予算を効率的に使うが、トークンフェーズは使わない。) **Figure 9: 電力キャップがプロンプト・トークン生成フェーズのレイテンシに与える影響** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig09-power-cap-latency.png]] (Fig. 9. プロンプトフェーズは電力キャップに強く敏感でレイテンシが急増するが、トークン生成フェーズは50%の電力キャップ(700W→350W)でもほとんどレイテンシに影響しない。) A100とH100の比較(Table IV)でも、TBTへの性能影響はTTFTより小さく、A100はH100よりコスト・エネルギー効率で優れる。**Insight VII**: トークン生成は計算能力の低いハードウェアでもPerf/W・Perf/$を改善できる。 ## 提案手法 - **アーキテクチャ**: Splitwiseは常時稼働する「プロンプトプール」「トークンプール」に加え、負荷変動を吸収する「混在プール(mixed pool)」の3種のマシンプールを維持する。新規リクエストはプロンプトマシンとトークンマシンのペアに割り当てられ、プロンプトマシンが最初のトークンとKVキャッシュを生成した後、KVキャッシュをトークンマシンへ転送してトークン生成を継続する。 **Figure 10: Splitwiseの高レベルシステム構成図** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig10-splitwise-system-diagram.png]] (Fig. 10. Cluster-Level Scheduler(CLS)がマシンプール管理とリクエストルーティングを担い、各マシンのMachine-Level Scheduler(MLS)がペンディングキューとバッチングを管理する。InfiniBand越しにKVキャッシュを転送する。) - **クラスタレベルスケジューリング(CLS)**: マシンをプロンプト・トークン・混在プールへ動的に配置する。リクエストルーティングにはJoin the Shortest Queue(JSQ、ペンディングトークン数基準)を用い、プロンプト・トークンマシンを同時に割り当ててKVキャッシュ転送とプロンプト計算をオーバーラップさせる。ペンディングキューが閾値を超えると混在プールのマシンを、さらに不足すれば反対プールのマシンを混在プールへ動員する。 - **マシンレベルスケジューリング(MLS)**: プロンプトマシンはFCFSでスケジュールし、複数プロンプトの合計バッチを2048トークンに制限する(Fig. 6の知見に基づく設定可能値)。トークンマシンはFCFSかつメモリ枯渇直前まで積極的にバッチする。混在マシンはTTFT SLOを守るためプロンプトを優先し、トークン生成をプリエンプトする(スタベーション防止のため年齢に応じた優先度上昇とプリエンプション回数制限あり)。 - **KVキャッシュ転送の最適化**: KVキャッシュ転送はSplitwiseの主要オーバーヘッドである。素朴な逐次転送(プロンプト完了後に一括転送)ではTBT・E2Eレイテンシに直接影響する。 **Figure 11: SplitwiseにおけるKVキャッシュ転送の最適化** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig11-kvcache-transfer-optimization.png]] (Fig. 11. (a)逐次転送はプロンプトフェーズ完了後に転送を開始しトークン生成を遅延させる。(b)レイヤー単位のパイプライン転送は、各レイヤーの計算完了ごとに非同期でKVキャッシュを転送し、プロンプト計算の裏で転送を隠蔽する。) 具体的には、GPU駆動の通信ライブラリMSCCL++のゼロコピー片方向putプリミティブを用い、InfiniBand上でレイヤーごとに非同期転送する。小さいプロンプトはKVキャッシュサイズが小さく逐次転送で十分なため、Splitwiseはプロンプトサイズに応じて逐次転送とレイヤー単位転送を使い分ける。 - **プロビジョニング**: マシン種別として、Splitwise-AA(A100/A100)、Splitwise-HH(H100/H100)、Splitwise-HA(H100プロンプト/A100トークン)、Splitwise-HHcap(H100/H100でトークンマシンを70%電力キャップ)の4構成を定義する。 **Figure 12: Splitwise-HHクラスタのプロビジョニング設計空間** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig12-provisioning-design-space.png]] (Fig. 12. codingワークロードにおけるプロンプト・トークンマシン台数の2次元探索空間。P50/P90/P99のTTFT・TBT・E2Eスローダウンをヒートマップ化し、70RPSの目標スループットを満たしコストが最小の(27プロンプト, 3トークン)構成を★で示す。イベント駆動シミュレータで台数を探索し、スループット・コスト・電力いずれかを最適化目標に選べる。) ## 新規性既存のヘテロジニアススケジューリング研究は、単一マシン上でハードウェア異種性を活かしつつコスト・エネルギー・性能をトレードオフするが、フェーズを跨いだワークロード全体を同一マシンで実行する前提だった。Orca等の混合バッチングを用いたモデルサービングシステムはバッチング・スケジューリング・メモリ利用を最適化してきたが、いずれもプロンプト計算とトークン生成を同一マシンで実行する点は共通していた。Splitwiseは、この2フェーズの資源特性差(計算バウンド vs メモリ帯域/容量バウンド)そのものを分割の軸とし、フェーズ単位でハードウェアを使い分ける点で異なる。KVキャッシュのレイヤー単位パイプライン転送により、分割のオーバーヘッドを実用上ほぼゼロに抑えている点も新規性である。 ## 実験設定 - **実験環境**: vLLMを改良したKVキャッシュ転送プロトタイプをMicrosoft Azure上のDGX-A100 2台・DGX-H100 2台(InfiniBand接続、H100は400Gbps・A100は200Gbps)で実行。 - **シミュレータ**: イベント駆動のSplitwiseSimを構築し、マシンプール・スケジューラ・メモリ・キュー・KVキャッシュ転送を忠実にモデル化。 **Figure 13: Splitwiseシミュレータの設計概要** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig13-simulator-design.png]] (Fig. 13. ハードウェアプロファイリングからLLM性能モデルとKVキャッシュ転送モデルを構築し、リクエストトレース・SLO・クラスタ/スケジューラ設定を入力にTTFT/TBT/E2E・利用率レベルを出力する。性能モデルは80:20のtrain:testで検証しMAPE 3%未満。) - **データセット**: Azure coding・conversationトレースのプロンプト・トークンサイズ分布を用い、Poisson到着率でリクエスト負荷を調整。 - **比較対象**: Baseline-A100(全A100の混在バッチング)、Baseline-H100(全H100の混在バッチング)。 - **評価指標**: Table VIのSLO定義(DGX-A100基準に対するスローダウン倍率、TTFT/TBT/E2EそれぞれP50/P90/P99の9指標すべてを満たすことを要求)。 ## 実験結果 **KVキャッシュ転送オーバーヘッド** **Figure 14: プロンプトサイズ増加に伴うKVキャッシュ転送レイテンシ** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig14-kvcache-transfer-latency.png]] (Fig. 14. 逐次転送はプロンプトサイズに線形増加するが、レイヤー単位転送はA100で約8ms・H100で約5msの一定オーバーヘッドに収まる(プロンプト計算時間比7%未満)。H100はA100の2倍の帯域のため転送も2倍速い。) **Figure 15: coding traceにおけるKVキャッシュ転送のTTFT・E2Eへの影響** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig15-kvcache-transfer-e2e-impact.png]] (Fig. 15. 逐次転送はE2Eの最大3%まで増加させるが、Splitwiseのレイヤー単位転送は0.8%に留まる。2番目のトークンへのレイテンシ影響は逐次転送の64%に対しSplitwiseは16.5%。ユーザー視点でのSplitwiseの転送オーバーヘッドはほぼ知覚不能。) **Iso-power・Iso-cost クラスタ比較** **Figure 16: iso-power スループット最適化クラスタの入力負荷別レイテンシ指標(coding/conversationトレース)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig16-latency-metrics-across-loads.png]] (Fig. 16. codingトレースではSplitwise-HH・HHcap・AAがBaseline-H100を上回り、負荷増加時はBaseline-H100が大きなプロンプトとの混合バッチによりTBTが悪化する。conversationトレースではトークン生成が長時間続くためSplitwise-HHcapが全指標で最良。混在プールがSplitwise-HAで高負荷時のTBT改善に寄与する(90RPS以降H100マシンが混在プールへ移動)。) **Figure 17: iso-power スループット最適化クラスタでのバッチトークン数の累積時間分布(低負荷70RPS・高負荷130RPS)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig17-batch-size-cdf-isopower.png]] (Fig. 17. 低負荷ではBaseline-H100機がトークン15個以下の実行に70%の時間を費やすのに対し、Splitwise-HHのプロンプトマシンはほぼアイドルで稼働時は大バッチを処理し、トークンマシンもより良いバッチングを行う。高負荷では混在プール利用が増えバッチサイズの差が縮小する。) **Figure 18: スループット最適化クラスタ設計の要約(iso-power/iso-cost)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig18-summary-throughput-optimized.png]] (Fig. 18. iso-power条件でSplitwise-AAはBaseline-A100比2.15倍のスループット(同電力・コスト)、Splitwise-HAは10%低コストで1.18倍のスループット。iso-cost条件ではSplitwise-AAがBaseline-H100比1.4倍のスループットを25%多い電力・2倍の設置面積で達成する。) **Figure 19: iso-throughput クラスタ設計の要約(電力最適化/コスト最適化)** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig19-summary-isothroughput.png]] (Fig. 19. Splitwise-HHcapは同一スループット・コスト・設置面積でBaseline-H100比25%低い電力を達成。コスト最適化ではSplitwise-AAがBaseline-H100と同一スループットを25%低コストで達成する。) **ワークロード変化への頑健性** **Figure 20: 異なるワークロード向けに設計されたクラスタでの実行によるレイテンシ影響** ![[_attachments/Splitwise--Efficient-Generative-LLM-Inference-Using-Phase-Splitting/fig20-workload-change-impact.png]] (Fig. 20. (a) coding向けに設計したクラスタでconversationトレースを実行しても、混在プールを持つSplitwise-AA/HHはスループット・レイテンシ低下がない一方、異種マシンのSplitwise-HA/HHcapは7%のスループット低下が生じる。(b) BLOOM-176B向けに設計したクラスタでLlama-70Bを実行すると、パラメータ数が少ないLlama-70Bはより高いスループットを支えられ、全Splitwise設計がBaselineを上回り続ける。) バッチジョブ向けの厳格なSLOなしクラスタでは、高負荷時にSplitwiseは混在プールへ収束しBaselineと同等のスループット/コスト(Splitwise-AA/Baseline-A100で0.89 RPS/$、Splitwise-HH/Baseline-H100で0.75 RPS/$)に落ち着く。 ## 考察 - Splitwiseはロスレスなキャッシュ転送のみを行い精度への影響はない。 - LLMリクエストは典型的なMLリクエストより長時間のため、同規模クラスタでのスケジューリングオーバーヘッドは相対的に小さいが、大規模クラスタではCLSがスケーラビリティのボトルネックになりうる(分割・複製スケジューリングの先行研究が緩和策になりうる)。 - 障害時はプロンプト/トークンマシンいずれの故障でもリクエストを最初からリスタートする(既存LLMサービングシステムと同様)。KVキャッシュのインメモリDB化によるチェックポイント・リカバリは今後の課題として本論文の範囲外とされる。 - Prefill-Decode分離という発想自体はMoEを含む現行・将来のあらゆる自己回帰型transformer LLMに適用可能とされる。 - H100-A100間のInfiniBand接続は一般的でないため、Splitwise-HAの実運用にはHPCクラウドのInfiniBand経由CPU接続やRoCE等の代替相互接続が必要になりうる。10倍低帯域の相互接続でも有効と推定されるが未検証。 ## 強み / 弱点・課題 **強み** - 実運用トレースに基づく丁寧な特性評価(Insight I〜VII)から設計原理を導出しており、根拠が明確。 - レイヤー単位パイプライン転送によりKVキャッシュ転送オーバーヘッドをE2Eの1%未満に抑制し、フェーズ分割の主要な懸念(転送コスト)を実証的に解消している。 - 混在プール機構により、ワークロード変化やモデル変更に対する頑健性を実測で示している。 **弱点・課題(論文が明示するもの)** - CLSの大規模クラスタでのスケーラビリティは今後の課題として残されている。 - 障害復旧はリクエスト全体の再実行のみで、KVキャッシュチェックポイントによる高速リカバリは範囲外。 - Splitwise-HAのような異種GPU混在データセンターは、クラウド事業者にとって運用上の複雑性増加という課題がある。 - 会話の文脈保持(将来的なマルチターンでのKVキャッシュ再利用)によりプロンプトフェーズのメモリ利用パターンが変わる可能性があり、その場合トークンマシンからプロンプトマシンへのKVキャッシュ逆転送が必要になりうる点は今後の検討課題としている。