---
type: "BlogPosting"
title: "tok/s non è tok/s — leggere bene i benchmark LLM locali"
description: "Decode vs. prefill, mean wall TPS, fedeltà dei quant: 4 trappole nei numeri di benchmark — e l'autoverifica in 5 minuti. Con misurazioni reali da 300 ricette."
resource: "https://www.contextstudios.ai/it/blog/tok-s-non-e-tok-s-leggere-bene-i-benchmark-llm-locali"
language: "it"
tags: ["Local AI", "Self-Hosting", "LLM", "Benchmark", "Hardware"]
generated:
  by: "process:contextstudios-md/1"
  at: "2026-10-05T09:19:21.220Z"
status: "stable"
---

# tok/s non è tok/s — leggere bene i benchmark LLM locali

Published: 2026-10-01
Tags: Local AI, Self-Hosting, LLM, Benchmark, Hardware

![tok/s non è tok/s — leggere bene i benchmark LLM locali](https://wary-platypus-754.convex.cloud/api/storage/7d941a54-362a-4f85-9eb7-8f97c33641c5)

«Quel modello gira a 250 token al secondo!» — quel numero si trova in quasi ogni post di benchmark della scena local AI. E quasi mai è tutta la verità. Abbiamo analizzato le 300 ricette della community nel nostro database local AI per mostrare quali numeri puoi credere, quali richiedono contesto — e come misurare pulito da solo in cinque minuti.

## Trappola 1: Decode, prefill e il «mean wall TPS»

L'errore più grande avviene in fase di lettura: i tok/s di decode (quanto veloce appare il testo mentre viene scritto) e i tok/s di prefill (quanto veloce viene elaborato il prompt) sono mondi diversi. Una ricetta su una RTX PRO 6000 ha misurato 14.842 tok/s di prefill — contro 207 tok/s di decode. Chi pubblica «2.000 tok/s» ha probabilmente preso la cifra di elaborazione del prompt, che si comporta in modo drasticamente diverso con contesti lunghi o prompt ripetuti (prefix cache!).

C'è poi il trucco del «mean wall TPS»: una ricetta riporta 251,8 tok/s di mean wall TPS su più stream. È throughput aggregato — nessun utente singolo vede mai quella velocità. In stream singolo sulla stessa hardware realisticamente si stanno su 40–60 tok/s. Entrambi i numeri sono corretti. Solo uno risponde alla tua domanda.

## Trappola 2: L'assetto del benchmark determina il risultato

Due ricette per la stessa classe 35B-A3B su due RTX 5090: 249,4 tok/s con quantizzazione NVFP4, 251,8 tok/s con AutoRound INT4. Suona identico? Il secondo numero viene da un prompt-saggio di 800 parole, il primo da query strutturate brevi. Il prompt del benchmark decide l'esito:

- Prompt strutturati brevi (tabelle, conteggi): alta accettazione del drafter, numeri artificialmente veloci
- Saggio di 800 parole: velocità reale senza il bonus del drafter
- I soliti test «count to 300»: numeri da dimostrazione che non esistono nell'uso reale

Una ricetta seria separa quindi codice, prosa e output strutturato — ciascuno con speculative decoding attivo e disattivo. Chi cita un solo numero senza dire cosa ha misurato ha di solito scelto il più bello.

## Trappola 3: Quantizzazione senza ricevuta di fedeltà

2,05 bit per peso suona come «inutilizzabile», 8,49 bit come «ovviamente meglio». La realtà è più sfumata. Una ricetta EXL3 a 2 bit (GLM-5.3-Flash su una singola DGX Spark) raggiunge 18,9 tok/s di decode con uno scostamento documentato dall'originale (metrica KLD, accordo top-1 dell'78,8%). Una ricetta EXL3 a 4 bit su due Spark decodifica a 36,1 tok/s — il doppio della velocità e misurabilmente più vicina all'originale.

La regola: a decidere non è solo il numero di bit, ma il numero di bit più la fedeltà documentata. Una ricetta senza cifra KLD/PPL è un'affermazione, non una misurazione. E: 2 bit può bastare per la chat ma rompersi misurabilmente per gli agenti di codice — per questo le ricette serie separano per caso d'uso.

## Trappola 4: Numeri del vendor vs. harness standard

I benchmark dei vendor girano spesso su scaffold proprietari. Le misurazioni della community mostrano regolarmente un divario di 15–20 punti tra scaffold del vendor e harness standard (Terminal-Bench, SWE-bench). Non significa che i vendor mentano — ma che il loro allestimento del test è diverso (più benevolo). Per un acquisto contano i numeri certificati; per un deployment reale, le ricette della community.

## L'autoverifica in 5 minuti

Come controllare una ricetta prima di adottarla:

