vLLM riduce la latenza negli agenti multi-turno con trasferimento bidirezionale della cache KV
Imagen generada con gpt-image-2.5-sunburst para InferamaFonte ↗
01

La sfida della latenza nell'inferenza disaggregata

L'inferenza dei grandi modelli linguistici (LLM) è diventata un collo di bottiglia critico per le applicazioni agentiche, dove la latenza accumulata tra i turni influisce direttamente sull'esperienza dell'utente. Nelle architetture disaggregate, le fasi di prefill (precompilazione) e decode (decodifica) vengono eseguite su nodi separati per ottimizzare l'uso delle risorse, ma questa separazione introduce una dipendenza cruciale: il trasferimento della cache delle chiavi e dei valori (KV) tra questi nodi.

Tradizionalmente, la gestione della cache KV era limitata alla memoria locale di ogni istanza. Tuttavia, nei carichi di lavoro multi-turno, il contesto della conversazione cresce esponenzialmente. Ricalcolare questo contesto a ogni turno genera un sovraccarico computazionale inutile. L'evoluzione di vLLM verso un modello di trasferimento bidirezionale cerca di risolvere questo problema consentendo ai nodi di prefill e decode di condividere e riutilizzare lo stato KV precedentemente calcolato, minimizzando i tempi di inattività e il ricalcolo.

02

Meccanismo di trasferimento push-based e bidirezionale

Il nucleo di questa ottimizzazione risiede nell'uso di un connettore push-based basato su NIXL (NVIDIA Inference Xfer Library). A differenza dei modelli pull-based, in cui il nodo di decodifica richiede attivamente i dati, il modello push-based consente al nodo di prefill di inviare proattivamente la cache KV al nodo di decodifica non appena disponibile. Questo elimina la latenza di attesa associata alla richiesta e alla negoziazione del trasferimento.

La natura bidirezionale di questo trasferimento è cruciale per gli agenti multi-turno. Non solo la cache del prefill viene trasferita al decode per avviare la generazione, ma è anche consentita l'aggiornamento e il ritorno di stati intermedi. Ciò significa che, al termine di un turno, la cache KV risultante può essere memorizzata e riutilizzata nel turno successivo, evitando che il sistema tratti ogni interazione come una richiesta indipendente da zero.

Flusso di trasferimento bidirezionale

Processo semplificato di come viene gestita la cache KV in un ciclo multi-turno.

  1. 01Turno N: Il nodo di prefill elabora il nuovo prompt e la cache KV accumulata dal turno precedente.
  2. 02Trasferimento Push: La cache KV aggiornata viene inviata proattivamente al nodo di decodifica.
  3. 03Decodifica: Il nodo di decode genera la risposta senza ricalcolare il contesto precedente.
  4. 04Persistenza: La cache KV finale viene salvata per essere riutilizzata nel Turno N+1.
03

Impatto sul Time To First Token (TTFT)

Il Time To First Token (TTFT) è la metrica più sensibile alla percezione della velocità nelle interfacce conversazionali. Spostando la coordinazione del trasferimento fuori dal percorso critico tramite il connettore NIXL, vLLM riesce a ridurre drasticamente il tempo che intercorre tra la ricezione della richiesta e la generazione del primo token.

Nei carichi di lavoro agentici, dove il contesto di input è esteso e viene parzialmente riutilizzato, la riduzione del TTFT è proporzionale alla quantità di contesto riutilizzato. Il trasferimento bidirezionale consente al sistema di identificare quali parti della cache esistono già nel nodo di destinazione e di trasferire o ricalcolare solo ciò che è strettamente necessario, ottimizzando la banda di rete e la latenza di calcolo.

04

Risultati su istanze AWS EC2 P5en

I benchmark eseguiti su istanze Amazon EC2 P5en, dotate di interconnessione AWS EFA (Elastic Fabric Adapter), dimostrano l'efficacia di questa architettura. La rete ad alta velocità di EFA è un requisito fondamentale affinché il trasferimento della cache KV non diventi un nuovo collo di bottiglia, permettendo che il movimento dei dati sia quasi veloce quanto l'accesso alla memoria locale.

Nei test con il modello Qwen3-32B, è stata osservata una riduzione del TTFT di fino a 1,6 volte rispetto all'inferenza disaggregata standard. Per il modello GLM-5-FP8, il miglioramento è stato ancora più marcato, raggiungendo una riduzione di 3,3 volte nel TTFT. Queste cifre confermano che il riutilizzo del contesto è più vantaggioso nei modelli con contesti lunghi e carichi di lavoro con alto riutilizzo dei prefissi.

Confronto del miglioramento del TTFT (EC2 P5en + EFA)

Riduzione del Time To First Token nei carichi di lavoro agentici multi-turno.

ModelloMiglioramento TTFTContesto di test
Qwen3-32B1.6xAgentico multi-turno
GLM-5-FP83.3xAgentico multi-turno
05

Implicazioni per gli architetti di IA

Per i team che distribuiscono agenti di IA nel cloud, questa ottimazione ha un doppio impatto: riduzione dei costi e miglioramento dell'esperienza dell'utente. Riutilizzando la cache KV, si riduce il numero di operazioni di calcolo (FLOPs) necessarie per turno, il che si traduce in un minore consumo di GPU per richiesta. Questo consente di servire più utenti simultanei con la stessa infrastruttura o di ridurre la dimensione della flotta di GPU per un dato carico di lavoro.

Inoltre, il miglioramento della latenza è critico per rispettare gli SLO (Service Level Objectives) nelle applicazioni interattive. L'architettura di vLLM, combinata con l'infrastruttura di rete ad alta velocità, posiziona l'inferenza disaggregata non solo come una tecnica di ottimizzazione del throughput, ma come una strategia fattibile per applicazioni a bassa latenza e alta interattività, come i copiloti di codice e gli assistenti conversazionali complessi.

Questioni aperte

  • I benchmark provengono da AWS e non sono stati verificati in modo indipendente in altri ambienti cloud o hardware.
  • L'impatto esatto sul consumo di memoria RAM/GPU rispetto all'inferenza monolitica non è dettagliato nelle fonti primarie fornite.
  • La disponibilità di questa funzionalità in versioni specifiche di vLLM e la sua compatibilità con altri provider cloud non sono specificate.
06

Continua a esplorare

06

Fonti consultate

03

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.

Proponi una correzione