LLM Benchmark di latenza per casi d'uso
Abbiamo sottoposto a benchmark 11 modelli linguistici di grandi dimensioni di punta tramite modelli linguistici di grandi dimensioni con un totale di 1.320 richieste, suddividendo tra modelli reasoning e non-reasoning, e abbiamo misurato la latenza del primo token, la latenza per token e il tempo di risposta complessivo.
LLM benchmark di latenza
Puoi trovare i dettagli su come abbiamo misurato la latenza qui.
Tempo di risposta end-to-end per modello
LLM Risultati del benchmark di latenza
Riportiamo separatamente i modelli reasoning e non-reasoning. I modelli reasoning impiegano 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 del compito: GPT-5.2 risponde alle domande di Q&A senza ragionamento, ma utilizza il ragionamento per i prompt di codifica.
Caso di risposta breve (Q&A)
Nel caso di risposta breve ciò che conta è la rapidità con cui appare il primo token di risposta, poiché l'intera risposta è composta solo da 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 di risposta anche in questo caso, 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
Per le domande brevi, il passo di ragionamento è per lo più un sovraccarico, poiché la risposta stessa è breve.
Caso di risposta lunga (generazione di codice)
Nel caso di risposta lunga, il ritardo del primo token conta meno, e lo streaming spNel caso di risposta lunga, il ritardo del primo token conta meno, e la velocità di streaming e il tempo di risposta complessivo prendono il sopravvento. claude-haiku-4-5 ha guidato entrambi, in streaming a circa 180 token al secondo e terminando in circa 5.5 secondi. Gli altri modelli non-reasoning hanno terminato all'incirca in 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, poiché il ragionamento e la lunga risposta 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 streammano rapidamente una volta partiti (hy3-preview corre a circa 200 token al secondo), ma il pensiero iniziale mantiene alto il tempo totale.
La lunghezza dell'output è stata limitata anziché lasciata libera, quindi i modelli non vengono confrontati in base alla verbosità: circa 128 token per le risposte brevi e 1.024 per le risposte lunghe. Ai modelli reasoning è stato assegnato un budget aggiuntivo oltre questo limite per contenere i token di ragionamento, in modo che i loro tempi end-to-end riflettano il ragionamento più la risposta anziché una risposta interrotta a metà del pensiero.
Risposte brevi contro risposte lunghe
Il contrasto tra i due casi è il punto principale:
- 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 in testa (Haiku più veloce a circa 5.5 secondi), mentre i modelli reasoning sono rimasti molto indietro a da 18 a 35 secondi.
- Anche l'ordine all'interno del gruppo non-reasoning cambia: Haiku era uno dei diversi modelli che partivano in meno di un secondo sui prompt brevi, ma si porta nettamente in testa 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é semplicemente spostarsi. Nel compito di codifica, MiniMax è passato da circa 13 secondi alla mediana a 42 secondi al 90° percentile, e Hunyuan da circa 16 a 46 secondi. Il tempo extra è il ragionamento, e la lunghezza del ragionamento 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. Utilizza il ragionamento su ogni richiesta ma pensa brevemente, quindi il suo 90° percentile è 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 quando utilizza il ragionamento. Nel Q&A il suo 90° percentile era inferiore a 2 secondi, ma nella codifica, dove attiva il ragionamento, è salito a circa 11 secondi.
- I modelli non-reasoning sono rimasti compatti. Haiku 4.5 e Opus 4.8 hanno mantenuto il 90° percentile entro circa 2-2.5 secondi. Persino Sonnet 5, che si è allargato sugli output lunghi (circa 4 secondi alla mediana a 8 al 90° percentile), è rimasto molto al di sotto del gruppo reasoning.
Il punto pratico è che la mediana può nascondere questo aspetto. La mediana di MiniMax nella codifica, circa 13 secondi, non è la peggiore del gruppo, ma il suo 90° percentile di circa 42 secondi eguaglia Hunyuan, quindi in una richiesta sfavorevole è lento quanto qualsiasi modello misurato.
LLM ragionamento e il suo effetto sulla velocità
I modelli reasoning impiegano più tempo a produrre il loro primo token di risposta perché generano token interni di catena di pensiero prima della risposta visibile. Questo passaggio di pensiero è ciò che aumenta il loro tempo per la prima risposta, da circa un secondo per i modelli non-reasoning a diversi secondi o più.
Se un modello utilizzi il ragionamento 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 percentuale di richieste in cui ciascun modello ha utilizzato il ragionamento:
GPT-5.2 lo dimostra direttamente: ha risposto ai prompt Q&A brevi senza ragionamento, ma ha usato il ragionamento sulla maggior parte dei prompt di codifica. Per un modello ibrido come questo, “reasoning” 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 per Q&A ma arretra nella codifica.
Abbiamo misurato ogni modello nel suo stato predefinito. Diversi modelli sono ibridi che possono ragionare su richiesta ma vengono forniti 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, come gli altri modelli Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Gli altri hanno ragionato su quasi ogni richiesta, motivo per cui appaiono più lenti nel primo tempo di 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 codifica più difficili e disattivandolo per Q&A.
Effetto dell'endpoint sulla latenza per gli LLMs
La latenza di un modello ospitato non è solo del modello. Include anche lo stack di serving del provider, l'accodamento, il percorso di rete e la geografia. La nostra selezione 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 lo schema 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 spiega in parte perché è risultato più veloce.
Per sapere come abbiamo scelto il provider per ciascun modello, leggi la nostra metodologia del 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ù. Questo limite è il budget di token per l'intera risposta, ed è da qui che provengono la maggior parte dei fallimenti:
- I modelli reasoning spendono parte del budget per pensare prima che inizi la risposta.
- Su prompt di codifica difficili, alcuni pensano molto e in modo imprevedibile (MiniMax ha utilizzato circa da 2.500 a 3.700 token di pensiero in un singolo prompt).
- Quando il pensiero riempie tutto il budget, non rimangono token per la risposta e la risposta arriva vuota.
- Questo ha colpito più duramente MiniMax nella codifica, dove il primo passaggio ha completato meno della metà delle sue richieste.
La conclusione è che il limite massimo di token è un parametro da tenere d'occhio: impostarlo 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, dato spazio al pensiero oltre la lunghezza della risposta, e riprovato le richieste fallite. La maggior parte dei vuoti si è riempita, anche se alcune richieste sono ancora fallite quando il pensiero del modello ha superato anche 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:
- 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 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: “Crea un downloader di URL multi-threaded in Python che prende una lista di URL di immagini e li scarica in modo concorrente.”
Ogni caso d'uso ha utilizzato 20 prompt, e ciascun prompt è stato inviato 3 volte per modello, ottenendo 60 misurazioni per modello per caso d'uso. Riportiamo la mediana (p50) e il 90° percentile.
Cosa abbiamo misurato
Abbiamo trasmesso in streaming 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-reasoning
Ogni risposta restituisce un riepilogo di utilizzo che include un conteggio dei token di ragionamento. Abbiamo letto questo per ogni richiesta e contrassegnato la richiesta come reasoning quando il conteggio era superiore a zero e non-reasoning quando era zero, invece di basarci sull'etichetta del modello. È così che abbiamo scoperto che GPT-5.2 utilizza il ragionamento nella codifica ma non nel Q&A.
Come abbiamo scelto i provider
Lo stesso modello è servito da provider diversi a velocità diverse, quindi abbiamo assegnato ogni modello a un unico provider invece di lasciare che le richieste venissero instradate liberamente. OpenRouter elenca tempo di attività, latenza e throughput di ciascun provider e abbiamo utilizzato queste cifre per scegliere. Abbiamo scartato qualsiasi provider con un tempo di attività inferiore a circa il 98 percento, quindi abbiamo scelto il più veloce tra i rimanenti per latenza e throughput. Abbiamo fissato quel provider per ogni richiesta e registrato il provider che ha effettivamente servito ogni risposta per confermare che l'assegnazione fosse rispettata. Alcuni dei provider più veloci non erano raggiungibili con il nostro account e restituivano errori di limite di velocità, quindi abbiamo utilizzato il provider più veloce che servisse in modo affidabile.
I provider fissati erano 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 le risposte brevi, 1.024 per quelle lunghe) in modo che la verbosità non distorca la latenza. Ai modelli reasoning è stato assegnato un budget extra per il pensiero oltre questo limite.
- Ogni prompt iniziava con un blocco di testo unico per impedire la cache dei prompt, e abbiamo verificato che nessun token di input provenisse dalla cache.
- Tutti i conteggi dei token utilizzano un unico tokenizzatore 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 = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consultato il 12 Agosto 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.
Il lavoro di Cem è stato citato da importanti pubblicazioni globali tra cui Business Insider, Forbes, Washington Post, aziende globali come Deloitte, HPE e ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione europea.
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente di tecnologia e imprenditore tecnologico. Ha consigliato aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un rapporto McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha anche guidato la crescita commerciale dell'azienda deep tech Hypatos che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da 0 in 2 anni. Il lavoro di Cem in Hypatos è stato trattato da importanti pubblicazioni tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato in ingegneria informatica all'Università Bogazici e ha conseguito un MBA presso la 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.