The Pulse

vLLM 0.29.0 rende Model Runner V2 l’opzione predefinita

vLLM 0.29.0 instrada per impostazione predefinita tutti i modelli supportati attraverso Model Runner V2, dopo 594 commit di 277 collaboratori. La release amplia inoltre le funzionalità di speculative decoding e di profilazione dei grafi CUD

AI.info Team · Scritto con l’IA · verificato · 2026-09-12

594 commit cambiano l’opzione predefinita del runtime di vLLM

vLLM 0.29.0 cambia il percorso di esecuzione per tutti i modelli supportati: Model Runner V2 è ora l’opzione predefinita, completando un’introduzione iniziata con i modelli di pooling e successivamente estesa alle architetture dense. La release, pubblicata il 9 settembre, contiene 594 commit di 277 collaboratori, tra cui 91 persone al loro primo contributo al progetto.

Model Runner V2, o MRV2, prende il posto del vecchio runner come opzione predefinita, con un’architettura che mantiene sulla GPU una parte maggiore della gestione delle richieste, considera l’esecuzione asincrona un vincolo primario e separa i comportamenti specifici dei modelli dal percorso comune di serving. Per adottarlo, gli utenti non devono modificare le API pubbliche di vLLM.

«Ho co-creato e ora co-dirigo il progetto vLLM, un motore di inferenza open source per LLM ampiamente adottato», scrive sul suo sito Woosuk Kwon, cofondatore e direttore tecnologico di Inferact. Kwon figura tra i collaboratori ringraziati nell’introduzione tecnica di vLLM a Model Runner V2.

Perché vLLM sta dismettendo il vecchio runner

La documentazione di vLLM su Model Runner V2 descrive il progetto come una risposta al debito tecnico accumulato con l’aggiunta di scheduling asincrono, speculative decoding e supporto per nuove architetture di modelli alla precedente implementazione. Il nuovo runner suddivide le responsabilità in componenti più piccoli, tra cui lo stato del modello, la preparazione degli input, il sampling e i percorsi di speculative decoding.

La modifica sposta inoltre sulla GPU, tramite kernel Triton, diverse operazioni che prima dipendevano dall’elaborazione dei tensori lato CPU. MRV2 mantiene lo stato persistente delle richieste separato dai tensori preparati per ogni fase di esecuzione, consentendo di modificare l’ordine delle richieste senza ricostruire la stessa struttura di stato attorno a ogni batch.

Questa architettura è particolarmente importante nel serving ad alta concorrenza, dove piccole operazioni della CPU possono interrompere il lavoro della GPU. Nel post tecnico del progetto pubblicato a marzo, vLLM ha riportato un aumento del throughput del 56,2% su Qwen3-0.6B eseguito su un GB200 quando la preparazione degli input è stata spostata sulla GPU, passando da circa 16.000 a 25.000 token di output al secondo. Lo stesso post riportava che lo speculative decoding aveva mostrato una riduzione del 6,3% del tempo per token di output su quattro GPU GB200 che eseguivano GLM-4.7-FP8 con un token speculativo.

MRV1 resta un’alternativa di ripiego, non un percorso equivalente

vLLM non rimuove Model Runner V1 nella versione 0.29.0. Il progetto considera MRV1 deprecato e punta a rimuoverlo nella v0.32. Il vecchio runner gestisce ancora un piccolo numero di modelli e configurazioni ROCm che MRV2 non supporta ancora.

Gli utenti che configurano il parallelismo sulle sequenze, la sovrapposizione di due batch, il parallelismo elastico degli esperti, processori di logits personalizzati o alcuni metodi di speculative decoding possono ancora essere instradati verso MRV1. vLLM prevede di colmare queste lacune entro due o tre settimane, ma la release non garantisce che tutte le configurazioni passeranno immediatamente al nuovo runner.

La distinzione offre agli operatori un periodo di transizione, rendendo al tempo stesso MRV2 il percorso normale per i nuovi deployment. Cambia anche la direzione della manutenzione del progetto: secondo le note di rilascio, vLLM non intende accettare ulteriori miglioramenti o ottimizzazioni specifici per MRV1.

Aggiornamenti importanti per i grafi CUDA e il sampling

MRV2 acquisisce la profilazione della memoria dei grafi CUDA per il dimensionamento automatico della cache KV, insieme a un sampling suddiviso per batch che riduce la memoria dei logits per ogni fase di un fattore pari alla dimensione del parallelismo dei tensori. La release aggiunge inoltre il supporto agli embedding dei prompt, l’estrazione degli stati nascosti per la speculazione, il dispatch di grafi CUDA completi con padding per la decodifica uniforme nell’ambito dello speculative decoding e l’eliminazione della sincronizzazione del parallelismo sui dati prima del prefill dei modelli draft EAGLE e MTP.

Queste modifiche riguardano le parti di un server di inferenza che determinano quanto lavoro raggiunge la GPU a ogni fase e quanta memoria resta disponibile per le richieste concorrenti. Non cambiano l’interfaccia di serving compatibile con OpenAI, ma possono influire sul comportamento all’avvio, sull’allocazione della memoria e sull’insieme delle funzionalità dei modelli che determinano la scelta di un particolare runner.

Model Runner V2 prosegue anche il lavoro di vLLM sul batching persistente, lo speculative decoding, l’offload della cache KV su più livelli e l’esecuzione disaggregata. Tra le modifiche al nucleo del motore, la release elenca l’offload su un livello secondario basato su disco, il controllo di ammissione alla coda, nuovi controlli per la cache dei prefissi e ulteriori percorsi per i grafi CUDA.

Nuovi checkpoint nella stessa release

vLLM 0.29.0 aggiunge il supporto per diverse famiglie di modelli e checkpoint. L’elenco comprende Hy4-preview; il modello da 770B di Tencent con 49B parametri attivi, Gated DeepSeek Sparse Attention e MTP nativo; Qwen3.8-Flash-Next con supporto BF16, FP8 e NVFP4; GraniteSWA e GraniteMoeSWA; NemotronH_Omni_Reasoning_V3; e i checkpoint Kimi K3 NVFP4.

La release aggiunge anche l’attenzione bidirezionale per i modelli di embedding basati su DeepSeek, il supporto a ModernBERT FP8 e una maggiore copertura MTP per i modelli vision-language Nemotron. Kimi K3 ora funziona su ROCm con il runner V2, estendendo la nuova opzione predefinita oltre i deployment CUDA.

Le opzioni di installazione coprono CUDA, ROCm, CPU e XPU

vLLM pubblica wheel Python per CUDA 12.9 e CUDA 13.0, oltre a pacchetti per CPU e XPU. Il progetto fornisce anche immagini Docker per deployment su CUDA 13.0, CUDA 12.9, Ubuntu 24.04, ROCm, CPU e Intel XPU.

L’immagine CUDA predefinita è disponibile come vllm/vllm-openai:v0.29.0, con tag separati per CUDA 12.9 e Ubuntu 24.04. Gli utenti ROCm possono installare la release dall’indice dei wheel di vLLM o usare vllm/vllm-openai-rocm:v0.29.0.

Per gli operatori, il compito immediato consiste meno nel modificare un’API che nel verificare le proprie ipotesi sulle funzionalità non supportate del runner, sulla copertura dei modelli ROCm e sul comportamento della memoria. vLLM 0.29.0 rende MRV2 il percorso di esecuzione standard; l’elenco delle compatibilità ancora mancanti determina quando questo standard diventerà l’unico percorso.