LLM benchmark di latenza per casi d'uso
We benchmarked 11 top large language models with a total of 1,320 requests, splitting reasoning and non-reasoning models, and measured first-token latency, per-token latency, and overall response time.
Qui puoi trovare i dettagli su come abbiamo misurato la latenza.
Tempo di risposta end-to-end per modello
LLM benchmark di latenza: risultati
Riportiamo separatamente i modelli reasoning e non-reasoning. I modelli reasoning trascorrono diversi secondi a pensare prima della prima risposta visibile, quindi confrontarli direttamente con i modelli non-reasoning in termini di latenza sarebbe fuorviante. Alcuni modelli cambiano anche comportamento a seconda dell'attività: GPT-5.2 risponde alle Q&A senza ragionamento ma ragiona sui prompt di coding.
Caso a risposta breve (Q&A)
Nel caso breve ciò che conta è la rapidità con cui appare il primo token di risposta, poiché l'intera risposta è solo una o due frasi. I modelli non-reasoning si concentrano 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 reasoning sono stati più lenti a raggiungere la prima parola della risposta anche in questo caso, perché prima pensano:
- 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 il passo di pensiero è per lo più un sovraccarico, poiché la risposta stessa è breve.
Caso a risposta lunga (generazione di codice)
Nel caso lungo il ritardo del primo token conta meno e subentrano la velocità di streaming e il tempo di risposta totale. claude-haiku-4-5 ha guidato entrambi, trasmettendo a circa 180 token al secondo e terminando in circa 5,5 secondi. Gli altri modelli non-reasoning 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 reasoning 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 modelli trasmettono rapidamente in streaming una volta avviati (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 le risposte lunghe. Ai modelli reasoning è 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 interrotta a metà pensiero.
Risposte brevi contro risposte lunghe
Il contrasto tra i due casi è il principale elemento da ricordare:
- 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-reasoning sono rimasti vicini alla testa (Haiku il più veloce a circa 5,5 secondi), mentre i modelli reasoning sono rimasti molto indietro a 18–35 secondi.
- Anche l'ordine all'interno del gruppo non-reasoning cambia: Haiku è stato uno dei diversi modelli a partire sotto il secondo sui prompt brevi, ma si porta chiaramente avanti sugli output lunghi grazie alla sua velocità di streaming.
Latenza al 90 percentile
Il modello principale è che la coda si moltiplica per i modelli reasoning anziché spostarsi semplicemente. 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 durata del pensiero varia da richiesta a richiesta, quindi questi modelli non sono solo più lenti ma anche meno prevedibili.
Alcuni punti emergono:
- MiMo è l'eccezione tra i modelli reasoning. 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 è stato sotto i 2 secondi, ma sul coding, dove attiva il ragionamento, il suo p90 è salito a circa 11 secondi.
- I modelli non-reasoning 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 è ampliato sugli output lunghi (circa 4 secondi alla mediana fino a 8 al p90), è rimasto molto al di sotto del gruppo reasoning.
Il punto pratico è che la mediana può nascondere questo aspetto. La mediana di MiniMax sul coding, circa 13 secondi, non è la peggiore del gruppo, ma il suo p90 di circa 42 secondi corrisponde a Hunyuan, quindi su una richiesta sfavorevole è lento quanto qualsiasi altro modello misurato.
LLM ragionamento e il suo effetto sulla velocità
I modelli reasoning impiegano più tempo a produrre il primo token di risposta perché generano token interni di catena di pensiero prima della risposta visibile. È proprio questa fase di pensiero ad aumentare il loro tempo alla prima risposta, da circa un secondo per i modelli non-reasoning a diversi secondi o più.
Se un modello ragiona non è sempre prestabilito. Abbiamo rilevato il ragionamento per ogni richiesta in base al numero di token di ragionamento restituiti da ciascuna risposta, quindi abbiamo raggruppato i risultati per attività. La quota di richieste in cui ciascun modello ha ragionato:
GPT-5.2 lo mostra direttamente: ha risposto ai prompt brevi 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 all'attività e la sua latenza cambia con quella decisione. È per questo che GPT-5.2 si colloca nel gruppo veloce sulle Q&A ma arretra sul coding.
Abbiamo misurato ogni modello nel suo stato predefinito. Diversi modelli sono ibridi che possono ragionare su richiesta ma vengono distribuiti con il pensiero disattivato: Claude Opus 4.8, per esempio, supporta il pensiero esteso, ma è disabilitato per impostazione predefinita, quindi non ha mai prodotto token di ragionamento nelle nostre esecuzioni ed è rimasto veloce, come gli altri modelli Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Gli altri hanno ragionato su quasi tutte le richieste, ed è per questo che appaiono più lenti alla prima risposta. 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 disattivato per le Q&A.
Effetto dell'endpoint sulla latenza per LLMs
La latenza di un modello ospitato non è solo il modello. Include anche lo stack di serving del provider, la coda, il percorso di rete e la geografia. Il nostro elenco lo mostra all'interno di una singola linea di modelli. Claude Opus 4.8, servito tramite Google Vertex in Europa, ha restituito il primo token in circa 0,75 secondi, mentre Claude Opus 4.7, servito tramite Anthropic con la sua API, ha impiegato circa 2 secondi.
Si tratta di versioni diverse, quindi il divario non è dovuto esclusivamente 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 è stato eseguito in Europa, quindi l'endpoint Vertex europeo aveva un percorso di rete più breve, il che è in parte il motivo per cui è risultato più veloce.
Per vedere come abbiamo scelto il provider per ciascun modello, leggi la nostra metodologia di benchmark.
Limite massimo di token e modelli reasoning
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 è derivata la maggior parte degli errori:
- I modelli reasoning spendono parte del budget per pensare prima che inizi la risposta.
- Sui prompt di coding difficili alcuni pensano molto e in modo imprevedibile (MiniMax ha usato circa 2.500–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 MiniMax soprattutto sul coding, dove il primo passaggio ha completato meno della metà delle sue richieste.
Il punto chiave è che il limite massimo di token è un parametro da tenere d'occhio: impostalo troppo basso e un modello reasoning può spenderlo tutto a pensare senza mai arrivare a una risposta. Abbiamo aumentato il budget per i modelli reasoning, abbiamo concesso spazio per il pensiero oltre la lunghezza della risposta e abbiamo ritentato le richieste fallite. La maggior parte delle lacune si è colmata, anche se alcune richieste sono ancora fallite quando il pensiero di un modello ha superato anche il budget più ampio.
Aggiungi come fonte preferitaLLM benchmark di latenza: metodologia
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ù usati su OpenRouter e abbiamo aggiunto altri sei modelli attuali:
- Non-reasoning per impostazione predefinita: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Reasoning 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 usato due casi d'uso con lunghezze fisse di input e output, in modo che i risultati riflettano la velocità e non quanto fossero lunghi un prompt o 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: “Crea un downloader multi-thread di URL in Python che accetti una lista di URL di immagini e li scarichi in modo concorrente.”
Ogni caso d'uso ha usato 20 prompt e ogni prompt è stato inviato 3 volte per modello, per un totale di 60 misurazioni per modello per caso d'uso. Riportiamo la mediana (p50) e il p90.
Cosa abbiamo misurato
Abbiamo trasmesso in streaming ogni risposta e registrato quando è stata inviata la richiesta, quando è arrivato il primo token, quando è arrivato il primo token di risposta (dopo l'eventuale pensiero) e quando è arrivato l'ultimo token. Da questi dati abbiamo ricavato 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.
Reasoning contro non-reasoning
Ogni risposta restituisce un riepilogo di utilizzo che include un conteggio dei token di ragionamento. Abbiamo letto questo dato per ogni richiesta e abbiamo contrassegnato la richiesta come reasoning quando il conteggio era superiore a zero e come non-reasoning quando era zero, invece di affidarci all'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 venissero instradate liberamente. OpenRouter elenca uptime, latenza e throughput di ciascun provider e abbiamo usato quelle cifre per scegliere. Abbiamo scartato qualsiasi provider con un uptime inferiore a circa il 98 percento, 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 vincolo reggesse. Alcuni dei provider più veloci non erano raggiungibili con il nostro account e restituivano errori di rate-limit, quindi abbiamo usato il provider più veloce che serviva 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 un'unica regione client.
- La lunghezza dell'output è stata limitata (128 per il breve, 1.024 per il lungo) affinché la verbosità non distorca la latenza. Ai modelli reasoning è stato concesso un budget extra per il pensiero oltre questo limite.
- Ogni prompt iniziava con un blocco di testo univoco per impedire la cache dei prompt e abbiamo verificato che nessun token di input provenisse dalla cache.
- Tutti i conteggi dei token usano un unico tokenizer, così la velocità è 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 = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consultato il 6 agosto 2026}
}Risultati e timestamp di 1.4 mila punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 6 file CSV e un README.
Vuoi i dati granulari che ci stanno dietro? Passa a Premium
Registro delle modifiche
5 aggiornamentiSostituiti gli intervalli di latenza approssimativi con valori di tempo precisi per modello nel benchmark di latenza.
L'elenco dei modelli confrontati è stato sostituito con 11 modelli attuali, con e senza ragionamento.
Espansa la sezione "Risultati del benchmark di latenza LLM" con i risultati dettagliati del benchmark di latenza del primo token e della latenza per token.
Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.
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.