Caching per LLM open-weight: perché il tuo è una roulette del provider

Con un modello closed, il prompt caching è un unico contratto documentato. Claude ha i breakpoint cache_control; OpenAI e Gemini cachano automaticamente oltre una soglia di token; gli sconti sono pubblicati e stabili. Leggi una pagina e hai finito.

Gli open weight rompono questo presupposto. Lo stesso checkpoint di Qwen o Llama viene servito da una dozzina di host, e il caching non è una proprietà del modello: è una proprietà di dove il modello gira. Per mostrare fin dove arriva la cosa, ecco una richiesta misurata: un prompt identico da ~4,7K token, inviato sei volte allo stesso modello Qwen attraverso un router multi-provider, senza fissare l’upstream:

Stesso modello, stesso router, stesso prompt: il conto è andato da $0.0141 a $0.000286, un fattore 49×, unicamente in base a quale upstream ha scelto il router e se quell’upstream aveva il prefisso warm.

Riepilogo

• Il prompt caching per i modelli open-weight è un risultato del routing, non una feature del modello. È implementato — gratuito e automatico — nel motore di inferenza, poi preservato o distrutto da ogni livello sopra di esso.
• Cinque livelli: uno fornisce il caching, tre possono romperlo. Il modello (definisce la cacheabilità, non serve nessuna cache) → il motore di inferenza (caching, gratuito) → l’host di compute (lo trasforma in prodotto, in modo disomogeneo) → il gateway (routing multi-cluster) → il router (disperde tra vendor con cache disgiunte).
• Misurato. Una richiesta identica, dispersa da un router, è costata 49× di più con una scelta rispetto a un’altra; su un modello, un host ha dato il 59,6% di sconto e un altro lo 0%; gli sconti di caching pubblicati vanno dallo 0% al ~98% tra i vari modelli.
• Cosa fare. Fissa la route così che i prefissi ripetuti colpiscano la stessa cache warm; verifica in base al delta di costo, non al campo cached_tokens (che spesso segna 0 su un hit reale); valuta la latenza separatamente: i prefill warm girano 2–10× più veloci anche a sconto di costo ~0%.

Le cifre live sono state misurate il 2026-06-14 contro un router multi-provider e il nostro gateway, con un prompt inglese fisso da ~4,7K token, max_tokens piccolo, esecuzioni sequenziali. Il pricing documentato è stato verificato contro la documentazione primaria dei provider lo stesso giorno e controverificato in modo avversariale. I rapporti (percentuale di sconto, variazione di latenza) sono la parte trasferibile; i valori assoluti in dollari dipendono dalla sede, dal tuo prompt e dal carico. Riproduci prima di citare.

I tipi di cache che incontri davvero

Prima dello stack, il vocabolario. Tra gli host open-weight esistono quattro forme distinte di cache, e ognuna fattura in modo diverso.

1. Prefix caching automatico (senza marker). Il pattern dominante. Il server calcola l’hash del prefisso del prompt, riutilizza lo stato KV se coincide con una richiesta precedente e applica lo sconto da solo — niente cache_control, niente modifiche al codice, spesso impossibile da disattivare. Lo fanno DeepSeek, Zhipu GLM e la maggior parte degli host open-weight. Le scritture sono gratis; la cache vive ovunque, dalla VRAM (minuti) al disco (DeepSeek tiene i prefissi “da qualche ora a qualche giorno”).

2. Breakpoint caching esplicito (cache_control). La forma di Anthropic, che offrono anche alcuni host open-weight. Model Studio di Alibaba accetta "cache_control": {"type": "ephemeral"} su un blocco di messaggio Qwen; alcune piattaforme di serving espongono un marker equivalente. Marchi il confine, paghi un sovrapprezzo in scrittura e in cambio ottieni uno sconto più profondo in lettura.

3. Oggetti cache in affitto (con canone di storage). Quello da tenere d’occhio. La vecchia famiglia moonshot-v1 di Moonshot ti obbliga a fare POST /v1/caching per creare una cache, poi fattura una tariffa di scrittura, un canone di storage per token al minuto e una tariffa di hit per chiamata. Il caching esplicito di Gemini di Google segue la stessa idea — costo di input più storage a circa $1.00–$4.50 per 1M token all’ora. La cache è una risorsa che affitti e devi ripulire da solo.

