The Pulse
AWS: il trasferimento bidirezionale della cache KV riduce di 3,3 volte il tempo al primo token degli agenti
Secondo AWS, nei test con conversazioni lunghe e a più turni il trasferimento bidirezionale della cache chiave-valore in vLLM ha ridotto fino a 3,3 volte il tempo al primo token. La tecnica consente ai nodi di prefill di recuperare il conte
AI.info Team · Scritto con l’IA · verificato ·
«Man mano che la conversazione si allunga, questo lavoro ripetuto consuma più capacità degli acceleratori e aumenta il tempo al primo token (TTFT)».
Sunita Nadampalli, ingegnera principale ed esperta di IA/ML presso AWS
Il 19 ottobre AWS ha pubblicato un’implementazione in vLLM per riutilizzare la cache chiave-valore (KV) tra un turno e l’altro, registrando un tempo al primo token fino a 3,3 volte inferiore per uno dei modelli testati. La tecnica modifica il flusso abituale dell’inferenza disaggregata: anziché inviare la cache soltanto dai nodi di prefill a quelli di decode, consente ai nodi di prefill di recuperare dai nodi di decode la cache già calcolata quando una conversazione prosegue.
È importante per gli agenti che inviano ripetutamente istruzioni di sistema, cronologia della conversazione, risultati degli strumenti e precedenti risposte del modello come parte di ogni nuovo prompt. Quando un nodo di prefill non dispone di quelle rappresentazioni nella cache, deve ricalcolarle prima che possa iniziare la generazione. Secondo AWS, con l’aumentare del contesto questo lavoro ripetuto può accrescere la latenza e consumare capacità degli acceleratori.
I nodi di decode restituiscono la cache per il turno successivo
Nella gestione convenzionale con prefill e decode separati, il nodo di prefill elabora un prompt e costruisce la relativa cache KV; il nodo di decode legge quella cache e genera una risposta. Con il nuovo flusso, il nodo di decode conserva i blocchi di cache idonei dopo la generazione e invia i metadati sulla loro posizione attraverso il flusso della risposta. Un router che mantiene lo stato associa quei metadati alla conversazione e li passa al nodo di prefill alla richiesta successiva.
Il nodo di prefill può quindi recuperare i blocchi riutilizzabili dal nodo di decode con una lettura NIXL tramite accesso diretto alla memoria remota e calcolare solo la parte del prompt non presente nella cache. Il router memorizza i metadati sulla posizione dei blocchi, non i tensori della cache. Secondo AWS, vLLM dispone del supporto sul lato del connettore, ma le implementazioni richiedono anche un router che tenga conto della cache KV; l’azienda rimanda a un proxy di esempio nel progetto vLLM.
Nei test di AWS, TTFT fino a 3,3 volte inferiore
AWS ha testato un nodo di prefill e un nodo di decode su istanze Amazon EC2 P5en collegate tramite Elastic Fabric Adapter. Ha usato Qwen3-32B e zai-org/GLM-5-FP8 e ha disabilitato la memorizzazione nella cache dei prefissi sul nodo di prefill, per simulare la rimozione di dati dalla cache o l’arrivo di una richiesta su un altro nodo di prefill.
Per i prompt più lunghi testati, AWS ha misurato una riduzione del TTFT di 1,6 volte per Qwen3-32B e di 3,3 volte per GLM-5-FP8. Senza trasferimento, il TTFT è salito da 158 millisecondi con 2.000 token a 778 millisecondi con 24.000 token per Qwen3-32B. Per GLM-5-FP8 è salito da 500 millisecondi con 2.000 token a 2.334 millisecondi con 20.000 token. Con il trasferimento abilitato, i valori riportati per quelle lunghezze massime dei prompt sono stati di 460 millisecondi per Qwen3-32B e 702 millisecondi per GLM-5-FP8.
Il riutilizzo della cache ha un limite di tempo e un costo
Recuperare la cache non è privo di costi. AWS ha misurato tempi di trasferimento della cache KV compresi tra circa 30 e 130 millisecondi per Qwen3-32B e tra 29 e 110 millisecondi per GLM-5-FP8, ma afferma che, nelle prove effettuate, il tempo di calcolo del prefill risparmiato ha più che compensato questo costo aggiuntivo. L’azienda avverte che i risultati dipendono dal modello, dal carico di lavoro, dall’hardware e dalla configurazione di rete.
La funzionalità conserva i blocchi di cache sul lato decode per un periodo predefinito di 480 secondi; per i turni che arrivano dopo tale periodo viene eseguito il normale prefill. Una soglia configurabile per il ricalcolo è impostata per impostazione predefinita a 64 token e consente al nodo di prefill di ricalcolare un prefisso breve quando trasferirlo richiederebbe più tempo. Secondo AWS, la configurazione usa vLLM v0.21.0 o successivo con NixlConnector, l’opzione di trasferimento bidirezionale abilitata su entrambi i tipi di nodo e un router che tiene traccia dei metadati della cache della conversazione. Questi requisiti fanno sì che i miglioramenti riportati siano un risultato dell’architettura di gestione delle richieste, non un’accelerazione ottenibile senza modifiche in ogni implementazione di vLLM.