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

Il benchmark ha misurato una configurazione controllata: 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 utilizzavano un prefisso unico, quelle a caldo ripetevano lo stesso prompt. Il sito specifica che si tratta di misurazioni di serving, non di punteggi sulla qualità del task.

Il costo nello studio non corrisponde al prezzo di listino dei token di input. È il totale degli addebiti per richiesta diviso per i token di input e moltiplicato per un milione, includendo quindi anche gli addebiti di output. Nel campione, le richieste di DeepSeek V4 Flash con 100.000 token di input e un budget di 100 token 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 upstream OpenRouter restituiva per ciascuna forma di richiesta. I nomi variano in base alla condizione della cache. Per le chiamate a freddo con 1.000 token 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 token 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 rappresenta solo la quota di chiamate, che i nomi indicano upstream dichiarati e non macchine verificate, e che questa distribuzione da sola 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, includendo tempi di rete e di coda. La velocità di decodifica è 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 misure 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 i valori. La misura è stata presa su prompt da 10.000 ripetuti con un budget di 100 token di output. Si tratta di una quota di token, non della percentuale di richieste che hanno trovato una cache, e la sequenza a caldo include la 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 richiede 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 gli acquirenti, 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, il che cambia se uno sconto di cache si applichi o meno.