HotKV ha ridotto del 70% l'uso di token di Claude nel nostro benchmark Banking77

Una cache semantica promette di ridurre la spesa per gli LLM rispondendo dalla memoria alle domande ripetute e simili, invece di chiamare il modello. Lo abbiamo misurato end to end: le stesse 3.000 richieste di assistenza clienti, inviate due volte a ciascuno di quattro modelli Claude, una volta direttamente al modello e una volta con HotKV davanti, con il prompt caching di Anthropic lasciato attivo in entrambe le esecuzioni. Ecco esattamente cosa abbiamo eseguito e cosa ne è emerso, compresi i punti in cui è carente.

In breve. HotKV ha ridotto di circa il 70% le chiamate al modello, i token (input più output) e il costo API su ciascuno dei quattro modelli. Gran parte del risultato deriva dalle domande che si ripetono identiche. Lo strato semantico aggiunge circa 12 punti in più. Alla soglia di similarità predefinita di 0,81, le risposte in cache sono state giudicate adeguate alla domanda esatta con una frequenza inferiore, tra 5,8 e 10,7 punti percentuali, rispetto alle risposte nuove. Sul solo modello per cui abbiamo provato più soglie (Sonnet 5.5), una soglia pari o superiore a 0,88 non ha mostrato questo scarto.

Aggiornato il 12 ottobre 2026: questo articolo riporta ora la nostra esecuzione più ampia su quattro modelli Claude attuali. Sostituisce una precedente esecuzione da 1.500 richieste su GPT e Claude Sonnet 5 che aveva misurato circa il 60% di token in meno, risultato che non presentiamo più.

Cosa abbiamo testato

Il workload

Abbiamo riproposto domande di assistenza clienti dallo split di test di Banking77 (PolyAI, CC BY 4.0), un dataset pubblico di brevi domande bancarie etichettate con 77 intent. È stato introdotto in Casanueva et al., 2020. Le 3.000 richieste sono state estratte con un seed fisso. La popolarità degli intent segue una distribuzione di Zipf con esponente 1,0, un'asimmetria sintetica in cui pochi intent compaiono molto più spesso degli altri, e la domanda all'interno di un intent viene scelta in modo uniforme, con ripetizioni. Compaiono tutti i 77 intent, e 1.264 delle 3.000 richieste sono domande distinte (conteggio ottenuto rieseguendo il generatore di richieste con seed). La banca e la sua policy di supporto sono fittizie. Abbiamo scritto una policy di circa 2.200 token, inviata come prompt di sistema a ogni richiesta, che chiede da due a quattro frasi brevi.

Modelli e impostazioni

Abbiamo eseguito claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5 e claude-haiku-5-5. Fable 5.1 e Opus 5.5 sono stati eseguiti al livello più basso di sforzo di ragionamento, perché il loro thinking non può essere disattivato. Sonnet 5.5 è stato eseguito con il thinking iniziale disattivato, la sua impostazione più bassa, e Haiku 5.5 con il thinking disabilitato. L'output massimo era di 2.000 token per Fable e Opus e di 400 per Sonnet e Haiku, e ogni risposta si è conclusa normalmente senza essere troncata. Otto richieste venivano eseguite alla volta in entrambe le modalità, le chiamate non erano in streaming e ogni condizione è stata eseguita una volta.

Le due esecuzioni

• Baseline: ogni richiesta va direttamente al modello, con il prompt caching di Anthropic attivo (cache_control sul prompt di sistema, durata predefinita di cinque minuti). È la baseline configurata usata qui, non l'affermazione che ogni ottimizzazione lato provider sia stata esaurita.
• Con HotKV: HotKV sta davanti allo stesso traffico e allo stesso prompt di sistema, con la cache che parte vuota.

Cosa abbiamo contato

Ogni conteggio dei token proviene dal blocco usage della risposta dell'API: input non in cache, letture e scritture della cache e output (thinking incluso). I token di embedding sono conteggiati a parte. I costi usano i prezzi di listino di Anthropic dell'11 ottobre 2026, includono le chiamate di embedding per le ricerche semantiche ed escludono l'hosting e la gestione operativa di HotKV. Non sono un preventivo sui prezzi attuali.

Come funziona la cache

Per ogni domanda, HotKV esegue due ricerche prima di chiamare il modello:

1. Corrispondenza esatta: un GET su una chiave SHA-256 costruita dal modello, dalla versione del prompt di sistema e dalla domanda normalizzata (in minuscolo, con gli spazi bianchi compattati). Intercetta una domanda posta con parole identiche.
2. Corrispondenza semantica: una chiamata SCACHE.GET con un embedding della domanda (text-embedding-3-small di OpenAI, similarità coseno). Cerca una domanda simile. Un punteggio di similarità da solo non può garantire che la risposta in cache sia adeguata.

