Riepilogo Tecnico: CacheTTL

Enunciato del Problema

I motori di inferenza dei Large Language Model (LLM) si basano attualmente su politiche di espulsione "a fine turno" per la gestione della cache Key-Value (KV). In questi sistemi, una volta completato il decoding di una richiesta, la sua cache KV viene espulsa dalla memoria GPU per massimizzare l'utilizzo per le nuove richieste in arrivo. Sebbene efficace per i chatbot standard multi-turno, questa politica fallisce per i carichi di lavoro agentic (ad esempio, agenti di ingegneria software, agenti che utilizzano strumenti) che seguono il paradigma ReAct.

Nei flussi di lavoro agentic, i passaggi di inferenza sono intercalati con chiamate a strumenti esterni. Queste chiamate introducono pause che sono spesso più brevi della velocità di digitazione umana ma sufficientemente lunghe da innescare l'espulsione della cache KV nei motori standard. Quando l'agente torna da una chiamata a uno strumento per avviare il successivo passaggio di inferenza, il sistema deve:

1. Ricalcolare il prefisso (prefill), sostenendo una latenza significativa.
2. Ricaricare la cache KV dalla memoria CPU (se il caricamento è abilitato), introducendo ritardi di coda per turno. Anche se il ricaricamento è veloce, la richiesta deve attendere in coda che la memoria GPU venga liberata da altre richieste attive.

Le soluzioni esistenti non affrontano questo problema in modo olistico:

• InferCept considera i costi di ricarica ma ignora il ritardo di coda per turno cumulativo e manca di robustezza contro la variabilità delle durate degli strumenti.
• Autellix e Pie si concentrano su flussi di lavoro statici o mancano di politiche di ritenzione specifiche per le chiamate a strumenti dinamiche.
• Le strategie di ritenzione statica rischiano di bloccare la memoria GPU se le chiamate a strumenti durano più del previsto.

La sfida principale è mantenere le cache KV abbastanza a lungo da evitare il ricalcolo e i ritardi di coda senza monopolizzare la memoria GPU durante i tempi di esecuzione imprevedibili degli strumenti.

Metodologia: CacheTTL

Gli autori propongono CacheTTL, un sistema di servizio che introduce un meccanismo Time-to-Live (TTL) per la ritenzione della cache KV. Invece dell'espulsione immediata, CacheTTL fissa selettivamente le cache KV nella memoria GPU per una durata calcolata.

1. Modello di Utilità Costo-Beneficio

CacheTTL determina il TTL ottimale ($\tau$) modellando il compromesso tra il costo di ritenzione della cache e il beneficio di evitare l'espulsione.

