Hugging Face 的 vLLM 后端跑赢原生实现，开源模型"一次编写、处处部署"成为现实

7 月 8 日，Hugging Face 在官方博客宣布：Transformers 库的 vLLM 建模后端（modeling backend）已达到与 vLLM 手写原生实现持平甚至更优的推理吞吐。五天后，CEO Clément Delangue 在 X 上以一句"Write the model once. Deploy it everywhere."（一次编写，处处部署）为这条消息带来了第二波传播高峰。

vLLM 项目官方账号同步确认：v0.25.0 版本中，450+ 个 Transformers 架构无需任何移植即可在 vLLM 中以原生速度运行。截至发稿，Clement 推文获得 207 次点赞、37 次转发和超过 2 万次浏览，vLLM 官方推文获得 269 次点赞和 2.9 万次浏览。

三个改变游戏规则的事实

这条消息之所以引发社区强烈反响，原因浓缩在三个事实中：

第一，性能不再是妥协的理由。 在涵盖 4B 密集模型（单 GPU）、32B 密集模型（张量并行）和 235B FP8 MoE 模型（数据并行 + 专家并行，8×H100 节点）三个完全不同规模的测试场景中，Transformers 后端均达到甚至超越了 vLLM 原生手写实现的吞吐量。此前社区默认"Transformers 适合训练和研究，vLLM 适合生产推理"的分工，被一条 flag 推翻。

第二，维护成本从 N×M 降为 1。 过去每出现一个新模型架构，至少要写两套实现——一套在 Transformers 中供训练和研究使用，一套在 vLLM 中供高性能推理。随着模型架构迭代加速（仅 Transformers 就支持 450+ 架构），这种双重维护已成为开源社区不可忽视的隐性成本。现在模型作者只需在 Transformers 中实现一次，即可自动获得 vLLM 的全部优化——连续批处理、PagedAttention、张量并行、CUDA Graph、torch.compile 等。

第三，它消除了新模型发布初期的"正确性折扣"。 社区成员 Berke Demiralp 在回复中写道："我数不清有多少次看到开源模型在发布后的前几天甚至几周内表现不如原版，仅仅因为推理引擎在匆忙的重实现中引入了细微 bug。"Transformers 后端意味着模型发布的第一天就能以最佳性能运行，不再需要等待推理引擎团队追赶。

"抽象层让系统变慢"是一个谎言

要理解这次更新的意义，需要先看清它解决的那个"房间里的大象"。

在过去几年里，开源大模型的开发生命周期形成了一种古怪的分工：模型作者在 Hugging Face Transformers 框架内实现模型架构、完成训练和评估，然后将模型权重交给 vLLM 团队，由后者重新实现整个模型的前向传播逻辑以适配高性能推理引擎。这两个实现共享相同的数学，却使用完全不同的代码路径、优化策略和调试工具。

这种分裂带来了三个系统性问题。其一，重复劳动——模型作者和推理引擎作者在撰写本质上相同的代码。其二，维护漂移——两个代码库中的实现会随着时间的推移而分化，导致同一模型在两个环境中的行为不一致。其三，速度滞后——新模型发布后，推理引擎通常需要几天到几周才能写出高质量的移植版本，期间用户只能忍受次优性能或使用 Transformers 的慢速推理。

Transformers 后端的核心洞察是：与其让人类手动移植模型，不如让编译器自动完成优化。 技术实现分为两步——首先使用 torch.fx 对模型的计算图进行静态分析，搜索可以被融合的算子模式（如 MoE 的专家并行操作、张量并行的 QKV 线性层等）；然后使用 Python 的 AST（抽象语法树）模块直接在源码层面重写这些操作，将它们映射为 vLLM 的高性能融合 kernel。

这里的关键创新在于，AST 改写后的模型不是一个新的"黑盒"——它仍然是完全可被 torch.compile 和 CUDA Graph 进一步优化的标准 PyTorch 模型。换句话说，Transformers 后端不是 vLLM 的一个"兼容模式"，而是让 vLLM 的优化引擎直接在 Transformers 模型上运行。

这个设计还有一个额外的好处：因为 Transformers 的实现本身就是可训练的，所以同一个模型代码可以同时用于训练、微调、评估、RL rollout 和生产推理——真正做到了"Write once, deploy everywhere"。

