The Pulse
vLLM aggiunge il trasferimento KV push e inverso per i carichi di lavoro degli agenti
In un test con GLM-5-FP8 su contesti lunghi, il trasferimento bidirezionale della cache KV di vLLM ha ridotto fino a 3,3 volte il tempo al primo token. In un test separato, un connettore push ha migliorato fino a 3 volte il TTFT di Qwen3-32
AI.info Team · Scritto con l’IA · verificato ·
Con GLM-5-FP8, TTFT fino a 3,3 volte più basso
Nei test multi-turno di vLLM, il trasferimento bidirezionale della cache chiave-valore (KV) ha ridotto fino a 3,3 volte il tempo al primo token per GLM-5-FP8 al crescere dei prompt della conversazione. Un test separato del connettore push del progetto ha rilevato un TTFT migliorato fino a 3 volte e un tempo per token di output migliorato fino al 30% per Qwen3-32B. Entrambi i risultati provengono da configurazioni con un’istanza di prefill e una di decode su istanze Amazon EC2 P5en collegate tramite AWS Elastic Fabric Adapter. Gli autori avvertono che i risultati dipendono dal carico di lavoro e dalla configurazione.
Le due funzionalità affrontano ritardi diversi nell’inferenza disaggregata, in cui un’istanza che esegue il modello elabora un prompt e un’altra genera la risposta. AWS ha pubblicato una descrizione dettagliata del trasferimento push il 19 ottobre 2026; il blog del progetto vLLM aveva descritto il trasferimento bidirezionale per i carichi di lavoro degli agenti multi-turno il 12 ottobre. I miglioramenti riguardano i tempi aggiuntivi tra queste fasi di calcolo separate, non modifiche ai modelli stessi.
La modalità push sposta la predisposizione fuori dal percorso di decode
Nel flusso pull convenzionale, l’istanza di prefill costruisce la cache KV del prompt, poi un router passa le informazioni sui blocchi all’istanza di decode. Quest’ultima alloca i blocchi di destinazione, prepara il trasferimento e legge la cache prima che la generazione possa iniziare. Questi passaggi sequenziali aggiungono operazioni al percorso che porta al primo token.
Il connettore push cambia l’ordine delle operazioni. L’istanza di decode registra in anticipo i propri blocchi di destinazione mentre il prefill è ancora in corso; l’istanza di prefill avvia poi il trasferimento quando i blocchi KV sono pronti. La predisposizione del trasferimento avviene sul lato prefill e in un thread in background, tenendo queste attività fuori dal ciclo di generazione di decode, sensibile alla latenza.
AWS afferma di aver sviluppato e validato inizialmente la funzionalità su cluster AWS Trainium, per poi contribuire a vLLM rendendola indipendente dal tipo di acceleratore. I risultati prestazionali pubblicati, tuttavia, utilizzano istanze GPU P5en e il modello Qwen3-32B. Confrontano push e pull in quella specifica configurazione di test; non costituiscono una garanzia generale per modelli, hardware o schemi di richieste diversi.
Il trasferimento bidirezionale riutilizza i turni precedenti di un agente
Per un agente, ogni nuova richiesta può includere prompt, risposte e risultati degli strumenti precedenti. Nel normale trasferimento da prefill a decode, l’istanza di decode conserva i blocchi KV dell’output precedente, ma l’istanza di prefill non può recuperarli in un turno successivo. Può quindi ricalcolare un contesto che il sistema ha già elaborato, soprattutto se la sua cache locale ha espulso quei blocchi.
Il trasferimento bidirezionale consente all’istanza di prefill di rileggere dall’istanza di decode i blocchi KV idonei prima di elaborare la nuova parte del prompt. Un router che tiene conto della cache KV segue i metadati relativi alla posizione dei blocchi tra i turni e li associa a un ID di conversazione; i tensori KV si spostano direttamente tra le istanze che eseguono il modello.
Il router trasporta solo i metadati; i tensori KV si spostano direttamente da un’istanza all’altra.
Sunita Nadampalli, AWS
Nei test riportati, con il riutilizzo abilitato il TTFT di Qwen3-32B è salito da 122 millisecondi con un prompt di 2.000 token a 460 millisecondi con 24.000 token. Senza riutilizzo, nello stesso confronto è salito da 158 a 778 millisecondi. Per GLM-5-FP8, i risultati corrispondenti con il riutilizzo abilitato sono stati di 358 millisecondi con 2.000 token e 702 millisecondi con 20.000; il percorso basato sul solo ricalcolo ha raggiunto 2.334 millisecondi con 20.000 token.
Le due modalità comportano compromessi diversi
Il trasferimento push e quello bidirezionale non sono semplicemente due fasi di un’unica configurazione. Secondo AWS, push è adatto alle configurazioni che possono scegliere in anticipo un’istanza di decode e danno priorità a un TTFT più basso. Pull rimane più indicato quando un carico di lavoro richiede il riutilizzo bidirezionale o rinvia la scelta dell’istanza di decode a dopo il prefill per un instradamento che tenga conto del carico.
Il riutilizzo bidirezionale ha anche un costo in termini di memoria: l’istanza di decode conserva i blocchi idonei per 480 secondi dopo la generazione per impostazione predefinita, e questo timer fisso non viene rinnovato. Una seconda impostazione, la soglia di ricalcolo, è fissata per impostazione predefinita a 64 token; al di sotto di tale soglia, l’istanza di prefill ricalcola localmente anziché sostenere il costo di un trasferimento remoto. Gli operatori hanno bisogno di un router con stato che tenga conto della cache KV per collegare i turni, e le istruzioni del progetto richiedono vLLM versione 0.21.0 o successiva per la configurazione descritta.
Per i team che gestiscono agenti, la scelta pratica dipende dal fatto che il collo di bottiglia sia la predisposizione del trasferimento prima della generazione oppure il lavoro di prefill ripetuto nel corso di una conversazione. I miglioramenti nei benchmark pubblicati provengono da una configurazione AWS definita con due istanze; gli articoli lasciano alla misurazione in ciascun sistema le prestazioni specifiche della configurazione, la pressione sulla memoria della cache e il comportamento dell’instradamento.