vLLM 0.29–0.30: ランナーのデフォルト変更を配信境界の変更として扱う

デフォルトも本番契約の一部である

2026年9月9日の vLLM v0.29.0 は、Model Runner V2 を全モデルのデフォルトにした。リリースノートには、V2 がまだ対応していない一部の ROCm モデルや機能では Model Runner V1 が使われ続けるとも書かれている。これは文書化された適用範囲であり、二つの配信設計を恒久的に併用する根拠ではない。現行リリースを採用する運用者は、対象モデルと設定で実際にどのランナーが起動するかを観測して記録し、意図しない状態なら黙って受け入れずに対象外として止める必要がある。

ランナーは速度だけに関係するものではない。メモリの振る舞い、対応するモデル経路、スケジューリング、失敗時に見える症状も変わり得る。v0.29.0 は待ち行列への投入制限も追加し、削除済み・非推奨の設定や起動経路も列挙している。更新後にプロセスが起動しただけでは十分ではない。古い環境変数が無視されているかもしれず、記録した対象と異なるバックエンドが選ばれているかもしれず、待ち行列が資源上限へ達した時に呼び出し元へ制御された拒否を返せないかもしれないからである。

1. 1リリースタグとイメージ digest
2. 2対象モデルとランナー
3. 3明示的な待ち行列制限

1. 1ルート一覧
2. 2ルートごとの許可または拒否
3. 3隔離フィクスチャ

1. 1実際のランナーと応答
2. 2固定したリリースを採用、または対象状態を拒否

リポジトリのコードに示されたライセンスは Apache-2.0 である。ただし、これはコードのライセンス表示であって、モデル、チェックポイント、コンテナ依存関係、入力データセットの利用条件を確定するものではない。配信を決める前に、それらを別々の成果物として記録する。

v0.30 は公開される面も変える

2026年9月22日公開の v0.30.0 は、内部実装だけを変えるリリースではない。通常の vllm serve では、--enable-scale-out を渡さない限り scale-out エンドポイントを登録しないと説明している。また、VLLM_ENABLE_SCALE_OUT_ENDPOINTS 環境変数による経路を削除し、ほかの削除済み・非推奨の設定を挙げ、モジュール形式の gRPC 起動を vllm serve --grpc へ移すとしている。

ここから生まれる確認質問は明確である。対象プロセスにどのルートが存在し、どの呼び出し元が各ルートへ到達してよいのか。プロセス全体に設定したキーから答えを推測してはいけない。以前の2026年8月26日公開の v0.28.0には、--api-key がすべてのエンドポイントを保護するわけではないという注意を文書へ追加したと書かれている。この歴史資料は今回の調査窓の外であり、v0.30.0 で新しく生まれた変更ではない。ルートごとの方針を別に調べる理由として扱い、ネットワーク配置、ゲートウェイ認可、アプリケーションの公開設定を一緒に確認する。意図したルートに認可の担当境界を確認できないなら、そのルートは利用可能にしない。

リポジトリの security policy は、脆弱性の私的な報告窓口とトリアージを案内している。疑わしい脆弱性の取り扱いには有用だが、配備を認証するものでも、到達可能な全エンドポイントを列挙するものでも、手元での認可検証を代替するものでもない。

採用前に実行するオフライン・フィクスチャ

ここで示すのは未実行の演習であり、vLLM の動作を確認済みと述べる手順ではない。隔離された機密データを含まない環境で、意図した固定済みリリース成果物を使う。最初に、リリースタグ、解決したイメージ digest またはパッケージ hash、モデル revision、ハードウェアとバックエンド、意図したランナー、ネットワーク listener、有効にする各ルートを書いた小さな manifest を作る。可変のイメージタグを、検証済み成果物の識別子にしてはいけない。

意図した設定だけを起動する。起動出力を保存し、実際に選ばれたランナーを特定する。次に、許可される代表リクエストを一つ送り、機密でないリクエスト metadata と結果の status だけを残す。続いて、文書化した小さな待ち行列上限を使って境界を試す。合格条件は速度の数値ではない。上限に達した時に、上限のある観測可能な応答を返すことである。

次にルート表を作る。発見した各ルートについて、許可されるべき呼び出し元を一つ、拒否されるべき呼び出し元を一つ試す。拒否されたリクエストは fail closed であるべきだ。モデル実行、部分的な管理操作、曖昧な成功応答を残してはならない。デフォルトで存在しない場合も含め、scale-out ルートを表に入れる。不在は意味のある観測結果である。予期せず成功するリクエストはフィクスチャの失敗であり、未審査の例外を増やす理由ではない。

最後に観測結果を manifest と照合する。古いランナーを互換経路として残さず、自動ロールバックに頼らず、文書化された例外を移行成功と呼ばない。意図した現行リリースを固定し、設定または認可境界を直し、対象状態が明確になるまで隔離フィクスチャを再実行する。本稿はベンチマークや安全性の結果を主張しない。リリースノートは保守者が説明する変更であり、この演習は運用者がなお集めるべき証拠を定めるものである。