摘要：transformers vLLM 后端现在对于许多大语言模型架构而言，速度已与定制 vLLM 实现相当（甚至更快）。模型作者可以自动利用其 transformers 实现，免费获得超快的 vLLM 推理性能。
# Upgrade the vllm pip package
uv pip install --upgrade vllm --torch-backend auto
transformers 库已成为机器学习的参考建模库。它通过一致的 API 支持 450 多种架构，其设计的主要目标是让模型实现能够自包含且易于理解。阅读 transformers 代码有助于贡献者轻松了解架构的工作原理，然后将其移植到其他框架，例如 vLLM、SGLang、MLX、llama.cpp 等。
我们已完全接纳了在生态系统中的这一角色，并投入大量精力使其更加便捷。朝此方向迈出的一大步是去年将 transformers 作为建模后端集成到 vLLM 中。这使得模型作者能够在 vLLM 内部运行 transformers 模型（包括大语言模型和视觉语言模型），而无需进行任何移植工作。Transformers 提供建模代码，vLLM 则提供高度优化的推理技术，例如连续批处理和定制注意力核。
这项集成现在变得更好了 🚀！
成果展示
我们将 vLLM 的 transformers 建模后端与 vLLM 手写的原生实现，在三种截然不同的 Qwen3 模型上进行了正面比较：
- 单 GPU 上的 4B 密集模型
- 采用张量并行的 32B 密集模型
- 在同一个 8×H100 节点上，采用数据并行和专家并行的 235B 参数 FP8 混合专家模型
 |
|---|
| 结果：transformers 建模后端在每一个模型上的吞吐量都达到或超越了原生实现。 |
通过 transformers 建模后端运行任何* Hugging Face 模型，只需一个标志——`--model-impl transformers`。它可以与常用的并行选项组合使用，因此你的服务设置无需任何更改：
# 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
*目前尚不支持使用线性注意力机制的模型，但很快会支持！代码位于 Hub 仓库中的定制模型不太可能正常工作，因为它们可能未按兼容性要求编写。
我们的测量方法
每个模型都在三种条件下进行比较，这些条件除代码路径外完全相同：
- 原生 —— `--model-impl vllm`，即 vLLM 手写模型（作为对标基准）
- 之后 —— `--model-impl transformers`，包含该 PR
- 之前 —— `--model-impl transformers`，不包含该 PR
完整且可复现的运行脚本以 gist 形式提供：benchmark.sh
那么，有哪些新变化？
vLLM 的 transformers 建模后端此前一直将注意力机制视为推理的瓶颈。通过在运行时接入 vLLM 的注意力实现，我们可以让 transformers 模型在 vLLM 引擎内高效运行。然而，部署场景涉及多个维度，只有通过定制化移植才能充分挖掘极致推理性能。跨 GPU 并行化、编译优化、融合内核以及更多技术手段，共同助力充分利用硬件资源，实现超高速推理。
 |
|---|
| 过去，一个新模型需要分别为 transformers 和 vLLM 各集成一次，且 vLLM 版本需附带定制优化 |
当模型作者追求极致性能时，他们仍需编写自定义的 vLLM 实现。
 |
|---|
| 如今，一个新模型一旦集成到 transformers 中，即可立即在 vLLM 中使用，并达到原生 vLLM 实现的运行速度 |
vLLM 的 transformers 建模后端最新版本，能够在运行时动态应用推理专用的层融合操作，对于兼容的架构而言，其速度可媲美自定义代码实现。
它是如何工作的？
vLLM 的 transformers 建模后端现在使用 torch.fx 对模型计算图进行静态分析。该过程会搜索可优化的已知模式。识别出模式后，再利用 ast（抽象语法树）对源代码进行操作，并就地重写部分运算。
我们能实现什么效果？
- 融合操作被多对一映射到（超）优化的 vLLM 内核上，例如用于混合专家（MoE）模型中专家并行化（EP）的那些内核。
- 其他主要的融合操作包括 vLLM 的 MergedColumnParallelLinear 和 QKVParallelLinear。这些模块使我们能够推断出张量并行（TP）的并行方案。如果解码器模块列表易于识别，流水线并行（PP）方案也可以被推断出来。
- 经过操控的模型仍然完全可（torch）编译，能够通过 `torch.compile` 和 CUDA Graphs 处理，与专门的 vLLM 模型实现完全相同。
- 与 vLLM 模型实现不同，Transformers 模型实现可用于训练。因此，你可以使用同一套模型代码进行训练、评估和强化学习 rollout。
如上所示，对于兼容的模型，这能够实现原生 vLLM 推理速度，而无需编写一行代码来优化模型的推理性能。
我们正在撰写一篇详细的博文，深入探讨这些优化的推理方法，并详细解释我们如何操控模型以适应这些方法。
资源
- Transformers 模型定义
- vLLM 中的 Transformers 建模后端
- 大规模服务
- Torch FX
- 抽象语法树