Raggiunge il modello solo una domanda che dà un miss in entrambe le ricerche, e la sua risposta viene scritta nella cache con SET e SCACHE.SET. La soglia di similarità per un hit semantico è stata fissata a 0,81 prima dell'esecuzione. L'abbiamo scelta su uno split di train separato di Banking77 come il valore più basso, a passi di 0,01, i cui hit semantici puntavano allo stesso intent almeno il 98% delle volte (98,2% in quel caso). In questa esecuzione, sullo split di test intatto, dal 96,7% al 96,8% degli hit semantici corrispondeva all'intent della domanda posta: 30 o 31 hit con intent sbagliato per modello su un totale da 926 a 936.

Risultati

Chiamate, token e costo

Sui quattro modelli, le chiamate sono scese da 12.000 a 3.588, i token del 70,1% e il costo del 69,6%. Circa il 70% delle richieste ha ricevuto risposta dalla cache su ogni modello: circa il 39% tramite corrispondenza esatta e il 31% tramite corrispondenza semantica.

Chiamate, token e dollari scendono insieme perché HotKV elimina intere chiamate. Leggi con attenzione il dato sui token: dal 90% al 93% dei token conteggiati sono letture dalla cache dello stesso prompt della policy da 2.200 token, che Anthropic fattura a una piccola frazione del normale prezzo dell'input. I token di output sono solo dal 6% al 9% dei token ma dal 73% al 92% del costo della baseline.

Velocità

Il tempo di risposta mediano sull'intera esecuzione è sceso da 2,7 secondi a 127 ms su Fable 5.1, da 2,9 secondi a 126 ms su Opus 5.5, da 1,8 secondi a 128 ms su Sonnet 5.5 e da 1,4 secondi a 125 ms su Haiku 5.5, cioè da 11 a 23 volte più veloce. Una domanda ripetuta è tornata con una mediana di circa 0,05 ms, misurata da un client Python tramite loopback sulla stessa macchina di HotKV, quindi è un valore locale e non di rete. Una domanda riformulata, servita dalla cache semantica, ha richiesto circa 130 ms, quasi tutti dovuti alla chiamata all'API di embedding.

La mediana sull'intera esecuzione cade all'interno di quella fascia degli hit semantici perché gli hit esatti (circa il 39% delle richieste) sono troppo pochi per determinare da soli la mediana, mentre gli hit esatti e semantici insieme (70%) superano la metà. La coda lenta si sposta meno: il 30% delle richieste chiama ancora il modello. Il 99° percentile era di circa 6,4 secondi con HotKV contro 6,6 secondi senza su Fable 5.1, e più o meno lo stesso su Haiku 5.5. Era inferiore su Opus 5.5 (4,7 secondi contro circa 6) e su Sonnet 5.5 (2,7 secondi contro 3,3). Le chiamate non erano in streaming, quindi questi sono tempi fino alla risposta completa, non fino al primo token.

Riscaldamento

La cache parte vuota, quindi le prime richieste raggiungono comunque il modello. La quota di richieste servite dalla cache è stata di circa il 52% nelle prime mille richieste e di circa l'81% nelle ultime mille.

Da dove viene il risparmio

La maggior parte del risparmio è semplice ripetizione. Una cache a sola corrispondenza esatta avrebbe richiesto al massimo 1.264 chiamate al modello su 3.000, una per ogni domanda distinta, cioè circa il 58% in meno. Lo strato semantico ha portato questa percentuale a circa il 70%, quindi contribuisce con circa 12 punti su questo workload. È anche la parte che comporta il rischio per la qualità delle risposte, come mostra la sezione successiva. Questo dato è derivato dalla sequenza delle richieste e dai log, non da un'esecuzione misurata a parte.

Qualità delle risposte

Un hit semantico significa lo stesso intent, non la stessa risposta corretta. Per misurare la correttezza abbiamo fatto valutare ogni hit semantico a un modello Claude diverso. Il giudice vedeva la domanda del cliente e due risposte in ordine casuale: la risposta in cache servita da HotKV e la risposta nuova che lo stesso modello aveva dato a quella domanda esatta nell'esecuzione baseline. Indicava se ciascuna risposta rispondeva correttamente a quella domanda esatta. Opus 5.5 ha valutato le risposte di Fable 5.1, Sonnet 5.5 e Haiku 5.5, e Fable 5.1 ha valutato Opus 5.5, quindi nessun modello ha valutato il proprio output.

Alla soglia predefinita

A 0,81, una risposta in cache era adeguata alla domanda esatta con una frequenza inferiore, tra 5,8 e 10,7 punti percentuali, rispetto a una risposta nuova dello stesso modello. Gli hit semantici sono circa il 31% delle richieste, quindi su tutte le risposte, considerando neutri gli hit esatti, lo scarto va da circa 2 a 3 punti (da 1,8 a 3,3). I giudici differiscono per rigore, quindi confronta le risposte in cache con quelle nuove solo all'interno dello stesso modello.

Alzare la soglia

Abbiamo rieseguito Sonnet 5.5 a quattro altre soglie, ciascuna partendo da una cache vuota, con lo stesso giudice. Il costo della baseline era di 5,51 $.

