Benchmark LLM: come misurare la velocità in token al secondo

Benchmark LLM: cosa misurano i token al secondo

I token al secondo in output misurano la velocità con cui un LLM fornisce i token generati dopo l'arrivo del primo token. Un modello linguistico di grandi dimensioni, o LLM, elabora il testo sotto forma di token: unità che possono corrispondere a parole, parti di parole o segni di punteggiatura. I token non equivalgono a un conteggio universale delle parole. La definizione di Cerebras chiarisce proprio questa distinzione.

Immagina di entrare in biblioteca per ritirare una serie di libri. L'attesa che la porta si apra è diversa dal ritmo con cui ti vengono consegnati i volumi, ed entrambe determinano quando potrai uscire con tutto ciò che ti serve. Una consegna rapida non cancella una lunga attesa all'ingresso.

Per un'applicazione, queste misure vanno tenute separate:

Questi intervalli seguono le definizioni delle metriche di Artificial Analysis. Il primo token di ragionamento può arrivare prima del primo token di risposta: servono quindi nomi distinti per i due tempi.

La latenza end-to-end dell'applicazione va dall'azione dell'utente a un risultato utile. Per un assistente vocale, può essere l'inizio della risposta audio; per un agente, il completamento di un'azione. Il recupero delle informazioni, l'esecuzione degli strumenti, la sintesi vocale e gli aggiornamenti dell'interfaccia possono avvenire al di fuori della richiesta al modello. Misura anche questo percorso più ampio.

Le fasi sottostanti sono il prefill, cioè l'elaborazione del prompt, e il decode, cioè la generazione del testo che segue. La guida all'inferenza degli LLM ripercorre queste operazioni nel sistema che eroga il modello.

Perché un solo dato di velocità può ingannare

Un risultato di velocità descrive un carico di lavoro su un endpoint, non una proprietà assoluta del modello. Se cambiano il lavoro da svolgere o le condizioni di erogazione, cambia anche il confronto.

Lunghezza del prompt e contesto in cache

Una chat di assistenza con una domanda breve è diversa dalla stessa chat con una lunga cronologia e documenti recuperati sulle procedure aziendali. Più input significa un lavoro diverso prima della risposta. Nella sua guida alla latenza, Groq indica la dimensione dell'input tra i fattori che influenzano il TTFT.

Annota nei risultati del test la lunghezza del prompt e lo stato della cache. La guida alla KV cache spiega lo stato di attenzione salvato durante la generazione e il rapporto tra riutilizzo dei prompt e caching. Un prompt ripetuto con cache già popolata non dovrebbe essere usato al posto di una nuova conversazione con un cliente senza dichiararlo.

Il ragionamento che precede la risposta

Un modello di ragionamento può produrre token intermedi prima di fornire la risposta. Una generazione rapida non dice quanto ragionamento svolgerà. Verifica se la velocità dichiarata include quel flusso e se il cronometro del primo token si ferma sul testo di ragionamento o su quello della risposta.

Per un assistente alle prenotazioni, l'evento utile è una risposta utilizzabile o una chiamata a uno strumento. Un indicatore di elaborazione può segnalare che la richiesta è stata ricevuta, ma non conclude la prenotazione.

Batching e richieste simultanee

Il batching raggruppa il lavoro per sfruttare meglio l'hardware. Il throughput aggregato conta l'output di più richieste; la velocità per utente descrive invece il flusso ricevuto da una singola richiesta. Cerebras osserva che il batching può aumentare il throughput introducendo però ulteriore attesa. Fonte: spiegazione del throughput di Cerebras.

Chi gestisce il servizio deve chiedersi se ogni conversazione continua a procedere quando ne arrivano altre. Misura un traffico simultaneo rappresentativo, includendo le richieste fallite e i nuovi tentativi. Un buon risultato ottenuto su un endpoint altrimenti inattivo non risponde a questa domanda.

Regione e consegna del flusso

La posizione dell'applicazione e dell'endpoint di inferenza influisce sul ritardo di rete. Nelle sue indicazioni per l'analisi della rete, Groq distingue i tempi lato server dalla latenza percepita dal client.

Effettua le misurazioni dalla regione in cui gira il backend. Se l'applicazione inoltra il flusso a un browser tramite proxy, aggiungi una misura dal browser: il buffering tra i due punti può far apparire a scatti una risposta che a monte scorre regolarmente. Correggere quel tratto del percorso può contare più di un cambio di modello.

Token al secondo: come confrontare le GPU

Una GPU, l'acceleratore che esegue l'inferenza, non ha un unico valore significativo di token al secondo indipendente dal modello e dal carico di lavoro. In un confronto hardware, il risultato deve essere accompagnato da modello, precisione numerica, contesto, configurazione del sistema di inferenza e carico simultaneo.

