Cache degli LLM open-weight: perché dipende dalla roulette dei provider

Con un modello closed, il prompt caching segue un unico contratto documentato. Claude usa breakpoint cache_control; OpenAI e Gemini attivano automaticamente la cache oltre una soglia di token; gli sconti sono pubblici e stabili. Basta leggere una pagina.

Con i modelli open-weight questa certezza viene meno. Lo stesso checkpoint Qwen o Llama viene servito da una dozzina di host e la cache non è una proprietà del modello, ma dell’ambiente in cui gira. Per capire fino a che punto, abbiamo inviato sei volte lo stesso prompt da ~4.7K token allo stesso modello Qwen tramite un router multi-provider, senza fissare l’upstream:

Stesso modello, stesso router, stesso prompt: il costo è variato da $0.0141 a $0.000286, con uno scarto di 49×, solo in base all’upstream scelto dal router e alla presenza del prefisso nella sua cache.

Riepilogo

• Per i modelli open-weight, il prompt caching dipende dal routing, non dal modello. Viene implementato gratuitamente e in automatico nell’inference engine, ma ogni livello superiore può conservarlo o vanificarlo.
• Cinque livelli: uno fornisce la cache, tre possono comprometterla. Il modello (determina la cacheability, ma non serve alcuna cache) → l’inference engine (cache gratuita) → il compute host (la trasforma in un prodotto, con risultati disomogenei) → il gateway (routing multi-cluster) → il router (distribuisce le richieste tra vendor con cache separate).
• Dati misurati. Una richiesta identica, distribuita da un router, è costata 49× di più con un upstream rispetto a un altro; per uno stesso modello, un host ha applicato uno sconto del 59.6% e un altro dello 0%; gli sconti pubblicati per la cache vanno dallo 0% a ~98% a seconda del modello.
• Come intervenire. Fissa il route affinché i prefissi ripetuti raggiungano la stessa cache warm; verifica la differenza di costo, non il campo cached_tokens, che spesso resta a 0 anche in caso di hit reale; valuta la latenza separatamente: i prefill warm sono 2-10× più veloci anche con uno sconto sul costo pari a ~0%.

I dati live sono stati misurati il 2026-06-14 su un router multi-provider e sul nostro gateway, usando un prompt fisso in inglese da ~4.7K token, un valore ridotto di max_tokens ed esecuzioni sequenziali. I prezzi documentati sono stati verificati lo stesso giorno sulle fonti primarie dei provider e sottoposti a controllo incrociato. I rapporti (sconto percentuale e variazione della latenza) sono il dato più generalizzabile; gli importi assoluti dipendono dalla piattaforma, dal prompt e dal carico. Ripeti il test prima di citare questi valori.

I tipi di cache che incontrerai davvero

Prima di esaminare lo stack, serve chiarire la terminologia. Gli host open-weight offrono quattro tipi distinti di cache, con modelli di fatturazione diversi.

1. Cache automatica dei prefissi (senza marker). È la soluzione più diffusa. Il server calcola l’hash del prefisso del prompt, riutilizza lo stato KV se corrisponde a una richiesta precedente e applica autonomamente lo sconto. Non servono cache_control né modifiche al codice e spesso non è possibile disattivarla. DeepSeek, Zhipu GLM e la maggior parte degli host open-weight funzionano così. Le scritture sono gratuite; la cache può restare in VRAM per alcuni minuti oppure su disco. DeepSeek conserva i prefissi da “alcune ore ad alcuni giorni”.

2. Cache con breakpoint espliciti (cache_control). È il modello adottato da Anthropic e offerto anche da alcuni host open-weight. Model Studio di Alibaba accetta "cache_control": {"type": "ephemeral"} in un blocco di messaggio Qwen; alcune piattaforme di serving espongono un marker equivalente. Si indica il limite della cache, si paga un sovrapprezzo in scrittura e si ottiene in cambio uno sconto maggiore in lettura.

