半導体チップとデータセンターをつなぐ青い抽象ビジュアル
NAW / COMPUTE 06

IMAGE: AI生成ビジュアル

COMPUTE / Infrastructure

vLLM v0.29.0公開 — Model Runner V2が全モデルの既定に、新モデル対応とRL重み同期を強化

高性能LLMサービングエンジンvLLMが安定版v0.29.0を公開。594コミット・277名が参加し、Model Runner V2の全モデル既定化、Tencent Hy4-previewやQwen3.8-Flash-Nextなど新モデル対応、RL向け重み同期バックエンド、Mambaのprefix caching改善、10件の非推奨アーキテクチャ削除などの破壊的変更を含む。

vLLMプロジェクトは2026年9月9日(UTC)、LLM推論サービングエンジン「vLLM」の最新安定版 v0.29.0 を公開した。GitHub Releasesで発表された正式リリース(prerelease・draftではない)で、594コミット・277名のコントリビューター(うち91名が新規参加)による大規模アップデートとなる。前版v0.28.0(本サイト既報)から約2週間でのマイナーリリースで、実行エンジンの既定構成の切り替えと新モデル対応が中心だ。

Model Runner V2が全モデルで既定化、新モデル対応も拡充

今回の最大の変更は、実行エンジン「Model Runner V2(MRV2)」が全モデルで既定になったことだ。

  • Model Runner V2の既定化: プーリングモデルから始まった移行が完了し、すべてのモデルでMRV2が既定に。CUDAグラフのメモリプロファイリングによるKVキャッシュ自動サイジング、バッチ分散サンプリングによるlogitsメモリ削減、prompt embeds、extract_hidden_states による投機機能などが含まれる。MRV1は、MRV2が未対応の機能や一部のROCmモデル向けに残る。
  • 新モデル対応: Tencentの770B/49B-active MoE「Hy4-preview」(Gated DeepSeek Sparse AttentionとネイティブMTP付き)、「Qwen3.8-Flash-Next」(BF16/FP8/NVFP4とMTP)、「GraniteSWA」「GraniteMoeSWA」、「NemotronH_Omni_Reasoning_V3」、Kimi K3のNVFP4チェックポイントなどを新たにサポート。
  • モデリング基盤の整理: FlexOlmo、Olmo3、Hunyuan V1/VLをTransformersモデリングバックエンドへ移行。LoRAはDeepSeek V4やQwen3-OmniのマルチモーダルLoRAなどに対応した。

いずれもプロジェクト側の実装報告であり、性能数値は特定のモデル・ハードウェア・バッチ条件での公称値として扱い、導入前の再現評価が推奨される。

推論性能と学習連携:Kimi-K3/DeepSeek V4、投機的デコーディング、RL重み同期

主要モデルの最適化と、強化学習ワークフローとの連携強化も含まれる。

  • Kimi-K3とDeepSeek V4の性能改善: K3向けのfused MXFP4 top-k確定処理(E2Eレイテンシ約5%改善と報告)、Mamba関連メタデータ準備の単一Triton起動化、Hopper向け低遅延GEMMの調整とSM100への展開、MLAゲートのQKV-A投影への融合、DeepSeek V4の共有エキスパート融合(MegaMoE)などを実施。
  • 投機的デコーディング: リクエスト単位の採択率統計をOpenAI互換APIの応答に含めるオプション、適応的検証のlogprobsへの拡張、SM100向けsparse MLA対応、Qwen3-OmniのDSparkドラフト、PLaMo3のEAGLE-3/DFlash対応などを追加。
  • RL向け重み同期: 各ワーカーがTP/EPスライスのみを取得する新しいsharded_rdt P2Pバックエンド(NIXLまたはRay Direct Transport経由)、ランクローカルIPCによる重み更新、ネイティブ重みローダー経由のスパースなチェックポイント座標更新などを導入。
  • Mambaのprefix caching: 内部prefillチェックポイントによりTTFTが9%〜25%改善したと報告。prefix_cache_retention_interval がCLI引数化された。
  • 新しい既定値: TP CUDAグループでFlashInfer all-reduceが既定で有効に、prefixキャッシュのハッシュが既定で決定的に(分散KVキャッシュ利用時のPYTHONHASHSEED固定が不要に)、キュー admission control用の--max-num-queued-reqs--max-num-queued-tokens フラグを新設。

破壊的変更と互換性:移行時の注意点

本番運用中の環境では、以下の破壊的変更の確認が必要だ。

  • 破壊的変更: 非推奨だったモデルアーキテクチャ10件を削除。FlexOlmo・Olmo3・Hunyuan V1/VLはTransformersバックエンドへ移行。PyAV動画デコーダーバックエンドを削除。python -m vllm.entrypoints.openai.api_server での起動は非推奨となり、vllm serve の利用が推奨される。
  • API互換の拡充: Anthropic Messages API向けの/v1/messages/render、Cohere向け/cohere/v2/chat/render を新設。OpenAI互換側ではlogprobs=-1 対応、ストリーミングlogprobオフセット、ツール呼び出し引数の防御的パースなどを改善。
  • ハードウェア別: NVIDIA(Blackwell/SM100系の最適化、Rubin向けDockerのオプトイン提供)、AMD ROCm(デュアルストリームデコード、W4A4プリシャッフルGEMMの既定化など)、Intel XPU、CPU(AMX向けMLAバックエンド)それぞれの更新を含む。

アップグレード時は、削除されたアーキテクチャや起動方法への依存がないか、既定値変更(FlashInfer all-reduce、ハッシュ決定性、キュー制御)が既存のチューニングと競合しないかを事前に確認したい。

出典

掲載内容は公開時点の情報に基づきます。重要な判断では、一次情報と最新の提供条件をあわせてご確認ください。