vLLM 原生速度的 Transformers 建模后端

# Upgrade the vllm pip package
uv pip install --upgrade vllm --torch-backend auto

transformers library 已成为 Machine Learning 领域事实上的标准建模库。它通过一致的 API 支持 450 多种架构，其核心设计目标是让模型实现保持自包含，并且易于理解。阅读 transformers 的代码，贡献者可以轻松了解某个架构的工作原理，进而将其移植到 vLLM、SGLang、MLX、llama.cpp 等其他众多框架中。

我们已经完全接受了自己在生态系统中的这一角色，并投入大量精力，让整个过程变得更加容易。朝着这个方向迈出的重要一步，是去年将 transformers 集成为 vLLM 的建模后端。借助这项集成，模型作者无需进行任何移植，就能在 vLLM 中运行 transformers 模型——无论是 LLM 还是 VLM。Transformers 提供建模代码，而 vLLM 则提供 continuous batching、自定义 attention kernel 等经过高度优化的推理技术。

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

我们选择了三款差异显著的 Qwen3 模型，让 vLLM 的 transformers 建模后端与 vLLM 手工编写的原生实现进行正面对比：

• 在单张 GPU 上运行的 4B dense 模型
• 使用 tensor parallelism 的 32B dense 模型
• 在同一台 8×H100 节点上，使用 data + expert parallelism 的 235B 参数 FP8 Mixture-of-Experts 模型

通过 transformers 建模后端运行任意* Hugging Face 模型，只需添加一个 flag：--model-impl transformers。它可以与常规的 parallelism 选项组合使用，因此你的 serving 配置完全不需要改变：

# 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

*目前尚不支持使用 linear attention 的模型，不过很快就会支持！对于代码存放在 Hub 仓库中的自定义模型，由于其代码很可能没有按照兼容规范编写，因此不太可能正常运行。

每个模型都会在以下三种条件下进行比较。除代码路径之外，其他所有条件都完全相同：

• native——使用 --model-impl vllm，即 vLLM 手工编写的模型实现，也是需要达到的基准
• after——使用包含该 PR 的 --model-impl transformers
• before——使用不包含该 PR 的 --model-impl transformers

完整且可复现的运行脚本已通过 gist 提供：benchmark.sh

过去，vLLM 的 transformers 建模后端主要将 attention 视为推理瓶颈。通过在运行时接入 vLLM 的 attention 实现，我们能够让 transformers 模型在 vLLM engine 内高效运行。但 deployment 涉及许多不同维度，只有专门的自定义移植才能针对这些维度进行优化，从而榨取最大的推理性能。跨 GPU 并行、编译、fused kernel 等诸多技术，共同帮助你充分利用硬件，实现超高速推理。

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

最新版 vLLM transformers 建模后端会在运行时动态应用针对推理场景的 layer fusion，使兼容架构达到与自定义代码实现相当的速度。

现在，vLLM 的 transformers 建模后端使用 torch.fx 对模型 graph 执行静态分析。该过程会搜索可以优化的已知模式。识别出这些模式后，它会使用 ast（abstract syntax tree，抽象语法树）操作源代码，并直接重写其中一部分运算。

这样能够实现什么？

可以将多个操作融合并映射为一个经过（极致）优化的 vLLM kernel，例如 Mixture-of-Experts（MoE）模型进行 Expert Parallelization（EP）时使用的 kernel。

其他主要的 fused operation 包括 vLLM 的 MergedColumnParallelLinear 和 QKVParallelLinear。借助这些 block，我们可以推导 TP（tensor-parallel）方案。如果 decoder block 列表很容易识别，还可以推导 PP（pipeline-parallel）方案。

经过处理的模型仍然能够完整地进行（torch）编译，并且会像专门的 vLLM 模型实现一样，通过 torch.compile 和 CUDA Graphs 处理。

与 vLLM 模型实现不同，Transformers 模型实现还可以用于训练。因此，你可以在 training、evals 和 RL rollouts 中使用同一份模型代码。

如上所示，对于兼容的模型，这种方式可以达到 vLLM 原生实现的推理速度，而且完全不需要为了推理优化而编写任何额外代码。

我们正在撰写一篇详细的博客文章，深入解析这些经过优化的推理方法，并具体说明我们如何操作模型，使其适配这些优化。

Transformers 模型定义

vLLM 中的 Transformers 建模后端

本文提到的数据集 1

更多博客文章

释放 continuous batching 的异步能力

Transformers 中的 Mixture of Experts（MoE）

· 注册或登录后发表评论

本文提到的数据集 1