ネイティブ速度の vLLM トランスフォーマーモデルバックエンド
Hugging Face は、vLLM を活用したネイティブ速度のトランスフォーマーモデルバックエンドを発表し、推論パフォーマンスとデプロイ効率を大幅に向上させた。
キーポイント
vLLM のネイティブ統合による高速化
Hugging Face が vLLM の高度な最適化技術（PagedAttention など）をバックエンドに直接組み込み、従来の推論速度を劇的に向上させた。
トランスフォーマーモデルのデプロイ効率向上
複雑なモデルアーキテクチャでも低遅延で高スループットな実行が可能になり、実環境での導入ハードルが低下した。
オープンソースエコシステムの強化
Hugging Face が持つ大規模なモデルライブラリと、vLLM の推論エンジンが連携することで、開発者にとっての利便性が飛躍的に高まった。
影響分析・編集コメントを表示
影響分析
この発表は、大規模言語モデルの実用化において最大の課題の一つであった「推論速度」と「スケーラビリティ」を解決する重要な転換点となります。開発者は複雑なインフラ構築の負担から解放され、より迅速にプロダクション環境へモデルを展開できるようになります。これにより、AI アプリケーションの普及スピードが加速し、コスト効率の良い大規模サービスの実現が現実味を帯びてきます。
編集コメント
Hugging Face が持つモデルの豊富さと、vLLM の推論エンジン技術が融合した今回の発表は、実務レベルでの LLM 導入を加速させる決定的な一手と言えます。特にコスト対効果を重視する企業にとって、即座に検討すべき重要な技術的進展です。
TL;DR: transformers の vLLM バックエンドは、多くの大規模言語モデル（LLM）アーキテクチャにおいて、カスタム vLLM 実装と同等かそれ以上の速度を達成しています。モデル作成者は、独自の transformers 実装を利用することで、無料で超高速な vLLM 推論を自動的に活用できるようになりました。
vllm pip パッケージのアップグレード
uv pip install --upgrade vllm --torch-backend auto
transformers ライブラリは、機械学習における参照モデルライブラリとして確立されました。一貫した API を通じて 450 以上のアーキテクチャをサポートし、モデル実装が*自己完結型*で*理解しやすい*ことを主目的に設計されています。transformers のコードを確認することで、貢献者はアーキテクチャの仕組みを容易に学び、vLLM、SGLang、MLX、llama.cpp など他のフレームワークへ移植することが可能になります。
私たちはこの生態系における役割を完全に受け入れ、より使いやすくするために多大な努力を注いでいます。その方向性における大きな一歩として、昨年は transformers を vLLM のモデルバックエンドとして統合しました。これにより、モデル作成者は何らかの移植作業を行うことなく、vLLM 内で transformers モデル（LLM および VLM の両方）を実行できるようになりました。transformers がモデリングコードを提供し、vLLM が連続バッチ処理やカスタムアテンションカーネルなどの極めて最適化された推論技術を提供します。
この統合がさらに進化しました 🚀!
紹介
vLLM の transformers モデリングバックエンドを、3 つの非常に異なる Qwen3 モデルにおいて、vLLM 自身が手書きしたネイティブ実装と比較しました。
- 単一 GPU 上の 4B デンサーモデル
- テンソル並列化を用いた 32B デンサーモデル
- 同じ 8×H100 ノード上でデータ並列化とエキスパート並列化を併用した、235B パラメータの FP8 Mixture-of-Experts (MoE) モデル
その結果：transformers モデリングバックエンドは、これらすべてのモデルにおいて、ネイティブのスループットに匹敵するか、あるいは上回ることを示しました。
Hugging Face の任意のモデルを transformers モデリングバックエンド経由で実行するには、単一のフラグ --model-impl transformers を指定するだけで済みます。通常の並列化オプションと組み合わせ可能なので、サービング設定について何も変更する必要はありません：
Qwen3-4B デンサー、単一 GPU
vllm serve Qwen/Qwen3-4B --model-impl transformers
Qwen3-32B デンサー、2 台の GPU にわたるテンソル並列化
vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2
Qwen3-235B-A22B-FP8 MoE、8 台の GPU にわたるデータ並列化＋エキスパート並列化
vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel
ノードがメモリ制約を受ける場合は、--max-model-len 8192 を追加してください
線形アテンション (linear attention) を使用するモデルは現時点ではサポートされていませんが、近い将来に対応予定です。コードが Hub リポジトリ内に存在するカスタムモデルについては、コンプライアンスに準拠して記述されていない限り、動作しない可能性が高いです。
測定方法について
各モデルは、コードパスのみが異なるという点以外、すべての条件において同一の 3 つの条件下で比較されます：
- native — --model-impl vllm, vLLM の手書きモデル（比較基準となるバー）
- after — PR を適用した後の --model-impl transformers
- before — PR を適用していない状態の --model-impl transformers
完全な再現可能なランナーは、以下の gist で利用可能です：benchmark.sh
さて、何が新しくなったのか？
vLLM の transformers モデルバックエンドは、従来推論のボトルネックとして *アテンション* に焦点を当てていました。ランタイムで vLLM のアテンション実装を組み込むことで、transformers モデルを vLLM エンジン内で効率的に実行できるようになりました。しかし、最大限の推論性能を引き出すためには、カスタムポートでしか対応できないデプロイメントにおける多くの側面が存在します。GPU 間での並列化、コンパイル、融合カーネルなど、ハードウェアを活用して超高速な推論を実現するために貢献する要素は数多くあります。
新しいモデルは、transformers 向けに一度統合され、カスタム最適化を施した vLLM 向けにもう一度統合される必要がありました。
モデル作成者が絶対的な最高性能を求めた場合、依然としてカスタムの vLLM 実装を作成していました。
transformers に新たに統合されたモデルは、ネイティブの vLLM 実装による速度で、すぐに vLLM で利用可能になりました。
vLLM の transformers モデリングバックエンドの最新バージョンでは、互換性のあるアーキテクチャにおいて、推論に特化したレイヤー融合（layer fusions）をランタイムで動的に適用し、カスタムコード実装と同等の速度を実現します。
仕組みは？
vLLM の transformers モデルバックエンドは、モデルのグラフに対する静的解析を torch.fx を用いて実行するようになりました。このプロセスでは、最適化可能な既知のパターンを検索します。パターンが特定された後、ast（抽象構文木）を使用してソースコードを操作し、一部の演算をその場で書き換えます。
これによって何が可能になるのでしょうか？
- 多数の演算を (超) 最適化された vLLM カーネルにマッピングする融合演算。例えば、混合専門家モデル（MoE）における専門家並列処理（EP）で利用されるようなカーネルです。
- もう一つの主要な融合演算は、vLLM の MergedColumnParallelLinear と QKVParallelLinear です。これらのブロックにより、TP（テンソル並列）の並列計画を推論することが可能になります。デコーダーブロックリストが容易に識別できる場合、PP（パイプライン並列）の計画も推論できます。
- 操作されたモデルは依然として完全に (torch) コンパイル可能です。専用 vLLM モデル実装と同様に、torch.compile と CUDA Graphs を通じて処理されます。
- vLLM のモデル実装とは異なり、Transformers モデル実装はトレーニングにも使用できます。つまり、トレーニング/評価/RL ロールアウトに同じモデルコードを使用することが可能です。
上記の通り、この手法により、互換性のあるモデルに対して vLLM 推論速度をネイティブで実現でき、推論用にモデルを最適化するためのコードを一行も記述する必要がありません。
これらの最適化された推論方法の詳細な解説や、モデルをどのように操作してこれらに適応させるかについて詳しく説明する詳細なブログ記事を作成中です。
リソース
- トランスフォーマーモデル定義
- vLLM におけるトランスフォーマーモデリングバックエンド
- 大規模推論サービス
- Torch FX
- 抽象構文木
原文を表示
TL;DR: The transformers vLLM backend is now as fast (or faster) than custom vLLM implementations for many LLM architectures. Model authors can automatically leverage their transformers implementations to get ultra fast vLLM inference, for free.
# Upgrade the vllm pip package
uv pip install --upgrade vllm --torch-backend auto
The transformers library has become the reference modeling library for Machine Learning. It supports 450+ architectures through consistent APIs, and is designed with the main goal that model implementations are *self contained* and *easy to understand*. Going through transformers code makes it easy for contributors to learn how an architecture works, and then port it to other frameworks such as vLLM, SGLang, MLX, llama.cpp, and many others.
We have fully embraced this role in the ecosystem and are investing a lot of effort to make it easier. A big step in this direction was the integration last year of transformers as a modeling backend in vLLM. This has been allowing model authors to run transformers models (LLMs and VLMs alike) inside vLLM, without having to port anything. Transformers provides the modeling code, and vLLM provides extremely optimized inference techniques such as continuous batching and custom attention kernels.
This integration gets better now 🚀!
Showcase
We put the transformers modeling backend for vLLM head to head with vLLM's hand written native implementations across three very different Qwen3 models:
- 4B dense model on a single GPU
- 32B dense model on tensor parallelism
- 235B-parameter FP8 Mixture-of-Experts on data + expert parallelism on the same 8×H100 node
The result: the transformers modeling backend now meets or beats native throughput on every one of them.
Running any* Hugging Face model through the transformers modeling backend is a single flag — --model-impl transformers. It composes with the usual parallelism options, so nothing about your serving setup changes:
# Qwen3-4B dense, single GPU
vllm serve Qwen/Qwen3-4B --model-impl transformers
# Qwen3-32B dense, tensor-parallel across 2 GPUs
vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2
# Qwen3-235B-A22B-FP8 MoE, data-parallel + expert-parallel across 8 GPUs
vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel
# add --max-model-len 8192 if your node is memory constrained
**Models that use linear attention are not currently supported, but they will be soon! Custom models where the code lives in a Hub repo are unlikely to work as they will not have been written compliantly.*
How we measured
Each model is compared under three conditions that are identical in every way except the code path:
- native — --model-impl vllm, vLLM's hand-written model (the bar to match)
- after — --model-impl transformers with the PR
- before — --model-impl transformers without the PR
The full, reproducible runner is available as a gist: benchmark.sh
So, what's new?
The transformers modeling backend for vLLM used to focus on *attention* as the bottleneck for inference. By plugging vLLM’s attention implementation at runtime, we could make a transformers model run efficiently inside the vLLM engine. But there are many dimensions to deployments that only a custom port can target to extract maximum inference performance. Parallelization across GPUs, compilation, fused kernels, and many more, all contribute to leveraging your hardware to achieve ultra-fast inference.
A new model used to be integrated once for transformers, and once for vLLM with custom optimizations
When model authors wanted the absolute best performance, they were still writing custom vLLM implementations.
A new model once integrated to transformers, can now be immediately used in vLLM with native vLLM implementation speed
The latest iteration of the transformers modeling backend for vLLM dynamically applies inference specific layer fusions at runtime to match the speed of custom code implementations, for compatible architectures.
How does it work?
The transformers modeling backend for vLLM now uses torch.fx to perform static analysis on the model’s graph. This process searches for known patterns that can be optimised. After any patterns have been identified, it uses ast (abstract syntax tree) to manipulate the source code and rewrite some of the operations in place.
What can we achieve with this?
- Fused operations that are many-to-one mapped to (ultra) optimized vLLM kernels, such as the ones used for Expert Parallelization (EP) in Mixture-of-Experts (MoE) models.
- The main other fused operations are vLLM's MergedColumnParallelLinear and QKVParallelLinear. These blocks allow us to infer parallel plans for TP (tensor-parallel). PP (pipeline-parallel) plans can also be inferred if the decoder block list is easily identifiable.
- The manipulated models are still fully (torch) compilable, being passed through torch.compile and CUDA Graphs, just the same as a dedicated vLLM model implementation.
- Unlike vLLM model implementations, Transformers model implementations can be used in training. So you can use the same model code for training/evals/RL rollouts.
As shown above, this results in native vLLM inference speed for compatible models, without having to write a single line of code to optimize the model for inference.
We are in the process of writing a detailed blog post to dive deep inside these optimized inference methods and explain in detail how we manipulate the model to adapt to them.
Resources
- Transformers model definition
- Transformers modeling backend in vLLM
- Large scale serving
- Torch FX
- Abstract syntax tree
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み