{"slug": "native-speed-vllm-transformers-modeling-backend", "title": "Native-speed vLLM transformers modeling backend", "summary": "Hugging Face announced that the transformers vLLM modeling backend now matches or exceeds native vLLM throughput for many LLM architectures, allowing model authors to run their transformers implementations inside vLLM without custom ports. Benchmarks on Qwen3 models show the backend meets or beats native performance across dense and MoE configurations.", "body_md": "Updated • 9 • 3\n\n# Native-speed vLLM transformers modeling backend\n\n[Update on GitHub](https://github.com/huggingface/blog/blob/main/native-speed-vllm-transformers-backend.md)\n\n**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.\n\n```\n# Upgrade the vllm pip package\nuv pip install --upgrade vllm --torch-backend auto\n```\n\nThe 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.\n\nWe 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.\n\nThis integration gets better now 🚀!\n\n## Showcase\n\nWe put the transformers modeling backend for vLLM head to head with vLLM's hand written native implementations across three very different Qwen3 models:\n\n- 4B dense model on a single GPU\n- 32B dense model on tensor parallelism\n- 235B-parameter FP8 Mixture-of-Experts on data + expert parallelism on the same 8×H100 node\n\nThe result: the transformers modeling backend now meets or beats native throughput on every one of them. |\n\nRunning any* Hugging Face model through the transformers modeling backend is a single flag — `--model-impl transformers`\n\n. It composes with the usual parallelism options, so nothing about your serving setup changes:\n\n```\n# Qwen3-4B dense, single GPU\nvllm serve Qwen/Qwen3-4B --model-impl transformers\n\n# Qwen3-32B dense, tensor-parallel across 2 GPUs\nvllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2\n\n# Qwen3-235B-A22B-FP8 MoE, data-parallel + expert-parallel across 8 GPUs\nvllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers --data-parallel-size 8 --enable-expert-parallel\n# add --max-model-len 8192 if your node is memory constrained\n```\n\n**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.*\n\n### How we measured\n\nEach model is compared under three conditions that are identical in every way except the code path:\n\n**native**—`--model-impl vllm`\n\n, vLLM's hand-written model (the bar to match)**after**—`--model-impl transformers`\n\n*with*the PR**before**—`--model-impl transformers`\n\n*without*the PR\n\nThe full, reproducible runner is available as a gist: `benchmark.sh`\n\n## So, what's new?\n\nThe 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.\n\n| A new model used to be integrated once for transformers, and once for vLLM with custom optimizations |\n\nWhen model authors wanted the absolute best performance, they were still writing custom vLLM implementations.\n\n| A new model once integrated to transformers, can now be immediately used in vLLM with native vLLM implementation speed |\n\nThe 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.\n\n## How does it work?\n\nThe transformers modeling backend for vLLM now uses `torch.fx`\n\nto 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.\n\n**What can we achieve with this?**\n\n- 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.\n- The main other fused operations are vLLM's\n`MergedColumnParallelLinear`\n\nand`QKVParallelLinear`\n\n. 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\n`torch.compile`\n\nand CUDA Graphs, just the same as a dedicated vLLM model implementation. - Unlike vLLM model implementations, Transformers model implementations can be used in\n**training**. So you can use the same model code for training/evals/RL rollouts.\n\nAs 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.\n\nWe 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.", "url": "https://wpnews.pro/news/native-speed-vllm-transformers-modeling-backend", "canonical_source": "https://huggingface.co/blog/native-speed-vllm-transformers-backend", "published_at": "2026-07-08 00:00:00+00:00", "updated_at": "2026-07-08 15:55:16.357615+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-infrastructure", "developer-tools"], "entities": ["Hugging Face", "vLLM", "Qwen3", "Qwen"], "alternates": {"html": "https://wpnews.pro/news/native-speed-vllm-transformers-modeling-backend", "markdown": "https://wpnews.pro/news/native-speed-vllm-transformers-modeling-backend.md", "text": "https://wpnews.pro/news/native-speed-vllm-transformers-modeling-backend.txt", "jsonld": "https://wpnews.pro/news/native-speed-vllm-transformers-modeling-backend.jsonld"}}