Meta ha illustrato come collega e costruisce Prometheus, il suo cluster di data center per l’IA a New Albany, in Ohio. Al summit Open Compute Project (OCP) del 12 ottobre 2026, a San Jose, Santosh Janardhan, responsabile delle infrastrutture globali dell’azienda, ha descritto una dorsale Ethernet che unisce gli edifici e grandi strutture a tenda pensate per accelerare la costruzione, secondo il resoconto di Linda Hardesty per Fierce Network.

La scala prevista è di 1 GW una volta completato, come indica Meta nella sua descrizione tecnica di Prometheus. Janardhan ha parlato di oltre 30 strutture, decine di migliaia di GPU e circa 3–4 milioni di chilometri complessivi di fibra di rete. Il problema ingegneristico, però, non si esaurisce nel mettere insieme tanti acceleratori: bisogna farli comunicare attraverso un intero campus.

Come la rete collega gli edifici di Prometheus

Janardhan ha descritto l’approccio come un Ethernet super spine: una dorsale superiore che aggrega localmente le dorsali dei singoli edifici. Il motivo è concreto. Nella sua spiegazione, l’addestramento dell’IA avanza alla velocità della comunicazione più lenta tra due GPU. Aggiungere potenza di calcolo serve a poco se una parte del sistema deve aspettare i dati delle altre.

Dietro questa descrizione c’è il livello BAG, acronimo di backend aggregation, ossia aggregazione della rete che serve il calcolo. Meta lo descrive come il collegamento tra i fabric regionali di livello 2, o L2 — le reti di interconnessione dei sistemi — e la dorsale aziendale. BAG consente quindi di mettere in comunicazione reti distribuite tra data center e regioni.

Per i collegamenti fra livelli BAG, Meta indica un esempio di capacità compresa tra 16 e 48 petabit al secondo per coppia di regioni. È una capacità di interconnessione: il dato riguarda i collegamenti tra quelle reti, non la velocità di una singola GPU.

Percorsi alternativi e gestione dei guasti

Meta ha illustrato la rete e le strutture di Prometheus

Meta descrive due modalità di collegamento fra i livelli BAG: planare e spread, con connessioni distribuite. La differenza importante è come si organizzano i percorsi e quanto si concentra il possibile effetto di un guasto.

Le connessioni planari sono più semplici da gestire, ma concentrano maggiormente i potenziali domini di guasto: gruppi di componenti che possono risentire dello stesso problema. Le connessioni spread offrono invece più percorsi e maggiore resilienza. Per chi progetta la rete, il compromesso è tra semplicità operativa e diversificazione dei collegamenti; il numero di cavi, da solo, non racconta questa scelta.

Anche la capacità disponibile ai diversi livelli richiede un equilibrio. Meta indica un rapporto tipico di oversubscription di circa 4,5:1 tra L2 e BAG. Il termine descrive una rete in cui la capacità aggregata dei collegamenti a valle supera quella disponibile verso il livello superiore: tutte le connessioni non possono usare contemporaneamente la propria velocità massima in quella direzione. Per la distinta configurazione NSF illustrata da Meta, il rapporto effettivo è invece di 4,98:1.

La gestione dei percorsi usa eBGP, un protocollo di instradamento, con attributi sulla larghezza di banda dei collegamenti. Questi permettono a UCMP di distribuire il traffico su percorsi con capacità diverse. Sui collegamenti BAG-to-BAG, Meta impiega inoltre MACsec per la protezione del traffico a livello di collegamento.

Strutture a tenda per ridurre i tempi di costruzione

Nella presentazione raccontata da Hardesty, Janardhan ha indicato strutture a tenda lunghe almeno quanto due campi da football americano, realizzabili in mesi anziché anni e progettate per resistere a un uragano di categoria 1.

Qui la scelta costruttiva affronta un vincolo diverso da quello della rete: quanto rapidamente si può predisporre lo spazio che ospiterà l’hardware. Una dorsale collega il campus; una struttura più rapida da realizzare accorcia il lavoro necessario per costruirne gli ambienti. Sono due aspetti dello stesso progetto, con problemi molto diversi da risolvere.

