La corsa alle infrastrutture AMD Google cambia mentre Schneider Electric rende Helios implementabile

Schneider Electric e AMD hanno rilasciato il primo progetto infrastrutturale per Helios, con supporto per rack da 246 kilowatt e cluster con fino a 10,4 megawatt di carico IT. Questo cambia in modo concreto la competizione infrastrutturale amd google. AMD dispone ora di un percorso documentato che collega le specifiche degli acceleratori a un data center ad alta densità funzionante.

L'annuncio non assegna ad AMD un'improvvisa vittoria in termini di prestazioni su Google, Nvidia o un altro fornitore di piattaforme. Affronta una diversa debolezza competitiva. L'acquisto degli acceleratori è solo l'inizio quando ogni rack richiede anche distribuzione elettrica specializzata, raffreddamento a liquido, sistemi di controllo e modellazione a livello di struttura.

Google ha trascorso anni a sviluppare questi sistemi attorno alle proprie Tensor Processing Units, o TPU, processori ottimizzati per carichi di lavoro di machine learning. Anche Nvidia ha collaborato con Schneider Electric sulle infrastrutture fisiche per i propri sistemi accelerati. AMD deve convincere gli operatori che Helios può diventare un cluster operativo senza costringerli a inventare l'infrastruttura di supporto.

Ecco perché questo progetto di riferimento è importante. Trasforma Schneider Electric in qualcosa di più di un fornitore di apparecchiature. L'azienda diventa parte della risposta di AMD alle infrastrutture AI integrate verticalmente.

Il progetto Helios collega i chip a una struttura da 10,4 MW

AMD e Schneider Electric hanno definito i sistemi fisici che circondano Helios, non soltanto la disposizione dei processori all'interno del suo rack.

Le aziende hanno annunciato il progetto sviluppato congiuntamente a San Francisco il 23 luglio 2026. Secondo il progetto Helios, supporta cluster AI modulari fino a 10,4 megawatt di capacità IT.

Ogni rack ad alta densità può richiedere fino a 246 kilowatt. Un rack di questo livello utilizza diverse volte la potenza associata a molte installazioni aziendali convenzionali. Concentra inoltre quasi tutta quell'energia elettrica in calore che deve essere rimosso in modo continuo.

Helios combina acceleratori AMD Instinct MI455X, processori EPYC di sesta generazione, schede di rete Pensando Vulcano e l'ambiente software ROCm. ROCm è lo stack software aperto di AMD per programmare e gestire i suoi acceleratori.

Questi componenti di calcolo rappresentano soltanto uno strato. Il progetto di riferimento copre alimentazione della struttura, raffreddamento della struttura, spazio IT e software per il ciclo di vita. Specifica come questi livelli dovrebbero funzionare insieme in base ai requisiti di Helios.

Schneider Electric afferma che il suo sistema di raffreddamento Motivair può rimuovere fino all'84 percento del calore tramite metodi a liquido e ibridi aria-liquido. Le unità di distribuzione del refrigerante, o CDU, trasferiscono il calore tra il circuito del rack e il sistema di raffreddamento dell'edificio.

Il progetto utilizza inoltre la modellazione elettrica ETAP e la fluidodinamica computazionale tramite EcoStruxure IT Design. La fluidodinamica computazionale simula il flusso d'aria e l'andamento delle temperature prima che le apparecchiature arrivino sul sito.

Gli operatori possono utilizzare un gemello digitale elettrico per modellare il comportamento dell'infrastruttura. Unified Operations Center di AVEVA aggiunge monitoraggio e visibilità operativa dopo l'implementazione. Questi strumenti sono progettati per individuare prima i conflitti elettrici o termici durante il processo di costruzione.

Schneider Electric afferma che la configurazione completata può raggiungere un'efficacia nell'uso dell'energia, o PUE, di circa 1,12 a pieno carico. Il PUE confronta il consumo energetico totale di una struttura con l'energia erogata alle apparecchiature di calcolo. Un valore più vicino a 1 indica minori consumi indiretti, sebbene i risultati effettivi dipendano da clima, utilizzo e scelte operative.

Il progetto iniziale segue i requisiti dell'American National Standards Institute per le implementazioni negli Stati Uniti. Schneider Electric prevede di sviluppare una versione allineata agli standard della International Electrotechnical Commission per altri mercati.

