AMD veranstaltete sein bisher größtes Event zum Thema KI-Entwicklung und legte dabei den Fokus auf Skalierbarkeit. Das Unternehmen präsentierte die Instinct MI455X GPU, das Helios-Rack mit 72 GPUs und die EPYC Venice CPUs der 6. Generation. Die MI455X verfügt über 432 GB HBM4-Speicher – eine Steigerung von 50 % gegenüber NVIDIAs B300 oder Rubin – mit einer Speicherbandbreite von 23.3 TB/s und bis zu 40.26 PFLOPS MXFP4-Rechenleistung. Ein komplettes Helios-Rack skaliert diese Werte um das 72-Fache und erreicht 2.9 ExaFLOPS FP4, 31 TB HBM4-Speicher, 1.7 PB/s Speicherbandbreite, 260 TB/s Scale-up-Bandbreite und 43 TB/s Scale-out-Bandbreite zum Rechenzentrum. AMD will in allen Bereichen branchenführend sein. Dieser Artikel untersucht die MI455X und Helios; die Markteinführung von Venice wird in einer separaten Analyse behandelt.

Ein weiteres Leitmotiv ist Offenheit, die sich durch alle Ebenen zieht, angefangen bei der Verbindung. Innerhalb des Racks teilen sich alle 72 GPUs den Speicher über UALink, ein offenes Konsortiums-Fabric, das AMD über Ethernet als UALink-over-Ethernet (UALoE) betreibt. Sobald der Datenverkehr das Rack verlässt, wird er über Ultra Ethernet, den offenen Scale-Out-Standard des Ultra Ethernet Consortiums, weitergeleitet. Die gleiche Instinct-Architektur kommt in allen Ebenen zum Einsatz. Die Berechnungen mit geringer Genauigkeit nutzen die offenen Datenformate MXFP4, MXFP6 und MXFP8 des OCP, und das Rack, in dem all dies untergebracht ist, entspricht dem Open Rack Wide-Design des Open Compute Project. Selbst die Software wird offen entwickelt: Compiler, Laufzeitumgebung und Bibliotheken von ROCm sind als Quellcode verfügbar.

Da alle Spezifikationen des Stacks veröffentlicht und heute zum Download verfügbar sind, kann ein Hyperscaler Helios als Vorlage nutzen und eine maßgeschneiderte Version erstellen, die auf seine eigenen Infrastrukturen und Workloads abgestimmt ist und beispielsweise Netzwerk, Stromversorgung oder Management anpasst. Das bedeutet, dass sich alles, was wir in diesem Artikel beschreiben, auf das von AMD vorgestellte Referenzdesign bezieht; die von Kunden eingesetzten Einheiten können sich deutlich unterscheiden. Die ersten Anwender stehen bereits in den Startlöchern: Laut AMD setzen unter anderem OpenAI, Meta, Anthropic, Microsoft und Oracle auf Helios.

AMD Instinct MI455X: das Flaggschiff mit CDNA 5

Der MI455X ist der erste CDNA-5-Beschleuniger mit 320 Milliarden Transistoren. Er verfügt über acht Accelerator Complex Dies (XCDs) im N2-Verfahren von TSMC, zwei I/O-Dies und zwei Fabric- und Cache-Dies im N3-Verfahren sowie zwölf HBM4-Stacks. Er ist der größte Chip, der jemals im CoWoS-L-Gehäuse von TSMC gefertigt wurde.

Der Speicher ist eines der Hauptthemen. Die zwölf HBM4-Stacks umfassen insgesamt 432 GB bei 23.3 TB/s, wobei HBM4 die Schnittstelle pro Stack auf 2,048 Bit verdoppelt, und die beiden Fabric- und Cache-Dies fügen einen 192 MB großen L2-Cache mit einer Übertragungsrate von 54 TB/s hinzu.

Auch bei den I/O-Leistungen geizt der MI455X nicht. Er verfügt über 72 UALoE-Lanes für eine bidirektionale Scale-up-Bandbreite von 3.6 TB/s für den Rest eines Racks, 256 GB/s bidirektionales Infinity Fabric für seine Host-CPU und wahlweise zwei PCIe Gen6 x16-Verbindungen oder drei AMD AI-NICs für Scale-out.

Im Vergleich zu dem Chip, den er ersetzt, und den Angeboten von NVIDIA ist der MI455X in jeder Hinsicht führend.

Normen	AMD MI455X	NVIDIA Rubin	AMD MI355X	NVIDIA B300
Architektur	CDNA 5	Einreiben	CDNA 4	Blackwell Ultra
Transistoren	320 Mrd	336 Mrd	185 Mrd	208 Mrd
HBM-Kapazität	432GB HBM4	288GB HBM4	288 GB HBM3E	288 GB HBM3E
HBM-Bandbreite	23.3 TB / s	22 TB / s	8 TB / s	8 TB / s
Skalierung pro GPU	3.6 TB / s	3.6 TB / s	1.08 TB / s	1.8 TB / s
Skalierung pro GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
CPU-GPU-Verbindung	256 GB/s Infinity Fabric	1.8 TB/s C2C (1:2)	PCIe 5	900 GB/s C2C (1:2)

 

Beginnen wir mit den Stärken von AMD. Mit 432 GB bietet die MI455X 50 % mehr HBM-Speicher als die MI355X, B300 oder Rubin, die alle maximal 288 GB erreichen. Ihre Speicherbandbreite von 23.3 TB/s ist ebenfalls die höchste in dieser Gruppe. Auch beim Scale-Out-Verfahren sieht es ähnlich aus: 2,400 Gbit/s pro GPU gegenüber 1,600 Gbit/s bei Rubin und 800 Gbit/s bei B300. Jede MI455X verlässt das Rack mit 50 % mehr Netzwerkbandbreite als ihr nächster Konkurrent.

AMD hat nun auch beim Scale-up aufgeholt. NVLink war jahrelang die führende GPU-Architektur und bot zwei Generationen lang die einzige Möglichkeit, Höchstleistungen auf MoE-Modellen mit WideEP zu erzielen. UALoE schließt diese Lücke innerhalb einer Generation: Mit 3.6 TB/s erreicht der MI455X die Geschwindigkeit von Rubins NVLink 6. NVIDIA hat jedoch weiterhin einen klaren Vorsprung bei der Host-Anbindung. Eine Vera-CPU versorgt zwei Rubin-GPUs über 1.8 TB/s C2C, während jeder MI455X über eine 256 GB/s schnelle Infinity Fabric-Verbindung mit seinem Venice-Host kommuniziert. Dieser Unterschied prägt die später in diesem Artikel erläuterten Unterschiede zwischen den beiden Rack-Architekturen.

Bei der reinen Rechenleistung ist der MI455X durchweg führend, mit einer kleinen Anmerkung: Die OCP MX-Formate von AMD und die NVFP4-Formate von NVIDIA skalieren unterschiedlich, daher sollten diese Werte als beworbene Spitzenwerte betrachtet werden; die tatsächliche Leistung ist eine andere Frage.

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

 

