The Pulse
vLLM 0.29.0 rende Model Runner V2 la scelta predefinita
Con vLLM 0.29.0, tutti i modelli supportati usano per impostazione predefinita Model Runner V2, dopo 594 commit di 277 collaboratori. La versione amplia inoltre la decodifica speculativa, la profilazione dei grafi CUDA, il supporto ai model
AI.info Team ·
594 commit portano l’esecuzione di vLLM su un nuovo percorso predefinito
vLLM 0.29.0 cambia il percorso di esecuzione per ogni modello supportato: Model Runner V2 è ora la scelta predefinita, a conclusione di un’introduzione graduale iniziata con i modelli di pooling e poi estesa alle architetture dense. La versione, pubblicata il 9 settembre, comprende 594 commit di 277 collaboratori, tra cui 91 persone al loro primo contributo al progetto.
Model Runner V2, o MRV2, subentra al runner precedente come scelta predefinita con un’architettura che mantiene sulla GPU una parte maggiore della gestione delle richieste, considera l’esecuzione asincrona un vincolo fondamentale e separa il comportamento specifico dei modelli dal percorso comune di erogazione del servizio. Per adottarlo, gli utenti non devono modificare le API pubbliche di vLLM.
«Ho contribuito a creare il progetto vLLM e ora lo guido insieme ad altri: è 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 abbandonando il runner precedente
La documentazione di vLLM su Model Runner V2 descrive il progetto come una risposta al debito tecnico accumulato con l’aggiunta, all’implementazione precedente, della pianificazione asincrona, della decodifica speculativa e del supporto a nuove architetture di modelli. Il nuovo runner suddivide le responsabilità in componenti più piccoli, tra cui lo stato del modello, la preparazione degli input, il campionamento e i percorsi di decodifica speculativa.
Il cambiamento sposta inoltre sulla GPU, tramite kernel Triton, diverse operazioni che prima dipendevano dall’elaborazione dei tensori sulla CPU. Secondo vLLM, MRV2 mantiene lo stato persistente delle richieste separato dai tensori preparati per ogni fase di esecuzione, consentendo di cambiare l’ordine delle richieste senza ricostruire la stessa struttura di stato per ogni batch.
Questa architettura conta soprattutto nell’erogazione del servizio con un’elevata concorrenza di richieste, dove piccole operazioni sulla CPU possono interrompere il lavoro della GPU. Nel suo articolo tecnico di marzo, vLLM ha riportato un aumento del 56,2% del throughput di Qwen3-0.6B su un singolo GB200 quando la preparazione degli input è stata spostata sulla GPU: da circa 16.000 a 25.000 token di output al secondo. Lo stesso articolo ha riportato una riduzione del 6,3% del tempo per token di output nella decodifica speculativa su quattro GPU GB200 con GLM-4.7-FP8 e un token speculativo.
MRV1 resta un’alternativa, non un percorso alla pari
vLLM non rimuove Model Runner V1 nella versione 0.29.0. Le note di rilascio indicano che il progetto considera MRV1 deprecato e punta a rimuoverlo nella v0.32. Il runner precedente gestisce ancora un piccolo numero di modelli e configurazioni ROCm che MRV2 non supporta.
Gli utenti che configurano il parallelismo delle sequenze, la sovrapposizione di due batch, il parallelismo elastico degli esperti, processori personalizzati dei logits o alcuni metodi di decodifica speculativa potrebbero ancora essere indirizzati a MRV1. vLLM prevede di colmare queste lacune entro due o tre settimane, ma la versione non garantisce che tutte le configurazioni passino subito a MRV2.
La distinzione concede agli operatori un periodo di transizione, rendendo al tempo stesso MRV2 il percorso normale per le nuove distribuzioni. Cambia anche l’orientamento 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 campionamento
MRV2 introduce la profilazione della memoria dei grafi CUDA per dimensionare automaticamente la cache KV, insieme a un campionamento suddiviso per batch che riduce la memoria necessaria ai logits in ogni fase di un fattore pari alla dimensione del parallelismo dei tensori. La versione aggiunge inoltre il supporto agli embedding dei prompt, l’estrazione degli stati nascosti per la speculazione, l’instradamento verso grafi CUDA completi con padding per una decodifica uniforme durante la decodifica speculativa e la possibilità di saltare la sincronizzazione del parallelismo dei dati prima del prefill delle bozze di EAGLE e MTP.
Questi cambiamenti riguardano le parti di un server di inferenza che determinano quanto lavoro raggiunge la GPU in ogni fase e quanta memoria resta disponibile per le richieste simultanee. Non modificano l’interfaccia di erogazione del servizio compatibile con OpenAI, ma possono incidere sul comportamento all’avvio, sull’allocazione della memoria e sulle funzionalità dei modelli che determinano la scelta di un determinato runner.
Model Runner V2 prosegue anche il lavoro di vLLM sui batch persistenti, sulla decodifica speculativa, sullo scaricamento della cache KV su livelli di memoria diversi e sull’esecuzione disaggregata. Tra le modifiche al nucleo del motore, la versione elenca lo scaricamento su disco a un livello secondario, il controllo dell’ammissione in coda, nuovi controlli per la cache dei prefissi e ulteriori percorsi basati sui grafi CUDA.
Con la stessa versione arrivano nuovi checkpoint
vLLM 0.29.0 aggiunge il supporto a diverse famiglie di modelli e a vari 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 a BF16, FP8 e NVFP4; GraniteSWA e GraniteMoeSWA; NemotronH_Omni_Reasoning_V3; e i checkpoint NVFP4 di Kimi K3.
La versione aggiunge anche l’attenzione bidirezionale per i modelli di embedding basati sull’architettura di DeepSeek, il supporto a FP8 per ModernBERT e un supporto più ampio a MTP per i modelli visivo-linguistici Nemotron. Kimi K3 ora funziona su ROCm con il runner V2, estendendo la nuova scelta predefinita oltre le distribuzioni CUDA.
Pacchetti di installazione per CUDA, ROCm, CPU e XPU
vLLM pubblica pacchetti wheel Python per CUDA 12.9 e CUDA 13.0, oltre a pacchetti per CPU e XPU. Il progetto fornisce anche immagini Docker per distribuzioni basate 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 versione dall’indice dei pacchetti wheel di vLLM oppure usare vllm/vllm-openai-rocm:v0.29.0.
Per gli operatori, il compito immediato non è tanto cambiare un’API quanto verificare le proprie ipotesi sulle funzionalità del runner non supportate, 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 da garantire determina quando diventerà l’unico percorso.