NVIDIAの大規模言語モデル推論ツールが対応モデルを増やし、キャッシュ管理のPython実装を削除した。新モデルの導入を検討する開発者には選択肢が増えたが、既存の実装に依存するサービスは設定とイベント収集方法を点検する必要がある。

1. モデル対応と準備条件

2026年10月14日に公開された今回のプレリリース版は、PyTorchバックエンドにGLM-5.3-Flashを追加した。テキスト・画像・動画入力に対応する。公式の8ビット浮動小数点モデルの重みをそのまま使う方式だ。

モデル対応の変更案にあるデプロイガイドは、統合サービングにB200を4枚、入力処理と出力を別のワーカーに分ける分離型サービングに8枚を提示している。OSはLinuxで、CUDAドライバーは575以上が必要だ。

テキスト専用サービスは、同時にインストールされるTransformersライブラリで動作する。画像・動画入力には以下のインストールが必要だ。

  pip install "transformers==5.17.0"

コンテナーにはfla-coreとeinopsもインストールする必要がある。

動画のデコードには、さらにopencv-python-headlessが必要だ。

2. 速度の数値は試験条件の範囲内で読む

複数トークン予測は、次に来るトークンを複数先行して提案する方式だ。モデル対応PR #19136のデプロイガイドは、TensorRT LLM 1.3.0rc29とB200 4枚での測定結果を示している。

8ビットのFP8重みと16ビットのBF16キャッシュを使い、入力・出力の長さはそれぞれ1,024トークンだった。ランダム入力のシードは0で、確率が最も高いトークンを選び、終了トークンは無視した。同時リクエスト数の2倍でウォームアップした後、5倍のリクエストを送る測定を2回行った。予測トークンの採用率は人為的に固定していない。

同時リクエスト1件で、モデル計算と、入力に応じて選択的に働く下位ニューラルネットワークであるエキスパートモジュールをそれぞれ4枚に分散し、3トークンを予測した場合、ユーザー当たり毎秒389トークン、GPU当たり92トークンだった。同じ条件で予測を無効にすると、トークン当たり平均5.57ミリ秒、ユーザー当たり毎秒180トークンで、単一ユーザーの生成速度には約2.2倍の差があった。

同時リクエスト256件では、入力のどの部分を参照するかを計算するアテンション処理のリクエストを4つのGPUプロセスに分け、エキスパートモジュールも4枚に分散した。1トークン予測でGPU当たり毎秒2,735トークンを記録し、バッチ上限はプロセスごとに64だ。

ユーザー当たりの数値は最初のトークンの待ち時間を除くが、GPU当たりの数値は入力処理と最初のトークンの待ち時間を含む。この結果は試験した構成と同時リクエストの範囲内の値であり、最大スループットを実証した値ではない。

数学問題の評価では、推論モードで1,319問に対し、確率が最も高いトークンを選ぶ方式と出力上限4,096トークンを適用した場合、Hugging Face実装との正解率の差は0.08パーセントポイント以内だった。

3. キャッシュ管理の実装を1系統に絞る

KVキャッシュは、先に処理したトークンの計算結果を保存する領域だ。PR #19154は、これを管理するKVCacheManagerV2からPython実装を削除した。すでにデフォルトだった実装だけを残し、同じキー計算・データの追い出し・統計ロジックを2系統でそろえる負担を減らした。

Pythonから利用するパッケージ自体がなくなったわけではない。残るパッケージはC++で書かれた実装に接続して公開する。バックエンド選択用の環境変数とPython実装の高速化用ビルドオプションも削除されたため、これらを指定したデプロイ・ビルド手順は修正対象となる。

4. イベント収集は変更時点を区別する

削除PRは、キャッシュの変化を即座に送出していたPythonのストリーミング経路も廃止した。この変更ではkv_cache_config.kv_events_configは起動時に拒否され、代替はkv_cache_config.event_buffer_max_sizeでイベントを蓄積し、反復単位で取り出す経路となる。

ただし、最終リリースの一覧には、PR #19359によるC++のストリーミングイベント対応も別途掲載されている。削除PRだけで、今回のバージョンがストリーミング全体に非対応だとは断定できない。既存の設定と新たな経路の互換関係は、提供資料には示されていない。

5. 導入の利点と移行コスト

キャッシュ精度も選択の問題だ。8ビット浮動小数点キャッシュは、圧縮されたキー・値表現の保存容量を半分にする。ただし、選択したキャッシュ行を計算用の精度に変換した後、小さなまとまりで一時領域に移してアテンションを呼び出す処理を繰り返す。この追加処理により、大きな入力では最初のトークンの待ち時間が延び、入力スループットが低下する可能性がある。位置を探す索引と再帰計算の状態の精度は変わらない。

モデルの前半の計算を再利用するには、中間状態を定期的に保存する方針が必要だ。

GLM-5.3-Flashは、複数の候補を維持しながら回答を選ぶビーム探索には対応していない。

このリリースには、H100でモデル計算を2つのGPUに分ける構成であるテンソル並列度2でストリーミング・リモート実行処理を行う際、モデルオブジェクト間でプロセス通信用のワーカープールを再利用すると、初期化が停止する可能性があるという既知の問題もある。

保存された公式リリースノートは1.3までしか扱っていないため、リリース一覧と各PRを併せて読む必要がある。

今回のバージョンの要点はモデルの選択肢拡大と実装の簡素化であり、導入の判断は既存のキャッシュ設定を移行できるかまで確認した上で下すべきだ。