Prompt Caching per LLM: la guida completa 2026

Se metti in produzione un chatbot, un’app RAG o un agente AI basato su un large language model, il prompt caching è l’ottimizzazione singola che ti restituisce il 50–90% del costo di input e da 3 a 10× sul time-to-first-token, senza perdite di qualità. Non è un trucco applicato dall’esterno: deriva direttamente da come è definita l’attenzione nei Transformer. Una volta capito questo, tutto il resto (TTL, differenze tra provider, struttura del prompt) va a posto senza sforzo.

TL;DR

• Il caching dei prompt restituisce il 50-90% del costo di input e un time-to-first-token 3-10x più veloce senza alcun costo in termini di qualità.
• Misurato il 2026-05-25: i marcatori cache_control di Claude riducono il costo di input dell’88-89%; l’auto-cache di GPT-5.4-mini ha portato il TTFT da 3.6s a 0.73s; DeepSeek-v4-flash ha offerto uno sconto del 74% con una cache su disco.
• I brevi TTL esistono perché lo stato KV è enorme: circa 10 GB per un contesto da 32K-token su un modello di classe 70B.
• DeepSeek effettua il caching con granularità a 64-token rispetto al consueto limite minimo di 1,024-token, quindi anche le corrispondenze parziali dei prefissi ottengono comunque sconti.

Questa pagina è l’indice di una serie in cinque parti che parte dalla teoria, arriva a una matrice decisionale per la produzione e scende fino al livello dei framework, dove i prompt vengono effettivamente assemblati. Scegli da dove entrare in base a ciò che già sai.

Da dove iniziare

Ogni parte si regge da sola, ma sono scritte in modo che leggerle in ordine costruisca il quadro completo senza ripetizioni.

Parte 1 — Come funziona il prompt caching per LLM

Come funziona il caching dei prompt LLM: KV Cache e TTL spiegati →

L’articolo architetturale. Ripercorre la self-attention come singola equazione, spiega perché i vettori K e V di un prefisso stabile sono matematicamente riutilizzabili e mostra come il compromesso tra memoria e calcolo produca quel comportamento del TTL con cui ogni sviluppatore deve fare i conti.

Punti chiave:

• Il prompt caching non è un’ottimizzazione aggiunta sopra: è una conseguenza diretta dell’attenzione con maschera causale. K/V alla posizione i è una funzione deterministica dei token 1…i, quindi prefissi identici producono K/V identici bit per bit.
• Il prefill (compute-bound, O(N²)) è ciò che il caching risparmia; il decode (memory-bandwidth-bound, O(N) per token) è ciò che ogni motore di inferenza ottimizza già.
• I TTL esistono perché la KV cache è enorme (~10 GB per un contesto da 32K su un modello da 70B). 5 minuti sono l’orizzonte della pressione sulla memoria della GPU; ore o giorni sono possibili solo con cache su disco (l’architettura MLA di DeepSeek).
• Il caching fa guadagnare sia sul costo (50–90% in meno sull’input in caso di cache hit) sia sulla latenza (il TTFT cala di 3–10× per prompt nell’ordine dei 5–10K token, e molto di più oltre i 100K).

Parte 2 — Confronto del prompt caching LLM tra i provider

Confronto tra Prompt Caching: Claude, GPT-5, Gemini, DeepSeek, Qwen (2026) →

La guida all’acquisto. Cinque provider espongono il prompt caching in cinque forme molto diverse: marker espliciti (Claude), completamente automatico (GPT-5, DeepSeek-v4), ibrido implicito+esplicito (Gemini, Qwen) oppure disk-backing architetturale (l’MLA di DeepSeek). L’articolo mette a confronto le funzionalità una per una e propone un framework di valutazione a 5 dimensioni per assegnare un punteggio in base al tuo workload specifico.

Punti chiave:

• Non confrontare i prezzi base — confronta il costo effettivo ponderato in base al tuo hit rate (formula in §4.1); il confronto dei prezzi degli LLM in tempo reale e il calcolatore dei costi rendono tutto concreto per il tuo carico di lavoro.
• Claude ha lo sconto più profondo per singola chiamata (~90%) ma richiede marcatori cache_control espliciti.
• DeepSeek-v4 è l’unico provider con cache su disco su larga scala; le corrispondenze parziali di prefisso ottengono sconti perché la granularità è di 64 token invece di 1.024.
• La cache esplicita di Gemini comporta costi di archiviazione orari — il punto di pareggio dipende dalla frequenza delle chiamate.
• L’ergonomia dell’API, la prevedibilità dell’hit rate, l’adattamento del TTL, la latenza in caso di miss e il costo di migrazione sono le cinque dimensioni che distinguono davvero i provider una volta controllato l’hit rate.

Parte 3 — Tutorial pratico in Python

Caching dei Prompt LLM in Python: un tutorial pratico con codice →

L’articolo pratico. Un SDK OpenAI + un SDK Anthropic contro un unico gateway, con numeri misurati il 2026-05-25 sull’intera famiglia Claude (da haiku-4-5 a opus-4-7), GPT-5.x, Gemini 2.5, DeepSeek-v4 e Qwen3.

Punti chiave:

• Claude con marker cache_control: riduzione dei costi misurata dell’88–89% in modo uniforme su haiku/sonnet/opus 4-x. Usa l’SDK Anthropic con base_url="https://synthorai.io/".
• Auto-cache di GPT-5.4-mini: TTFT migliorato di 5× (da 3,6 s a 0,73 s su un prompt da 7K token), hit rate della cache del 93% sui token di sistema.
• Gemini 2.5-flash implicito: riduzione dei costi dell’88% sui cache hit quando si cattura l’usage in streaming.
• DeepSeek-v4-flash: 74% di sconto, disk-backed (la cache sopravvive a inattività di ore).
• Pattern TTL-aware: heartbeat keep-alive per i cron, regole di stabilità del prefisso, cosa loggare per ogni chiamata.

Parte 4 — Il modello migliore per caso d’uso

Miglior LLM per Chat, RAG e Agenti: Matrice Decisionale Modello + Costi 2026 →

L’articolo decisionale. Ogni workload agisce sulle leve di costo/latenza in modo diverso: la chat è naturalmente cache-friendly, il RAG combatte contro il problema della stabilità del prefisso, gli agent dipendono dalla disciplina cumulativa sul prefisso. L’articolo consiglia un modello in base alla forma del workload, con stime di costo.

Punti chiave:

• Chatbot: va bene qualsiasi modello con auto-cache; le sessioni fanno hit in modo naturale. Scegli in base a costo/qualità. gpt-5.4-nano è il più economico, gpt-5.4-mini ha il TTFT cached più veloce, claude-haiku-4-5 segue meglio le istruzioni a un sovrapprezzo contenuto.
• RAG: il riordino dei documenti recuperati azzera i cache hit a metà prompt. Tre soluzioni: spostare i riferimenti in fondo, ordinare i chunk in modo deterministico, oppure usare più breakpoint cache_control di Claude.
• Agent: le tool call e i loro risultati devono essere append-only e identici byte per byte a ogni step. claude-sonnet-4-5 con 4 marker cache_control dà lo sconto cumulativo sul prefisso più forte; gpt-5.4-mini funziona senza modifiche al codice con il 50% di risparmio.
• Corrispondenza del TTL: 5 min per la chat, 1 ora per gli agent con step human-in-the-loop, disk-backed per i batch sporadici.

Parte 5 — Integrazione con LangChain

Caching dei Prompt in LangChain: Configurazioni che Colpiscono Davvero la Cache →

L’articolo dedicato al framework. Tutto quello che trovi nelle Parti 1–4 presuppone che tu abbia il controllo dei byte del prompt; LangChain li assembla al posto tuo, e la sua sintassi più comoda disattiva silenziosamente la cache di Claude. Misurato su langchain-core 1.4.8 con un prefisso di system marcato.

Punti chiave:

• Il template a tupla di stringhe ("system", "...") non può trasportare cache_control: attività di cache misurata pari a zero su chiamate identiche. La soluzione è un SystemMessage con content block.
• L’ordine del prompt è la leva sull’hit rate: il contesto RAG recuperato messo prima delle regole statiche ha reso ogni chiamata una cold write, che costa più che non fare caching affatto per via del sovrapprezzo di scrittura di Claude.
• Un marker sul blocco system copre anche i tool bindati; bind_tools serializza in modo byte-stabile, e un marker su un dict di tool in formato Anthropic passa inalterato.
• Agent multi-turn: sposta il marker sull’ultimo messaggio e a ogni turno viene riletto l’intero prefisso precedente scrivendo solo il delta (misurato: read 1.864, write 15).
• Sui modelli a cache automatica (GPT, GLM, DeepSeek) un ordinamento sbagliato fallisce in silenzio: nessun sovrapprezzo, nessun errore, solo uno sconto che non arriva mai. Tieni d’occhio i campi usage.

Come leggere questa serie

• Ingegnere alle prime armi con l’argomento: leggi in ordine. L’architettura della Parte 1 fa scattare tutto il resto nelle Parti 2–4.
• PM o architetto che deve scegliere un vendor: salta alla Parte 2 + Parte 4. Torna alla Parte 1 se un collega ti chiede “ma perché esiste il TTL”.
• Ingegnere con un workload preciso da spedire oggi: prima la Parte 4 (trova la tua riga nella matrice), poi la Parte 3 per il codice esatto.
• Già su LangChain: direttamente alla Parte 5 — i pattern con l’SDK grezzo della Parte 3 si applicano, ma le insidie (template a stringa, posizionamento delle variabili, nomi dei campi usage) sono specifiche del framework.
• Chiunque stia ottimizzando un’app esistente: Parte 3 §6, il benchmark cross-provider — riproducilo sul tuo prompt; è un esercizio da un giorno, non una migrazione di settimane.

I numeri di questa serie

I numeri misurati nelle Parti 1–4 sono stati raccolti il 2026-05-25, mentre le misurazioni LangChain della Parte 5 il 2026-07-04, sul gateway Synthorai (https://synthorai.io/v1 per la compatibilità OpenAI, https://synthorai.io/ per l’API nativa Anthropic), single-tenant, singola esecuzione sequenziale, senza carico concorrente. I tuoi numeri cambieranno con la region, l’ora del giorno e il carico degli altri tenant — prendili come punto di partenza e riproducili sul tuo traffico prima di citarli.

Le tabelle dei prezzi e il comportamento del TTL riflettono la documentazione pubblica dei vendor aggiornata a 2026-05. I provider la aggiornano ogni pochi mesi; il ragionamento architetturale (Parte 1) è stabile, i numeri comparativi (Parti 2 e 3) cambiano nel tempo.

← Torna al blog