Im Vergleich zur MI355X bietet die MI455X den vierfachen Durchsatz bei MXFP4 und MXFP8 sowie die doppelte Leistung bei FP16/BF16 und FP32. Der Vergleich mit NVIDIA lässt sich in zwei Bereiche unterteilen. Gegenüber der B300 erzielt die MI455X den 2.7-fachen FP4-Durchsatz und die vierfache Leistung bei FP6 und FP8. Rubin ist der aussagekräftige Benchmark, und hier zeigt die MI455X einen durchgängigen Vorteil: 15 % bei FP4, 15 % bei FP6 und FP8 sowie 26 % bei FP16/BF16. Der größte Unterschied zeigt sich bei FP32, wo die 315 TF der MI455X etwa das 2.4-Fache der 130 TF von Rubin und mehr als das Vierfache der 75 TF der B300 betragen. Diese Zahl stammt aus der HPC-Tradition von Instinct und ist auch heute noch für KI-Anwendungen relevant, da Master-Gewichte, hochpräzise Akkumulation und wissenschaftliche Workloads weiterhin über den Low-Bit-Formaten laufen.

Innerhalb von CDNA 5

Lasst uns einen Blick auf die Architektur werfen und sehen, was diese erstklassige Leistung tatsächlich ermöglicht.

Von XCD zu SIMD

Die hierarchische Struktur, ausgehend vom Package, verdeutlicht, wie umfangreich die Neuerungen sind, da CDNA 4 die Rechenchips grundlegend anders organisiert. Beim MI355X enthielt jede XCD 32 aktive Compute Units und einen privaten 4 MB großen L2-Cache, der den Datenverkehr des Chips bündelte, bevor er die Infinity Fabric erreichte. CDNA 5 behält die acht XCDs bei, überarbeitet aber deren Inhalt und übernimmt dabei Struktur und Terminologie von AMDs RDNA-Grafiklinie. Jede MI455X-XCD ist nun in zwei Shader Engines aufgeteilt. Jede Shader Engine enthält physisch 17 Work Group Processors, von denen 16 aktiviert sind – einer dient als Reserve. Der L2-Cache pro XCD entfällt vollständig; er wurde vom Rechenchip in die darunterliegenden Basischips ausgelagert, in die der Speicherbereich zurückkehrt.

Die entscheidenden Berechnungen sind die, die sich nicht geändert haben. Ein XCD trägt weiterhin 32 aktive Einheiten bei, und die GPU verfügt nach wie vor über insgesamt 256 Recheneinheiten – dieselbe Anzahl wie der MI355X. Die vierfache Steigerung des Durchsatzes bei niedriger Präzision im Vergleich zur Vorgängergeneration resultiert nicht aus zusätzlichen Ausführungseinheiten, sondern ausschließlich daraus, dass jeder WGP mehr Arbeit pro Taktzyklus verrichtet. Die Überarbeitung konzentriert sich auf den WGP.

Ein Wavegroup (WGP) besteht aus vier 32-Lane-SIMD-Einheiten und vier Skalareinheiten mit gemeinsamem Konstantcache. Die größte Änderung betrifft den Thread-Fluss: den Wechsel von Wave64 zu Wave32. Eine Wave ist ein Bündel von Threads, die eine SIMD-Einheit synchron ausführt. CDNA 4 nutzte Wave64 und verarbeitete jede 64-Thread-Wave über vier Taktzyklen durch eine 16-Lane-SIMD-Einheit. CDNA 5 verzichtet vollständig auf Wave64 – als erste Instinct-Architektur – und verwendet Wave32 nativ. Eine 32-Thread-Wave wird eins zu eins auf jede der vier 32-Lane-SIMD-Einheiten des WGP abgebildet, in einem einzigen Zyklus ausgeführt und ermöglicht es jeder SIMD-Einheit, in jedem Taktzyklus eine neue Anweisung zu starten.

Schmalere, schnellere Wellen verändern den Arbeitsablauf im System. Die Befehlslatenz sinkt, da eine Welle schneller abgeschlossen ist. Verzweigungsdivergenzen sind weniger kostspielig, da eine Verzweigung (übernommen oder nicht) nun maximal 32 statt 64 Threads blockiert. Der Registerdruck verringert sich, sodass mehr Wellen im Speicher verbleiben – bis zu 64 pro WGP (Wave Generation Processor) im Vergleich zur Hälfte zuvor. Dadurch stehen dem Scheduler mehr kleine, unabhängige Arbeitspakete zur Verfügung, hinter denen sich die Speicherlatenz verbergen kann. Wave32 erleichtert zudem die Hardware-Abbildung unterschiedlicher Kachelgrößen für Tensoroperationen und vereinfacht so die Kernelentwicklung.

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.

Die Speicherhierarchie

Hinter den Ausführungseinheiten verbirgt sich eine von oben nach unten neu aufgebaute Hierarchie, die am deutlichsten im Vergleich zum MI355X Ebene für Ebene sichtbar wird.

Niveau	MI455X (CDNA 5)	MI355X (CDNA 4)
Vektorregister	128 KB pro SIMD; 1,024 pro Thread; 2× Bandbreite	128 KB pro SIMD; 256 pro Thread
WGP / CU lokale Filiale	384 KB (320 KB LDS + 64 KB Vektorcache); 2× Bandbreite	192 KB (160 KB LDS + 32 KB L1)
Befehls-/Konstantencache	64 KB + 16 KB pro WGP	64 KB gemeinsam genutzt pro zwei CUs + 16 KB
L2	2 × 96 MB auf den FCDs; 54 TB/s	8 × 4 MB, eine pro XCD
Speicherseitiger Cache	Ausgeschieden	256 MB Infinity-Cache
HBM	432 GB HBM4; 12 × 2,048-Bit-Stacks; 23.3 TB/s	288 GB HBM3E; 8 × 1,024-Bit-Stacks; 8 TB/s

 

Die Cache-Zeilen markieren den Punkt, an dem sich die Architektur grundlegend veränderte. CDNA 4 nutzte ein dreistufiges Design: Der private 4-MB-L2-Cache jedes XCD bündelte den Datenverkehr des jeweiligen Chips, bevor dieser die Infinity Fabric erreichte. Ein gemeinsamer 256-MB-Infinity-Cache in den I/O-Chips befand sich speicherseitig vor den HBM-Controllern. CDNA 5 verzichtet auf diese beiden Ebenen und ersetzt sie durch zwei unabhängige 96-MB-L2-Caches, einen pro Fabric und Cache-Chip, die jeweils aus 96 Ein-Megabyte-Blöcken bestehen. Das Layout ist vertikal: Vier XCDs (oder acht Shader Engines) sind hybridgebunden auf jedem FCD angeordnet, der zusätzlich sechs der zwölf HBM4-Speicherplätze beherbergt. Die beiden FCDs treffen sich in einer zentralen Infinity Fabric in der Mitte des Gehäuses, wobei die I/O-Chips die jeweiligen Enden abschließen. Jeder L2-Cache kann jede beliebige Adresse im GPU-Speicher aufnehmen, und die Infinity Fabric sorgt für die Kohärenz der beiden Caches. AMDs Begründung lautet Bandbreite: Einer dieser Caches allein liefert das 1.5-fache der Gesamtbandbreite des gesamten Infinity Cache des MI355X, das Paar das Dreifache, und dieser Datenverkehr muss nicht mehr die Die-zu-Die-Bisection durchlaufen, die beim alten Layout die Grenze setzte.

