llm-d 1.0、多テナント推論スケジューリングを強化し、APIを安定化、アップグレード互換性を調整

llm-dのメンテナーチームは10月20日に1.0を発表し、分散推論の焦点をデプロイ後の継続的な運用へと移した。同じアクセラレーター群で複数のテナントにどう対応するか、エージェントのバーストリクエストをどう処理するか、更新中にどうサービスを維持するかが課題となる。プレフィックスキャッシュルーティング、KVキャッシュのオフロード、プリフィル／デコード分離はすでに提供されていた。今回の主な変更点は、これらの機能をより安定したスケジューリングおよび設定インターフェースに統合したことだ。公式発表

マルチテナント制御では、テナントまたはワークロードの識別子と優先度を組み合わせてトラフィックを分類し、それぞれにキューを設ける。スケジューラーはまず優先度に基づいて処理し、同じ優先度のテナント間では公平に順番を回す。バックエンドが飽和した場合、リクエストはルーティング層で待機でき、モデルサーバーへのリクエストの積み上がりを防ぐ。デプロイチームが注意すべき点は、デフォルトの動作が依然として先着順に近いことだ。テナントポリシーは明示的に設定する必要があり、アップグレードしてもサービスレベルの分離が自動的に構成されるわけではない。トラフィック制御の説明

エージェントサービスでは、セッション状態を利用し、後続のターンを関連するKVキャッシュがすでにあるレプリカへルーティングする。レプリカが飽和すると、リバランスが行われる。同じコード、ドキュメント、会話履歴を繰り返し参照するエージェントでは特に有用で、コンテキストを再計算する頻度を減らせる可能性がある。IBMの説明も、バージョンの価値は混合ワークロードへの対応と運用の成熟度にあると強調している。単一のキャッシュヒット率を、あらゆるアプリケーションにおけるコスト削減率と見なすことはできない。IBMの技術解説

移行に関しては、ルーターのEPPConfigとInferenceObjectiveがllm-d.ai/v1に引き上げられた。後者では、複数のリソースプールにまたがって目標を設定できる。旧リソースグループinference.networking.x-k8s.ioは削除され、inference.networking.k8s.ioへの切り替えが必要だ。また、一部のkvcache_*メトリクスエイリアスと、サイドカーの--vllm-portフラグも削除された。これらの変更は、デプロイマニフェスト、監視クエリ、起動スクリプトに影響する可能性がある。正式なリリースノート

エンジニアリングチームは次に、対話型リクエストとエージェントのバーストトラフィックを混在させて実測し、最初のトークンまでの遅延、テナントごとの待ち時間、キャッシュアフィニティによるホットスポットの有無を確認するとよい。アップグレードのリハーサルでは、プリフィルレプリカとデコードレプリカのバージョンの組み合わせも検証する必要がある。公式発表日は10月20日だが、ルーターコンポーネントのタグはそれより前の10月16日に公開されており、両者を同じリリース日時と見なすべきではない。