vLLM 0.31: マルチモーダルの資源方針を運用者の管理に置く

権限を配備側に残す

2026 年 10 月 5 日公開の vLLM v0.31.0 は、9 月 26 日に作成・merge された PR #58830 を挙げる。PR は既定 false の --trust-request-mm-kwargs gate を加えた。確認した online rendering と pooling/scoring の経路では、要求の mm_processor_kwargs または media_io_kwargs が空でなければ、flag なしに VLLMValidationError となる。作者はこれらが media loading と preprocessing の resource use を変え得ると説明し、server-level settings と offline LLM は変更なしとしている。

1. 1運用者: 配備時のメディア方針
2. 2server configuration
3. 3制限付きの既定値

1. 1client: text と media
2. 2確認済み request validator
3. 3空の kwargs は通常 validation へ

1. 1client: 空でない request kwargs
2. 2作者の test で validation rejection

1. 1信頼済み内部 client + 明示した server flag
2. 2別の試験で override の候補

これは権限の対応表であり、endpoint の網羅調査ではない。patch の test は既定拒否、opt-in 受理、CLI wiring、flash late-interaction の一経路を扱うが、本稿では実行していない。安全な media size、CVE、深刻度、model/backend の範囲、API 全体の境界は確定しない。repository code の Apache-2.0 表示と、weight、media、container、dataset の利用条件も別に扱う。security policy は報告を案内するもので、deployment の認証ではない。

v0.29–v0.30 の記事は runner と route の公開を扱った。本稿の問いは、到達を許された request の後に、誰が preprocessing の仕事を選べるかである。feature に別の frame count や processor setting が必要でも、まず承認済みの値を deployment manifest に置く。internal client は名前、subnet、成功した request ではなく、定義済みの identity と制約の組である。

有効化前に作るオフラインの拒否表

これは独自の未実行 N=1 演習である。vLLM を install せず、model を取得せず、server を起動せず、API request も送らない。隔離した試験環境に accelerator time を使わせる前に、受け入れ条件を書くための表である。

ケース	server flag	request fields	期待する分類
A	なし	両方 omitted または空	通常の request validation の候補
B	なし	空でない mm_processor_kwargs	request validation failure。field 名を記録
C	なし	空でない media_io_kwargs	request validation failure。field 名を記録
D	あり	承認済みの空でない override 一つ	信頼済み client の試験だけに進める候補

実際に隔離して実行するなら、v0.31.0 を pin し、解決した artifact digest、model revision、hardware/backend、listener、認証済み caller、server-level の media settings、要求する override 一つ、timeout と memory/CPU/GPU budget を記録する。まず B と C を行う。flag なしで override が受理される、拒否後に preprocessing が始まる、queue が制限されない、field ごとの診断がない場合は fixture の失敗とする。release、configuration、reverse proxy の request handling を調べ、第二の backend や permissive fallback を加えない。

D は自動的な合格ではない。定義済みの内部 identity、狭い許可値、cost limit が要る。許可された request でも大きな file を decode し、media I/O を待ち、processor state を確保し、model 固有の理由で失敗し得る。media と prompt は機密になり得るため、非機密の request metadata と resource counter だけを記録する。timeout や budget 超過は配備方針を絞る根拠であり、trust flag を有効なままにする根拠ではない。

系譜と判断の境界

2024 年 9 月 5 日の vLLM performance post は、API server の CPU work を inference engine から分離する設計を説明する。これは報告された性能設計であり、speed result の転用や 2026 年の client-authority gate を確定しない。要求権限の根拠は、9 月 26 日の PR と 10 月 5 日の release に限る。

API が、運用者の管理外にある caller から到達できるなら、この gate は default-deny の境界として採用する。明示的な opt-in を検討するのは、caller、許可する override、resource budget、診断経路を一緒に試験できるときだけである。本稿は benchmark、availability、CVE、endpoint の網羅、独立 security 検証を主張しない。fixture も未実行である。