Contents — find the section you need

Change parameters and verify

Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.

Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.

The experiment controls are in English.

Open experiment panel in a new tab

Download reproduction source

Il solo numero di token al secondo non è sufficiente a spiegare l'attesa dopo l'invio di una richiesta. È necessario misurare separatamente il contenuto della prima risposta, la velocità di generazione, il tempo di completamento e la memoria. Questo articolo fornisce una procedura di misurazione e un client; non sono stati eseguiti benchmark su modelli reali né classifiche hardware.

Definizione dei limiti temporali

Diagram 1 · Use the button to switch views
Limiti temporali per richiesta, elaborazione, prima risposta e completamento.

TTFT indica normalmente il tempo di attesa per il primo token, ma un frammento HTTP non corrisponde necessariamente a un singolo token. Questo script riporta TTFC, ovvero il tempo di attesa per il primo frammento response non vuoto. Registra separatamente il contenuto della prima risposta elaborata al momento della restituzione. Questa metrica del client include accodamento, caricamento, elaborazione del prompt e trasporto.

La velocità di generazione utilizza invece il conteggio dei token generati dal server e la durata della generazione. Le durate Ollama sono espresse in nanosecondi; le definizioni dell'API Generate sono state verificate il 07/09/2026.

\text{generation rate [token/s]}=\frac{\text{eval\_count}}{\text{eval\_duration [ns]}}\times10^9

Questo non rappresenta il throughput dell'intera richiesta. L'utilizzo di tokenizzatori diversi implica inoltre che il solo numero di token non sia sufficiente per un confronto equo del volume o della qualità delle risposte in giapponese.

Correggere le condizioni

Registrare il digest del modello, la quantizzazione, la versione di Ollama, CPU/GPU, RAM/VRAM, i limiti di potenza, la concorrenza e il prompt. Conservare i conteggi restituiti perché un testo identico può essere tokenizzato in modo diverso. Separare la prima richiesta con un modello scaricato dalle successive richieste con modello residente.

I prompt ripetuti possono utilizzare le cache. Trattare separatamente i test con modello residente/stesso prompt e con modello residente/nuovo input. Registrare l'ordine di esecuzione perché le condizioni termiche e le operazioni in background possono falsare i confronti.

Leggere lo stream

Posizionare llm_benchmark.py accanto a prompt.txt contenente il testo di confronto. Utilizza solo la libreria standard di Python. Sostituisci YOUR_MODEL con un modello installato:

python3 llm_benchmark.py --model YOUR_MODEL --prompt-file prompt.txt --runs 5 > runs.jsonl

L'endpoint predefinito è 127.0.0.1:11434/api/generate. Le richieste utilizzano temperature=0, seed=42, num_predict=128, num_ctx=4096 e keep_alive=5m. Queste sono impostazioni sperimentali e non garantiscono determinismo o idoneità per ogni modello. Verifica il conteggio degli output e done_reason per eventuali terminazioni anticipate o comportamenti di elaborazione diversi.

Validazione degli output e degli errori

Ogni riga JSON include ttfc_s, first_thinking_s, client_total_s, generation_tokens_s e conteggi/durate dei server. L'assenza di frammenti di risposta produce un TTFC nullo; una durata di generazione pari a zero produce un throughput nullo. I flussi interrotti e gli errori API hanno stato=error, mai successi in zero secondi.

L'analisi, i campi di temporizzazione e la gestione degli errori sono stati testati con risposte di streaming sintetiche, non con la generazione effettiva di Ollama. Inizia con cinque prove per convalidare la procedura, quindi aumenta le ripetizioni con regole di riscaldamento esplicite. Riporta il numero di successi, la mediana e l'intervallo; non presentare un p95 su un piccolo campione come preciso.

Misura la memoria separatamente

Lo script non misura la memoria. L'API running-model espone informazioni sulla residenza, inclusa la dimensione della VRAM, ma non l'utilizzo dell'intero sistema o i picchi transitori. Campiona le metriche del sistema operativo/GPU in modo coerente durante l'inattività e la generazione, specificando l'intervallo di osservazione.

La RAM di processo, la cache di pagine e le allocazioni GPU sono quantità diverse; sommarle può generare un doppio conteggio. Verifica i limiti, in particolare sui sistemi con memoria unificata. Una modifica del posizionamento, come l'elaborazione parziale della CPU, non dovrebbe essere descritta semplicemente come una differenza nelle capacità del modello.

Crea una tabella di confronto utile

Includi modello/quantizzazione, token di input/output, condizioni di residenza/cache, successi, TTFC mediano, velocità di generazione mediana, tempo totale e metrica della memoria/intervallo di campionamento. Valuta separatamente la correttezza delle risposte. Per il consumo energetico, collega lo stesso carico di lavoro ai Wh utilizzando la misurazione della potenza del server.

What to read next

Compare generation speed with energy per completed workload.Misurare il consumo energetico del server domestico: inattivo, inferenza e archiviazione.Review the backgroundIntroduzione all'apprendimento automatico: modelli generativiExplore another aspect of this fieldIntroduzione al rilevamento di oggetti e alla segmentazione semantica: leggere "cosa si trova dove" in un'immagine.