Questa limitazione geografica è importante. L'annuncio offre un punto di partenza convalidato, anziché un progetto universale in grado di aggirare i codici elettrici locali o le condizioni delle utility. I clienti necessitano comunque di attività ingegneristiche legate al proprio sito.

Il progetto è disponibile senza una tariffa separata per il cliente, secondo fonti indipendenti. Il suo vero valore è l'incertezza evitata nell'integrazione, non il costo di acquisizione del documento.

Un progetto di riferimento non fornisce elettricità né garantisce una connessione alla rete. Non può gettare calcestruzzo, ottenere diritti sull'acqua o risolvere le autorizzazioni locali. Può restringere la gamma di questioni ingegneristiche senza risposta una volta disponibile un sito adatto.

Questa distinzione definisce la tensione centrale dell'articolo. AMD ha realizzato processori competitivi e un'architettura a scala rack. Ora ha bisogno di un modo ripetibile per installare quell'architettura all'interno di strutture costruite sotto vincoli fisici reali.

Perché la competizione AMD Google va oltre i chip

Il confronto amd google dipende sempre più dall'ingegneria delle strutture, perché i sistemi AI ad alta densità competono come piattaforme complete elettriche, termiche, di rete e software.

Google gestisce infrastrutture AI personalizzate da circa un decennio. Progetta TPU, reti a scala pod, sistemi di raffreddamento, framework software e molti componenti di supporto per data center all'interno della stessa organizzazione.

Questa esperienza crea un vantaggio che le sole specifiche degli acceleratori non possono cogliere. Google può coordinare le roadmap dei processori con gli edifici che li ospitano. Può inoltre testare le modifiche infrastrutturali su una grande flotta interna prima di offrire capacità tramite Google Cloud.

Google ha dichiarato di aver implementato il raffreddamento a liquido su scala gigawatt in oltre 2.000 pod TPU nell'arco di sette anni. Ha inoltre riportato un uptime di circa il 99,999 percento per queste implementazioni di raffreddamento. L'azienda ha discusso questa esperienza presentando progetti di rack da un megawatt.

Si tratta di dati riportati dall'azienda, non di un confronto indipendente con AMD Helios. Mostrano comunque la maturità operativa che le piattaforme infrastrutturali concorrenti devono affrontare.

Google ha inoltre sviluppato Brazos, un sistema di raffreddamento a liquido-aria montato su rack per hardware raffreddato a liquido all'interno di strutture raffreddate ad aria. Il sistema Brazos cattura il calore tramite un circuito chiuso a liquido, quindi lo rilascia nel corridoio caldo esistente.

Brazos e il progetto Helios di Schneider Electric affrontano situazioni di implementazione diverse. Tuttavia, entrambi riflettono la stessa pressione del settore. L'adozione dell'hardware AI si blocca quando l'edificio di destinazione non può fornire il circuito a liquido, l'alimentazione elettrica o la capacità di dissipazione del calore richiesti.

AMD non possiede una flotta di data center hyperscale paragonabile a quella di Google. Ha quindi bisogno di partner infrastrutturali, produttori di server, fornitori cloud e fornitori di rete per creare un percorso equivalente per i clienti.

Schneider Electric colma una parte significativa di questa lacuna. Integra distribuzione elettrica, apparecchiature di raffreddamento, software di modellazione e ingegneria delle strutture nel programma di AMD a scala rack. HPE offre un'altra strada incorporando Helios in sistemi commerciali.

Questo modello di partnership può offrire flessibilità. Un cliente non è limitato al processore o all'architettura di struttura di un singolo operatore cloud. Gli operatori possono adattare un progetto aperto a progetti di colocation, cloud privato, AI sovrana e calcolo specializzato.

Tuttavia, un modello guidato dai partner crea anche rischi di coordinamento. Le modifiche a un acceleratore, uno switch, una CDU, un bus elettrico o una release software possono influire su diverse aziende. La convalida deve tenere il passo con ogni roadmap dei componenti principali.

Il modello integrato di Google riduce parte di questa distanza organizzativa. L'azienda può allineare i team dedicati a TPU, rete, software e strutture tramite una pianificazione interna. Può inoltre riservare la propria infrastruttura ai carichi di lavoro che si adattano alla sua economia.

