AI・信頼性・評価

vLLMはモデル定義を機種別と機種非依存の二本に分け始めた

2026/10/7

🤖 AIが執筆しています

vLLM の作り手は、共通の定義とコンパイラに頼る形を改めると書く

vLLM は、LLM 推論のための推論エンジンをオープンソースで開発するプロジェクトである。LLM 推論は、大規模な言語モデル（LLM）で文章を生成する処理を指す。vLLM の開発者の Woosuk Kwon は、2026年5月に RFC #42770 を起票し、モデル定義の作り方を変えると提案した¹。この RFC は 2026年10月5日の時点で open であり、計画の一部はまだ実装されていない。

PyTorch のブログによれば、vLLM のモデル定義には現在、flat、legacy、transformers バックエンドの三種類がある²。legacy は、従来どおり全機種で一つの定義を共有する形を指す。transformers バックエンドは、Hugging Face が開発するモデル実装のライブラリ transformers のモデルを、vLLM から呼び出して動かす経路である。三種類の定義は、行列の掛け算を複数の GPU に分けて行う RowParallelLinear のような共通の層を使う²。CustomOp は、共通の層の中の演算を機種ごとに別の実装へ差し替える仕組みであり、PluggableLayer は層を外から差し替える仕組みである²。

これまでの vLLM は、モデルのコードを PyTorch の基本の演算だけで書き、速くする作業をコンパイラと CustomOp に任せてきた。PyTorch は、Meta を中心に開発される、深層学習の計算を書くためのライブラリである。torch.compile は PyTorch に組み込まれたコンパイラで、PyTorch のコードを機種向けの速いコードへ変換する。full-graph のコンパイルは、モデル全体の計算を一つのまとまりとして torch.compile にかけることを指す。この形では、演算の融合とカーネルの選択を、コンパイラと CustomOp が機種ごとに行っていた。カーネルは GPU の上で動く一つの計算のプログラムで、演算の融合は連続する複数の演算を一つのカーネルにまとめてメモリの読み書きを減らすことである。

RFC #42770 は、この形から三つの教訓を引き出している¹。

1. 作り手は演算の融合とカーネルの選択のためにモデルのコードを直接変えることをためらい、抽象とコンパイラの処理を積み重ねた。その結果、コードは中身が読み取りにくく、最適化しにくくなった。
2. 作り手は、どの機種でもよく動く一つのモデル定義を追ったが、機種ごとに適した融合の方法が違うので、各機種は自分用の実装から利益を得る。
3. AI のコーディングエージェント（言語モデルがコードを読み、書き、試験するまでを自動で進める道具）が手での融合とカーネルを書く作業を容易にし、エージェントは抽象の少ない生のモデルのコードで最もよく働く。

作り手は、性能と開発体験の二つの面から変更の理由を書く¹。性能の面では、最新の機種で最速を出すには手での最適化が要り、コンパイラによる最適化だけでは足りなかった。開発体験の面では、torch.compile は起動の時間を延ばし、コンパイラに固有の制約と読み取りにくさを開発者に課す。そのうえで作り手は、隣り合う演算を局所的に融合する用途には、効果があれば torch.compile を使い続けると書く¹。やめる対象は full-graph のコンパイルであり、torch.compile そのものは残る。

最新の GPU 向けには、機種ごとのディレクトリに手で融合を書いた定義を置く

RFC #42770 の新しい形では、モデルのコードを GPU の作り手ごとに分ける¹。RFC は例として、DeepSeek V4 の NVIDIA 向けの定義を models/deepseek_v4/nvidia/model.py に置く構成を示す¹。同じ場所には、その機種用のカーネルを置く kernels/ と、試験を置く tests/ が並ぶ¹。DeepSeek V4 は、DeepSeek が公開した大規模な言語モデルである。AMD の GPU 向けには、別の定義を別のディレクトリに置く。PyTorch のブログは、機種ごとに別に持ち、演算の融合をモデルのコードに直接書いた定義を「flat」モデルと呼ぶ²。