3. Oggetti cache a noleggio (con costo di storage). È il caso a cui prestare maggiore attenzione. La famiglia legacy moonshot-v1 di Moonshot richiede una chiamata POST /v1/caching per creare una cache, poi applica un costo di scrittura, un costo di storage per token e per minuto e un costo per ogni hit. La cache esplicita di Gemini segue lo stesso modello: costo di input più storage, circa $1.00-$4.50 per 1M token all’ora. La cache diventa una risorsa a noleggio da eliminare quando non serve più.

4. Riutilizzo KV in self-hosting (gratuito). Se esegui direttamente i pesi, l’inference engine gestisce la cache in automatico e senza costi aggiuntivi. Nessun costo di scrittura, lettura o storage: un hit evita semplicemente il prefill.

Qwen su Model Studio offre entrambe le modalità, automatica ed esplicita, con un compromesso concreto: in modalità implicita, un hit costa il 20% dell’input e le scritture sono gratuite; in modalità esplicita, un hit costa il 10% dell’input, ma la scrittura viene fatturata al 125% e la voce ha un TTL di 5 minuti. Lo sconto è maggiore, ma si paga per popolare la cache e di nuovo a ogni scadenza.

Dove si trova la cache nello stack

Il concetto chiave è questo: per i modelli open-weight, il prompt caching è risolto a un solo livello e messo a rischio da tutti quelli superiori. Risaliamo lo stack a partire dai pesi. Per ogni livello bisogna chiedersi se fornisce la cache o si limita a inoltrarla, e se può compromettere ciò che il livello inferiore ha già fatto.

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

Livello 1: Il modello: cacheability, non cache

Molti pensano che la cache risieda qui, come nell’affermazione “DeepSeek ha la cache”. Conviene quindi chiarire subito il punto. Un checkpoint è un insieme di pesi e usa lo stesso meccanismo di attention, indipendentemente dall’esistenza di una KV cache. Non include cache, sconti, TTL o marker cache_control: sono tutte funzionalità del serving layer. In senso stretto, i pesi non forniscono alcun prodotto di cache.

I pesi, però, non sono neutrali. DeepSeek mostra bene il motivo. L’architettura di attention del modello determina le dimensioni della KV cache e, di conseguenza, il costo minimo che il caching può raggiungere:

• La Multi-head Latent Attention (MLA) di DeepSeek comprime la KV cache in una rappresentazione latente di basso rango, riducendola a circa il 4-14% di una cache multi-head standard. È proprio questa compressione che consente all’API DeepSeek di conservare i prefissi su disco e prezzare una lettura dalla cache a ~2% dell’input. L’architettura è il fattore abilitante; la cache su disco è un prodotto costruito sopra di essa.
• La Grouped-Query Attention (GQA), usata da Llama, Qwen, Mistral e DeepSeek, condivide le head KV per ridurre la cache in base al fattore di raggruppamento (≈8× su Llama-3).

Il contributo del Livello 1 è quindi la cacheability, non la cache. L’architettura stabilisce il limite minimo di costo raggiungibile dai livelli superiori, ma i pesi non servono mai direttamente token dalla cache. Inoltre, dire che “DeepSeek ha la cache” confonde due elementi diversi con lo stesso nome: i pesi (questo livello, che fornisce MLA) e l’API con lo stack di serving di DeepSeek (Livelli 2-3, che forniscono cache su disco, sconto e campi usage). Se scarichi i pesi open-weight e li esegui in proprio, mantieni la KV cache compatta di MLA, ma il prodotto di cache su disco resta sui server DeepSeek. Al suo posto userai il Livello 2 che hai distribuito. La conclusione operativa non cambia: non chiederti se un modello usa la cache, ma dove viene servito. Questo non significa che l’architettura sia irrilevante. L’architettura stabilisce il limite; il percorso della richiesta determina ciò che ottieni davvero.

Livello 2: L’inference engine: dove la cache viene implementata, gratuitamente

