Velocità di inferenza LLM spiegata: TTFT, throughput e cosa conta davvero

Due problemi rendono difficile il confronto. Il primo è che i provider misurano cose molto diverse: chi pubblicizza 400 token al secondo parla di altro rispetto a chi promette una latenza sotto i 200ms. Entrambe le affermazioni possono essere vere, eppure nessuna delle due è forse decisiva per il tuo caso d'uso.

Il secondo è che "veloce" è sempre relativo, e resta da chiedersi rispetto a cosa. Quando un provider basato su GPU si definisce veloce, di solito intende più veloce di altri provider GPU. All'interno di quella categoria è una baseline ragionevole, ma non dice nulla sulle prestazioni assolute. Un provider con hardware di inferenza specializzato può essere 5-10x più veloce, e a quel punto il confronto tra GPU perde di significato. Questo articolo spiega le tre metriche che determinano la velocità dell'inferenza LLM, quando conta ciascuna, e fornisce numeri reali con cui confrontarsi. Se stai valutando anche il prezzo, leggi l'articolo complementare Cosa non ti dice il 'Prezzo per Token'.

Le tre metriche che definiscono la velocità

Quando invii una richiesta a un'API LLM, la risposta non arriva tutta in una volta. Attraversa diverse fasi, e ognuna ha il proprio profilo di prestazioni.

La latenza, fase per fase:

Per uno sviluppatore in Europa che chiama un provider negli USA, la latenza si compone così:

• Round-trip di rete: 80-150ms (è la velocità della luce nella fibra, e nessun software può cambiarla)
• Handshake TLS: 1-3 round-trip in più per ogni nuova connessione (con il connection pooling li eviti nelle richieste successive)
• Overhead del gateway: 10-50ms (autenticazione, rate limiting, routing)
• Tempo in coda: da 0ms a diversi secondi (dipende dal carico e dalla capacità)
• Prefill: dipende dalla lunghezza del prompt
• Decode: dipende dalla lunghezza dell'output e dal throughput

Perché prefill e decode vanno considerati separatamente:

Nel prefill il modello elabora in parallelo l'intero prompt. Legge tutti i token in una volta e costruisce una rappresentazione interna, la KV cache. Questa fase è compute-bound: conta soprattutto la potenza di calcolo pura.

Nel decode il modello genera l'output un token alla volta. Ogni nuovo token dipende da tutti i precedenti, quindi la fase è sequenziale. È memory-bound: il chip passa la maggior parte del tempo a leggere dalla memoria i pesi del modello e la cache, e aspetta i dati prima di poter calcolare il token successivo.

Le diverse architetture hardware gestiscono queste due fasi in modo diverso:

Le GPU sono forti nel prefill, perché sono nate per il calcolo parallelo. Nel decode invece faticano: l'utilizzo scende al 20-40%, perché le unità di calcolo restano ferme in attesa della memoria.

I chip di inferenza specializzati, come l'RDU di SambaNova, l'LPU di Groq e il WSE di Cerebras, sono progettati per la fase di decode memory-bound. Tengono i dati sul chip, riducono i round-trip verso la memoria e restano molto utilizzati anche durante la generazione sequenziale dei token. Il risultato è un decode 3-10x più veloce sui modelli grandi.

Questa latenza di rete si paga due volte, all'andata con la richiesta e al ritorno con la risposta. Un provider che pubblicizza 300ms di TTFT dalla Virginia arriva a Monaco con 400ms o più. Prima ancora che l'inferenza cominci, sono già passati 100ms sulla rete.

L'overhead del gateway di solito è piccolo, ma c'è sempre. La grande incognita è il tempo in coda: su un'infrastruttura condivisa la tua richiesta aspetta dietro quelle degli altri clienti. La stessa API può rispondere all'istante alle 3 di notte e sembrare lenta alle 15. Con la capacità dedicata non competi più con altri clienti, e le prestazioni diventano prevedibili.

Time to First Token (TTFT)

Il TTFT misura il tempo che passa dall'invio di una richiesta al primo token che torna in streaming. Determina quanto un'applicazione sembra reattiva. Con un TTFT di 200ms la risposta sembra istantanea. Uno schermo vuoto per 2 secondi, invece, dà l'impressione che l'applicazione sia rotta, anche se il tempo di risposta totale alla fine è lo stesso.

