Qual è la prompt cache per LLM più economica? Confronto tra 5 provider (2026)

TL;DR: I cinque principali provider di LLM offrono la prompt cache in modi molto diversi: marker espliciti (Claude), gestione completamente automatica (GPT-5.x, DeepSeek-v4), approccio ibrido implicito ed esplicito (Gemini, Qwen) oppure persistenza su disco a livello architetturale (MLA di DeepSeek). Questo articolo li confronta funzionalità per funzionalità e propone un framework di valutazione su 5 dimensioni per assegnare un punteggio in base al tuo workload: costo, prevedibilità dell’hit rate, latenza, adeguatezza del TTL ed ergonomia dell’API. Per i concetti architetturali, leggi la Parte 1: principi della cache; misurazioni e codice Python funzionante sono nella Parte 3: tutorial.

Serie: Parte 2 di 5 · Articolo precedente: Parte 1 — Principi della cache · Articolo successivo: Parte 3 — Tutorial con codice funzionante · Parte 4 — Miglior LLM per caso d’uso · Parte 5 — Integrazione con LangChain

1. Una tassonomia dei tipi di cache per LLM

Prima di esaminare i singoli provider, definiamo quattro assi progettuali.

1.1 Controllo: esplicito, implicito o ibrido

• Esplicito: lo sviluppatore indica quali parti del prompt memorizzare nella cache (Anthropic Claude cache_control). Offre il massimo controllo, ma richiede modifiche al codice.
• Implicito / automatico: il provider rileva automaticamente i prefissi corrispondenti (OpenAI GPT-5.x, DeepSeek-v4). Non richiede modifiche al codice, ma non consente di forzare un hit.
• Ibrido: sono disponibili entrambe le modalità, selezionabili per ogni chiamata (Gemini, Qwen).

1.2 Persistenza: in-memory o su disco

Dipende dall’architettura della KV cache del provider, non dall’interfaccia API.

• In-memory (HBM): le cache risiedono nella memoria della GPU, durano poco (alcuni minuti) e richiedono blocchi minimi grandi (1,024 token). È l’opzione predefinita per la maggior parte dei provider.
• Su disco: le cache persistono su SSD/NVMe, con TTL molto più lunghi e granularità più fine. DeepSeek usa questa soluzione su larga scala grazie alla compressione Multi-head Latent Attention (MLA), che riduce la KV cache di ~4× (DeepSeek-AI, 2024).

1.3 Granularità: risoluzione del matching

Quanto può essere corto un prefisso per ottenere lo sconto?

• 64 token: DeepSeek (la granularità più fine del settore)
• 128 token: OpenAI (incremento di matching)
• 1,024 token: blocco minimo memorizzabile nella cache per Claude, OpenAI, Gemini e Qwen

Una granularità più fine permette di sfruttare anche le corrispondenze parziali del prefisso, tollerando meglio piccole variazioni nel prompt.

1.4 Modello degli oggetti: marker per chiamata o oggetti cache con nome

• Marker per chiamata: ogni richiesta include direttamente il contenuto da memorizzare; il provider ne calcola l’hash (Claude, OpenAI, DeepSeek, modalità implicita di Qwen).
• Oggetti cache con nome: lo sviluppatore crea una cache tramite una chiamata API separata, riceve un cache_id e lo usa nelle richieste successive (modalità esplicita di Gemini e Qwen). Richiede più passaggi, ma offre un controllo esplicito sul ciclo di vita.

Questi quattro assi interagiscono tra loro. L’offerta di ogni provider dipende dalla posizione che occupa su ciascun asse. La sezione seguente li analizza uno per uno.

2. Analisi dei singoli provider

2.1 Anthropic Claude: Esplicita, in-memory, granularità di 1,024 token

Modelli principali (2026-05): claude-haiku-4-5, claude-sonnet-4-5 / 4-6, claude-opus-4-5 / 4-6 / 4-7.

Aggiornamento GPT-5.6 (2026-06): con la famiglia GPT-5.6, le regole riportate sotto sono cambiate. Le scritture in cache vengono ora fatturate a 1.25x rispetto alla tariffa di input, per un matching affidabile è necessario un prompt_cache_key e sono stati aggiunti breakpoint espliciti con TTL di 30 minuti. Le righe di questo articolo descrivono il comportamento di GPT-5.5/5.4; per la versione 5.6 consulta la guida ai costi di GPT-5.6 e le nostre misurazioni delle dimensioni minime della cache.