Der Cache übernimmt ebenfalls neue Aufgaben. Gerätebezogene atomare Operationen, die zuvor außerhalb des Fabric ausgeführt wurden, laufen nun innerhalb des L2-Caches mit deutlich höherer Geschwindigkeit, während systembezogene atomare Operationen weiterhin im Infinity Fabric verbleiben. Ein neuer Broadcast-Arbiter vervollständigt das System, indem er Tensor-Kacheln an alle WGPs verteilt, die an derselben Matrix zusammenarbeiten. Dadurch wird ein einmal abgerufenes Gewicht allen WGPs zur Verfügung gestellt, was die effektive Lesebandbreite um bis zu das Vierfache erhöht.

Die oben genannten Stufen skalieren entsprechend. Der lokale Speicher pro WGP verdoppelt sich auf 384 KB, aufgeteilt in 320 KB LDS und einen 64 KB großen Vektordatencache, bei doppelter Lesebandbreite. Dadurch kann FlashAttention Abfragen, Schlüssel, Werte und Teilreduktionen auf dem Chip speichern, anstatt die gesamte Aufmerksamkeitsmatrix zu schreiben. Zudem werden fusionierte MoE-Kernel unterstützt, um Routing-Zustände und Akkumulatoren resident zu halten. Die Vektorregisterdatei behält ihre Kapazität von 128 KB pro SIMD, wird aber für Wave32 neu organisiert. Dies führt zu doppelt so vielen Waves, ermöglicht es einem einzelnen Thread, 1,024 statt 256 Register zu adressieren, und verdoppelt die Registerbandbreite, um die breiteren SIMDs und ihre Co-Execution-Units zu versorgen.

Die Skalarseite wurde entsprechend angepasst, mit 128 Skalarregistern pro Welle und 32 KB pro WGP. Im Basisbereich wechselt HBM4 von acht 1,024-Bit-Stacks zu zwölf 2,048-Bit-Stacks, wodurch die Kapazität um 50 % auf 432 GB und die Bandbreite um das 2.9-Fache auf 23.3 TB/s über eine 192-Kanal-Schnittstelle erhöht wird.

Die Grundlage dafür bildet ein neuer Tensor Data Mover (einer pro WGP), der Tensor-Tiling-Schemata bis zu fünf Dimensionen unterstützt und Tiles asynchron zwischen DRAM und lokalem Speicher streamt, ohne zwischengespeicherte Register. Die Übertragungen werden durch Deskriptoren beschrieben, die aus den Skalarregistern geladen und hardwareseitig auf ihre Grenzen geprüft werden. Multicast-Ladevorgänge werden unterstützt, sodass die SIMD-Einheiten nicht durch das Warten auf eine Kopie oder das Vorladen von Registern blockiert werden. Dies ist die Antwort von CDNA 5 auf die Tensor-Speicherbeschleuniger aktueller NVIDIA-Prozessoren. Eine Reihe von Nutzungsfunktionen rundet die Frontend-Architektur ab: Workgroup-Cluster ermöglichen Kernels die explizite Kontrolle über Platzierung und Parallelität bei datenteilenden Workloads; geteilte und benannte Barrieren erlauben es einem Produzenten, die Fertigstellung zu signalisieren und fortzufahren, ohne auf die Antwort des Konsumenten warten zu müssen; Prefetcher auf jeder Hierarchieebene stellen Daten für den jeweiligen Verwendungspunkt bereit; und ein überarbeitetes Command Frontend reduziert die Start- und Dispatch-Latenz für die kurzen Kernels, die bei der Inferenz dominieren.

Das DMA-System wurde nach demselben Prinzip neu entwickelt. Die Software plant die Datenübertragungen über die DMA-Frontends, während physikalisch orientierte Backends neben den UALoE-Verbindungen jedes Arbeitselement aufteilen, die Last gleichmäßig auf alle verfügbaren Verbindungen verteilen und Puffer direkt aus dem Speicher abrufen, anstatt Daten über den Chip zu einer entfernten Engine zu übertragen. Die Backends reagieren zudem auf den Gegendruck durch die Netzwerkauslastung und umgehen ausgelastete Pfade, sodass Kommunikationsbibliotheken einen ausgewogenen Datenverkehr erhalten, ohne die zugrundeliegende Topologie zu kennen.

GPU-Slicing: NPS und SR-IOV

Das zweistufige L2-Layout bietet einen weiteren Vorteil bei der GPU-Partitionierung. Bei NPS1 bildet der gesamte Chip eine einzige NUMA-Domäne: Adressen verteilen sich über alle zwölf HBM-Stacks und beide Hälften, um eine gleichmäßige Bandbreite zu gewährleisten – die einfachste Methode für Portierung und gleichmäßig verteilte Zugriffsmuster. NPS2 teilt die GPU in zwei NUMA-Domänen auf, von denen jede sechs HBM-Stacks, einen Fabric- und Cache-Die sowie die darauf gestapelten XCDs besitzt. Jeder Speicherzugriff erfolgt somit innerhalb der jeweiligen Hälfte, und jede Domäne erhält effektiv einen privaten 96 MB großen L2-Cache. Dies verkürzt nicht nur den physischen Pfad. Da keine Cache-Zeilen zwischen den Hälften geteilt werden, entfällt der Infinity-Fabric-Kohärenzverkehr zwischen den beiden L2-Caches weitgehend. Laut AMD führt dies zu geringerer Latenz und höherer Effizienz für NUMA-fähige Anwendungen. CDNA 4 bot den gleichen breiten Tauschhandel, wobei NPS2 den Datenverkehr innerhalb eines I/O-Dies hielt, aber CDNA 5 verschärft ihn, da das zu lokalisierende Element nun der gesamte L2-Cache und nicht mehr nur ein Ausschnitt eines speicherseitigen Puffers ist.

Die Partitionierung der Rechenprozesse erfolgt über den acht XCDs. Diese ermöglichen es der GPU, mit einer, zwei, vier oder acht räumlichen Partitionen zu starten und die 432 GB HBM in gleichmäßige Segmente von 432, 216, 108 oder 54 GB aufzuteilen, die jeweils von acht XCDs unterstützt werden. Durch die Zuordnung der Partitionen zu den NUMA-Domänen kann die Laufzeitumgebung die Arbeit verteilen und Speicherzuweisungen räumlich platzieren, sodass ein Job auf den XCDs landet, die seinem Speicher am nächsten liegen. SR-IOV virtualisiert die Partitionen anschließend in bis zu acht hardwareisolierte virtuelle Maschinen. Die Isolation wird dabei im Speichersystem selbst erzwungen, unabhängig vom verwendeten NUMA-Modus. Der MI355X bot dieselben Partitionierungsoptionen von eins bis acht, die Granularität ist also nicht neu. CDNA 5 ergänzt dies um das private L2-Verhalten und darüber um die Rack-Level Virtual Pods, die im Abschnitt Helios beschrieben werden.

AMD Helios