Al livello successivo, la cache non è solo presente: è già risolta e gratuita. Gli inference engine moderni memorizzano automaticamente i prefissi:

• vLLM: Automatic Prefix Caching: calcola l’hash di ogni blocco KV, riutilizza i blocchi di cui ha già visto l’hash del prefisso e applica eviction LRU. In V1 è attivo per impostazione predefinita.
• SGLang: RadixAttention: conserva la KV cache in un radix tree, così da riutilizzare ogni prefisso condiviso, con scheduling cache-aware.
• TensorRT-LLM: riutilizzo dei blocchi (enable_block_reuse, attivo per impostazione predefinita), con offload opzionale dei blocchi KV nella memoria host.

Progetti come LMCache estendono ulteriormente il meccanismo, spostando la KV cache su CPU o disco e condividendola tra istanze. È il primo passo verso la soluzione del problema di routing che vedremo tra poco. Il punto è semplice: in self-hosting, la cache è già disponibile. È automatica, non costa nulla oltre alle GPU già in uso, applica eviction LRU e resta sotto il tuo controllo. Un hit salta il prefill, riduce il TTFT e aumenta il throughput. Non esiste un campo di fatturazione cached_tokens, perché non c’è nulla da fatturare; il vantaggio emerge nelle metriche di latenza. Con un modello closed noleggi la cache; con uno open-weight puoi possederla. Rispetto ai servizi hosted, però, il limite è opposto: la cache è effimera, risiede in VRAM ed è soggetta a LRU. Sopravvive solo finché il prefisso resta hot, ed è proprio questo che i livelli superiori devono preservare.

Livello 3: Il compute host: un prodotto offerto in modo disomogeneo

Gli host di inference commerciali aggiungono un wrapper al Livello 2 e gestiscono flotte di repliche. Ereditano la cache automatica gratuita; resta da capire quanto bene la implementino. I risultati variano lungo due dimensioni.

Prima di tutto, visibilità e prezzi cambiano radicalmente. Tra i principali host open-weight, uno applica uno sconto fisso del 50% all’input in cache ed esclude i token memorizzati dai rate limit; un altro applica per impostazione predefinita uno sconto del 50% in modalità serverless; un terzo definisce il prezzo dell’input in cache per ciascun modello, per esempio con un tier Qwen scontato di ~80%, ed espone un suggerimento cache-key per migliorare l’affinity; un quarto mantiene la cache sempre attiva e non consente di disabilitarla sugli endpoint dedicati. Stesso engine di base, quattro strategie di prezzo.

Il secondo aspetto, e il primo punto in cui la cache può rompersi, è il problema delle repliche multiple. Il prefisso warm risiede nella VRAM della replica che ha servito la richiesta cold. Il load balancer dell’host può inviare la richiesta successiva a una replica diversa, con cache cold. È esattamente ciò che abbiamo osservato fissando lo stesso modello Qwen su un upstream alla volta ed eseguendo una sequenza cold→warm:

Il Provider A ha usato correttamente la cache e l’ha indicato nella risposta. Il Provider B, pur pubblicizzando un prezzo di lettura dalla cache per questo modello, non ha applicato alcuno sconto tra una chiamata cold e due chiamate warm nel nostro test. Potrebbe dipendere dai criteri di idoneità, dalla distribuzione tra repliche o da un warm-up che richiede più di due richieste. Su questo percorso, il risultato misurato è stato comunque zero. La funzionalità è risolta al Livello 2; la sua effettiva disponibilità dipende dall’esecuzione al Livello 3 e varia da host a host.

Livello 4: Il gateway: il problema multi-cluster