機種ごとに分けたことの利点として、作り手は三つを挙げる¹。各機種の定義は、ほかの機種の定義を壊すおそれなしに、それぞれの機種に合わせて変更できる。コードが生の形で書かれるので、AI のコーディングエージェントで最適化しやすい。モデルごと、機種ごとにファイルが分かれるので、使われなくなった古いモデルを削除しやすい。

この形は、すでに新しいモデルの標準になっている。PyTorch のブログは、最近の数か月に vLLM へ加わった新しいフロンティアのモデルは、すべて flat の定義を使うと書く²。フロンティアのモデルは、各社が公開する最先端の大規模な言語モデルを指す。新しいモデルを最新の GPU で使う利用者は、この変更から直接に速さの利益を受ける。

移植の側は、全機種で動く機種非依存の層を別に組む

機種ごとの定義に対して、同じプロジェクトの中から移植性を補う提案が出ている。Meta の Richard Zou は RFC #44219 を起票し、機種ごとの定義だけでは利用者全体に応えられないと述べた³。RFC #44219 は、別の機種への関心が利用者の間で大きいことを理由に、全モデルに機種非依存の定義を用意し、vLLM の中核のリポジトリでコミュニティが保守するよう求める³。2026年9月22日には、IBM、Meta、Hugging Face の開発者が、この方針の進み具合を PyTorch のブログで報告した²。著者は、IBM の Thomas Parnell と Thomas Ortner、Meta の Richard Zou、Hugging Face の Harry Mellor である。

PyTorch のブログは、機種非依存の層に四つの原則を置く²。

• コンパイル可能： 層は full-graph の torch.compile でコンパイルできる。
• 拡張可能： 各機種は、CustomOp と PluggableLayer で層の中身を自分の実装へ差し替えられる。
• 分離： 機種非依存の層は、機種ごとの経路の層と分ける。複数のモデルで共有する層は model_executor/hw_agnostic に、モデル固有の層は各モデルの場所に置く。
• 移植可能： 層は PyTorch の演算か、Triton や Helion で書くことを目指す。これらに対応しない機種は、拡張可能の項の差し替えに頼る。

Triton は、GPU のカーネルを Python に近い書き方で記述するための言語とコンパイラである。Helion は、PyTorch の開発者と Meta が開発する、機種非依存のカーネルを書くための DSL である⁴。DSL は、特定の用途に絞って作られた小さなプログラミング言語を指す。

作り手は、transformers バックエンドが使う層を、機種非依存の層へつなぎ替えた²。この対応は、一部の層について vLLM の main ブランチにすでに入っている²。利用者は、環境変数 USE_HW_AGNOSTIC=1 を設定し、—model-impl=transformers を付けて vLLM を起動すると、この経路を有効にできる²。作り手は、IBM のアクセラレータ IBM Spyre の上で、Gemma 4、Qwen3、Granite 4.2 のモデルが動くことを確かめたと報告する²。IBM Spyre の対応は OOT プラグインとして提供される。OOT プラグインは、vLLM の本体のリポジトリの外（out of tree）で開発し、特定の機種への対応を vLLM に足すプラグインである。

速さについて、作り手は自分の測定を一つ示す。NVIDIA の H100 で、transformers バックエンドの層を機種非依存の層に替えても、total token throughput は替える前のネイティブの実装との差が 3.4% 以内だった（最近の三つのモデルの幾何平均、作り手の測定）²。total token throughput は、入力と出力を合わせて 1 秒あたりに処理したトークンの数である。ネイティブの実装は、FlashAttention や CUTLASS のような CUDA 向けのライブラリを使う層を指す。この比較は transformers バックエンドの中で層だけを替えたもので、flat の定義との比較ではない。RFC #44219 は、transformers バックエンドそのものと通常の vLLM の間にも性能の差があると書く³。ただし作り手は、Blackwell や CDNA 4 のような最先端の GPU で最高の性能を出すことは、機種非依存の定義の目標ではないと明記する²。

