llm-d、マルチテナントのトラフィック制御と安定版APIで分散推論の運用を強化する1.0を発表

llm-dプロジェクトは10月20日、1.0のリリースを発表しました。分散推論の焦点を、デプロイ後の運用へと移し、対話型リクエストと突発的なエージェントトラフィックを同じクラスターでどう処理するか、複数の推論コンポーネントのアップグレードをどう協調させるかに取り組みます。このKubernetesネイティブのオープンソーススタックは、vLLMやSGLangなどのエンジン上で動作し、レプリカ間のルーティングとリソース調整を担います。IBMのリリース説明によると、プレフィックスキャッシュルーティング、KVキャッシュのオフロード、prefill／decodeの分離といった技術はすでに存在しており、今回は統合と運用面の成熟度が強化されました。IBMのリリース説明

マルチテナント制御は、新版の実質的な変更点です。ルーターはテナントまたはワークロードIDと優先度に基づいてキューを作成し、優先度順にディスパッチしたうえで、同じ優先度のテナント間では公平に順番を割り当てます。バックエンドが飽和した場合、リクエストはルーティング層で待機できるため、大量の処理がモデルサーバーに先回りして流れ込むのを防げます。これにより対話型リクエストのレイテンシを守りやすくなりますが、デフォルトの挙動は依然として先着順に近く、デプロイ担当者がポリシーを明示的に有効化する必要があります。プロジェクトの技術発表

アップグレード関連では、Endpoint Pickerにホットスタンバイが加わりました。DisaggregatedSetは、プロンプト処理用レプリカとトークンを逐次生成するレプリカを一つの論理単位として扱い、バージョンと準備完了状態に基づいて互換性のある組み合わせを選びます。また、設定APIは安定版のv1に移行し、プラットフォームチームにとって、より明確な統合インターフェースが用意されました。プロジェクトの技術発表

エージェントアプリケーション向けのセッションルーティングでは、後続のリクエストをKVキャッシュが残っているレプリカへ優先的に送り、飽和した場合に再割り当てします。技術的な利点は、各ターンで同じコード、ドキュメント、履歴内容を再計算する量を減らせることです。ただし、実際の効果はコンテキストの再利用率と負荷分布に左右されます。IBMの技術解説

エンジニアリングチームは今後、混合トラフィックにおけるテールレイテンシと、アップグレード中のエラー率を検証する必要があります。公式ロードマップでは、アクティブ／アクティブのルーター、リクエストのフェイルオーバー、移行が今後の作業として挙げられています。そのため、「ゼロダウンタイム」という主張はデプロイ条件に応じてテストすべきであり、あらゆる障害シナリオにそのまま当てはめることはできません。プロジェクトの今後の計画