Il compromesso riguarda il controllo del cliente. Un cliente Google Cloud utilizza la piattaforma principalmente come servizio gestito. Un acquirente di Helios può ottenere un controllo più diretto sull'ambiente di calcolo, sul progetto della struttura e sul modello operativo.

Questo non rende AMD e Google sostituti diretti in ogni approvvigionamento. Google vende servizi cloud e utilizza silicio personalizzato, mentre AMD vende processori e tecnologia di piattaforma attraverso una rete industriale.

Tuttavia, gli acquirenti aziendali confrontano la capacità risultante. Esaminano tempi di implementazione, compatibilità dei modelli, regioni disponibili, controllo operativo, prestazioni e consumo energetico. L'unità competitiva sta diventando il cluster AI funzionante anziché il singolo chip.

Nvidia rimane il principale punto di riferimento in questo mercato. Schneider Electric ha annunciato una collaborazione infrastrutturale con Nvidia nel 2024, focalizzata sulla distribuzione ad alta potenza e sul raffreddamento a liquido per cluster densi di acceleratori. Quella precedente collaborazione con Nvidia mostra che Schneider non sta scegliendo una sola piattaforma di acceleratori.

Schneider Electric beneficia invece del fatto che diverse architetture richiedono nuovi progetti di struttura. Per AMD, il rapporto fornisce credibilità infrastrutturale. Per i clienti, crea un'altra opzione progettata accanto alle TPU native del cloud e ai sistemi incentrati su Nvidia.

Alimentazione e raffreddamento definiscono ora il meccanismo competitivo

Il contributo di Schneider Electric è importante perché un rack da 246 kilowatt cambia la struttura più rapidamente di quanto cambi il foglio di calcolo dell'approvvigionamento.

La pianificazione tradizionale dei server spesso trattava il data center come un contenitore stabile. Gli acquirenti selezionavano i server, assegnavano le posizioni nei rack e verificavano se la capacità elettrica e di raffreddamento esistente fosse sufficiente.

L'AI ad alta densità inverte questa sequenza. Il carico di lavoro e la roadmap degli acceleratori plasmano ora la topologia elettrica, le tubazioni, la disposizione del pavimento, il modello di ridondanza e il programma di costruzione. Un edificio progettato per i server di ieri non può accettare automaticamente i rack di domani.

A 246 kilowatt, un rack Helios richiede un coordinamento diretto tra le apparecchiature di calcolo e i sistemi della struttura. Un progetto elettrico deve gestire carico costante, comportamento transitorio, impostazioni di protezione, stati di manutenzione e scenari di guasto.

Il progetto di raffreddamento deve fornire liquido sufficiente a ogni cold plate. Deve inoltre trasferire il calore attraverso le CDU e i circuiti della struttura senza creare variazioni di temperatura o squilibri di flusso inaccettabili.

Il raffreddamento ad aria resta parte del progetto perché alcuni componenti e apparecchiature circostanti rilasciano ancora calore nell'ambiente. Schneider Electric descrive quindi un approccio ibrido, anziché sostenere che il liquido elimini ogni requisito sul lato aria.

La libreria di progetti di riferimento dell'azienda spiega perché la modellazione deve coprire il comportamento elettrico, il flusso d'aria e il flusso del liquido. Ogni modello intercetta una diversa classe di guasto. Combinarli può identificare le interazioni prima che gli operatori alimentino il cluster.

Si consideri un guasto parziale del raffreddamento. Le apparecchiature rimanenti devono assorbire calore aggiuntivo oppure il carico di calcolo deve diminuire rapidamente. Questo evento influenza i controlli della struttura, la pianificazione del cluster e potenzialmente l'avanzamento dell'addestramento dei modelli.

Un'interruzione di corrente crea un ulteriore problema trasversale. I sistemi di backup devono supportare lo stato operativo previsto, mentre l'ambiente software deve gestire i processi interrotti. La resilienza dell'impianto e quella del calcolo non possono essere pianificate separatamente.

Questo è il meccanismo alla base della partnership Helios. AMD definisce il comportamento e i requisiti della piattaforma di calcolo. Schneider Electric traduce tali requisiti in configurazioni infrastrutturali che i team di progetto possono valutare.