Da 0,88 in su le risposte in cache non hanno mostrato un deficit rispetto a quelle nuove, riducendo comunque il costo del 64% a 0,88 e del 61% a 0,90. Le evidenze sono scarse. A 0,90 l'intervallo al 95% per la differenza va da circa 4 punti in peggio a 7 punti in meglio, la riga a 0,95 ha solo 50 hit e ogni riga valuta un sottoinsieme diverso di hit. Si tratta di un solo modello, un solo giudice e una sola esecuzione per soglia, quindi non è una prova di qualità equivalente né di una soglia sicura universale.

Domande quasi identiche

Il vero rischio sono le domande che sembrano quasi identiche ma richiedono risposte diverse, come depositare contro prelevare. Abbiamo fatto scrivere 119 coppie a Opus 5.5, ciascuna composta da una domanda reale dello split di train più una versione con un dettaglio decisivo modificato, e abbiamo contato quante domande modificate supererebbero la soglia rispetto a una cache che contiene solo l'originale. Queste coppie sono costruite per essere difficili, non sono state riviste da una persona e mostrano il caso peggiore, non la frequenza con cui accade nel traffico reale.

Alzare la soglia riduce il rischio ma non lo elimina. Anche a 0,90 il 25% delle coppie volutamente vicine corrisponderebbe, e corrispondono meno anche le vere riformulazioni.

Cosa significa su larga scala

Estrapolando il costo misurato per richiesta a 1 milione di richieste al giorno su un mese di 30 giorni, e ipotizzando lo stesso andamento del traffico, si ottengono questi valori mensili:

• claude-fable-5-1: circa 303.100 $ senza HotKV, 91.800 $ con HotKV, circa 211.300 $ risparmiati.
• claude-opus-5-5: circa 146.000 $ senza HotKV, 45.000 $ con HotKV, circa 101.000 $ risparmiati.
• claude-sonnet-5-5: circa 55.100 $ senza HotKV, 16.600 $ con HotKV, circa 38.500 $ risparmiati.
• claude-haiku-5-5: circa 2.700 $ senza HotKV, 800 $ con HotKV, circa 1.900 $ risparmiati.

Si tratta di aritmetica sul costo misurato per richiesta, non di un'altra esecuzione misurata. Esclude l'hosting, e la capacità necessaria per quel volume non è stata misurata. Alle 3.000 richieste che abbiamo eseguito, il risparmio è di soli 0,19 $ per Haiku 5.5 e 21,12 $ per Fable 5.1. I quattro modelli sono stati eseguiti con risposte brevi, e Fable 5.1 e Opus 5.5 al livello più basso di sforzo di ragionamento, quindi risposte più lunghe o basate su molto ragionamento renderebbero più prezioso ogni chiamata evitata.

Limitazioni

Questa non è un'affermazione generale del tipo «HotKV ti fa risparmiare il 70%». È ciò che abbiamo misurato su questo workload, ed è il workload a fare il grosso del lavoro.

• Il risparmio segue la ripetizione. Con ogni intent ugualmente probabile invece di seguire una distribuzione di Zipf, il costo è sceso del 56% su Sonnet 5.5 e Haiku 5.5. Con 3.000 domande tutte diverse è sceso del 38%, interamente grazie alle corrispondenze semantiche tra domande diverse dello stesso intent, di cui Banking77 ha in abbondanza. Un workload senza domande ripetute o simili non fa risparmiare nulla.
• Traffico sintetico. Le estrazioni sono indipendenti: niente picchi, sessioni o contesto multi-turn. Un solo dataset pubblico di brevi domande bancarie, una policy fittizia scritta per questo test e un insieme finito di circa 3.080 domande di test.
• A giudicare le risposte è un modello. Nessun essere umano le ha riviste, non c'era un secondo giudice e ogni giudice è un modello Claude. Le risposte nuove non hanno superato il test «adeguata» del giudice dall'1% al 21% delle volte, quindi l'asticella è alta.
• Stesso intent non significa stessa risposta. La soglia di 0,81 è stata calibrata sulle etichette degli intent, non sulla qualità delle risposte. Il confronto tra soglie e il test sulle domande quasi identiche riguardano un solo modello e un solo modello di embedding.
• Piccola configurazione di test. Una sola esecuzione per condizione, un unico server da quattro vCPU con il client sulla stessa macchina e una cache non riscaldata prima delle esecuzioni con HotKV.
• I costi sono costi API. Escludono l'hosting e la gestione operativa di HotKV. Verifica la qualità delle risposte sulle tue domande e usa il caching esatto o risposte nuove dove il riutilizzo semantico non è adatto.

I valori per modello sono anche nella pagina sull'IA.

Provalo tu stesso

La cache a corrispondenza esatta di questo test usa semplici GET e SET, inclusi in ogni piano HotKV. La cache semantica (SCACHE.*) è disponibile con il piano Performance e superiori (prezzi). Inizia su HotKV Cloud e punta il tuo traffico esistente su HotKV, oppure contatta le vendite se vuoi prima analizzare i numeri per il tuo workload.