4. Riuso KV in self-host (gratis). Fai girare i pesi in casa e l’inference engine fa caching gratis e in automatico. Niente tariffa di scrittura, niente costo di lettura, niente affitto di storage — un hit salta semplicemente il prefill.

Qwen su Model Studio offre entrambe le modalità, automatica ed esplicita, con un compromesso concreto: quella implicita fattura un hit al 20% dell’input con scritture gratis; quella esplicita fattura un hit al 10% dell’input ma addebita il 125% sulla scrittura e vincola l’entry a un TTL di 5 minuti. Sconto più profondo, ma paghi per popolare la cache e paghi di nuovo ogni volta che scade.

Dove vive il caching nello stack

Ecco il punto chiave. Il prompt caching per i pesi open è risolto in un solo layer e messo a rischio in tutti i layer sopra di esso. Percorri lo stack dai pesi verso l’alto e a ogni layer chiediti: questo layer fornisce il caching o si limita a inoltrarlo? E può rompere quello che il layer sotto 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.

Layer 1 — Il modello: cacheabilità, non una cache

Questo è il layer in cui la maggior parte delle persone pensa risieda il caching — “DeepSeek ha il caching” — quindi è il primo su cui fare chiarezza. Un checkpoint è un insieme di pesi; esegue la stessa attention che esista o meno una KV cache. Non porta con sé alcuna cache, nessuno sconto, nessun TTL, nessun marcatore cache_control: quelle sono funzionalità del serving layer. In senso stretto, i pesi non forniscono alcun prodotto di caching.

Ma i pesi non sono neutri, e DeepSeek è l’esempio perfetto del perché. L’architettura di attention del modello decide quanto è grande la KV cache, e quindi quanto può essere economico il caching:

• La Multi-head Latent Attention (MLA) di DeepSeek comprime la KV cache in un latente a basso rango, portandola a circa il 4–14% di una cache multi-head standard. È proprio questa compressione che permette all’API di DeepSeek di persistere i prefix su disco e di far pagare una lettura da cache a circa il 2% dell’input. L’architettura è l’abilitatore; la disk cache è un prodotto costruito sopra di essa.
• La Grouped-Query Attention (GQA) — usata da Llama, Qwen, Mistral e DeepSeek — condivide le KV head per ridurre la cache del fattore di gruppo (≈8× su Llama-3).

Il contributo del Layer 1 è quindi la cacheabilità, non una cache: l’architettura fissa il tetto massimo su quanto economico può diventare il caching in tutti i layer superiori, ma i pesi non servono mai un token in cache da soli. E “DeepSeek ha il caching” mescola silenziosamente due cose diverse che portano lo stesso nome: i pesi (questo layer, che ti danno MLA) e l’API e lo stack di serving di DeepSeek (Layer 2–3, che ti danno la disk cache, lo sconto e i campi di usage). Scarica i pesi open ed eseguili tu stesso: conservi la piccola KV cache di MLA, ma il prodotto disk-cache resta sui server di DeepSeek — erediti qualunque Layer 2 tu deploi al suo posto. La mossa operativa resta quindi valida: smetti di chiederti se un modello fa caching e inizia a chiederti dove viene servito — solo, non scambiarlo per il fatto che l’architettura non conti. È l’architettura a fissare il tetto; è il percorso a determinare cosa ottieni davvero.

Layer 2 — L’inference engine: dove il caching è costruito, e gratuito

Un layer più su, il caching non è solo presente: è risolto, e gratuito. Gli inference engine moderni cachano i prefix automaticamente:

• vLLM — Automatic Prefix Caching: fa l’hash di ogni blocco KV, riutilizza qualsiasi blocco il cui prefix hash ha già visto, sfratta in LRU. Attivo di default in V1.
• SGLang — RadixAttention: memorizza la KV cache in un radix tree così da riutilizzare qualsiasi prefix condiviso, con scheduling cache-aware.
• TensorRT-LLM — riuso dei blocchi (enable_block_reuse, attivo di default), con offload opzionale dei blocchi KV sulla host memory.

Progetti come LMCache estendono ulteriormente tutto questo — spostando le KV su CPU/disco e condividendole tra le istanze, il che è il seme della soluzione al problema di routing che stiamo per incontrare. Il punto: se fai self-hosting, hai finito. Il caching è automatico, non costa nulla oltre alle GPU che già fai girare, sfratta in LRU, e lo possiedi tu — un hit salta semplicemente il prefill, abbassando il TTFT e alzando il throughput. Non c’è alcun campo di billing cached_tokens perché non viene fatturato nulla; il guadagno si vede nelle tue metriche di latenza. Per un modello chiuso il caching lo affitti; per uno open puoi possederlo interamente. Il rovescio della medaglia è l’inverso rispetto al mondo hosted: la cache è effimera (VRAM, LRU), quindi sopravvive solo finché il prefix resta caldo — che è esattamente ciò che i layer superiori devono preservare.

