vLLM 0.30.0、GPU常駐の重みキャッシュを導入　エンジン再起動後も再利用可能に

vLLMは9月22日に0.30.0をリリースし、Fast Start重みキャッシュ機構を導入した。モデルの重みのライフサイクルを推論エンジンから切り離し、GPUごとに独立した常駐プロセスが、量子化処理とテンソル並列の分割を終えた重みを保持する。エンジンは再起動時にその重みに再接続する。リリース告知には、FP4チェックポイントと複数ノードでのテンソル並列への対応も記載されている。[リリース告知](https://github.com/vllm-project/vllm/releases/tag/v0.30.0)

この設計は、サービス再起動時に重みを繰り返し読み込むコストの削減を狙う。実装では、ローカルのUnixソケットを通じてCUDA IPCハンドルを渡し、新しいエンジンが既存のGPUメモリをマッピングできるようにする。起動時に`--load-format ipc_cache`を指定すると利用できる。同じモデルの重みを使い続けながらサービス設定を繰り返し調整する環境では、ディスク読み込みを減らす手段となる。[実装提案](https://github.com/vllm-project/vllm/pull/54921)

ローダーはまずmetaデバイス上にモデルの骨格を作成し、パラメータとバッファをキャッシュ済みテンソルに置き換えることで、重み読み込み後の処理を省略する。デフォルトの`zero_copy`モードは常駐プロセスのGPUメモリを共有する。一方、`copy`モードはエンジン自身のメモリに重みをコピーした後、キャッシュの解放を要求する。両者ではメモリの所有権が異なるため、障害復旧とGPUメモリの容量計画もそれぞれ検証する必要がある。[ローダーのドキュメント](https://docs.vllm.ai/en/v0.30.0/api/vllm/model_executor/model_loader/weight_cache/ipc_loader/)

対応する構成には制約がある。常駐プロセスはテンソル並列とエキスパート並列に対応するが、パイプライン並列とデータ並列の構成は起動時に拒否する。複数ノードへのデプロイでは、各ノードでプロセスを起動し、グローバルなテンソル並列グループを協調させる必要がある。IPCハンドルは引き続きノード内でのみ使用され、各エンジンのワーカープロセスはローカルGPUの重みシャードを取得する。[デプロイのドキュメント](https://docs.vllm.ai/en/v0.30.0/api/vllm/model_executor/model_loader/weight_cache/daemon/)

また、キャッシュプロセスに接続できない場合や設定のフィンガープリントが一致しない場合、デフォルトではディスクからの読み込みにフォールバックする。サービスが起動できたからといって、キャッシュがヒットしたとは限らない。ゼロコピーモードは、CuMemAllocatorを使って重みをオフロードするsleep modeとも併用できず、既存のGPUメモリ節約手順を再確認する必要がある。[互換性の説明](https://docs.vllm.ai/en/v0.30.0/api/vllm/model_executor/model_loader/weight_cache/ipc_loader/)

アーキテクチャから推測すると、効果は重みを同じGPU群に保持し続けられるかどうかと、従来の起動時間に占める重み読み込みの割合に左右される。エンジニアリングチームは、キャッシュヒット、ディスクへのフォールバック、常駐プロセスの再起動を個別に測定し、サービスが利用可能になるまでの時間、最初のリクエストのレイテンシ、GPUメモリ使用量のピークを記録すべきだ。モデルの重み以外にも、サービスはスケジューリングや通信などの実行状態を構築する必要がある。運用上の中断時間が短縮されたかを判断するには、初期化全体を測定対象に含めなければならない。告知では、幅広い環境に適用できるFast Startの高速化倍率は示されておらず、通常の生成スループットが向上すると推定することもできない。