DeepSeek V4 Flash costa 14,9 volte meno con la cache calda: il benchmark su 14 fornitori

Il benchmark ha misurato una sola configurazione: obiettivi di 1.000, 10.000 e 100.000 token di input, ciascuno abbinato a un budget di 100 o 1.000 token di output, temperatura 0 e reasoning disattivato. Le richieste a freddo portavano un prefisso unico, quelle a caldo ripetevano lo stesso prompt. Il sito lo dice chiaramente: sono misurazioni di serving, non punteggi sulla qualità delle attività.

Il costo nello studio non è il prezzo di listino dei token di input. È il totale degli addebiti per richiesta diviso per i token di input e moltiplicato per un milione, quindi dentro ci sono anche gli addebiti di output. Nel campione, le richieste di DeepSeek V4 Flash con 100.000 di input e un budget di 100 di output sono costate 14,9 volte meno a caldo che a freddo.

L'instradamento non è stabile tra una chiamata e l'altra

Il benchmark ha registrato anche quali nomi upstream restituiva OpenRouter per ciascuna forma di richiesta. I nomi cambiano con la condizione della cache. Per le chiamate a freddo con 1.000 di input e 100 di output la lista era guidata da Baidu con 18 chiamate, Relace con 14 e AkashML con 13. La stessa forma a caldo era guidata da Relace con 24, CoreWeave con 16 e DeepSeek con 11.

Con 100.000 di input e un budget di 100 token di output, le richieste a freddo sono andate per lo più a Baidu (7), DigitalOcean (3), Relace (3) e Wafer (3). Quelle a caldo della stessa forma sono andate a Relace (14), Together (6) e CoreWeave (5). Gli autori avvertono che l'ampiezza del segmento è solo la quota di chiamate, che i nomi sono upstream dichiarati e non macchine verificate, e che questa sola distribuzione non spiega perché l'instradamento sia cambiato.

Sulla velocità, Telnyx ha guidato la velocità mediana di generazione in tutte le 12 condizioni. La latenza del primo token dipendeva dalla forma della richiesta, non da un unico vincitore. Il sito definisce il tempo al primo token come l'intervallo dall'inizio della richiesta al primo delta di contenuto o di reasoning ricevuto dal client, rete e coda comprese. La velocità di decodifica è invece il rapporto tra i token di completamento riportati e il tempo trascorso dal primo all'ultimo delta di output. Le risposte non in streaming non producono alcuna misura di velocità di decodifica.

I tempi includono solo le chiamate riuscite.

Quota di cache e tassi di errore

Lo studio riporta la quota di cache come la somma dei token di input in cache divisa per la somma dei token di input, per i successi che riportavano entrambi. La misura è stata presa su prompt da 10.000 ripetuti con un budget di 100 token di output. È una quota di token, non la percentuale di richieste che hanno trovato una cache, e la sequenza a caldo include la sua richiesta iniziale.

I tassi di errore sono suddivisi per obiettivo di input, budget di output e condizione della cache. Gli autori osservano che una rotta può comportarsi diversamente quando lo stesso prompt chiede una risposta più lunga. Il tasso di errore è il numero di chiamate fallite diviso per le chiamate misurate in quella condizione, contando errori HTTP, di trasporto e di risposta. I conteggi esatti e gli intervalli descrittivi sono nelle tabelle sotto i grafici, e i record grezzi sono scaricabili. Uno zero dichiarato significa nessun errore osservato nel campione, e il benchmark contrassegna i campi non misurati come non riportati anziché come zero.

Per chi compra, la lettura pratica è ristretta. Il divario tra freddo e caldo è abbastanza ampio che il riuso del prompt, non solo la scelta del fornitore, può dominare la bolletta per carichi di lavoro ripetuti. Ma gli stessi numeri mostrano che un prompt ripetuto può finire su un upstream diverso, e questo cambia se uno sconto di cache si applichi o meno.