Hugging Face在7月8日的博客里给出一个反常识的结论：跑在vLLM里的transformers建模后端，现在不比vLLM自己手写的原生实现慢——部分场景甚至更快。官方用Qwen3系列三种量级做了验证：4B稠密模型单卡、32B稠密模型张量并行、235B参数FP8 MoE模型在8×H100节点上做数据并行加专家并行，三种场景下transformers后端都“meets or beats”vLLM原生实现的吞吐。
这意味着模型作者以后可能只需要在transformers里写一份代码，就能同时拿到能训练、能推理、还跑得够快的模型——前提是，你的模型恰好落在这次升级划定的范围里。
从只补attention，到整张图重写
这套后端不是新东西。去年vLLM就支持把transformers的模型实现直接接进推理引擎，加一个--model-impl transformers参数即可。那时候的做法很朴素：vLLM把自己优化过的attention实现在运行时“焊”进transformers模型，其余部分照旧。张量并行怎么切、算子怎么融合、编译怎么加速——这些环节没人动，全靠原生实现里那套手写代码撑着。
这次更新把优化范围从attention一环扩展到了整张计算图。transformers后端现在用torch.fx对模型做静态分析，找出可以合并的运算模式，再用ast把源码在运行时改写成融合后的算子调用。效果是：MergedColumnParallelLinear、QKVParallelLinear这类vLLM专用融合算子，以及MoE场景下的专家并行内核，都能自动套到transformers写的普通模型代码上，作者不用改一行。改写后的模型依然能过torch.compile和CUDA Graphs，这条编译链路没有绕过去。
免费提速有一份门槛清单
但“追平原生”这四个字是有边界的。vLLM文档写明，这套后端目前只覆盖full attention和sliding attention两类，linear attention架构不在支持列表里——用了linear attention的模型暂时享受不到这次提速，官方说未来会支持，没给时间表。另一头，如果自定义模型代码散落在Hub仓库里、没按vLLM要求的规范写（kwargs怎么传、attention怎么调用、能否被替换成vLLM自己的attention层），这套后端大概率认不出来，还得走老路手写。
- 提醒.linear attention模型和不规范的Hub自定义模型被明确排除在外，“免费”两个字后面挂着一份适配清单。
值得多问一句的是，官方展示的三个案例全部来自Qwen3系列，同宗同源。检索范围里没找到第三方对Llama、Mistral、DeepSeek这类非Qwen架构的独立复现测试。450多个支持架构里，有多少能真正复现这张对比图的结果，目前只有Hugging Face自己说了算。
追平vLLM原生，不等于追平行业最快
另一件容易被忽略的事是，“vLLM原生”本身在推理引擎的赛道里并不是天花板。业内的经验判断是，TensorRT-LLM在NVIDIA硬件上通常有更高的性能上限，SGLang也在部分聊天类基准测试里跑赢过vLLM。所以这次升级更准确的说法是：transformers后端不再是vLLM生态里的性能短板，而不是拿到了世界最快的推理方案。
追平的是vLLM自己的原生实现，不是整条推理引擎的天花板。
原文给出的对比图没有列出具体吞吐数字，也没有附上对应的GitHub PR链接，检索范围内也没找到独立的第三方复现数据。这不代表结论不成立，但说明眼下这份结论主要还是Hugging Face一家的自证——想拿它当选型的硬依据，最好等有人拿真实业务场景跑一遍。
对模型作者来说，如果新架构用的是标准attention、代码写得规范，以后大概率不用再为vLLM单独开一套优化分支，维护成本会降下来。对已经在生产环境跑vLLM的团队，更现实的动作是拿自己的并发、上下文长度和量化方案去试一遍这个flag，而不是直接假设Qwen3的结论能照搬。至于用linear attention或非规范自定义代码的模型，该手写还得手写——这次升级还没轮到它们。