Ein einzelner MI455X ist schnell. Mit dieser Produkteinführung steigt AMD nun in den Kreis der Rack-Scale- und Large-Scale-Up-Anbieter ein.

Helios verzichtet auf die herkömmlichen 19- und 21-Zoll-Racks und setzt stattdessen auf Open Rack Wide, ein Format, das AMD gemeinsam mit Meta auf der OCP entwickelt hat: ein 1.2 Meter breites und 1.3 Meter tiefes Gehäuse mit 44 Höheneinheiten (UE) vertikaler Höhe. Im Inneren befinden sich die 72 GPUs in zwei Gruppen mit je neun Recheneinschüben, dazwischen sind die sechs Switch-Einschübe angeordnet. Jede GPU-Switch-Verbindung ist über Kupferkabel in vier Blind-Mate-Kabelkassetten an der Rückseite ausgeführt, sodass die Einschübe zur Wartung herausgezogen werden können, ohne dass Kabel manuell getrennt werden müssen.

Das gesamte Rack benötigt je nach Auslastung 225 bis 245 kW, die über eine flüssigkeitsgekühlte 50-V-Sammelschiene bereitgestellt werden. Rückseitige Verteiler fördern dabei etwa 385 Liter Kühlmittel pro Minute aus dem Kühlkreislauf. Die Schaltschienen selbst sind robuste Bauteile: Jede wiegt rund 170 kg, und das Einsetzen der 1,728 Differenzialpaar-Anschlüsse einer Schaltschiene erfordert eine Einpresskraft von etwa 690 kg. Aus diesem Grund erstrecken sich die Nockengriffe fast über die gesamte Breite der Schaltschiene.

Die Bausteine in intelligenten Netzen

Compute Tray

Im Referenzdesign ist jedes Rechenmodul ein in sich geschlossener Knoten, der aus vier MI455X-Modulen und einer hochfrequenten 96-Kern-CPU vom Typ Venice SP7 mit bis zu 5 GHz besteht. Die 16 DIMM-Sockel beherbergen 1 TB DRAM in Form von 16 × 64 GB DDR5 ECC RDIMMs. Zusätzlich sind fünf E1.S NVMe-Steckplätze an die CPU angeschlossen. Die Plattform ist für deutlich mehr ausgelegt: Die 16 Speicherkanäle von Venice unterstützen eine Bandbreite von bis zu 1.6 TB/s. Da 256 GB RDIMMs derzeit die größte Speicherkapazität für DDR5 darstellen, erreicht ein 16-Kanal-Sockel mit einem DIMM pro Kanal eine maximale Speicherkapazität von 4 TB.

AMD folgt NVIDIAs Beispiel und integriert die CPU über Infinity Fabric in den zusammenhängenden Speicherbereich, anstatt wie bisher als einfacher PCIe-Host hinter den GPUs zu sitzen. AMD argumentiert, das Verhältnis von 1:4 zwischen CPU und GPU sei bewusst gewählt: Der Kern selbst übertreffe die Konkurrenz. Laut AMDs Vergleichswerten liegt der 5-GHz-Zen-6-Kern in der Leistung pro Kern etwa 20 % vor NVIDIAs Vera. Da der Sockel ein Standard-SP7 ist, können Kunden mit höherem Rechenbedarf jede Venice-Variante bis hin zum 256-Kern-Flaggschiff einsetzen. Ein Venice-Sockel bietet zudem deutlich mehr DDR5-Speicherkapazität als ein LPDDR-Host-Design, und seine Speicherbandbreite wird über die Infinity-Fabric-Verbindungen voll auf alle vier GPUs ausgeschöpft.

Die Infinity Fabric-Verbindung verdient eine genauere Betrachtung. Im Gespräch mit George Cozma von Chips and Cheese über die Verbindung zwischen Venice und MI455X vermutete er, dass die stabile Verbindung über die PCIe-Lanes der CPU läuft – ähnlich wie EPYC seine xGMI-Sockelverbindungen seit Jahren über PCIe-PHYs realisiert. Die Zahlen bestätigen diese Theorie. PCIe Gen 6 signalisiert mit 64 Gbit/s pro Lane, und eine x16-Verbindung erreicht bei dieser Rate 128 Gbit/s in beide Richtungen – exakt die von AMD angegebenen 256 Gbit/s bidirektional pro GPU. Das Blockdiagramm im CDNA-5-Whitepaper weist die Host-Infinity-Fabric-Schnittstelle mit 64 Gbit/s pro Lane aus, der exakten Gen-6-Signalrate. Diese Theorie erklärt auch, warum jede Venice-SKU kompatibel ist: Die vier GPUs belegen 64 der 128 Gen-6-Lanes der CPU, sodass die restlichen für DPUs, Speicher und andere Systemkomponenten frei bleiben.

Drei separate Netzwerke durchlaufen jeden Compute Tray, jedes für eine andere Aufgabe. Das konventionellste ist das Frontend: Eine einzelne Pensando Salina 400G DPU verbindet den Knoten mit dem regulären Rechenzentrumsnetzwerk, das wir später genauer betrachten werden.

Die zweite Funktion ist Scale-Out, das Netzwerk, das Racks zu Clustern verbindet. Am einfachsten lässt sich dies anhand der SerDes-Anzahl verstehen. Das Scale-Out des MI455X kann entweder PCIe Gen 6 mit 64 Gbit/s pro Lane oder UALink128 mit 128 Gbit/s nutzen. Eine Vulcano 800 NIC benötigt jeweils etwa 128 Gbit/s an Anbindung, um ihren 800-GbE-Port auszulasten. Bei Gen-6-Geschwindigkeit ist dafür eine vollständige x16-Verbindung pro NIC erforderlich, sodass die GPU zwei NICs unterstützt. Bei der doppelten Signalrate von UALink128 reicht eine x8-Verbindung mit der Hälfte der SerDes aus, sodass die GPU drei NICs unterstützt – die Konfiguration, mit der Helios ausgeliefert wird. In beiden Fällen ist der UALink128-Hop lediglich eine private Verbindung zwischen GPU und NIC; das Netzwerk selbst beginnt am Vulcano. Jede Netzwerkkarte (NIC) steuert einen 800-GbE-Port mit UEC-konformen Transportprotokollen, einschließlich MRC, dem von OpenAI gemeinsam mit AMD und anderen Partnern entwickelten Multipath-Protokoll. Die NICs befinden sich auf jeweils zwei kundenspezifischen Platinen pro Tray, die jeweils vier oder sechs Vulcano-ASICs tragen und den Konfigurationen mit zwei bzw. drei NICs pro GPU entsprechen. In der Vollausstattung ergeben sich somit zwölf NICs pro Tray und eine skalierbare Bandbreite von 2,400 Gbit/s pro GPU. Da die NICs direkt an die GPUs angeschlossen sind und die CPU nicht im Datenpfad liegt, wird der Datenverkehr zwischen den Racks niemals über die Host-Verbindung geleitet.

