Prefix-Aware Routing(プレフィックスアウェアルーティング)とは

Prefix-Aware Routingとは、複数のLLMの推論サーバーのうち、同じプロンプト先頭部の計算結果を再利用しやすいサーバーへ依頼を振り分ける方式です。キャッシュが残る場所へ次の依頼を近づけ、最初の回答が出るまでの待ち時間と計算量を減らすことを狙います。

なぜ振り分け先で速さが変わる？

振り分け先で速さが変わるのは、なぜでしょうか？LLMが入力文を処理したときに生まれるのが、KVキャッシュという途中の計算結果です。複数の利用者が同じ長いシステム指示や例文から質問を始める場合、その先頭部分をすでに計算したサーバーへ送れば再計算を省けます。Prefix-Aware Routingは、依頼の先頭が過去の入力とどれだけ一致するかを手がかりに振り分け先を選ぶ仕組みです。

ただし、振り分け役を置くだけではキャッシュは生まれません。Ray公式ガイドは前提条件としてvLLMでAutomatic Prefix Caching（自動プレフィックスキャッシュ）を有効にしておくことを挙げ、これを設定しなければ振り分け役に効果は出ないと注意しています。加えて、複数の依頼に共通する先頭文が必要です。途中だけが同じ文章や、毎回まったく異なる短い依頼では効果が限られるでしょう。

負荷分散とどう両立する？

キャッシュの一致だけを優先すると、人気のある先頭文を持つ一台へ依頼が集中し、待ち行列が長くなる恐れがあります。Ray Serve LLMの実装は三段構えです。まず待ち行列の長さの差を見て、負荷が均衡しているかを判定します。均衡していれば先頭一致率で選ぶ段へ進み、一致率が10%以上なら最も一致するサーバーへ、10%未満ならあえてキャッシュ利用率が最も低いサーバーへ。過去の記録が無ければ通常の振り分けに戻ります。負荷が均衡していないと判定した場合は、キャッシュより負荷分散を優先する仕組みです。

ここで運用上の落とし穴があります。待ち行列の差をどこまで許すかを決めるしきい値（imbalanced_threshold）の既定値は「無限大」＝どれだけ差が開いても均衡とみなす設定だと、Ray公式ガイドは明記しています。つまり既定のままでは、負荷分散へ切り戻す安全弁は働きません。切り戻しを効かせたいなら、待ち行列の差を何件まで許すかを自分で決めて設定する必要があります。

つまりこれは、キャッシュ命中率だけを最大にする機能ではありません。再利用による節約と、特定サーバーへ集中させないことの折り合いを取る交通整理です。どこで折り合うかは、設定値を入れて初めて決まります。

導入効果をどう測る？

向いているのは、共通のシステムプロンプト、長い社内ルール、同じfew-shot例を多くの依頼で使うサービスです。導入前に、先頭部の一致率と長さを実ログから集計してください。個人情報や機密情報を比較用ログへ残す場合は、必要な範囲へ減らし、閲覧権限と保存期間も決めます。

評価では、キャッシュ命中率、最初の文字が返るまでの時間、待ち行列、サーバーごとの負荷を一緒に見ます。平均だけでなく、遅い側のリクエストがさらに遅くなっていないかも確認が必要です。キャッシュ命中率が上がっても利用者の待ち時間が減らなければ、運用上の目的は達成していません。

周辺技術を整理すると、再利用する中身がKVキャッシュ、先頭部の再利用がプレフィックスキャッシュ、複数の依頼をまとめて処理する方法が連続バッチングです。これらを推論エンジンとモデルサービングの全体設計の中で組み合わせます。

Prefix-Aware Routingに関するよくある質問

プロンプトの途中だけが同じ場合にも効きますか？

原則として効きません。再利用の単位は先頭から連続して一致する部分なので、共通の指示や例文を前にまとめる設計が必要です。

先頭部分の記録は、どんどん溜まっていきませんか？

Ray公式ガイドには古い記録を自動で捨てる設定（do_eviction）がありますが、既定では無効です。有効にすると、記録が40万文字を超えた時点で36万文字まで減らすといった条件で整理されます。長く動かすなら、記録量が増え続けないかを確認してください。

推論サーバーが1台だけでも導入する意味はありますか？

振り分け先が1台だけなら、このルーティング方式を選ぶ意味はほぼありません。まず推論エンジン側のプレフィックスキャッシュを有効にし、複数のサーバーへ分散するときに振り分け方式を検討します。