AMD Helios riunisce 72 GPU, ma Nvidia fissa il parametro di confronto
AMD ha presentato Helios come un unico sistema da 72 GPU, non come una raccolta poco integrata di server acceleratori collegati all'interno di un cabinet. L'analisi architetturale di AMD di ServeTheHome è rilevante perché l'azienda ora controlla quasi ogni livello principale del proprio rack per l'IA.
Helios combina acceleratori Instinct MI455X, processori EPYC Venice, networking Pensando, software ROCm e infrastruttura di alimentazione raffreddata a liquido. Broadcom fornisce il silicio di switching Ethernet commerciale che collega le GPU tramite un unico fabric scale-up.
Questa combinazione definisce il vero confronto. AMD non sfida più Nvidia soltanto con una scheda acceleratrice. Sta sfidando il modello rack-scale di Nvidia, respingendo al contempo l'approccio di networking chiuso che ha contribuito a rendere difficili da replicare i sistemi Nvidia.
Helios appare credibile sulla carta. Tuttavia, le specifiche di picco non dimostrano le prestazioni applicative effettivamente fornite, la maturità del software, i volumi di fornitura o l'economia operativa. Queste questioni irrisolte determineranno se l'apertura diventerà un vantaggio d'acquisto o soltanto una preferenza architetturale.
Cosa rivela la copertura di AMD su ServeTheHome all'interno di Helios
Helios sposta l'unità competitiva di AMD da una singola GPU a un rack IA integrato.
Il sistema contiene 72 acceleratori Instinct MI455X distribuiti su 18 tray di calcolo raffreddati a liquido. Ogni tray ospita quattro GPU e un socket per un processore EPYC 9006 di sesta generazione, con nome in codice Venice.
AMD assegna 432 GB di memoria HBM4 a ciascuna MI455X. Nell'intero rack, ciò produce circa 31 TB di memoria ad alta larghezza di banda disponibile all'interno del dominio scale-up.
La memoria ad alta larghezza di banda, o HBM, si trova vicino alla GPU e fornisce dati a velocità molto superiori rispetto alla memoria server convenzionale. Questa capacità è importante per modelli di grandi dimensioni, contesti lunghi, cache per l'inferenza e carichi di lavoro che altrimenti richiederebbero una maggiore partizione.
AMD indica fino a 23,3 TB/s di larghezza di banda della memoria per ogni MI455X nella documentazione della sua architettura CDNA 5. Il rack aggrega questi dispositivi in un sistema di memoria con oltre un petabyte al secondo di larghezza di banda teorica.
Il layout fisico è importante quanto il numero di acceleratori. Helios utilizza un telaio Open Rack Wide dell'Open Compute Project, più largo di un rack convenzionale. Il design offre spazio per tray di calcolo densi, cablaggio, apparecchiature di alimentazione e hardware per il raffreddamento a liquido.
Il rack include sei tray di switch scale-up. Ogni tray contiene due chip switch Broadcom Tomahawk 6, per un totale di 12 chip switch nell'intero sistema Helios.
Ogni dispositivo Tomahawk 6 offre 102,4 Tbps di capacità di switching. Le sue linee Ethernet formano il fabric interno che consente a ogni acceleratore di comunicare con tutti gli altri acceleratori tramite un singolo hop di switch.
Questo fabric trasporta UALink su Ethernet, spesso abbreviato in UALoE. UALink definisce una connessione scale-up per gli acceleratori, mentre Ethernet fornisce il trasporto sottostante e l'hardware di switching commerciale.
AMD afferma che ogni MI455X riceve 3,6 TB/s di larghezza di banda scale-up bidirezionale. Su 72 dispositivi, il dato aggregato raggiunge circa 260 TB/s.
Questo è il meccanismo alla base dell'affermazione di AMD secondo cui Helios si comporta come un unico sistema da 72 GPU. I cluster tradizionali spesso dividono la proprietà della memoria tra server separati, quindi trasferiscono i dati attraverso più livelli di rete.
Helios riduce questi confini all'interno del rack. Contiene ancora processori e dispositivi di memoria distinti, ma il suo fabric a singolo hop offre al software un dominio di acceleratori più strettamente interconnesso.
Le specifiche MI455X di AMD mostrano anche quanto il networking sia stato integrato nel package della GPU. Ogni modulo acceleratore include due die I/O avanzati e 36 collegamenti UALoE bidirezionali.
Questo cambiamento rende il networking parte dell'architettura dell'acceleratore. Non è più un accessorio selezionato dopo la progettazione della piattaforma di calcolo.
Helios utilizza inoltre hardware Pensando per le comunicazioni oltre il dominio scale-up. Ogni GPU può connettersi a tre schede di interfaccia di rete Vulcano da 800 Gbps, fornendo fino a 2,4 Tbps di larghezza di banda scale-out per acceleratore.
Il networking scale-out collega più rack in un'installazione più ampia. Una data processing unit Pensando Salina gestisce il traffico front-end, inclusi gestione, accesso allo storage e richieste applicative.
Il rack contiene quindi due livelli di rete distinti. Il silicio Broadcom unisce gli acceleratori all'interno di Helios, mentre i dispositivi AMD Pensando collegano Helios a storage, servizi e altri rack.
L'alimentazione completa il sistema. Una sbarra collettrice posteriore a corrente continua da 50 volt alimenta il rack, mentre il raffreddamento a liquido rimuove il calore dai suoi componenti ad alta densità.
I resoconti dell'evento Advancing AI di AMD hanno collocato il carico del rack tra 225 kW e 245 kW. Questo requisito rende Helios inadatto alle sale dati prive di supporto per alimentazione ad alta densità e raffreddamento a liquido.
Secondo i dettagli di piattaforma pubblicati, il rack può pesare anche circa 5.000 libbre. Gli acquirenti devono pertanto considerare l'implementazione come un progetto infrastrutturale, non come un normale rinnovo dei server.
L'attenzione di ServeTheHome all'architettura è quindi giustificata. Il prodotto centrale è l'integrazione stessa, inclusi calcolo, memoria, networking, alimentazione, raffreddamento, meccanica e software.
Perché AMD ha dovuto costruire subito l'intero rack
Nvidia ha costretto ogni fornitore serio di acceleratori a competere su scala di sistema.
I moderni carichi di lavoro IA impiegano molto tempo nello spostamento di dati tra acceleratori. Un'aritmetica più veloce aiuta solo quando modelli, attivazioni e risultati intermedi possono raggiungere i motori di calcolo senza creare lunghe attese.
Questa realtà favorisce sistemi progettati come unità coordinate. Nvidia ha affermato questo modello con le sue piattaforme NVL72, che combinano 72 GPU, CPU, switching NVLink, networking, raffreddamento e software.
In precedenza AMD vendeva acceleratori competitivi che i fornitori di sistemi assemblavano in server e cluster. Quel modello offriva scelta ai clienti, ma lasciava una maggiore quantità di lavoro di integrazione al di fuori del controllo diretto di AMD.
L'azienda poteva migliorare una GPU continuando comunque a perdere a livello di sistema. Topologia di rete, comunicazione collettiva, limiti di raffreddamento, ottimizzazione del software e progettazione dei server potevano annullare un vantaggio misurato sull'acceleratore.
Helios affronta questa debolezza fornendo un'architettura di riferimento completa. AMD specifica il tray di calcolo, la topologia scale-up, la rete scale-out, il formato del rack, l'alimentazione, l'approccio al raffreddamento e il software associato.
Le tempistiche riflettono anche l'arrivo di CDNA 5, la più recente architettura di calcolo dedicata ai data center di AMD. MI455X utilizza otto chiplet di calcolo prodotti con un processo a 2 nm e li colloca sopra due die per fabric e cache a 3 nm.
Due die I/O aggiuntivi gestiscono la comunicazione esterna. Dodici stack HBM4 circondano la logica, mentre il packaging avanzato collega i componenti in un unico modulo acceleratore.
Questo design a chiplet consente ad AMD di ottimizzare funzioni diverse con processi produttivi differenti. Densità di calcolo, interfacce di memoria, cache e networking non necessitano tutti delle stesse caratteristiche del silicio.
MI455X contiene 320 miliardi di transistor e 256 work group processor. Un work group processor organizza risorse di esecuzione che elaborano gruppi di operazioni IA e di calcolo scientifico.
AMD punta ai calcoli IA a bassa precisione con formati quali MXFP4, MXFP6, MXFP8 e FP8. Questi formati rappresentano i valori del modello con meno bit, aumentando il throughput quando un'applicazione può mantenere un'accuratezza accettabile.
L'acceleratore raggiunge un picco dichiarato di 40,3 petaflop per operazioni MXFP4. Nell'intero rack, AMD pubblicizza fino a 2,9 exaflop di prestazioni FP4 di picco e 1,4 exaflop in FP8.
Questi valori sono picchi teorici, non risultati misurati per un modello completo. Tuttavia, spiegano perché l'integrazione del rack sia arrivata insieme a MI455X.
Un singolo acceleratore ora sposta abbastanza dati e consuma abbastanza energia da far sì che il sistema circostante determini se le applicazioni possano utilizzare l'aritmetica disponibile. AMD aveva bisogno di Helios per esporre le capacità di CDNA 5 su una scala significativa.
L'azienda ha inoltre acquisito ZT Systems nel 2025, ottenendo esperienza ingegneristica nella progettazione di rack hyperscale. AMD ha poi separato l'attività produttiva, limitando la concorrenza diretta con partner server già affermati.
Questa operazione ha dato ad AMD competenze di sistema più profonde senza obbligarla a diventare l'unico fornitore di Helios. HPE, Supermicro, fornitori cloud e altri partner possono realizzare prodotti basati sul design di riferimento.
Microsoft ha annunciato l'intenzione di implementare Helios nei propri data center. HPE si era precedentemente impegnata ad adottare l'architettura, offrendo ad AMD canali di accesso sia alle infrastrutture hyperscale sia a quelle enterprise.
AMD ha dichiarato al CES che Helios sarebbe servito da modello per sistemi IA molto più grandi. La sua anteprima rack-scale ha collegato il design all'addestramento, all'inferenza e alle future implementazioni multi-rack.
La pressione quindi va oltre Nvidia. I produttori di server devono decidere quanta ingegneria AMD adottare, mentre i fornitori cloud devono stabilire se una piattaforma di riferimento aperta riduca il rischio di integrazione.
Anche i fornitori di chip affrontano un nuovo modello d'acquisto. I clienti valutano sempre più gli acceleratori come componenti di sistemi completi, non come schede intercambiabili con punteggi benchmark isolati.
Ethernet aperta è la principale sfida di AMD a Nvidia
Il confronto principale è tra il rack Ethernet aperto di AMD e la piattaforma NVLink controllata verticalmente da Nvidia.
Helios assomiglia alla Vera Rubin NVL72 di Nvidia sotto diversi aspetti importanti. Entrambi distribuiscono 72 acceleratori su 18 tray di calcolo raffreddati a liquido e utilizzano tray di switch dedicati per comunicazioni ad alta larghezza di banda.
La differenza risiede nel controllo della rete scale-up. Nvidia integra NVLink e lo switching NVLink nella propria piattaforma, mantenendo un'autorità diretta sul protocollo, sul silicio, sulla topologia e sull'integrazione software.
AMD utilizza un collegamento per acceleratori aperto trasportato tramite Ethernet. Broadcom fornisce il silicio di switching Tomahawk 6, mentre UALink definisce come gli acceleratori comunicano attraverso quel fabric.
Questa scelta consente ad AMD di usare tecnologia di rete commerciale anziché un'architettura di switch proprietaria. I fornitori di sistemi e gli hyperscaler possono lavorare con strumenti Ethernet, fornitori e pratiche operative familiari.
Apertura non significa che ogni componente possa essere scambiato senza lavoro ingegneristico. Le reti scale-up hanno requisiti rigorosi di latenza, congestione, affidabilità, sincronizzazione e software.
Tuttavia, le interfacce pubblicate offrono ai partner maggiore spazio per personalizzare il rack. Un fornitore cloud può modificare le scelte di networking, gestione o implementazione senza dipendere da un unico fornitore per ogni livello.
Il ruolo di Broadcom rende questa affermazione più concreta. Tomahawk 6 fornisce 512 linee a 200 Gbps, con capacità sufficiente per alimentare le 72 GPU alla velocità scale-up dichiarata da AMD.
Il rapporto sull'architettura Helios mostra perché questa partnership sia importante. Il portafoglio hardware di AMD è ampio, ma l'azienda non deve produrre ogni componente per controllare il design del sistema.
Questo crea un'alternativa a Nvidia basata su una coalizione. AMD contribuisce con GPU, CPU, dispositivi di rete Pensando, software e ingegneria di piattaforma. Broadcom contribuisce con il silicio centrale di switching scale-up.
HPE e altri produttori possono quindi trasformare questo modello in sistemi. Gli operatori cloud possono implementare tali sistemi mantenendo una maggiore influenza sulle scelte di networking e software.
Nvidia propone l’opposto. La sua integrazione più stretta riduce il numero di variabili esterne e offre ai clienti una piattaforma ottimizzata da un singolo fornitore.
Questo controllo può semplificare l’ottimizzazione delle prestazioni. Nvidia può coordinare il comportamento delle GPU, i chip degli switch, le librerie di comunicazione, i driver, il networking e i framework applicativi attraverso un’unica roadmap.
AMD scommette invece sul fatto che gli standard aperti possano raggiungere un’efficienza comparabile senza richiedere che un’unica azienda possieda ogni anello della catena. Questa proposta dovrà reggere ai carichi di lavoro reali, non solo ai diagrammi di topologia.
I due sistemi differiscono anche al di fuori del rack. Helios assegna tre interfacce Vulcano da 800 Gbps a ciascun acceleratore, raggiungendo 2,4 Tbps di larghezza di banda scale-out per GPU.
Le configurazioni Vera Rubin pubblicate abbinano ogni GPU a un’interfaccia ConnectX-9 da 1,6 Tbps. AMD rivendica quindi il 50% di larghezza di banda scale-out in più per acceleratore.
Questo confronto favorisce i carichi di lavoro distribuiti su più rack, a condizione che il software riesca a utilizzare i collegamenti in modo efficiente. I grandi job di addestramento e i servizi di inferenza distribuita dipendono da questo livello quando un singolo rack non può contenere l’intero carico di lavoro.
AMD rivendica anche una maggiore capacità e larghezza di banda di memoria. Helios offre 31 TB di HBM4 nell’intero rack, che secondo AMD rappresentano il 50% di capacità in più rispetto alla piattaforma Nvidia concorrente.
Una maggiore capacità di memoria può ridurre il partizionamento dei modelli e lasciare più spazio alle cache chiave-valore. Una cache chiave-valore memorizza i dati di attenzione affinché un sistema di inferenza possa generare token successivi senza ricalcolare il contesto precedente.
Questo vantaggio è particolarmente rilevante per l’inferenza a contesto lungo e per i modelli che gestiscono molte richieste simultanee. Tuttavia, la sola capacità non determina né la latenza né il throughput.
La pianificazione software, la qualità dei kernel, l’efficienza delle comunicazioni e la forma del carico di lavoro continuano a determinare quante prestazioni utili arrivino effettivamente ai clienti. L’ambiente CUDA di Nvidia rimane il riferimento consolidato per molti team AI.
ROCm è migliorato nelle recenti generazioni Instinct e i principali framework ora supportano l’hardware AMD. Helios attribuisce comunque ad AMD una responsabilità maggiore nel far funzionare in modo prevedibile 72 acceleratori come un’unica piattaforma.
La competizione tra apertura e controllo non è quindi filosofica. È una questione misurabile: un’architettura basata su partner può eguagliare le prestazioni effettive e l’affidabilità di una piattaforma integrata?
Le specifiche non risolvono la questione delle prestazioni
I numeri più forti di AMD restano dichiarazioni del fornitore finché test indipendenti a livello di rack non li confermeranno.
AMD afferma che Helios offra il 15% di prestazioni FP4 di picco in più per acceleratore rispetto al principale sistema concorrente. Prevede inoltre fino al 30% di migliore economia per token.
Queste affermazioni richiedono un’attenta contestualizzazione. L’aritmetica FP4 di picco descrive l’operazione a bassa precisione supportata più veloce in condizioni ideali, non la velocità sostenuta di un modello in produzione.
Un confronto tra token per dollaro richiede ancora più ipotesi. Utilizzo dell’hardware, elettricità, raffreddamento, licenze software, personale, accuratezza del modello, dimensione dei batch e disponibilità del sistema incidono tutti sul risultato.
AMD non ha divulgato prezzi pubblici in una forma che consenta un confronto neutrale del costo di proprietà. Gli acquirenti negozieranno inoltre accordi per hardware, supporto, networking e implementazione su scale differenti.
I dati a livello di rack complicano il quadro delle prestazioni. AMD indica 2,9 exaflop di prestazioni FP4 di picco per Helios, mentre Nvidia ha pubblicato un dato superiore di 3,6 exaflop per rack per Vera Rubin NVL72.
Le definizioni alla base di questi numeri potrebbero differire. Il risultato Nvidia può incorporare un comportamento di compressione adatto ad alcuni compiti di inferenza, mentre AMD enfatizza i tassi di precisione supportati senza compressione.
Il confronto tra rack di The Register ha rilevato questa distinzione. Alcuni carichi di lavoro possono trarre vantaggio dalla compressione adattiva di Nvidia, mentre altri richiedono calcoli più strettamente allineati alla cifra non compressa di AMD.
Nessuno dei due confronti identifica un vincitore universale. Addestramento, fine-tuning, inferenza densa, modelli mixture-of-experts e servizi a contesto lungo sollecitano l’hardware in modo diverso.
Un modello mixture-of-experts attiva solo gruppi selezionati di parametri per ciascun token. Può ridurre il calcolo, ma crea anche impegnativi schemi di comunicazione tra GPU.
Helios potrebbe offrire buone prestazioni quando la capacità di memoria o la larghezza di banda scale-out limitano un’applicazione. Nvidia potrebbe mantenere un vantaggio quando il suo stack software estrae più lavoro da risorse nominali inferiori.
La stessa cautela vale per il linguaggio di AMD sulla memoria a singolo hop. Helios fornisce un dominio HBM strettamente connesso, ma non trasforma 72 pool di memoria fisici in un unico dispositivo convenzionale a memoria uniforme.
Il software deve comunque comprendere il posizionamento dei dati, la proprietà degli acceleratori, la sincronizzazione e i costi di comunicazione. Un accesso HBM remoto attraverso uno switch non si comporta come un accesso locale all’interno di un package GPU.
Anche la latenza conta, accanto alla larghezza di banda. AMD pubblica un throughput aggregato impressionante, ma risultati applicativi dettagliati mostreranno come il fabric si comporti in presenza di contesa e traffico irregolare.
L’affidabilità pone un’altra sfida. Un rack da 72 GPU combina acceleratori, processori, switch, interfacce di rete, connessioni di raffreddamento, componenti di alimentazione, cavi e software in un unico dominio operativo.
I guasti diventano più costosi quando i carichi di lavoro trattano il rack come un unico sistema. Gli operatori hanno bisogno di isolamento dei guasti, telemetria, checkpointing, facilità di manutenzione e procedure di ripristino prevedibili.
Il rack a doppia larghezza presenta anche vincoli infrastrutturali. Il suo intervallo di potenza da 225 kW a 245 kW supera la capacità di molte sale dati aziendali esistenti.
Il raffreddamento a liquido è obbligatorio a questa densità. Gli acquirenti hanno bisogno di distribuzione del refrigerante, conversione di potenza, portata del pavimento, accesso per la manutenzione e team operativi qualificati.
Questi requisiti non indeboliscono Helios rispetto a ogni concorrente. I sistemi Nvidia su scala rack generano richieste infrastrutturali simili.
Limitano tuttavia il mercato indirizzabile. Helios, almeno inizialmente, appartiene a data center hyperscale, strutture AI specializzate, laboratori nazionali e siti progettati per apparecchiature dense con raffreddamento a liquido.
Il software rimane la maggiore variabile incerta. ROCm deve supportare la topologia del rack e al tempo stesso eguagliare l’usabilità e le prestazioni che gli sviluppatori si aspettano da implementazioni Nvidia mature.
I clienti avranno bisogno di comunicazione collettiva stabile, kernel ottimizzati, integrazione con i framework, osservabilità, orchestrazione e supporto rapido per nuove architetture di modelli.
AMD controlla una porzione maggiore di questo percorso rispetto al passato. Possedere il processore, l’acceleratore, le interfacce di rete e il sistema di riferimento offre ai suoi ingegneri più opportunità di eliminare problemi tra fornitori diversi.
Eppure il controllo non crea istantaneamente maturità. Le prime implementazioni in produzione faranno emergere problemi che benchmark di presentazione e progetti di riferimento non possono prevedere.
Helios mette sotto pressione gli acquirenti quanto Nvidia
Helios offre agli acquirenti di infrastrutture una seconda strada su scala rack, ma rende anche più impegnativo il loro lavoro di valutazione.
Un’alternativa credibile può migliorare il potere negoziale. Gli hyperscaler non devono più confrontare un rack Nvidia integrato con un assortimento di server AMD assemblati indipendentemente.
Possono confrontare due architetture rack da 72 GPU con ambizioni fisiche simili. Entrambe arrivano come piattaforme coordinate per addestramento e inferenza su scala di data center.
Questo rende più significativi i confronti negli acquisti. Gli acquirenti possono esaminare memoria per rack, larghezza di banda scale-up, larghezza di banda scale-out, potenza, raffreddamento, maturità software, manutenibilità e risultati dei carichi di lavoro.
L’analisi approfondita di AMD di ServeTheHome evidenzia anche l’importanza della scelta nella catena di fornitura. Lo switching Broadcom e uno standard rack aperto creano più spazio affinché i produttori differenzino le loro implementazioni.
HPE può combinare Helios con la propria ingegneria di sistema e l’esperienza nel networking Juniper. Supermicro può puntare ai clienti che già gestiscono le sue piattaforme raffreddate a liquido.
I fornitori cloud possono esporre capacità MI455X tramite servizi gestiti, riducendo la necessità per i clienti più piccoli di installare direttamente i rack fisici.
AMD ottiene maggiore portata da questo modello, ma dipende anche dai partner per un’esecuzione coerente. Una scarsa integrazione da parte di un produttore potrebbe danneggiare la percezione della piattaforma più ampia.
Il design controllato di Nvidia limita questa variazione. I clienti ricevono meno scelte architetturali, ma beneficiano anche di un obiettivo più uniforme per l’ottimizzazione delle applicazioni e il supporto.
Gli acquirenti aziendali dovrebbero quindi evitare di considerare l’apertura come una riduzione automatica dei costi. La personalizzazione crea valore solo quando l’organizzazione dispone della capacità ingegneristica per sfruttarla.
Un’azienda che esegue modelli standard tramite un servizio cloud gestito potrebbe preoccuparsi più dei token effettivamente erogati e della disponibilità che del fornitore di switch sottostante.
Un hyperscaler che sviluppa software di networking e pianificazione personalizzato potrebbe attribuire molto più valore alle interfacce pubblicate e al silicio commerciale.
I ricercatori che lavorano con modelli che superano la memoria di un server possono beneficiare del dominio HBM da 31 TB di Helios. La stessa capacità può supportare cache di inferenza più grandi e più richieste simultanee.
Gli sviluppatori dovrebbero interessarsene perché la diversità hardware influisce sulla portabilità del software. Una seconda architettura rack praticabile offre ai progetti framework e ai fornitori di modelli ragioni più solide per ottimizzare anche al di fuori di CUDA.
Questo processo non avverrà automaticamente. I team applicativi devono validare kernel, comportamento numerico, librerie di comunicazione, immagini container, strumenti di monitoraggio e flussi di lavoro di implementazione.
Anche l’industria più ampia beneficia di una competizione tra standard. UALink e Ultra Ethernet dispongono ora di un sistema di alto profilo in cui le loro prestazioni possono essere misurate sotto impegnativi carichi di lavoro AI.
Il successo incoraggerebbe più fornitori di switch, progettisti di acceleratori e costruttori di sistemi a partecipare. Risultati deboli rafforzerebbero invece il caso dell’integrazione proprietaria.
AMD sta inoltre esercitando pressione su se stessa. Le uscite annuali di acceleratori richiedono che il design del rack, il networking, il software e la catena manifatturiera avanzino secondo lo stesso programma.
Un componente in ritardo può frenare l’intero sistema. La piattaforma è pronta solo quando acceleratori, CPU, switch, interfacce di rete, raffreddamento, firmware, driver e framework funzionano insieme.
L’azienda afferma che Helios è entrato in produzione, con spedizioni previste entro la fine del terzo trimestre del 2026. Questa tempistica lo colloca vicino al lancio di Vera Rubin di Nvidia, anziché un’intera generazione indietro.
Il tempismo riduce lo svantaggio tradizionale di AMD. Elimina però anche le giustificazioni qualora software o fornitura non soddisfino le aspettative dei clienti.
L’annuncio della produzione ha riportato implementazioni pianificate da importanti partner. Il prossimo test è capire se tali impegni si tradurranno in capacità produttiva accessibile.
Un rack installato per la valutazione non equivale a una flotta che gestisce carichi di lavoro in grado di generare ricavi. Gli acquirenti dovrebbero richiedere risultati ripetibili nell’arco di settimane, non brevi dimostrazioni in condizioni controllate.
Tre segnali decideranno se Helios funziona
Il volume delle spedizioni, i risultati indipendenti sui carichi di lavoro e l’affidabilità multi-rack determineranno se Helios cambierà il mercato.
Il primo segnale è la consegna in produzione. AMD prevede spedizioni di Helios entro la fine del terzo trimestre, quindi i clienti dovrebbero osservare quali sistemi arriveranno prima della fine di settembre.
Le installazioni nominate contano, ma le quantità contano di più. Più flotte operative dimostrerebbero che AMD e i suoi partner possono procurarsi HBM4, assemblare i dispositivi MI455X, costruire rack e mettere in servizio siti raffreddati a liquido.
I ritardi indebolirebbero l’argomento temporale di AMD. La base installata e l’esperienza produttiva di Nvidia diventano più preziose a ogni trimestre in cui Helios rimane scarso.
Il secondo segnale è il benchmarking indipendente delle applicazioni. I valutatori hanno bisogno di risultati completi a livello di rack per gli attuali modelli linguistici, i carichi di lavoro mixture-of-experts, i job di fine-tuning e l'inferenza a contesto lungo.
I test utili dovrebbero riportare latenza, throughput, consumo energetico, utilizzo, accuratezza e comportamento in caso di guasto. Il solo picco aritmetico non può dimostrare se 72 GPU rimangano occupate durante un carico di lavoro reale.
I benchmark dovrebbero inoltre confrontare lo sforzo software. Una piattaforma che richiede settimane di lavoro su kernel personalizzati può offrire risultati hardware interessanti, aumentando però il rischio di progetto.
I confronti più informativi utilizzeranno modelli, dimensioni dei batch, formati numerici e obiettivi di livello di servizio equivalenti. In caso contrario, i fornitori possono selezionare impostazioni favorevoli alla propria architettura.
I risultati dovrebbero coprire carichi di lavoro ad alta intensità di memoria oltre a quelli ad alta intensità di calcolo. Le dichiarazioni di Helios su capacità e larghezza di banda diventano più solide se le applicazioni possono sfruttare entrambe senza un eccessivo overhead di comunicazione.
Il terzo segnale è una scalabilità affidabile su più rack. Un rack Helios testa UALink su Ethernet, mentre le distribuzioni più grandi testano anche le interfacce Pensando Vulcano e la rete Ultra Ethernet circostante.
AMD deve dimostrare che le prestazioni restano prevedibili quando i job attraversano i confini tra rack. Congestione, operazioni collettive, pianificazione dei job e guasti dei componenti diventano più difficili da gestire a questa scala.
I grandi clienti osserveranno con quale rapidità sia possibile isolare un acceleratore o un collegamento di rete guasto. Misureranno inoltre se un job possa continuare, riavviarsi o riprendersi da un checkpoint recente.
Solidi risultati su più rack sosterrebbero la tesi di AMD sulle reti aperte. Dimostrerebbero che switching commerciale, specifiche aperte e ingegneria dei partner possono offrire un sistema AI coordinato.
Una scalabilità debole favorirebbe l'integrazione più stretta di Nvidia. Suggerirebbe che il controllo dell'intero fabric offra ancora un vantaggio operativo che le specifiche non riescono a cogliere.
Questi segnali dovrebbero orientare il modo in cui i lettori interpretano i futuri report AMD ServeTheHome. Nuovi diagrammi e dati di picco saranno utili, ma le evidenze di produzione hanno ora più peso dell'intento architetturale.
Helios non è soltanto un altro server Instinct. È il tentativo di AMD di combinare le risorse accumulate nei data center in un unico prodotto competitivo.
MI455X fornisce calcolo a bassa precisione e 432 GB di HBM4. Venice fornisce l'elaborazione host, Pensando offre il networking scale-out e ROCm collega il sistema ai framework AI.
Il silicio Tomahawk 6 di Broadcom fornisce il collegamento centrale tra i 72 acceleratori. L'hardware Open Rack Wide offre ai produttori una base fisica comune.
Questa combinazione rende Helios la sfida più completa di AMD alla strategia di infrastruttura AI di Nvidia. Espone però anche AMD a uno standard più esigente.
I clienti non giudicheranno più l'azienda soltanto in base alle specifiche degli acceleratori. Valuteranno disponibilità del rack, prestazioni delle applicazioni, qualità del software, requisiti della struttura, affidabilità e supporto come un unico pacchetto.
La prossima domanda è pratica: gli operatori indipendenti riprodurranno le dichiarazioni di AMD dopo l'arrivo di Helios nei data center di produzione? Seguite le prime grandi distribuzioni, confrontate i risultati completi dei carichi di lavoro e osservate se Ethernet aperto resterà efficiente oltre un singolo rack.