Der dritte Aspekt ist die Skalierbarkeit, die Helios zu einem echten Rack-System macht. Jede GPU verfügt über 36 UALoE-Verbindungen, die die Speichersemantik von UALink über ESUN Ethernet bereitstellen. Jede Verbindung ist für 400 Gbit/s ausgelegt, was eine bidirektionale Bandbreite von 3.6 TB/s pro GPU ergibt. Diese Verbindungen treten an der Rückseite des Trays in Richtung der Switch-Trays aus und übertragen den Load-Store-Traffic, der die 72 GPUs zu einem Shared-Memory-Pod zusammenführt.

Fach wechseln

Als Nächstes betrachten wir die Switch-Einschübe. Am auffälligsten ist dabei, wie gewöhnlich ihre Siliziumchips sind. Jeder der sechs Einschübe enthält zwei Broadcom Tomahawk 6 ASICs – dieselben Ethernet-Switch-Chips, die Hyperscaler in ihren Leaf-Spine-Netzwerken einsetzen. Jeder dieser Chips verarbeitet 512 Lanes mit 200 Gbit/s.

Jede GPU sendet drei UALoE-Verbindungen (jede UALoE-Verbindung besteht aus zwei 200-Gbit/s-Lanes) an jeden der zwölf Switches. Insgesamt verlassen 144 Verbindungen jedes Rechenmodul durch die rückseitigen Kabeleinführungen. Jeder Tomahawk terminiert somit 216 Verbindungen mit 400 Gbit/s und überträgt dabei eine bidirektionale Bandbreite von 21.6 TB/s, während jede GPU ihre vollen 36 Verbindungen (72 × 200-Gbit/s-Lanes) und 3.6 TB/s behält. Die Switches benötigen dafür keine besonderen Technologien: Die UALoE-Kapselung ist ein einfaches Layer-2-Protokoll, die Weiterleitung basiert auf statischer MAC-Programmierung, die Ethernet-Chips seit zwei Jahrzehnten bieten, und die Flusssteuerung ist eine standardmäßige Prioritätsflusssteuerung.

Mit einer einzigen Übertragungsebene treten ganze Klassen von Überlastungsproblemen im Rechenzentrum gar nicht erst auf: Es gibt keine mehrstufigen Incast-Probleme, und jede GPU ist exakt einen Hop mit fester Latenz von jeder anderen entfernt. Im Vergleich zu einem direkten Mesh-Netzwerk ermöglicht der Switched-Ansatz zudem, dass ein einzelner Datenfluss die gesamte Bandbreite eines Pfades beansprucht, wenn eine Arbeitslast dies erfordert, und hält alle GPUs auf gleicher Distanz. Daher muss die Planung die lokale Lage nicht berücksichtigen und bietet jeder Verbindung denselben Fehlerschutz.

Fehlertoleranz

Helios berücksichtigt Hardwareausfälle als Designparameter. In dieser Größenordnung ist ständig mit Ausfällen zu rechnen: ein fehlerhaftes Kabel, ein verlorenes Paket, ein Switch, der für ein Firmware-Update außer Betrieb genommen wird, ein komplett ausgefallenes Rechenmodul. Die Infrastruktur ist so konzipiert, dass keines dieser Ereignisse einen Job zum Abbruch bringt. Verlorene Pakete werden durch erneute Übertragung wiederhergestellt, und wenn eine Verbindung, ein Kabel oder ein Switch ausfällt, wird der Datenverkehr nach einer kurzen Unterbrechung automatisch umgeleitet. Die Arbeitslast wird mit der verbleibenden Bandbreite weitergeführt, anstatt von einem Checkpoint neu zu starten.

Die 12-Ebenen-Topologie sorgt für einen sanften Bandbreitenverlust, und die 3-Wege-Striping-Struktur bestimmt die Schrittweite. Fällt eine der drei Verbindungen einer GPU zu einem Switch aus, behält diese Ebene zwei Drittel ihrer Bandbreite. Fällt ein kompletter Tomahawk aus, verliert jede GPU ein Zwölftel ihrer Skalierungsbandbreite, während die Verbindung über die verbleibenden elf Ebenen aufrechterhalten wird. Selbst der Ausfall eines kompletten Switch-Trays (zwei der zwölf Switches) kostet jede GPU nur ein Sechstel ihrer Bandbreite, ohne die Konnektivität zu unterbrechen, da keine GPU von einem einzelnen Switch abhängig ist, um eine andere zu erreichen. Zum Vergleich: Vera Rubin NVL72 verteilt jede GPU auf 36 NVSwitch 6 ASICs in neun Trays, sodass ein Ausfall eines Switch-Trays hier eher ein Neuntel der Bandbreite kostet. NVIDIA erzielt kleinere Bandbreitenverluste durch die dreifache Anzahl an Switch-ASICs; AMD argumentiert hingegen, dass zwölf Switches mit höherer Radix-Rate von vornherein weniger Komponenten, Kabel und Steckverbinder bedeuten, die ausfallen können. Bei einer Trainingsphase von mehreren Wochen entspricht der Unterschied zwischen dem Verlust eines Sechstels der Bandbreite des Geräts und dem Verlust des Arbeitsplatzes den gesamten wirtschaftlichen Kosten des Racks.

Virtuelle Kapseln

Dieselbe Technologie, die das Netzwerk bei Ausfällen partitioniert, kann es auch gezielt partitionieren. AMD nennt dieses Konstrukt Virtual Pods (vPods). Die Recheneinheit ist der Compute-Knoten: Jede Kombination der 18 4-GPU-Knoten des Racks kann zu einem isolierten Pod zusammengefasst werden – von einem einzelnen Knoten für einen kleinen Mandanten bis hin zum Großteil des Racks für einen umfangreichen Trainingsauftrag. Die Isolation wird in der Hardware des Netzwerks realisiert, unabhängig von den Entscheidungen des Schedulers. Ein vPod ist an seinen Mandanten gebunden; andere Pods haben keinen Zugriff auf seinen Speicher oder seinen Datenverkehr. Die AES-256-GCM-Verschlüsselung mit Leitungsgeschwindigkeit auf jeder UALoE-Verbindung, mit Unterstützung für kundeneigene Cluster-Schlüssel, sorgt dafür, dass die Tensoren eines Mandanten für den nächsten undurchsichtig bleiben. Eine Gast-VM, die sich über mehrere GPUs erstreckt, profitiert von einer transparenten Erweiterung ihrer Sicherheitsdomäne über diese hinweg, ohne dass dem Host-Betriebssystem vertraut werden muss. NVIDIA löst das gleiche Problem bei seinen NVL72-Racks, indem es die NVLink-Domäne in Partitionen aufteilt, wobei der IMEX-Dienst vermittelt, welche Knoten Speicher exportieren und importieren dürfen; vPods sind das Äquivalent in der UALoE-Welt, sodass Betreiber, die von GB200- oder GB300-Flotten kommen, das Konzept als vertraut empfinden werden.

Wenn ein Compute Tray ausfällt, beschränkt sich der Schadensradius auf den zugehörigen vPod: Die Workload wird vom Checkpoint neu gestartet, während alle anderen Pods unberührt weiterlaufen. Die Tenant-Grenze dient gleichzeitig als Ausfallgrenze. Die Partitionierung ist hierarchisch verschachtelt, da ein einzelner MI455X in bis zu acht SR-IOV-VMs aufgeteilt werden kann. So kann dasselbe Rack entweder einen Kunden mit allen 72 GPUs als einen Pod oder im Extremfall bis zu 576 GPU-Slice-Tenants bedienen – mit Hardware-Isolation auf jeder Ebene dieser Hierarchie.

