L’ANALISI
Olmo-core 3: cosa cambia nel training aperto dei modelli MoE
Ai2 rilascia Olmo-core 3 con parallelismo MoE, checkpoint distribuiti e benchmark su B300: analisi del delta, limiti e checklist di prova.
In breve: Olmo-core 3 è un rilascio operativo: codice, configurazioni e ricette rendono riproducibile un nuovo stack per addestrare modelli mixture-of-experts su cluster distribuiti. Il vantaggio dichiarato è netto sul banco prova Ai2, ma va verificato su topologie e GPU differenti.
Il delta verificato
Il primo ottobre Ai2 ha pubblicato Olmo-core 3 e il relativo codice. La modifica centrale sostituisce il precedente schema FSDP per i MoE con una combinazione di data, expert, tensor e context parallelism.
Perché il routing conta
Nei mixture-of-experts solo una parte degli esperti elabora ogni token. Ai2 dichiara di aver portato il pool da 8 a 128 esperti, mantenendone quattro attivi per token e facendo crescere la capacità totale da 4,6 a 47 miliardi di parametri con meno del 5% di perdita di throughput.
Il benchmark su B300
In un test preliminare su otto NVIDIA B300, Ai2 riporta circa 52.000 token al secondo per GPU contro 19.400 del vecchio stack FSDP. Con MXFP8 dichiara un ulteriore aumento del 21%. Sono numeri del progetto, legati a configurazione e hardware specifici.
Scalabilità e checkpoint
Il framework include checkpoint distribuiti e configurazioni pensate per modelli oltre un trilione di parametri. Questo amplia ciò che un laboratorio può studiare, ma non rende economico il training frontier.
Che cosa è davvero aperto
Il repository espone l’implementazione usata dallo stack Olmo, con licenza e configurazioni consultabili. Una riproduzione utile richiede versioni bloccate, dataset, topologia del cluster e metriche energetiche documentate.
Condizioni e limiti
Mancano repliche indipendenti su GPU meno recenti, cluster piccoli e reti diverse. Il throughput non misura qualità, stabilità o costo totale; precisione numerica e batch possono cambiare drasticamente il confronto.
Checklist per una prova
- Bloccare commit, dipendenze CUDA e versione PyTorch.
- Registrare GPU, interconnessione, precisione e dimensione del batch.
- Riprodurre prima una configurazione ridotta con pochi esperti.
- Confrontare il nuovo stack con FSDP a parità di modello e token.
- Misurare throughput, memoria, comunicazione e tempi di checkpoint.
- Controllare bilanciamento degli esperti e token scartati.
- Ripetere la prova con e senza MXFP8.
- Separare costo di training, qualità finale e stabilità numerica.