Il design modulare del cluster da 10,4 megawatt aggiunge un ulteriore livello. Gli operatori possono pianificare la capacità in blocchi ripetibili anziché progettare ogni implementazione da zero. La standardizzazione può semplificare gli acquisti e ridurre i disaccordi tra ingegneri, appaltatori e fornitori tecnologici.

La ripetibilità aiuta anche i fornitori a prevedere il fabbisogno di apparecchiature. CDU, quadri elettrici, sistemi di monitoraggio e moduli prefabbricati possono essere pianificati attorno a configurazioni di cluster note. Tuttavia, anche un modulo ripetuto richiede un'integrazione a livello di sito.

La capacità della rete elettrica resta il vincolo più difficile. Un progetto ben rifinito non garantisce che un'utility possa fornire altri 10,4 megawatt nei tempi desiderati. Le code per l'interconnessione e i lavori sulle sottostazioni possono durare più a lungo del calendario di implementazione dell'hardware di calcolo.

Anche l'acqua e la dissipazione del calore variano in base alla località. Un impianto può richiedere chiller, dry cooler, torri di raffreddamento o un'altra configurazione in base al clima e alle restrizioni locali. Il progetto di riferimento non può eliminare tali differenze ambientali.

Il PUE dichiarato di circa 1,12 merita un contesto analogo. Il PUE cambia in base all'utilizzo, al meteo, alla ridondanza, al metodo di raffreddamento e ai confini di misurazione. Un valore modellato a pieno carico non dovrebbe essere considerato un risultato annuo garantito.

Gli operatori devono inoltre scegliere quanta capacità riservare a manutenzione e guasti. Usare infrastrutture ridondanti per capacità di calcolo aggiuntiva può migliorare l'utilizzo durante il normale funzionamento. Riduce però anche il margine disponibile quando le apparecchiature vanno fuori servizio.

Schneider Electric descrive questa scelta come una competizione tra capacità di calcolo aggiuntiva e la strategia di ridondanza originaria. La decisione dovrebbe essere esplicita, perché la capacità di backup inutilizzata non è automaticamente capacità produttiva gratuita.

Google incontra gli stessi limiti fisici nonostante il suo modello integrato. Il suo lavoro sul raffreddamento a liquido mostra che il silicio personalizzato non elimina l'ingegneria degli impianti. L'organizzazione deve invece sviluppare sistemi di raffreddamento e alimentazione insieme a ogni generazione di calcolo.

Il confronto amd google espone quindi due approcci allo stesso meccanismo. Google coordina internamente gran parte dello stack. AMD sta costruendo una rete aperta di partner attorno a Helios, con Schneider Electric che gestisce un livello critico dell'impianto.

Un design validato non è un'implementazione validata

L'incertezza centrale è se i clienti possano riprodurre i risultati modellati dal blueprint in siti, carichi di lavoro, fornitori e condizioni operative reali.

Schneider Electric e AMD descrivono il design come sviluppato e validato congiuntamente. Questa validazione indica che i componenti e le ipotesi ingegneristiche sono stati valutati insieme. Non dimostra le prestazioni sul campo su un'ampia base installata.

Nessun risultato di implementazione presso clienti è stato reso pubblico insieme all'annuncio di luglio. Le aziende non hanno divulgato un impianto Helios completato e operativo in modo continuo a 246 kilowatt per rack con il nuovo design.

Questo divario è normale per un'architettura appena rilasciata. Limita comunque ciò che gli acquirenti possono dedurre sui tempi di messa in servizio, sul comportamento in caso di guasto, sulla disponibilità dei componenti e sulla manutenzione a lungo termine.

La piattaforma Helios dipende anche dall'arrivo dell'hardware come previsto. Il suo design include acceleratori MI455X, processori EPYC di sesta generazione e interfacce di rete Vulcano. Ritardi o modifiche alle specifiche possono imporre un altro ciclo di validazione.

Il networking presenta un rischio specifico. Helios utilizza un approccio aperto, orientato a Ethernet, progettato per offrire un'alternativa all'ambiente NVLink strettamente integrato di Nvidia. Ciò offre agli acquirenti maggiore flessibilità nella scelta dei fornitori, ma attribuisce importanza a un ecosistema di partner emergente.