Layer 3 — L’host di calcolo: la messa in produzione, in modo disomogeneo

Gli host di inferenza commerciali incapsulano il Layer 2 e gestiscono flotte di repliche. Ereditano il caching automatico gratuito; la domanda è se lo implementino bene, e la risposta è variabile su due assi.

Primo, esposizione e prezzo variano moltissimo. Tra i principali host open-weight: uno applica un 50% fisso all’input in cache e permette ai token cache di saltare i rate limit; un altro applica di default uno sconto del 50% sul serverless; un terzo prezza l’input in cache per modello (per esempio un tier Qwen a circa l’80% di sconto) ed espone un hint sulla cache-key per migliorare l’affinità; un quarto rende il caching sempre attivo e non divulgabile sugli endpoint dedicati. Stesso motore sottostante, quattro filosofie di prezzo.

Secondo — ed è il primo punto in cui il caching si rompe — il problema delle repliche multiple. Il tuo prefisso caldo vive nella VRAM dell’unica replica che ha servito la richiesta fredda. Il load balancer dell’host può inviare la richiesta successiva a una replica diversa, con cache fredda. Abbiamo visto esattamente questo: fissando lo stesso modello Qwen a un singolo upstream alla volta ed eseguendo cold→warm:

Il Provider A ha messo in cache correttamente e lo ha riportato. Il Provider B — che pubblicizza un prezzo di cache-read per questo modello — non ha restituito alcuno sconto su una chiamata fredda e due chiamate calde nel nostro test. Che si tratti di eleggibilità, fan-out sulle repliche o un warm-up più lungo di due richieste, il risultato misurato su questo percorso è stato zero. La funzionalità è risolta a livello del Layer 2; se poi la ricevi davvero è un dettaglio di esecuzione del Layer 3, e cambia da host a host.

Livello 4 — Il gateway: il problema multi-cluster

Un gateway sta davanti a uno o più upstream e moltiplica il problema delle repliche fino a trasformarlo in un problema di cluster. Se distribuisce le richieste in round-robin tra cluster o provider senza cache affinity, la cache calda diventa strutturalmente irraggiungibile: ogni richiesta finisce dove il prefisso non c’è. Un gateway cache-aware deve instradare in base all’hash del prefisso, così che prefissi identici restino sullo stesso upstream, allo stesso modo in cui il Livello 2 li lega agli stessi blocchi KV.

Abbiamo fatto girare una batteria cold→warm su modelli open-weight tramite un gateway di terze parti, leggendo direttamente il cost di ogni richiesta:

DeepSeek-V4 ha raggiunto il 97–99% (affinity funzionante da un capo all’altro); qwen3.5-plus e qwen3-max sono tornati a circa 0% sulla chiamata calda, pur avendo un prezzo di cache-read a catalogo. In questa tabella si nascondono altre due lezioni sui gateway:

• Il campo usage mente; il costo no. Qui cached_tokens riportava 0 su ogni chiamata, comprese quelle con un calo di costo del 99%. Molti gateway OpenAI-compatible non popolano il campo dei cached-token per gli upstream che fanno cache in automatico. Verifica con il delta di cost tra chiamata cold e warm, non con il campo dei token: è la stessa lezione della verifica delle dichiarazioni di cache di un gateway.
• La latenza migliora anche quando il costo no. Ogni chiamata calda era 2–10× più veloce — qwen3.5-flash è passato da 10.2s a 1.0s — incluse quelle con sconto vicino allo 0%. Un hit salta il prefill a prescindere da come l’host lo tariffa, quindi la cache può ripagare sul TTFT anche su un gateway che non ti dà nulla in bolletta.

Un gateway che non preserva l’affinity ti consegna una cache che non puoi raggiungere; uno che non espone il costo della cache te ne consegna una che non puoi verificare.

Layer 5 — Il router: distribuzione casuale tra provider

