GKE Inference Gatewayとllm-dによる推論負荷分散：4倍スループットを支えるキャッシュ親和性と適用条件

なぜ今か：LLMクラスタ推論における負荷の偏りとキャッシュの無駄

Kubernetesクラスタ内でサービスを公開する標準的な手段であるClusterIP Serviceは、クラスタ内部の仮想IP宛てのトラフィックをバックエンドのPod群へ転送するネットワーク層の機能です[1]。しかし、ZenteiQが比較対象としたClusterIPラウンドロビン構成では、推論エンジン内部のキュー負荷やKVキャッシュの局所性を考慮していません[1]。

LLM推論の処理時間は、プロンプトの複雑さや応答トークン長のばらつきによって、リクエストごとに大きく変動します[2]。ZenteiQの報告によれば、標準的なClusterIPのラウンドロビン構成ではvLLMのエンジンキューを把握できませんでした。そのため、長時間の推論を実行中のPodにも新たな要求が次々と送信され、近隣ノードに処理余力がある状況でも一部のPodにキューが集中していました[3]。

キャッシュ効率の面でも、大きな非効率が生じていました。ZenteiQが運用する生成バッチでは、各プロンプトの約70〜80%を共通の指示コンテキストやタスク仕様が占めていました[4, 5]。従来のラウンドロビンでは、同じ指示文を含むリクエストが複数のサービングインスタンスに無作為に分散されていました。その結果、各Podで共有プレフィックスを再計算する必要が生じ、アクセラレータメモリ上のウォームキャッシュを有効に再利用できませんでした[6]。

補足：KVキャッシュとは

LLMの推論処理で、過去に計算したトークンのKey（鍵）とValue（値）のテンソルをメモリ上に保持し、後続のトークン生成時に同じ計算を繰り返さずに済むようにするキャッシュ機構です。

計算資源の割り当てが固定された開発環境では、合成データの生成や検証に使うアクセラレータ時間が、そのまま基盤モデルの事前学習枠を圧迫します。推論処理の遅延によって、事前学習を担う複数ホストのクラスタがデータ待ちとなり、計画した学習ランの開始が遅れることもありました[7]。また、インフラの非効率を解消するために独自スケジューラを構築・保守すると、研究者が本来のモデル開発業務から離れる懸念も生じていました[7]。

何が変わるか：GKE Inference Gatewayとllm-dの連携アーキテクチャ

こうしたクラスタ推論特有の課題に対応するため、Google Cloudは「GKE Inference Gateway powered by llm-d」を提供しています。GKE Inference Gateway機能は追加料金なしで利用できます[8]。

Gateway Modeでは、GKE Inference GatewayはGKE Gateway（L7 Proxy）とllm-dのルーティング機能を組み合わせた、二段階の振り分けアーキテクチャを採用しています[9, 8]。

第一段階では、データプレーンを担うGKE Gatewayがクライアントから要求を受信し、リクエスト本文（JSON）からモデル識別子を抽出する「Body-Based Routing」を実行します[10]。抽出したモデル名を基に、Gateway APIのHTTPRouteリソースで定義されたルールに従って、転送先となるInferencePool（モデルプール）を特定します[11]。

第二段階では、ルーティング判断を担うEndpoint Picker（EPP）が、ext-proc（External Processor）プロトコルを介して特定されたInferencePool内で呼び出されます[9]。EPPはプール内の各モデルサーバPodからリアルタイムの負荷信号を取得し、待ちキュー長、KVキャッシュ使用率、プレフィックスキャッシュの一致度を評価します[12, 13]。負荷が低く、より長いプレフィックスが一致するPodに高いスコアを付与し、合計スコアが最も高いPodを選びます[14]。その後、GKE Gatewayが選ばれたモデルPodへ要求を直接転送します[9]。

補足：ext-procプロトコルとは

L7プロキシがEPPなどの外部サービスを呼び出し、ルーティング判断を委譲するためのプロトコルです。

各モデルPodでは、vLLMなどの推論エンジンが実際の推論処理を担当します。vLLM内部では、APIサーバープロセスがHTTP要求を受け付け、エンジンコアプロセスがPod内の生成要求をスケジューリングしてKVキャッシュを管理し、ワーカープロセスがモデル重みをメモリに読み込んでforward passを実行します[15]。llm-d Routerとモデルサーバは、OpenAI互換のHTTP APIおよび推論エンジンの標準メトリクスを介して通信します。公式資料では、vLLMとSGLangがサポート対象として明記されています[16]。

