AMD var värd för sitt hittills största Advancing AI-evenemang, med fokus på skalbarhet. Företaget introducerade grafikkortet Instinct MI455X, Helios-racket med 72 grafikkort och 6:e generationens EPYC Venice-processorer. MI455X har 432 GB HBM4, en ökning med 50 % jämfört med NVIDIAs B300 eller Rubin, med 23.3 TB/s minnesbandbredd och upp till 40.26 PFLOPS MXFP4-beräkningshastighet. Ett komplett Helios-rack skalar dessa siffror med 72, vilket ger 2.9 exaFLOPS FP4, 31 TB HBM4, 1.7 PB/s minnesbandbredd, 260 TB/s uppskalning och 43 TB/s utskalningsbandbredd till datacentret. AMD strävar efter att leda branschen på alla mätvärden. Den här artikeln undersöker MI455X och Helios; lanseringen i Venice tas upp i en separat analys.

Det andra temat är öppenhet, som når varje lager, med början i sammankopplingen. Inuti racket delar alla 72 grafikkort minne över UALink, en öppen konsortiumstruktur som AMD kör på Ethernet som UALink-over-Ethernet (UALoE). När trafiken lämnar racket flyttas den på Ultra Ethernet, den öppna skalningsstandarden från Ultra Ethernet Consortium. Samma Instinct går uppför stacken. Den lågprecisionsmatematiken använder OCP:s öppna dataformat MXFP4, MXFP6 och MXFP8, och racket som innehåller allt är byggt enligt Open Compute Projects Open Rack Wide-design. Även programvaran utvecklas öppet, med ROCms kompilator, runtime och bibliotek tillgängliga i källkod.

Eftersom varje specifikation i stacken är publicerad och nedladdningsbar idag, kan en hyperskalare behandla Helios som en ritning och bygga en skräddarsydd version som är anpassad till sina egna anläggningar och arbetsbelastningar, och byta nätverk, strömförsörjning eller hantering för att passa. Det betyder att allt vi går igenom i den här artikeln är den referensdesign som AMD presenterade; de ​​enheter som kunderna driftsätter kan skilja sig avsevärt. Aktörerna är redan redo: AMD säger att OpenAI, Meta, Anthropic, Microsoft , Oracle och fler anammar Helios.

AMD Instinct MI455X: flaggskeppet i CDNA 5

MI455X är den första CDNA 5-acceleratorn, som består av 320 miljarder transistorer. MI455X har åtta Accelerator Complex Dies (XCD) byggda på TSMC:s N2-nod, plus två I/O-dies och två Fabric- och Cache-dies på N3-noden, samt tolv HBM4-stackar. Det är det största chipet som någonsin byggts på TSMC:s CoWoS-L-kapsling.

Minne är en av rubrikerna. De tolv HBM4-stackarna rymmer totalt 432 GB med en hastighet av 23.3 TB/s, där HBM4 fördubblar gränssnittet per stack till 2 048 bitar, och de två Fabric- och Cache-chipsen lägger till 192 MB L2-minne som körs med en hastighet av 54 TB/s.

MI455X har inte heller några problem med I/O. Den har 72 banor UALoE för 3.6 TB/s dubbelriktad bandbredd för uppskalning till resten av ett rack, 256 GB/s dubbelriktad Infinity Fabric till sin värd-CPU och ett val mellan två PCIe Gen6 x16-länkar eller tre AMD AI-NIC för utskalning.

Jämfört med chippet den ersätter och NVIDIAs erbjudanden, leder MI455X i alla mätvärden.

Specifikation	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
arkitektur	CDNA 5	Rubin	CDNA 4	Blackwell Ultra
Transistorer	320B	336B	185B	208B
HBM-kapacitet	432GB HBM4	288GB HBM4	288 GB HBM3E	288 GB HBM3E
HBM-bandbredd	23.3 TB/s	22 TB/s	8 TB/s	8 TB/s
Uppskalning per GPU	3.6 TB/s	3.6 TB/s	1.08 TB/s	1.8 TB/s
Skalbarhet per GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
CPU-GPU-länk	256 GB/s Infinity Fabric	1.8 TB/s C2C (1:2)	PCIe 5	900 GB/s C2C (1:2)

 

Låt oss börja med var AMD leder. Med 432 GB har MI455X 50 % mer minnesbandbredd än MI355X, B300 eller Rubin, som alla når en topp på 288 GB. Dess minnesbandbredd på 23.3 TB/s är också den högsta i gruppen. Utskalningsraden lutar åt samma håll: 2 400 Gbit/s per GPU mot 1 600 för Rubin och 800 för B300. Varje MI455X lämnar racket med 50 % mer nätverksbandbredd än sin närmaste konkurrent.

AMD har äntligen hunnit ikapp även inom skalning. NVLink har varit den ledande GPU-strukturen i åratal och var i två generationer det enda sättet att få topprestanda på MoE-modeller med WideEP. UALoE täcker det gapet på en enda generation: med 3.6 TB/s matchar MI455X Rubins NVLink 6. NVIDIA har fortfarande en tydlig ledning inom värdlänken. En Vera-processor matar två Rubin-GPU:er över 1.8 TB/s C2C, medan varje MI455X kommunicerar med sin Venice-värd över en 256 GB/s Infinity Fabric-länk. Den skillnaden formar hur de två rackarkitekturerna skiljer sig åt senare i den här artikeln.

På rå beräkning leder MI455X över hela linjen, med en fotnot: AMD:s OCP MX-format och NVIDIA:s NVFP4 skalar olika, så behandla dessa som annonserade toppar; levererad prestanda är en separat fråga.

