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

Ogni provider di inferenza parla di velocità. Le pagine marketing mostrano numeri impressionanti. Ma cosa significa realmente "veloce"?

Due problemi rendono difficile l'interpretazione. Primo: quando un provider pubblicizza 400 token al secondo e un altro vanta latenza sotto i 200ms, stanno misurando cose completamente diverse. Entrambe le affermazioni possono essere vere - e nessuna delle due potrebbe essere rilevante per il tuo caso d'uso.

Secondo: "veloce" è sempre relativo - ma relativo a cosa? Quando un provider basato su GPU afferma di essere veloce, di solito intende veloce rispetto ad altri provider GPU. È una baseline ragionevole all'interno della loro categoria, ma non dice nulla sulle prestazioni assolute. Un provider con hardware di inferenza specializzato potrebbe offrire 5-10x la velocità, rendendo irrilevante il confronto GPU. Questo articolo analizza le tre metriche che definiscono la velocità di inferenza, spiega quando ciascuna è importante e fornisce numeri reali per il confronto. 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 insieme. Fluisce in fasi, e ogni fase ha la sua caratteristica di performance.

La scomposizione completa della latenza:

Per uno sviluppatore europeo che chiama un provider US:

• Round-trip di rete: 80-150ms (velocità della luce attraverso la fibra - nessun software può risolvere questo)
• Handshake TLS: 1-3 round-trip aggiuntivi su nuove connessioni (usa connection pooling per evitarlo nelle richieste successive)
• Overhead gateway: 10-50ms (autenticazione, rate limiting, routing)
• Tempo in coda: 0ms a secondi (dipende dal carico e dalla capacità)
• Prefill: varia in base alla lunghezza del prompt
• Decode: varia in base alla lunghezza dell'output e al throughput

Prefill vs Decode - perché contano separatamente:

Prefill elabora l'intero prompt di input in parallelo. Il modello legge tutti i tuoi token contemporaneamente e costruisce una rappresentazione interna (la KV cache). Questa fase è compute-bound - la velocità di calcolo pura conta di più.

Decode genera i token di output uno alla volta. Ogni nuovo token dipende da tutti i precedenti, quindi è sequenziale. Questa fase è memory-bound - il chip passa la maggior parte del tempo a leggere i pesi del modello e la cache dalla memoria, aspettando che i dati arrivino prima di poter calcolare il token successivo.

Diverse architetture hardware gestiscono queste fasi in modo diverso:

Le GPU eccellono nel prefill - il calcolo parallelo è ciò per cui sono progettate - ma faticano con il decode. Durante il decode, l'utilizzo della GPU scende al 20-40% mentre le unità di calcolo rimangono inattive in attesa della memoria.

Chip di inferenza specializzati come l'RDU di SambaNova, l'LPU di Groq e il WSE di Cerebras sono architettati per la fase di decode memory-bound. Mantengono i dati on-chip, riducono i round-trip di memoria e mantengono un'alta utilizzazione anche durante la generazione sequenziale di token. Il risultato: 3-10x decode più veloce sui modelli grandi.

La latenza di rete ti colpisce due volte - richiesta e risposta. Un provider che pubblicizza 300ms TTFT dalla Virginia consegna 400ms+ a Monaco. Prima che avvenga qualsiasi inferenza, hai già speso 100ms sulla rete.

L'overhead del gateway è solitamente piccolo ma sempre presente. Il tempo in coda è la variabile nascosta - su infrastruttura condivisa, aspetti dietro le richieste di altri clienti. La stessa API può sembrare istantanea alle 3 di notte e lenta alle 15. La capacità dedicata elimina la contesa con altri clienti, rendendo le prestazioni prevedibili.

Time to First Token (TTFT)

TTFT misura la latenza da quando invii una richiesta a quando il primo token inizia a tornare in streaming. Determina la reattività percepita. Un TTFT di 200ms sembra istantaneo. Uno schermo vuoto per 2 secondi sembra rotto, anche se il tempo di risposta totale finisce per essere lo stesso.

Per prompt da corti a medi intorno a 1K token, qualsiasi cosa sotto i 300ms sembra eccellente per la chat interattiva. Tra 300-600ms è accettabile per la maggior parte delle applicazioni. Oltre 600ms, gli utenti iniziano a notare il ritardo. Oltre un secondo e presumeranno che qualcosa non funzioni.