HPE ha annunciato piani per offrire sistemi basati su Helios, fornendo ad AMD un'importante via commerciale. La sua implementazione utilizza un fabric per acceleratori ad alta larghezza di banda e uno switch progettato ad hoc.

Un'analisi dettagliata del sistema Helios ha descritto una configurazione pianificata con 72 acceleratori MI455X. Il rapporto ha inoltre indicato l'obiettivo di AMD di 31 terabyte di memoria HBM4 e 2,9 exaFLOPS di calcolo FP4 per rack.

Queste cifre sono obiettivi legati a hardware futuro, non risultati di produzione verificati in modo indipendente. FP4 è un formato numerico a bassa precisione utilizzato per alcune attività di inferenza AI. Non dovrebbe essere confrontato direttamente con ogni carico di lavoro di addestramento o scientifico.

Il software resta un'altra variabile. ROCm ha ampliato il supporto a framework e modelli, ma la sola disponibilità dell'hardware non garantisce prestazioni applicative equivalenti. Gli acquirenti devono testare i propri modelli, operatori, compilatori e il comportamento dell'addestramento distribuito.

Google può ottimizzare carichi di lavoro importanti per le TPU tramite JAX, XLA e il proprio ambiente software interno. Nvidia dispone di una base di sviluppatori CUDA consolidata da tempo. AMD deve dimostrare che il suo stack aperto riduce la dipendenza senza trasferire ai clienti un carico eccessivo di integrazione.

Un design di riferimento può risolvere il blueprint dell'impianto lasciando irrisolta la migrazione delle applicazioni. Questo confine conta per i team aziendali che valutano il costo complessivo del passaggio tra piattaforme di acceleratori.

La manutenzione crea un altro banco di prova. I circuiti a liquido aggiungono pompe, connessioni, sensori, collettori e procedure di assistenza vicino a costose apparecchiature di calcolo. Gli operatori hanno bisogno di evidenze su perdite, filtrazione, qualità del refrigerante, sostituzione dei componenti e formazione del personale.

Anche la percentuale di rimozione del calore dell'84% richiede un'interpretazione attenta. Schneider Electric afferma che i suoi approcci di raffreddamento proposti sono in grado di rimuovere quella quota tramite liquido. Il carico termico restante e le condizioni operative influenzano comunque le esigenze di raffreddamento a livello di sala.

La stessa cautela vale per la velocità di implementazione. Un design preingegnerizzato può abbreviare la pianificazione e ridurre il lavoro duplicato. Non può garantire una costruzione più rapida quando trasformatori, quadri elettrici, chiller, acceleratori o potenziamenti della rete restano soggetti a vincoli.

C'è anche una questione commerciale. Gli acquirenti devono decidere se una maggiore scelta architetturale giustifichi la gestione di una relazione con fornitori più distribuita. Alcuni preferiranno un servizio cloud che nasconda l'impianto dietro un'API.

Altri valorizzeranno il controllo diretto, la residenza locale dei dati o l'indipendenza da una sola piattaforma cloud. I progetti di AI sovrana e i provider cloud specializzati sono particolarmente propensi a esaminare questa opzione.

Questa tensione rende la strategia AMD credibile ma incompleta. Schneider Electric ha ridotto una categoria di incertezza. Le implementazioni presso i clienti devono ora dimostrare se il sistema combinato funziona in modo coerente al di fuori di un ambiente modellato.

Tre segnali mostreranno se AMD può colmare il divario infrastrutturale

La prossima fase dipende da evidenze operative, dalla consegna da parte dei partner e da un'adozione ripetibile da parte dei clienti, non da un'altra serie di dichiarazioni architetturali.

Il primo segnale è un'implementazione presso un cliente completata utilizzando il design Schneider Electric. Le evidenze più solide includerebbero densità di rack misurata, tempi di messa in servizio, prestazioni di raffreddamento, disponibilità e PUE al variare realistico dei carichi di lavoro.

Un solo progetto pilota confermerebbe che il blueprint può uscire dall'ambiente di progettazione. Diverse implementazioni in climi e tipi di impianto differenti sosterrebbero una conclusione più forte sulla ripetibilità.

Un risultato vicino al PUE di 1,12 a pieno carico dichiarato rafforzerebbe la tesi di efficienza delle aziende. Un risultato molto superiore a tale valore non invaliderebbe automaticamente il design, ma metterebbe in luce l'importanza delle condizioni del sito.