Die Managementebene

Das gesamte System wird von einem dedizierten Software-Stack gesteuert, der dem gleichen Offenheitsprinzip wie die Hardware folgt. Der AMD Fabric Manager (AFM) bildet die Steuerungsebene: Er erkennt und provisioniert das 72-GPU-Fabric mit Zero-Touch-Bring-up, sodass das Einschalten des Racks ausreicht, um alle 72 GPUs zu aktivieren. Anschließend überprüft er die Kabelverdrahtung auf Montagefehler, unterteilt das Rack in vPods und koordiniert die oben beschriebenen Umleitungen und Wiederherstellungsmaßnahmen. Es gibt kein separates Management-Tray. AFM läuft auf den Management-Prozessoren der Switch-Trays als drei redundante Instanzen, verteilt auf die sechs Trays mit einer gemeinsamen Datenbank. Der Ausfall eines Switch-Trays hat daher keine Auswirkungen auf die Steuerungsebene. Eine REST-API (Northbound) stellt das Fabric den Cluster-Controllern zur Verfügung, die mehrere Racks verwalten.

AFM nutzt im Hintergrund Cloud-native Technologien und basiert auf standardmäßigen Kubernetes-Controllern mit Agenten auf jedem Tray. Es kümmert sich um die Fabric-Details, die Benutzer nicht benötigen, bis hin zur Zuweisung der Beschleuniger-IDs, die UALink zur Adressierung jeder GPU verwendet. AFM dient gleichzeitig als Überwachungsschicht des Racks. Ein zentrales Dashboard überwacht GPU- und Fabric-Auslastung, Verbindungsstatus und Fehlerereignisse. Bei Störungen werden die laufenden Behebungsmaßnahmen angezeigt und Warnmeldungen ausgegeben, die Betreiber in ihre eigenen Tools integrieren können. Der obige Screenshot zeigt AFM bei der Überwachung eines Helios-Clusters in den AMD-Laboren. Die Verwaltung erfolgt sowohl in- als auch out-of-Band, sodass Diagnose und Konfiguration laufende Workloads nicht beeinträchtigen. Die Switches unter AFM verwenden ein Netzwerkbetriebssystem auf Basis von SONiC, dem Open-Source-NOS. AMD gibt an, dass die UALoE-Erweiterungen in den Upstream-Code integriert und über die Standard-gNMI-APIs bereitgestellt werden. Über dem Rack kümmert sich ein Rack Infrastructure Manager um den Lebenszyklus von Knoten und Switches, die Stromversorgung und die Leckageerkennung, und ein Cluster Controller verbindet Helios mit Kubernetes und Slurm zur Terminplanung.

Helios vs. NVIDIA Vera Rubin NVL72

Schauen wir uns also an, wie sich das im Vergleich zu dem NVIDIA-Angebot schlägt, dem Helios tatsächlich auf dem Markt begegnen wird: dem Vera Rubin NVL72.

Rack-Metrik	AMD Helios	Vera Rubin NVL72
GPUs	72 MI455X	72 Rubin
CPUs	18 Venedig	36 Vera
HBM-Kapazität	31TB	20.7TB
HBM-Bandbreite	1.7 PB/s	1.58 PB/s
Skalierung pro GPU	3.6 TB / s	3.6 TB / s
Rack-Scale-up	260 TB / s	260 TB / s
Skalierung pro GPU	2,400 Gb / s	1,600 Gb / s
Scale-up-Schalter	12 Tomahawk 6	36 NVSwitch 6
Rack-Format	Doppelbreites ORW	Single-wide MGX

Auf dem Papier spricht die Punktetabelle für AMD: 50 % mehr HBM, dieselbe Scale-up-Geschwindigkeit von 3.6 TB/s pro GPU dank nur eines Drittels der Switch-ASICs und 50 % mehr Scale-out-Bandbreite pro GPU. AMDs interne Tests wandeln diese Spezifikationen in Leistungsangaben um und erzielen 10 bis 15 % mehr Token pro Sekunde und GPU auf Kimi K2 Thinking sowie bis zu 30 % mehr Token pro Dollar. Diese Zahlen von AMD im Vergleich zu den veröffentlichten Zahlen von NVIDIA sind keine unabhängigen Messungen, aber sie setzen den Maßstab, an dem AMD gemessen werden will. Die interessanteren Unterschiede liegen jedoch darin, wie die jeweiligen Designs ihre GPUs mit der Außenwelt verbinden.

Beginnen wir mit der Skalierung. Die Netzwerkkarten des MI455X sind direkt an die GPU angeschlossen. Laut SemiAnalysis ist dies bei Rubin nicht der Fall: Demnach fehlt dem Gehäuse die PCIe-Schnittstelle, um beide ConnectX-9-Netzwerkkarten zu versorgen. Daher sind diese stattdessen an die Vera-CPU angeschlossen, wodurch der GPU-Datenverkehr einen längeren Weg nimmt: Rubin → NVLink-C2C → Vera → PCIe → ConnectX-9. Dieser Umweg verursacht einen zusätzlichen Latenz-Hop und beansprucht die C2C-Verbindung doppelt. Da Rechenleistung, Host-Datenverkehr und Netzwerk gleichzeitig voll ausgelastet sind, wird ein Teil der C2C-Bandbreite von Vera für die Übertragung der Netzwerkkarten-Nutzdaten benötigt, und die effektive Host-Bandbreite, die einer GPU zur Verfügung steht, sinkt unter die angegebenen 1.8 TB/s.

Die Bandbreitenberechnung verstärkt diesen Effekt. Jede MI455X-Karte erhöht die Scale-Out-Geschwindigkeit um 2,400 Gbit/s auf die 1,600 Gbit/s von Rubin, sodass Helios mehr Netzwerkleistung pro FLOP bietet. AMDs Simulationen eines Trainingslaufs mit 8,000 GPUs bestätigen, dass die dritte Netzwerkkarte eine um etwa 13 % schnellere Jobabwicklung ermöglicht.

Rubin kontert beim Speicher, und der Grund dafür liegt erneut in der Position der Netzwerkkarte. ConnectX-9 verfügt über einen integrierten PCIe-Switch, sodass NVMe-SSDs direkt an die Netzwerkkarte angeschlossen werden können und eine GPU Daten über GPUDirect Storage abrufen kann, ohne die CPU zu belasten. Der MI455X bietet kein Äquivalent: Sein Speicher ist an den Venice-Host angebunden, sodass alle GPUDirect-Daten über die CPU und die Infinity Fabric-Verbindung übertragen werden müssen. AMD optimierte den Netzwerkpfad und zahlte dies auf Kosten des Speicherpfads; NVIDIA ging den umgekehrten Weg. Welcher Aspekt wichtiger ist, hängt davon ab, ob eine Arbeitslast das Verschieben von Aktivierungen zwischen GPUs oder das Streamen von Daten von der Festplatte erfordert.

Was Kunden ändern können

