言語モデルを提供する開発者向けのvLLMの新バージョンは、メモリ節約用キャッシュの対応範囲を広げ、モデルの応答を解釈する汎用パーサーを追加した。既存サービスの移行時には、性能改善だけでなく、ブラウザーのアクセス制限やリクエスト処理方式の変更も確認する必要がある。

1. NVFP4キャッシュの対応拡大と性能条件

キャッシュは、処理済みトークンの情報を保存して再利用する領域だ。これを少ないビット数で保存するNVFP4形式の対応範囲が広がった。

GPUアーキテクチャ系列のSM8xとSM12xでも、この形式を使える。

SM90にも対応し、SM12xでは処理済みの内容を利用して次のトークンを生成するデコード段階の専用経路にも適用される。対応範囲の拡大を、すべてのハードウェアでの既定値変更と捉えてはならない。

GLM-5.xはSM100で8ビット浮動小数点キャッシュを既定で使う。リリースノートはスループットが2.3~5.5%増加したと報告している([#60140](https://github.com/vllm-project/vllm/pull/60140), [#60281](https://github.com/vllm-project/vllm/pull/60281))。

SM90ではfp8_ds_mlaキャッシュ経路が追加された。

この経路では、GLM-5.3-Flashの出力スループットが最大31%増加したと報告している([#59246](https://github.com/vllm-project/vllm/pull/59246))。2つのスループット値の具体的な比較基準と負荷条件は原文にないため、それぞれ該当するモデル・ハードウェア経路で報告された改善値としてのみ見るべきだ。

AMD GPU向けの実行環境ROCmには、ultraquant_4bitという4ビットキャッシュが追加された。保存密度は8ビット浮動小数点キャッシュの約2倍だ([#57057](https://github.com/vllm-project/vllm/pull/57057))。前述のスループット値はモデルと経路が異なるため相互に比較できず、保存密度も処理速度とは別の指標だ。

2. 構造化された判断と汎用パーサー

新しいPOST /v1/systemoneは、構造化された状態に基づき、選択やスコアなどに関する質問に答えるAPIで、標準で提供される。リクエスト・レスポンスの例はリリースノートに示されていない。

hfパーサーは、保存されたモデルファイル内のresponse_templateを読み込む。応答形式の説明書をモデルと一緒に受け取るようなもので、これを提供するモデルには、ツール呼び出しや推論内容を解釈する専用パーサーが不要になる。

PythonとRustの両フロントエンドに対応する。ツール呼び出しには--tool-call-parser hf、推論には--reasoning-parser hfオプションでこのパーサーを選択する。

3. セキュリティ修正と入力制限

セキュリティ勧告3件に対応した。チャットテンプレートは実行前に検査し、実行時間を制限してリソース枯渇に対処する([Security #50300](https://github.com/vllm-project/vllm/pull/50300))。

ブラウザーの異なるオリジンからのアクセスを制御するCORSは、すべてのオリジンを既定では許可しなくなった。ブラウザークライアントを接続するには、許可するオリジンを別途指定する必要がある([Security #61009](https://github.com/vllm-project/vllm/pull/61009))。

信頼できない画像は、ピクセルで表現するラスター形式のみ許可する。このため、EPSとWMF形式は拒否される([Security #60022](https://github.com/vllm-project/vllm/pull/60022))。

画像・音声など複数種の入力を扱う共有メモリのマルチモーダルキャッシュでは、参照情報に偽造を検出する署名を付け、偽造された参照を拒否する([Security #59357](https://github.com/vllm-project/vllm/pull/59357))。

構造化出力用のJSONスキーマが64段階より深くネストされると、HTTP 400を返す。出力形式の規則を過度に深く積み重ねたリクエストを拒否するものだ([Security #60036](https://github.com/vllm-project/vllm/pull/60036))。

キャッシュ密度の向上と汎用パーサーは、メモリ活用とモデルごとの連携負担を改善する。一方、強化されたアクセス・入力制限は、既存のブラウザー接続や画像処理経路の修正コストにつながる可能性がある。

4. インストール環境と削除された機能

Python 3.10のサポートが終了し、最小バージョンは3.11になった。

CUDAのソースビルドにはGCC 13が必要で、要件を満たさないとビルドの初期段階で失敗する。

ビルド済みパッケージはCUDA 13.0を基準に、次のようにインストールする。

pip install vllm

torch.compileのコンパイル過程で、シーケンスを分割して並列処理するよう最適化する機能は削除された。ただし、モデル自体でシーケンスを分割して処理する並列化機能は維持される。

5. リクエストとレスポンスの互換性の変化

max_tokensは、コンテキストウィンドウ内で事前に予約する値ではなく、出力の上限になった。出力分の予約によって長い入力を拒否していた動作がなくなったのであり、モデルが受け付ける全体の長さが無制限になるわけではない([#57035](https://github.com/vllm-project/vllm/pull/57035))。

Responses APIの推論イベント名で分岐するクライアントは、受信コードを点検する必要がある([#59652](https://github.com/vllm-project/vllm/pull/59652))。

開始イベントはresponse.reasoning_part.addedからresponse.content_part.addedに変わった。

終了イベントはresponse.reasoning_part.doneからresponse.content_part.doneに変わった。

この際、part.type="reasoning_text"で推論内容を区別する。

今回のアップグレードは、キャッシュとパーサーの対応拡大を活用しつつ、セキュリティの既定値と既存リクエストの互換性を併せて点検する移行と捉えるべきだ。