Format	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
MXFP4 / NVFP4	40.26 PF	35 PF	10.1 PF	15 PF
MXFP6 / FP6	20.13 PF	17.5 PF	10.1 PF	5 PF
MXFP8 / FP8	20.13 PF	17.5 PF	5 PF	5 PF
FP16 / BF16	5.03 PF	4 PF	2.5 PF	2.5 PF
FP32	315TF	130TF	157.3TF	75TF

 

Jämfört med MI355X levererar MI455X fyra gånger högre dataflöde för MXFP4 och MXFP8 samt dubbelt så höga hastigheter som FP16/BF16 och FP32. Jämförelsen mot NVIDIA är uppdelad i två delar. Mot B300 levererar MI455X 2.7 gånger högre dataflöde för FP4 och fyra gånger högre hastigheter som FP6 och FP8. Rubin är det betydelsefulla riktmärket, och mot det har MI455X en konsekvent fördel: 15 % vid FP4, 15 % vid FP6 och FP8, och 26 % vid FP16/BF16. Den största skillnaden syns vid FP32, där MI455X:s 315 TF är ungefär 2.4 gånger Rubins 130 TF och mer än fyra gånger B300:s 75 TF. Den siffran kommer från Instincts HPC-härstamning och är fortfarande viktig för AI-arbete, eftersom mastervikter, högprecisionsackumulering och vetenskapliga arbetsbelastningar fortsätter att köras över lågbitsformaten.

Inuti CDNA 5

Låt oss dubbelklicka på arkitekturen och se vad som faktiskt driver denna klassledande prestanda.

Från XCD till SIMD

Att gå ner i hierarkin från paketet och ner visar hur mycket som byggdes om eftersom CDNA 4 organiserade beräkningskretsen väldigt annorlunda. På MI355X hade varje XCD 32 aktiva beräkningsenheter och en privat 4MB L2-cache som samlade kretsens trafik innan den nådde Infinity Fabric. CDNA 5 behåller de åtta XCD:erna men bygger om det som finns inuti dem, och lånar struktur och terminologi från AMD:s RDNA-grafiklinje. Varje MI455X XCD är nu uppdelad i två Shader Engines. Varje Shader Engine rymmer fysiskt 17 arbetsgruppsprocessorer, med 16 aktiverade, en reserv för utbyte. L2-kretsen per XCD är helt borta, lyft från beräkningskretsen och ner i baskretsarna nedanför, som minnessektionen återgår till.

Den aritmetik som spelar roll är vad som inte förändrades. En XCD bidrar fortfarande med 32 aktiva enheter, och GPU:n har fortfarande totalt 256, samma antal som MI355X hade som beräkningsenheter. Inget av generationens 4× i lågprecisionsgenomströmning kommer från att lägga till exekveringsenheter; allt kommer från att varje WGP gör mer arbete per cykel, och det är WGP som omdesignen koncentreras på.

En WGP är uppbyggd av fyra 32-filiga SIMD-enheter och fyra skalära enheter som delar en konstant cache. Den största förändringen är hur trådar flyter genom den: övergången från Wave64 till Wave32. En våg är det paket av trådar som en SIMD kör i takt. CDNA 4 använde Wave64 och skickade varje 64-trådsvåg genom en 16-filig SIMD över fyra klockcykler. CDNA 5 slopar Wave64-stödet helt och hållet, den första Instinct-arkitekturen som gör det, och kör Wave32 direkt. En 32-trådsvåg mappar en-till-en på var och en av WGP:s fyra 32-filiga SIMD-enheter, utfärdas i en enda cykel och låter varje SIMD starta en ny instruktion varje klocka.

Smala, snabbare vågor förändrar hur arbete rör sig genom maskinen. Instruktionslatensen minskar eftersom en våg slutförs tidigare. Grenavvikelser kostar mindre eftersom en "tagen-or-not"-delning nu stannar högst 32 trådar istället för 64. Registertrycket minskar, så fler vågor stannar kvar, upp till 64 per WGP jämfört med hälften så mycket som tidigare. Detta ger schemaläggaren fler små, oberoende arbetsstycken att dölja minneslatensen bakom. Wave32 gör det också enklare att mappa olika kakelstorlekar för tensoroperationer på hårdvaran, vilket förenklar kärnutvecklingen.

Single-cycle issue is only the start of the throughput story. The SIMDs co-execute, starting new instructions while earlier multi-cycle operations drain underneath, and packed vector instructions carry 64 threads' worth of work in a single issue, details AMD's architects confirmed in the post-briefing Q&A. The vector pipeline also gains native BF16 support and a set of new data-conversion instructions for moving tensors between formats. The transcendental units double their throughput over the MI355X and add a native tanh instruction, so the softmax and activation math inside attention keeps pace with the tensor hardware around it. That path is becoming a habit: CDNA 4 doubled the transcendental rates to accelerate attention, and CDNA 5 doubles them again.

Minneshierarkin

Bakom exekveringsenheterna sitter en hierarki ombyggd från topp till botten, och det tydligaste sättet att se den är nivå för nivå mot MI355X.

Nivå	MI455X (CDNA 5)	MI355X (CDNA 4)
Vektorregister	128 kB per SIMD; 1 024 per tråd; 2× bandbredd	128 KB per SIMD; 256 per tråd
WGP / CU lokal butik	384 kB (320 kB LDS + 64 kB vektorcache); 2× bandbredd	192 kB (160 kB LDS + 32 kB L1)
Instruktion / konstant cache	64 KB + 16 KB per WGP	64 KB delat per två CU:er + 16 KB
L2	2 × 96 MB på FCD:erna; 54 TB/s	8 × 4 MB, en per XCD
Minnessidans cache	Utslagen	256MB Infinity Cache
HBM	432 GB HBM4; 12 × 2 048-bitars stackar; 23.3 TB/s	288 GB HBM3E; 8 × 1 024-bitars stackar; 8 TB/s

 