La quantizzazione riduce la precisione numerica per risparmiare memoria; i compromessi tra velocità e qualità dipendono dall'implementazione. Cerebras documenta questa distinzione nella sua spiegazione della compressione dei modelli. Per confrontare sistemi che usano modelli compressi, consulta la guida alla quantizzazione degli LLM e affianca sempre ai tempi una verifica della qualità delle risposte.

Come i fornitori dichiarano le proprie velocità

Considera le velocità pubblicate come dichiarazioni attribuite a un fornitore, riferite a un modello e a una data. Le pagine dei fornitori riportate qui sono state verificate il 24 ottobre 2026. I valori sono quelli dichiarati dai fornitori, non misurazioni eseguite per questo articolo.

Cerebras: una velocità dichiarata, con una precisazione sul deployment

Cerebras, fornitore di servizi di inferenza, riporta per OpenAI GPT-OSS 120B “~3000 tokens/s” nella tabella Developer. La stessa pagina precisa che le prestazioni variano in base al modello e alla configurazione e presenta l'accesso Developer come destinato alla valutazione, non alla produzione. Fonte: prezzi di Cerebras.

La domanda utile è se la configurazione acquistabile riesca a gestire il tuo carico di lavoro con la reattività e la capacità necessarie. La sola tabella non basta a rispondere.

Token al secondo su Groq: guarda la riga del modello

Groq, fornitore di servizi di inferenza, riporta “500” per OpenAI GPT-OSS 120B nella colonna “SPEED (T/SEC)” della tabella dei modelli supportati. È il valore pubblicato da Groq per quella riga. Fonte: modelli supportati da Groq.

Queste tabelle non permettono di stabilire un rapporto tra le velocità dei fornitori all'interno di un'applicazione. Per sostenerlo servono ancora prompt, impostazioni di ragionamento, criteri di conteggio dei token, carico e intervalli di misurazione equivalenti.

Per valutare il rapporto tra velocità e costi, confronta il prezzo di un'attività completata con successo e la capacità necessaria usando la guida ai prezzi di Cerebras e la guida ai prezzi di Groq.

Dove trovare misurazioni indipendenti

Artificial Analysis, servizio indipendente di benchmarking, offre un utile punto di partenza per confrontare modelli e fornitori di inferenza. Apri la sua classifica dei fornitori, poi esamina l'endpoint e il carico di lavoro a cui si riferisce il risultato.

La sua metodologia per i benchmark delle prestazioni prevede attualmente:

• Un carico di lavoro predefinito di circa 10,000 token di input e almeno 1,500 token di risposta.
• Risultati espressi come mediana delle ultime 72 ore per i carichi di lavoro abituali.
• Un server di test principale nella zona us-central1-a di Google Cloud.
• Conteggi delle prestazioni normalizzati con o200k_base, anziché con il tokenizer nativo di ciascun modello.

Questo offre un riferimento comune, non una promessa sulle prestazioni della tua applicazione. Prima di confrontare i risultati, controlla dimensione del prompt, endpoint, modalità di ragionamento e data. Prompt più lunghi possono modificare sia l'attesa del primo token sia la velocità di output.

Per i modelli che nascondono parte dei token di ragionamento, Artificial Analysis calcola la velocità di output sull'ultimo 80% dei blocchi di risposta. Il semplice script che segue non riproduce né quel metodo né l'intero carico di lavoro del benchmark. Misura il flusso di testo osservato dal tuo client.

Misura il flusso della tua applicazione

Misura dal client che riceve la risposta e conta i token di testo, non gli eventi dello stream. Un evento può non contenere testo oppure contenerne un blocco: contando gli eventi si ottengono blocchi al secondo.

Il seguente esempio Python usa l'API di streaming di Groq e tiktoken, un tokenizer di testo. Riporta il ritardo del primo blocco di testo, il tempo dalla richiesta all'ultimo testo, il tempo di completamento del flusso e una stima dei token di output normalizzati al secondo.

Installa le dipendenze:

python3 -m pip install groq tiktoken

Imposta GROQ_API_KEY nell'ambiente. Assegna a GROQ_MODEL un modello testuale senza ragionamento disponibile per il tuo account nell'elenco dei modelli supportati da Groq e inserisci in prompt.txt un prompt rappresentativo dell'applicazione. Salva il codice come measure_stream.py, quindi esegui python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

L'SDK di Groq permette di disattivare i tentativi automatici. Questo esempio li disattiva per evitare che l'attesa di un nuovo tentativo rientri, senza essere segnalata, in un campione altrimenti riuscito; una richiesta fallita va registrata come tale.