1. **Quale numero, quale modalità?** Decode o prefill? Stream singolo o aggregato? È indicato?
2. **Quale prompt?** Saggio in prosa (realistico) o «count to 300» (mostra del drafter)?
3. **Quale quantizzazione, quale fedeltà?** bpw più KLD/PPL contro l'originale documentati?
4. **Quale software?** Versione del motore indicata? Un solo aggiornamento di vLLM può spostare il 10%.
5. **Misura da solo:** stesso prompt, stesse impostazioni, tre esecuzioni, prendi la mediana. Il tuo rig, la tua versione, il tuo numero.

## Quali numeri si possono credere?

I numeri più onesti del nostro database vengono dalle ricette che separano tutte e tre le dimensioni: casi d'uso (prosa/codice/strutturato), modalità operative (speculative decoding on/off) e correttezza (KLD contro l'originale). Quelle ricette hanno le note più lunghe e i numeri meno spettacolari. È esattamente questo il marcatore di qualità.

Tutte le misurazioni citate in questo articolo provengono dal database pubblico di ricette sulla nostra [pagina Local AI](/it/local-ai) — ogni ricetta rimanda al repository originale con metodologia e istruzioni di riproduzione.

## Domande frequenti

**Perché due ricette per lo stesso modello sulla stessa hardware differiscono così tanto?**
Perché «la stessa hardware» raramente è la stessa hardware: limite di potenza (300 W contro 600 W su una RTX 3090), lane PCIe, versione del motore, tipo di cache KV e il prompt del benchmark stesso spostano il risultato di fattori. Una ricetta seria documenta proprio questi parametri — per questo fanno parte dei nostri campi dati delle ricette.

**Lo speculative decoding è un numero truccato?**
No, ma è una modalità operativa diversa. Lo speculative decoding (per esempio con un modello draft) fornisce output più veloce a parità di qualità — ma il tasso di accettazione dipende dal prompt. Gli output strutturati ne beneficiano enormemente, la prosa libera appena. Le misurazioni serie separano i due; «un solo numero» è un segnale d'allarme.

**Cosa significano KLD e top-1 agreement per le quantizzazioni?**
La KLD (divergenza di Kullback-Leibler) misura quanto la distribuzione di output del modello quantizzato devia dall'originale — più è bassa, più il modello è fedele. Il top-1 agreement indica quanto spesso i due modelli scelgono lo stesso token (78,8% a 2 bit, oltre il 94% per i buoni pacchetti a 4 bit). Senza quel numero, una quantizzazione è un azzardo con passaggi in più.

**I valori alti di prefill mi riguardano?**
Molto — se elabori documenti lunghi o prompt di sistema ripetuti. Il prefill decide l'attesa fino al primo token. Con prompt ricorrenti entra in gioco il prefix cache: la stessa prefisso del prompt non viene ricalcolata. Per brevi sessioni di chat conta di più il decode; per RAG e workload agentici spesso è il prefill.

**Perché fidarsi delle ricette della community e non dei benchmark dei vendor?**
Perché le ricette della community sono riproducibili: repository, versione del motore, prompt, configurazione hardware — tutto aperto. I numeri dei vendor sono affermazioni di marketing con uno scaffold sconosciuto. Il nostro database di ricette collega ogni ricetta al suo originale così puoi verificarla sul tuo rig.

## Fonti

- [Local AI — Context Studios (database pubblico di ricette, 300 ricette)](https://www.contextstudios.ai/local-ai)
- [club3090 — Qwen3.6 35B-A3B NVFP4 su 1× RTX 5090 (251,8 tok/s mean wall TPS)](https://github.com/noonghunna/club-3090/blob/master/BENCHMARKS.md)
- [vcruz305 — GLM-5.3-Flash EXL3 K2 su 1× DGX Spark (documentazione fedeltà KLD)](https://huggingface.co/vcruz305/GLM-5.3-Flash-EXL3-K2)
- [MiaAI-Lab — GLM-5.3-Flash EXL3 4bpw su 2× DGX Sparks](https://github.com/MiaAI-Lab/GLM-5.3-Flash-EXL3-2x-DGX-Sparks)
- [jpezzulli — Qwen3.8-Flash-Next NVFP4 SGLang su 1× RTX PRO 6000 (prefill 14.842 tok/s)](https://www.contextstudios.ai/local-ai)
- [Regolo — DeepSeek V4 Flash vs Qwen3.8-Flash-Next vs GLM-5.3-Flash (discussa scaffold vendor)](https://regolo.ai/deepseek-v4-flash-vs-qwen3-8-flash-next-vs-glm-5-3-flash-the-real-leader-in-quality-to-price-in-2026/)


## Related

- [Sviluppo LLM](https://www.contextstudios.ai/it/sviluppo-llm.md)
- [Sviluppo AI](https://www.contextstudios.ai/it/sviluppo-ia.md)
- [Integrazione LLM](https://www.contextstudios.ai/it/integrazione-llm.md)
- [Consulenza AI](https://www.contextstudios.ai/it/consulenza-ia.md)
