In una cucina di ristorante il cuoco lavora al bancone, che è piccolo, e gli ingredienti stanno in dispensa, che è grande e lontana. Quando una ricetta chiede qualcosa che sul bancone non c’è, le strade sono due: mandare qualcuno a prenderlo, sperando che serva anche per il piatto dopo, oppure far preparare quel pezzo direttamente in dispensa da un secondo cuoco, più lento ma già sul posto. Nessuna è sempre giusta. Dipende da quanto è lungo il corridoio e da quanto è svelto il cuoco della dispensa, e ogni ristorante ha il suo corridoio.
È, tradotto in hardware, il problema da cui parte FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution, depositato su arXiv il 17 agosto 2026 (2608.16157) e in questi giorni fra i paper in tendenza su Papers with Code. Lo firmano undici autori, con Shuo Yang e Xiaoze Fan primi a pari merito e Chenfeng Xu e Ion Stoica a coordinare; fra gli altri ci sono Kurt Keutzer, Song Han e Matei Zaharia. La tesi è nell’abstract: una macchina personale non va trattata come una GPU piccola, ma come un’unica piattaforma di inferenza, elastica, in cui scheda video, processore, memoria e bus lavorano insieme.
Perché i MoE aprono la porta, e poi la chiudono
I modelli aperti più forti di oggi sono quasi tutti mixture-of-experts: ogni strato contiene centinaia di esperti, ma ogni token ne attraversa pochi. Il paper cita DeepSeek-V4-Flash, che su 256 esperti per strato ne accende 6, in ciascuno dei suoi 43 strati: dei 284 miliardi di parametri, a ogni token ne lavorano 13. Alla precisione usata in pratica, quella parte attiva entra nei 32 GB di una RTX 5090. Il resto no: gli esperti inattivi devono stare nella RAM del sistema e salire sulla scheda quando servono.
Che cosa sono gli esperti, come il router sceglie i pochi da accendere e perché un modello da centinaia di miliardi costa al passo come uno molto più piccolo: la mixture of experts è spiegata nel capitolo sui Transformer.
llama.cpp, Ollama e KTransformers fanno già girare questi modelli su macchine personali. Secondo gli autori ne usano solo una frazione, per tre ragioni.
Il prefill distrugge la sparsità. Un token sceglie pochi esperti, ma un prompt di migliaia di token, preso tutto insieme, finisce per toccarli quasi tutti. Per DeepSeek-V4-Flash in FP4 vuol dire spostare circa 140 GB di pesi a ogni prefill: circa due secondi su una 5090 con PCIe 5.0, cinque su una 4090 o una 3090 con PCIe 4.0, dieci o più sui collegamenti a 8 linee dei portatili. Con gli agenti il danno si moltiplica, perché gli harness modificano il contesto quasi a ogni giro (tolgono i vecchi output degli strumenti, cancellano i blocchi di ragionamento) e i modelli con strati ricorrenti, come Qwen3.6, non possono riusare lo stato calcolato dopo il punto modificato. Si ricalcolano migliaia di token, e su una GPU di consumo sono decine di secondi.
In decodifica gli esperti mancanti vanno serviti, e nessuno decide come. llama.cpp fissa la posizione degli esperti al caricamento, KTransformers tiene sulla GPU un sottoinsieme «caldo» e calcola il resto sul processore. Ma il router cambia idea a ogni token, e una disposizione congelata perde gran parte del traffico. Il processore da solo non basta: due canali di DDR5 danno 80–90 GB/s, contro 1–1,8 TB/s della memoria di una 4090 o 5090.
Sul PC niente è dedicato. Browser, giochi e compositore del desktop si prendono gigabyte di memoria video quando vogliono, e il contesto dell’agente cresce giro dopo giro. Una ripartizione decisa al primo turno è sbagliata molti turni dopo.
La formula del corridoio
FreeToken tiene l’intero insieme degli esperti in RAM, come fonte di verità, e trasforma la memoria video che avanza in un’unica cache condivisa da tutti gli strati, gestita con la politica LRU: resta sulla scheda l’esperto usato di recente, esce quello dimenticato da più tempo. Funziona perché i token vicini tendono a scegliere esperti simili. Chi manca, però, manca comunque, e qui sta il contributo più netto del paper.
Degli $m$ esperti mancanti a un passo, una parte $q$ viene copiata sulla scheda attraverso il PCIe, calcolata lì e tenuta per i passi successivi; gli altri $m-q$ vengono calcolati dal processore, direttamente in RAM. Le due strade pescano dalla stessa memoria: il trasferimento consuma la banda $B_P$ del collegamento, e al processore resta quella avanzata dal sistema, $B_H – B_P$. Se $S$ è la dimensione di un esperto, i due rami impiegano
$$T_{\text{fill}}(q) \approx \frac{qS}{B_P}, \qquad T_{\text{cpu}}(m-q) \approx \frac{(m-q)S}{B_H – B_P},$$
e il passo dura quanto il più lento dei due. Pareggiarli dà la regola che il paper chiama $q^\star$:
$$q^\star \approx m \, \frac{B_P}{B_H}.$$
È il corridoio della cucina messo in numeri, e le due bande si misurano sulla macchina, non si leggono dalle schede tecniche. Quando la RAM è appena più veloce del bus, $q^\star$ tende a $m$ e il sistema diventa una normale cache che carica tutto; quando la RAM è molto più veloce, il processore si prende la maggior parte del lavoro. FreeToken arrotonda il valore, tiene sempre almeno un caricamento perché la cache continui a scaldarsi, e somma le due uscite parziali: il risultato dello strato è esattamente quello del modello, senza approssimazioni. Tutta la logica gira dentro un CUDA Graph, senza tornare al Python a ogni token.
E per il prefill, due accorgimenti da sistemista
Il primo è un doppio buffer a strato intero. Visto che il prefill tocca quasi tutti gli esperti, FreeToken non li chiede uno per uno: mentre la GPU calcola lo strato $l$, un secondo flusso carica tutti gli esperti dello strato $l+1$, senza aspettare di sapere quali serviranno.
Il secondo riguarda gli agenti. Poiché uno stato ricorrente pesa quanto la cache di centinaia di token, se ne possono salvare pochi, e conta dove. FreeToken li mette sui token speciali che delimitano ragionamento, chiamate agli strumenti e loro output: esattamente i punti in cui OpenClaw, OpenCode e SWE-agent tagliano la cronologia. Dopo una modifica si riparte dall’ultimo di questi punti rimasto intatto e si ricalcola solo la parte nuova.
Che cosa conserva la cache dei valori di attenzione, perché permette di non ricalcolare il prefisso e perché gli strati ricorrenti non si prestano allo stesso trucco: il capitolo sull’attenzione in pratica.
Il resto è gestione della casa: la cache si ridimensiona a caldo quando un’altra applicazione si prende memoria video, senza riavviare il motore, e l’avvio scrive i pesi dal disco direttamente nella loro disposizione finale.
I numeri
La valutazione usa tre modelli (Qwen3.6-35B-A3B, DeepSeek-V4-Flash, GLM-5.2), sei macchine e quattro carichi di lavoro: problemi AIME senza strumenti, un issue di SWE-bench risolto attraverso OpenCode, lo stesso issue guidato da Claude Code con i suoi subagenti, e un agente di posta e calendario su OpenClaw per tredici turni. I rivali sono llama.cpp, Ollama, KTransformers e MoE-Infinity, con gli stessi pesi.
Su una RTX 5090 FreeToken genera 77–83 token al secondo con Qwen3.6, fra 1,8 e 2,3 volte il miglior concorrente; con DeepSeek-V4-Flash ne genera 22–25, fra 1,5 e 1,9 volte. Il ritmo resta entro il 12% di quello a turno singolo anche sugli agenti, mentre KTransformers su DeepSeek-V4-Flash perde il 31% già al secondo carico. Il dato più interessante però è la coda: il turno peggiore di FreeToken non supera i 44 secondi prima del primo token, mentre ogni rivale passa i 150 secondi da qualche parte, KTransformers fino a 946. Il paper ricorda che OpenClaw abbandona una richiesta dopo 120 secondi di silenzio: oltre quella soglia la latenza smette di essere una statistica e diventa un guasto.
Le analisi separano i contributi. Il doppio buffer porta il prefill di Qwen3.6 a 6.700 token al secondo su prompt da 16.000; spegnerlo costa fra il 19% e il 26%. Rigiocando le stesse tracce di routing con la stessa capacità di cache, la LRU di FreeToken manca meno esperti sia della disposizione di KTransformers sia di quella statica di llama.cpp.
| Disposizione | Qwen3.6 | DeepSeek-V4-Flash |
|---|---|---|
| FreeToken, cache LRU | 16% | 39% |
| KTransformers | 41% | 59% |
| llama.cpp, statica | 62% | 89% |
Sulle cinque macchine di consumo, con l’agente di programmazione, il vantaggio va da 1,3 volte (3090 e 4090) a 2,1 volte (5090 desktop). Su un portatile con RTX 4060 da 8 GB, Qwen3.6 in NVFP4 gira a 39,3 token al secondo, sopra i 33 che il paper indica come velocità mediana di Codex in produzione. In cima alla scala, GLM-5.2, 753 miliardi di parametri con 40 attivi, gira su una sola RTX PRO 6000 a 14,9 token al secondo, contro i 7,3 di llama.cpp.
Quello che il paper non dice in copertina
«La macchina di casa» ha molta RAM. Il desktop che serve i 284 miliardi di DeepSeek-V4-Flash ha una 5090 da 32 GB ma anche 192 GiB di DDR5; la workstation di GLM-5.2 ha 512 GiB di RAM accanto alla scheda da 96 GB. Il portatile da 8 GB serve il modello da 35 miliardi, non gli altri. Il salto è reale, ma non vale per un PC qualunque.
Tre macchine su sei sono simulate. I sistemi con 3090, 4090 e la prima 5090 sono server a doppio socket noleggiati, limitati a 6 thread per somigliare a un PC. Gli autori mostrano che le bande risultanti sono della stessa scala di quelle del desktop e del portatile veri, che servono da controllo; resta un’emulazione.
Il perimetro è quello scelto dagli autori. Un solo issue di SWE-bench, metriche di velocità e non di qualità (che del resto non cambia, visto che il calcolo è esatto). Le medie non sono sempre a favore: sul primo token llama.cpp vince con i prompt brevi di AIME, KTransformers in un caso con Claude Code. E alcuni sistemi operativi non permettono di bloccare in memoria tutti gli esperti: lì FreeToken ripiega su un percorso tutto su processore, senza la sua carta migliore.
Perché conta adesso
La frase che riassume il lavoro è nell’introduzione: pubblicare i pesi decide chi può avere un modello, non chi può permettersi di farlo girare. Il divario di capacità fra modelli aperti e chiusi si sta chiudendo più in fretta di quello di accesso. FreeToken non cambia l’hardware, cambia come lo si usa: invece di scegliere una volta per tutte chi calcola che cosa, misura il corridoio della propria cucina e decide a ogni passo. Se le misure reggeranno fuori dai sei banchi di prova degli autori lo diranno gli altri, ora che il codice è pubblico. Ma la domanda che pone è quella giusta: il confine dell’intelligenza artificiale locale non lo traccia più soltanto la quantità di memoria sulla scheda, lo traccia il software che mette insieme le risorse che una macchina ha già.
I commenti sono riservati agli iscritti.
Accedi per commentare