Hugging Face ha pubblicato i numeri del nuovo modeling backend transformers per vLLM: su diverse architetture il throughput eguaglia o supera quello delle implementazioni native scritte a mano dentro vLLM. Chi serve modelli in produzione non deve più scegliere tra codice leggibile e inference veloce.
Il contesto conta. La libreria transformers copre oltre 450 architetture ed è di fatto la reference implementation da cui si parte per portare un modello su vLLM, SGLang, MLX o llama.cpp. Il backend dentro vLLM esisteva già, ma si limitava a sostituire l’attention con quella ottimizzata di vLLM. Tutto il resto — parallelismo tra GPU, compilazione, kernel fusi — restava terreno delle porting fatte a mano.
Cosa è cambiato sotto il cofano
Il backend ora usa torch.fx per fare analisi statica sul graph del modello, individua pattern noti e riscrive le operazioni in place manipolando l’AST del sorgente. Da lì derivano le fusioni che mappano su kernel ottimizzati di vLLM: quelli dell’expert parallelism per i modelli Mixture-of-Experts, e blocchi come MergedColumnParallelLinear e QKVParallelLinear, da cui si inferiscono i piani di tensor parallelism (e, quando la lista dei decoder block è identificabile, anche di pipeline parallelism). I modelli così manipolati restano compilabili con torch.compile e CUDA Graphs.
Il confronto è stato fatto su tre modelli Qwen3 molto diversi tra loro: un dense da 4B su singola GPU, un dense da 32B in tensor parallelism e un Mixture-of-Experts da 235B parametri in FP8 con data ed expert parallelism sullo stesso nodo 8×H100. In tutti e tre i casi il backend transformers raggiunge o supera il throughput nativo. Il benchmark è riproducibile: lo script è pubblicato come gist.
Cosa significa in pratica
Il flag è uno solo, --model-impl transformers, e si compone con le solite opzioni di parallelismo: nulla cambia nel resto del serving setup. L’effetto pratico è che la finestra tra “il modello esce” e “il modello gira veloce su vLLM” si accorcia, perché non serve più una porting dedicata per ottenere performance da implementazione custom.
Due limiti dichiarati: i modelli con linear attention non sono ancora supportati, e i modelli custom il cui codice vive in una repo dell’Hub difficilmente funzioneranno, non essendo scritti in modo conforme. Va segnalato anche un vantaggio collaterale non banale: a differenza delle implementazioni vLLM, quelle transformers si possono usare anche in training. Lo stesso codice modello copre training, evaluation e rollout di RL, il che riduce la quantità di implementazioni parallele da mantenere allineate.
In sintesi
- Il backend
transformersdi vLLM eguaglia o supera il throughput nativo sui tre Qwen3 testati (4B dense, 32B dense, 235B MoE in FP8). - Il meccanismo è analisi statica con
torch.fxe riscrittura dell’AST per applicare fusioni e piani di parallelismo a runtime. - Restano fuori linear attention e modelli custom su Hub; in compenso lo stesso codice modello vale sia per training sia per inference.
Hai qualcosa da aggiungere? Unisciti alla discussione.