• Costo ($Cost(\tau, r)$): Il costo opportunità dell'occupazione della memoria GPU, calcolato come il rapporto tra l'uso di memoria della richiesta e la footprint media di memoria delle richieste attive, moltiplicato per la durata del TTL ($\tau$). Questo rappresenta la latenza aggiunta ad altre richieste bloccate dalla cache fissata.
• Beneficio ($Benefit(r)$): La somma di due costi evitati:
  1. CacheMissCost: Il tempo necessario per ricostruire la cache KV (prefill) o ricaricarla dalla CPU.
  2. OutofOrderCost: Il ritardo di coda per turno che si verificherebbe se la richiesta venisse espulsa e dovesse attendere in coda che la memoria GPU diventi disponibile. Questo termine è critico e distingue CacheTTL dal lavoro precedente come InferCept. È scalato da un fattore di memoria ($\eta$), che misura come il numero di passaggi rimanenti si correla con il progresso corrente (ad esempio, programmi a lunghezza fissa hanno un'alta memoria).

2. Calcolo del TTL

Il sistema calcola il TTL ottimale ($\tau^*$) massimizzando il beneficio netto atteso:
$$\tau^* = \arg\max_{\tau} \left( P(\tau, f) \times Benefit(r) - Cost(\tau, r) \right)$$
Dove $P(\tau, f)$ è la probabilità che la chiamata a strumento $f$ si completi entro il tempo $\tau$, stimata utilizzando una Funzione di Distribuzione Cumulativa (CDF) empirica dai registri storici delle chiamate a strumenti.

• Gestione dell'Avvio a Freddo: Quando i dati storici sono scarsi, CacheTTL predefinisce un TTL fisso derivato da un'assunzione di distribuzione esponenziale o da medie globali.
• Robustezza: Se una chiamata a strumento supera il TTL, la cache KV viene espulsa automaticamente, prevenendo l'occupazione indefinita della memoria e potenziali deadlock.

3. Pianificazione e Progettazione del Sistema

• FCFS a Livello di Programma: CacheTTL combina il TTL con una politica First-Come-First-Serve (FCFS) a livello di programma (non solo a livello di richiesta). Questo garantisce che le richieste appartenenti allo stesso programma agente siano prioritarie per mantenere la continuità.
• Priorità Consapevole del TTL: Lo scheduler assegna una tupla di priorità multi-chiave:
  1. Stato di preemption.
  2. Stato TTL: Le richieste con TTL attivi (fissate) sono prioritarie rispetto a quelle non fissate.
  3. Tempo di arrivo a livello di programma.
• Implementazione: Costruito su vLLM con un Gestore Chiamate a Strumenti modulare. Questo gestore analizza gli output LLM per identificare le chiamate a strumenti, registra gli intervalli inter-richiesta e comunica i valori TTL allo scheduler. Il design aggiunge un overhead minimo (~1k righe di Python) ed è compatibile con il caricamento su CPU/SSD.

Contributi Chiave

1. Identificazione del Problema: Il documento identifica che le politiche esistenti di espulsione della cache KV degradano le prestazioni agentic ignorando i ritardi di coda per turno e la variabilità delle durate delle chiamate a strumenti.
2. Sistema CacheTTL: Un nuovo sistema di servizio che utilizza un meccanismo TTL per ritenere dinamicamente le cache KV. Bilancia i costi di prefill/ricarica contro i costi di contenzione della memoria.
3. Modello di Costo Innovativo: L'introduzione del termine OutofOrderCost, che quantifica la penalità di ritardo di coda dell'espulsione, e del fattore di memoria per adattarsi a diverse strutture di carico di lavoro.
4. Robustezza: Il sistema gestisce durate degli strumenti imprevedibili imponendo un tempo di ritenzione massimo, prevenendo deadlock e pressione sulla memoria.

Risultati Sperimentali

Gli autori hanno valutato CacheTTL utilizzando Llama-3.1 (8B/70B), Gemma-3 (12B) e GLM-4.5 (355B) su carichi di lavoro SWE-Bench, BFCL e OpenHands su vari hardware (A100, H100, B200).

• Riduzione della Latenza: CacheTTL riduce il tempo medio di completamento del lavoro di 1,12x a 3,66x rispetto alle baseline (vLLM, Autellix, InferCept). Nei test reali con agenti SWE sul banco di prova interno dell'Azienda A, ha raggiunto un miglioramento dei ritardi fino a 8,18x.
• Throughput: Il throughput è migliorato di 1,10x a 3,22x.
• Robustezza: Il sistema mantiene prestazioni stabili all'aumentare del numero di turni, mentre le baseline degradano significativamente a causa dei ritardi di coda accumulati.
• Compatibilità: CacheTTL supera le baseline anche quando combinato con il caricamento su CPU e SSD, dimostrando che i suoi vantaggi di pianificazione sono ortogonali alle tecniche di offloading della memoria.
• Overhead: L'overhead di pianificazione è trascurabile (singole cifre in millisecondi), ampiamente compensato dai risparmi di latenza end-to-end.

Significato e Affermazioni

Il documento afferma che CacheTTL fornisce la prima strategia robusta e consapevole degli strumenti per la gestione della cache KV, progettata specificamente per carichi di lavoro agentic multi-turno. Spostandosi dall'espulsione "a fine turno" a una politica di ritenzione basata su TTL, il sistema colma efficacemente il divario tra l'inferenza LLM e l'esecuzione di strumenti esterni.

Gli autori sottolineano che il loro approccio è modulare e può essere integrato nei motori di inferenza esistenti con modifiche minime. Sostengono che una gestione della KV consapevole degli strumenti e basata su principi è essenziale per il futuro del servizio efficiente degli agenti, in particolare man mano che i flussi di lavoro agentic diventano più complessi e multi-turno. Il documento conclude rendendo open source le loro tracce, il codice e il banco di prova per favorire ulteriori ricerche nel servizio degli agenti.