Benchmark Inference Academy: DeepSeek V4 Flash costa 14,9 volte di più sulle richieste a freddo

La misurazione non riguarda la qualità delle risposte. Inference.academy ha usato un unico setup controllato su target di input da 1.000, 10.000 e 100.000 token, ognuno con un budget di output di 100 o 1.000 token. La temperatura era a zero e il reasoning disattivato. Le richieste a freddo usavano un prefisso unico, quelle a caldo ripetevano lo stesso prompt. Il sito parla di misurazioni di serving, non di punteggi sulla qualità del compito.

Il costo è l'addebito totale della richiesta diviso per i token di input, moltiplicato per 1M, e comprende gli addebiti di output. Il dettaglio conta: il prezzo di input in evidenza sulla pagina di un fornitore non è quello che il benchmark confronta. Lo studio riporta punti di costo su 13 route per la condizione con 10.000 input, 100 output token e cache a freddo.

Il dato di 14,9 volte è il divario più ampio che il benchmark segnala. Sulle richieste DeepSeek con 100.000 input e budget di 100 output, in questo campione le chiamate a caldo costano 14,9 volte in meno di quelle a freddo. Caldo vuol dire prompt ripetuto, e la quota di cache misurata determina quanta parte del lavoro di input è stata fatturata alla tariffa non in cache.

La velocità è un asse a parte

Telnyx ha guidato la velocità mediana di generazione in tutte le 12 condizioni testate. La latenza del primo token non ha seguito lo stesso schema. Secondo il benchmark il primo token più veloce dipendeva dalla forma della richiesta: un fornitore che vince sul time-to-first-token con un prompt da 1.000 non è per forza quello che vince a 100.000.

"Dove invii un prompt cambia quanto paghi, quanto aspetti e se la chiamata va a buon fine."

È la frase con cui inference.academy inquadra l'esercizio. I pannelli sui tempi usano richieste a freddo con un budget di output di 100 token e una scala con asse condiviso. Il TTFT va dall'inizio della richiesta al primo delta di contenuto o reasoning ricevuto dal client, e include il tempo di rete e di coda. Il P90 usa l'interpolazione lineare tra osservazioni ordinate. La velocità di decodifica, misurata dopo l'avvio dello streaming, è il numero di token di completamento diviso per il tempo trascorso dal primo all'ultimo delta di output. Le risposte non in streaming non ricevono alcuna misurazione della velocità di decodifica.

Il routing è un'altra variabile. Il benchmark ha registrato i nomi upstream restituiti da OpenRouter per ogni forma di richiesta e condizione di cache. Osserva anche che un prompt ripetuto può raggiungere un upstream diverso, cambiandone il comportamento in cache.

Nella condizione a caldo da 10.000 a 100, Together ha totalizzato 29 chiamate, Novita 20 e CoreWeave 17. In quella a freddo da 10.000 a 100, Baidu è comparso 15 volte e Relace 13. Il sito è esplicito: l'ampiezza del segmento è la quota di chiamate, e i nomi sono upstream riportati, non macchine verificate. La sola distribuzione, aggiunge, non spiega perché il routing sia cambiato.

I tassi di errore sono divisi per target di input e budget di output, con freddo e caldo confrontati a parte. Il benchmark avverte che una route può comportarsi diversamente quando lo stesso prompt chiede una risposta più lunga. Errori HTTP, di trasporto e di risposta contano tutti come fallimenti, e i conteggi esatti sono nelle tabelle sotto i grafici. Zero significa nessun fallimento osservato in quel campione, non una garanzia.

Per chi paga le bollette di inferenza l'indicazione pratica è più stretta del titolo. La cache cambia la fattura di più di un ordine di grandezza sugli input lunghi, e il fornitore che si ottiene tramite un router non è fisso. Il benchmark copre 14 fornitori e 13 route nel suo scatter dei costi, ma la sua stessa impostazione è il riassunto più sicuro: sono misurazioni di serving, e descrivono ciò che è accaduto in questo campione.