# Breaking the Ice: Analyzing Cold Start Latency in vLLM > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 3 (May 20 / Wed)、Research Track Oral "LLM Serving 2" セッション（09:45 PDT） > - **登壇者:** Huzaifa Shaaban Kabakibo (Paderborn University)、Animesh Trivedi (IBM Research Europe, Zurich)、Lin Wang (Paderborn University) > - **URL:** https://mlsys.org/virtual/2026/oral/3784 > - **OpenReview:** https://openreview.net/forum?id=eoEobeKTNZ > - **スライド:** https://mlsys.org/media/mlsys-2026/Slides/3784.pdf > - **Code:** https://github.com/upb-cn/vllm-startup-profiler > - **アーティファクトバッジ:** Artifacts Available v1.1 / Artifacts Evaluated Functional / Results Reproduced v1.1 > [!abstract] 概要（論文アブストラクト・忠実日本語訳） > スケーラブルな推論サービスが普及するにつれ、推論エンジンのコールドスタートレイテンシが重要になる。今日、vLLM は多くの推論ワークロードにおいて事実上の標準推論エンジンへと進化した。広く利用されているにもかかわらず、その複雑さと急速な進化により、vLLM エンジンの起動レイテンシに関する体系的な研究は行われてこなかった。V1 API や `torch.compile` の導入といった主要なアーキテクチャ革新のもとで、本論文では vLLM の起動レイテンシに関する初の詳細なパフォーマンス特性評価を提示する。起動プロセスを 6 つの基礎的ステップに分解し、このプロセスが主として CPU 律速であることを実証する。各ステップはモデルパラメータおよびシステムレベルパラメータに対して一貫した解釈可能なスケーリング傾向を示し、細粒度のレイテンシ帰属を可能にする。これらの知見に基づき、所与のハードウェア構成に対して vLLM の起動レイテンシを正確に予測する軽量な分析モデルを開発し、大規模推論環境におけるリソース計画のための実用的な指針を提供する。ベンチマークデータセット、分析ツール、予測スクリプトはすべて https://github.com/upb-cn/vllm-startup-profiler で公開されている。 ## 動機と問題設定 - LLM はファイナンス、コーディング、医療など多様な領域で広く利用されている。スケーラブルな展開には GPU リソースのプロビジョニングやリクエストスケジューリングなどの課題があり、サーバーレスコンピューティングが有力なパラダイムとして台頭している - サーバーレス環境ではユーザが関数をアップロードし、プロバイダがオートスケーリングを自動処理する。従量課金によりコストと運用の複雑さが低減される - **コールドスタートレイテンシ**が決定的な課題である。LLM リクエストはバースト的に到着し、クラウドプロバイダは頻繁に新規インスタンスを起動する必要がある。コールドスタートレイテンシはユーザリクエストから最初のトークン生成（TTFT）までの時間に直接影響する - 公開されている LLM 本番トレース（Microsoft Azure、Shanghai AI Lab、Mooncake AI、Alibaba）を分析した結果、リクエスト到着率のピーク対平均比が 2〜20 倍に達し、リソースプロビジョニングが困難であることが判明した - コールドスタートの全体は (1) コンテナ初期化 (2) ライブラリダウンロード (3) イメージプル (4) モデル取得 (5) エンジン起動の 5 段階からなる。本研究はこのうち **エンジン起動**（ステップ 5）に焦点を当てる ## 研究目標 本研究の 3 つの主要目標: 1. **エンドツーエンドの特性評価**: 起動プロセスを分解し、主要なパフォーマンスボトルネックを特定する。結果として 6 つの基礎的ステップに分解された 2. **依存関係の特定**: 各ステップをモデルパラメータおよびハードウェアパラメータに対応付け、線形関係を識別する。いくつかの例外を除き、各ステップはモデルパラメータと線形関係を示す 3. **CPU 対 GPU の律速判定**: 各ステップが CPU 律速か GPU 律速かを判定する。起動プロセスは**主として CPU 律速**であることが判明した ## 方法論の概要 方法論は 4 段階で構成される: 1. **起動プロセスの分解**: 初期化を 6 つの基礎的ステップに分解する 2. **パターンの特定**: モデルおよびシステムパラメータに対するトレンドを同定する 3. **ボトルネックの特性評価**: プロセスが主に CPU 律速であることを実証する 4. **予測器の構築**: 正確なレイテンシ予測のための軽量な分析モデルを開発する ## 課題 - vLLM の急速な進化と複雑化が一貫した分析を困難にしている。v0.3.1（2024年2月）から v0.11.0（2025年10月）までの約 1.5 年間で、OPT-6.7B モデルの起動時間は 7.9 秒から 36.41 秒まで 4 倍以上の変動を示す - v0.9 と v0.10 の間では 2 倍のレイテンシ削減も観測されており、体系的な理解の必要性を示す - ハードウェア（CPU、GPU、ストレージデバイス）とソフトウェア（フレームワーク、エコシステム、モデル）の異種性が分析を複雑にする ## 実験的発見プロセス ### 評価対象モデル 0.5B から 32B パラメータにわたる 22 種の LLM を体系的にテストした: - **モデルファミリ**: LLaMA、Falcon、Qwen、Mistral、GPT、DeepSeek、Yi、Gemma、Granite、OLMoE - **アテンション機構**: Full MHA、GQA、MQA、MLA - **アーキテクチャ**: 標準トランスフォーマーおよび MoE（Mixture of Experts） ### 実験環境 主要実験はノード n1（AMD EPYC 9354 (32C)、NVIDIA H100 NVL、DDR5 251GB、vLLM v0.10.1.1）で実施。GPU 比較には n1 上の L40S、CPU 比較にはノード n2（2x Intel Xeon Platinum 8568Y+ (2x48C)、H100、DDR5 2TB）を使用した。Python 3.11.2/3.12、CUDA 12.6/12.8、PyTorch 2.7.1+cu126 の環境である。全実験を 5 回繰り返し、平均値を報告している。 ## 6 つの基礎的ステップ Llama3.2-3B における起動レイテンシの内訳（合計 20.32 秒）を基準として、6 ステップの詳細を以下に述べる。 ### ステップ 1: フレームワークブートストラップ 4 つのサブステップからなる: 1. **プラットフォーム検出（Detect Platform）**: CUDA または CPU の実行環境を検出する（約 1.37 秒） 2. **依存関係インポート（LLM Imports）**: PyTorch、Transformers、トークナイザライブラリ、vLLM 固有プラグインをロードする（約 4.86 秒） 3. **モデルメタデータ取得（Get Model Info）**: モデル設定（`config.json`、`model_index.json`）とトークナイザメタデータを読み取る（約 0.92 秒） 4. **ワーカー初期化（Worker Initialization）**: Ray または Python マルチプロセシングでメインワーカーを生成し、プロセス間通信、共有メモリ、GPU コンテキストを設定する（約 1.66 秒） このステップは主に vLLM の実装に依存し、モデルによらず一定のレイテンシを示す。`Model_Class` メタデータのキャッシュなど最近の最適化により、Get Model Info サブステップは約 4.47 秒から約 0.12 秒に短縮された（ただし v0.11 で導入のため本実験では無効）。 **斜線ハッチ = CPU 律速**。フレームワークブートストラップの全サブステップは CPU 律速である。 ### ステップ 2: トークナイザ初期化 トークナイザの語彙ファイルと設定をメモリにロードし、内部トークナイゼーションロジックを構築する。 - 初期化時間はトークナイザサイズと**線形に**スケールする（PCC = 0.99） - トークナイザサイズは語彙サイズによって決定される - LLaMA 2-7B および Falcon-7B は小さいトークナイザ（1.8 MB / 2.7 MB）で 0.08 秒と高速。Llama3-3B は大きいトークナイザ（8.7 MB）で 0.29 秒を要する - Qwen シリーズはすべてトークナイザサイズ 6.8 MB を共有し、モデルサイズによらず同一の初期化時間（0.25 秒）を示す - トークナイゼーション方式（SentencePiece、BPE など）やエンコーディング形式（JSON 対バイナリ）の影響は軽微であり、ファイルサイズが支配的である **CPU 律速**。 ### ステップ 3: モデルロード モデル構造の初期化と事前学習済み重みの GPU メモリへの転送の 2 段階からなる。 - **モデル構造の初期化**: レイヤ、アテンションブロック、活性化関数を設定。モデルパラメータサイズに依存せず一貫して約 0.1 +/- 0.05 秒 - **重みロード**: チェックポイントファイルから事前学習済みパラメータを GPU メモリに転送。ロード時間はモデルパラメータ数と**線形に**スケールする（PCC = 1.00） - Qwen-1.8B や Llama3-3B など小型モデルは 0.5〜1 秒のロード時間。DeepSeek-V2-Lite-16B は約 5 秒に達する - FP16 形式では 1.8B パラメータのモデルは約 3.6 GB のデータを GPU メモリにロードする必要がある - 本実験ではウォーム Linux バッファキャッシュ環境（DRAM からの読み出し）で計測 **CPU 律速**（重みのシリアライゼーションと転送が律速）。 ### ステップ 4: Torch コンパイル v0.7.0 で導入された `torch.compile` ステップ。スループットを改善するが、起動レイテンシを大幅に増加させた。v0.7.0 導入前の vLLM 起動時間（OPT-6.7B）は 7.8〜13.26 秒であったが、導入後は 20.89〜36.41 秒に急増した。2 つのサブステップに分かれる: #### Dynamo バイトコード変換 Python バイトコードを実行時にキャプチャし、中間表現（IR）に変換する。各レイヤの演算（行列乗算、活性化関数、アテンションレイヤ）が個別の Python 呼び出しから静的な計算グラフに変換される。 - 変換時間はコンパイル済みグラフの合計サイズと線形関係にある（PCC = 0.96） - レイヤ数とレイヤごとの複雑さによって決定される。LLaMA 2-7B と LLaMA 2-13B はアーキテクチャが同一（類似の複雑さ）だが、レイヤ数の違い（32 対 40）により 4.86 秒対 5.97 秒 - Granite4.0-h-32B（865 KB グラフ）で 3.12 秒、Granite3.3-8B-Instruct（1374 KB グラフ）で 6.30 秒 #### コンパイル済みグラフのロード/保存 TorchInductor が IR グラフを最適化された低レベル GPU カーネルにコンパイルする。コンパイル済みアーティファクトはファイルシステムキャッシュに保存され、後続の起動で再コンパイルを省略可能にする。 - ロード時間はコンパイル済みグラフサイズと線形にスケールする（PCC = 0.95） - Qwen-MoE-14.3B（808 KB）で 2.89 秒から Yi-9B（1693 KB）で 5.66 秒 - 同一アーキテクチャ・同一レイヤ数のモデル（Qwen-4B と Qwen-14B）はパラメータ数が異なっても類似のロード時間を示す（4.55 秒対 4.69 秒） キャッシュ無効時（`VLLM_DISABLE_COMPILE_CACHE=1`）、グラフ保存時間は 11〜21 秒に増大する（キャッシュ有効時の 3〜6 秒と比較）。 **CPU 律速**（Dynamo 変換・グラフコンパイルともに）。 ### ステップ 5: KV キャッシュプロファイリング KV キャッシュに割り当てる最適な GPU メモリ量を決定するステップ。vLLM はダミーのフォワードパスを実行してピークメモリ使用量を計測し、残余のメモリを KV キャッシュに割り当てる。 - このステップでモデルの `forward()` 関数が初めて実行されるため、`torch.compile` が暗黙的にトリガーされる。正確なプロファイリング時間を得るため、`torch.compile` を明示的に無効化して計測 - `torch.compile` 無効化後のプロファイリング時間はトランスフォーマーモデルのパラメータサイズと線形にスケールする（PCC = 0.92） - Qwen-0.5B および Qwen-1.8B は約 0.67 秒。Qwen-14B は約 0.94 秒、DeepSeek-V2-Lite-16B は約 0.97 秒 - **MoE モデルは線形トレンドから逸脱する**。動的なエキスパートのアクティベーションとロードバランシング機構がプロファイリング時の複雑さを増大させるためである **GPU 律速**（ダミーフォワードパスを実行するため）。 ### ステップ 6: CUDA グラフキャプチャ 推論カーネルの実行（メモリ割り当て、アテンション計算、その他の CUDA 演算）を CUDA グラフに記録し、個別カーネルの再起動なしに効率的にリプレイする。これにより CPU-GPU 同期オーバーヘッドとカーネル起動レイテンシが大幅に削減される。 - キャプチャ時間はモデルサイズと線形にスケールする（PCC = 0.99）。Qwen-0.5B で 0.91 秒、Qwen-MoE-14.3B で 1.51 秒 - キャプチャ時間はバッチサイズ数とも線形にスケールする（PCC = 1.00）。グラフは各バッチサイズごとに個別にキャプチャされるため - Llama2-7B でバッチサイズ数 3 の場合 0.33 秒、60 の場合 1.80 秒 **GPU 律速**（ダミーフォワードパスの実行を伴うため）。 ## 起動プロセスの要約 | ステップ | パラメータ依存性 | 資源律速 | |---|---|---| | 1. フレームワークブートストラップ | モデルによらず一定 | CPU | | 2. トークナイザ初期化 | トークナイザサイズ（語彙サイズ） | CPU | | 3. モデルロード | モデルパラメータサイズ | CPU | | 4. Torch コンパイル | レイヤ数とレイヤ複雑性（コンパイル済みグラフサイズ） | CPU | | 5. KV キャッシュプロファイリング | モデルパラメータサイズ | GPU | | 6. CUDA グラフキャプチャ | モデルパラメータサイズ + バッチサイズ数 | GPU | Llama3.2-3B の場合（合計 20.32 秒）: フレームワークブートストラップ約 8.81 秒（Detect Platform 1.37 秒 + LLM Imports 4.86 秒 + Get Model Info 0.92 秒 + Worker Init 1.66 秒）、トークナイザ初期化、モデルロード 4.57 秒、Dynamo 変換 3.96 秒、コンパイル済みグラフロード 1.52 秒、KV キャッシュプロファイリング 1.00 秒、グラフキャプチャ 1.00 秒。**全 6 ステップのうち最後の 2 ステップのみが GPU 律速であり、起動プロセス全体は主に CPU 律速である。** ## CPU 対 GPU の律速分析 ### 異なる GPU での比較 H100 と L40S の間で 10 モデルにわたり各ステップの起動時間比を計測した。 - ほぼ全ステップで比率が 0.94〜1.00 に留まり、GPU を変更してもパフォーマンスゲインはほぼ無視できる - 唯一の例外は CUDA グラフキャプチャで、H100 で 1.2 倍の高速化を示す（フォワードパスが GPU 上で実行されるため） - H100 は L40S に対して大幅に高い理論スループットを持つが、起動時間には反映されない ### 異なる CPU での比較 AMD EPYC 9354 (n1) と Intel Xeon Platinum 8568Y+ (n3) を同一 H100 GPU で比較した。 - CPU の変更は GPU の変更よりも**顕著に**起動時間に影響する - 各ステップでのスピードアップが 0.90〜2.61 と大きく変動: - n3 は Tokenizer Init（1.45 倍）と Model Init（0.90 倍）で優位 - n1 は Graph Capturing（1.38 倍）と Dynamo Transform（1.32 倍）で優位 - CPU コアの利用率ヒートマップ（Qwen-4B、100 ms サンプリング間隔）では、起動プロセス中は常に少なくとも 1 コアが 100% で飽和しており、2 コア以上が同時に完全利用される局面はほとんどない。起動操作は逐次的であり、並列性が限定的であることを示す **結論: vLLM の起動プロセスは CPU 律速である。** ## ベンチマーク環境の影響 ### SSD の影響 SSD（4x PCIe 5.0 SSD、LVM ミラーリング RAID-0、読み取り 25 GB/s・書き込み 15 GB/s）からの直接ロードの影響を調査した。 - DRAM ベースラインとの比較で、有意な影響があるのはモデルロードステップのみで、SSD からのロードは約 0.5 倍に減速する - ただしモデルロードは全起動時間の約 7〜10% に過ぎないため、全体の起動時間の改善は 1.04 倍に留まる ### モデル重みのロード方式の影響 3 種のロード方式（Safetensors、CoreWeave Tensorizer、Run:ai Model Streamer）を比較した。 - Tensorizer が一貫して最低レイテンシを達成し、Safetensors の 53〜60% のロード時間 - Run:ai Model Streamer は I/O と GPU 転送のオーバーラップにより中程度の改善 - 重みロードは起動プロセスの数少ない I/O 依存コンポーネントであり、データストリーミングとデシリアライゼーションの最適化が有効 ### コンパイル済みグラフキャッシュの影響 `VLLM_DISABLE_COMPILE_CACHE=1` でキャッシュを無効化した場合: - グラフ保存時間が 11〜21 秒に増大（キャッシュ有効時の 3〜6 秒に対して） - コンパイルコストはコンパイル済みグラフサイズと線形にスケールする（PCC = 0.95） ## 分析的予測器 ### 設計原理 各起動ステップが対応するパラメータ（重みロードならモデルサイズ、コンパイルならグラフサイズなど）に対して近線形の依存関係を示すという知見を活用し、**ホワイトボックス分解型予測器**を設計した。各ステップに対して独立した軽量な線形回帰器を訓練する。 - モジュラー構造により解釈性を保持: 各パラメータの寄与がステップごとに明示される - 新しいモデルやハードウェアが利用可能になった際は、該当するステップ固有の回帰器のみを再訓練すれば良い - 非 MoE モデルを対象とする ### 検証 Table 1 の非 MoE モデルすべてを使用し、Falcon-11B、Gemma-7B、Mistral-7B、Llama3-3B、Qwen-7B を検証用に確保した。各モデルの起動プロセスを 5 回実行して平均化し、ステップ固有の予測器を訓練した。 - 平均二乗誤差（MSE）: 2.42 秒 - 最大誤差: Llama3-3B で 2.08 秒 - 検証結果（予測値 / 実測値）: - Falcon-11B: 31.33 秒 / 33.01 秒 - Mistral-7B: 24.53 秒 / 23.65 秒 - Gemma-7B: 21.91 秒 / 23.74 秒 - Llama3-3B: 21.54 秒 / 23.62 秒 - Qwen-7B: 23.81 秒 / 24.74 秒 - v0.11（2025年10月リリース）でも検証を実施し、MSE 2.62 秒と依然として高い精度を維持 予測器はスケジューリングやオートスケーリングの意思決定、vLLM のスリープモードにおける高速再初期化のパフォーマンス推定にも活用可能である。 ## 議論 ### ベンチマークの範囲 分散推論サービスにおけるコールドスタートレイテンシは (i) ネットワーク、リモートストレージ、コンテナ取得などの分散環境オーバーヘッド、(ii) PCIe 競合、OS スケジューリング、コンテナ初期化などのノードローカルなダイナミクス、(iii) 推論エンジン自体の起動の 3 要因の複合である。本研究は (iii) に焦点を当て、外部要因からのノイズを最小化した実験設計としている。3 要因すべてを統合したエンドツーエンドの特性評価は今後の課題である。 ### 洞察の持続性 vLLM は急速に進化するが、特定した 6 ステップは post-V1 リリースに共通するコア初期化ステージに対応し、コンテナ化された推論サービスの分析でも類似のフェーズが報告されている。2 種類の GPU、2 種類の CPU、22 モデル、複数バージョンの Python・PyTorch で一貫した結果が得られており、観察されたスケーリング傾向とステップレベルの挙動は特定のハードウェアやソフトウェアスタックに限定されない。 ### 線形性の仮定 予測器はモデルパラメータとステップレイテンシの線形関係を仮定する。経験的に大部分のステップで裏付けられるが、MoE や SSM-トランスフォーマーハイブリッド、拡散モデルでは非線形挙動が確認される。ただし現時点ではこれは KV キャッシュプロファイリングステップのみに限定される。 ### 計測ノイズ バックグラウンドプロセス、スケジューラ競合、NUMA 効果、vLLM の内部ロギング粒度（数百ミリ秒のオーダー）が計測誤差を生じうる。複数回の平均化により軽減しているが、微小な偏差は残りうる。 ## 結論・オープン課題 - vLLM の起動レイテンシに関する**初の体系的特性評価**を提示した。起動プロセスを 6 つの基礎的ステップに分解し、主要なボトルネックとそのモデル・ハードウェア構成への依存関係を定量化した - 起動レイテンシは**主に CPU 律速**であり、GPU パフォーマンスの影響は限定的である - 高い精度で起動レイテンシを推定する回帰ベースのモジュラー分析予測器を提案した（MSE 2.42 秒） ### 今後の方向性 - 実世界のサーバーレスオーケストレーションフレームワークへの予測器の統合（マルチテナント環境でのプロアクティブなコールドスタート緩和） - ステップごとの分解に基づく最適化の方向性: `torch.compile`、KV キャッシュプロファイリング、CUDA グラフキャプチャのオーバーラップまたは並列化 - 適応的かつスケーラブルで低レイテンシな LLM サービングシステムの実現に向けた起動レイテンシのさらなる削減