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 eseguito un setup controllato su target di input da 1.000, 10.000 e 100.000 token, ciascuno abbinato a un budget di output di 100 o 1.000 token. La temperatura era impostata a zero e il reasoning disattivato. Le richieste a freddo usavano un prefisso unico, quelle a caldo ripetevano lo stesso prompt. Il sito definisce i risultati come misurazioni di serving, non come punteggi sulla qualità del compito.

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

Il fattore di 14,9 volte è il divario più ampio segnalato dal benchmark. Sulle richieste DeepSeek con 100.000 token di input e budget di 100 token di output, in questo campione le chiamate a caldo costano 14,9 volte meno di quelle a freddo. "Caldo" significa 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. Il benchmark afferma che il primo token più veloce dipendeva dalla forma della richiesta: un provider che vince sul time-to-first-token con un prompt da 1.000 token non è necessariamente 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, il che può cambiare il suo 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 rappresenta la quota di chiamate, e i nomi sono upstream riportati, non macchine verificate. Aggiunge inoltre che la sola distribuzione non stabilisce perché il routing sia cambiato.

I tassi di errore sono suddivisi per target di input e budget di output, con freddo e caldo confrontati separatamente. Il benchmark avverte che una route può comportarsi diversamente quando lo stesso prompt richiede una risposta più lunga. Errori HTTP, di trasporto e di risposta contano tutti come fallimenti, e i conteggi esatti si trovano 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 provider che si ottiene tramite un router non è fisso. Il benchmark copre 14 provider 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.