Det var i cacheraderna som arkitekturen ändrade form. CDNA 4 körde en trenivådesign: varje XCD:s privata 4MB L2 sammanfogade den discens trafik innan den nådde Infinity Fabric, och en delad 256MB Infinity Cache i I/O-discarna placerades på minnessidan framför HBM-kontrollerna. CDNA 5 tar bort båda lagren och ersätter dem med två oberoende 96MB L2-cacher, en per Fabric och Cache Die, var och en byggd som 96 block på en megabyte. Layouten är vertikal: fyra XCD:er, eller åtta Shader Engines, är hybridbundna ovanpå varje FCD, som också innehåller sex av de tolv HBM4-platserna, och de två FCD:erna möts vid en central Infinity Fabric längst ner i mitten av paketet med I/O-discarna som täcker vardera änden. Endera L2 kan innehålla vilken adress som helst i GPU:ns minne, och Infinity Fabric håller paret koherent. AMDs angivna anledning är bandbredd: en av dessa cacher ensam levererar 1.5 gånger den sammanlagda bandbredden för MI355X:s hela Infinity Cache, paret levererar tre gånger, och ingen av den trafiken behöver korsa den die-to-die-halvering som begränsade den gamla layouten.

Cachen får också nya uppgifter. Enhets-scope-atomer, som tidigare kördes i fabric-strukturen, körs nu inuti L2 med mycket högre hastigheter, medan system-scope-atomer stannar kvar i Infinity Fabric som tidigare. En ny broadcast-domare kompletterar det hela genom att multicasta tensorplattor till varje WGP som samarbetar på samma matris. Därför tjänar en vikt som hämtas en gång dem alla, vilket förstärker den effektiva läsbandbredden med upp till 4×.

Nivåerna ovan skalas för att matcha. Lokal lagring per WGP fördubblas till 384 KB, uppdelat på 320 KB LDS och en 64 KB vektordatacache, med dubbelt så stor läsbandbredd. Det finns utrymme för FlashAttention att lagra frågor, nycklar, värden och partiella reduktioner på chipet istället för att skriva ut hela uppmärksamhetsmatrisen. Den stöder också sammanslagna MoE-kärnor för att hålla routingstatus och ackumulatorer residenta. Vektorregisterfilen behåller sin kapacitet på 128 KB per SIMD men är omorganiserad för Wave32. Detta resulterar i dubbelt så många vågor, gör att en enda tråd kan adressera 1 024 register istället för 256, och fördubblar registerbandbredden för att mata de bredare SIMD:erna och deras samexekveringsenheter.

Den skalära sidan är ombyggd för att matcha, med 128 skalära register per våg och 32 KB per WGP. I grunden går HBM4 från åtta 1 024-bitars stackar till tolv 2 048-bitars stackar, vilket ökar kapaciteten med 50 % till 432 GB och bandbredden 2.9× till 23.3 TB/s över ett 192-kanaligt gränssnitt.

Allt detta matas av en ny Tensor Data Mover, en per WGP, som förstår tensor-tilingscheman upp till fem dimensioner och strömmar tiles asynkront mellan DRAM och det lokala minnet utan mellanliggande registerstaging. Överföringar beskrivs av deskriptorer som laddas från skalära register och gränskontrolleras i hårdvara för säkerhet. Multicast-laddningar stöds, så SIMD-enheterna stannar aldrig i väntan på en kopia eller brännregister som staging. Det är CDNA 5:s svar på tensorminnesacceleratorerna på nyare NVIDIA-komponenter. En uppsättning användningsfunktioner avrundar maskinens front: arbetsgruppskluster ger kärnor explicit kontroll över placering och samtidighet för datadelningsarbetsbelastningar, delade och namngivna barriärer låter en producent signalera slutförande och gå vidare utan att vänta på att konsumenten ska svara, förhämtar data på varje nivå i hierarkin mot dess konsumtionspunkt, och ett omarbetat kommandogränssnitt minskar kärnans start- och avsändningslatens för de korta kärnorna som dominerar inferens.

DMA-systemet byggdes om med samma filosofi. Programvaran schemalägger överföringar mot DMA-frontends, medan fysiskt medvetna backends som sitter bredvid UALoE-länkarna delar upp varje arbetsobjekt, lastbalanserar det över varje tillgänglig länk och hämtar buffertar från minnet direkt istället för att släpa data över chipet till en avlägsen motor. Backends reagerar också på överbelastning från det uppskalbara nätverket och styr runt laddade sökvägar, så att kommunikationsbibliotek får välbalanserad fabric-trafik utan att någonsin förstå topologin under.

Skiva GPU: NPS och SR-IOV

Den fysiska layouten med två nivåer ger en andra utdelning i hur GPU:n partitioneras. I NPS1 är hela chipet en NUMA-domän: adresserar sammanflätning över alla tolv HBM-stackar och båda halvorna för enhetlig bandbredd, det enkla läget för portering och för jämnt spridda åtkomstmönster. NPS2 delar upp GPU:n i två NUMA-domäner, som var och en äger sex HBM-stackar, en Fabric- och Cache-die, och XCD:erna staplade på den. Varje minnesreferens stannar sedan kvar i sin egen halva, och varje domän får effektivt en privat 96 MB L2. Det gör mer än att förkorta den fysiska vägen. Utan några cachelinjer som delas mellan halvorna försvinner Infinity Fabric-koherenstrafiken mellan de två L2:orna till stor del, och AMD säger att resultatet är lägre latens och bättre effektivitet för NUMA-medvetna applikationer. CDNA 4 erbjöd samma breda utbyte, där NPS2 höll trafiken inuti en I/O-die, men CDNA 5 skärper det eftersom det som lokaliseras nu är hela L2-cachen snarare än en del av en minnesbuffert.

