«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:
- Quale numero, quale modalità? Decode o prefill? Stream singolo o aggregato? È indicato?
- Quale prompt? Saggio in prosa (realistico) o «count to 300» (mostra del drafter)?
- Quale quantizzazione, quale fedeltà? bpw più KLD/PPL contro l'originale documentati?
- Quale software? Versione del motore indicata? Un solo aggiornamento di vLLM può spostare il 10%.
- 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 — 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)
- club3090 — Qwen3.6 35B-A3B NVFP4 su 1× RTX 5090 (251,8 tok/s mean wall TPS)
- vcruz305 — GLM-5.3-Flash EXL3 K2 su 1× DGX Spark (documentazione fedeltà KLD)
- MiaAI-Lab — GLM-5.3-Flash EXL3 4bpw su 2× DGX Sparks
- jpezzulli — Qwen3.8-Flash-Next NVFP4 SGLang su 1× RTX PRO 6000 (prefill 14.842 tok/s)
- Regolo — DeepSeek V4 Flash vs Qwen3.8-Flash-Next vs GLM-5.3-Flash (discussa scaffold vendor)