Kurz gesagt, beschreibt alles oben Genannte das Referenzdesign von AMD, wobei einige der genannten Werte Mindestanforderungen darstellen, die Kunden übertreffen können. Das offensichtlichste Beispiel ist die Host-CPU. Rubins Vera wird in einer festen Konfiguration geliefert; die Venice im Helios-Tray ist eine Standard-SP7-CPU mit Sockel, und AMD bestätigte, dass jede Venice-Variante ohne Helios-spezifische Anpassungen kompatibel ist. Der Referenz-Tray verwendet die 96-Kern-CPU mit 5 GHz, da die Single-Thread-Geschwindigkeit die GPUs ausreichend mit Daten versorgt. Dennoch steht es jedem Kunden frei, seine Version mit dem 256-Kern-Flaggschiff oder der Venice-X mit ihren 1,152 MB gestapeltem L3-Cache für cacheintensive Vorverarbeitung zu konfigurieren.

Speicher und Netzwerk folgen der gleichen Steckplatzlogik. Die Referenzkonfiguration von 1 TB DRAM besteht aus 16 64-GB-RDIMMs; mit dichteren DIMMs lässt sich ein Tray auf 4 TB erweitern, und MRDIMM-12800 ermöglicht die volle Übertragungsrate von Venice mit 1.6 TB/s. Netzwerkseitig kann die Anzahl der NICs pro GPU von 3 auf 2 über PCIe Gen 6 reduziert werden; jeder Vulcano-Port kann mit 1x800G, 2x400G, 4x200G oder 8x100G an Tomahawk 5- oder Tomahawk 6-Fabrics betrieben werden, und die P4-Pipeline überlässt die Wahl des Transportprotokolls (RoCEv2, MRC oder proprietär) dem Betreiber. Selbst die Managementebene ist austauschbar, da das Switch-NOS auf Open-Source-SONiC basiert und AFM das gesamte Fabric über seine Northbound-API zugänglich macht.

Das Leistungsbudget richtet sich ebenfalls nach dem Sockel. NVIDIAs Superchips teilen sich ein gemeinsames Gehäuse: Vera ist ein 450-Watt-Chip mit einer begrenzten Leistungsaufnahme, während neuere Generationen unter Last die Leistung zu den GPUs hin verteilen. AMD hat nicht angegeben, ob das Referenzdesign die Leistung begrenzt oder die Host-Leistung umverteilt. Bei AMDs Design liegt die Entscheidung jedoch beim Kunden, der das System mit höherem Stromverbrauch ohne Leistungsschwankungen anpassen kann.

Die PCIe-Grundlagen der Host-Verbindung, die im Compute Tray-Bereich weiter unten zu finden sind, eröffnen eine letzte, wenn auch spekulative Möglichkeit. Venice unterstützt 2P-Konfigurationen, und ausgewählte KI-Host-Plattformen können 2P mit bis zu 160 nutzbaren PCIe-Lanes betreiben, indem die xGMI-Breite zwischen den Sockeln gegen I/O-Kapazität getauscht wird. Theoretisch könnte ein Kunde ein Zwei-Sockel-Tray entwickeln, um NVIDIAs CPU-zu-GPU-Verhältnis von 1:2 zu erreichen, oder die xGMI-Verbindungen optimieren, um die effektive CPU-zu-GPU-Bandbreite zu erhöhen. Nichts deutet darauf hin, dass dies aktuell umgesetzt wird, und nichts davon schließt die Lücke zu NVLink-C2C mit 1.8 TB/s. Der entscheidende Punkt ist, wer die Kontrolle hat: Bei Helios liegen Host, Speicher, Stromversorgung und potenziell auch Topologie in der Verantwortung des Kunden, während NVIDIAs Superchip ihm keinerlei Einflussmöglichkeiten lässt.

Die Salina DPU

Nun zurück zum Frontend-Netzwerk, das wir vorhin besprochen haben. Salina, AMDs Pensando DPU der dritten Generation, ist eine 400G-Karte mit einem vollständig P4-programmierbaren Datenpfad. Das bedeutet, dass neue Kapselungen, Telemetrie-Anschlüsse oder Transportprotokolle per Firmware-Update live eingespielt werden können, ohne den Datenverkehr zu unterbrechen. Die verfügbaren Dienste decken bereits alle Anforderungen des Frontends ab: SDN mit VXLAN oder NVGRE, eine zustandsbehaftete Firewall mit Skalierbarkeit auf Millionen von Regeln, IPsec mit Leitungsgeschwindigkeit, PSP, DTLS oder benutzerdefinierte Verschlüsselung, NAT und Load Balancing. Sie ist zudem die am besten bewährte Chiptechnologie im Rack. Pensando DPUs sind seit 2019 bei Hyperscalern im Einsatz; Salina wird heute bei Microsoft, Oracle und IBM eingesetzt; Oracle schreibt der Produktlinie einen fünffachen SDN-Gewinn zu, und ein Hyperscaler konnte durch die Auslagerung von E/A-Operationen 22 CPU-Kerne pro Server einsparen.

Speicher ist der zweite Akt. Salina stellt NVMe-over-Fabrics-Geräte für den Host bereit und virtualisiert entfernte SSD-Pools über TCP oder RDMA. Verschlüsselung, Hash-Werte und Komprimierung erfolgen dabei auf der Karte. Auf Helios kommt ein Trick aus der Agenten-Ära hinzu: Eine Kontext-Speicher-Engine stellt ein emuliertes Key-Value-Gerät bereit. Dadurch wird ein überlaufender Key-Value-Cache in den CPU-DRAM, die lokale SSD oder den entfernten Speicher ausgelagert und mit Leitungsgeschwindigkeit zurück in den HBM gestreamt, anstatt neu berechnet zu werden. Wie im Vergleich mit Rubin erwähnt, fehlt dem MI455X GPUDirect Storage; diese Key-Value-Auslagerung ist AMDs Teillösung für den wichtigsten Aspekt der Datenverarbeitung.

Hier liegen auch unsere Bedenken. Der Bandbreitenunterschied ist offensichtlich: Salina ist eine 400G-Karte, während die in Vera-Rubin-Racks verbaute BlueField-4 mit einer 64-Kern-Grace-CPU und dem integrierten ConnectX-9 die Bandbreite auf 800G verdoppelt. Der Softwareunterschied ist zwar umstrittener, aber dennoch real. NVIDIAs DOCA bietet Entwicklern containerisierte, vorkonfigurierte Dienste, die in herkömmlichem C und C++ programmierbar sind; P4 hingegen ist eine spezialisierte Datenebenensprache, mit der die meisten Teams noch nie gearbeitet haben. Der Vergleich lautet nicht „DOCA-Katalog versus reines P4“, da Salina seine wichtigsten Dienste vollständig ausliefert und die Hyperscaler, die es einsetzen, es unter anderem deshalb gewählt haben, weil P4 die Integration neuer Protokolle wie MRC in die Firmware ermöglicht, noch bevor der Siliziumzyklus anderer Hersteller erreicht ist. Der eigentliche Unterschied liegt darin, wem die Programmierbarkeit dient. Salinas Flexibilität ist ein Vorteil für AMD und Hyperscale-Teams mit fundierten P4-Kenntnissen; DOCA ist ein Toolkit, das auch von Entwicklern in Unternehmen problemlos genutzt werden kann. Für den breiten Markt ist der Software-Einstieg von NVIDIA einfacher, und AMD weiß das.