Al vertice, un router multi-provider bilancia il carico di un singolo model ID tra i cluster di aziende diverse, ognuna con una cache separata. A questo punto nemmeno un’affinità perfetta all’interno di un provider ti salva: se la chiamata 1 va a un vendor e la chiamata 2 a un altro, non c’è nessuna cache condivisa da colpire. È lo scatter da cui è partito questo post, e aggrava il Layer 4: non solo cluster multipli, ma vendor multipli con stati di cache disgiunti e prezzi disgiunti (l’opzione più cara costava 20× la tariffa base dell’upstream più economico). La cache si attivava solo quando per caso il routing restava sullo stesso provider.

La soluzione è azzerare la casualità: rendere il routing deterministico, così che i prefissi ripetuti finiscano sulla stessa cache calda:

# 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,
    },
  })

Va detto a suo favore che il router ha effettivamente riportato i cached_tokens (4.224 sul hit) e un cost per richiesta, quindi puoi verificare entrambi: meglio del gateway del Layer 4 che leggeva 0. Ma il routing sta a te vincolarlo. Il caching è un problema di routing travestito da funzionalità di pricing: la cache è gratuita al Layer 2, e i Layer 3, 4 e 5 sono tre modi via via più gravi per instradarti lontano da essa.

Quanto è profondo lo sconto? È tutto molto variabile

Quando il routing è allineato, quanto risparmi? Per i modelli chiusi lo sconto sulla lettura da cache si concentra intorno al 90%. Per gli open weight il prezzo pubblicato per la lettura da cache va da un gesto simbolico a quasi totale, anche all’interno della gamma di uno stesso vendor. Tariffe pubblicate first-party:

La disk cache automatica di DeepSeek è la più profonda del settore: deepseek-v4-flash legge l’input in cache a $0.0028/M contro $0.14/M in caso di miss, un rapporto di 1:50, che il nostro test al Layer 4 ha riprodotto al 97,9%. Gli host di terze parti di questi stessi open weight prezzano l’input in cache in modo indipendente: alcuni applicano un ~50% fisso, altri variano per modello dal ~50% al ~90%, quindi lo sconto che ottieni dipende dall’host su cui atterri, non solo dal modello. Stesso nome della funzionalità, 48 punti di differenza.

Dato che lo sconto è una proprietà del luogo, uno stesso modello porta economie di cache diverse ovunque venga servito. deepseek-v4-pro, in quattro modi:

“DeepSeek-V4-Pro supporta il caching” è vero e quasi inutile; la domanda operativa è “lo supporta dove, a quale tariffa, riportato come”.

Una checklist per decidere

• ✅ È il modello a fissare il tetto, non la cache (Layer 1). La sua architettura di attention (MLA, GQA) determina quanto può essere economico il caching, ma il modello non serve mai un token dalla cache — quindi chiediti comunque dove viene servito e cosa fa lo stack di quell’host.
• ✅ Self-hosting? Ce l’hai già gratis (Layer 2). Verifica che il prefix caching automatico sia attivo (in vLLM/SGLang lo è per default) e tieni d’occhio il tuo prefix hit rate.
• ✅ Su un compute host, verifica la consegna, non la colonna del prezzo (Layer 3). Un prezzo di cache-read è una promessa; misura il delta di costo cold→warm. Usa un hint di cache-key affinity dove l’host lo mette a disposizione.
• ✅ Tramite un gateway, pretendi routing con cache-affinity e reportistica sui costi (Layer 4). Se prefissi identici non finiscono sempre sullo stesso upstream, o se il cost non cala su una chiamata warm, la cache è irraggiungibile o non verificabile.
• ✅ Su un router, fissa l’upstream (Layer 5). Vincola il routing (ad esempio con un campo provider-order e i fallback disattivati), altrimenti perdi gli hit perché il load-balancing ti spalma su cache separate — e rischi un upstream 20–50× più costoso.
• ✅ Valuta la latenza separatamente dal costo. Un prefill warm è 2–10× più veloce anche quando lo sconto in denaro è circa zero.
• ✅ Attenzione alle cache con storage fee. Le cache “in affitto” (Moonshot moonshot-v1, Gemini explicit) si pagano per token-tempo anche quando la cache è inattiva; le prefix cache automatiche no.

In sintesi