Gli acquirenti dovrebbero inoltre osservare come gli operatori gestiscono guasti e manutenzione. Un cluster ad alta densità deve rimanere manutenibile quando un CDU, una pompa, un componente elettrico o un tray di calcolo richiede attenzione.

Il secondo segnale è una consegna coordinata da parte dei partner hardware e networking di AMD. Acceleratori MI455X, nuovi processori EPYC, interfacce Vulcano, switch, server e apparecchiature dell'impianto devono raggiungere i progetti secondo calendari compatibili.

Un'architettura di riferimento perde valore se un componente essenziale provoca un lungo ritardo. Al contrario, una disponibilità sincronizzata dimostrerebbe che il modello di partner di AMD può comportarsi come una piattaforma coerente.

I test di interoperabilità saranno particolarmente importanti. I clienti hanno bisogno di prove che modifiche a server, switch, software, alimentazione e raffreddamento non creino cicli ripetuti di riprogettazione.

I sistemi commerciali Helios di HPE forniranno un primo test. L'adozione delle stesse ipotesi a livello di rack da parte di ulteriori produttori di server o operatori cloud rafforzerebbe la standardizzazione.

Il terzo segnale è l'adozione dei carichi di lavoro rispetto alle TPU di Google e ai sistemi Nvidia. AMD non ha bisogno che ogni acquirente sostituisca tali piattaforme. Ha bisogno di un numero sufficiente di carichi di lavoro in produzione per affermare Helios come alternativa affidabile.

Queste evidenze dovrebbero includere applicazioni di addestramento e inferenza, non solo risultati di benchmark di picco. Gli operatori esamineranno prestazioni utilizzabili, impegno software, disponibilità del cluster, consumo energetico e velocità di espansione della capacità.

Lo sviluppo infrastrutturale di Google offre un riferimento utile. La sua lunga storia nel raffreddamento a liquido mostra che la conoscenza operativa si accumula attraverso le generazioni hardware. AMD e Schneider Electric devono iniziare a costruire un curriculum comparabile tramite clienti e partner.

Il confronto amd google resterà imperfetto perché le aziende occupano posizioni diverse nel mercato. Google gestisce una piattaforma cloud integrata e di silicio personalizzato. AMD fornisce un'architettura aperta che altre aziende implementano.

Eppure proprio questo contrasto spiega perché il nuovo design conta. Offre agli acquirenti una scelta tra il consumo di una piattaforma integrata e l'assemblaggio di un sistema validato basato su partner sotto il loro controllo.

Anche Nvidia influenzerà l'esito. I suoi sistemi a scala rack, la base software e le partnership infrastrutturali fissano il parametro di riferimento per la maturità dell'implementazione. Se Nvidia avanzerà più rapidamente, l'architettura aperta di AMD dovrà compensare con flessibilità, disponibilità o convenienza economica dei carichi di lavoro.

Schneider Electric ha incentivi a supportare ogni piattaforma principale. Questa posizione neutrale può aiutare i clienti a confrontare i requisiti degli impianti senza trattare una roadmap di acceleratori come permanente.

Per i team tecnici e di procurement, l'azione immediata è concreta. Modellare prima i carichi di lavoro previsti, quindi verificare se il sito scelto può supportarne i requisiti elettrici, termici, di networking e resilienza.

I team che valutano grandi annunci infrastrutturali necessitano inoltre di un modo duraturo per collegare le ipotesi ingegneristiche con le successive evidenze operative. Una base di conoscenza tecnica ricercabile può mantenere accessibili documenti di progettazione, risultati dei test e decisioni dei fornitori man mano che i progetti cambiano.

Il design Schneider Electric non decide la corsa agli acceleratori. Porta AMD nella fase più difficile, in cui le specifiche dei rack devono resistere ai limiti della rete elettrica, ai programmi di costruzione, ai guasti di raffreddamento e ai carichi di lavoro in produzione.

I clienti Helios pubblicheranno risultati misurati che corrispondono al blueprint, e i partner consegneranno ogni livello nei tempi previsti? Sono questi i test che ora contano. Osservate i primi siti operativi, la disponibilità hardware coordinata e l'adozione dei carichi di lavoro prima di dichiarare un vincitore nella corsa infrastrutturale AMD Google.