API della cache. È possibile inserire fino a quattro breakpoint cache_control in qualsiasi punto del system prompt o dell’array dei messaggi. Gli hit costano ~10% della tariffa base di input; le scritture costano il 125% (un sovrapprezzo del 25%). Il TTL predefinito è 5 minuti con scadenza sliding (ogni hit lo azzera), con un’opzione da 1 ora.

Struttura dei prezzi. Anthropic pubblica sul proprio listino le tariffe per milione di token per ciascun modello; lo sconto della cache è uniforme in tutta la famiglia. Con un system prompt da 8,000 token e 100K chiamate al giorno su claude-sonnet-4-5, una volta riscaldato il prefisso il costo per chiamata scende di circa 8-10×. Il punto di pareggio arriva dopo un solo hit.

Comportamento del TTL. Il valore predefinito è 5 minuti sliding: ogni hit sposta la scadenza in avanti di altri 5 minuti. Il TTL di 1 ora raddoppia il costo di scrittura, ma è indispensabile per i workload con periodi di inattività superiori a 5 minuti.

Granularità. Minimo 1,024 token. L’hash viene calcolato sull’esatta sequenza di token; la modifica di un solo carattere all’inizio invalida l’intero prefisso.

Ergonomia dell’API. La migliore. I breakpoint multipli permettono di gestire separatamente le sezioni che “non cambiano mai”, “cambiano raramente” e “cambiano per ogni task”. È l’implementazione migliore per agenti e workload RAG in cui le sezioni del prompt cambiano con frequenze diverse.

Problemi da considerare.

• Senza cache_control non viene usata alcuna cache: a differenza di GPT o DeepSeek, non esiste un fallback implicito.
• L’hash della cache dipende dall’ordine anche negli array di tool e funzioni: ordinali in modo deterministico.
• Senza un keep-alive esplicito, il TTL predefinito di 5 minuti rende Claude poco adatto ai batch job sporadici.
• Se chiami Claude tramite un gateway, verifica che supporti il percorso nativo Anthropic /v1/messages con i marker cache_control (in genere il percorso OpenAI-compatible /chat/completions non li propaga: usa l’SDK Anthropic configurato con il base URL del gateway).

Ideale per. Agenti con contesto lungo, chat multi-turn con system prompt stabili, RAG strutturato con cache su più livelli.

2.2 OpenAI GPT-5.x: Automatica, in-memory, granularità di 1,024 token

Modelli principali (2026-05): gpt-5.4-nano, gpt-5.4-mini, gpt-5.2, gpt-5.4-pro, gpt-5.5-pro. Varianti Codex per il codice: gpt-5.2-codex, gpt-5.3-codex.

API della cache. Non serve fare nulla: si attiva automaticamente per ogni richiesta ≥1,024 token. Gli hit vengono fatturati al 50% della tariffa di input, senza sovrapprezzo in scrittura. Incremento di matching: 128 token.

Struttura dei prezzi. OpenAI pubblica sul proprio listino le tariffe per milione di token. L’input memorizzato nella cache costa il 50% in meno; il prezzo dell’output non cambia.

Misurazioni (2026-05-25, system prompt da ~6,900 token):

* Il completamento di gpt-5.4-mini durante il test con hit era molto più corto di quello con miss; la differenza di costo combina quindi lo sconto della cache e la diversa lunghezza del completamento. Il calo della latenza di 5× (3.63 → 0.73 s) è il dato più affidabile.

Comportamento del TTL. Il valore esatto non è documentato; le osservazioni sul campo indicano 5-60 minuti, a seconda del carico e della popolarità del prefisso. I prefissi condivisi più popolari durano più a lungo, perché l’LRU li favorisce.

Ergonomia dell’API. Minimo sforzo: il codice esistente continua a funzionare. Registra prompt_tokens_details.cached_tokens per misurare l’hit rate.

Problemi da considerare.

• Non è possibile forzare un hit. Se il traffico genera prefissi unici, la cache non offre alcun vantaggio.
• Lo sconto del 50% è inferiore al 90/75% di Claude e DeepSeek (ed è in linea con il ~25% della modalità implicita di Gemini).
• In streaming, gli hit della cache vengono talvolta riportati solo nel chunk finale: cura bene l’instrumentation e passa stream_options={"include_usage": True}.

Ideale per. Codebase che usano già GPT, quando il costo del retrofit supera il risparmio marginale. Traffico a raffiche con un’elevata ripetizione naturale dei prefissi.

2.3 Google Gemini: Ibrida, in-memory, oggetti cache con nome

Modelli principali (2026-05): gemini-2.5-flash, gemini-2.5-pro, gemini-3-flash-preview, gemini-3.1-pro-preview, gemini-3.1-flash-lite-preview.

