【ITニュース解説】The KV-Cache Thrashing Trap: Why Multi-Tenant vLLM Suffers Spikes

近年、AI技術の発展は目覚ましく、特に大規模言語モデル（LLM）は私たちの仕事や生活に大きな変革をもたらしつつある。多くの企業が、クラウドサービスの利用コストやセキュリティへの懸念から、自社内にLLMを運用するプライベートAIインフラの構築に乗り出している。NVIDIA H100のような高性能なGPUサーバーを導入し、vLLM、TensorRT-LLM、SGLangといった推論エンジンを使って、自前のLLMサービスを提供しようとしているのだ。

これらの推論エンジンは、「PagedAttention」や「自動プレフィックスキャッシング」といった革新的な技術を取り入れており、単一のユーザーが利用する環境（シングルテナント）では驚くほど高速な応答を実現する。例えば、複数のユーザーが共通のシステムプロンプト（AIへの指示の最初の部分）を使う場合、GPUはそのプロンプトに対応する計算結果（キー・バリューテンソル）を一度だけ行い、キャッシュ（一時保存場所）に記憶する。これにより、二度目以降の同様のリクエストでは、わずか200ミリ秒程度の速さで応答を返すことが可能になる。これはまさに魔法のように感じられるだろう。

しかし、複数の部署や異なる種類のAIエージェント（金融アナリスト、コンプライアンスチェッカー、プログラミングアシスタントなど）が、同じ共有のLLMクラスターを同時に利用するマルチテナント環境では、事態は一変する。このような環境で「KV-キャッシュスラッシング」という深刻な問題が発生し、推論の性能が劇的に悪化することが明らかになっている。

KV-キャッシュスラッシングとは、GPUの高速メモリ（VRAM）上で発生する推論のボトルネックだ。LLMが次の単語を生成する際、過去に生成された単語やプロンプト（指示文）の内容を「KV-キャッシュ」という一時的な記憶領域に保存している。これにより、モデルは会話の文脈を記憶し、効率的に次の単語を予測できる。特に、プロンプトの最初の部分（プレフィックス）の計算結果は「プレフィックスブロック」としてキャッシュされることで、繰り返し使われるプロンプトの再計算を省ける。

KV-キャッシュスラッシングは、異なるテナントからのリクエストが、ランダムに複数のGPUワーカーに分配されることで発生する。例えば、あるGPUワーカーが30,000トークンもの長い金融アナリストのエージェントからのリクエストを処理し、そのプレフィックスブロックをキャッシュする。しかしその直後、別の28,000トークンのSQLデバッガーエージェントからのリクエストが同じワーカーに送られると、新しいプロンプトのプレフィックスブロックを保存するために、以前の金融アナリストのキャッシュがGPUメモリから追い出されてしまう。

このような状況が頻繁に繰り返されると、キャッシュがほとんど役に立たなくなり、「キャッシュヒット率」（キャッシュから目的のデータが見つかる割合）が95%からほぼゼロにまで落ち込む。その結果、AIが最初のトークンを生成するまでの時間（Time-to-First-Token, TTFT）が250ミリ秒から8,000ミリ秒以上へと大幅に跳ね上がる。これは、高価なGPUの計算コアが、新しいトークンの生成ではなく、すでに一度計算したはずのプロンプトの計算を何度もやり直すことに時間を使ってしまうためだ。結果として、GPUの計算リソースの利用効率も大幅に低下し、システム全体の処理能力が落ちる。

このような問題は、従来のウェブサービスの負荷分散手法をLLMクラスターにそのまま適用することで引き起こされる、主に三つのアーキテクチャ上の落とし穴が原因だ。

一つ目は「素朴なラウンドロビン負荷分散」である。標準的なリバースプロキシやロードバランサーは、入ってくるリクエストを順番に（ラウンドロビンで）GPUワーカーに振り分ける。しかし、異なるエージェントからのリクエストが次々と同じワーカーに送られると、先にキャッシュされた情報がすぐに追い出され、どのエージェントも毎回最悪の性能でプロンプトの事前計算（プレフィル）を強いられる。

二つ目は「高いコンテキスト対完了比率」だ。現代のエンタープライズ向けAIエージェントは、25,000トークンの大量の文書を読み込ませて、わずか120トークンの短いJSON形式の応答を生成するといった、非常に長い入力と短い出力というパターンが多い。KVキャッシュがヒットしない場合、この長いプロンプトの事前計算にかかる時間が、応答時間の98%以上を占めてしまう。

三つ目は「カスケードリトライストーム」だ。最初のトークンが出るまでの時間が5,000ミリ秒（5秒）を超えると、多くのクライアントアプリケーションはHTTPゲートウェイのタイムアウトエラーを出す。すると、クライアント側のシステムが自動的にリクエストを再試行するため、さらに大量の30,000トークンにも及ぶプロンプトが飽和状態のLLMクラスターに送り込まれ、システム全体の麻痺を悪化させる悪循環に陥る。

これらの問題を解決し、マルチテナント環境での遅延スパイクをなくすためには、リクエストを単に接続数に基づいてルーティングするのではなく、「トークンプレフィックスの同一性」に基づいてルーティングする必要がある。

Logic42が提案する解決策は、「決定論的プレフィックスハッシュルーティングとチャンクされたプレフィル」というアーキテクチャだ。これは、入ってくるシステムプロンプトのプレフィックス（冒頭の共通部分）をハッシュ化し、そのハッシュ値に基づいて、同じプレフィックスを持つリクエストが常に同じGPUワーカーに送られるようにする、インテリジェントな推論ゲートウェイプロキシを導入するものである。これにより、GPUワーカーのKVキャッシュが特定のプレフィックスの計算結果を「温かいまま」（つまり頻繁に再利用される状態）保持できるようになり、キャッシュヒット率が90%以上に改善される。

このアプローチをさらに強化し、高スループットなモデルサービングを実現するためには、三つのルールを実践することが重要だ。

一つ目は「一貫したプレフィックスハッシュの導入」だ。これは、上述したように、システム指示やRAG（Retrieval Augmented Generation）の文書テンプレートなど、共通のプレフィックスを持つすべてのリクエストを同じGPUワーカーにルーティングすることを意味する。これにより、キャッシュが頻繁に活用され、高いキャッシュヒット率を維持できる。

二つ目は「vLLMでのチャンクされたプレフィルの有効化」だ。これは、vLLMの設定で、プロンプトの事前計算（計算負荷が高い処理）と、すでに進行中のトークン生成（メモリ帯域幅が重要になる処理）を交互に実行できるようにする機能だ。これにより、長いプロンプトの処理中に既存のトークン生成の流れが一時停止することなく、効率的にGPUリソースを利用できる。

三つ目は「デコードワーカーとプレフィルワーカーの分離」だ。大規模なエンタープライズ環境では、LLMクラスターを二つの異なる役割を持つノードに分割することが有効だ。一つは計算量の多いプロンプトの事前計算（プレフィル）を専門とするノード、もう一つはメモリ帯域幅を多く使うトークン生成（デコード）を専門とするノードである。このように役割を分けることで、異なる処理が互いに干渉し合うのを防ぎ、全体としてのスループットと応答速度を向上させることが可能になる。

結論として、プライベートGPUクラスターで大規模言語モデルを運用する際には、KV-キャッシュの割り当てと管理を適切に行わないと、深刻な遅延劣化に見舞われることになる。エージェントアプリケーションがエンタープライズ規模で秒未満の応答速度を提供するためには、このような決定論的なモデルゲートウェイを自社のインフラストラクチャ内に設計し、導入することが不可欠である。