Con prompt brevi o medi, intorno a 1K token, in una chat interattiva tutto ciò che sta sotto i 300ms risulta eccellente. Tra 300 e 600ms il tempo è accettabile per la maggior parte delle applicazioni. Oltre i 600ms gli utenti iniziano a notare il ritardo, e oltre il secondo pensano che qualcosa non funzioni.

Il TTFT però cresce con la lunghezza dell'input, ed è qui che i benchmark diventano fuorvianti. Un prompt da 100 token può tornare in 200ms. Un prompt da 10K token richiede più tempo per il prefill: anche su un'infrastruttura veloce bisogna aspettarsi 400-800ms. Con 100K token, diversi secondi sono normali. Un benchmark del TTFT che non indica la lunghezza dell'input non ha quindi senso: "300ms TTFT" su un prompt breve non è niente di speciale, su 10K token è notevole.

Tre fattori determinano il TTFT:

• Calcolo del prefill - il modello deve elaborare tutto l'input prima di iniziare a generare l'output. Più il prompt è lungo, più il TTFT sale.
• Tempo in coda - se il provider è sovraccarico, la tua richiesta aspetta prima ancora che l'elaborazione cominci.
• Latenza di rete - quando un utente nell'UE chiama un provider negli USA, si aggiungono 100-150ms prima che l'inferenza inizi. È fisica e non si può ottimizzare. Per questo la residenza dei dati conta anche per le prestazioni, non solo per la compliance.

Il TTFT conta soprattutto nelle applicazioni interattive, dove una persona guarda lo schermo: interfacce di chat, assistenti di coding nell'IDE, voice AI e tutto ciò che funziona in tempo reale.

Throughput di output (token al secondo)

Il throughput misura la velocità con cui arrivano i token dopo il primo. Determina quando hai la risposta completa. Una risposta da 1.000 token richiede 10 secondi a 100 tok/s e 2,5 secondi a 400 tok/s. Con output più lunghi il divario cresce di conseguenza.

Il throughput dipende molto dall'architettura del modello, per cui i confronti tra modelli diversi sono fuorvianti. Un modello dense da 70B legge tutti i 70B parametri per ogni token. Un modello MoE da 671B come DeepSeek può attivarne solo 37B per token. Meno parametri attivi significano un decode più veloce, anche se il modello nel complesso è più grande. Conta anche l'hardware: le GPU faticano con il decode memory-bound, mentre chip di inferenza specializzati come l'RDU di SambaNova, l'LPU di Groq e il WSE di Cerebras sono progettati proprio per questo. E a parità di architettura, i modelli più grandi sono sempre più lenti: sullo stesso hardware un modello da 7B supera un modello da 70B.

L'unico confronto equo è quello dello stesso modello su provider diversi. DeepSeek R1 671B gira a 30-80 tok/s sui provider basati su GPU, mentre l'RDU di SambaNova arriva a 250+ tok/s. È il valore più alto registrato da Artificial Analysis per quel modello. Con Llama 3.3 70B il divario è ancora più netto: 50-150 tok/s su GPU contro 2.100 tok/s sul WSE di Cerebras e 1.200+ tok/s sull'LPU di Groq.

Il throughput conta soprattutto quando un sistema può proseguire solo con la risposta completa. I workflow agentici sono l'esempio più chiaro, come mostra il nostro articolo sul throughput nell'agentic coding. Lo stesso vale per l'elaborazione batch, la generazione di testi lunghi e qualsiasi workflow in cui la produttività dipende dal tempo totale di completamento.

Latenza end-to-end

La latenza end-to-end è il tempo totale dalla richiesta alla risposta completa, cioè il TTFT più il tempo necessario a generare tutti i token di output.

Il calcolo è semplice. Con 1.000 token di output, 100 tok/s e 500ms di TTFT, aspetti 0,5 secondi per il primo token e poi altri 10 secondi per il resto, 10,5 secondi in tutto. A 400 tok/s con 600ms di TTFT, lo stesso output richiede 3,1 secondi. Il throughput 4x più alto compensa ampiamente il TTFT più lento.

La latenza end-to-end conta soprattutto quando nessuno segue l'output intermedio. Pipeline batch, chiamate API di backend e applicazioni con SLA sul tempo di risposta totale guardano a quando il lavoro finisce, non a quando comincia.

Perché queste metriche si ostacolano a vicenda

Ottimizzare una metrica spesso ne peggiora un'altra.

Il compromesso tra TTFT e throughput:

La fase di prefill (elaborazione dell'input) e quella di decode (generazione dell'output) si contendono lo stesso hardware. Un provider può configurare la propria infrastruttura per uno di due obiettivi:

1. Ottimizzare il TTFT: più risorse al prefill, così la generazione parte presto, ma il decode è più lento
2. Ottimizzare il throughput: più richieste per batch e quindi un throughput più alto per richiesta, ma tempi di coda più lunghi

Questo compromesso sta cambiando. Il settore si sta muovendo verso l'inferenza disaggregata, in cui prefill e decode girano su hardware separato e specializzato. Le GPU gestiscono in modo efficiente il prefill compute-bound, mentre i chip ottimizzati per la memoria si occupano del decode. Al GTC 2026 NVIDIA ha annunciato questa direzione, e SambaNova si è unita a Intel per un'architettura eterogenea: GPU per il prefill, RDU per il decode, Xeon per l'orchestrazione. I primi risultati mostrano un throughput superiore del 50% o più, senza penalizzare il TTFT.

Per ora, però, la maggior parte dei provider fa ancora girare entrambe le fasi sullo stesso hardware. Per questo lo stesso modello si comporta diversamente da un provider all'altro. Il provider A costa meno, ma la sua velocità varia. Il provider B costa di più, ma offre prestazioni costanti. Il modello è identico, cambiano solo le scelte infrastrutturali.

La lunghezza del contesto amplifica tutto:

La maggior parte dei provider applica la stessa tariffa per token, indipendentemente dalla lunghezza del contesto. Il costo di calcolo, però, non resta costante.

Il costo del prefill cresce in modo circa quadratico con la lunghezza del contesto, perché il modello calcola l'attention tra tutte le coppie di token:

• 1.000 token: 1 milione di calcoli di attention
• 10.000 token: 100 milioni di calcoli di attention

I dati di sistemi in produzione mostrano l'effetto. Un prompt con un contesto da 128K richiede circa 4 secondi di prefill su un'infrastruttura ottimizzata. Uno con un contesto da 1M ne richiede circa 77. Modello e hardware sono gli stessi, cambia solo la lunghezza dell'input.

Quale metrica per quale caso d'uso

Nella chat interattiva il TTFT ha la precedenza sul throughput. Gli utenti leggono mentre i token arrivano, quindi conta soprattutto che la risposta parta. Una generazione più lenta la perdonano, se la risposta inizia in fretta. Con i workflow agentici è il contrario: gli agenti aspettano la risposta completa prima di agire, e tra un passaggio e l'altro nessuno guarda. Qui decide il throughput. La voice AI ha bisogno di entrambi, perché il tempo della prima risposta influisce sul flusso della conversazione e anche il ritmo del parlato deve essere giusto. L'elaborazione batch guarda quasi soltanto al throughput e al tempo totale di completamento. Le pipeline RAG stanno nel mezzo: devono essere reattive, ma di solito a dominare è comunque la latenza del retrieval.

Il caso d'uso: i workflow agentici

Strumenti di agentic coding come Cursor, Cline o Codex CLI mostrano perché per alcuni workload il throughput è decisivo. Un solo task di programmazione può richiedere da 50 a oltre 200 chiamate LLM: l'agente legge file, costruisce il contesto, pianifica come procedere, genera codice, esegue test, corregge gli errori e ripete finché il lavoro non è finito.

Ogni chiamata genera centinaia di token. Una sessione da 300K token, normale per un refactoring complesso, richiede circa 50 minuti di pura inferenza a 100 tok/s. A 400 tok/s la stessa sessione richiede 12 minuti. Quei 38 minuti di differenza decidono se resti concentrato nel flusso di lavoro o passi a Slack mentre aspetti.

Il fattore sottovalutato: la consistenza sotto carico

I benchmark mostrano le prestazioni di picco, mentre in produzione il carico varia.

Le domande da fare ai provider:

• Latenza P50 e P99: il 99° percentile mostra le prestazioni nel caso peggiore. Se P99 è 5x più alto di P50, i tuoi utenti saranno frustrati.
• Rate limit: riesci a raggiungere le velocità pubblicizzate, o i limiti ti frenano prima?
• Prestazioni sotto carico elevato: il throughput regge quando invii 100 richieste al secondo?