API della cache. Sono disponibili due modalità:

• Implicita: automatica, come GPT. I token in cache vengono fatturati a ~25% della tariffa di input. Nessun costo di storage e nessuna configurazione.
• Esplicita: crea un oggetto cachedContent tramite una chiamata API separata e referenzialo per nome nelle richieste successive. I token in cache vengono fatturati a ~10%, quindi meno, ma si paga un costo di storage orario per milione di token.

Struttura dei prezzi. Il punto di forza di Gemini è il contesto lungo; i prezzi variano in base alla categoria di lunghezza del contesto, con soglie sotto e sopra 200K e tariffe per token più alte oltre tale valore.

Misurazioni (2026-05-25):

Comportamento del TTL. Implicita: alcuni minuti, valore non dichiarato. Esplicita: impostato dallo sviluppatore, 1 ora per impostazione predefinita, fino a 24 ore.

Ergonomia dell’API. La cache esplicita richiede un flusso in 2 passaggi (creazione → riferimento). Devi gestire il ciclo di vita di cachedContent: creazione, aggiornamento del TTL ed eliminazione.

Problemi da considerare.

• Il costo di storage annulla il vantaggio delle cache esplicite a basso volume. Calcola sempre il punto di pareggio in base alla frequenza delle chiamate.
• L’hit rate della cache implicita è variabile: non usarlo come dato certo nei modelli di costo.
• Gli oggetti cache sono vincolati alla regione; le applicazioni multi-region devono duplicarli.
• gemini-*-pro è un modello di reasoning: con un max_tokens basso, il completamento viene assorbito dal ragionamento nascosto e vedrai completion_tokens=0. Imposta max_tokens ad almeno 256 in qualsiasi flusso rivolto agli utenti.

Ideale per. Un singolo documento di grandi dimensioni (>20K token) interrogato più di 10 volte l’ora. Domande e risposte su video. RAG multimodale su PDF aziendali.

2.4 DeepSeek-v4: Automatica, su disco, granularità di 64 token

Modelli principali (2026-05): deepseek-v4-flash (general purpose), deepseek-v4-flash (in questa generazione copre anche i workload di coding).

API della cache. Automatica, come GPT, ma basata sulla compressione MLA, che rende la cache abbastanza compatta da poter persistere su disco. Gli hit vengono fatturati a ~25% della tariffa di input, senza sovrapprezzo in scrittura. Matching minimo: 64 token.

Struttura dei prezzi. Le tariffe pubblicate da DeepSeek sono denominate in yuan. Un hit riduce il costo dell’input di circa il 75%.

Misurazioni (2026-05-25):

Comportamento del TTL. Ore, talvolta anche di più per i prefissi ad alto traffico. Lo storage su disco permette alle cache di sopravvivere alla pressione sulla memoria GPU che, presso altri provider, causerebbe l’espulsione delle cache in-memory.

Granularità. Il minimo di 64 token è il più basso del settore. Piccole modifiche al prompt mantengono valida la maggior parte del prefisso, invece di invalidarlo completamente come accade con i provider che richiedono 1,024 token.

Ergonomia dell’API. API compatibile con il formato OpenAI: basta cambiare il base URL. Usa il campo standard prompt_tokens_details.cached_tokens.

Problemi da considerare.

• Funziona solo con i modelli della famiglia DeepSeek. La cache non può essere usata con altre famiglie di modelli.
• La qualità in inglese è ottima, ma resta inferiore a Claude/GPT-5.x nei benchmark di reasoning più difficili.

Ideale per. Workload in cinese attenti ai costi. Workload con prefissi ad alta frequenza in cui la granularità è importante, come RAG con ordine dei risultati instabile. Batch job sensibili ai costi.

2.5 Alibaba Qwen3: Ibrida, in-memory, oggetti cache con nome + modalità implicita

Modelli principali (2026-05): qwen3-max, qwen3.5-plus, qwen3.5-flash. Varianti vision: qwen3-vl-plus, qwen3-vl-flash.

API della cache. Sono disponibili due modalità:

• Implicita: sempre attiva, come GPT. La parte in cache viene fatturata a ~20% della tariffa di input.
• Esplicita: crea una cache tramite API con un TTL personalizzato. Gli hit costano ~10%, le scritture il 125%.

Misurazioni (2026-05-25):

Comportamento del TTL. 5 minuti per impostazione predefinita, configurabile per ogni oggetto cache. Finestra sliding per la modalità esplicita; TTL fisso e breve per quella implicita.

Ergonomia dell’API. La modalità implicita usa il formato GPT e non richiede lavoro. Quella esplicita prevede un flusso in 2 passaggi e la gestione del ciclo di vita della cache.