何が変わるか：prefixキャッシュと予測レイテンシによる高度な振り分け制御

入力長や応答長に大きなばらつきがあるワークロードでは、Podの待ちキューの深さ（queue depth）だけでは実際の処理負荷を十分に把握できません[17]。そこでGKE Inference Gatewayは、任意で利用できる予測レイテンシモード（predicted latency-based routing）を提供しています。このモードでは、KVキャッシュ利用率、キュー長、プレフィックス一致度、リクエスト特徴量を基に、初手トークン生成時間（TTFT: Time To First Token）とトークン間生成時間（TPOT: Time Per Output Token）を推計し、変化するPod負荷に追随します[17]。

llm-dのOptimized Baselineでは、まずプレフィックス一致の見込みが高いPod（sticky endpoint）に候補を絞り、その中から実行中のプリフィルトークン負荷（in-flight prefill token load）を基に転送先を選びます[18]。ただし、キャッシュを保持する特定のPodに負荷が集中すると、「saturation-aware override」が作動します。過負荷状態のPodではキャッシュ局所性を優先せず、他の利用可能なPodへトラフィックを逃がし、クラスタ全体のキュー詰まりを防ぎます[18]。

GKEの予測レイテンシモードでは、プレフィックス一致スコアが既定の閾値0.80を超えるPodを優先します[19]。この絞り込みを迂回する少数の探索リクエストも許容します。また、最もキャッシュが温まったPodの予測TTFTが、クラスタ全体で最も速いPodより既定の許容幅5,000ミリ秒を超えて遅くなると推計された場合は、キャッシュ親和性（affinity）を解除し、全候補Podから最も速く応答できるPodを選びます[19]。

プレフィックスキャッシュの追跡機構には、実装要件の異なる「近似方式」と「精密方式」の2種類があります[20, 21]。

項目	近似方式（Approximate）	精密方式（Precise）
追跡手法	ルーターが選択Podへ送信したプレフィックスのハッシュ値をルーター側インデックスに記録して再利用を推定[20]	推論サーバが発行するKVイベントをZMQ経由で受信し、常駐ブロックを索引と照合[20]
トークン照合単位	ハッシュ値による推計	リクエストをvLLM render endpointで字句解析して得る正確なトークンID[20]
外部依存インフラ	追加の外部依存なし（標準EPP配備のみで完結）[21]	vLLM render endpoint、ZeroMQ（ZMQ）接続設定が必要[21]
状態把握の特性	実サーバー上の実際のキャッシュ破棄（eviction）を直接検知する状態情報ではない[20]	サーバー上の常駐キャッシュブロック状態と厳密に同期[20]

何が変わるか：ZenteiQの「推論4倍」の達成条件と測定の限界

ZenteiQが報告した「推論4倍」は、本番クラスタで導入前後を比較した実測結果です。従来の標準的なClusterIPラウンドロビン構成と比べ、集約推論スループットは4.07倍に向上しました[22]。実数では、1,000アクセラレータ当たり毎秒16,964トークンから毎秒69,114トークンへの増加が記録されています[23]。同日公開のGoogle Cloud記事では、日次生成トークン容量が1,000 TPU v6eアクセラレータ当たり14.7億トークン/日から59.7億トークン/日に増加したと報告されています[24]。個別モデルプールでは3.5倍から5.5倍の向上が確認され、プレフィックスキャッシュのヒット率は14パーセントポイント上昇しました[25, 26]。

この大幅な性能向上を支えた前提として、対象ワークロードの特性が挙げられます。ZenteiQの科学的データ生成パイプラインでは、生成バッチ内の各プロンプトの約70〜80%が共通の指示コンテキストとタスク仕様で構成されていました[4]。同じ科学的指示文を持つリクエストを、ウォームキャッシュがあるノードへ集中して送れる運用だったため、プレフィックスキャッシュ局所性の効果が特に大きく表れた環境でした[6]。

公表された数値と確認できる仕様、未公表の項目を次の表に整理します[27]。

