TL;DR
- Il modello Mixture-of-Experts Kimi K3 pesa 1,45 TB: nessuna RAM per laptop può contenerlo. Il fork Deltafin archivia gli Expert su SSD NVMe e li trasmette in streaming a livelli (layer) nella RAM.
- Misurazioni dell'8 settembre 2026: velocità di decode a 1,00 token al secondo su un MacBook Pro M5 Max con 128 GB e quattro SSD, con un'attesa di 6,3 minuti per il primo token dopo un prompt da 512 token.
- Il concetto chiave replicabile è un Layer-Budget-Check (controllo del budget dei layer) in tre passaggi: mostra quale classe di modello può girare sul proprio hardware e quanto gli SSD aggiuntivi accelerino realmente le prestazioni.
Il problema: modelli giganti, RAM limitata
Kimi K3 di Moonshot è un modello Mixture-of-Experts (MoE) con 2,8 bilioni di parametri. I pesi degli "Expert" occupano 1,45 TB, circa undici volte in più della memoria massima che un MacBook Pro con 128 GB può fisicamente contenere.
Un normale processo di caricamento fallisce di fronte a questo limite: il modello non entra completamente nella memoria di sistema. È esattamente qui che entra in gioco il Layer-Streaming, così come implementato dal fork argonautlabsai/deltafin.
La soluzione: streaming a livelli da NVMe
Il principio è semplice: i layer "caldi" restano in RAM, il resto risiede su un massimo di quattro SSD e viene caricato su richiesta. Ogni token viene comunque deciso dallo stesso K3: nulla viene tagliato, nessun esperto viene saltato.
Tutti i 16 expert per token entrano in azione, esattamente come rilasciati da Moonshot. Un piccolo modello draft può provare ad anticipare, ma K3 verifica ognuna di queste proposte e conferma ogni singolo token. Il risultato è la massima qualità del modello con un'occupazione di RAM ridotta al minimo.
I numeri parlano in modo estremamente onesto: ogni valore deriva da un singolo cold run con un prompt esatto; log e manifesti di posizionamento (placement manifest) sono aperti e disponibili nella repository.
Le misurazioni dell'8 settembre 2026
| Metrica | Drafter spento | Drafter acceso |
|---|---|---|
| Decode-Rate, risposta da 512 token (tok/s) | 0,92 | 1,00 |
| Decode-Rate, risposta da 128 token (tok/s) | 0,93 | 1,13 |
| Prompt pubblico da 17 token, mediana su 3 (tok/s) | — | 0,96 |
| Tempo al primo token, prompt da 512 token | 6,3 min | 6,3 min |
Per fare un confronto: la repository upstream riporta 0,2901 tok/s su un M1 Max. La combinazione M5 Max con quattro SSD è quindi circa tre volte più veloce. Il prompt pubblico da 17 token, con 0,96 tok/s, si è posizionato nettamente al di sopra dello 0,68 riportato dall'upstream.
La scalabilità degli SSD: più dischi, meno linearità
I quattro SSD non sono un trucco per fare notizia, ma fisica pura e misurabile. La progressione su prompt identici è la seguente:
- 1 SSD: ≈ 52 % della velocità a quattro dischi
- 2 SSD: ≈ 73 %
- 3 SSD: ≈ 90 %
- 4 SSD: 100 % (Riferimento)
Il motivo: per ogni layer vengono eseguite 16 letture in parallelo, e il blocco più lento detta il ritmo dell'intero processo. La larghezza di banda totale è utile solo se le singole letture sono sufficientemente veloci.
Il limite reale: Prefill e Time-to-First-Token
Il Decode-Rate di ~1 tok/s è solo metà della storia. Un prompt da 512 token richiede 6,3 minuti prima di generare il primo token (Time-to-First-Token, TTFT): questo è il vero limite progettuale.
Come causa, il team ha individuato che la fase di Prefill rilegge gli expert di ogni layer per ben otto volte. È previsto un fix, ma al momento della misurazione non era ancora stato implementato. All'atto pratico, questo significa: prompt brevi e precisi offrono il miglior rapporto tra tempo di attesa e risposta.
Il Layer-Budget-Check replicabile
Questi tre passaggi funzionano con qualsiasi modello MoE e qualsiasi hardware, senza aver bisogno di consultare la repository:
- Annotare il peso totale dei parametri. Esempio K3: 1.450 GB. Il numero si trova nella Model Card o si ricava dalla dimensione totale dei file dei pesi.
- Calcolare la porzione "calda". RAM utilizzabile divisa per il peso totale: 128 / 1450 ≈ il 9 percento dei pesi rimane permanentemente in RAM. Questa è la base da cui parte lo streaming.
- Applicare la progressione degli SSD. Partendo dal riferimento di 1,00 tok/s con quattro dischi: un disco ≈ 0,52, due ≈ 0,73, tre ≈ 0,90 tok/s. In questo modo è possibile prevedere approssimativamente il rendimento di qualsiasi configurazione hardware personale.
Il controllo è particolarmente utile quando lo si confronta con le API cloud: a ~1 tok/s, una risposta da 100 token equivale a circa 100 secondi di esecuzione. Va bene per job asincroni in batch, ma decisamente no per chat interattive con più prompt al minuto.
Cosa significa questo per l'ecosistema Agent (Agent-Stack)?
- I grandi modelli MoE ammiragli diventano eseguibili in locale, senza dover incastrare 1,45 TB in una singola memoria RAM. La qualità rimane intatta sfruttando appieno tutti gli Expert.
- La latenza è la nuova valuta: chi non pianifica il TTFT e il Decode-Rate rischia un ingorgo di 6 minuti per ogni prompt.
- Il Budget-Check diventa la regola decisionale: solo i sistemi della classe da 256 GB e con configurazioni multi-disco portano l'inferenza locale fuori dalla nicchia (esattamente le configurazioni al centro dell'articolo sull'hardware Apple presente in questo blog).
Conclusione
Deltafin dimostra che il Layer-Streaming da NVMe colma davvero il divario tra i 128 GB di RAM dei laptop e le dimensioni di 1,45 TB dei modelli giganti, fornendo misurazioni pulite e riproducibili al posto di semplici promesse. La vera leva è il numero di SSD, mentre il freno principale è la fase di Prefill. Per gli sviluppatori (Builder) questo significa: eseguire localmente i flagship MoE non è più una teoria, ma le tempistiche vanno calcolate matematicamente per ogni singolo flusso di lavoro (workflow).
Domande Frequenti
Di quanti SSD ha realmente bisogno Deltafin? La misurazione di riferimento gira con quattro dischi NVMe, raggiungendo 1,00 tok/s. Un singolo disco fornisce comunque circa il 52 percento di questa velocità, due dischi il 73 percento e tre il 90 percento; il salto da uno a due dischi è quindi il più redditizio in termini di prestazioni/costo. Chi necessita di un solo processo (job) al minuto si troverà benissimo con due dischi; per generare risposte in parallelo conviene invece l'espansione massima.
Perché il primo token dopo prompt da 512 token è così lento? Il ciclo di prefill legge gli expert di ogni layer otto volte, e ciascuna di queste serie di letture deve concludersi prima che il primo token venga restituito. Tutto ciò si somma ai 6,3 minuti misurati per un prompt da 512 token. Un fix per questo comportamento è stato annunciato nella repository, ma al momento del test non era ancora implementato.
Valgono la pena 128 GB di RAM per l'inferenza locale? Con 128 GB è effettivamente possibile far girare Kimi K3 tramite Layer-Streaming, poiché la porzione calda (circa il 9 percento dei pesi totali) riesce a sostenere il funzionamento base. La classe da 256 GB spinge ovviamente il limite più in alto e mitiga le catene di prefill più piccole. La risposta onesta dipende dal caso d'uso: per prompt lunghi, il tempo fino al primo token resta il vero collo di bottiglia dell'operazione, non la RAM.
Come calcolo il Layer-Budget-Check per il mio modello? Dividi la tua RAM utilizzabile per il peso totale indicato nella descrizione del modello per scoprire la tua porzione "calda". Successivamente, moltiplica il Decode-Rate di riferimento per la progressione degli SSD (0,52 / 0,73 / 0,90 / 1,00). Il risultato è una previsione grezza ma verificabile, che può essere poi confrontata con i log aperti nella cartella k3-public-bench della repository.
Questo sostituisce un'API Cloud? Per compiti asincroni a un token al secondo è uno strumento locale validissimo, ad esempio per sintetizzare appunti, report o per le esecuzioni batch notturne. Tuttavia, per catene interattive composte da cinque prompt da 300 token ciascuno, il runtime si accumulerebbe fino a svariati minuti. L'approccio ibrido e pragmatico resta il migliore: il modello grande in locale come àncora solida, e il lavoro di bozza (draft) veloce e leggero sul cloud, come sempre.
Fonti
- https://github.com/argonautlabsai/deltafin — Fork con benchmark, log di misurazione e manifesti di posizionamento dei layer (Layer-Placement-Manifeste)
- https://github.com/gavamedia/deltafin — Motore Upstream (MIT), originale di gavamedia
- https://github.com/argonautlabsai/argodrive — Strumenti di misurazione e diagnostica (ARGODRIVE)
- https://news.ycombinator.com/ — Discussione sull'esecuzione (run) con 198 commenti