Il calcolo della velocità esclude il primo blocco di testo sia dal conteggio dei token sia dall'intervallo di ricezione. Segue la formula basata sui blocchi descritta nelle definizioni di Artificial Analysis. Inoltre, quando individua l'arrivo dell'ultimo testo, ignora i metadati finali.

Usa questo esempio per il testo semplice. Un flusso di ragionamento, gli argomenti di una chiamata a uno strumento o l'audio richiedono una gestione specifica dei rispettivi tipi di evento e una definizione del primo output utile. Per i confronti, mantieni invariati prompt e impostazioni, registra la lunghezza dell'output e ripeti le misurazioni dalla regione del tuo deployment con un carico rappresentativo. Conserva sia i risultati tipici sia quelli lenti; non trasformare il campione più veloce in una garanzia.

Cosa possono dirti calcolatori e simulatori

Uno strumento di pianificazione può illustrare un'ipotesi sui tempi, ma non può rilevare il ritardo del tuo endpoint.

Simulare i token al secondo

Usa un simulatore per discutere se un'interfaccia chat debba mostrare il testo man mano che arriva o aspettare un oggetto completo. Poi verifica quella scelta con un flusso osservato. Una velocità simulata costante non permette di stabilire se la risposta reale si interrompa, arrivi a scatti o resti in attesa di uno strumento.

Per una risposta testuale completata, il calcolo è semplice: il tempo dalla richiesta all'ultimo testo è uguale all'attesa iniziale più l'intervallo dal primo all'ultimo testo. Lo script misura entrambi gli intervalli, invece di dedurli da una velocità pubblicizzata.

Quanti token al secondo servono davvero?

L'obiettivo utile dipende dai punti in cui l'attività resta in attesa. Definiscilo rispondendo alle domande sull'esperienza che stai costruendo.

Per chi sviluppa un assistente vocale: quanto aspetta chi chiama, dopo aver finito una frase, prima di sentire una risposta utile? La voce può partire prima che l'intera risposta sia stata scritta? Il buffer audio si svuota? Chi chiama può interrompere? Se il silenzio precede l'inizio del testo, aumentare la velocità di decode può lasciare irrisolto il problema principale.

Per chi sviluppa una chat: l'utente aspetta la prima frase utile, la spiegazione completa o un risultato strutturato valido? L'interfaccia può mostrare un output parziale? Una risposta di assistenza e un report esportabile hanno eventi di completamento diversi. Misura l'evento di cui ha bisogno la tua interfaccia.

Per chi gestisce un agente: quanta parte dell'attività è generazione del modello e quanta è esecuzione degli strumenti? Una risposta più veloce mantiene corretti gli argomenti degli strumenti e porta comunque a termine l'attività con successo? Il passaggio successivo aspetta tutto l'output? Migliorare l'intervallo sbagliato può lasciare quasi invariato il tempo di completamento del workflow.

Per chi sceglie un fornitore: il deployment proposto riesce a mantenere l'esperienza necessaria con il tuo traffico, dalla tua regione e con i tuoi prompt? Il risultato dichiarato è tipico di quel deployment? Cosa succede quando le richieste falliscono o la capacità è occupata?

Intervieni quando le tracce mostrano utenti in attesa della generazione o della prima risposta utile. Rimanda il cambio di fornitore finché non hai isolato il ritardo dominante. Per un processo in background che rispetta già la propria scadenza, un dato di velocità più alto cambia poco, a meno che il throughput o il costo per attività riuscita non spostino la decisione.

Dove si esagera con la velocità degli LLM?

L'affermazione più esagerata è che il tasso di output più alto identifichi l'endpoint migliore per un'applicazione. La velocità non garantisce qualità della risposta, validità dell'output o uso corretto degli strumenti.

Il limite contro cui si scontra ogni endpoint veloce è l'applicazione che lo circonda. Un testo generato più rapidamente non rimedia a una chiamata lenta al database, a un percorso di ragionamento inutilmente lungo o a una risposta che non supera la validazione. Allo stesso modo, un ottimo tempo al primo token può nascondere un flusso che si blocca prima di fornire qualcosa di utile all'utente.

Continua a valutare la velocità, ma considera raggiunto il traguardo solo con un risultato corretto e utilizzabile.

Domande frequenti

Il prossimo passo nello sviluppo

Alla prossima iterazione, scegli uno scambio vocale, un prompt di chat o un'attività dell'agente che siano rappresentativi e definisci cosa rende utilizzabile il risultato. Misura quell'evento insieme al primo output e al completamento del flusso. Confronta gli endpoint candidati sulla stessa attività, esamina gli errori e ottimizza l'intervallo che tiene l'utente in attesa.

Per guide pratiche allo sviluppo di applicazioni AI utili, iscriviti alla newsletter.