Triton 2.72、動的バッチ処理のスタベーションと応答順序を修正し、CUDA 13.4推論スタックへ移行

NVIDIAは8月31日、NGC 26.08コンテナに対応するTriton Inference Server 2.72.0をリリースした。今回の更新は新しい生成モデルを前面に押し出すものではなく、オンラインサービスの信頼性に直接影響するスケジューリングと状態報告の問題に対処している。動的バッチャーの`waiting_consumer_count`が実際の状態から徐々に乖離し、キューにリクエストが残っているにもかかわらず、スケジューラが処理を割り当てなくなる可能性があった。新版ではこのスタベーションを修正したため、動的バッチ処理と高並行トラフィックを利用するチームは、長時間のストレステストをアップグレード検証に組み込むべきだ。

`preserve_ordering`についても、計算完了後に割り当てるのではなく、リクエストがキューに入った時点で完了スロットを予約するよう変更され、クライアントが期待する出力順序が復元された。モデルのヘルスチェックでは、`TRITONSERVER_ServerModelIsReady`が「モデルが存在しない」以外の種類のエラーも返すようになり、解析に失敗したモデルも正しく`ready=false`と表示される。モデルのロードパスでは例外を捕捉し、`invalid_argument`と`out_of_range`を統一的に処理することで、不正なモデル設定がサーバーのライフサイクル全体に悪影響を及ぼすことを防ぎやすくなった。

組み込みデプロイ向けには、新たに追加されたC／Pythonログcallbackにより、Tritonのメッセージをアプリケーション既存のオブザーバビリティスタックへ直接送信できる。バックエンドの修正には、非バッチTensorRTモデルでのCUDA Graph実行、vLLMのJSON入力解析、ARM SBSA上でのOpenVINOモデル生成が含まれる。ビルドプロセスでは実験的なpresetファイルも読み込めるようになり、利用可能なメモリに応じて並列コンパイル数を制限できるため、ONNX RuntimeまたはOpenVINOバックエンドを独自にビルドする際のOOMリスクが軽減される。

26.08コンテナはTriton 2.72、CUDA 13.4.1、TensorRT 11.2.1.2を採用し、最低compute capabilityは7.5となる。アップグレード前に、ホストドライバとカスタムバックエンドのABIを確認する必要がある。注目すべき点として、このリリースではTensorRT-LLM backendコンテナが提供されていない。また、公式はvLLM v0 APIとRayに脆弱性があると警告しており、executorやホストが信頼できないネットワーク接続を受け入れないよう求めている。さらに、CuPyのマルチスレッドCUDA 13 Device APIや、明示的モデル制御下でのvLLM tensor parallelismなどにも既知の制限がある。そのため、回帰テストを省略してイメージをそのまま置き換えられる更新ではない。