Ma il TTFT scala con la lunghezza dell'input, ed è qui che i benchmark diventano fuorvianti. Un prompt da 100 token potrebbe tornare in 200ms. Un prompt da 10K token richiede più tempo per il prefill - aspettati 400-800ms anche su infrastruttura veloce. Un prompt da 100K token? Diversi secondi sono normali. I benchmark TTFT senza lunghezza dell'input sono privi di significato. "300ms TTFT" su un prompt corto non è notevole. "300ms TTFT" su 10K token è impressionante.

Tre fattori determinano il TTFT:

• Compute di prefill - il modello deve elaborare tutto l'input prima di generare output, quindi prompt più lunghi significano TTFT più lungo.
• Tempo in coda - se il provider è sovraccarico, la tua richiesta aspetta prima ancora che l'elaborazione inizi.
• Latenza di rete - un utente EU che chiama un provider US aggiunge 100-150ms prima che l'inferenza inizi. La fisica aggiunge latenza che non puoi ottimizzare, ecco perché la residenza dei dati conta per le prestazioni, non solo per la compliance.

Il TTFT conta di più per le applicazioni interattive dove un umano sta guardando lo schermo: interfacce chat, assistenti di coding negli IDE, voice AI, qualsiasi cosa in tempo reale.

Throughput di output (Token al secondo)

Il throughput misura quanto velocemente i token arrivano in streaming dopo il primo. Determina quanto velocemente ricevi la risposta completa. Per una risposta da 1.000 token, la differenza tra 100 tok/s e 400 tok/s è 10 secondi contro 2,5 secondi. Quel divario si amplifica con output più lunghi.

Il throughput dipende fortemente dall'architettura del modello, il che rende fuorvianti i confronti tra modelli. Un modello dense da 70B legge 70B parametri per ogni token. Un modello MoE da 671B come DeepSeek potrebbe attivare solo 37B parametri per token - meno parametri attivi significa decode più veloce nonostante la dimensione totale maggiore. Anche l'hardware conta: 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 specificamente per questo. E all'interno della stessa architettura, i modelli più grandi sono sempre più lenti - un modello da 7B supererà un modello da 70B su hardware identico.

L'unico confronto equo è lo stesso modello su provider diversi. DeepSeek R1 671B gira a 30-80 tok/s sui provider basati su GPU, ma l'RDU di SambaNova offre 250+ tok/s - il più veloce registrato da Artificial Analysis per quel modello. Llama 3.3 70B mostra un divario ancora più marcato: 50-150 tok/s su GPU contro 2.100 tok/s su Cerebras WSE e 1.200+ tok/s su LPU di Groq.

Il throughput conta di più quando qualcosa sta aspettando la risposta completa prima di agire. I workflow agentici sono l'esempio più chiaro - vedi perché il throughput conta per l'agentic coding. Elaborazione batch, generazione di contenuti lunghi, qualsiasi workflow dove il tempo totale di completamento guida la produttività.

Latenza end-to-end

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

La matematica è semplice. Per un output da 1.000 token a 100 tok/s con 500ms TTFT, aspetti 0,5 secondi per il primo token, poi 10 secondi per il resto - 10,5 secondi in totale. A 400 tok/s con 600ms TTFT, lo stesso output richiede 3,1 secondi. Il TTFT più lento è più che compensato da un throughput 4x più veloce.

La latenza end-to-end conta di più quando nessun umano sta guardando l'output intermedio. Pipeline di elaborazione batch, chiamate API backend, applicazioni vincolate da SLA con requisiti di tempo di risposta totale - a questi interessa quando il lavoro finisce, non quando inizia.

Perché queste metriche sono in conflitto

Ottimizzare per una metrica spesso danneggia un'altra.

Tradeoff TTFT vs. throughput:

La fase di prefill (elaborazione del tuo input) e la fase di decode (generazione dell'output) competono per le stesse risorse hardware. Un provider può configurare la propria infrastruttura per:

1. Ottimizzare per TTFT: Dedicare più risorse al prefill, iniziare a generare velocemente, ma decode più lento
2. Ottimizzare per throughput: Raggruppare più richieste insieme, throughput più alto per richiesta, ma tempi di coda più lunghi

Questo tradeoff sta cambiando. L'industria si sta muovendo verso l'inferenza disaggregata - eseguire prefill e decode su hardware separato e specializzato. Le GPU gestiscono efficientemente il prefill compute-bound; i chip ottimizzati per la memoria gestiscono il decode. Al GTC 2026, NVIDIA ha annunciato questa direzione, e SambaNova ha collaborato con Intel su un'architettura eterogenea: GPU per prefill, RDU per decode, Xeon per l'orchestrazione. I primi risultati mostrano guadagni di throughput del 50%+ senza penalità sul TTFT.

Per ora, però, la maggior parte dei provider esegue ancora entrambe le fasi sullo stesso hardware. Lo stesso modello da provider diversi performa in modo diverso. Il provider A costa meno ma ha velocità variabile. Il provider B costa di più ma offre prestazioni costanti. Il modello sottostante è identico; le scelte infrastrutturali differiscono.

La lunghezza del contesto amplifica tutto:

La maggior parte dei provider addebita la stessa tariffa per token indipendentemente dalla lunghezza del contesto. Ma il costo computazionale non è piatto.

Il prefill scala approssimativamente in modo quadratico con la lunghezza del contesto. Il modello calcola l'attention tra ogni coppia di token:

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

I numeri reali dai sistemi di produzione mostrano l'impatto. Un prompt con contesto da 128K richiede ~4 secondi per il prefill su infrastruttura ottimizzata. Un prompt con contesto da 1M richiede ~77 secondi. Stesso modello, stesso hardware - solo più input.

Abbinare le metriche ai casi d'uso

La chat interattiva prioritizza il TTFT sul throughput. Gli utenti leggono mentre i token arrivano in streaming, quindi la prima risposta conta di più - perdoneranno una generazione più lenta se la risposta inizia velocemente. I workflow agentici invertono questo: gli agenti aspettano risposte complete prima di agire, nessun umano guarda tra i passaggi, quindi il throughput domina. La voice AI ha bisogno di entrambi - il tempo di risposta iniziale influenza il flusso della conversazione, ma anche il ritmo del parlato conta. L'elaborazione batch si preoccupa quasi esclusivamente di throughput e tempo totale di completamento. Le pipeline RAG cadono da qualche parte nel mezzo, bilanciando la reattività con la latenza di retrieval che di solito domina comunque.

Il caso d'uso agentico

Strumenti di agentic coding come Cursor, Cline o Codex CLI illustrano perché il throughput domina alcuni workload. Un singolo task di coding potrebbe richiedere 50-200+ chiamate LLM mentre l'agente legge file, costruisce contesto, pianifica un approccio, genera codice, esegue test, debugga errori e itera fino a completamento.

Ogni chiamata genera centinaia di token. A 100 tok/s, una sessione da 300K token - comune per refactoring complessi - richiede circa 50 minuti di tempo di inferenza. A 400 tok/s, la stessa sessione richiede 12 minuti. Sono 38 minuti risparmiati, la differenza tra rimanere nel flow e passare a Slack mentre aspetti.

Il fattore nascosto: consistenza sotto carico

I benchmark mostrano le prestazioni di picco. I sistemi di produzione sperimentano carichi variabili.

Cosa chiedere ai provider:

• Latenza P50 vs P99: Il 99° percentile mostra le prestazioni nel caso peggiore. Se P99 è 5x più alto di P50, avrai utenti frustrati.
• Rate limit: Puoi effettivamente raggiungere le velocità che pubblicizzano, o i limiti ti rallentano prima?
• Degradazione delle prestazioni su scala: Il throughput regge quando invii 100 richieste/secondo?

Artificial Analysis pubblica benchmark indipendenti che catturano questa varianza. La loro metodologia testa i provider continuamente, mostrando non solo le prestazioni di picco ma la consistenza nel tempo.

Come fare benchmark tu stesso

Non fidarti dei numeri del marketing. Esegui i tuoi benchmark con i tuoi workload reali.

Testa con le tue lunghezze di prompt reali - le prestazioni variano significativamente tra 1K e 100K token di input, e la maggior parte dei benchmark marketing usa prompt corti che abbelliscono i risultati. Testa anche le tue lunghezze di output previste, poiché completamenti brevi e generazione di contenuti lunghi hanno profili di prestazione diversi. Se stai eseguendo richieste concorrenti, fai benchmark di quel pattern specificamente piuttosto che testare singole richieste in isolamento. Cosa più importante, testa durante le ore di punta. I benchmark fuori picco mostrano prestazioni nel caso migliore che raramente vedrai in produzione. Artificial Analysis pubblica confronti indipendenti tra provider se vuoi una baseline neutrale, ma niente sostituisce la strumentazione dei tempi nel tuo ambiente di produzione.

Quale metrica conta di più?

Il tuo workload determina la risposta. Se gli utenti stanno guardando lo schermo, prioritizza il TTFT - un inizio di risposta sotto il secondo sembra istantaneo. Se gli agenti stanno aspettando risposte, prioritizza il throughput - token più veloci significano completamento del task più veloce. Se stai elaborando su scala, prioritizza la latenza end-to-end e la consistenza - il tempo totale di completamento del lavoro e SLA prevedibili contano più della velocità di picco.

La maggior parte delle applicazioni di produzione ha bisogno di prestazioni accettabili su tutte e tre. Throughput fulmineo con 3 secondi di TTFT frustrerà gli utenti interattivi. TTFT istantaneo con 50 tok/s di throughput creerà un collo di bottiglia nei workflow agentici. I tradeoff sono reali.

Testalo tu stesso: benchmark.infercom.ai ti permette di eseguire i tuoi prompt reali contro la nostra infrastruttura. Oppure vedi i nostri benchmark pubblicati per confronti standardizzati.

Perché lo chiamiamo "Ultraspeed"

Ecco perché chiamiamo il nostro MiniMax M2.7 Ultraspeed:

1. Architettura dataflow SambaNova. Hardware di inferenza costruito appositamente, non GPU riconvertite. L'RDU elimina il collo di bottiglia della memoria che limita il throughput delle GPU. Come il dataflow offre velocità
2. 428 token al secondo. Throughput misurato che rende pratici i workflow agentici. A questa velocità, un task di coding da 50 passaggi che richiederebbe un'ora su infrastruttura GPU standard si completa in minuti.
3. 690ms TTFT su 10K token di input, sotto 150ms su prompt corti. Misurato dalla Germania alla nostra infrastruttura di Monaco - gli utenti EU ottengono il vantaggio di latenza senza la penalità di rete di 100ms+ verso i datacenter US.

Ultraspeed è infrastruttura condivisa - benefici dell'architettura e dell'hosting EU, ma il tempo in coda varia con il carico della piattaforma come qualsiasi servizio condiviso.

Prova MiniMax M2.7 Ultraspeed

Il punto fondamentale

Le affermazioni sulla velocità senza contesto sono prive di significato. Chiedi sempre: quale metrica, quale lunghezza di input, quale baseline? "API LLM più veloce" potrebbe significare TTFT più veloce su prompt corti, throughput più alto su un modello specifico, o latenza end-to-end più bassa in condizioni ideali. Senza quel contesto, l'affermazione non ti dice nulla.

Il tuo workload determina quale metrica conta. Le applicazioni interattive hanno bisogno di TTFT veloce. I workflow agentici hanno bisogno di alto throughput. L'elaborazione batch ha bisogno di latenza end-to-end consistente. La maggior parte dei sistemi di 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 durante l'orario lavorativo non è realmente un provider da 400 tok/s per il tuo workload di produzione.

La latenza di rete è fisica, non software. Per gli utenti EU, un provider di inferenza a Monaco sarà sempre più veloce di uno in Virginia - nessuna ottimizzazione può superare la velocità della luce. La residenza dei dati non riguarda solo la compliance; è un vantaggio prestazionale.

Fonti

• LLM API Latency Benchmarks 2026 - Kunal Ganglani
• Time to First Token (TTFT) - IBM
• Tokens Per Second: LLM Speed Benchmark Guide - Morph
• SambaNova - Artificial Analysis
• Inference Speed or Throughput? With RDUs - SambaNova
• Key metrics for LLM inference - BentoML
• Cerebras Llama 3.1 405B at 969 tokens/second