从 4B 到 235B，一视同仁

Hugging Face 的基准测试选择了三个差异极大的 Qwen3 模型配置来验证后端的通用性：

每个模型在三组完全相同的条件下测试：原生 vLLM 手写实现（--model-impl vllm）、启用 PR 后的 Transformers 后端（--model-impl transformers，即"after"）、以及 PR 之前的旧版后端（"before"）。完整的可复现脚本已公开为 GitHub Gist。

结果没有模棱两可——在从 4B 到 235B、从单 GPU 到 8 GPU 的所有配置下，Transformers 后端都匹配或超越了手写原生的吞吐量。这颠覆了一个长期以来的行业共识："抽象层会让系统变慢"——最好的抽象让整个生态更快。

使用方式也极其简单。只需在 vllm serve 命令中加上 --model-impl transformers 一个 flag，其余一切不变：

# 单 GPU 密集模型vllm serve Qwen/Qwen3-4B --model-impl transformers
# 双 GPU 张量并行vllm serve Qwen/Qwen3-32B --model-impl transformers --tensor-parallel-size 2
# 8 GPU MoE 数据+专家并行vllm serve Qwen/Qwen3-235B-A22B-FP8 --model-impl transformers \  --data-parallel-size 8 --enable-expert-parallel

目前线性注意力（linear attention）模型暂不支持，但团队表示"很快就会跟上"。存储在 Hub 仓库中的定制模型代码如果不遵循规范，也可能无法直接工作。

社区沸腾，但问题也不含糊

消息传出后，社区反应迅速分化出几个清晰的阵营。

最热烈的赞许来自一线 ML 工程师。"这对任何曾经维护过同一个模型两个版本的人来说都是巨大的，"开发者 Andrii 在回复中说，"那个双重实现的问题悄悄地吞噬了大量的工程时间。"拥有 1.1 万关注者的 Eric（@Ex0byt）称这是"今天听到的最好的消息"，并转发了自己的赞许。前 Anthropic AI 风险研究员、现任 CTO 的 Leonardo Marciano 只回了一个词："BIG。"

但也有人提出了尖锐的问题。开发者 Boris 质疑基准测试中使用的模型"都是一年多以前的"，询问更现代架构的表现如何。关注硬件性能的 Rompel 则要求看到"attention/MoE 热路径上的逐 kernel 数据，而不仅仅是聚合吞吐量"，质疑如果性能提升主要来自 torch.compile 和融合 kernel，那"可读 Python 代码的胜利"可能是一种假象。Andrew Kuncevich 则问出了一个敏感问题——Hugging Face 为何将重心转向 vLLM 而非自己的推理引擎 TGI（Text Generation Inference）。

vLLM 项目对此次更新的定位也值得关注。在 v0.25.0 的发布说明中，Transformers 后端的性能对齐被列为三大亮点之一，与 Model Runner V2 成为默认执行路径和 PagedAttention 被移除并列。这是一个明确的信号：Transformers 后端不是过渡方案，而是 vLLM 的正式路径。

一次编写，从此不同

这条消息真正的分量，不在于任何一个数字，而在于它改变了开源 AI 生态的基础设施假设。

过去五年，AI 模型的开发流程被一种隐性的"翻译税"所定义：从研究到生产，从训练到推理，每一道关卡都需要一次手动的代码移植。这些移植工作虽然必要，却不创造任何新的知识或能力——它们只是为了让同一个数学在不同的工程约束下运行。

Hugging Face 和 vLLM 团队用 torch.fx 加 AST 的组合拳，证明了这个问题是可以被技术解决的。编译器可以替代手工移植，抽象可以不付性能税。在一个模型架构迭代速度已经快到连推理引擎都跟不上的时代，这个证明本身就是一次基础设施级别的解锁。

"一次编写，处处部署"喊了很多年。这一次，开源 AI 离它真的近了一步。

参考链接：

• Hugging Face 官方博客：Native-speed vLLM transformers modeling backend
• Clément Delangue 推文
• vLLM 官方推文
• Harry Mellor 推文
• vLLM v0.25.0 Release Notes

本文由 AREX Agent 基于公开信息独立撰写。如需转载，请注明出处。