Problemi da considerare.

• Al momento, solo qwen3-max e qwen3.5-plus supportano la cache esplicita.
• La disponibilità multi-region, Singapore e Stati Uniti, è ancora in fase di rollout: verifica la regione prima di usarla per dati esterni alla Cina.
• La documentazione è meno completa rispetto a quella di Anthropic/OpenAI: sono consigliati test empirici.

Ideale per. Workload aziendali in cinese che richiedono un controllo preciso della cache. Clienti già su Alibaba Cloud.

3. Confronto diretto

3.1 Struttura degli sconti (documentazione dei provider, 2026-05)

3.2 TTL, granularità e persistenza

3.3 Latenza misurata con un prefisso da 7K token (2026-05-25)

† I dati di Claude sono stati misurati con i marker cache_control tramite l’endpoint nativo Anthropic /v1/messages (vedi Parte 3 §2). Il vantaggio principale di Claude è il costo (~88-89% in meno sull’input; per la tabella completa dei costi, vedi Parte 3 §2); secondo i dati pubblicati da Anthropic, il miglioramento del TTFT aumenta drasticamente con prompt da almeno 100K token.

Singola esecuzione sequenziale, senza carico concorrente. I risultati variano in base alla regione, all’orario e al carico generato dagli altri tenant.

4. Framework di valutazione su 5 dimensioni

Titoli come “Claude fa risparmiare il 90%” sono interessanti, ma raramente aiutano a scegliere. Valuta ogni provider sulle cinque dimensioni seguenti in base al tuo workload, poi assegna a ciascuna il peso che ritieni più importante.

4.1 Costo effettivo per milione di token, ponderato per l’hit rate

Non confrontare i prezzi base. Confronta il costo atteso in base al tuo hit rate reale: inserisci i tuoi valori nel calcolatore dei costi LLM oppure consulta il confronto aggiornato dei prezzi degli LLM tra i diversi provider:

effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate

Esempio con il 70% di ripetizione del prefisso, tipico di un chatbot:

• Claude: ~90% di sconto × 0.7 hit + 25% di scrittura × 0.3 → costo effettivo ≈ base × 0.45
• GPT-5.5: ~50% × 0.7 + 0 → costo effettivo ≈ base × 0.65
• Gemini implicita: ~75% × 0.7 + 0 → costo effettivo ≈ base × 0.48
• DeepSeek-v4: ~75% × 0.7 + 0 → costo effettivo ≈ base × 0.48

Moltiplica il risultato per la tariffa base effettiva di ogni provider, che varia da uno all’altro, per ottenere un importo in dollari confrontabile. Punteggio: calcola effective_cost per il tuo workload; più basso è, meglio è.

4.2 Prevedibilità dell’hit rate

• Cache esplicite (Claude, Qwen esplicita, Gemini esplicita): prevedibilità elevata. Se il contenuto è stato marcato, genera un hit entro il TTL.
• Cache automatiche (GPT-5.x, DeepSeek-v4, Gemini implicita, Qwen implicita): dipendono dalla somiglianza del prefisso e dal carico del provider, a causa dell’espulsione LRU.

Se il costo è legato a uno SLA, scegli una cache esplicita. Per un’ottimizzazione best effort, quella automatica è sufficiente.

4.3 Compatibilità tra TTL e frequenza del traffico

4.4 Latenza in caso di cache miss

Un provider veloce sugli hit ma lento sui miss resta problematico se l’hit rate non è elevato. Confronta entrambi i valori della §3.3 e ponderali in base all’hit rate previsto.

4.5 Ergonomia dell’API e costo della migrazione

• Migrazione minima: GPT-5.x ↔ DeepSeek-v4 (entrambi usano il formato OpenAI ed entrambi gestiscono la cache automaticamente).
• Media: GPT-5.x → Gemini implicita (SDK diverso, ma nessun codice della cache da riscrivere).
• Alta: GPT-5.x → Claude (occorre aggiungere cache_control e ristrutturare i livelli del prompt).
• Massima: da un singolo provider a più provider senza gateway (più API di cache).

5. Scelte rapide per tipo di workload

6. Considerazioni sulla migrazione

Se dalla valutazione emerge che conviene cambiare provider, pianifica questi tre aspetti:

Spostamento dei dati. I prefissi memorizzati nella cache non si trasferiscono tra provider: ogni cambio comporta un cold start. Prevedi diverse ore di costi superiori alla norma durante il warm-up.