Un gateway si trova davanti a uno o più upstream e trasforma il problema delle repliche in un problema di cluster. Se distribuisce le richieste in round-robin tra cluster o provider senza cache affinity, la cache warm diventa strutturalmente irraggiungibile: ogni richiesta finisce dove il prefisso non è presente. Un gateway cache-aware deve instradare in base all’hash del prefisso, così che prefissi identici restino associati allo stesso upstream, proprio come al Livello 2 vengono associati agli stessi blocchi KV. Vale sia per un gateway gestito internamente, come LiteLLM, sia per un servizio hosted; i compromessi operativi sono descritti in LiteLLM rispetto a un gateway gestito.

Abbiamo eseguito una serie di test cold→warm su diversi modelli open-weight tramite un gateway di terze parti, leggendo direttamente il cost di ogni richiesta:

DeepSeek-V4 ha raggiunto il 97-99%, segno che l’affinity ha funzionato lungo tutto il percorso. qwen3.5-plus e qwen3-max, invece, hanno prodotto uno sconto di ~0% nella chiamata warm, pur avendo un prezzo di lettura dalla cache nel catalogo. La tabella mostra anche altri due aspetti importanti dei gateway:

• Il campo usage non è affidabile; il costo sì. cached_tokens è rimasto a 0 in tutte le chiamate, comprese quelle con un calo del costo del 99%. Molti gateway compatibili con OpenAI non valorizzano il campo dei token in cache quando l’upstream gestisce la cache automaticamente. Verifica la differenza di cost tra una chiamata cold e una warm, non il campo dei token. È lo stesso approccio usato per verificare le dichiarazioni di un gateway sulla cache.
• La latenza migliora anche quando il costo non cambia. Tutte le chiamate warm sono state 2-10× più veloci. qwen3.5-flash è passato da 10.2s a 1.0s, compresi i casi con uno sconto di ~0%. Un hit evita il prefill indipendentemente dal prezzo applicato dall’host. La cache può quindi ridurre il TTFT anche su un gateway che non offre alcun risparmio economico.

Un gateway che non conserva l’affinity offre una cache irraggiungibile; se non espone il costo della cache, non consente neppure di verificarla.

Livello 5: Il router: distribuzione casuale tra provider

Al livello più alto, un router multi-provider bilancia lo stesso model ID tra cluster appartenenti ad aziende diverse, ognuna con una cache separata. A questo punto neppure un’affinity perfetta all’interno del provider è sufficiente: se la prima chiamata va a un vendor e la seconda a un altro, non esiste una cache condivisa da interrogare. È la dispersione descritta all’inizio dell’articolo e amplifica il problema del Livello 4: non ci sono solo più cluster, ma anche più vendor con stato della cache e prezzi distinti. L’opzione più costosa ha fatturato 20× la tariffa base dell’upstream più economico. La cache è entrata in funzione solo quando il routing ha continuato per caso a usare lo stesso provider.

La soluzione consiste nell’eliminare la casualità: il routing deve essere deterministico, così i prefissi ripetuti raggiungono la stessa cache warm.

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

Il router ha riportato sia cached_tokens (4,224 in caso di hit) sia il cost per richiesta, permettendo di verificare entrambi. Da questo punto di vista ha fatto meglio del gateway al Livello 4, che indicava 0. Resta comunque compito tuo vincolare il routing. La cache è un problema di routing presentato come funzionalità di prezzo: al Livello 2 è gratuita, mentre i Livelli 3, 4 e 5 introducono tre modi sempre più ampi di instradare le richieste lontano dalla cache.

Quanto è profondo lo sconto? Non c’è uno standard

Quando il routing è corretto, quanto si risparmia? Per i modelli closed, lo sconto sulla lettura dalla cache si concentra intorno al 90%. Per gli open-weight, invece, i prezzi pubblicati vanno da sconti quasi simbolici a riduzioni pressoché totali, anche all’interno dell’offerta di un solo vendor. Ecco le tariffe first-party pubblicate:

