AMD organiseerde zijn grootste Advancing AI-evenement tot nu toe, waarbij schaalbaarheid centraal stond. Het bedrijf introduceerde de Instinct MI455X GPU, het Helios-rack met 72 GPU's en de 6e generatie EPYC Venice CPU's. De MI455X beschikt over 432 GB HBM4-geheugen, een toename van 50% ten opzichte van NVIDIA's B300 of Rubin, met een geheugenbandbreedte van 23.3 TB/s en tot 40.26 PFLOPS MXFP4-rekenkracht. Een compleet Helios-rack schaalt deze cijfers met 72, wat resulteert in 2.9 exaFLOPS FP4, 31 TB HBM4-geheugen, een geheugenbandbreedte van 1.7 PB/s, 260 TB/s opschaling en 43 TB/s uitschaling naar het datacenter. Op alle fronten streeft AMD ernaar de industrie te leiden. Dit artikel behandelt de MI455X en Helios; de lancering van Venice wordt in een aparte analyse besproken.

Het andere thema is openheid, die elke laag bereikt, te beginnen met de interconnectie. Binnen het rack delen alle 72 GPU's geheugen via UALink, een open consortium-architectuur die AMD via Ethernet gebruikt als UALink-over-Ethernet (UALoE). Zodra het verkeer het rack verlaat, gaat het verder via Ultra Ethernet, de open schaalbare standaard van het Ultra Ethernet Consortium. Dezelfde Instinct-technologie wordt door de hele stack heen gebruikt. De wiskundige berekeningen met lage precisie maken gebruik van de open MXFP4-, MXFP6- en MXFP8-dataformaten van OCP, en het rack waarin alles is ondergebracht, is gebouwd volgens het Open Rack Wide-ontwerp van het Open Compute Project. Zelfs de software wordt openlijk ontwikkeld, met de compiler, runtime en bibliotheken van ROCm die allemaal in broncode beschikbaar zijn.

Omdat alle specificaties in de stack vandaag de dag gepubliceerd en downloadbaar zijn, kan een hyperscaler Helios als blauwdruk gebruiken en een aangepaste versie bouwen die is afgestemd op de eigen faciliteiten en workloads, waarbij netwerk-, stroomvoorzienings- of beheercomponenten naar wens kunnen worden aangepast. Dit betekent dat alles wat we in dit artikel bespreken, gebaseerd is op het referentieontwerp dat AMD heeft gepresenteerd; de units die klanten implementeren, kunnen aanzienlijk verschillen. De belangstelling is al groot: AMD meldt dat OpenAI, Meta, Anthropic, Microsoft , Oracle en vele anderen Helios al gebruiken.

AMD Instinct MI455X: het vlaggenschip van de CDNA 5-processor