Artificial Analysis pubblica benchmark indipendenti che rilevano queste variazioni. I provider vengono testati di continuo, per cui si vedono non solo le prestazioni di picco, ma anche la loro consistenza nel tempo.

Come fare i tuoi benchmark

Non fidarti dei numeri del marketing: misura con i tuoi workload reali.

Testa con le lunghezze di prompt che usi in produzione. Tra 1K e 100K token di input le prestazioni cambiano molto, e la maggior parte dei benchmark di marketing usa prompt brevi che abbelliscono i risultati. Testa anche le lunghezze di output che ti aspetti, perché completamenti brevi e testi lunghi hanno profili di prestazione diversi. Se invii richieste in parallelo, misura proprio quello scenario invece di testare singole richieste isolate. Soprattutto, testa nelle ore di punta. Fuori da quelle ore vedi il caso migliore, che in produzione capita di rado. Artificial Analysis pubblica confronti indipendenti tra provider, se vuoi una baseline neutrale. Ma niente sostituisce la misurazione dei tempi nel tuo ambiente di produzione.

Quale metrica conta di più?

Dipende dal tuo workload. Se gli utenti guardano lo schermo, dai priorità al TTFT: se la risposta parte entro un secondo, sembra istantanea. Se sono gli agenti ad aspettare le risposte, dai priorità al throughput, perché token più veloci significano task completati prima. Se elabori grandi volumi, dai priorità alla latenza end-to-end e alla consistenza: il tempo totale di completamento e SLA prevedibili contano più della velocità di picco.

La maggior parte delle applicazioni in produzione ha bisogno di prestazioni accettabili su tutte e tre le metriche. Un throughput altissimo con 3 secondi di TTFT frustra gli utenti interattivi. Un TTFT istantaneo con 50 tok/s di throughput diventa un collo di bottiglia per i workflow agentici. Questi compromessi non si possono evitare.

Su benchmark.infercom.ai puoi provare i tuoi prompt sulla nostra infrastruttura. Per confronti standardizzati, consulta i nostri benchmark pubblicati.

Perché lo chiamiamo "Ultraspeed"

Ecco perché il nostro MiniMax M2.7 si chiama Ultraspeed:

1. Architettura dataflow di SambaNova. Si tratta di hardware progettato apposta per l'inferenza, non di GPU riadattate. L'RDU elimina il collo di bottiglia della memoria che limita il throughput delle GPU. Come il dataflow genera velocità
2. 428 token al secondo. Con questo throughput misurato i workflow agentici diventano praticabili. Un task di programmazione da 50 passaggi, che su un'infrastruttura GPU standard richiederebbe un'ora, si completa in pochi minuti.
3. 690ms di TTFT con 10K token di input, sotto i 150ms con prompt brevi. I valori sono misurati dalla Germania verso la nostra infrastruttura di Monaco. Gli utenti nell'UE ottengono il vantaggio di latenza senza i 100ms o più che costa la strada verso i datacenter negli USA.

Ultraspeed gira su infrastruttura condivisa. Benefici dell'architettura e dell'hosting nell'UE, ma il tempo in coda varia con il carico della piattaforma, come per qualsiasi servizio condiviso.

Prova MiniMax M2.7 Ultraspeed

In sintesi

Le affermazioni sulla velocità senza contesto non significano nulla. Chiedi sempre: quale metrica, quale lunghezza di input, quale baseline? "L'API LLM più veloce" può voler dire il TTFT più rapido su prompt brevi, il throughput più alto su un modello specifico o la latenza end-to-end più bassa in condizioni ideali. Senza questo contesto, l'affermazione non ti dice nulla.

È il tuo workload a stabilire quale metrica conta. Le applicazioni interattive hanno bisogno di un TTFT basso, i workflow agentici di un throughput alto e l'elaborazione batch di una latenza end-to-end stabile. La maggior parte dei sistemi in produzione ha bisogno di prestazioni accettabili su tutte e tre.

La consistenza sotto carico conta quanto le prestazioni di picco. Un provider che offre 400 tok/s alle 3 di notte ma 150 tok/s in orario di lavoro non è un provider da 400 tok/s per il tuo workload in produzione.

La latenza di rete è fisica, non software. Per gli utenti nell'UE un provider di inferenza a Monaco sarà sempre più veloce di uno in Virginia, perché nessuna ottimizzazione può battere la velocità della luce. La residenza dei dati quindi non riguarda solo la compliance: è anche un vantaggio in termini di prestazioni.