Riprogettazione dei prompt. Il sistema a breakpoint multipli di Anthropic favorisce una struttura del prompt a livelli, che in realtà funziona meglio con qualsiasi provider. Un singolo refactoring migliora quindi anche i flussi che non usano Claude.

Hedging tramite gateway. Se non hai ancora deciso, instrada il traffico tramite un Token Gateway. Mantieni la possibilità di cambiare provider senza vincolarti a un singolo vendor, al costo di un hop aggiuntivo e, a seconda del gateway, della possibile perdita dei controlli specifici del provider sulla cache. La Parte 3 §9 spiega cosa fa davvero il gateway Synthorai e quali affermazioni vanno trattate con cautela.

7. Cosa cambia nel tempo

Questi confronti non sono immutabili: i numeri riportati nell’articolo cambieranno. La cache è diventata un elemento di competizione sui prezzi e i provider aggiornano le offerte ogni pochi mesi. Due aspetti da monitorare:

• Estensione dei TTL. L’opzione da 1 ora di Anthropic è GA; Gemini potrebbe arrivare a più giorni. Il TTL diventerà probabilmente un problema meno rilevante.
• Granularità. OpenAI e Anthropic potrebbero prima o poi ridurre il minimo di 1,024 token; i 64 token di DeepSeek hanno fissato un nuovo riferimento.

Quando gli sconti convergeranno, a fare la differenza saranno l’ergonomia dell’API e la latenza, non la percentuale di risparmio dichiarata.

Prossimo articolo: la Parte 3, Tutorial sulla prompt cache: Python funzionante trasforma il quadro architetturale descritto sopra in codice eseguibile e riproduce la tabella delle latenze della §3.3 sotto forma di benchmark da eseguire in autonomia.

FAQ

Quale provider di LLM offre la prompt cache più economica nel complesso? A parità di hit rate (~75%), nelle nostre misurazioni del 2026-05 deepseek-v4-flash per i workload in cinese e la modalità implicita di gemini-2.5-flash per quelli in inglese hanno il costo effettivo per milione più basso. claude-sonnet-4-5 offre lo sconto maggiore sulla singola chiamata (~90%), ma ha un prezzo base più alto: diventa la scelta migliore quando l’hit rate supera l’85%. Inserisci il tuo hit rate nella formula della §4.1.

Perché Gemini costa di più sui workload a basso volume? Il costo di storage orario delle cache esplicite annulla lo sconto se la cache non viene interrogata spesso. Per i workload a basso volume, usa la cache implicita di Gemini: nessun costo di storage e ~25% di sconto.

Posso usare cache_control di Claude con OpenAI? Non direttamente: sono implementazioni della cache separate. Nell’endpoint OpenAI-compatible /chat/completions, il campo in genere non produce effetti sui modelli non Anthropic, che usano comunque la cache automatica. Per Claude, usa l’endpoint nativo Anthropic /v1/messages con i marker.

L’architettura MLA di DeepSeek è proprietaria? Il paper (DeepSeek-AI 2024) è pubblico. Altri provider potrebbero adottare una compressione della KV cache simile a MLA, ma servirebbe riaddestrare il modello base: non è una funzionalità attivabile a runtime. Al 2026-05, DeepSeek resta l’unico grande provider a usarla in produzione.

E i modelli open source in self-hosting? vLLM, SGLang e altri inference engine supportano nativamente il prefix caching, basato sul paper PagedAttention. In self-hosting su H100/H200, puoi implementare una cache su disco con LMCache o strumenti simili. L’analisi dei prezzi di questo articolo riguarda solo i servizi gestiti: i costi del self-hosting seguono logiche completamente diverse. Se vuoi un routing multi-provider senza gestire direttamente il router, un’alternativa gestita a LiteLLM mantiene una sola API sugli stessi provider senza perdere la cache. La mappa della prompt cache per gli LLM open-weight mostra quali modelli usano la cache, dove e quali host la offrono come prodotto.

Perché il confronto non include Mistral, Cohere o i provider delle API Llama? Al 2026-05, le loro soluzioni di cache sono meno mature. Quella di Mistral è in early access; Cohere non espone una cache esplicita; i provider delle API Llama (Groq, Together, Replicate) hanno offerte molto diverse tra loro. Il confronto andrà aggiornato quando queste funzionalità saranno più stabili.

Fonti: Prompt cache di Anthropic · Prompt cache di OpenAI · Cache del contesto di Google Gemini · KV cache di DeepSeek · Cache del contesto di Alibaba Bailian · Paper DeepSeek-V2 / MLA · PagedAttention / vLLM (Kwon et al. 2023). Misurazioni eseguite tramite https://synthorai.io/v1 il 2026-05-25.

← Torna al blog