Meta Prometheus: un milione di GPU non misura il lavoro utile

Un milione di GPU è un numero perfetto per una presentazione: enorme, facile da ricordare e sufficientemente astratto da non costringere nessuno a spiegare cosa ci si faccia davvero. Il problema comincia quando lo trasformiamo in una misura di produttività. Una GPU acquistata, una GPU disponibile, una GPU assegnata a un training e una GPU che sta contribuendo a un avanzamento utile non sono la stessa cosa. E più il sistema cresce, più questa differenza costa.

Il 19 ottobre 2026 Meta ha descritto l’architettura e l’operatività di Prometheus, il suo supercluster a New Albany, in Ohio. La prima fase è completata e ha contribuito all’addestramento dei modelli Muse, incluso Muse Wonder. Oggi l’azienda parla di centinaia di migliaia di GPU distribuite su più edifici; circa un milione è l’obiettivo della configurazione futura, non il numero già operativo. Il dato più interessante, però, non è l’obiettivo. Sono i meccanismi con cui Meta cerca di evitare che una quantità impressionante di hardware passi il tempo ad aspettare.

La scheda tecnica non ti dice quanto lavoro hai completato

Chi sviluppa software conosce già questa trappola in scala ridotta. Un server con molti core non garantisce un’applicazione veloce. Un database con molta RAM non garantisce query efficienti. Un cluster con molte GPU non garantisce che il training avanzi senza fermarsi. La capacità nominale descrive ciò che il sistema potrebbe eseguire in condizioni ideali; il risultato dipende da sincronizzazione, errori, checkpoint, rete, alimentazione e tempo perso a recuperare.

Meta dichiara per Muse Wonder un goodput superiore all’85% nel pre-training e al 90% nelle esecuzioni di reinforcement learning. Qui goodput indica la quota di tempo di esecuzione che produce avanzamento utile, tenendo conto delle interruzioni e del recupero. Sono misure pubblicate dall’azienda sui propri workload, non benchmark indipendenti che consentano di classificare Prometheus rispetto a qualunque altro supercluster. Il loro valore editoriale sta nella domanda che obbligano a porre: quanto del tempo acquistato in silicio diventa effettivamente progresso?

È la stessa distinzione che vale quando si parla di ottimizzazione delle risorse dal codice ai processi: prima di celebrare la capacità disponibile, bisogna capire dove viene consumata e quanta parte genera il risultato desiderato. Una metrica aggregata non spiega da sola le cause, ma almeno impedisce di scambiare l’inventario per il prodotto.

32.768 GPU attive richiedono 37.656 GPU installate: il denominatore conta

Il dettaglio più concreto dell’architettura Prometheus è il modo in cui vengono allocati i gruppi NVL72 di NVIDIA. Ogni dominio contiene 72 GPU collegate strettamente; Meta ne assegna 64 al lavoro attivo e conserva le altre otto come ricambi locali. Il motivo non è soltanto una scelta prudente: le dimensioni dei gruppi usati dal parallelismo del modello si adattano bene a potenze di due, mentre il dominio fisico è composto da 72 unità.

Nell’esempio pubblicato da Meta, un training con 32.768 GPU attive richiede 523 rack NVL72, cioè 37.656 GPU fisiche, includendo anche una piccola riserva di rack per guasti più estesi. La differenza è di 4.888 GPU. Significa circa il 13% dell’inventario installato oppure quasi il 15% rispetto alle GPU attive: due percentuali entrambe corrette, con denominatori diversi. Chiamare tutto questo “GPU sprecate” sarebbe una scorciatoia altrettanto sbagliata quanto chiamarle tutte “GPU al lavoro”.

Quelle riserve sono una scelta architetturale: sacrificano una parte della capacità immediatamente assegnabile per ridurre il costo delle interruzioni e il tempo necessario a ripartire. Un ricambio disponibile nel rack può evitare di attendere la riparazione fisica; non elimina magicamente il costo del guasto, perché può comunque essere necessario tornare a un checkpoint. Capacità di riserva e goodput non sono percentuali intercambiabili: la prima riguarda l’allocazione dell’hardware, il secondo il tempo utile del workload.

Una GPU ferma come riserva può essere una scelta efficiente. Una GPU ferma perché il sistema non riesce a ripartire è un problema. Metterle nella stessa colonna di un foglio Excel non rende il confronto più intelligente.

Più grande è il dominio di guasto, più il software deve conoscere l’hardware

Con il passaggio dai domini NVL8 agli NVL72, il gruppo di GPU strettamente interdipendenti cresce da otto a 72 unità. La maggiore banda di comunicazione porta benefici al calcolo, ma aumenta anche la superficie di guasto condivisa. Un errore non è più soltanto la storia di una scheda da sostituire: può compromettere il lavoro di un’intera porzione sincronizzata del modello.

Meta descrive due percorsi di recupero. Se il guasto resta confinato a una replica data-parallel, il sistema può isolare quella replica, far ripetere agli altri il passo interessato e reinserire la parte difettosa dopo il ripristino su host di riserva. Se invece l’errore supera quel confine, serve ripartire da un checkpoint dell’intero job. Per limitare la perdita, i checkpoint sono distribuiti e includono salvataggi differenziali e staging in memoria. Il dettaglio importante non è il nome del meccanismo, ma il suo rapporto con il blast radius: il recupero funziona quando l’architettura sa esattamente quale lavoro può salvare e quale deve rifare.

