💬 NLP

Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks

Questo articolo presenta una valutazione completa del prompt caching attraverso tre principali provider di LLM per compiti agentici a lungo termine, dimostrando che tecniche di caching strategiche — come l'esclusione dei risultati dinamici degli strumenti e la gestione della struttura del prompt — possono ridurre i costi delle API del 41–80% e migliorare il tempo al primo token (time to first token) del 13–31% rispetto al caching ingenuo dell'intero contesto.

Autori originali: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Pubblicato 2026-02-03

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di assumere un brillante ma costoso assistente alla ricerca per risolvere un mistero complesso. Questo assistente deve leggere un enorme manuale di istruzioni (il "system prompt") prima di iniziare a lavorare. Mentre lavora, effettua decine di telefonate a diverse fonti, ottiene le risposte e le annota in un taccuino.

Ogni volta che effettua una nuova telefonata, deve rileggere l'intero manuale di istruzioni dalla prima pagina per ricordare cosa fare. Questo richiede molto tempo e costa molto denaro perché l'assistente viene pagato in base alle pagine che legge.

Il "Prompt Caching" è come se dessi a questo assistente un evidenziatore magico. Se il manuale di istruzioni non è cambiato, l'assistente può saltare la rilettura del primo 90% del libro e passare direttamente alla parte nuova dove si trovano i risultati delle telefonate. Questo fa risparmiare tempo e denaro.

Tuttavia, questo articolo pone una domanda spinosa: il magic highlighter funziona sempre, o possiamo rovinarlo?

I ricercatori hanno testato questo scenario con tre grandi aziende di "assistenti" (OpenAI, Anthropic e Google) utilizzando un benchmark chiamato DeepResearch Bench, dove gli agenti compiono ricerche sul web lunghe e multi-step per rispondere a domande difficili. Hanno provato tre modi diversi per usare l'evidenziatore:

L'approccio "Naive" (Full Context): Evidenziare tutto, inclusi i risultati delle nuove telefonate.
L'approccio "Sticky Note" (Solo System Prompt): Evidenziare solo il manuale di istruzioni, lasciando i risultati delle nuove telefonate non evidenziati.
L'approccio "Clean Break" (Escludere i Tool Results): Evidenziare il manuale e le telefonate, ma inserendo un segnale di "stop" speciale dopo ogni nuovo risultato, in modo che l'evidenziatore non prenda accidentalmente gli appunti disordinati della persona successiva.

Cosa hanno scoperto

1. Fa risparmiare un sacco di soldi (La vittoria del "Portafoglio")
Indipendentemente dal metodo utilizzato, il magic highlighter ha fatto risparmiare una grande quantità di denaro. A seconda dell'azienda, hanno risparmiato tra il 41% e l'80% del conto.

Analogia: È come rendersi conto di non dover comprare una nuova tessera della biblioteca ogni volta che si entra in biblioteca; si usa semplicemente quella che si ha già.

2. La velocità è complicata (Il problema del "Traffico")
Sebbene risparmiare denaro fosse facile, risparmiare tempo era più difficile.