Beräkningspartitioneringsstackar ovanpå. De åtta XCD:erna låter GPU:n starta som en, två, fyra eller åtta spatiala partitioner, vilket delar upp de 432 GB HBM i jämna skivor om 432, 216, 108 eller 54 GB, backade upp av åtta ner till en XCD vardera. Genom att para ihop partitioner med NUMA-domänerna kan körtidsutskicket arbeta och placera allokeringar spatialt, så att ett jobb landar på de XCD:er som är närmast dess minne. SR-IOV virtualiserar sedan partitionerna till så många som åtta hårdvaruisolerade virtuella maskiner, med isoleringen verkställd i själva minnessystemet, oberoende av vilket NUMA-läge som körs. MI355X erbjöd samma partitionsalternativ med en till åtta partitioner, så granulariteten är inte ny; det som CDNA 5 lägger till under är beteendet privat-L2, och ovanför det de virtuella poddarna på racknivå som Helios-sektionen täcker.

AMD Helios

En enda MI455X är snabb. Men med den här lanseringen ansluter sig AMD till klubben för rack- och storskaliga domäner.

Rent fysiskt har Helios övergett de traditionella 19-tums- och 21-tumsracken till förmån för Open Rack Wide, ett format som AMD hjälpte till att utveckla tillsammans med Meta på OCP: ett kabinett som är 1.2 meter brett och 1.3 meter djupt med 44 OU vertikalt utrymme. Inuti sitter de 72 grafikkorten i två banker med nio datorfacken, med de sex switchfacken staplade mellan dem, och varje GPU-till-switch-länk är koppar som går genom fyra blind-mate-kabelkassetter på baksidan, så facken kan skjutas ut för service utan att kablar behöver kopplas ur för hand.

Hela racket drar 225 till 245 kW beroende på arbetsbelastning, levererat via en 50V vätskekyld samlingsskena, med bakre grenrör som trycker ungefär 385 liter kylvätska per minut från anläggningens loop. Själva brickorna är seriös hårdvara: varje väger cirka 70 kg, och att placera en switchbrickas 1 728 differentialpar-anslutningar kräver cirka 690 kg insättningskraft, vilket är anledningen till att dess kamhandtag löper nästan längs brickans hela bredd.

Byggstenarna

Beräkningsfack

I referensdesignen är varje datorbricka en fristående nod byggd kring 4x MI455X-moduler och en högfrekvent 96-kärnig Venice SP7-processor som ökar klockfrekvensen till 5 GHz. Dess 16 DIMM-socklar har 1 TB DRAM som 16 × 64 GB DDR5 ECC RDIMM-minnen, med 5 E1.S NVMe-platser hängande utanför processorn. Plattformen är klassad för mycket mer: Venices 16 minneskanaler stöder upp till 1.6 TB/s bandbredd, och med 256 GB RDIMM-minnen i toppen av DDR5-serien idag, når en 16-kanals sockel med 1 DIMM per kanal upp till 4 TB.

I NVIDIAs fotspår ansluter sig processorn till den koherenta minnesdomänen över Infinity Fabric istället för att sitta bakom grafikkorten som en vanlig PCIe-värd, och AMD hävdar att förhållandet mellan processor och grafikkort på 1:4 är avsiktligt: ​​själva kärnan överträffar konkurrenterna, med AMDs jämförbara uppskattningar som placerar 5 GHz Zen 6-kärnan cirka 20 % före NVIDIAs Vera i prestanda per kärna, och eftersom sockeln är en standard SP7 kan kunder som vill ha mer värdberäkning anpassa vilken Venice SKU som helst upp till flaggskeppet med 256 kärnor. En Venice-sockel har också mycket mer DDR5-kapacitet än en LPDDR-värddesign, och dess minnesbandbredd mättas till alla fyra grafikkorten över Infinity Fabric-länkarna.

Den där Infinity Fabric-länken är värd att titta närmare på. När George Cozma från Chips and Cheese genomgick Venice-till-MI455X-anslutningen föreslog han att den koherenta länken använder processorns PCIe-banor, på samma sätt som EPYC har transporterat sina xGMI-socketlänkar över PCIe PHY:er i åratal. Siffrorna stöder den teorin. PCIe Gen 6 signalerar med 64 Gb/s per lane, och en x16-länk med den hastigheten blir 128 GB/s åt varje håll, exakt den dubbelriktade siffra på 256 GB/s som AMD anger per GPU. CDNA 5-whitepaperns eget blockdiagram märker värdens Infinity Fabric-gränssnitt med 64 Gb/s per lane, den exakta Gen 6-signalhastigheten. Teorin förklarar också varför alla Venice SKU:er används: de 4 GPU:erna förbrukar 64 av processorns 128 Gen 6-banor, vilket lämnar resten fritt för DPU:er, lagring och andra systembehov.

Tre separata nätverk passerar genom varje datorbricka, och varje nätverk har olika uppgifter. Det mest konventionella är front-end-enheten: en enda Pensando Salina 400G DPU ansluter noden till det vanliga datacenternätverket, vilket vi kommer att utforska mer i detalj senare.

Det andra är skalbarhet, nätverket som sammanfogar rack i kluster, och det renaste sättet att förstå det är att räknaSerDess. MI455X:s skalbarhet kan använda antingen PCIe Gen 6 med 64 Gb/s per lane eller UALink128 med 128 Gb/s, och ett Vulcano 800 NIC behöver ungefär 128 Gb/s anslutning åt varje håll för att hålla sin 800 GbE-port matad. Vid Gen 6-hastigheter krävs en full x16-länk per NIC, så GPU:n bär 2 NIC; vid UALink128:s fördubblade signalhastighet gör en x8-länk samma jobb på hälften av SerDes, så GPU:n bär 3, vilket är den konfiguration som Helios levererar. Hur som helst är UALink128-hoppet inget annat än en privat kabel mellan GPU och NIC; själva nätverket börjar vid Vulcano. Varje nätverkskort driver en 800 GbE-port som kör UEC-kompatibla transporter, inklusive MRC, flervägsprotokollet OpenAI som utvecklats tillsammans med AMD och andra partners. Fysiskt sitter nätverkskorten på två anpassade kort per fack med fyra eller sex Vulcano ASIC:er vardera, vilket matchar konfigurationerna med två och tre per GPU. I full storlek blir det 12 nätverkskort per fack och 2 400 Gb/s skalbar bandbredd per GPU. Och eftersom nätverkskorten är anslutna till grafikkorten, utan att processorn befinner sig i vägen, kommer rack-till-rack-trafik aldrig att vidröra värdlänken.