指標・項目	公表された数値・仕様	測定前提および非公表の事項
集約推論スループット	4.07倍（毎秒16,964トークンから毎秒69,114トークンへ増加）[28]	1,000アクセラレータ当たりの比較。測定窓の長さや反復回数は非開示[22]
日次生成トークン容量	14.7億から59.7億tokens/dayへ増加[29]	基準アクセラレータは1,000 TPU v6e。計測日・集計期間は非開示[30]
個別モデルプール倍率	3.5倍〜5.5倍の伸び[25]	プール別の絶対値や個別の測定単位は非開示[25]
プレフィックスキャッシュ	hit率が14パーセントポイント上昇[26]	各プロンプトの70〜80%が共通指示文脈[2]。導入前後の絶対hit率は非開示[26]
対象モデル規模	9Bおよび35Bパラメータモデルスケジュール[31]	generator・evaluator・guardrail各モデルのcheckpoint名や個別規模との対応は非開示[31]
品質検証プロセス	evaluatorによる採点と別ファミリによるguardrail検査[32]	定量的な品質スコア、採点基準、合格閾値、導入前後の品質比較は非開示[32]
推論クラスタ構成	vLLMを用いたマルチノードアクセラレータプール[33]	実測時の実チップ数、ノード数、Pod数、到着率、バッチング設定等は非開示[33]

ZenteiQの事例報告には、単一の実行（single run）の最中でもスループットが変動したと記されています。一方、比較対象期間の測定窓、反復回数、ウォームアップやキャッシュ状態の統制、レイテンシやエラー率、ばらつき指標などの詳細は開示されていません。そのため、測定窓などが非公表で、公開情報からは追試に必要な条件の一部を確認できません[34]。公表された4.07倍という倍率は、共通指示文脈が70〜80%を占める特定のバッチワークロードでクラスタ全体を測定した結果です。一般的なルーティングの効果や、モデルサーバー単体の推論性能が4倍になったことを示すものではありません[35]。

何が変わるか：モデル単体最適化や通常負荷分散との役割分担

大規模な推論環境の処理効率を高めるアプローチには、ネットワークレベルのトラフィック分配、モデル実行エンジン内部の計算最適化、推論ゲートウェイによる高度なルーティングという3つのレイヤーがあります。

通常のClusterIP Serviceは、クラスタ内の仮想IPを介してバックエンドPodへ通信を振り分ける、標準的なサービス／ネットワーク層の仕組みです[1]。要求パケットの均等分配を担い、推論エンジン内部のキューの深さやKVキャッシュの局所性といった推論特有の状態は考慮しません[1]。

これに対し、連続バッチング（Continuous Batching）、量子化（Quantization）、カーネル最適化などは、選定された個々のPod内で動作するモデル推論エンジン（vLLM等）の実行効率を高める技術です[36]。連続バッチングは複数要求の計算をまとめて実行してスループットを高めます。量子化は重みや活性値の精度を変更し、メモリ使用量や必要帯域を削減します。カーネル最適化はGPU/TPU上での演算を効率化します。これらの技術はPodの選択後にモデル実行へ直接働きかけ、主にPod単体の処理スループット、遅延、同時処理容量を改善します[36]。

GKE Inference Gateway powered by llm-dは、これらの技術と併用できる上位の制御レイヤーとして、Pod間の要求分配を担います[35]。リクエスト本文からモデル名を読み取って適切なInferencePoolを決め、EPPが各Podのキュー長、KVキャッシュ使用率、プレフィックス一致度を総合評価して転送先を選びます[11]。

比較項目	通常のClusterIP（L4負荷分散）	モデル単体の高速化技術（連続バッチング・量子化等）	GKE Inference Gateway powered by llm-d
動作レイヤー	Kubernetesネットワーク層（L4）[1]	Pod内部の推論エンジン層（vLLM等の内部実行）[36]	クラスタ規模のL7プロキシおよびルーティング拡張層[11]
主な最適化対象	仮想IP宛てパケットのPod均等分散[1]	行列演算の効率化、メモリ帯域・容量の削減、バッチ統合[36]	モデルプール選定、キュー平準化、プレフィックスキャッシュ親和性[11]
内部キュー・キャッシュの認識	認識しない（要求数ベース）[1]	自Pod内のKVキャッシュとスケジューリングを直接管理[36]	クラスタ内全Podのキュー深さ、KVキャッシュ利用率、prefix状態を評価[11]
主な効果の適用範囲	単純な接続分散による死活監視・基本疎通[1]	Pod単体の処理スループット・遅延・並行処理能力の向上[36]	クラスタ全体のスループット最大化とアクセラレータ資源の偏り解消[35]

誰に影響するか：合成データ生成などの適格ワークロードと開発パイプライン

ZenteiQの事例からは、共通の指示文脈があり要求ごとの計算量に幅があるワークロードで効果が期待されます。

