8月17日、llm-d.aiが「Sticky Until Saturated: Token-Aware Routing in llm-d」と題した記事を公開した。LLM推論インフラにおけるKVキャッシュ効率とロードバランシングの二律背反を、「閾値付き粘着性（sticky until saturated）」という一貫した原則で解消するトークン認識ルーティング手法の詳細と、その設計思想が解説されている。
KVキャッシュ偏りとホットスポット問題を解く「飽和したら手放す」思想
LLM推論の分散サービングにおいて、ルーティングは見た目以上に難しい問題だ。単純なラウンドロビンではKVキャッシュのプレフィックスヒット率が上がらず、逆にキャッシュ親和性を優先しすぎると特定のエンドポイントにトラフィックが集中してホットスポットが生じる。
llm-dが今回デフォルト設定として採用したトークン認識ルーティング（Token-Aware Routing）は、この二律背反を「閾値付き粘着性（sticky until saturated）」という考え方で解消する。基本原則は単純だ：プレフィックスキャッシュが温まっているエンドポイントを優先するが、そのエンドポイントのトークン負荷が閾値τを超えたら親和性を捨てて負荷ベースでルーティングする。
ボトルネックに合わせた2つの構成
ワークロードのボトルネックに応じて、2つの「マッチング構成」を使い分ける。
| ボトルネック | 典型的なワークロード | 構成 |
|---|---|---|
| プレフィックス計算（Prefill） | 長いプロンプト、コード生成 | prefix-cache-affinity-filter + token-load-scorer |
| デコードスロット（Decode） | 短いプロンプト、長い出力 | prefix-cache-affinity-filter + active-request-scorer |
Prefill boundの場合、スコアリング式は以下だ：
score(endpoint) = current_uncached_in_flight(endpoint)
+ prompt_tokens × (1 - hit_rate(endpoint))
第2項が「このリクエストを割り当てた場合に増える未キャッシュ処理量」のルックアヘッド推定であり、キャッシュヒット率が高いエンドポイントほど有利になる設計になっている。
Decode boundの場合はactive-request-scorer、つまりアクティブなストリーム数をベースに負荷を測る。デコードフェーズではKVキャッシュ容量（スロット数）がボトルネックになるため、在飛行トークン数よりもリクエスト数そのものが制約を表す指標として機能する。
閾値τをハードウェアから導出する
この手法の肝は閾値τ（maxTokensInFlightPenalty）の設定だ。τを大きくしすぎると親和性を手放すタイミングが遅れてホットスポットが生じ、小さくしすぎるとキャッシュ効率が下がる。
llm-dはτを「1回のハードウェアキャリブレーション測定から閉形式で導出する」アプローチをとる：
τ = peakPrefillThroughput × maxTTFTPenaltyMs
Qwen3-32B / H100（max-num-batched-tokens=8192）でTTFT劣化許容値14秒の場合：
τ = 20480 tok/s × 14s = 286720
= 35 × 8192（最大バッチトークン数の35チャンク分）
この導出手順はキャリブレーションレシピとしてリポジトリに同梱されており、モデル・アクセラレータ別の設定マトリクスも公開されている。
ベンチマーク結果
実験環境はQwen3-32B × 10エンドポイント、各エンドポイントはTP=2（H100 × 2枚）、vLLM＋連続バッチング、GKE上でのKubernetesデプロイ。3種類のワークロードで評価した：
- code-generation（Prefill bound）：システムプロンプト3,000〜100,000トークン、平均55,000トークン
- reasoning（Decode bound）：250トークン共有システムプロンプト、平均8,000トークン出力
- b2b-saas（Prefill bound・病理的ケース）：150種類の6,000トークンシステムプロンプト × 5バリアント
結果として、マッチング構成はPrefill boundワークロードにおいてスループット指標でKubernetesのラウンドロビンの2〜3倍を達成しつつ、TTFTを動作範囲内に維持した。なお、この倍率はシステム全体の処理トークン数／秒（スループット絶対値）での比較であり、p50/p99レイテンシの詳細は元記事の図表を参照されたい。その他のワークロードでも同等以上の性能を示している。
ボトルネックが不明な場合の第3の選択肢
ワークロードのボトルネックが不明、あるいはトラフィックが高分散で動的に変化する場合向けに、latency-predictor構成も用意されている。各モデルサーバーのサイドカーとしてTTFT予測器をデプロイし、予測レイテンシをスコアリングに使う。設定はprefix-cache-affinity-filter (ttftSource=latencyPredictor, maxTTFTPenaltyMs=5000) + latency-scorer + weighted-random-picker。全ワークロードでラウンドロビンを上回る性能を示した。
ただし、この構成は予測器の初期学習コストと、サイドカーを各モデルサーバーに追加でデプロイする運用負荷を伴う。キャリブレーション1回で完結するマッチング構成と比べてセットアップが重くなるため、ボトルネックが明確な場合はマッチング構成を推奨している。
旧設計との決別：4信号ブレンドの問題
今回の変更で廃止されたデフォルト設定は、prefix-cache-scorer（重み3）+ queue-scorer（重み2）+ kv-cache-utilization-scorer（重み2）+ no-hit-lru-scorer（重み2）の4信号加重ブレンドだった。llm-dはこの設計の問題点を「挙動の予測が難しく、チューニングはさらに難しい」と明示している。信号数が増えるほど相互作用が複雑化し、オペレーターが「なぜこのルーティング判断をしたか」を事後に説明できなくなる。トークン認識ルーティングは1信号×1ボトルネック×1閾値という構造により、スケジューラの挙動を人間が読める（legible）ものにすることを設計目標に据えている。
この構成はすでにoptimized-baseline、agentic-serving、multimodal-serving、P/D-disaggregationの各ガイドでデフォルトとして採用されており、Google Cloud Vertex AI、Red Hat、Mistralの本番サービングフリートでも稼働中だ。
詳細はSticky Until Saturated: Token-Aware Routing in llm-dを参照していただきたい。