Det tredje är skalbarhet, den struktur som gör Helios till ett verkligt rackbaserat system. Varje GPU har 36 UALoE-länkar som kör UALinks minnessemantik över ESUN Ethernet, där varje länk klarar 400 Gb/s, vilket ger upp till 3.6 TB/s dubbelriktad bandbredd per GPU. Dessa länkar går ut genom baksidan av lådan mot switchfacken och transporterar load-store-trafiken som sammanfogar de 72 GPU:erna till en delad minnespod.

Växelbricka

Nästa steg är switchfacken, och det mest slående med dem är hur ordinärt deras kisel är. Var och en av de 6 facken rymmer två Broadcom Tomahawk 6 ASIC:er, samma handels-Ethernet-switchchip som hyperscalers använder i deras leaf-spine-nätverk, och var och en har 512 banor på 200G.

Varje GPU skickar 3 UALoE-länkar (varje UALoE-länk är 2x 200G-banor) till var och en av de 12 switcharna, med 144 länkar som lämnar varje datorbricka genom de bakre kabelkassetterna. Varje Tomahawk avslutar därför 216 länkar med 400 Gb/s, vilket flyttar 21.6 TB/s dubbelriktad bandbredd, medan varje GPU behåller sina fulla 36 länkar (72x 200G-banor) och 3.6 TB/s. Switcharna behöver inget exotiskt för att klara detta: UALoEs inkapsling är ett vanligt L2-protokoll, vidarebefordran bygger på statisk MAC-programmering som Ethernet-kisel har erbjudit i två decennier, och flödeskontroll är standardprioriterad flödeskontroll.

Med en enda nivå uppstår aldrig hela klasser av datacenteröverbelastningsproblem: det finns ingen flernivåinkastning, och varje GPU har exakt ett hopp med fast latens från varandra. Jämfört med ett direkt mesh-nätverk låter den switchade metoden också ett enda flöde göra anspråk på en hel vägs bandbredd när en arbetsbelastning behöver det, och håller varje GPU på samma avstånd. Därför behöver schemaläggning aldrig tänka på lokalitet, och ger varje länk samma felskydd.

Feltolerans

Helios behandlar hårdvarufel som en designinput. I den här skalan går det alltid sönder något: en trasig kabel, ett tappat paket, en switch som dras ut för en firmwareuppdatering, ett datorfack som dör helt. Strukturen är byggd så att ingen av dessa händelser dödar ett jobb. Tappade paket återställs genom omsändning, och när en länk, kabel eller switch fallerar omdirigeras trafiken automatiskt runt den efter en kort paus, där arbetsbelastningen fortsätter på den bandbredd som finns kvar istället för att starta om från en kontrollpunkt.

12-planstopologin är det som gör degraderingen graciös, och 3-vägsstrimningen anger stegstorleken. Om man förlorar 1 av de 3 länkarna som en GPU kör till en switch, behåller det planet två tredjedelar av sin bandbredd. Om man förlorar en hel Tomahawk, ger varje GPU upp 1/12 av sin uppskalningsbandbredd medan allt-till-all-funktionen fortsätter att fungera över de andra 11 planen. Även om man förlorar en hel switchbricka, kostar 2 av de 12 switcharna, varje GPU en sjättedel av sin bandbredd utan att bryta anslutningen, eftersom ingen GPU är beroende av någon enskild switch för att nå en annan. Som jämförelse sprider Vera Rubin NVL72 varje GPU över 36 NVSwitch 6 ASIC:er i 9 bricker, så ett switch-bracket-fel där kostar närmare en niondedel. NVIDIA köper mindre degraderingssteg med 3 gånger så många switch-ASIC:er; AMD motsätter sig att 12 switchar med högre radix innebär färre komponenter, kablar och kontakter som går sönder från första början. För en träningsperiod mätt i veckor är skillnaden mellan att förlora en sjättedel av tygets bandbredd och att förlora jobbet hela rackets ekonomi.

Virtuella poddar

Samma maskineri som partitionerar tygstrukturen runt fel kan partitionera den med flit. AMD kallar konstruktionen Virtual Pods, eller vPods, och enheten är beräkningsnoden: vilken kombination som helst av rackets 18 4-GPU-noder kan inhägnas till en isolerad pod, från 1 nod för en liten hyresgäst till större delen av rackstrukturen för ett stort träningsjobb. Isoleringen upprätthålls i tygstrukturens hårdvara, under vad en schemaläggare bestämmer. En vPod är knuten till sin hyresgäst; andra poddar har ingen åtkomst till dess minne eller dess trafik, och linjehastighetskrypteringen AES-256-GCM på varje UALoE-länk, med stöd för kundägda klusternycklar, håller en hyresgästs tensorer ogenomskinliga för nästa. En gäst-VM som sträcker sig över flera GPU:er har sin säkerhetsdomän utökad transparent över dem, utan krav på att lita på värdoperativsystemet. NVIDIA löser samma problem på sina NVL72-rack genom att dela upp NVLink-domänen i partitioner, där sin IMEX-tjänst förmedlar vilka noder som kan exportera och importera minne till varandra; vPods är UALoE-världens motsvarighet, så operatörer som kommer från GB200- eller GB300-flottor kommer att tycka att konceptet är bekant.