カーネルの書き方の面でも、移植性と速さの両立が試されている。Red Hat と Meta の開発者は、2026年10月2日の PyTorch のブログで、Helion で vLLM の線形層を書いた試みを報告した⁴。作り手によれば、移植可能な Helion の書き方でも、NVIDIA の Hopper 世代の GPU で、評価した密なモデルと量子化の形式について vLLM の既定のバックエンドを一貫して上回った⁴。この結果は、トークン数 32 以下の形状だけを Helion で動かし、それより大きい形状は既定のカーネルに戻す振り分けで、形状ごとに調整した設定を使い、H100 の上で得られた⁴。同じ記事は、この書き方の代償も具体的に挙げている⁴。

二つの RFC と二つのブログ記事を並べると、vLLM は一つの定義で全機種の速さを狙う形をやめ、速さの経路と移植の経路を分けて持つ形へ移っている。flat の定義は最新の GPU での速さを受け持ち、機種非依存の層は古い GPU や独自のアクセラレータでモデルが動き続けることを受け持つ。本稿は、ここに挙げた数値と動作を作り手の報告に基づいて書いており、何も実行していない。

二本立てに残る代償

独自のアクセラレータの利用者には、モデル定義と層を自前で保守する負担がかかるおそれがある。PyTorch のブログによれば、機種ごとの定義が本流になると、OOT プラグインは自前のモデル定義と層を保守する負担に直面する見通しである²。同じ記事は、新しいモデルに対応するたびに、transformers と vLLM、場合によっては各プラグインへの変更の提案が要ると書く²。本稿は、機種ごとの定義を本流にする限りこの負担は恒久と判定し、機種非依存の層がその軽減を狙っていると見る。

古いモデルや利用の少ないモデルは、GPU の上で遅くなるおそれがある。PyTorch のブログによれば、古いモデルの定義は vLLM から削除されつつあり、transformers バックエンドへ移されている。コンパイルできる層が無いと、こうしたモデルの GPU での性能は大きく落ちる²。機種非依存の層がコンパイルできる層を用意すれば、この落ち込みは一時的に終わる。現時点で対応するのは一部の層だけであり、有効にするには USE_HW_AGNOSTIC=1 と —model-impl=transformers の指定が要る²。ブログとは別に、RFC #42770 は、移行で性能の後退を入れないと書き、古いモデルには CustomOp などの仕組みを残すと本文を改めた¹。

古い GPU と、消費者向けやプロシューマー向けの GPU は、flat の定義の対象に入らない見通しである。PyTorch のブログは、flat のモデルと層が最先端の GPU 向けに最適化され、こうした GPU への対応は見込んでいないと書く²。同じ記事は、vLLM の利用統計で、その種の機材を使う利用者がかなりの割合を占めるとも書く²。作り手が示したのは現在の見通しで、変える予定は書かれていない。本稿は、これを現時点の制約と判定する。

機種非依存の層は、まだ作業の途中にある。PyTorch のブログによれば、対応する層は限られ、flat のモデルごとに機種非依存の model.py を用意する作業は計画の段階で、まだ main に入っていない²。DeepSeek V4 の機種非依存の定義を足す変更は審査中で、継続的な自動試験（CI）への組み込みもこれからである²。作り手自身が作業中と書いており、進めば変わる性質なので、本稿は一時的と判定する。

Helion のような移植可能な DSL にも、調整と起動と保守の手間が残る。Helion の作り手は、細かな調整には数時間かかりうると書く⁴。vLLM の起動時に CUDA Graph を記録すると Helion の JIT コンパイルが走り、最初の起動が遅くなる⁴。CUDA Graph は、GPU に送る一連のカーネルの起動を記録し、まとめて再生する仕組みである。JIT コンパイルは、プログラムを実行する直前にコンパイルすることを指す。作り手によれば、この遅れは暖機後の起動ではキャッシュで大部分を取り除ける一方、CUDA Graph の外で動かすとカーネルの起動に CPU の負荷がかかる⁴。作り手は、線形層では Helion を CUDA Graph の再生の中だけで動かし、この負荷を避けている⁴。事前に調整した設定の保守も残り、作り手は現在、その設定を自分たちの vLLM のフォークで配っている⁴。作り手は、性能・使いやすさ・保守性の三つのうち二つを取ると三つ目が損なわれることが多い関係を、作業負荷ごとにカーネルを最適化すること自体に内在すると書く⁴。本稿は、作り手の記述に従い、この関係を恒久的なものとして扱う。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。