La cache automatica su disco di DeepSeek offre lo sconto più elevato del settore: deepseek-v4-flash fattura l’input in cache a $0.0028/M rispetto a $0.14/M in caso di miss, con un rapporto di 1:50, valore che abbiamo replicato nel test al Livello 4 con uno sconto del 97.9%. Gli host di terze parti definiscono autonomamente il prezzo dell’input in cache per gli stessi pesi open-weight: alcuni applicano uno sconto fisso di ~50%, altri variano tra ~50% e ~90% in base al modello. Lo sconto dipende quindi dall’host raggiunto, non solo dal modello. Stesso nome della funzionalità, 48 punti percentuali di differenza.

Poiché lo sconto dipende dalla piattaforma, uno stesso modello presenta condizioni economiche diverse in ogni ambiente di serving. deepseek-v4-pro, in quattro configurazioni:

“DeepSeek-V4-Pro supporta la cache” è un’affermazione vera, ma quasi inutile. La domanda operativa è: “Dove supporta la cache, a quale tariffa e con quali dati di reporting?”

Checklist decisionale

• ✅ Il modello stabilisce il limite, non fornisce la cache (Livello 1). L’architettura di attention (MLA, GQA) determina quanto economica può diventare la cache, ma non serve mai direttamente un token memorizzato. Bisogna quindi verificare dove viene servito il modello e come si comporta lo stack dell’host.
• ✅ In self-hosting, la cache è già gratuita (Livello 2). Verifica che la cache automatica dei prefissi sia attiva, come avviene per impostazione predefinita in vLLM/SGLang, e monitora il tasso di hit dei prefissi.
• ✅ Su un compute host, verifica il comportamento reale, non la colonna dei prezzi (Livello 3). Un prezzo per la lettura dalla cache è solo una dichiarazione; misura la variazione del costo tra cold e warm. Usa un suggerimento cache-key per l’affinity, se l’host lo supporta.
• ✅ Con un gateway, richiedi routing con cache affinity e reporting dei costi (Livello 4). Se prefissi identici non restano associati allo stesso upstream o il cost non scende in una chiamata warm, la cache è irraggiungibile o non verificabile.
• ✅ Con un router, fissa l’upstream (Livello 5). Vincola il routing, per esempio specificando l’ordine dei provider e disattivando i fallback. In caso contrario, il load balancing tra cache separate annulla gli hit e può portarti su un upstream 20-50× più costoso.
• ✅ Valuta la latenza separatamente dal costo. I prefill warm sono 2-10× più veloci anche quando lo sconto economico è ~0.
• ✅ Controlla i tipi di cache con costi di storage. Le cache a noleggio, come quelle esplicite di Moonshot moonshot-v1 e Gemini, fatturano il tempo di permanenza per token anche quando sono inattive; le cache automatiche dei prefissi no.

Conclusione

Per i modelli closed, la domanda “usa la cache?” ha una sola risposta. Per gli open-weight, la funzionalità è stata risolta anni fa al livello dell’inference engine: vLLM e SGLang memorizzano ogni prefisso automaticamente e gratuitamente. Tutto ciò che si trova sopra quel livello è infrastruttura che può conservare l’hit oppure disperdere le richieste: il load balancer delle repliche di un compute host, il routing tra cluster di un gateway, la distribuzione casuale di un router tra vendor. L’architettura del modello stabilisce il limite minimo di costo della cache: MLA e GQA producono vantaggi reali a livello di modello. Il percorso seguito dalla richiesta determina però ciò che ottieni in pratica. Considera il comportamento della cache una proprietà del routing. Misura i costi sul percorso esatto che userai, fissa il route affinché le richieste successive raggiungano la cache già popolata e ricorda che anche lo sconto più alto è inutile se la seconda richiesta finisce dove la prima non è mai arrivata.

Per capire perché esiste una KV cache e come funzionano i TTL, parti da Come funzionano KV cache e TTL; per verificare le dichiarazioni di un gateway sulla cache, leggi Il tuo gateway LLM mente sulla cache?.

FAQ

