On July 8, Hugging Face announced in an official blog post that the vLLM backend of transformers has reached — or even exceeded — the speed of customized vLLM implementations. A horizontal test of three Qwen3 model scales: 4B dense on a single card, 32B dense using tensor parallelism, and 235B-A22B-FP8 MoE doing data + expert parallel on an 8×H100 node — all three deployment forms meet or beat native vLLM implementation throughput. Over the past year, model authors had to hand-write a parallelization kernel for vLLM outside transformers — MergedColumnParallelLinear, QKVParallelLinear, MoE's EP fusion — to get peak performance. The core idea this time is to use torch.fx to do static analysis of the model graph, find optimizable patterns, and then directly rewrite the source code via ast, injecting fused ops into the transformers model definition. In other words, "write once in transformers, vLLM automatically gets native speed", and authors no longer need to maintain two copies. The deeper impact is training-inference unification: transformers models can both infer and directly run in RL rollout / training, while hand-written vLLM models can only infer. With a single --model-impl transformers flag, Qwen3-4B, Qwen3-32B, and Qwen3-235B-A22B-FP8 can all run at native throughput in the vLLM engine. This is an ecosystem-position reshuffle. HF is pushing "reference implementation" toward "reference implementation = production deployment"; for the open-source community, new-model authors can focus on one codebase covering both training and inference service; for vLLM, the moat of the native model implementation has become shallower, but the model library coverage speed will significantly accelerate. When "transformers-native speed" becomes the default, the coupling between model distribution and inference deployment will be further broken.