Om en beräkningsbricka kraschar stannar explosionsradien vid sin vPod: den arbetsbelastningen startar om från kontrollpunkten medan alla andra pods körs orörda, och hyresgästgränsen fungerar även som en felgräns. Partitioneringshistorien kapslas också hela vägen ner, eftersom en enda MI455X kan delas upp i så många som 8 virtuella SR-IOV-maskiner så att samma rack kan betjäna 1 kund som kör alla 72 GPU:er som en pod eller så många som 576 GPU-slice-hyresgäster i extremfallet, med hårdvaruisolering på varje nivå i den hierarkin.

Ledningsplanet

Allt detta körs av en dedikerad programvarustack som följer samma öppenhetstes som hårdvaran. AMD Fabric Manager (AFM) är kontrollplanet: den upptäcker och provisionerar 72-GPU-strukturen med zero-touch-uppstart, så att starta racket räcker för att alla 72 GPU:er ska aktiveras, validerar sedan kabelkassettens kablage mot monteringsfel, delar upp racket i vPods och koordinerar omdirigeringen och återställningen som beskrivs ovan. Det finns inget dedikerat hanteringsfack. AFM körs på switchfackens egna hanteringsprocessorer som 3 redundanta instanser utspridda över de 6 facken med en distribuerad databas mellan dem, så att förlora ett switchfack gör ingenting med kontrollplanet, och ett norrgående REST API exponerar strukturen för klusterstyrenheter som hanterar många rack.

Under huven lånar AFM sina rörmokeri från molnbaserade system, byggda på standardstyrenheter i Kubernetes-stil med agenter på varje fack, och hanterar de fabric-detaljer som användarna aldrig vill se, ner till att tilldela accelerator-ID:n som UALink använder för att adressera varje GPU. Det är också rackets observerbarhetslager. En enda instrumentpanel spårar GPU- och fabric-utnyttjande, länkhälsa och felhändelser; när något går sönder visar den den pågående åtgärden och utlöser varningar som operatörer kan koppla in i sina egna verktyg. Skärmdumpen ovan visar AFM som övervakar ett Helios-kluster i AMD:s egna labb. Hanteringen fungerar in-band eller out-of-band, så diagnostik och konfiguration stör aldrig körda arbetsbelastningar. Switcharna under AFM kör ett nätverks-OS byggt på SONiC, NOS med öppen källkod, och AMD säger att deras UALoE-tillägg kommer att uppströmmas och exponeras via standard gNMI API:er. Ovanför racket hanterar en Rack Infrastructure Manager nod- och switchlivscykel, strömförsörjning och läckagedetektering, och en Cluster Controller ansluter Helios till Kubernetes och Slurm för schemaläggning.

Helios vs. NVIDIA Vera Rubin NVL72

Så låt oss titta på hur detta står sig i jämförelse med NVIDIA-erbjudandet som Helios faktiskt kommer att möta på marknaden: Vera Rubin NVL72.

Rackmetrik	AMD Helios	Vera Rubin NVL72
GPUs	72 MI455X	72 Rubin
CPU: er	18 Venedig	36 Vera
HBM-kapacitet	31TB	20.7TB
HBM-bandbredd	1.7 PB/s	1.58 PB/s
Uppskalning per GPU	3.6 TB/s	3.6 TB/s
Rackuppskalning	260 TB/s	260 TB/s
Skalbarhet per GPU	2,400 Gb / s	1,600 Gb / s
Skalbara switchar	12 Tomahawk 6	36 NVSwitch 6
Rackformat	Dubbelbred ORW	Enkelbred MGX

På pappret lutar poängtavlan åt AMD: 50 % mer HBM, samma 3.6 TB/s uppskalning per GPU från en tredjedel så många switch-ASIC:er, och 50 % mer skalbar bandbredd per GPU. AMD:s interna tester förvandlar dessa specifikationer till ett prestandakrav, vilket ger 10 till 15 % fler tokens per sekund per GPU på Kimi K2 Thinking och upp till 30 % fler tokens per dollar. Det är AMD:s siffror jämfört med NVIDIA:s publicerade siffror, inte oberoende mätningar, men de sätter ribban som AMD förväntar sig att bli bedömd efter. De mer intressanta skillnaderna döljer sig i hur varje design kopplar sina GPU:er till omvärlden.

Börja med skalbarhet. MI455X:s nätverkskort hänger direkt från grafikkortet. Enligt SemiAnalysis gör inte Rubins det: enligt SemiAnalysis saknar paketet PCIe för att mata båda ConnectX-9-nätverkskorten, så de hänger istället från Vera-processorn, och GPU-trafiken tar den långa vägen runt: Rubin till NVLink-C2C till Vera till PCIe till ConnectX-9. Omvägen kostar en hel del latens och sätter C2C-länken i dubbel belastning. Med beräkning, värdtrafik och nätverk kopplade samtidigt går en del av Veras C2C-bandbredd till att bära nätverksnyttolasten, och den effektiva värdbandbredden som en grafikkort ser sjunker under den genomsnittliga gränsen på 1.8 TB/s.

Bandbreddsmatematiken förvärrar det hela. Varje MI455X utökar skalbarheten med 2 400 Gbit/s till Rubins 1 600, så Helios har mer nätverk per FLOP. AMD:s simuleringar av en träningskörning med 8 000 GPU:er tillskriver det tredje nätverkskortet cirka 13 % snabbare slutförande av jobb.