De MI455X is de eerste CDNA 5-accelerator en bestaat uit 320 miljard transistors. De MI455X bevat acht Accelerator Complex Dies (XCD's) gebouwd op TSMC's N2-node, plus twee I/O-dies en twee Fabric- en Cache-dies op de N3-node, en twaalf HBM4-stacks. Het is de grootste chip die ooit is gebouwd op TSMC's CoWoS-L-verpakkingsmateriaal.

Geheugen is een van de belangrijkste kenmerken. Die twaalf HBM4-stacks hebben een totale capaciteit van 432 GB met een snelheid van 23.3 TB/s. HBM4 verdubbelt de interface per stack naar 2,048 bits, en de twee Fabric- en Cache-chips voegen daar nog eens 192 MB L2-geheugen aan toe met een snelheid van 54 TB/s.

Ook op het gebied van I/O doet de MI455X geen concessies. Hij beschikt over 72 UALoE-lanes voor een bidirectionele bandbreedte van 3.6 TB/s naar de rest van het rack, 256 GB/s bidirectionele Infinity Fabric naar de host-CPU en de keuze uit twee PCIe Gen6 x16-links of drie AMD AI-NIC's voor schaalvergroting.

Vergeleken met de chip die hij vervangt en het aanbod van NVIDIA, presteert de MI455X op alle fronten beter.

Specificaties	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
Architectuur	CDNA 5	Rubin	CDNA 4	Blackwell-ultra
Transistors	320B	336B	185B	208B
HBM-capaciteit	432GB HBM4	288GB HBM4	288 GB HBM3E	288 GB HBM3E
HBM-bandbreedte	23.3 TB/s	22 TB/s	8 TB/s	8 TB/s
Opschaling per GPU	3.6 TB/s	3.6 TB/s	1.08 TB/s	1.8 TB/s
Schaalvergroting per GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
CPU-GPU-koppeling	256 GB/s Infinity Fabric	1.8 TB/s C2C (1:2)	PCIe 5	900 GB/s C2C (1:2)

 

Laten we beginnen met waar AMD de leiding neemt. Met 432 GB heeft de MI455X 50% meer HBM-geheugen dan de MI355X, B300 of Rubin, die allemaal maximaal 288 GB hebben. De geheugenbandbreedte van 23.3 TB/s is ook de hoogste in deze groep. De schaalbaarheid is vergelijkbaar: 2,400 Gbit/s per GPU tegenover 1,600 Gbit/s voor Rubin en 800 Gbit/s voor B300. Elke MI455X heeft 50% meer netwerkbandbreedte dan zijn naaste concurrent.

AMD heeft eindelijk ook op het gebied van schaalvergroting een inhaalslag gemaakt. NVLink is al jaren de toonaangevende GPU-fabric en was twee generaties lang de enige manier om topprestaties te behalen op MoE-modellen met WideEP. UALoE dicht die kloof in één generatie: met 3.6 TB/s evenaart de MI455X de NVLink 6 van Rubin. NVIDIA behoudt echter nog steeds een duidelijke voorsprong in de hostlink. Eén Vera CPU stuurt twee Rubin GPU's aan via een C2C-verbinding van 1.8 TB/s, terwijl elke MI455X met zijn Venice-host communiceert via een Infinity Fabric-link van 256 GB/s. Dat verschil bepaalt hoe de twee rackarchitecturen later in dit artikel van elkaar verschillen.

Op het gebied van pure rekenkracht is de MI455X op alle fronten de beste, met één kanttekening: AMD's OCP MX-formaten en NVIDIA's NVFP4 schalen anders, dus beschouw dit als geadverteerde piekwaarden; de daadwerkelijke prestaties zijn een ander verhaal.

Formaat	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	315 TF	130 TF	157.3 TF	75 TF

 

Ten opzichte van de MI355X levert de MI455X vier keer de MXFP4- en MXFP8-doorvoer en twee keer de FP16/BF16- en FP32-snelheden. De vergelijking met NVIDIA is in twee delen op te splitsen. Ten opzichte van de B300 levert de MI455X 2.7 keer de FP4-doorvoer en vier keer de FP6- en FP8-snelheden. Rubin is de relevante benchmark en daarop heeft de MI455X een consistent voordeel: 15% bij FP4, 15% bij FP6 en FP8 en 26% bij FP16/BF16. Het grootste verschil is te zien bij FP32, waar de 315 TF van de MI455X ongeveer 2.4 keer zo hoog is als de 130 TF van Rubin en meer dan vier keer zo hoog als de 75 TF van de B300. Dat cijfer komt uit de HPC-achtergrond van Instinct en is nog steeds relevant voor AI-werk, aangezien mastergewichten, accumulatie met hoge precisie en wetenschappelijke workloads nog steeds boven de low-bit formaten draaien.

Binnenin CDNA 5

Laten we eens nader bekijken hoe de architectuur in elkaar zit en wat deze toonaangevende prestaties mogelijk maakt.

Van XCD naar SIMD

Door de hiërarchie van boven naar beneden te bekijken, wordt duidelijk hoeveel er opnieuw is opgebouwd, omdat CDNA 4 de compute-die op een heel andere manier organiseerde. Op de MI355X bevatte elke XCD 32 actieve Compute Units en een eigen L2-cache van 4 MB die het dataverkeer van de die bundelde voordat het de Infinity Fabric bereikte. CDNA 5 behoudt de acht XCD's, maar herbouwt de inhoud ervan, waarbij de structuur en terminologie zijn overgenomen van AMD's RDNA-grafische lijn. Elke MI455X XCD is nu opgesplitst in twee Shader Engines. Elke Shader Engine bevat fysiek 17 Work Group Processors, waarvan er 16 zijn ingeschakeld en één reserve is voor de opbrengst. De L2-cache per XCD is volledig verdwenen, van de compute-die naar de basisdies eronder verplaatst, waar het geheugengedeelte weer in terechtkomt.

De belangrijkste berekeningen zijn niet veranderd. Een XCD levert nog steeds 32 actieve eenheden en de GPU heeft er nog steeds 256, hetzelfde aantal als de MI355X als rekeneenheden had. De viervoudige toename in doorvoer bij lage precisie komt niet door het toevoegen van uitvoereenheden; alles komt doordat elke WGP meer werk per cyclus verricht, en de herontwerp is dan ook gericht op de WGP.

Een WGP is opgebouwd uit vier 32-lane SIMD-eenheden en vier scalaire eenheden die een constante cache delen. De grootste verandering is de manier waarop threads erdoorheen stromen: de overstap van Wave64 naar Wave32. Een wave is de bundel threads die een SIMD synchroon uitvoert. CDNA 4 gebruikte Wave64, waarbij elke wave van 64 threads door een 16-lane SIMD werd geleid over vier klokcycli. CDNA 5 laat de ondersteuning voor Wave64 volledig vallen, de eerste Instinct-architectuur die dit doet, en draait Wave32 native. Een wave van 32 threads wordt één-op-één toegewezen aan elk van de vier 32-lane SIMD-eenheden van de WGP, wordt in één cyclus uitgevoerd en zorgt ervoor dat elke SIMD elke klokcyclus een nieuwe instructie start.

Smallere, snellere waves veranderen de manier waarop werk door de machine beweegt. De instructielatentie daalt omdat een wave eerder klaar is. Branch divergence kost minder, omdat een take-or-not split nu maximaal 32 threads blokkeert in plaats van 64. De druk op registers neemt af, waardoor meer waves actief blijven, tot 64 per WGP tegenover de helft daarvan voorheen. Dit geeft de scheduler meer kleine, onafhankelijke taken om geheugenlatentie te maskeren. Wave32 maakt het ook gemakkelijker om verschillende tegelgroottes voor tensorbewerkingen op de hardware toe te wijzen, wat de kernelontwikkeling vereenvoudigt.

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.

De geheugenhiërarchie

Achter de uitvoerende eenheden bevindt zich een hiërarchie die van boven naar beneden is herbouwd, en de duidelijkste manier om dit te zien is door het niveau voor niveau te vergelijken met de MI355X.

Niveau	MI455X (CDNA 5)	MI355X (CDNA 4)
Vectorregisters	128 KB per SIMD; 1,024 per thread; 2× bandbreedte	128 KB per SIMD; 256 KB per thread
WGP / CU lokale winkel	384 KB (320 KB LDS + 64 KB vectorcache); 2× bandbreedte	192KB (160KB LDS + 32KB L1)
Instructie-/constante cache	64KB + 16KB per WGP	64KB gedeeld per twee CU's + 16KB
L2	2 × 96 MB op de FCD's; 54 TB/s	8 × 4MB, één per XCD
Geheugen-cache	Uitgeschakeld	256 MB oneindige cache
HBM	432 GB HBM4; 12 × 2,048-bits stacks; 23.3 TB/s	288 GB HBM3E; 8 × 1,024-bits stacks; 8 TB/s

 

De cachelagen zijn waar de architectuur van vorm veranderde. CDNA 4 had een drielaags ontwerp: de privé 4MB L2-cache van elke XCD bundelde het verkeer van die chip voordat het de Infinity Fabric bereikte, en een gedeelde 256MB Infinity Cache in de I/O-chips bevond zich aan de geheugenzijde vóór de HBM-controllers. CDNA 5 verwijdert beide lagen en vervangt ze door twee onafhankelijke 96MB L2-caches, één per Fabric en Cache Die, elk opgebouwd uit 96 blokken van één megabyte. De lay-out is verticaal: vier XCD's, oftewel acht Shader Engines, zijn hybride verbonden bovenop elke FCD, die ook zes van de twaalf HBM4-sites bevat, en de twee FCD's komen samen in een centrale Infinity Fabric in het midden van de behuizing, met de I/O-chips aan beide uiteinden. Elke L2-cache kan elk adres in het GPU-geheugen bevatten en de Infinity Fabric zorgt ervoor dat het paar coherent blijft. De door AMD opgegeven reden is bandbreedte: één van deze caches levert op zichzelf al 1.5 keer de totale bandbreedte van de gehele Infinity Cache van de MI355X, de combinatie levert drie keer zoveel, en geen van dat verkeer hoeft de chip-naar-chip-scheiding te passeren die de oude lay-out beperkte.

De cache krijgt er ook nieuwe taken bij. Apparaatbrede atomaire bewerkingen, die voorheen buiten de fabric werden uitgevoerd, worden nu binnen de L2-cache uitgevoerd met veel hogere snelheden, terwijl systeembrede atomaire bewerkingen zoals voorheen in de Infinity Fabric blijven. Een nieuwe broadcast-arbiter completeert het geheel door tensor-tegels naar elke WGP te multicasten die op dezelfde matrix samenwerkt. Hierdoor is een gewicht dat eenmaal wordt opgehaald voldoende voor al deze WGP's, wat de effectieve leesbandbreedte tot wel vier keer vergroot.

De bovenstaande niveaus schalen mee. De lokale opslag per WGP verdubbelt naar 384 KB, verdeeld over 320 KB LDS en een vectordatacache van 64 KB, met een tweemaal zo hoge leesbandbreedte. Dit biedt ruimte voor FlashAttention om query's, sleutels, waarden en gedeeltelijke reducties op de chip op te slaan in plaats van de volledige aandachtmatrix uit te schrijven. Het ondersteunt ook gecombineerde MoE-kernels om de routingstatus en accumulatoren lokaal te houden. Het vectorregisterbestand behoudt zijn capaciteit van 128 KB per SIMD, maar is opnieuw georganiseerd voor Wave32. Dit resulteert in twee keer zoveel waves, stelt een enkele thread in staat om 1,024 registers te adresseren in plaats van 256, en verdubbelt de registerbandbreedte om de bredere SIMD's en hun co-executie-eenheden te voeden.

De scalaire kant wordt herbouwd om overeen te komen, met 128 scalaire registers per wave en 32 KB per WGP. Aan de basis gaat HBM4 van acht 1,024-bits stacks naar twaalf 2,048-bits stacks, waardoor de capaciteit met 50% toeneemt tot 432 GB en de bandbreedte met een factor 2.9 toeneemt tot 23.3 TB/s via een interface met 192 kanalen.

De aanvoer van dit alles wordt verzorgd door een nieuwe Tensor Data Mover, één per WGP, die tensor-tilingschema's tot vijf dimensies begrijpt en tiles asynchroon streamt tussen DRAM en de lokale opslag zonder tussenliggende register-staging. Overdrachten worden beschreven door descriptors die worden geladen vanuit de scalaire registers en in hardware worden gecontroleerd op grenzen voor de veiligheid. Multicast-loads worden ondersteund, waardoor de SIMD-eenheden nooit vastlopen in afwachting van een kopie of registers verbruiken voor de staging ervan. Het is CDNA 5's antwoord op de tensor-memory accelerators op recente NVIDIA-processors. Een reeks gebruiksfuncties completeert de voorkant van de machine: workgroup-clusters geven kernels expliciete controle over plaatsing en gelijktijdigheid voor data-sharing workloads, gesplitste en benoemde barriers stellen een producent in staat om voltooiing te signaleren en verder te gaan zonder te wachten op een antwoord van de consument, prefetchers op elk niveau van de hiërarchie zetten data klaar voor gebruik, en een herwerkte command front-end vermindert de latentie bij het opstarten en verzenden van kernels voor de korte kernels die dominant zijn in inferentie.

Het DMA-systeem is op dezelfde filosofie herbouwd. Software plant overdrachten in via DMA-front-ends, terwijl fysiek aanwezige back-ends naast de UALoE-links elk werkitem opsplitsen, de belasting ervan verdelen over alle beschikbare links en buffers rechtstreeks uit het geheugen halen in plaats van data over de chip naar een externe engine te transporteren. De back-ends reageren ook op congestie en tegendruk vanuit het opschaalnetwerk en vermijden overbelaste paden, zodat communicatiebibliotheken een evenwichtige netwerkbelasting krijgen zonder ooit de onderliggende topologie te hoeven begrijpen.

De GPU in segmenten verdelen: NPS en SR-IOV

De fysieke lay-out met twee L2-lagen levert nog een voordeel op wat betreft de manier waarop de GPU wordt gepartitioneerd. In NPS1 is de hele chip één NUMA-domein: adressen worden afwisselend verdeeld over alle twaalf HBM-stacks en beide helften voor een uniforme bandbreedte, de makkelijkste manier om te porteren en voor gelijkmatig verdeelde toegangspatronen. NPS2 splitst de GPU in twee NUMA-domeinen, elk met zes HBM-stacks, één Fabric- en Cache-Die en de daarop gestapelde XCD's. Elke geheugenreferentie blijft dan binnen zijn eigen helft en elk domein krijgt in feite een eigen L2-laag van 96 MB. Dat doet meer dan alleen het fysieke pad verkorten. Doordat er geen cachelijnen worden gedeeld tussen de helften, verdwijnt het Infinity Fabric-coherentieverkeer tussen de twee L2-lagen grotendeels, en AMD zegt dat dit resulteert in een lagere latentie en een betere efficiëntie voor NUMA-compatibele applicaties. CDNA 4 bood dezelfde brede afweging, waarbij NPS2 het verkeer binnen één I/O-chip hield, maar CDNA 5 verfijnt dit doordat hetgeen gelokaliseerd wordt nu de volledige L2-cache is in plaats van een deel van een buffer aan de geheugenzijde.

Compute partitioning stacks komen bovenop. De acht XCD's stellen de GPU in staat om op te starten als één, twee, vier of acht ruimtelijke partities, waarbij de 432 GB HBM wordt verdeeld in gelijke segmenten van 432, 216, 108 of 54 GB, ondersteund door acht tot één XCD per segment. Door partities te koppelen aan de NUMA-domeinen kan de runtime taken ruimtelijk verdelen en toewijzingen plaatsen, zodat een taak terechtkomt op de XCD's die zich het dichtst bij het geheugen bevinden. SR-IOV virtualiseert de partities vervolgens in maximaal acht hardware-geïsoleerde virtuele machines, waarbij de isolatie wordt afgedwongen in het geheugensysteem zelf, onafhankelijk van welke NUMA-modus actief is. De MI355X bood dezelfde opties voor één tot en met acht partities, dus de granulariteit is niet nieuw; wat CDNA 5 eronder toevoegt, is het private-L2-gedrag, en daarboven de rack-level Virtual Pods die in het Helios-gedeelte worden behandeld.

AMD Helios

Een enkele MI455X is al snel. Maar met deze lancering betreedt AMD de markt voor rack-scale en large-scale-up chips.

Fysiek gezien laat Helios de traditionele 19-inch en 21-inch racks achterwege en kiest voor Open Rack Wide, een formaat dat AMD samen met Meta heeft ontwikkeld tijdens OCP: een kast van 1.2 meter breed en 1.3 meter diep met 44 OU verticale ruimte. Binnenin bevinden zich de 72 GPU's in twee rijen van negen compute-trays, met de zes switch-trays ertussen gestapeld. Elke GPU-naar-switch-verbinding is via koperkabels door vier blind-mate kabelhouders aan de achterkant geleid, waardoor de trays eruit geschoven kunnen worden voor onderhoud zonder dat er kabels handmatig losgekoppeld hoeven te worden.

Het hele rack verbruikt 225 tot 245 kW, afhankelijk van de belasting, via een vloeistofgekoelde 50V-busbar. De achterste verdeelstukken pompen ongeveer 385 liter koelvloeistof per minuut vanuit het koelcircuit. De schakelkasten zelf zijn serieuze componenten: elk weegt ongeveer 170 kilogram en het plaatsen van de 1,728 differentiële aansluitingen in een schakelkast vereist een inbrengkracht van ongeveer 690 kilogram. Daarom lopen de nokkenhendels bijna over de volledige breedte van de kast.

De bouwstenen

Rekenlade

In het referentieontwerp is elke compute tray een op zichzelf staande node, opgebouwd rond 4x MI455X-modules en een hoogfrequente Venice SP7 CPU met 96 kernen die tot 5 GHz kan boosten. De 16 DIMM-sockets bevatten 1 TB DRAM in de vorm van 16 x 64 GB DDR5 ECC RDIMM's, met 5 E1.S NVMe-slots direct op de CPU. Het platform is geschikt voor veel meer: ​​de 16 geheugenkanalen van Venice ondersteunen een bandbreedte tot 1.6 TB/s, en met de 256 GB RDIMM's die momenteel de top van het DDR5-assortiment vormen, kan een socket met 16 kanalen en 1 DIMM per kanaal maximaal 4 TB aan geheugen bevatten.

In navolging van NVIDIA maakt de CPU via Infinity Fabric deel uit van het coherente geheugendomein in plaats van achter de GPU's te zitten als een gewone PCIe-host. AMD stelt dat de verhouding van 1:4 tussen CPU en GPU bewust is gekozen: de core zelf presteert beter dan de concurrentie. Volgens AMD's schattingen, gebaseerd op een eerlijke vergelijking, loopt de 5 GHz Zen 6-core ongeveer 20% voor op NVIDIA's Vera qua prestaties per core. Omdat de socket een standaard SP7 is, kunnen klanten die meer rekenkracht nodig hebben, elke Venice-variant tot en met het vlaggenschip met 256 cores gebruiken. Eén Venice-socket biedt bovendien veel meer DDR5-capaciteit dan een LPDDR-hostontwerp, en de geheugenbandbreedte is maximaal benut voor alle vier de GPU's via de Infinity Fabric-verbindingen.

Die Infinity Fabric-verbinding verdient een nadere blik. Tijdens een gesprek met George Cozma van Chips and Cheese over de verbinding tussen Venice en MI455X , suggereerde hij dat de coherente verbinding gebruikmaakt van de PCIe-lanes van de CPU, net zoals EPYC al jaren zijn xGMI-socketverbindingen via PCIe PHY's transporteert. De cijfers ondersteunen die theorie. PCIe Gen 6-signalen gaan met 64 Gb/s per lane, en een x16-verbinding met die snelheid komt neer op 128 GB/s in beide richtingen, precies de 256 GB/s bidirectionele snelheid die AMD per GPU noemt. Het blokdiagram in de CDNA 5-whitepaper zelf geeft de host Infinity Fabric-interface aan met 64 Gb/s per lane, de exacte Gen 6-signaalsnelheid. De theorie verklaart ook waarom elke Venice SKU probleemloos werkt: de 4 GPU's gebruiken 64 van de 128 Gen 6-lanes van de CPU, waardoor de rest vrij blijft voor DPU's, opslag en andere systeembehoeften.

Elke rekenmodule heeft drie afzonderlijke netwerken, elk voor een andere taak. Het meest gebruikelijke netwerk is de front-end: een enkele Pensando Salina 400G DPU verbindt de node met het reguliere datacenternetwerk, waar we later dieper op in zullen gaan.

Het tweede aspect is scale-out, het netwerk dat racks verbindt tot clusters. De eenvoudigste manier om dit te begrijpen is door het aantal SerDes te tellen. De scale-out van de MI455X kan gebruikmaken van PCIe Gen 6 met 64 Gb/s per lane of UALink128 met 128 Gb/s. Een Vulcano 800 NIC heeft ongeveer 128 Gb/s aan verbinding in beide richtingen nodig om de 800 GbE-poort te blijven voeden. Bij Gen 6-snelheden is daarvoor een volledige x16-link per NIC nodig, dus de GPU heeft 2 NIC's; bij de verdubbelde signaalsnelheid van UALink128 doet een x8-link hetzelfde werk op de helft van de SerDes, dus de GPU heeft er 3, wat de configuratie is waarmee Helios wordt geleverd. In beide gevallen is de UALink128-hop niets meer dan een privékabel tussen de GPU en de NIC; het netwerk zelf begint bij de Vulcano. Elke netwerkkaart stuurt een 800GbE-poort aan die UEC-compatibele transportprotocollen gebruikt, waaronder MRC, het multipath-protocol dat OpenAI samen met AMD en andere partners heeft ontwikkeld. Fysiek bevinden de netwerkkaarten zich op twee op maat gemaakte printplaten per tray, elk met 4 of 6 Vulcano ASIC's, overeenkomend met de configuraties van 2 per GPU en 3 per GPU. In de volledige configuratie zijn dat 12 netwerkkaarten per tray en een schaalbare bandbreedte van 2,400 Gb/s per GPU. En omdat de netwerkkaarten direct aan de GPU's zijn gekoppeld, zonder dat de CPU zich in het pad bevindt, komt het verkeer tussen racks nooit in contact met de hostverbinding.

Het derde aspect is schaalvergroting, de infrastructuur die van Helios een echt rack-schaalbaar systeem maakt. Elke GPU beschikt over 36 UALoE-links die de geheugenfunctionaliteit van UALink via ESUN Ethernet uitvoeren. Elke link is goed voor 400 Gb/s, wat neerkomt op een bidirectionele bandbreedte van 3.6 TB/s per GPU. Deze links verlaten de achterkant van de tray richting de switchtrays en transporteren het load-store-verkeer dat de 72 GPU's samenvoegt tot één gedeelde geheugenmodule.

Wissel van lade

Vervolgens de switch-trays, en het meest opvallende daaraan is hoe gewoon de gebruikte siliciumchips zijn. Elk van de 6 trays bevat 2 Broadcom Tomahawk 6 ASIC's, dezelfde commerciële Ethernet-switchchips die hyperscalers inzetten in hun leaf-spine-netwerken, elk met 512 lanes van 200G.

Elke GPU stuurt 3 UALoE-links (elke UALoE-link bestaat uit 2x 200G-lanes) naar elk van de 12 switches, waarbij 144 links elke compute-tray verlaten via de kabelcassettes aan de achterzijde. Elke Tomahawk beëindigt dus 216 links met een snelheid van 400 Gb/s, waarmee 21.6 TB/s aan bidirectionele bandbreedte wordt verplaatst, terwijl elke GPU zijn volledige 36 links (72x 200G-lanes) en 3.6 TB/s behoudt. De switches hebben niets bijzonders nodig om dit te realiseren: de encapsulatie van UALoE is een eenvoudig L2-protocol, het doorsturen is gebaseerd op statische MAC-programmering die Ethernet-chips al twintig jaar bieden, en de flow control is standaard prioriteitsflow control.

Met een enkele laag ontstaan ​​er geen problemen met datacentercongestie: er is geen multi-tier incast en elke GPU bevindt zich precies één hop met vaste latentie van elke andere GPU. In vergelijking met een direct mesh-netwerk maakt de switched-aanpak het bovendien mogelijk dat één enkele datastroom de volledige bandbreedte van een pad claimt wanneer een workload dit vereist, en zorgt ervoor dat elke GPU op gelijke afstand blijft. Hierdoor hoeft de planning geen rekening te houden met de locatie en krijgt elke link dezelfde bescherming tegen fouten.

Fout tolerantie

Helios beschouwt hardwarefouten als input voor het ontwerp. Op deze schaal gaat er altijd wel iets kapot: een haperende kabel, een verloren datapakket, een switch die wordt verwijderd voor een firmware-update, een compute-tray die volledig uitvalt. De infrastructuur is zo ontworpen dat geen van deze gebeurtenissen een taak beëindigt. Verloren datapakketten worden hersteld door herverzending, en wanneer een link, kabel of switch uitvalt, wordt het verkeer na een korte pauze automatisch omgeleid, waarbij de workload verdergaat op de resterende bandbreedte in plaats van opnieuw te starten vanaf een checkpoint.

De topologie met 12 vlakken zorgt voor een geleidelijke degradatie, en de 3-weg striping bepaalt de stapgrootte. Verliest één van de drie verbindingen tussen een GPU en een switch, dan behoudt dat vlak tweederde van zijn bandbreedte. Verliest een complete Tomahawk, dan verliest elke GPU 1/12 van zijn opschalingsbandbreedte, terwijl de all-to-all-verbinding via de andere 11 vlakken gewoon blijft werken. Zelfs het verlies van een complete switch-tray, 2 van de 12 switches, kost elke GPU een zesde van zijn bandbreedte zonder dat de connectiviteit wordt verbroken, omdat geen enkele GPU afhankelijk is van één enkele switch om een ​​andere te bereiken. Ter vergelijking: de Vera Rubin NVL72 verdeelt elke GPU over 36 NVSwitch 6 ASIC's in 9 trays, waardoor een switch-tray-storing daar bijna een negende kost. NVIDIA bereikt kleinere degradatiestappen met 3 keer zoveel switch-ASIC's; AMD stelt daarentegen dat 12 switches met een hogere radix betekenen dat er minder componenten, kabels en connectoren zijn die kunnen uitvallen. Bij een trainingsperiode van enkele weken kan het verschil tussen het verliezen van een zesde van de bandbreedte van het netwerk en het verliezen van de opdracht de volledige economische waarde van het serverrack vertegenwoordigen.

Virtuele pods

Dezelfde mechanismen die de infrastructuur opsplitsen bij storingen, kunnen deze ook doelbewust opsplitsen. AMD noemt deze constructie Virtual Pods, of vPods, en de eenheid is het rekenknooppunt: elke combinatie van de 18 4-GPU-knooppunten van het rack kan worden afgeschermd in een geïsoleerde pod, van 1 knooppunt voor een kleine gebruiker tot het grootste deel van het rack voor een grote trainingstaak. De isolatie wordt afgedwongen op hardwareniveau, onder alles wat een scheduler bepaalt. Een vPod is gekoppeld aan zijn gebruiker; andere pods hebben geen toegang tot het geheugen of het verkeer ervan, en de AES-256-GCM-encryptie op lijnsnelheid op elke UALoE-link, met ondersteuning voor door de klant beheerde clustersleutels, zorgt ervoor dat de tensors van de ene gebruiker ondoorzichtig blijven voor de volgende. Een virtuele machine die meerdere GPU's beslaat, heeft zijn beveiligingsdomein transparant over deze GPU's uitgebreid, zonder dat het hostbesturingssysteem hoeft te worden vertrouwd. NVIDIA lost hetzelfde probleem op in zijn NVL72-racks door het NVLink-domein op te splitsen in partities, waarbij de IMEX-service regelt welke knooppunten geheugen naar elkaar kunnen exporteren en importeren; vPods zijn het equivalent in de UALoE-wereld, dus operators die afkomstig zijn van GB200- of GB300-vloten zullen het concept bekend voorkomen.

Als een compute-tray crasht, blijft de impact beperkt tot de bijbehorende vPod: die workload wordt hervat vanaf een checkpoint, terwijl alle andere pods ongestoord verder draaien. De tenantgrens fungeert dan ook als een faalgrens. De partitionering strekt zich bovendien uit tot in de kleinste details, aangezien een enkele MI455X kan worden opgesplitst in maximaal 8 SR-IOV virtuele machines. Hierdoor kan hetzelfde rack één klant bedienen die alle 72 GPU's als één pod gebruikt, of in het uiterste geval maximaal 576 tenants met GPU-slices, met hardware-isolatie op elk niveau van die hiërarchie.

Het managementplan

Dit alles wordt aangestuurd door een speciale softwarestack die dezelfde openheidsfilosofie volgt als de hardware. AMD Fabric Manager (AFM) is het besturingsvlak: het detecteert en configureert de 72 GPU's in de fabric met zero-touch bring-up, waardoor het inschakelen van het rack voldoende is om alle 72 GPU's te activeren. Vervolgens valideert AFM de bedrading van de kabelcartridges op montagefouten, verdeelt het rack in vPods en coördineert het de hierboven beschreven herroutering en herstel. Er is geen aparte managementtray. AFM draait op de eigen managementprocessors van de switchtrays als 3 redundante instanties verdeeld over de 6 trays met een gedistribueerde database ertussen. Het uitvallen van een switchtray heeft dus geen invloed op het besturingsvlak, en een northbound REST API stelt de fabric beschikbaar aan clustercontrollers die meerdere racks beheren.

Onder de motorkap leent AFM zijn infrastructuur van de cloud-native wereld, gebouwd op standaard Kubernetes-achtige controllers met agents op elke tray. Het beheert de fabric-details die gebruikers nooit hoeven te zien, tot aan het toewijzen van de accelerator-ID's die UALink gebruikt om elke GPU aan te spreken. Het is tevens de observability-laag van het rack. Een enkel dashboard houdt het GPU- en fabric-gebruik, de linkstatus en storingen bij; wanneer er iets misgaat, toont het de lopende herstelprocedure en genereert het waarschuwingen die operators in hun eigen tools kunnen integreren. De bovenstaande schermafbeelding toont AFM die een Helios-cluster in de laboratoria van AMD in de gaten houdt. Beheer werkt in-band of out-of-band, zodat diagnostiek en configuratie de draaiende workloads nooit verstoren. De switches onder AFM draaien een netwerkbesturingssysteem gebouwd op SONiC, het open-source NOS, en AMD zegt dat de UALoE-toevoegingen zullen worden opgenomen in de upstream-architectuur en beschikbaar zullen worden gesteld via standaard gNMI API's. Boven het rack beheert een Rack Infrastructure Manager de levenscyclus van nodes en switches, de stroomvoorziening en lekdetectie, en een Cluster Controller verbindt Helios met Kubernetes en Slurm voor de planning.

Helios versus NVIDIA Vera Rubin NVL72

Laten we eens kijken hoe dit zich verhoudt tot het aanbod van NVIDIA waarmee Helios daadwerkelijk op de markt zal concurreren: de Vera Rubin NVL72.

Rack-metriek	AMD Helios	Vera Rubin NVL72
GPU's	72 MI455X	72 robijnen
CPUs	18 Venetië	36 keer
HBM-capaciteit	31TB	20.7TB
HBM-bandbreedte	1.7 PB/s	1.58 PB/s
Opschaling per GPU	3.6 TB/s	3.6 TB/s
Rack scale-up	260 TB/s	260 TB/s
Schaalvergroting per GPU	2,400 Gb / s	1,600 Gb / s
Opschalingsschakelaars	12 Tomahawk 6	36 NVSwitch 6
Rek formaat	Dubbele ORW-aansluiting	Enkelvoudige MGX

Op papier slaat de scorekaart in het voordeel van AMD: 50% meer HBM, dezelfde 3.6 TB/s aan schaalbaarheid per GPU met een derde minder switch-ASIC's, en 50% meer schaalbare bandbreedte per GPU. AMD's interne tests vertalen deze specificaties naar een prestatieclaim, waarbij 10 tot 15% meer tokens per seconde per GPU wordt behaald op de Kimi K2 Thinking en tot 30% meer tokens per dollar. Dit zijn AMD's cijfers vergeleken met de gepubliceerde cijfers van NVIDIA, geen onafhankelijke metingen, maar ze bepalen wel de norm waaraan AMD verwacht te worden beoordeeld. De interessantere verschillen zitten hem in de manier waarop elk ontwerp zijn GPU's met de buitenwereld verbindt.

Laten we beginnen met schaalvergroting. De netwerkkaarten van de MI455X zijn direct aangesloten op de GPU. Volgens SemiAnalysis is dat bij Rubin niet het geval: het pakket mist de PCIe-sleuf om beide ConnectX-9-netwerkkaarten van stroom te voorzien, waardoor ze in plaats daarvan op de Vera-CPU zijn aangesloten. Het GPU-verkeer moet daardoor een omweg maken: Rubin naar NVLink-C2C naar Vera naar PCIe naar ConnectX-9. Deze omweg kost een latency en zorgt ervoor dat de C2C-verbinding dubbel belast wordt. Doordat de rekenkracht, het hostverkeer en het netwerk tegelijkertijd maximaal belast worden, gaat een deel van de C2C-bandbreedte van Vera op aan het transport van de netwerkdata, waardoor de effectieve hostbandbreedte die een GPU ziet, onder de geadverteerde 1.8 TB/s zakt.

De berekeningen met betrekking tot bandbreedte maken het nog complexer. Elke MI455X levert 2,400 Gbit/s aan schaalbaarheid, wat Rubin's 1,600 Gbit/s ten goede komt. Hierdoor verwerkt Helios meer netwerk per FLOP. AMD's simulaties van een trainingssessie met 8,000 GPU's laten zien dat de derde netwerkkaart de taak ongeveer 13% sneller voltooit.

Rubin slaat terug op het gebied van opslag, en de reden daarvoor is wederom de plaatsing van de netwerkkaart. ConnectX-9 heeft een ingebouwde PCIe-switch, waardoor NVMe direct op de netwerkkaart kan worden aangesloten en een GPU data via GPUDirect Storage kan ophalen zonder de CPU te hoeven gebruiken. De MI455X heeft geen equivalent: de opslag daarvan is aangesloten op de Venice-host, waardoor alles wat via GPUDirect wordt verwerkt, eerst via de CPU moet gaan en vervolgens via de Infinity Fabric-verbinding terugkomt. AMD optimaliseerde het netwerkpad en betaalde daarvoor de prijs op het opslagpad; NVIDIA maakte de omgekeerde afweging. Wat belangrijker is, hangt af van de vraag of een workload afhankelijk is van het verplaatsen van activaties tussen GPU's of van het streamen van data vanaf de schijf.

Wat klanten kunnen wijzigen

Kortom, alles hierboven beschrijft AMD's referentieontwerp, en een aantal van de getallen geven de minimale vereisten aan waar klanten hun systeem bovenuit kunnen bouwen. Het meest voor de hand liggende voorbeeld is de host-CPU. Rubins Vera wordt geleverd in één vaste configuratie; de ​​Venice in een Helios-tray is een standaard SP7-processor met socket, en AMD heeft bevestigd dat elke Venice-variant zonder Helios-specifieke aanpassingen kan worden geïnstalleerd. De referentietray gebruikt de 96-core 5GHz-processor omdat single-threaded snelheid de GPU's optimaal benut. Niets belet een klant echter om zijn of haar versie te configureren met het 256-core vlaggenschip, of Venice-X met zijn 1,152 MB gestapelde L3-cache voor cache-intensieve preprocessing.

Geheugen en netwerken volgen dezelfde socket-and-slot-logica. De referentie 1 TB DRAM bestaat uit 16 bescheiden 64GB RDIMM's; dichtere DIMM's nemen een tray mee tot 4 TB, en de MRDIMM-12800 ontsluit de volledige 1.6 TB/s van Venice. Aan de netwerkzijde kan een configuratie het aantal NIC's per GPU terugbrengen van 3 naar 2 via standaard PCIe Gen 6; elke Vulcano-poort kan werken als 1x800G, 2x400G, 4x200G of 8x100G met Tomahawk 5- of Tomahawk 6-fabrics, en de P4-pipeline laat het transport, RoCEv2, MRC of een eigen protocol, over aan de operator. Zelfs het managementvlak is verwisselbaar, aangezien het switch-NOS open-source SONiC is en AFM de hele fabric beschikbaar stelt via zijn northbound API.

Het stroombudget volgt ook de socket. NVIDIA's superchips hebben één gemeenschappelijk ontwerp: Vera is een chip van 450W met een beperkt stroomverbruik, en recente generaties verschuiven het vermogen onder belasting naar de GPU's. AMD heeft niet aangegeven of het referentieontwerp het stroomverbruik van de host beperkt of verschuift, maar bij AMD ligt die vraag bij de klant. Die kan het systeem aanpassen met een hoger stroomverbruik zonder dat er sprake is van stroomverschuiving.

De PCIe-onderbouwing van de hostlink, die zich in het compute-traygedeelte bevindt, opent nog één laatste deur, die echter openlijk speculatief is. Venice ondersteunt 2P-configuraties en bepaalde AI-hostplatformen kunnen 2P draaien met maximaal 160 bruikbare PCIe-lanes door de xGMI-breedte tussen sockets in te ruilen voor I/O. Een klant zou in theorie een tray met twee sockets kunnen bouwen om te voldoen aan NVIDIA's 1:2 CPU-naar-GPU-verhouding, of de xGMI-links opnieuw kunnen afstemmen om de effectieve CPU-naar-GPU-bandbreedte te verhogen. Niets wijst erop dat iemand dat momenteel bouwt, en niets dicht het ruwe verschil met NVLink-C2C van 1.8 TB/s. De kernvraag is wie de touwtjes in handen heeft: bij Helios zijn de host, het geheugen, de voeding en mogelijk de topologie de beslissingen van de klant, en NVIDIA's superchip geeft de klant helemaal geen zeggenschap.

De Salina DPU

Nu terug naar het front-end netwerk waar we het eerder niet over hadden. Salina, AMD's derde generatie Pensando DPU, is een 400G-kaart met een volledig P4-programmeerbaar datapad. Dit betekent dat een nieuwe encapsulatie, telemetrie-hook of transport een firmware-update is die live wordt toegepast zonder dat er verkeer verloren gaat. De standaardfunctionaliteit dekt al de front-end checklist: SDN met VXLAN of NVGRE, een stateful firewall die schaalbaar is tot miljoenen regels, IPsec op lijnsnelheid, PSP, DTLS of aangepaste encryptie, NAT en load balancing. Het is bovendien de meest beproefde chip in het rack. Pensando DPU's worden al sinds 2019 gebruikt door hyperscalers; Salina is momenteel de front-end van implementaties bij Microsoft, Oracle en IBM. Oracle schrijft de lijn een 5x hogere SDN-prestatie toe, en één hyperscaler heeft 22 CPU-cores per server teruggewonnen door I/O naar de kaart te offloaden.

Opslag is het tweede onderdeel. Salina stelt NVMe-over-Fabrics-apparaten beschikbaar aan de host, waardoor externe SSD-pools worden gevirtualiseerd via TCP of RDMA met encryptie, digests en compressie die op de kaart worden uitgevoerd. Op Helios voegt het een truc uit het agent-tijdperk toe: een context-memory engine presenteert een geëmuleerd KV-apparaat, waardoor overvolle KV-cache wordt overgezet naar CPU-DRAM, lokale SSD of externe opslag en met lijnsnelheid terug naar HBM wordt gestreamd in plaats van opnieuw te worden berekend. Zoals opgemerkt in de vergelijking met Rubin, mist de MI455X GPUDirect Storage; deze KV-offload is AMD's gedeeltelijke antwoord op het verkeer waar servering het meest om geeft.

Daar liggen ook onze bedenkingen. Het bandbreedteverschil is overduidelijk: Salina is een 400G-kaart, terwijl de BlueField-4 die in Vera Rubin-racks wordt geleverd dat verdubbelt naar 800G met een 64-core Grace CPU en een geïntegreerde ConnectX-9. Het softwareverschil is meer discutabel, maar wel degelijk reëel. NVIDIA's DOCA biedt ontwikkelaars gecontaineriseerde, vooraf gebouwde services die programmeerbaar zijn in gewone C en C++; P4 is een gespecialiseerde dataplane-taal waar de meeste teams nog nooit mee hebben gewerkt. De vergelijking is niet "DOCA's catalogus versus kale P4", aangezien Salina zijn belangrijkste services compleet levert en de hyperscalers die het inzetten, er mede voor hebben gekozen omdat P4 het mogelijk maakt om nieuwe protocollen zoals MRC in de firmware te implementeren vóór de siliciumcyclus van wie dan ook. Het echte verschil zit hem in wie de programmeerbaarheid dient. De flexibiliteit van Salina is een wapen voor AMD en hyperscale-teams die P4 beheersen; DOCA is een toolkit die een gewone enterprise-ontwikkelaar kan oppakken. Voor de brede markt is de software-instap van NVIDIA eenvoudiger, en AMD weet dat.

ROCm.AI

Over software gesproken, AMD bewaarde een van zijn grootste aankondigingen voor de stack zelf. ROCm.AI, dat in augustus verschijnt, is AMD's poging om het GPU-platform van de grond af aan agentisch te maken. AI Skills integreren ROCm in de codeeragents die ontwikkelaars al gebruiken, zoals Claude, Codex, Cursor en Gemini, waardoor installeren, uitvoeren en debuggen op Instinct in begrijpelijke taal verloopt. Hyperloom is het meest gedurfde onderdeel: een optimizer die volledig geautomatiseerd een workload profileert, de serverconfiguratie aanpast, GPU-kernels herschrijft en de resultaten valideert terwijl de operator slaapt. AMD zegt dat het momenteel continu zo'n 14,000 modellen optimaliseert, en een live demo liet een 38% hogere doorvoer zien op de MiniMax M3. Onder de agents brengt FlyDSL bijna assembly-niveau controle naar Python, ROCm schakelt over op een vaste releasecyclus van 6 weken, en AMD claimt dat ROCm.AI gemiddeld 3.3 keer snellere inferentie en 2.4 keer snellere training levert dan ROCm 7 op identieke hardware. ROCm 7 liet al een aanzienlijke verbetering zien; nu zet AMD in op AI om dit tempo te versnellen.

De belangrijkste slide van de softwaresessie ging wellicht over hardware. AMD benadrukte dat elk getal erop gemeten was, waarmee ze impliceerden dat de MI455X-chip vandaag de dag operationeel en snel is onder ROCm. De cijfers: 20 TB/s in FP8 MLA-decodering, 20 PFLOPS aan FP4-berekening, 3.2 TB/s aan opschaalbandbreedte en 190 GB/s aan uitschaalbandbreedte. Tijdens de vraag- en antwoordsessie erkende AMD dat het FP4-resultaat een MAMF-meting (Maximum Achievable Matmul-FLOPS) is, uitgevoerd met de matrixvorm die het apparaat het beste tot zijn recht laat komen, wat standaardpraktijk is voor dit type benchmark. Het is ook een gedurfde onthulling: AMD geeft openlijk toe dat de MI455X ongeveer 50% van zijn piekwaarde van 40.26 PFLOPS haalt in MXFP4, een getal dat de meeste leveranciers zouden verzwijgen.

AMD noemt dit de hoogst aangetoonde rekenkracht van alle accelerators op de markt, en daar moet je wel een korreltje zout bij nemen. AMD's FP4 is OCP MXFP4; die van NVIDIA is NVFP4. Het zijn verschillende recepten: NVFP4 past een fractionele FP8-schaal toe op elk blok van 16 elementen, plus een schaal op tensorniveau, terwijl de standaard MXFP4 een grovere schaal met machten van twee per 32 elementen gebruikt. Daardoor kan een NVFP4 FLOP meer werk verwerken dan een MXFP4 FLOP. CDNA 5 kan ook fractionele schaling toepassen op MXFP4, maar AMD heeft niet aangegeven welk recept daarvoor gebruikt is. Een Rubin MAMF-run en een MI455X MAMF-run meten niet dezelfde berekeningen, dus vergelijkingen tussen FP4-processors van verschillende leveranciers zijn alleen op applicatieniveau relevant: tokens per seconde bij gelijke nauwkeurigheid. Gemeten waarden overtreffen de verwachte waarden, maar deze cijfers zijn het meest eerlijk in vergelijking met AMD's eigen vorige generatie, waar de winst van 3x tot 4x onmiskenbaar is.

Er is echter ook een tegenargument in het voordeel van AMD. Dit zijn vroege ROCm.AI-resultaten op gloednieuwe chips, dus ze onderschatten mogelijk wat een handmatig geoptimaliseerde productieomgeving zal bereiken. Het echte oordeel zal pas geveld worden wanneer deze racks in de hyperscalers worden geïnstalleerd.

Sluiting Gedachten

Helios is het meest complete systeem dat AMD ooit heeft uitgebracht, en het eerste dat NVIDIA rechtstreeks op rackschaal beconcurreert in plaats van chip voor chip. De resultaten laten zien dat AMD de overhand heeft op de punten die de AI-capaciteit van vandaag de dag bepalen: 50% meer HBM per GPU, gelijke schaalbaarheid als Rubin, 50% meer schaalbare bandbreedte en, volgens AMD's eigen modellen, tot 30% meer tokens per dollar. Net zo belangrijk is hoe dit is bereikt: Tomahawk-switches voor de massamarkt, open standaarden van de nummerformaten tot de behuizing, en een host met sockets waardoor de uiteindelijke configuratie in handen van de klant blijft. NVIDIA behoudt echte voordelen in de C2C-hostverbinding, de DPU en de software-onramp, maar voor het eerst is het algehele hardwareargument op papier in het voordeel van AMD.

En de kopers zijn het daarmee eens. OpenAI, Meta, Anthropic, Microsoft en Oracle behoren tot de bedrijven die volgens AMD Helios gebruiken, en AMD benadrukt dat de racks momenteel in productie zijn. In navolging van NVIDIA is de roadmap nu een jaarlijks ritme: de op CDNA 6 gebaseerde MI500-serie verschijnt in 2027 met de volgende generatie HBM plus koper en optische interconnect, en de MI600-serie is al in ontwikkeling voor 2028.

Dan blijft er nog de software over, en voor het eerst in jaren hoeven we een verhaal over een AMD GPU niet met die kanttekening af te sluiten. ROCm 7 heeft echte lacunes gedicht, ROCm.AI komt in augustus met meetbare verbeteringen en de releasecyclus is nu vastgesteld op zes weken. Het is ook belangrijk wie de kopers zijn. De labs en hyperscalers die deze deals sluiten, werken samen met AMD aan de ontwikkeling van hun software en hebben voldoende engineers in dienst om eventuele problemen op te lossen. Bedrijven die een kant-en-klare oplossing nodig hebben, zijn een ander verhaal, en die markt blijft voorlopig in handen van NVIDIA. Maar Helios is ontwikkeld voor de hyperscalers en AI-labs, en voor hen is de hardware klaar, de software loopt gelijke tred en de racks worden geleverd. AMD heeft nog nooit zo'n sterke positie gehad.