The Pulse
Edge0 serve un MoE da 35B a 20 token al secondo in 3 GiB
I ricercatori dietro Edge0 descrivono un motore di inferenza che esegue un modello mixture-of-experts da 35 miliardi di parametri, archiviato su SSD, a 20,4 token al secondo. Il sistema usa 2,9 GiB di memoria attiva di picco su una macchina
AI.info Team ·
Un modello linguistico da 35 miliardi di parametri raggiunge 20,4 token al secondo usando 2,9 GiB di memoria attiva di picco in un nuovo sistema chiamato Edge0, secondo un articolo pubblicato il 16 settembre. Il risultato è ottenuto archiviando la maggior parte dei pesi del modello su SSD, invece di mantenerli nella memoria di sistema.
Il dato va precisato: Edge0 non riduce il modello a 3 GiB. Il suo checkpoint a 4 bit occupa 19,5 GB su disco, mentre la misurazione della memoria attiva riguarda la porzione necessaria durante l’inferenza con un contesto breve. I ricercatori hanno testato la versione da 35B su un Mac mini con chip M4 Pro e 24 GB di memoria unificata.
Il lavoro è descritto in «L’altra metà del muro della memoria: eseguire MoE da 35B da SSD con una previsione del routing addestrata» di Yu Lin, Yiming Wang, Runyuan Cai, Hanze Liu e Xiaodong Zeng. Gli autori hanno inoltre rilasciato il framework, i checkpoint del modello, gli adapter e i componenti di routing nell’ambito del progetto Edge0.
Perché il trasferimento su SSD di solito rallenta l’inferenza MoE
I modelli mixture-of-experts attivano solo una parte dei propri parametri per ogni token, ma l’intero insieme dei pesi degli esperti deve comunque essere archiviato da qualche parte. Il modello da 35B descritto nell’articolo attiva circa 3 miliardi di parametri per token, ma il suo checkpoint a 4 bit contiene 19,5 GB di pesi. La sparsità riduce il calcolo, ma non elimina il requisito di archiviazione.
Edge0 conserva i pesi degli esperti in file mappati in memoria e li carica dall’unità di archiviazione quando servono. Un sistema convenzionale di trasferimento deve attendere l’output di un livello prima di sapere quali esperti userà il livello successivo, inserendo così le letture dall’unità di archiviazione direttamente nel percorso di decodifica. Questa dipendenza può trasformare la generazione di ogni token in una sequenza di attese per il disco.
Edge0 riduce il ritardo con un prerouter addestrato. Ogni testa di routing prevede con un token di anticipo la selezione degli esperti del livello successivo, consentendo al sistema di iniziare a caricare il nuovo insieme di esperti mentre il token corrente è ancora in elaborazione. La previsione diventa poi la decisione di routing stessa, perciò gli esperti caricati in anticipo coincidono con quelli usati per il calcolo.
La versione da 35B usa 256 esperti distribuiti su 40 livelli
La versione da 35B rilasciata si basa su Qwen3.6-35B-A3B e usa 40 livelli con 256 esperti per livello, oltre a un esperto condiviso. Edge0 instrada ogni token verso quattro esperti, usa la quantizzazione affine int4 con gruppi da 64 e fornisce 33 teste di prerouting. Il progetto addestra anche un adapter LoRA di recupero non fuso, per recuperare la qualità persa a causa della quantizzazione e della sostituzione del routing.
L’adapter rimane separato dal modello di base quantizzato. Secondo l’articolo, fondere l’adapter nei pesi int4 e quantizzare di nuovo annulla gran parte del suo effetto; perciò Edge0 esegue l’adapter come ramo parallelo durante l’inferenza. Il modello, l’adapter e i pesi del prerouter sono inclusi nel checkpoint rilasciato.
Secondo le misurazioni riportate nell’articolo, la velocità di decodifica della versione da 35B è di 20,4 token al secondo e la memoria attiva di picco è di 2,9 GiB. Il prefill raggiunge 113 token al secondo a freddo e 140 token al secondo quando i dati pertinenti sono già nella cache delle pagine. Un confronto con gli stessi pesi a 4 bit interamente residenti in memoria raggiunge 3,9 token al secondo occupando 18,2 GiB, secondo gli autori.
La previsione migliora la velocità quando il modello non entra in memoria
L’articolo confronta anche il normale caricamento su richiesta con il pre-caricamento anticipato di un token su un MacBook da 16 GB con processore M2. La directory della versione rilasciata, da 18,4 GiB, non entra nella memoria fisica, costringendo il sistema a recuperare i dati degli esperti dall’SSD durante la generazione.
Con quattro esperti selezionati per livello, lo streaming su richiesta raggiunge 3,5 token al secondo nel test degli autori svolto nella stessa sessione. Il prerouter arriva a 6,4 token al secondo, con un aumento dell’82 per cento. Con ampiezze di routing pari a due e otto, i miglioramenti misurati sono rispettivamente dell’80 e dell’84 per cento.
Edge0 non ottiene questi risultati leggendo molti meno dati. Con l’impostazione a quattro esperti, il prerouter legge 58,9 MiB per passaggio, contro i 50,9 MiB del caricamento su richiesta. Il vantaggio deriva dall’avvio anticipato di un numero minore di letture, ma più grandi, riducendo il tempo in cui il thread principale di esecuzione attende l’unità di archiviazione.
La qualità resta simile, ma il ragionamento mostra una differenza maggiore
Nelle valutazioni OpenCompass, la versione Edge0 da 35B ottiene una media di 79,2 su 100 in cinque benchmark, contro 83,2 del modello di base Qwen3.6 originale in fp16. La differenza media è di 3,9 punti. Edge0 ottiene 90,9 su HumanEval, contro 95,1 del modello fp16; 79,8 contro 81,8 su GPQA-Diamond; e 81,0 contro 84,6 su MMLU-Pro.
La differenza maggiore si registra su AIME 2026, dove Edge0 ottiene 86,6 contro 92,7 del modello fp16. L’articolo individua nel ragionamento a catena lunga l’ambito in cui la quantizzazione int4 e la sostituzione del routing restano più evidenti. La LoRA di recupero riduce la perdita di qualità negli altri test, ma non la elimina.
Edge0 include anche una versione da 8B basata su un modello ibrido Ling 3.0. Nelle prove degli autori su Mac mini, questa versione raggiunge 28 token al secondo con 1,5 GiB di memoria attiva di picco; il risultato della versione da 35B è però la dimostrazione più significativa, perché il suo checkpoint è molto più grande della memoria disponibile.
Apple Silicon è il limite attuale
Il repository open source del progetto afferma che l’implementazione attuale usa il framework MLX di Apple e funziona sui Mac Apple Silicon dalle generazioni M1 a M4. L’architettura del repository prevede il supporto a CUDA, ma questo non è implementato nel backend rilasciato; i risultati riportati, quindi, non dimostrano le prestazioni su GPU Nvidia né sui normali sistemi Windows e Linux.
Il motore gestisce inoltre una richiesta alla volta, nell’ordine FIFO. L’articolo afferma che l’elaborazione in batch e la gestione simultanea delle richieste non rientrano nella valutazione attuale, perché modificano l’insieme di esperti attivi in memoria. I contesti lunghi richiedono ulteriore memoria per la cache KV, quindi il dato di 2,9 GiB non è un requisito fisso per ogni carico di lavoro.
Il contributo di Edge0 è dunque più circoscritto rispetto a un modello da 35B che entri letteralmente in 3 GiB. Dimostra che una macchina consumer può eseguire in streaming da un’unità di archiviazione locale un modello sparso molto più grande, mantenendo bassa la memoria attiva, a condizione che il sistema riesca a prevedere con sufficiente precisione il successivo insieme di esperti e a sovrapporre l’attività di archiviazione al calcolo. Il checkpoint rilasciato da 35B resta un file da 19,5 GB; i 2,9 GiB misurati sono la memoria necessaria per eseguirlo.