L’IA entra anche nella formulazione del calcestruzzo

Janardhan ha inoltre attribuito al lavoro di Meta sul calcestruzzo assistito dall’IA una miscela con il 19% di carbonio in meno, una maturazione del 43% più rapida e nessun aumento di costo. Sono i risultati che ha dichiarato al summit, riportati da Hardesty.

Il funzionamento del processo è spiegato da Meta nel post dedicato a BOxCrete del 30 marzo 2026. Il nome sta per Bayesian Optimization for Concrete: ottimizzazione bayesiana applicata al calcestruzzo. Il sistema usa dati storici e vincoli di progetto per proporre miscele, poi incorpora i risultati delle prove di laboratorio per migliorare le proposte successive.

È un ciclo di sperimentazione, non una ricetta da adottare automaticamente in cantiere. Meta precisa che restano necessari test di laboratorio, prove sul campo, approvazione degli ingegneri e rispetto delle norme edilizie.

Un caso concreto descritto dall’azienda riguarda una soletta di un data center a Rosemount, in Minnesota. Secondo Meta, la miscela impiegata ha raggiunto la piena resistenza strutturale il 43% più rapidamente rispetto alla formulazione originale e ha ridotto di quasi il 10% il rischio di fessurazione. In questo caso il risultato riguarda il tempo per raggiungere la resistenza strutturale e il rischio di crepe, in un impianto del Minnesota.

Le piattaforme illustrate nella precedente presentazione OCP

Maggie Han e Abhinav Triguna sulle piattaforme e sulle reti di Prometheus: intervento in inglese pubblicato da Open Compute Project il 22 ottobre 2025.

Il progetto hardware aveva già ricevuto un approfondimento tecnico in un intervento di Maggie Han e Abhinav Triguna, entrambi di Meta, pubblicato da Open Compute Project il 22 ottobre 2025.

Han aveva presentato due piattaforme di accelerazione con configurazioni differenti:

  • Clemente, basata su NVIDIA GB300, con 72 GPU per rack dedicato alle GPU.
  • Catalina, basata su NVIDIA GB200, con due rack da 36 GPU ciascuno collegati tra loro nella configurazione 36×2. La presentazione descriveva anche il raffreddamento a liquido assistito ad aria.

L’architettura descritta comprendeva poi più livelli di archiviazione e calcolo. Grand Canyon era destinata all’archiviazione su dischi rigidi di grandi volumi di dati; Olympic e Yosemite V3.5 Crater Lake coprivano lo storage su memoria flash. Yosemite V3.5 Halfdome e Yosemite V4 erano le piattaforme di calcolo generalista.

Triguna aveva spiegato le due famiglie di fabric: DSF, con pianificazione del traffico e componenti disaggregati, e NSF, senza pianificazione del traffico. Per DSF aveva indicato switch basati su Broadcom Jericho 3 AI e Ramone 3; per NSF, switch Minipack 3 a 400 GbE.

Il tema operativo era sostenere più generazioni di acceleratori e gestire l’affidabilità su una scala enorme. Triguna aveva richiamato anche la necessità di strategie efficienti per i ricambi: quando cresce il numero di dispositivi, sostituire l’hardware guasto diventa parte del progetto della rete.

Hyperion: il progetto separato in Louisiana

Al summit del 12 ottobre, Janardhan ha presentato anche Hyperion, il progetto di Meta nella parrocchia di Richland, in Louisiana. Le capacità dichiarate per i due campus sono queste:

ProgettoLuogoCapacità dichiarata
PrometheusNew Albany, Ohio1 GW una volta completato, secondo Meta
HyperionParrocchia di Richland, Louisiana5 GW previsti, secondo Janardhan al summit OCP

Per Hyperion, Janardhan ha descritto un’area di circa 1.600 ettari. Nella sua valutazione, e con l’esplicita riserva di quanto fosse a sua conoscenza, si tratterebbe del più grande data center del pianeta.