Ray 2.58、KV-cache／token-aware routingを完成。ただし新ルーターは依然alpha

Ray 2.58.0では、2.57でプレビューされたKV-cache／token-aware routingが、デプロイ可能な経路として完成した。従来はリクエスト数だけに基づいて振り分けていたため、再利用可能なプレフィックスを持つプロンプトが、対応するKV blockを保持していないGPUへ送られ、エンジンがprefillを再実行せざるを得ないことがあった。新設計では、`LLMRouter` ingressがまずエンジンと同じテンプレートを使ってトークン化し、その後、各レプリカに既存のKV overlap、未処理のprefill、実行中のdecodeワークロードを比較する。

レプリカは、vLLMのKV作成イベントとevictionイベントを通じてキャッシュ状態を報告し、Rayがそのイベントをすべてのingressへブロードキャストする。ルーターはCPUへオフロード済みのKV blockもヒット推定に含める。レプリカを選択すると、プロンプトtokenは独立したチャネルを通じてエンジンへ送られ、2回目のトークン化を回避する。これは、大規模なsystem prompt、few-shot example、長い会話プレフィックスを共有するエージェントサービスで特に有用だ。ヒット位置とキュー負荷を同じ判断の中で比較でき、session affinityだけを追求せずに済むためだ。

その代償として、ingressではトークン化とスコアリングを実行するための追加CPUリソースが必要になり、レプリカ間で結果整合性のあるキャッシュビューを維持しなければならない。高い並行処理負荷では、ingress replicaを増やす必要が生じる可能性もある。ドキュメントでは、KV-aware routerが依然alphaであり、direct streamingとNVIDIA Dynamo selection serviceを必要とすることも明記されている。単純でプレフィックス再利用率の低いトラフィックでは、調整のオーバーヘッドを相殺できない可能性がある。2.58では同時にvLLMが0.26.0へアップグレードされた。デプロイ担当者は、アーキテクチャだけからスループット向上を推定せず、実際のリクエスト分布をリプレイして、time to first token、KV cache hit rate、ingress CPU使用率を比較すべきだ。新バージョンには、実験的なgVisor Ray Sandboxも追加され、Serve replicaがtoken authenticationをバイパスする問題も修正された。したがって、アップグレード評価にはセキュリティと互換性も含める必要がある。