vLLM マルチテナント運用でTTFTが8倍化する原因と回避策

社内で複数のAIエージェント用途に共有LLM基盤を使っているなら、この話は無関係ではありません。
自社でvLLM（オープンソースの高速LLM推論エンジン）クラスタを運用し、財務分析・コンプライアンスチェック・コード生成など複数のエージェントワークロードを同居させているチームに向けた内容です。

単一用途でvLLMを検証したときは速かったのに、本番で複数エージェントを同居させた途端にレイテンシが暴れ出す、という現象が実測ベースで報告されています。
具体的には、Time-to-First-Token（TTFT、リクエストから最初のトークンが返るまでの時間）が250msから8,000ms超へ、実に30倍以上に悪化するケースです。
原因を理解したうえで、自分たちの構成がこの罠に該当するかを判断できるようにしておく価値があります。

なぜキャッシュが効かなくなるのか

vLLMの高速性を支えているのがPagedAttention（KVキャッシュをページ単位で管理する仕組み）です。
LLMは一度計算したプロンプトの中間結果（KVキャッシュ）を再利用することで、同じ接頭辞（プレフィックス）を持つリクエストを高速に処理できます。
たとえば共通のシステムプロンプトを使う10人のユーザーがいれば、GPUは最初の1回だけ重い計算をして、あとはキャッシュを使い回せます。

この仕組みは単一テナント（単一用途）であれば驚くほど機能します。
実測では専用ドメインでウォームキャッシュの状態だと、キャッシュヒット率96.4%、TTFTの中央値は210msという数字が出ています。

問題は、性質の異なるエージェントを同じGPUノードに無秩序に流し込んだときに起きます。
ロードバランサ（負荷分散装置）がラウンドロビン（順番に振り分ける方式）でリクエストを捌くと、3万トークン規模のシステムプロンプトを持つ財務分析エージェントの直後に、まったく別のSQLデバッグエージェントのリクエストが同じワーカーに着弾します。
するとGPUのVRAM（高帯域メモリ）上にあった前者のキャッシュページは、後者のプリフィル（プロンプトの事前計算）処理のために追い出されてしまいます。

これがKVキャッシュのスラッシング（キャッシュの奪い合いで有効活用できない状態）です。
実測データでは、100並列のアンマネージドなマルチテナントバーストでキャッシュヒット率が4.2%まで落ち込み、TTFTの99パーセンタイルが8,450msに達しています。
GPUの演算資源の69%が、新しいトークン生成ではなく同じ静的なツールスキーマの再計算に消費されている計算になります。

判断軸はどこに置くべきか

自分たちのvLLM構成がこの罠に該当するかどうかは、次の軸で確認できます。

コンテキスト対生成比率という軸がまず重要です。
エージェントが2万トークン超のドキュメントを読み込んで120トークンのJSON応答を返すような構成では、プリフィル処理がレスポンス時間の98%を占めるとされています。
入力が長く出力が短い用途ほど、キャッシュヒットの有無がレイテンシを支配します。

次にテナント間のプロンプト多様性です。
財務・コンプライアンス・コーディングのように、システムプロンプトの構造が大きく異なるエージェントを同じクラスタに混在させているかを確認してください。
プロンプトの先頭部分（プレフィックス）が揃っているほどキャッシュは効きやすく、バラバラなほど奪い合いが起きます。

3つ目はルーティング方式です。
NGINXやAWS ALBのような標準的なリバースプロキシで、接続数ベースやラウンドロビンの振り分けをそのまま使っているなら要注意です。
リクエストの中身（プロンプトの接頭辞）を見ずに振り分ける方式は、キャッシュ局所性を破壊する設計になっています。

最後にリトライの挙動も見落とせません。
TTFTが5,000msを超えてクライアント側のHTTPタイムアウトに達すると、オーケストレータが自動リトライをかけます。
これは3万トークンの巨大プロンプトをもう一度満杯のキューに投入する行為であり、障害を連鎖的に悪化させます。

ルーティング方式の比較

ケース別の推奨

単一用途でシステムプロンプトがほぼ固定、かつ同時接続が20〜40程度にとどまるなら、標準のラウンドロビンのままでも大きな問題にはなりにくい構成です。
まずは現状のvLLMのメトリクスエンドポイントでキャッシュヒット率とTTFTの分布を確認し、劣化の兆候がないかを見てください。

財務・コンプライアンス・コーディング支援のように性質の異なるエージェントを1つのGPUクラスタに同居させているなら、プレフィックスハッシュルーティングの導入を検討する価値があります。
リクエストのシステムプロンプト（またはその先頭部分）をハッシュ化し、同じハッシュ値を同じワーカーに固定的に送る仕組みです。
これにより、ワーカーごとに「得意なプロンプトパターン」が固定され、キャッシュの追い出しが起きにくくなります。

長文コンテキスト（2万トークン超）を扱うエージェントが混在する場合は、チャンクドプリフィル（長いプロンプトを分割して段階的に処理する方式）の併用も検討してください。
これは1つの巨大プロンプトの処理中に他の短いリクエストを割り込ませることができ、テールレイテンシの悪化を抑える効果が報告されています。

リトライストームが疑われる場合は、まずクライアント側のタイムアウト値とリトライ回数の設定を見直すのが先決です。
TTFTが悪化している最中に自動リトライで同じ巨大プロンプトを再投入する設計は、問題を倍加させるだけです。

あえて見送ってよい条件

同時接続数が常に数十程度で、エージェントの種類が1〜2種類に限られているなら、プレフィックスハッシュルーティングのような専用ゲートウェイを急いで導入する必然性は薄いといえます。
実装・運用コストが見合わない可能性があります。

また、そもそもエージェントごとに別々のvLLMインスタンス（別GPUノードやモデルレプリカ）を割り当てられる予算とハードウェアがあるなら、ルーティングの最適化より先に物理的な分離を検討する方がシンプルです。
共有を前提にした最適化は、共有せざるを得ない制約があるチーム向けの対策です。

次の一歩として確認すること

まず自分たちのvLLM環境で、Prometheusメトリクスなどからキャッシュヒット率とTTFTの50/99パーセンタイルを可視化してください。
ヒット率が90%台から大きく割り込んでいる時間帯があれば、マルチテナントの混在がボトルネックになっている可能性が高いです。

次に、現在のロードバランサ設定（NGINXやALBの振り分けロジック）がリクエストの中身を見ずに振り分けているかを確認してください。
もし見ていないなら、プレフィックスベースのルーティング層を前段に追加することが次の選択肢になります。

最後に、クライアント側のタイムアウトとリトライ設定を洗い出し、障害時に巨大プロンプトの再投入が連鎖していないかを点検してください。
この3点を順に確認するだけでも、スラッシングが起きているかどうかの当たりはつけられるはずです。