ROCm.AI

Apropos Software: AMD hat eine seiner wichtigsten Ankündigungen für die GPU-Plattform selbst aufgehoben. ROCm.AI, das im August erscheint, ist AMDs Versuch, die GPU-Plattform von Grund auf autark zu gestalten. AI Skills integrieren ROCm in die bereits von Entwicklern genutzten Coding-Agenten Claude, Codex, Cursor und Gemini. Dadurch erfolgen Installation, Bereitstellung und Debugging auf Instinct in natürlicher Sprache. Hyperloom ist das noch wichtigere Element: ein vollautomatischer Optimierer, der Arbeitslasten analysiert, die Bereitstellungskonfiguration anpasst, GPU-Kernel neu schreibt und die Ergebnisse validiert, während der Benutzer nicht arbeitet. Laut AMD werden aktuell rund 14,000 Modelle kontinuierlich optimiert, und eine Live-Demo erzielte eine um 38 % höhere Leistung der MiniMax M3. Unterhalb der Agenten ermöglicht FlyDSL eine nahezu Assembler-basierte Steuerung von Python, ROCm wird nun im festen 6-Wochen-Rhythmus veröffentlicht, und AMD gibt an, dass ROCm.AI im Vergleich zu ROCm 7 auf identischer Hardware eine durchschnittliche 3.3-fache Inferenz- und eine 2.4-fache Trainingsleistung erzielt. ROCm 7 brachte bereits deutliche Verbesserungen; nun setzt AMD auf KI, um diese Entwicklung weiter zu beschleunigen.

Die wohl wichtigste Folie der Software-Session befasste sich mit der Hardware. AMD betonte nachdrücklich, dass alle Angaben darauf gemessen wurden. Die Aussage implizierte, dass der MI455X-Chip bereits heute unter ROCm einsatzbereit und schnell ist. Die Ergebnisse: 20 TB/s bei der FP8-MLA-Dekodierung, 20 PFLOPS FP4-Rechenleistung, 3.2 TB/s Scale-up-Bandbreite und 190 GB/s Scale-out-Bandbreite. In der anschließenden Fragerunde räumte AMD ein, dass das FP4-Ergebnis eine Messung der maximal erreichbaren Matrixmultiplikations-FLOPS (MAMF) darstellt, durchgeführt mit der Matrixform, die die Leistung des Chips am besten zur Geltung bringt – ein Standardverfahren für diese Art von Benchmark. Es ist zudem eine gewagte Offenlegung: AMD gibt offen zu, dass der MI455X etwa 50 % seiner maximalen MXFP4-Leistung von 40.26 PFLOPS erreicht – eine Zahl, die die meisten Hersteller verschweigen würden.

AMD bezeichnet dies als die höchste demonstrierte Rechenleistung aller derzeit erhältlichen Beschleuniger – doch Vorsicht ist geboten. AMDs FP4 basiert auf OCP MXFP4, NVIDIAs auf NVFP4. Die zugrundeliegenden Verfahren unterscheiden sich: NVFP4 wendet eine fraktionale FP8-Skalierung auf jeden 16-Element-Block an, zusätzlich eine Skalierung auf Tensor-Ebene. Das Basis-MXFP4 hingegen verwendet eine gröbere Zweierpotenz-Skalierung pro 32 Elemente. Daher kann ein NVFP4-Flop mehr Arbeit bewältigen als ein MXFP4-Flop. CDNA 5 kann ebenfalls fraktionale Skalierung auf MXFP4 anwenden, AMD hat jedoch nicht angegeben, welches Verfahren für die Messung verwendet wurde. Ein Rubin-MAMF-Lauf und ein MI455X-MAMF-Lauf messen nicht dieselben mathematischen Operationen. Daher sind herstellerübergreifende FP4-Vergleiche nur auf Anwendungsebene aussagekräftig: Token pro Sekunde bei gleicher Genauigkeit. Gemessene Ergebnisse übertreffen die Prognosen, aber diese Zahlen lesen sich am ehrlichsten im Vergleich zur vorherigen Generation von AMD, wo die 3- bis 4-fachen Leistungssteigerungen eindeutig sind.

Es gibt aber auch einen Vorteil für AMD. Da es sich hier um erste Ergebnisse von ROCm.AI auf brandneuen Chips handelt, unterschätzen sie eher das Potenzial einer präzise abgestimmten Produktionsumgebung. Das endgültige Urteil wird fallen, sobald diese Racks bei Hyperscalern zum Einsatz kommen.

Abschließende Gedanken

Helios ist das bisher umfassendste System von AMD und das erste, das NVIDIA auf Rack-Ebene statt auf Chip-Ebene direkt Paroli bietet. Die Leistungsbilanz spricht für AMD in den Bereichen, die heute die KI-Leistung bestimmen: 50 % mehr HBM pro GPU, Scale-up-Parität mit Rubin, 50 % mehr Scale-out-Bandbreite und, laut AMDs eigenen Berechnungen, bis zu 30 % mehr Token pro Dollar. Ebenso wichtig ist der Weg dorthin: Tomahawk-Switches von Drittanbietern, offene Standards von den Nummernformaten bis zum Gehäuse und ein gesockelter Host, der die endgültige Konfiguration dem Kunden überlässt. NVIDIA behält zwar echte Vorteile bei der C2C-Host-Verbindung, der DPU und der Software-Anbindung, aber zum ersten Mal spricht die Hardware-Argumentation auf dem Papier für AMD.

Und die Käufer stimmen zu. OpenAI, Meta, Anthropic, Microsoft und Oracle gehören laut AMD zu den Unternehmen, die Helios einsetzen, und AMD betont, dass die Racks bereits in Produktion sind. Nach dem Vorbild von NVIDIA folgt die Roadmap nun einem jährlichen Rhythmus: Die auf CDNA 6 basierende MI500-Serie erscheint 2027 mit HBM der nächsten Generation sowie Kupfer- und optischen Verbindungen, und die MI600-Serie befindet sich bereits für 2028 in Entwicklung.

Bleibt also die Software, und zum ersten Mal seit Jahren beenden wir unsere Berichterstattung über AMD-GPUs nicht mit diesem Vorbehalt. ROCm 7 hat deutliche Lücken geschlossen, ROCm.AI erscheint im August mit weiteren messbaren Verbesserungen, und der Veröffentlichungszyklus beträgt nun feste sechs Wochen. Es kommt auch darauf an, wer kauft. Die Labore und Hyperscaler, die diese Verträge abschließen, entwickeln gemeinsam mit AMD und beschäftigen genügend Ingenieure, um auftretende Probleme zu beheben. Unternehmen, die eine schlüsselfertige Lösung benötigen, sind eine andere Geschichte, und dieser Markt bleibt vorerst NVIDIAs. Helios wurde jedoch für die Hyperscaler und KI-Labore entwickelt, und für sie ist die Hardware bereit, die Software hält Schritt, und die Racks werden ausgeliefert. AMD war noch nie so stark aufgestellt.