Rubin slår tillbaka på lagringsområdet, och anledningen är återigen var nätverkskortet sitter. ConnectX-9 har en inbyggd PCIe-switch, så NVMe kan hänga direkt från nätverkskortet och en GPU kan hämta data över GPUDirect-lagring utan att röra processorn. MI455X har ingen motsvarighet: dess lagring hänger från Venice-värden, så allt GPUDirect-format måste korsa processorn och komma tillbaka över Infinity Fabric-länken. AMD optimerade nätverksvägen och betalade för den på lagringsvägen; NVIDIA gjorde motsatt byte. Vilket som spelar större roll beror på om en arbetsbelastning är bunden till att flytta aktiveringar mellan GPU:er eller strömma data från disk.

Vad kunderna kan ändra

Kort sagt, allt ovan beskriver AMDs referensdesign, och flera av siffrorna är våningar som kunderna kan bygga förbi. Det mest uppenbara fallet är värdprocessorn. Rubins Vera levereras i en fast konfiguration; Venice i ett Helios-fack är en standard SP7-komponent med sockel, och AMD bekräftade att alla Venice SKU-paket som ingår utan Helios-specifik anpassning. Referensfacket använder 96-kärnig 5 GHz-komponent eftersom enkeltrådad hastighet håller GPU:erna matade. Ändå hindrar ingenting en kund från att konfigurera sin version med 256-kärnig flaggskeppsmodell, eller Venice-X med dess 1 152 MB staplade L3 för cache-hungrig förbehandling.

Minne och nätverk följer samma socket-och-kortplats-logik. Referensplanet på 1 TB DRAM är 16 blygsamma 64 GB RDIMM-minnen; tätare DIMM-minnen tar ett fack upp till 4 TB, och MRDIMM-12800 låser upp Venices fulla 1.6 TB/s. På nätverkssidan kan en build gå från 3 NIC-kort per GPU till 2 över vanlig PCIe Gen 6; varje Vulcano-port kan köras som 1x800G, 2x400G, 4x200G eller 8x100G mot Tomahawk 5- eller Tomahawk 6-strukturer, och P4-pipelinen lämnar transporten, RoCEv2, MRC eller något proprietärt, som operatören väljer. Även hanteringsplanet är utbytbart, eftersom switchens NOS är öppen källkod SONiC och AFM exponerar hela strukturen genom sitt norrgående API.

Även strömförbrukningen följer sockeln. NVIDIAs superchips delar ett spektrum: Vera är en 450W-komponent med en begränsad krets, och senare generationer slösar ström mot grafikkorten under belastning. AMD har inte sagt om referensdesignen begränsar eller flyttar värddatorns strömförbrukning, men med AMDs design ligger frågan hos kunden, och de kan anpassa systemet med högre strömförbrukning utan strömsnålhet.

Värdlänkens PCIe-grundläggande funktioner, upppackade tillbaka i beräkningsfacksektionen, öppnar en sista dörr, denna öppet spekulativ. Venice stöder 2P-konfigurationer, och utvalda AI-värdplattformar kan köra 2P med upp till 160 användbara PCIe-banor genom att byta xGMI-bredd mellan socklar för I/O. En kund skulle kunna bygga ett två-socket-fack för att matcha NVIDIAs 1:2 CPU-till-GPU-förhållande, eller justera xGMI-länkarna för att öka effektiv CPU-till-GPU-bandbredd. Ingenting tyder på att någon bygger det idag, och inget av det minskar det råa gapet till NVLink-C2C på 1.8 TB/s. Den verkliga poängen är vem som har pennan: på Helios är värden, dess minne, dess kraft och potentiellt dess topologi kundens beslut, och NVIDIAs superchip ger kunden ingen penna alls.

Salina DPU

Nu tillbaka till frontend-nätverket som vi sköt upp tidigare. Salina, AMD:s tredje generationens Pensando DPU, är ett 400G-kort med en helt P4-programmerbar dataväg, vilket innebär att en ny inkapsling, telemetri-krok eller transport är en firmwareuppdatering, som appliceras live utan att trafiken förloras. Leveranstjänsterna täcker redan frontend-checklistan: SDN med VXLAN eller NVGRE, en tillståndskänslig brandvägg som skalar till miljontals regler, linjehastighets-IPsec, PSP, DTLS eller anpassad kryptering, NAT och lastbalansering. Det är också den mest beprövade kiseln i racket. Pensando DPU:er har kört hyperskalare sedan 2019; Salina leder idag distributioner hos Microsoft, Oracle och IBM; Oracle tillskriver linjen en 5× SDN-vinst, och en hyperskalare återtog 22 CPU-kärnor per server genom att avlasta I/O till den.

Lagring är den andra akten. Salina exponerar NVMe-over-Fabrics-enheter för värden och virtualiserar fjärranslutna SSD-pooler över TCP eller RDMA med kryptering, digests och komprimering gjorda på kortet. På Helios lägger den till ett knep från agenteran: en kontextminnesmotor presenterar en emulerad KV-enhet, så överfylld KV-cache spills till CPU DRAM, lokal SSD eller fjärrlagring och strömmar tillbaka till HBM med linjehastighet istället för att beräknas om. Som noterats i Rubin-jämförelsen saknar MI455X GPUDirect-lagring; denna KV-avlastning är AMD:s delvisa svar på den trafik som serveringen bryr sig mest om.

Det är också där våra reservationer ligger. Bandbreddsgapet är tydligt: ​​Salina är ett 400G-kort, och BlueField-4 som levereras till Vera Rubins rack fördubblar det till 800G med en 64-kärnig Grace-processor och en medföljande ConnectX-9. Programvarugapet är mer diskutabelt men verkligt. NVIDIAs DOCA ger utvecklare containerbaserade, förbyggda tjänster programmerbara i vanligt C och C++; P4 är ett specialiserat dataplanspråk som de flesta team aldrig har rört vid. Jämförelsen är inte "DOCAs katalog kontra ren P4", eftersom Salina levererar sina huvudtjänster kompletta, och de hyperskalare som driftsätter det valde det delvis för att P4 låter nya protokoll som MRC landa i firmware före någons kiselcykel. Den verkliga skillnaden är vem programmerbarheten betjänar. Salinas flexibilitet är ett vapen för AMD och P4-flytande hyperskaleteam; DOCA är en verktygslåda som en vanlig företagsutvecklare kan plocka upp. För den breda marknaden är NVIDIAs programvaruintroduktion enklare, och AMD vet det.

