LLM Benchmark di latenza per casi d'uso
Abbiamo sottoposto a benchmark 11 migliori grandi modelli linguistici con un totale di 1.320 richieste, separando i modelli di ragionamento da quelli non di ragionamento, e abbiamo misurato la latenza del primo token, la latenza per token e il tempo di risposta complessivo.
LLM benchmark di latenza
Qui trovi i dettagli su come abbiamo misurato la latenza.
Tempo di risposta end-to-end per modello
LLM risultati del benchmark di latenza
Riportiamo separatamente i modelli di ragionamento e quelli non di ragionamento. I modelli di ragionamento impiegano diversi secondi a pensare prima della prima risposta visibile, quindi confrontarli direttamente con i modelli non di ragionamento sulla latenza sarebbe fuorviante. Alcuni modelli cambiano anche comportamento a seconda del compito: GPT-5.2 risponde alle domande e risposte senza ragionamento, ma ragiona sui prompt di coding.
Caso a risposta breve (Q&A)
Nel caso breve ciò che conta è la velocità con cui appare il primo token di risposta, poiché l'intera risposta è solo una o due frasi. I modelli non di ragionamento si raggruppano nella regione a bassa latenza:
- claude-opus-4-8: 0,75 secondi
- gpt-5-2: 0,8 secondi
- claude-haiku-4-5: 0,96 secondi
- claude-sonnet-5: 1,5 secondi
- claude-opus-4-7: 2 secondi
I modelli di ragionamento sono stati più lenti a raggiungere la prima parola di risposta anche qui, perché pensano prima:
- mimo-v2-5: 1,2 secondi
- minimax-m3: 2,4 secondi
- deepseek-v4-flash: 3,6 secondi
- gemini-3-1-pro-preview: 9 secondi
- hy3-preview: 14,6 secondi
Sulle domande brevi la fase di pensiero è per lo più un overhead, poiché la risposta stessa è breve.
Caso a risposta lunga (generazione di codice)
Nel caso lungo il ritardo del primo token conta meno, e la velocità di streaming e il tempo di risposta totale prendono il sopravvento. claude-haiku-4-5 ha guidato entrambi, trasmettendo in streaming a circa 180 token al secondo e terminando in circa 5,5 secondi. Gli altri modelli non di ragionamento hanno terminato in circa 10 - 13 secondi: claude-sonnet-5 a 10 secondi, claude-opus-4-8 a 10,8 e claude-opus-4-7 a 12,7.
I modelli di ragionamento hanno prodotto tempi totali più lunghi, perché il pensiero e l'output lungo si sommano:
- gemini-3-1-pro-preview: 18,5 secondi
- hy3-preview: 23,1 secondi
- deepseek-v4-flash: 24,3 secondi
- minimax-m3: 28,1 secondi
- mimo-v2-5: 35 secondi
Alcuni fanno streaming veloce una volta partiti (hy3-preview viaggia a circa 200 token al secondo), ma il pensiero iniziale mantiene alto il totale.
La lunghezza dell'output è stata limitata anziché lasciata aperta, quindi i modelli non vengono confrontati sulla verbosità: circa 128 token per le risposte brevi e 1.024 per quelle lunghe. Ai modelli di ragionamento è stato concesso un budget extra oltre questo limite per contenere i token di pensiero, quindi i loro tempi end-to-end riflettono il pensiero più la risposta anziché una risposta tagliata a metà pensiero.
Risposte brevi contro risposte lunghe
Il contrasto tra i due casi è il principale insegnamento:
- Nel caso breve i modelli più veloci hanno risposto in meno di un secondo e la dispersione era ridotta.
- Nel caso lungo i modelli non di ragionamento sono rimasti vicini alla testa (Haiku più veloce a circa 5,5 secondi), mentre i modelli di ragionamento sono rimasti molto indietro a 18 - 35 secondi.
- Anche l'ordine all'interno del gruppo non di ragionamento cambia: Haiku era uno dei diversi starter sub-secondo sui prompt brevi, ma si stacca nettamente in avanti sugli output lunghi grazie alla sua velocità di streaming.
Latenza al 90° percentile
Il pattern principale è che la coda si moltiplica per i modelli di ragionamento anziché solo spostarsi. Nel compito di coding, MiniMax è passato da circa 13 secondi alla mediana a 42 secondi al p90, e Hunyuan da circa 16 a 46 secondi. Il tempo extra è il pensiero, e la lunghezza del pensiero varia da richiesta a richiesta, quindi questi modelli non sono solo più lenti ma anche meno prevedibili.
Alcuni punti spiccano:
- MiMo è l'eccezione tra i modelli di ragionamento. Ragiona su ogni richiesta ma pensa brevemente, quindi il suo p90 è rimasto vicino a 3,7 secondi. Il ragionamento di per sé non rende un modello imprevedibile; è la quantità di pensiero a farlo.
- GPT-5.2 mostra una coda solo dove ragiona. Sulle Q&A il suo p90 era sotto i 2 secondi, ma sul coding, dove attiva il ragionamento, il suo p90 è salito a circa 11 secondi.
- I modelli non di ragionamento sono rimasti compatti. Haiku 4.5 e Opus 4.8 hanno mantenuto il p90 entro circa 2 - 2,5 secondi. Anche Sonnet 5, che si è allargato sugli output lunghi (circa 4 secondi alla mediana a 8 al p90), è rimasto molto al di sotto del gruppo di ragionamento.
Il punto pratico è che la mediana può nasconderlo. La mediana di MiniMax sul coding, circa 13 secondi, non è la peggiore del gruppo, ma il suo p90 di circa 42 secondi eguaglia Hunyuan, quindi su una richiesta sfortunata è lento quanto qualsiasi cosa misurata.
LLM ragionamento e il suo effetto sulla velocità
I modelli di ragionamento impiegano più tempo a produrre il loro primo token di risposta perché generano token interni di ragionamento a catena di pensiero prima della risposta visibile. Quel passo di pensiero è ciò che aumenta il loro tempo al primo token, da circa un secondo per i modelli non di ragionamento a diversi secondi o più.
Che un modello ragioni o meno non è sempre fisso. Abbiamo rilevato il ragionamento per ogni richiesta dal numero di token di ragionamento restituiti da ciascuna risposta, quindi abbiamo raggruppato i risultati per compito. La quota di richieste in cui ciascun modello ha ragionato:
GPT-5.2 lo dimostra direttamente: ha risposto ai brevi prompt di Q&A senza ragionamento, ma ha ragionato sulla maggior parte dei prompt di coding. Per un modello ibrido come questo, "ragionamento" non è un'etichetta fissa; il modello decide in base al compito, e la sua latenza cambia con quella decisione. Questo è il motivo per cui GPT-5.2 si trova nel gruppo veloce sulle Q&A ma arretra sul coding.
Abbiamo misurato ogni modello nel suo stato predefinito. Diversi sono ibridi che possono ragionare su richiesta ma partono con il pensiero disattivato: Claude Opus 4.8, ad esempio, supporta il pensiero esteso, ma è disabilitato per impostazione predefinita, quindi non ha mai prodotto token di ragionamento nelle nostre esecuzioni ed è rimasto veloce, così come gli altri modelli Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Gli altri hanno ragionato su quasi tutte le richieste, motivo per cui appaiono più lenti al primo token. Quindi "non ragiona mai" qui significa non per impostazione predefinita, non che la capacità manchi. GPT-5.2 si distingue perché ha fatto questa scelta da solo, attivando il ragionamento per i prompt di coding più difficili e lasciandolo disattivo per le Q&A.
Effetto dell'endpoint sulla latenza per gli LLM
La latenza di un modello hosted non è solo il modello. Include anche lo stack di serving del provider, l'accodamento, il percorso di rete e la geografia. Il nostro roster lo mostra all'interno di una singola linea di modello. Claude Opus 4.8, servito tramite Google Vertex in Europa, ha restituito il suo primo token in circa 0,75 secondi, mentre Claude Opus 4.7, servito tramite l'API di Anthropic, ha impiegato circa 2 secondi.
Si tratta di versioni diverse, quindi il divario non è puramente dovuto all'endpoint, ma il pattern corrisponde a un effetto ben noto: gli stessi pesi possono essere diverse volte più veloci o più lenti a seconda di dove e come vengono serviti. Il nostro client di misurazione era in esecuzione in Europa, quindi l'endpoint Vertex europeo aveva un percorso di rete più breve, il che è parte del motivo per cui è risultato più veloce.
Per vedere come abbiamo scelto il provider per ciascun modello, leggi la nostra metodologia del benchmark.
Limite massimo di token e modelli di ragionamento
Per misurare la latenza in modo equo, abbiamo impostato una lunghezza massima fissa dell'output in modo che nessun modello venga premiato o penalizzato per aver scritto di più. Quel limite è il budget di token per l'intera risposta, ed è da lì che proviene la maggior parte dei fallimenti:
- I modelli di ragionamento spendono parte del budget per pensare prima che la risposta inizi.
- Sui prompt di coding difficili alcuni pensano molto, e in modo imprevedibile (MiniMax ha usato da circa 2.500 a 3.700 token di pensiero su un singolo prompt).
- Quando il pensiero riempie l'intero budget, non rimangono token per la risposta e la risposta torna vuota.
- Questo ha colpito più duramente MiniMax sul coding, dove il primo passaggio ha completato meno della metà delle sue richieste.
L'insegnamento è che il limite massimo di token è un parametro che vale la pena tenere d'occhio: impostalo troppo basso e un modello di ragionamento può spenderlo tutto a pensare senza mai arrivare a una risposta. Abbiamo aumentato il budget per i modelli di ragionamento, dato spazio al pensiero in aggiunta alla lunghezza della risposta, e riprovato le richieste fallite. La maggior parte delle lacune si è colmata, anche se alcune hanno continuato a fallire quando il pensiero di un modello superava persino il budget più ampio.
Aggiungi come fonte preferitaLLM metodologia del benchmark di latenza
Abbiamo sottoposto a benchmark 11 modelli linguistici con 1.320 richieste, misurando la rapidità con cui ciascun modello risponde.
Modelli
Abbiamo preso i cinque modelli più utilizzati su OpenRouter e abbiamo aggiunto altri sei modelli attuali in cima:
- Non di ragionamento per impostazione predefinita: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Di ragionamento per impostazione predefinita: DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Casi d'uso e prompt di esempio
Abbiamo utilizzato due casi d'uso con lunghezze di input e output fisse, in modo che i risultati riflettano la velocità e non la lunghezza casuale di un prompt o di una risposta:
- Risposta breve (Q&A): input breve (circa 256 token), output breve (limitato a 128 token). Esempio: “Qual è lo scopo di una chiave primaria in un database?”
- Risposta lunga (generazione di codice): input breve (circa 512 token), output lungo (limitato a 1.024 token). Esempio: “Costruisci un downloader di URL multi-thread in Python che prende una lista di URL di immagini e le scarica in modo concorrente.”
Ogni caso d'uso ha utilizzato 20 prompt e ogni prompt è stato inviato 3 volte per modello, ottenendo 60 misurazioni per modello per caso d'uso. Riportiamo la mediana (p50) e il p90.
Cosa abbiamo misurato
Abbiamo fatto lo streaming di ogni risposta e registrato quando la richiesta è stata inviata, quando è arrivato il primo token, quando è arrivato il primo token di risposta (dopo l'eventuale pensiero) e quando è arrivato l'ultimo token. Da questi abbiamo derivato il tempo al primo token, il tempo al primo token di risposta, la latenza per token e la velocità di output, e il tempo end-to-end.
Ragionamento vs non ragionamento
Ogni risposta restituisce un riepilogo di utilizzo che include un conteggio dei token di ragionamento. Abbiamo letto questo dato per ogni richiesta e contrassegnato la richiesta come di ragionamento quando il conteggio era superiore a zero e non di ragionamento quando era zero, invece di basarci sull'etichetta del modello. È così che abbiamo scoperto che GPT-5.2 ragiona sul coding ma non sulle Q&A.
Come abbiamo scelto i provider
Lo stesso modello è servito da provider diversi a velocità diverse, quindi abbiamo fissato ogni modello a un unico provider invece di lasciare che le richieste si instradassero liberamente. OpenRouter elenca uptime, latenza e throughput di ciascun provider, e abbiamo usato quelle cifre per scegliere. Abbiamo scartato qualsiasi provider con meno di circa il 98 percento di uptime, quindi abbiamo scelto il più veloce tra i restanti per latenza e throughput. Abbiamo fissato quel provider per ogni richiesta e registrato il provider che ha effettivamente servito ciascuna risposta per confermare che il fissaggio ha retto. Alcuni dei provider più veloci non erano raggiungibili con il nostro account e restituivano errori di limite di velocità, quindi abbiamo usato il provider più veloce che ha servito in modo affidabile.
I provider fissati sono stati Claude Opus 4.8 su Google Vertex (Europa), Claude Opus 4.7 su Anthropic, Claude Sonnet 5 e GPT-5.2 su Azure, Claude Fable 5 e Claude Haiku 4.5 su Amazon Bedrock, DeepSeek V4 Flash su Novita, MiMo v2.5 su DeepInfra, MiniMax M3 su Together, Gemini 3.1 Pro su Google Vertex, e Hunyuan HY3 su GMICloud.
Controlli
- Tutte le richieste sono state eseguite da una singola regione client.
- La lunghezza dell'output è stata limitata (128 per il breve, 1.024 per il lungo) in modo che la verbosità non distorca la latenza. Ai modelli di ragionamento è stato concesso un budget extra per il pensiero oltre questo limite.
- Ogni prompt iniziava con un blocco di testo unico per annullare la caching dei prompt, e abbiamo verificato che nessun token di input provenisse dalla cache.
- Tutti i conteggi dei token utilizzano un unico tokenizer in modo che la velocità sia confrontabile tra i modelli.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{LLM Benchmark di latenza per casi d'uso}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consultato il 8 Luglio 2026}
}Risultati e timestamp di 1.3 mila punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente un file CSV e un README.
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.