I modelli open-weight supportano il prompt caching? I pesi determinano quanto economica può diventare la cache: architetture di attention come MLA e GQA riducono le dimensioni della KV cache. La cache vera e propria, lo sconto e l’API provengono però dallo stack di serving. La cache viene implementata nell’inference engine (vLLM, SGLang, TensorRT-LLM), ereditata dai compute host e inoltrata, o dispersa, da gateway e router. Distribuendo lo stesso checkpoint su tre host puoi ottenere cache automatica gratuita, nessuna cache oppure solo cache esplicita.

Perché lo stesso modello è costato 49× di più in una chiamata rispetto a un’altra? Su un router multi-provider, una richiesta senza upstream fissato viene bilanciata tra cluster di vendor diversi, con prezzi base e stato della cache differenti. Una chiamata ha raggiunto cold un provider costoso; un’altra ha raggiunto warm quello economico. Fissa l’upstream, vincolando l’ordine dei provider e disattivando i fallback, per controllare entrambi gli aspetti.

Se uso il self-hosting, devo pagare per la cache? No. La cache automatica dei prefissi di vLLM, SGLang e TensorRT-LLM è attiva per impostazione predefinita e gratuita: un hit evita semplicemente il prefill. Paghi solo le GPU già in uso e la cache resta sotto il tuo controllo, con eviction LRU quando serve liberare VRAM.

L’API riporta cached_tokens: 0, ma il costo è sceso: la cache ha funzionato? Probabilmente sì. Molti gateway non valorizzano cached_tokens per gli upstream che gestiscono automaticamente la cache. Fai affidamento sul campo cost: un calo significativo tra una chiamata cold e una chiamata warm identica indica un cache hit.

Quale modello open-weight offre lo sconto maggiore sulla cache? La cache automatica su disco di DeepSeek: deepseek-v4-flash fattura l’input in cache a ~$0.0028/M rispetto a $0.14/M senza cache, uno sconto di ~98%. Nei nostri test cold→warm abbiamo misurato il 97.9-99.2% sulla linea V4. Molti host di terze parti applicano invece uno sconto fisso di ~50%.

Le cache con costi di storage hanno qualche svantaggio? Sì. La cache esplicita di Moonshot moonshot-v1 e quella esplicita di Gemini fatturano in base al numero di token e al tempo di permanenza della cache. Per Gemini il costo è di circa ~$1-4.50 / 1M token / ora. Una cache inattiva che dimentichi di eliminare continua a generare costi. Le cache automatiche dei prefissi non prevedono costi di storage.

Verifica: i dati live su costi e latenza sono stati misurati il 2026-06-14 su un router multi-provider e sul nostro gateway, usando un prompt fisso da ~4.7K token, un valore ridotto di max_tokens ed esecuzioni sequenziali cold→warm; gli sconti sono stati calcolati dal cost restituito per ogni richiesta. I prezzi documentati e i meccanismi di cache sono stati verificati lo stesso giorno sulle fonti primarie dei provider e sottoposti a controllo incrociato; alcuni valori dei vendor, in particolare i costi della cache esplicita di Moonshot, cambiano spesso. Verifica i valori aggiornati prima di citarli. I risultati variano in base a provider, prompt, area geografica e carico.

Fonti

• DeepSeek, Prezzi
• DeepSeek, Guida alla KV cache e al Context Caching
• Report tecnico DeepSeek-V3, MLA (compressione della KV cache)
• GQA: addestramento di modelli Transformer Generalized Multi-Query (Ainslie et al.)
• Alibaba Cloud Model Studio, context cache e prezzi
• Moonshot AI, Context Caching
• Zhipu / Z.AI, prezzi e cache
• vLLM, Automatic Prefix Caching
• SGLang, RadixAttention e cache
• LMCache, offload e condivisione della KV cache
• Google, Context caching di Gemini

Tutte le fonti sono state verificate il 2026-06-14. Queste informazioni non costituiscono consulenza finanziaria; verifica i prezzi correnti prima di farvi affidamento.

← Torna al blog