TensorRT-LLM 1.4候補版、KVキャッシュの既定値を変更

TensorRT-LLM 1.4.0 リリース候補には段階的なアップグレードが必要です

NVIDIA は、オープンソースの TensorRT-LLM「v1.4.0rc1」リリース候補を UTC 10 月 22 日に公開しました。リリース ノートでは、モデルのサポート、API の提供、KV キャッシュ管理、デコード パス、ハードウェア固有の最適化について説明します。リリース候補は、これらの変更のいずれかを必要とするチームにとって有用な統合ターゲットですが、広く証明された運用ビルドと同じではありません。メモ自体が既知の問題にフラグを立てます。 1 つは、A100 での分離型サービングとデフォルトの Python KV キャッシュ トランシーバーによるキャンセルされたストリーミング リクエストに関するものです。もう一つは、JSON スキーマ提供サンプルが Qwen3 モデルで無制限の出力を返すことができると述べています。これらの注意事項は、機能リストの背後に埋もれるのではなく、評価計画の一部として含める必要があります。

キャッシュのデフォルトは互換性の変更です

注では 2 つの API 変更が破壊的であるとマークされています。KV キャッシュ マネージャー V2 と Python KV キャッシュ トランシーバーがデフォルトになり、未使用の `LlmRequest` フィールドが削除されます。したがって、以前のバージョンからアップグレードされたサービスは、それ自体の構成ファイルが変更されていなくても、動作が変更される可能性があります。プリフィルとデコードの分離、キャンセル、または外部キャッシュ コネクタを使用するチームは、それらのパスを明示的にテストする必要があります。 NVIDIA は、KV キャッシュ マネージャー V2 用の Mooncake コネクタ、転送バックエンド用のレンディング API、ネイティブ KV イベント ストリーミング、およびルーティング負荷エクスポージャを追加します。これらは、ワークを配置し、ワーカー間で状態を移動する必要があるオペレーターにとって便利なプリミティブですが、リリース ページでは、すべてのトポロジでスループットの向上が証明されているわけではありません。

特定のキャンセルの問題は、隠れた状態遷移のリスクを示しています。クライアントは十分な出力を受信した後、ストリームを閉じることができます。サーバーにはまだキャッシュ状態があり、調整する転送作業が必要です。そのキャンセル後にトランシーバーが失敗した場合、後の世代のリクエストが影響を受ける可能性があります。制御された負荷テストでは、正常な完了と意図的なクライアントの切断を組み合わせ、エラー率とキャッシュのクリーンアップを検査し、展開を計画した同じハードウェアとサービス モードで繰り返す必要があります。単純な 1 リクエストのレイテンシ ベンチマークでは、この障害モードは見逃されます。この問題は A100 で観察されたものとして報告されているため、すべての GPU に共通であるとは言えません。

モデルと精度のサポートが拡大

このリリースでは、DeepSeek-V4.1-Flash および NVFP4 GLM-5.3-Flash チェックポイントのサポートに加え、Qwen3.8-Flash-Next NVFP4 の実験的な Modeling V2 ターゲットが追加されています。また、LiLiCorr の DFlash ドラフト チェックポイントについても言及し、Hopper 上の Nemotron-H NVFP4 のフォールバック動作を変更します。各エントリは、特定のモデル形式と実行パスの互換性を主張します。モデルの出力やパフォーマンスが精度全体で同一であるということではありません。チームは、正常なデプロイメントを置き換える前に、チェックポイントのライセンス、トークナイザー、チャット テンプレート、数値許容誤差、および代表的な出力品質を検証する必要があります。量子化により、特に長い出力や構造化された出力でのエッジケースの動作を変更しながら、メモリを削減したりスループットを向上させることができます。

NVIDIA は、NVFP4 コールド ページ圧縮における RoPE 精度、段階的に満たされるホスト キャッシュ層、およびキャッシュ V2 プールのリバランス パラメーターのオプションもリストしています。これらのノブは、GPU メモリ、ホスト メモリ、転送時間、応答遅延など、ビジーなサービング クラスターが直面するリソースのトレードオフを明らかにします。有用な測定では、同じプロンプト長分布の下で p50 とテール レイテンシを使用して、4 つすべてが報告されます。リリース ノートでは、Rubin のサポート、Blackwell CuTe DSL の動作、注目のバリアントなど、多くのハードウェア パスについて言及しています。これらは、対象のマシンでテストされるまでは、アーキテクチャ固有の開発として扱う必要があります。ある GPU ファミリに関する見出しを別の GPU ファミリの予算にコピーするべきではありません。

構造化された出力と決定論には独自のテストが必要です

Qwen3 の JSON スキーマ例の警告は、制限された機械可読応答を期待するエージェント システムにとって重要です。クライアントが無期限に待機したり、切り捨てられたオブジェクトを気付かずに受け入れたりできる場合、スキーマ機能は運用上役に立ちません。このリリースでは、決定論的な FP32 GVR V2 top-K デコーディングも追加され、特定のバッチ化されたサンプリング パスでリクエストごとのシードが尊重されます。決定的な動作の範囲は、これらの指定されたパスに限定されており、すべての分散実行でバイトごとに再現されるという包括的な約束ではありません。チームは、レスポンスキャップを設定し、解析された出力を検証し、モデルとデコード設定をログに記録し、運用環境で使用されている正確なバッチ計画に基づいて繰り返し実行を比較する必要があります。

10月25日時点での導入判断

現在のスタックが安定しており、新しいモデルやキャッシュ機能が必要ない場合は、リリース候補を評価対象のままにすることができます。必要なチェックポイントまたはコネクタで必要な場合は、分離されたサービスでアップグレードを段階的に実行し、キャンセル、プレフィル/デコード転送、構造化出力、品質およびリソースの使用をカバーする前後のプロファイルを収集します。構成とキャッシュの動作について、テスト済みのダウングレード パスを保持します。これは公表された変更点と問題点のリストからの編集上の推奨事項であり、候補者がどこでも安全ではないという主張ではありません。 10 月 25 日のダイジェストでは、10 月 22 日のオリジナル リリースが制限付きでそのまま表示されます。最終的な 1.4.0 の可用性は暗示されません。