Per i modelli chiusi, “fa caching?” ha una sola risposta. Per i pesi aperti il problema è risolto da anni a livello di inference engine: vLLM e SGLang mettono in cache ogni prefisso, gratis, in automatico. Tutto ciò che sta sopra quel livello è idraulica che o preserva l’hit o ti disperde lontano da esso: il replica balancer di un compute host, il cluster routing di un gateway, la distribuzione casuale di un router tra i vari vendor. L’architettura del modello fissa il tetto di quanto può essere economico il caching — MLA e GQA sono vantaggi reali, a livello di modello — ma è il percorso della tua richiesta a decidere cosa ottieni davvero. Tratta il comportamento della cache come una proprietà di routing: misuralo in termini di costo sul percorso esatto che userai, fissa la route in modo da colpire la cache che hai riscaldato, e ricorda che lo sconto più profondo del mondo non vale nulla se la seconda richiesta finisce dove la prima non è mai passata.

Per i meccanismi del perché esiste una KV cache e di come funzionano i TTL, parti da How KV Cache & TTL Work; per verificare le promesse di cache di un gateway, vedi Does Your LLM Gateway Lie About Cache?.

FAQ

I modelli open-weight supportano il prompt caching? I pesi determinano quanto può costare poco il caching — architetture di attention come MLA e GQA riducono la KV cache — ma la cache in sé, lo sconto e l’API vengono dallo stack di serving. Il caching è implementato nell’inference engine (vLLM, SGLang, TensorRT-LLM), ereditato dagli host di compute e inoltrato (o disperso) da gateway e router. Manda lo stesso checkpoint a tre host e puoi ottenere caching automatico gratuito, nessun caching, oppure solo quello esplicito.

Perché lo stesso modello è costato 49 volte di più su una chiamata rispetto a un’altra? Su un router multi-provider, una richiesta non pinnata viene bilanciata su cluster di vendor diversi, con prezzi base diversi e stati di cache separati. Una chiamata è finita su un provider costoso a freddo; un’altra su uno economico a caldo. Pinna l’upstream (vincola l’ordine dei provider, disattiva i fallback) per controllare entrambe le cose.

Se faccio self-host, devo pagare per il caching? No. L’automatic prefix caching in vLLM, SGLang e TensorRT-LLM è attivo di default ed è gratuito — un hit salta semplicemente il prefill. Paghi solo le GPU che già usi, e la cache è tua, con eviction LRU quando serve VRAM.

L’API dice cached_tokens: 0 ma il conto è calato — il caching ha funzionato? Probabilmente sì. Molti gateway non popolano cached_tokens per gli upstream che fanno caching automatico. Fidati del campo cost: un calo netto tra una chiamata a freddo e una identica a caldo significa che la cache ha fatto hit.

Quale modello open-weight ha lo sconto di cache più profondo? La disk cache automatica di DeepSeek: deepseek-v4-flash legge l’input in cache a ~$0.0028/M contro $0.14/M non in cache (~98% di sconto), riprodotto tra il 97.9% e il 99.2% su tutta la linea V4 nei nostri test cold→warm. Molti host di terze parti applicano invece un forfait di ~50%.

C’è una fregatura con le cache che addebitano una tariffa di storage? Sì — la cache esplicita moonshot-v1 di Moonshot e la cache esplicita di Gemini fatturano per token-tempo per mantenere viva la cache (Gemini ~$1–4.50 / 1M-token / ora). Una cache inattiva che ti sei dimenticato di eliminare continua ad addebitare. Le automatic prefix cache non hanno tariffa di storage.

Verifica: dati live di costo/latenza misurati il 2026-06-14 su un router multi-provider e sul nostro gateway, usando un prompt fisso di ~4.7K token, max_tokens piccolo, run sequenziali cold→warm; sconti calcolati dal cost per-richiesta restituito. Prezzi documentati e meccaniche di cache verificati sulla documentazione primaria dei provider lo stesso giorno e controllati in modo avversariale; alcuni dati dei vendor (in particolare le tariffe della cache esplicita di Moonshot) cambiano spesso — conferma i valori correnti prima di citarli. I tuoi numeri varieranno in base a provider, prompt, regione e carico.

Fonti

• DeepSeek — Pricing
• DeepSeek — KV cache / Context Caching guide
• DeepSeek-V3 Technical Report — MLA (KV-cache compression)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — context cache & pricing
• Moonshot AI — Context Caching
• Zhipu / Z.AI — pricing & caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading & sharing
• Google — Gemini context caching

Tutto verificato il 2026-06-14. Non è consulenza finanziaria; verifica i prezzi correnti prima di farci affidamento.

← Torna al blog