La sorpresa: A volte, evidenziare tutto (l'approccio Naive) rendeva l'assistente effettivamente più lento.
Analogia: Immagina un corriere che cerca di memorizzare l'indirizzo di ogni singolo pacco che consegna. Se prova a memorizzare un pacco che viene consegnato una sola volta e mai più, spreca tempo a memorizzarlo. Quando arriva il pacco successivo, deve "disimparare" il vecchio per fare spazio al nuovo. Questo processo di "scrittura nella memoria" lo rallenta.
Il documento ha scoperto che se evidenzi solo le parti stabili (il manuale di istruzioni) e lasci le parti disordinate e mutevoli (i risultati delle telefonate) da sole, l'assistente rimane veloce.

3. La regola del "Non rompere la cache"
La lezione più importante riguarda dove si traccia la linea.

Se inserisci informazioni dinamiche e mutevoli (come "Ora corrente: 14:00" o "ID Utente: 123") all'interno del manuale di istruzioni, il tuo magic highlighter si rompe. Il sistema pensa che il manuale sia cambiato, quindi smette di evidenziare e ricomincia a leggere da capo.
La soluzione: Mantieni il manuale di istruzioni puro e statico. Se devi includere informazioni variabili, mettile alla fine del manuale, come un post-it sull'ultima pagina. In questo modo, il primo 99% del manuale rimane evidenziato e riutilizzabile.

In sintesi

Per le aziende che costruiscono agenti IA impegnati in compiti lunghi e complessi:

Sì, usate il prompt caching. Ridurrà drasticamente i vostri costi.
Ma, siate intelligenti. Non attivatelo semplicemente per tutto.
La migliore strategia: Evidenzia solo la parte stabile (il System Prompt). Lascia che le parti variabili (i tool results) fluiscano liberamente senza essere messe in cache. Questo ti darà il miglior mix di basso costo e alta velocità.

Se provi a mettere in cache le parti mutevoli, potresti finire per pagare per la "scrittura" della cache senza ottenere i benefici della "lettura", il che può effettivamente rallentare il tuo sistema.

Riepilogo Tecnico: Non rompere la cache: Una valutazione del prompt caching per compiti agentici a lungo orizzonte

Definizione del Problema

I recenti progressi negli agenti basati su Large Language Model (LLM) hanno abilitato compiti agentici complessi e multi-turno che coinvolgono estese chiamate a strumenti (tool calling), come la ricerca approfondita e la programmazione autonoma. Questi flussi di lavoro spesso si estendono su decine di chiamate API con finestre di contesto che accumulano decine di migliaia di token, risultando in costi operativi significativi e sovraccarichi di latenza. Sebbene i principali provider di LLM (OpenAI, Anthropic, Google) offrano funzionalità di prompt caching per riutilizzare i tensori chiave-valore (KV) precedentemente calcolati e ridurre la ridondante computazione, i benefici specifici di queste funzionalità per i carichi di lavoro agentici rimangono poco esplorati. La letteratura esistente si concentra sulla gestione della memoria a livello di inferenza o sull'audit della sicurezza, ma manca di un'analisi quantitativa dei risparmi sui costi o di valutazioni comparative delle strategie di caching per sessioni agentiche dinamiche e multi-turno.

Metodologia

Gli autori hanno condotto una valutazione completa del prompt caching attraverso tre dei principali provider di LLM: OpenAI, Anthropic e Google. Lo studio ha utilizzato quattro modelli flagship: GPT-5.2, GPT-4o (OpenAI), Claude Sonnet 4.5 (Anthropic) e Gemini 2.5 Pro (Google).

Configurazione Sperimentale:

Benchmark: La valutazione ha utilizzato il DeepResearch Bench, un benchmark agentico multi-turno in cui gli agenti eseguono autonomamente chiamate a strumenti di ricerca web nel mondo reale per rispondere a complesse domande di ricerca di livello PhD.
Scala: Lo studio ha coperto oltre 500 sessioni agentiche con prompt di sistema da 10.000 token. Ogni modello è stato testato con 40 sessioni indipendenti per ogni condizione di cache.
Strategie di Cache: Gli autori hanno implementato e confrontato quattro diverse condizioni per controllare precisamente i confini della cache utilizzando identificatori unici (UUID):
1. Nessuna Cache (Baseline): Un UUID viene preposto al prompt di sistema per forzare la ricalcolazione di tutti i token, simulando uno scenario con contenuti dinamici (es. timestamp) che rompono la cache.
2. Full Context Caching (Caching del Contesto Completo): Nessun UUID viene aggiunto, permettendo al meccanismo di caching automatico del provider di operare sull'intera cronologia della conversazione, inclusi i risultati dinamici degli strumenti.
3. System Prompt Only Caching (Caching Solo del Prompt di Sistema): Un UUID viene aggiunto alla fine del prompt di sistema, garantendo che solo le istruzioni statiche del sistema vengano memorizzate nella cache, mentre la cronologia della conversazione dinamica e i risultati degli strumenti vengono ricalcolati.
4. Exclude Tool Results Caching (Esclusione del Caching dei Risultati degli Strumenti): Gli UUID vengono aggiunti dopo il prompt di sistema e dopo ogni risultato dello strumento, impedendo esplicitamente ai risultati dinamici degli strumenti di entrare nella cache.

Metriche:
Lo studio ha misurato il costo API (distinguendo tra token standard, letti dalla cache e scritti nella cache) e il Time to First Token (TTFT) come metrica principale di latenza. La significatività statistica è stata determinata tramite t-test per campioni indipendenti ( $\alpha = 0.05$ ).

Contributi Chiave

Prima Valutazione Quantitativa: Questo lavoro fornisce la prima quantificazione completa dei benefici del prompt caching specificamente per compiti agentici a lungo orizzonte attraverso molteplici provider e modelli.
Confronto delle Strategie: Confronta il caching ingenuo del contesto completo con i metodi di controllo strategico dei confini (solo prompt di sistema, esclusione dei risultati degli strumenti), rivelando che gli approcci "naïve" possono essere controproducenti.
Discrepanze tra Provider: Lo studio identifica differenze significative nel modo in cui i provider implementano il caching, in particolare riguardo alla gestione dei contenuti dinamici e al conseguente impatto su latenza e costi.
Insight dall'Ablazione: Attraverso studi di ablazione su dimensioni del prompt (500–50.000 token) e conteggi di chiamate agli strumenti (3–50), gli autori dimostrano benefici lineari universali in termini di costo e TTFT dopo aver soddisfatto i minimi di token specifici del provider.

Risultati

La valutazione ha prodotto tre scoperte primarie:

Riduzioni Sostanziali dei Costi: Il prompt caching ha ridotto costantemente i costi API dal 41% all'80% in tutti i provider e modelli. Il driver principale di questi risparmi è stato il caching del ampio e stabile prompt di sistema.
Variazioni nei Miglioramenti della Latenza: I miglioramenti del TTFT sono variati dal 13% al 31% a seconda del provider e della strategia. Tuttavia, i guadagni di latenza non sono stati uniformi; per alcuni modelli (es. GPT-4o), il caching del contesto completo ha causato una regressione della latenza dell'8,8%.
Il Controllo Strategico dei Confini è Critico: Lo studio ha scoperto che il controllo strategico dei blocchi del prompt cache supera il caching ingenuo del contesto completo.
- Le strategie System Prompt Only ed Exclude Tool Results hanno fornito i benefici più consistenti.
- Il Full Context Caching ha spesso introdotto overhead memorizzando chiamate e risultati dinamici degli strumenti che non vengono riutilizzati nelle sessioni successive, paradossalmente aumentando la latenza.
- Per GPT-4o, la migliore strategia (System Prompt Only) ha migliorato il TTFT del 30,9%, mentre il Full Context Caching ha degradato le prestazioni.

Significato e Rivendicazioni

L'articolo sostiene di fornire una guida sfumata per l'implementazione del prompt caching nei sistemi agentici in produzione. Gli autori sottolineano che, sebbene i provider astraggano gran parte del meccanismo di caching, i professionisti devono esercitare un controllo strategico sui confini della cache.

L'argomento centrale è che nei carichi di lavoro agentici, dove il contesto è dinamico e specifico per sessione, il caching dell'intero contesto (approccio ingenuo) può essere deleterio. Inveve, i professionisti dovrebbero garantire che solo il contenuto stabile e riutilizzabile (come il prompt di sistema) venga memorizzato nella cache, mentre gli elementi dinamici (risultati degli strumenti, cronologia della conversazione) siano esclusi tramite confini espliciti (es. UUID). Questo approccio massimizza l'efficienza dei costi e i miglioramenti della latenza, evitando l'overhead di memorizzare contenuti che non verranno riutilizzati. Il lavoro funge da guida pratica per l'ottimizzazione di sistemi agentici di livello enterprise, evidenziando che la "migliore" strategia di caching è specifica per ogni provider e dipende dall'obiettivo di ottimizzazione (costo vs latenza).