ZenteiQが本番環境で運用しているのは、科学的シードからマルチステッププロンプトを構築し、generatorで推論トレース（reasoning trace）を生成した後、evaluatorモデルで採点し、別モデルファミリによるguardrail検査を行うバッチ合成データ生成パイプラインです。重複除去と検証を経たデータセット（verified dataset）をMaxText事前学習ジョブへ引き渡します[37]。この構成では、同じGKE Inference Gatewayが、generation、evaluation、guardrailという異なる役割を持つ複数のモデルプール宛てのリクエストを統括して処理しています[37]。

同社の報告では、事後学習（post-training RL）および自動数値ソルバー評価ループでの利用は、将来の計画として言及されています。導入済みとして稼働が確認されているのは、ソルバー検証問題を生成・評価・フィルタリングして事前学習データセットへ供給するパイプラインです[38]。

実務上、共通の指示文脈を含み、プロンプトの複雑さや応答長にばらつきがあるバッチ推論では、負荷平準化とプレフィックスキャッシュ局所性を両立する本技術の強みが最も発揮されると考えられます。特に、複数のモデルプールを横断する合成データ生成や検証データ生成が該当します[39]。多ターン対話や、同一文書を繰り返し参照するエージェントのツール呼び出しループのように、同じプレフィックスが伸長しながら反復送信されるワークロードとの親和性も期待されます[40]。ただし、効果を得るために必要な最低限のプレフィックス再利用率など、定量的な閾値は公開資料に示されていません[40]。

誰に影響するか：導入要件・運用コスト・監視管理の判断基準

本番クラスタへの導入を検討する際は、インフラストラクチャの前提要件、費用構造、運用上の管理項目を整理する必要があります。

インフラの前提条件として、GKE 1.32.3以降のAutopilotまたはStandardクラスタが必要です[41]。ネットワークはVPC-nativeクラスタであることが必須で、HttpLoadBalancingアドオンを有効にし、プロキシ専用サブネット（proxy-only subnet）を構成する必要があります[41]。利用できるGatewayClassは、リージョン内部向けロードバランサのgke-l7-rilbと、リージョン外部向けロードバランサのgke-l7-regional-external-managedの2種類です[41]。

Google Cloud側ではCompute Engine API、Kubernetes Engine API、Network Services APIを有効にする必要があり、セキュリティ機能のModel Armorも任意で併用できます[42]。Kubernetes環境では、Gateway API StandardのGatewayおよびHTTPRouteリソースを使い、推論管理用にGateway API Inference Extensionが提供するInferencePoolおよびInferenceObjective CRDを適用します[42]。このうちInferencePool v1リソースはGKE 1.34.0-gke.1626000以降で自動管理されますが、InferenceObjectiveはalpha APIとして別途管理する必要があります[42]。ハードウェアは任意のコンピュートファミリおよびアクセラレータを選択できます。llm-dの公式仕様では、任意のNVIDIA GPUと、GKE上で稼働するCloud TPU（v6e、v7）が対応ハードウェアとして挙げられています[43]。

GKE Inference Gateway powered by llm-dの機能自体に追加のライセンス費用は発生しません[44]。運用費用は基盤となるGoogle Cloudリソースの利用料で構成されます。具体的には、1クラスタ当たり毎時0.10米ドルのGKEクラスタ管理料、GPU/TPUを含むCompute Engineインスタンスのコンピュート費用、Cloud Load Balancingでのリクエスト・レスポンスのデータ処理料金、Cloud Monitoringなどの利用量に応じた観測性費用が見込まれます[44]。

運用状況の可視化に向けて、Google CloudはInference Gateway専用の事前構成済みCloud Monitoringダッシュボードを提供しています。このダッシュボードでは、InferencePool全体のリクエスト数とトークンスループット、レイテンシ、エラー率、キャッシュ利用状況を確認できます。また、各モデルサーバのKVキャッシュ利用率や待ちキュー長も一覧で監視できます[45]。

L7プロキシを独自に構築・保守する負担は解消されますが、CRDやInferencePool、HTTPRoute、EPPの構成管理、推論サーバとのメトリクス接続設定、キャッシュヒット率と負荷分散のバランス監視は引き続き必要です[46]。また、異なるモデルやアクセラレータを採用する場合、ピークプリフィルスループット値（peakPrefillThroughput）などのルーティングパラメータを実測に基づいて校正する作業が必要になることがあります[46]。