ROCm.AI

På tal om mjukvara så sparade AMD ett av sina större tillkännagivanden till själva stacken. ROCm.AI, som kommer i augusti, är AMDs försök att göra GPU-plattformen agentisk från grunden. AI Skills kopplar in ROCm i de kodningsagenter som utvecklare redan använder, Claude, Codex, Cursor och Gemini, så installation, servering och felsökning på Instinct sker i enkel text. Hyperloom är den djärvare delen: en optimerare utan människa i loopen som profilerar en arbetsbelastning, finjusterar dess serveringkonfiguration, skriver om GPU-kärnor och validerar resultaten medan operatören sover. AMD säger att de kontinuerligt optimerar cirka 14 000 modeller idag, och en livedemo pressade ut 38 % mer dataflöde ur MiniMax M3. Under agenterna ger FlyDSL nästan-assembleringskontroll till Python, ROCm går över till en fast 6-veckors releasekadens, och AMD hävdar att ROCm.AI levererar en genomsnittlig 3.3× inferens och 2.4× träningsvinst jämfört med ROCm 7 på identisk hårdvara. ROCm 7 har redan visat en verklig förbättring; nu satsar AMD på AI för att öka takten.

Den viktigaste bilden i programvarusessionen handlade förmodligen om hårdvara. AMD betonade eftertryckligt att varje siffra på den mättes, med undertonen att MI455X-kisel är uppe, igång och snabbt under ROCm idag. Siffrorna: 20 TB/s i FP8 MLA-avkodning, 20 PFLOPS FP4-beräkning, 3.2 TB/s bandbredd vid uppskalning och 190 GB/s utskalning. I frågestunden erkände AMD att FP4-resultatet är en max-achievable-matmul-FLOPS (MAMF)-mätning, körd med den matrisform som smickrar enheten mest, vilket är standardpraxis för denna klass av riktmärken. Det är också ett djärvt avslöjande: AMD medger öppet att MI455X upprätthåller cirka 50 % av sitt maximala MXFP4-betyg på 40.26 PFLOPS, ett tal som de flesta leverantörer skulle begrava.

AMD kallar detta den högsta demonstrerade beräkningsförmågan av alla acceleratorer på marknaden, och det är där saltkornet kommer in. AMDs FP4 är OCP MXFP4; NVIDIAs är NVFP4. De är olika recept: NVFP4 tillämpar en fraktionerad FP8-skala på varje 16-elementsblock plus en tensornivåskala ovanpå, medan baslinje-MXFP4 använder en grövre potens-av-två-skala per 32 element, så en NVFP4 FLOP utför mer arbete än en MXFP4 FLOP. CDNA 5 kan också tillämpa fraktionerad skalning på MXFP4, men AMD sa inte vilket recept mätningen använde. En Rubin MAMF-körning och en MI455X MAMF-körning mäter inte samma matematik, så FP4-jämförelser mellan leverantörer avgörs endast på applikationsnivå: tokens per sekund med matchad noggrannhet. Uppmätta slag projiceras, men dessa siffror läses ärligt mot AMDs egen tidigare generation, där 3× till 4× vinsterna är entydiga.

Det finns också en motvikt till AMDs fördel. Dessa är tidiga ROCm.AI-resultat på helt ny kisel, så om något underskattar de vad en handjusterad produktionsdistribution kommer att uppnå. Den riktiga domen kommer när dessa rack når hyperscaler-golv.

Utgående Tankar

Helios är det mest kompletta systemet AMD någonsin har levererat, och det första som möter NVIDIA direkt i rackskala istället för chip för chip. Poängkortet visar hur AMD ser ut på de områden som avgör AI-kapaciteten idag: 50 % mer HBM per GPU, skalbarhet med Rubin, 50 % mer skalbar bandbredd och, enligt AMDs egen modellering, upp till 30 % fler tokens per dollar. Lika viktigt är hur de hamnade där: Tomahawk-switchar, öppna standarder från nummerformat till kabinett och en socket-ansluten värd som lämnar den slutliga konfigurationen i kundens händer. NVIDIA behåller genuina fördelar i C2C-värdlänken, DPU:n och dess programvaruuppstart, men för första gången gynnar det övergripande hårdvaruargumentet på pappret AMD.

Och köparna håller med. OpenAI, Meta, Anthropic, Microsoft och Oracle är bland de företag som AMD säger anammar Helios, och AMD framhåller att racken är i produktion idag. I NVIDIAs fotspår är färdplanen nu en årlig kadens: den CDNA 6-baserade MI500-serien anländer 2027 med nästa generations HBM plus koppar och optisk sammankoppling, och MI600-serien är redan under utveckling för 2028.

Vilket återstår mjukvara, och för första gången på flera år avslutar vi inte en AMD GPU-historia med den varningen. ROCm 7 täckte verkliga luckor, ROCm.AI anländer i augusti med uppmätta vinster på toppen, och lanseringskadensen är nu en fast sex veckor. Det spelar också roll vem som köper. Labben och hyperscalers som skriver på dessa avtal samdesignar med AMD och anställer tillräckligt många ingenjörer för att åtgärda eventuella problem de stöter på. Företag som behöver en nyckelfärdig stack är en annan historia, och den marknaden förblir NVIDIAs för tillfället. Men Helios byggdes för hyperscalers och AI-labb, och för dem är hårdvaran redo, mjukvaran håller jämna steg och racken levereras. AMD har aldrig varit i en starkare position.