Il banco di prova
Cosa ho messo sul tavolo, e perché la parte interessante non è se funziona
Un modello da 35 miliardi di parametri gira su un portatile con 8 GB di scheda video, e lo fa abbastanza in fretta da poterci lavorare. Ho verificato il numero dichiarato dal paper, l'ho confrontato con l'alternativa che usano tutti, e ho passato i giorni successivi a capire perché i vincoli sono quelli. Questo articolo mette sul tavolo la macchina, i numeri di partenza e il paradosso da cui nasce il resto cogliendo l'occasione per andare a fondo su una serie di tematiche.
Di dichiarazioni sul far girare LLM su hardware consumer ne passano parecchie, e la maggior parte si limita a un uso teorico: la prima risposta arriva dopo minuti, o la generazione del testo è troppo lenta.
Ad agosto è uscito FreeToken, un engine per modelli Mixture-of-Experts (MoE), e questa volta c'era dietro un paper che mi ha dato subito l'idea di essere interessante e con una rivendicazione abbastanza precisa da essere messa alla prova:
FreeToken supports more than 20 MoE models and real coding and tool-using agents across hardware ranging from an 8GB laptop GPU to a single workstation GPU. […] from a 35B model on a laptop to a 284B model on a gaming desktop.
Dall'abstract del paper
Un modello da 35 miliardi di parametri su una GPU da 8 GB. Nel paper quella configurazione non è un'ipotesi, è misurata: 39,3 token al secondo — un token è di solito un frammento di parola — su un portatile con una RTX 4060.
Io ho un portatile con una RTX 4070 e quegli stessi 8 GB: esattamente il caso che il paper dichiara di coprire.
Questa serie nasce dal verificare un progetto per poi diventare un viaggio nel capire come si riesca, con hardware consumer e piuttosto piccolo, ad ottenere prestazioni abbastanza buone da rendere un LLM da 35B un modello davvero utilizzabile.
Cosa c'è sul tavolo
Non una workstation, non una macchina affittata a ore in un data center: la scheda è una RTX 4070 in versione mobile, con 8 GB di VRAM. È la GPU che si trova in un portatile di fascia alta comprato per lavorare, non per addestrare modelli. Il resto della macchina è generoso.
- GPU
- NVIDIA GeForce RTX 4070 Laptop — 8.188 MiB
- PCIe
- gen 4, larghezza x8 — e non x16, come credevo
- CPU
- Intel Core i9-13980HX — 24 core, 32 thread
- RAM
- 32 GB installati, 30,97 GiB visti dal sistema
Quella riga sul PCIe è l'unica da segnarsi adesso: è la strada su cui i pesi viaggiano quando non sono già sulla scheda, ed è la metà larga di quella che davo per scontata leggendo le tabelle. Nel terzo articolo indagheremo come questo cambia la strategia che conviene adottare.
FreeToken è open source e pubblicato su github, ed è costruito per una famiglia specifica di modelli di cui parlerò nel prossimo articolo. I modelli provati sono Qwen3.6-35B-A3B e Qwen3.6-35B-A3B-heretic-mixed-ftw: 35 miliardi di parametri e quel A3B che fa la differenza. Tutti i numeri di questo articolo vengono dal primo, il checkpoint ufficiale, perché è quello che il paper misura.
Cosa ho trovato, prima di spiegarlo
Qualche risultato lo anticipo, e nei vari articoli andremo ad argomentarlo. Sono tre, e il terzo è quello che non mi aspettavo.
Uno — il numero regge, ma va messo un asterisco
Il numero del paper regge come ordine di grandezza, e l'asterisco vale più del numero. Sul checkpoint ufficiale, sulla mia macchina, ho misurato circa 35 token al secondo contro i 39,3 dichiarati: la stessa cosa, a un'occhiata. Ed è una velocità di scrittura — il decoding — che si verifica in trenta secondi.
L'asterisco è che un "token al secondo", da solo, non dice quasi niente, e due esperimenti ravvicinati lo dimostrano meglio di qualsiasi argomento. Sulla stessa macchina, senza toccare niente della configurazione, quel numero perde quasi un terzo solo perché la conversazione si è allungata. E cambiando come divido la memoria fra la conversazione e i pesi tenuti sulla scheda, si muove ancora di altrettanto. Sono due settaggi, ed entrambi spostano il risultato più di quanto disti dal numero del paper. Confrontare solo il decoding in tok/s senza sapere il contesto utilizzato e con che divisione della memoria sono stati presi è come confrontare due cose diverse. Un deep dive su questi esperimenti ci sarà nel terzo e nel quarto articolo, dove ci sarà lo spazio per andare a fondo.
Due — e allora? Quello che fa la differenza non è il token al secondo
C'è una domanda che va fatta prima di tutte: e allora? Far girare un MoE da 35B su una scheda piccola lo sa fare anche llama.cpp, scaricando gli esperti in RAM, e lo fa da anni. Quindi ho installato anche quello, sulla stessa macchina, con lo stesso modello e una quantizzazione della stessa taglia — 22 GB su disco da una parte e dall'altra — e ho misurato i due motori con lo stesso identico script.
Il modello gira in entrambi i casi. Ma non allo stesso prezzo.
quello che serve a un agent3′54″1′18″
Sulla velocità di scrittura il divario è un fattore 1,7: reale, non clamoroso. Sulla prima risposta è un fattore 3, e quello non è un dettaglio da benchmark.
Un agent come Claude Code — un programma che non chiede al modello di rispondere ma di lavorare: leggere file, eseguire comandi, correggersi — non fa una domanda. Consuma decine di migliaia di token di solo prompt iniziale, poi legge file, chiama tools e riscrive parte del contesto a ogni giro (tool calls). Ogni volta che la cache manca il bersaglio si ripaga l'attesa intera. Un compito da venti chiamate a tools, con le performance di llama.cpp, è un'ora e mezza contro venticinque minuti. Nessuno dei due è gratis; solo uno dei due è un flusso di lavoro.
Il metodo del confronto, e perché la configurazione di llama.cpp non l'ho scelta io, sono nel terzo articolo.
Tre — la sorpresa, che non era un numero
Che quei 29 secondi si paghino una volta sola, e che dai turni successivi la risposta parta in pochi secondi, era prevedibile: le prefix cache ci sono in tutti i motori, senza sarebbero tutti inutilizzabili. Non è lì la notizia.
Quello che non mi aspettavo è che a reggere fosse un modello fatto così. Di linear attention avevo letto, non ne avevo mai visto uno all'opera — e tanto meno dentro un agent, dove il contesto si riscrive in continuazione ed è il caso peggiore. Da qualche parte pensavo di pagarla. Invece tramite uno stratagemma hanno bypassato il problema con il risultato che la memoria che serve a tenere in piedi la conversazione è un quarto di quella che servirebbe se questo modello fosse costruito con una attention standard: è ciò che rende possibile un contesto lungo su una scheda da 8 GB, ed è anche la ragione per cui il tetto sul contesto sta dove sta. A questo dedicherò un articolo intero.
Trentacinque miliardi di cosa, esattamente
Cosa sono i parametri di un modello
Un LLM è un modello autoregressivo di deep learning, e possiamo vederlo come composto da due componenti:
- L'architettura
- Una serie molto grande (quei 35B) di numeri tipicamente in formato BF16
Quei numeri si chiamano parametri — e quelli fra loro che moltiplicano qualcosa, che sono la grande maggioranza, si chiamano pesi. Sono il risultato dell'addestramento: mesi di calcolo in cui il modello ha letto testo e aggiustato progressivamente ogni numero, milioni di volte, finché l'insieme ha cominciato a produrre testo sensato. L'addestramento è la fase in cui i numeri vengono decisi. È costosissima, la fanno in pochi, e non è la fase che affronterò qui.
Quello che vedremo è la fase dopo: l'inferenza. I parametri sono già decisi e non cambiano più. Far girare il modello significa prendere il vostro testo, trasformarlo in numeri anch'esso, e farlo passare attraverso il modello tramite una lunga sequenza di moltiplicazioni fino a ottenere in fondo una previsione: quale pezzo di testo viene dopo. Quel pezzo si chiama token — di solito una parola, o un frammento di parola — ed è l'unità in cui si misura tutto il resto di questa serie: la lunghezza di una conversazione, la velocità di scrittura, il costo della memoria. Poi si ricomincia, con il token appena prodotto attaccato in coda.
Da questo discende una cosa sola, ed è il filo di tutta la serie.
Per moltiplicare un numero, il processore deve prima averlo sotto mano.
I pesi non sono istruzioni da eseguire, sono materiale da attraversare. Ogni singolo token prodotto richiede che una certa quantità di quei numeri arrivi fisicamente al chip al fine di fare il calcolo.
Ecco perché una scheda da 8 GB è un vincolo così pesante, e perché è un vincolo di memoria prima che di potenza. Non è che la GPU sia troppo lenta per il modello: è che il modello non ci sta nel posto in cui la GPU sa leggere in fretta. La domanda giusta non è "quanto calcola?", è "dove sono i numeri, e quanto ci vuole a portarli dove le operazioni avvengono?".
Tutta questa serie, da qui in avanti, è una variazione su quella domanda.
Il paradosso da cui parte tutto
Mettiamo in fila i due fatti.
35 miliardi di parametri, nella forma in cui vengono normalmente distribuiti, occupano circa 70 GB. La memoria della scheda è 8 GB.
Il modello gira. Risponde, ragiona, scrive codice. Su questa macchina, adesso, mentre scrivo.
Non c'è nessun trucco di compressione miracolosa (o meglio non solo), e non è che il modello venga "caricato a pezzi" pagando ogni volta un'attesa insopportabile. Ma non è nemmeno che ci stia: i pesi restano nella memoria di sistema, e vengono portati sul chip quando servono. Si chiama offloading, e non ha niente di speciale — è quello che permette a qualunque modello troppo grande di girare comunque, anche a uno tradizionale.
Quello che l'offloading fa pagare è il trasporto: quanti byte devono attraversare il collegamento fra le due memorie per ogni token prodotto. Ed è lì che questo modello è diverso, perché quasi tutti quei 70 gigabyte non servono contemporaneamente. È una proprietà del modo in cui è costruito (Mixture-of-Experts), non un'astuzia del motore che lo esegue, o meglio possiamo dire che questo motore sfrutta in modo molto efficace ed efficiente questa caratteristica. Un modello tradizionale della stessa taglia, sulla stessa macchina, girerebbe anche lui: e farebbe meno di un token al secondo.
Quindi la domanda non è come ci stia, ma perché ci stia a una velocità che serve a qualcosa — e cosa si paga in cambio. È il prossimo articolo. Da lì in avanti la serie segue una domanda per volta:
| 2 — Come ci può stare | non ci sta, e non gli serve: i pesi arrivano dalla memoria di sistema un pezzo per volta. Cos'è un Mixture-of-Experts, e perché è quello che rende l'offloading utilizzabile invece che soltanto possibile |
| 3 — Dove si perde il tempo | gira, ma la velocità cambia moltissimo. I motori a confronto, e un fatto controintuitivo: la CPU può battere la GPU perché il paragone è fra due bande di memoria, non fra due potenze di calcolo |
| 4 — Cosa occupa lo spazio che resta | più la conversazione si allunga, più rallenta. Cosa cresce, e perché si chiama KV cache |
| 5 — Il tetto | mi sono fermato a un numero preciso di token di contesto. Ecco il conto che lo spiega, e che torna al byte |
| 6 — Quello che manca | Claude Code funziona, ma non naviga. Staccare l'endpoint stacca anche i tools, e quasi nessuno se lo aspetta |
| 7 — Il verdetto | cosa basta e cosa no, misurato in tempo su compiti veri invece che in token al secondo |
Ognuno con le sue prove sul campo, per restare con i piedi — o meglio con i numeri — per terra.
Da qui in avanti: l'aritmetica e i comandi
[ ] La misura — da dove vengono i settanta gigabyte e la quantizzazione
Un parametro è un numero, e un numero su un computer occupa uno spazio deciso dal formato in cui lo si scrive. Il formato standard con cui i modelli vengono distribuiti si chiama BF16 e usa due byte per numero: sedici bit, di cui uno per il segno, otto per l'esponente, sette per la mantissa. Poca precisione sulle cifre, molta libertà sull'ordine di grandezza che per l'addestramento è il compromesso giusto.
Da qui il conto è una moltiplicazione:
35.000.000.000 parametri × 2 byte = 70.000.000.000 byte ≈ 70 GB
E il verso opposto, che è quello che conta quando si guarda una GPU:
8 GB di VRAM ÷ 2 byte per parametro = 4 miliardi di parametri
Quattro miliardi su trentacinque. Meno di un ottavo — e nemmeno quello, perché la memoria della scheda non è tutta disponibile: una parte serve al sistema, e un'altra parte servirà a tenere traccia della conversazione (kv-cache), che è un costo di cui parleremo e che non è fisso.
Questa aritmetica è il motivo per cui esiste la quantizzazione: riscrivere gli stessi numeri in un formato più piccolo, 4 bit invece di 16, accettando di perdere un po' di precisione. Il modello che uso è quantizzato, e nel formato in cui l'ho scaricato, occupa circa 22 GB invece di 70. Meglio. Ma la scheda ne ha sempre 8, quindi il problema non è risolto: è solo diventato meno grande. Per ora prendiamolo come un dato di fatto: ci torneremo.
[ ] Taratura — guardate la vostra scheda
Se avete una GPU NVIDIA e i driver installati, questo comando dice quanta memoria avete davvero e come è collegata la scheda al resto del computer:
nvidia-smi --query-gpu=name,memory.total,pcie.link.gen.current,pcie.link.width.current \ --format=csv
Due righe di output. La prima cifra è il numero da confrontare con l'aritmetica del box qui sopra.
La seconda coppia — generazione e larghezza del collegamento PCIe — sembra un dettaglio da manuale e invece è uno dei protagonisti di questa serie: è la strada su cui i pesi viaggiano quando non sono già sulla scheda, e la sua larghezza decide quanto costa andarli a prendere. Segnatevela. Nel terzo articolo scoprirete che sulla mia macchina quel numero era la metà di quello che davo per scontato, e che questo cambia quale strategia conviene adottare.