vLLM 的 transformers 建模后端提速至原生实现水平

TL;DR：对于许多 LLM 架构，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 模型（无论是 LLM 还是 VLM），而无需移植任何内容。Transformers 提供建模代码，vLLM 提供极度优化的推理技术，如连续批处理和自定义注意力内核。

这项集成现在变得更好了 🚀！

展示

我们将 vLLM 的 transformers 建模后端与 vLLM 手写的原生实现，在三个截然不同的 Qwen3 模型上进行了正面比较：

• 单 GPU 上的 4B 稠密模型
• 张量并行下的 32B 稠密模型
• 在同一 8×H100 节点上采用数据 + 专家并行的 235B 参数 FP8 专家混合模型

结果是：transformers 建模后端现在在每一个模型上都达到或超越了原生吞吐量。

通过 transformers 建模后端运行任何* HF Mirror 模型只需一个标志——--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 仓库中的自定义模型不太可能正常工作，因为它们并非以合规方式编写。

我们如何测量

每个模型在三种条件下进行比较，除代码路径外其他方面完全相同：

1. 原生 — --model-impl vllm，vLLM 手写的模型（需要达到的标准）
2. 之后 — --model-impl transformers 带有该 PR
3. 之前 — --model-impl transformers 不带该 PR

完整、可复现的运行器以 gist 形式提供：benchmark.sh

那么，有什么新变化？

vLLM 的 transformers 建模后端过去将注意力视为推理的瓶颈。通过在运行时插入 vLLM 的注意力实现，我们可以让 transformers 模型在 vLLM 引擎内高效运行。但部署有许多维度，只有自定义移植才能针对这些维度来榨取最大推理性能。跨 GPU 并行、编译、融合内核等，都有助于充分利用你的硬件来实现超高速推理。

一个新模型过去需要分别为 transformers 和 vLLM 各集成一次，后者还带有自定义优化

当模型作者想要绝对最佳性能时，他们仍然需要编写自定义 vLLM 实现。

一个新模型一旦集成到 transformers，现在就可以立即在 vLLM 中使用，并达到原生 vLLM 实现的速度

vLLM 的 transformers 建模后端的最新迭代，在运行时动态应用针对推理的层融合，从而在兼容架构上达到自定义代码实现的速度。

它是如何工作的？

vLLM 的 transformers 建模后端现在使用 torch.fx 对模型的计算图执行静态分析。该过程会搜索可优化的已知模式。在识别出任何模式之后，它使用 ast（抽象语法树）来操作源代码，并就地重写部分运算。

我们能借此实现什么？

• 将多对一映射的融合运算映射到（超）优化的 vLLM 内核，例如用于 Mixture-of-Experts (MoE) 模型中 Expert Parallelization (EP) 的内核。
• 其他主要的融合运算包括 vLLM 的 MergedColumnParallelLinear 和 QKVParallelLinear。这些模块让我们能够推断 TP（张量并行）的并行方案。如果解码器层列表易于识别，也可以推断 PP（流水线并行）方案。
• 经过处理的模型仍然完全可（torch）编译，会经过 torch.compile 和 CUDA Graphs，与专用的 vLLM 模型实现完全相同。
• 与 vLLM 模型实现不同，Transformers 模型实现可用于训练。因此你可以将同一份模型代码用于训练/评估/RL rollout。

如上所示，这为兼容模型带来了原生 vLLM 推理速度，而无需编写一行代码来为推理优化模型。

我们正在撰写一篇详细的博客文章，以深入探讨这些优化推理方法，并详细解释我们如何操纵模型来适配它们。

资源

• Transformers 模型定义
• vLLM 中的 Transformers 建模后端
• 大规模服务
• Torch FX
• 抽象语法树