In un’applicazione web possiamo spesso riavviare un processo e lasciare che le altre istanze continuino a rispondere. Nel training sincrono, invece, un partecipante lento o guasto può costringere gli altri ad aspettare. È un problema di sistemi distribuiti prima ancora che di acceleratori. Il software deve sapere come partizionare il lavoro, rilevare il guasto, scegliere una strategia di ripartenza e mantenere coerente lo stato.

Il 99% di interruzioni in meno non è una proprietà del chip

Meta racconta che, nella fase iniziale del 2025, le interruzioni erano arrivate a quasi mille eventi al giorno per ogni 8.000 GPU. Dopo interventi su firmware, integrità dei segnali NVLink, memoria, switch, diagnostica e procedure di manutenzione, l’azienda dichiara una riduzione del 99% rispetto a quel picco. Riporta inoltre un MTBI di circa 47.000 GPU-ore durante i training Muse Wonder, poi migliorato oltre 54.000 GPU-ore grazie a ulteriori correzioni. Sono dati operativi dichiarati da Meta; il confronto temporale e il perimetro delle misure vanno tenuti distinti, non trasformati in un generico “99% più veloce”.

La parte meno fotogenica è probabilmente la più istruttiva: diagnosi dei collegamenti prima della messa in produzione, correlazione della telemetria, classificazione dei guasti, quarantena dei componenti riparati e distribuzione di bundle firmware a più di 100.000 GPU in poche ore. L’azienda riferisce di aver ridotto il P90 dell’aggiornamento di un pod da oltre sette a due ore. Non è un nuovo modello AI che ripara magicamente il data center: è ingegneria di esercizio, misurazione e responsabilità condivisa fra chi gestisce il cluster e chi produce l’hardware.

Questo principio non cambia quando scendiamo a un servizio molto più piccolo. Anche il caso del profiling di Cloudflare Workers e del codice che continuava a consumare memoria racconta una versione meno spettacolare dello stesso problema: le metriche indicano che qualcosa non torna, ma serve una diagnosi che colleghi l’effetto alla causa. Senza questa catena, la dashboard rischia di diventare un modo molto elegante per osservare gli errori senza correggerli.

La rete, l’energia e il raffreddamento entrano nell’algoritmo

Prometheus unisce edifici diversi attraverso una rete back-end dedicata. Meta descrive fabric Ethernet locali fino a 20.736 GPU e una rete di aggregazione fra edifici, chiamata Backend Aggregation, con tratte da circa due a oltre cento chilometri. È un dettaglio decisivo: la distanza fisica non scompare perché l’applicazione ragiona in tensori. I passaggi più sensibili alla latenza devono restare il più possibile dentro le repliche; le comunicazioni fra repliche vanno organizzate in modo da non trasformare ogni sincronizzazione in una lunga attesa collettiva.

Poi c’è l’elettricità. Secondo Meta, fasi di calcolo e comunicazione eseguite in sincronia possono produrre oscillazioni di carico del 30-40%. L’azienda usa un sistema di power capping, Dynamo Dimmer, che riduce gradualmente i limiti di potenza invece di fermare bruscamente il training. In parallelo impiega sistemi di accumulo e differenti soluzioni di raffreddamento a liquido. Non basta dunque chiedere quanta energia è disponibile: bisogna anche gestire quando viene richiesta, con quale velocità cambia il carico e quale degrado prestazionale è preferibile a uno stop.

Questi numeri non permettono di ricavare da soli il costo energetico totale del training o l’efficienza economica del progetto. Un’analisi esterna, come la ricostruzione del sito Prometheus di Samaritan Research, stima capacità e potenza usando immagini satellitari, dati infrastrutturali e modelli propri: è utile per contestualizzare la scala, ma non verifica indipendentemente il goodput dichiarato da Meta. Mescolare stime di capacità, potenza di picco e tempo utile in un unico numero sarebbe un altro modo per produrre precisione apparente.

La domanda che resta quando finisce la presentazione

Da questo caso emergono almeno quattro misure che sarebbe utile tenere distinte in qualsiasi sistema complesso: capacità installata, capacità assegnabile, lavoro effettivamente completato e costo del recupero. Il numero di GPU appartiene soprattutto alla prima. La ridondanza protegge la seconda. Goodput, checkpoint e diagnostica spiegano qualcosa della terza e della quarta. Nessuna, da sola, racconta tutto.

Prometheus è interessante proprio perché Meta ha reso pubblici dettagli che spostano la conversazione dall’acquisto di acceleratori alla loro gestione. Non significa che ogni dato sia stato verificato da terzi o che il traguardo del milione sia già raggiunto. Significa che il problema reale è abbastanza difficile da obbligare perfino un gigante dell’infrastruttura a parlare di firmware, isolamento dei guasti, topologie di rete, procedure di manutenzione e contabilità del tempo perso.

La lezione per chi progetta software non è comprare più GPU. È smettere di trattare la potenza nominale come sinonimo di risultato. Un sistema maturo non è quello che promette di fare più lavoro in condizioni perfette: è quello che sa spiegare quanto lavoro completa quando le condizioni perfette, inevitabilmente, finiscono.