AMD Helios vereint 72 GPUs, doch Nvidia setzt den Maßstab

AMD hat Helios als ein einzelnes System mit 72 GPUs vorgestellt, nicht als lose Sammlung von Accelerator-Servern, die innerhalb eines Schranks verbunden sind. Der Architekturbericht von AMD ServeTheHome ist wichtig, weil das Unternehmen nun nahezu jede wesentliche Schicht seines KI-Racks kontrolliert.

Helios kombiniert Instinct-MI455X-Accelerators, EPYC-Venice-Prozessoren, Pensando-Netzwerktechnik, ROCm-Software und flüssigkeitsgekühlte Stromversorgungsinfrastruktur. Broadcom liefert die Ethernet-Switching-Chips aus dem Handel, welche die GPUs über ein gemeinsames Scale-up-Fabric verbinden.

Diese Kombination schafft den eigentlichen Konflikt. AMD fordert Nvidia nicht mehr nur mit einer Accelerator-Karte heraus. Das Unternehmen greift Nvidias Rack-Scale-Modell an und lehnt zugleich den geschlossenen Netzwerkansatz ab, der Nvidias Systeme schwer kopierbar gemacht hat.

Helios wirkt auf dem Papier überzeugend. Spitzenwerte bei den Spezifikationen belegen jedoch weder die tatsächlich erzielte Anwendungsleistung noch Software-Reife, Liefermengen oder Betriebskosten. Diese offenen Fragen werden entscheiden, ob Offenheit zum Beschaffungsvorteil oder lediglich zu einer Architekturpräferenz wird.

Was die AMD-ServeTheHome-Berichterstattung über Helios verrät

Helios verschiebt AMDs Wettbewerbseinheit von einer einzelnen GPU hin zu einem integrierten KI-Rack.

Das System umfasst 72 Instinct-MI455X-Accelerators in 18 flüssigkeitsgekühlten Compute-Trays. Jedes Tray trägt vier GPUs und einen Sockel für einen EPYC-9006-Prozessor der sechsten Generation mit dem Codenamen Venice.

AMD ordnet jeder MI455X 432 GB HBM4-Speicher zu. Über das gesamte Rack ergibt das rund 31 TB High-Bandwidth-Memory, die innerhalb der Scale-up-Domäne verfügbar sind.

High-Bandwidth-Memory oder HBM sitzt nahe an der GPU und liefert Daten mit deutlich höheren Raten als herkömmlicher Serverspeicher. Diese Kapazität ist für große Modelle, lange Kontexte, Inferenz-Caches und Workloads wichtig, die andernfalls stärker partitioniert werden müssten.

AMD nennt in seiner Dokumentation zur CDNA-5-Architektur für jede MI455X bis zu 23,3 TB/s Speicherbandbreite. Das Rack bündelt diese Geräte zu einem Speichersystem mit mehr als einem Petabyte pro Sekunde theoretischer Bandbreite.

Das physische Layout ist ebenso wichtig wie die Zahl der Accelerators. Helios verwendet einen Open Compute Project Open Rack Wide-Rahmen, der breiter als ein herkömmliches Rack ist. Das Design schafft Platz für dichte Compute-Trays, Verkabelung, Stromversorgung und Flüssigkeitskühlung.

Das Rack umfasst sechs Scale-up-Switch-Trays. Jedes Tray enthält zwei Broadcom-Tomahawk-6-Switch-Chips, sodass Helios insgesamt 12 Switch-Chips nutzt.

Jeder Tomahawk-6-Chip bietet 102,4 Tbps Switching-Kapazität. Seine Ethernet-Lanes bilden das interne Fabric, über das jeder Accelerator mit jedem anderen Accelerator über einen einzigen Switch-Hop kommunizieren kann.

Dieses Fabric transportiert UALink über Ethernet, oft zu UALoE verkürzt. UALink definiert eine Scale-up-Verbindung für Accelerators, während Ethernet den zugrunde liegenden Transport und die Switching-Hardware aus dem Handel bereitstellt.

AMD zufolge erhält jede MI455X 3,6 TB/s bidirektionale Scale-up-Bandbreite. Über 72 Geräte hinweg erreicht der Gesamtwert etwa 260 TB/s.

Das ist der Mechanismus hinter AMDs Aussage, Helios verhalte sich wie ein einzelnes System mit 72 GPUs. Herkömmliche Cluster teilen die Speicherhoheit häufig auf separate Server auf und übertragen Daten dann über mehrere Netzwerkstufen.

Helios reduziert diese Grenzen innerhalb des Racks. Es enthält weiterhin separate Prozessoren und Speichergeräte, doch sein Single-Hop-Fabric bietet der Software eine enger verknüpfte Accelerator-Domäne.

Die MI455X-Spezifikationen von AMD zeigen zudem, wie viel Netzwerktechnik auf das GPU-Paket verlagert wurde. Jedes Accelerator-Modul umfasst zwei erweiterte I/O-Dies und 36 bidirektionale UALoE-Links.

Diese Änderung macht Netzwerktechnik zu einem Teil der Accelerator-Architektur. Sie ist nicht länger ein Zubehör, das erst nach dem Entwurf der Compute-Plattform ausgewählt wird.

Helios verwendet außerdem Pensando-Hardware für die Kommunikation außerhalb der Scale-up-Domäne. Jede GPU kann sich mit drei Vulcano-Netzwerkschnittstellenkarten mit 800 Gbps verbinden und erhält damit bis zu 2,4 Tbps Scale-out-Bandbreite pro Accelerator.

Scale-out-Netzwerke verbinden mehrere Racks zu einer größeren Bereitstellung. Eine Pensando-Salina-Datenverarbeitungseinheit verarbeitet Front-End-Datenverkehr, einschließlich Verwaltung, Speicherzugriff und Anwendungsanfragen.

Das Rack enthält daher zwei getrennte Netzwerkschichten. Broadcom-Silizium verbindet die Accelerators innerhalb von Helios, während AMD-Pensando-Geräte Helios mit Speicher, Diensten und anderen Racks verbinden.

Die Stromversorgung komplettiert das System. Eine rückseitige 50-Volt-Gleichstrom-Stromschiene versorgt das Rack, und Flüssigkeitskühlung führt die Wärme seiner dicht gepackten Komponenten ab.

Berichte von AMDs Advancing-AI-Veranstaltung bezifferten die Last des Racks auf 225 kW bis 245 kW. Diese Anforderung macht Helios für Rechenzentrumshallen ohne Unterstützung für hohe Leistungsdichte und Flüssigkeitskühlung ungeeignet.

Laut veröffentlichten Plattformdetails kann das Rack zudem etwa 5.000 Pfund wiegen. Käufer müssen die Bereitstellung als Infrastrukturprojekt behandeln, nicht als routinemäßige Server-Erneuerung.

Der Architektur-Fokus von ServeTheHome ist daher gerechtfertigt. Das zentrale Produkt ist die Integration selbst, einschließlich Compute, Speicher, Netzwerktechnik, Stromversorgung, Kühlung, Mechanik und Software.

Warum AMD jetzt das gesamte Rack bauen musste

Nvidia hat jeden ernstzunehmenden Accelerator-Anbieter gezwungen, auf Systemebene zu konkurrieren.

Moderne KI-Workloads verbringen viel Zeit damit, Daten zwischen Accelerators zu verschieben. Schnellere Rechenleistung hilft nur dann, wenn Modelle, Aktivierungen und Zwischenergebnisse die Rechenwerke ohne lange Wartezeiten erreichen können.

Diese Realität begünstigt Systeme, die als koordinierte Einheiten konzipiert sind. Nvidia etablierte dieses Modell mit seinen NVL72-Plattformen, die 72 GPUs, CPUs, NVLink-Switching, Netzwerktechnik, Kühlung und Software kombinieren.

AMD verkaufte zuvor wettbewerbsfähige Accelerators, die Systemanbieter zu Servern und Clustern zusammensetzten. Dieses Modell bot Kunden Wahlfreiheit, ließ jedoch mehr Integrationsarbeit außerhalb der direkten Kontrolle von AMD.

Das Unternehmen konnte eine GPU verbessern und auf Systemebene dennoch verlieren. Netzwerktopologie, kollektive Kommunikation, Kühlgrenzen, Software-Tuning und Serverdesign konnten einen auf dem Accelerator gemessenen Vorteil aufzehren.

Helios begegnet dieser Schwäche mit einer vollständigen Referenzarchitektur. AMD spezifiziert das Compute-Tray, die Scale-up-Topologie, das Scale-out-Netzwerk, das Rack-Format, die Stromversorgung, den Kühlansatz und die zugehörige Software.

Der Zeitpunkt spiegelt auch die Einführung von CDNA 5 wider, AMDs jüngster dedizierter Compute-Architektur für Rechenzentren. MI455X nutzt acht Compute-Chiplets, die in einem 2-nm-Prozess gefertigt werden, und platziert sie über zwei 3-nm-Dies für Fabric und Cache.

Zwei zusätzliche I/O-Dies verwalten die externe Kommunikation. Zwölf HBM4-Stacks umgeben die Logik, während fortschrittliche Packaging-Technik die Komponenten zu einem Accelerator-Modul verbindet.

Dieses Chiplet-Design ermöglicht AMD, verschiedene Funktionen mit unterschiedlichen Fertigungsprozessen zu optimieren. Compute-Dichte, Speicherschnittstellen, Cache und Netzwerktechnik benötigen nicht alle dieselben Siliziumeigenschaften.

MI455X enthält 320 Milliarden Transistoren und 256 Work-Group-Prozessoren. Ein Work-Group-Prozessor organisiert Ausführungsressourcen, die Gruppen von KI- und wissenschaftlichen Rechenoperationen verarbeiten.

AMD zielt mit Formaten wie MXFP4, MXFP6, MXFP8 und FP8 auf KI-Berechnungen mit niedriger Präzision. Diese Formate stellen Modellwerte mit weniger Bits dar und erhöhen den Durchsatz, wenn eine Anwendung eine akzeptable Genauigkeit bewahren kann.

Der Accelerator erreicht einen angegebenen Spitzenwert von 40,3 Petaflops für MXFP4-Operationen. Über das Rack hinweg bewirbt AMD bis zu 2,9 Exaflops FP4-Spitzenleistung und 1,4 Exaflops bei FP8.

Diese Werte sind theoretische Spitzen, keine gemessenen Ergebnisse für ein vollständiges Modell. Sie erklären jedoch, warum die Rack-Integration gemeinsam mit der MI455X eingeführt wurde.

Ein einzelner Accelerator bewegt inzwischen genug Daten und verbraucht genug Energie, dass sein umgebendes System bestimmt, ob Anwendungen die verfügbare Rechenleistung nutzen können. AMD benötigte Helios, um die Fähigkeiten von CDNA 5 in relevantem Maßstab verfügbar zu machen.

Das Unternehmen übernahm 2025 zudem ZT Systems und gewann damit Engineering-Erfahrung im Hyperscale-Rack-Design. AMD gliederte das Fertigungsgeschäft später aus und begrenzte damit die direkte Konkurrenz zu etablierten Serverpartnern.

Diese Transaktion verschaffte AMD tiefere Systemkompetenz, ohne dass das Unternehmen zum alleinigen Helios-Anbieter werden musste. HPE, Supermicro, Cloud-Anbieter und andere Partner können Produkte auf Grundlage des Referenzdesigns bauen.

Microsoft hat Pläne angekündigt, Helios in seinen Rechenzentren einzusetzen. HPE hatte sich zuvor zur Übernahme der Architektur verpflichtet und verschafft AMD damit Wege in Hyperscale- wie auch Unternehmensinfrastrukturen.

AMD erklärte auf der CES, Helios werde als Blaupause für deutlich größere KI-Systeme dienen. Seine Rack-Scale-Vorschau verknüpfte das Design mit Training, Inferenz und künftigen Multi-Rack-Bereitstellungen.

Der Druck reicht daher über Nvidia hinaus. Serverhersteller müssen entscheiden, wie viel AMD-Engineering sie übernehmen wollen, während Cloud-Anbieter entscheiden müssen, ob eine offene Referenzplattform das Integrationsrisiko verringert.

Auch Chipzulieferer sehen sich mit einem neuen Beschaffungsmuster konfrontiert. Kunden bewerten Accelerators zunehmend als Teile vollständiger Systeme und nicht als austauschbare Karten mit isolierten Benchmark-Ergebnissen.

Offenes Ethernet ist AMDs wichtigste Herausforderung für Nvidia

Der zentrale Wettbewerb besteht zwischen AMDs offenem Ethernet-Rack und Nvidias vertikal kontrollierter NVLink-Plattform.

Helios ähnelt Nvidias Vera Rubin NVL72 in mehreren wichtigen Punkten. Beide verteilen 72 Accelerators auf 18 flüssigkeitsgekühlte Compute-Trays und nutzen dedizierte Switch-Trays für Kommunikation mit hoher Bandbreite.

Der Unterschied liegt in der Kontrolle über das Scale-up-Netzwerk. Nvidia integriert NVLink und NVLink-Switching in seine Plattform und erhält damit direkte Kontrolle über Protokoll, Silizium, Topologie und Software-Integration.

AMD verwendet einen offenen Accelerator-Link, der über Ethernet transportiert wird. Broadcom liefert die Tomahawk-6-Switch-Chips, während UALink definiert, wie Accelerators über dieses Fabric kommunizieren.

Diese Wahl ermöglicht AMD den Einsatz von Netzwerktechnik aus dem Handel statt einer proprietären Switch-Architektur. Systemanbieter und Hyperscaler können mit vertrauten Ethernet-Tools, Lieferanten und Betriebspraktiken arbeiten.

Offenheit bedeutet nicht, dass jede Komponente ohne Engineering-Aufwand ausgetauscht werden kann. Scale-up-Netzwerke stellen strenge Anforderungen an Latenz, Überlastung, Zuverlässigkeit, Synchronisierung und Software.

Veröffentlichte Schnittstellen geben Partnern jedoch mehr Spielraum, das Rack anzupassen. Ein Cloud-Anbieter kann Netzwerktechnik, Verwaltung oder Bereitstellungsentscheidungen anpassen, ohne bei jeder Schicht von einem Anbieter abhängig zu sein.

Die Rolle von Broadcom macht diese Behauptung konkreter. Tomahawk 6 stellt 512 Lanes mit 200 Gbps bereit – genug Kapazität, um die 72 GPUs mit der von AMD genannten Scale-up-Rate zu versorgen.

Der Helios-Architekturbericht zeigt, warum diese Partnerschaft wichtig ist. AMDs Hardware-Portfolio ist breit, doch das Unternehmen muss nicht jede Komponente selbst fertigen, um das Systemdesign zu kontrollieren.

Damit entsteht eine koalitionsbasierte Alternative zu Nvidia. AMD liefert die GPUs, CPUs, Pensando-Netzwerkgeräte, Software und Plattform-Engineering. Broadcom liefert die zentralen Scale-up-Switch-Chips.

HPE und andere Hersteller können diese Blaupause anschließend in Systeme umsetzen. Cloud-Betreiber können diese Systeme bereitstellen und dabei mehr Einfluss auf Netzwerk- und Softwareentscheidungen behalten.

Nvidia verfolgt den gegenteiligen Ansatz. Die stärkere Integration verringert die Zahl externer Variablen und bietet Kunden eine von einem einzigen Anbieter optimierte Plattform.

Diese Kontrolle kann die Leistungsoptimierung vereinfachen. Nvidia kann GPU-Verhalten, Switch-Silizium, Kommunikationsbibliotheken, Treiber, Netzwerke und Anwendungs-Frameworks über eine einheitliche Roadmap koordinieren.

AMD setzt darauf, dass offene Standards eine vergleichbare Effizienz erreichen können, ohne dass ein Unternehmen jedes Glied der Kette besitzen muss. Dieses Versprechen muss sich in realen Workloads bewähren, nicht nur in Topologiediagrammen.

Die beiden Systeme unterscheiden sich auch außerhalb des Racks. Helios weist jedem Beschleuniger drei 800-Gbps-Vulcano-Schnittstellen zu und erreicht damit 2,4 Tbps Scale-out-Bandbreite pro GPU.

Veröffentlichte Vera-Rubin-Konfigurationen koppeln jede GPU an eine 1,6-Tbps-ConnectX-9-Schnittstelle. AMD beansprucht daher 50 Prozent mehr Scale-out-Bandbreite pro Beschleuniger.

Dieser Vergleich begünstigt Workloads, die sich über mehrere Racks erstrecken – vorausgesetzt, die Software kann die Verbindungen effizient nutzen. Große Trainingsjobs und verteilte Inferenzdienste sind auf diese Ebene angewiesen, wenn ein einzelnes Rack nicht den gesamten Workload aufnehmen kann.

AMD beansprucht außerdem mehr Speicherkapazität und Bandbreite. Helios bietet 31 TB HBM4 im Rack; laut AMD entspricht das 50 Prozent mehr Kapazität als bei der konkurrierenden Nvidia-Plattform.

Mehr Speicherkapazität kann die Aufteilung von Modellen verringern und mehr Platz für Key-Value-Caches schaffen. Ein Key-Value-Cache speichert Aufmerksamkeitsdaten, damit ein Inferenzsystem spätere Tokens erzeugen kann, ohne den vorherigen Kontext erneut berechnen zu müssen.

Dieser Vorteil ist besonders für Long-Context-Inferenz und Modelle relevant, die viele parallele Anfragen bedienen. Doch Kapazität allein bestimmt weder Latenz noch Durchsatz.

Software-Scheduling, Kernel-Qualität, Kommunikationseffizienz und die Form des Workloads bestimmen weiterhin, wie viel nutzbare Leistung bei Kunden ankommt. Nvidias CUDA-Umgebung bleibt für viele KI-Teams der etablierte Referenzpunkt.

ROCm hat sich über mehrere Instinct-Generationen hinweg verbessert, und wichtige Frameworks unterstützen inzwischen AMD-Hardware. Helios legt AMD dennoch stärker in die Pflicht, 72 Beschleuniger als eine Plattform vorhersehbar arbeiten zu lassen.

Der Wettbewerb zwischen offen und kontrolliert ist daher nicht philosophisch. Es ist eine messbare Frage, ob eine partnerbasierte Architektur bei tatsächlich bereitgestellter Leistung und Zuverlässigkeit mit einer integrierten Plattform mithalten kann.

Die Spezifikationen entscheiden nicht über die Leistung

AMDs stärkste Kennzahlen bleiben Herstellerangaben, bis unabhängige Tests auf Rack-Ebene sie bestätigen.

AMD behauptet, Helios liefere pro Beschleuniger 15 Prozent mehr FP4-Spitzenleistung als das führende Konkurrenzsystem. Zudem prognostiziert das Unternehmen eine um bis zu 30 Prozent bessere Token-Ökonomie.

Diese Angaben erfordern eine sorgfältige Einordnung. FP4-Spitzenrechenleistung beschreibt die schnellste unterstützte Low-Precision-Operation unter Idealbedingungen, nicht die nachhaltige Geschwindigkeit eines eingesetzten Modells.

Ein Vergleich von Tokens pro Dollar setzt noch mehr Annahmen voraus. Hardwareauslastung, Strom, Kühlung, Softwarelizenzen, Personal, Modellgenauigkeit, Batch-Größe und Systemverfügbarkeit beeinflussen alle das Ergebnis.

AMD hat keine öffentlichen Preise in einer Form offengelegt, die einen neutralen Vergleich der Gesamtbetriebskosten ermöglicht. Käufer werden außerdem Hardware-, Support-, Netzwerk- und Bereitstellungsvereinbarungen in unterschiedlichem Umfang verhandeln.

Kennzahlen auf Rack-Ebene verkomplizieren die Leistungsfrage. AMD nennt für Helios 2,9 Exaflops FP4-Spitzenleistung, während Nvidia für Vera Rubin NVL72 einen höheren Rack-Wert von 3,6 Exaflops veröffentlicht hat.

Die Definitionen hinter diesen Zahlen können unterschiedlich sein. Nvidias Ergebnis kann Kompressionsverhalten einbeziehen, das für einige Inferenzaufgaben geeignet ist, während AMD rohe unterstützte Präzisionsraten hervorhebt.

Der Rack-Vergleich von The Register wies auf diesen Unterschied hin. Manche Workloads können von Nvidias adaptiver Komprimierung profitieren, während andere Berechnungen benötigen, die stärker mit AMDs unkomprimierter Kennzahl übereinstimmen.

Keiner der Vergleiche liefert einen universellen Sieger. Training, Fine-Tuning, dichte Inferenz, Mixture-of-Experts-Modelle und Long-Context-Serving belasten Hardware auf unterschiedliche Weise.

Ein Mixture-of-Experts-Modell aktiviert für jedes Token nur ausgewählte Gruppen von Parametern. Das kann den Rechenaufwand verringern, erzeugt jedoch zugleich anspruchsvolle Kommunikationsmuster zwischen GPUs.

Helios könnte gut abschneiden, wenn Speicherkapazität oder Scale-out-Bandbreite eine Anwendung begrenzen. Nvidia könnte einen Vorteil behalten, wenn sein Software-Stack aus nominell geringeren Ressourcen mehr Arbeit herausholt.

Dieselbe Vorsicht gilt für AMDs Formulierung zum Single-Hop-Speicher. Helios stellt eine eng vernetzte HBM-Domäne bereit, verwandelt aber nicht 72 physische Speicherpools in ein einzelnes herkömmliches Gerät mit einheitlichem Speicher.

Die Software muss Datenplatzierung, Eigentümerschaft der Beschleuniger, Synchronisierung und Kommunikationskosten weiterhin verstehen. Ein entfernter HBM-Zugriff über einen Switch verhält sich nicht wie ein lokaler Zugriff innerhalb eines GPU-Pakets.

Neben der Bandbreite zählt auch die Latenz. AMD veröffentlicht beeindruckende aggregierte Durchsatzwerte, doch detaillierte Anwendungsergebnisse werden zeigen, wie sich das Fabric unter Konkurrenz und unregelmäßigem Verkehr verhält.

Zuverlässigkeit schafft eine weitere Herausforderung. Ein Rack mit 72 GPUs vereint Beschleuniger, Prozessoren, Switches, Netzwerkschnittstellen, Kühlanschlüsse, Stromkomponenten, Kabel und Software in einer Betriebsdomäne.

Ausfälle werden kostspieliger, wenn Workloads das Rack als ein System behandeln. Betreiber benötigen Fehlerisolierung, Telemetrie, Checkpointing, Wartbarkeit und vorhersehbare Wiederherstellungsverfahren.

Auch das Rack in doppelter Breite stellt Anforderungen an die Infrastruktur. Sein Leistungsbereich von 225 kW bis 245 kW übersteigt die Kapazität vieler bestehender Unternehmens-Rechenzentrumshallen.

Bei dieser Dichte ist Flüssigkühlung zwingend erforderlich. Käufer benötigen eine geeignete Kühlmittelverteilung, Stromumwandlung, ausreichende Bodenbelastbarkeit, Wartungszugang und geschulte Betriebsteams.

Diese Anforderungen schwächen Helios nicht gegenüber jedem Wettbewerber. Nvidias Rack-Scale-Systeme stellen ähnliche Anforderungen an die Infrastruktur.

Sie begrenzen jedoch den adressierbaren Markt. Helios gehört zunächst in Hyperscale-Rechenzentren, spezialisierte KI-Einrichtungen, nationale Labore und Standorte, die für dichte flüssigkeitsgekühlte Systeme ausgelegt sind.

Software bleibt die größte unsichere Variable. ROCm muss die Topologie des Racks unterstützen und zugleich die Benutzerfreundlichkeit und Leistung erreichen, die Entwickler von ausgereiften Nvidia-Deployments erwarten.

Kunden werden stabile kollektive Kommunikation, optimierte Kernel, Framework-Integration, Observability, Orchestrierung und schnelle Unterstützung für neue Modellarchitekturen benötigen.

AMD kontrolliert davon mehr als zuvor. Der Besitz von Prozessor, Beschleuniger, Netzwerkschnittstellen und Referenzsystem gibt seinen Ingenieuren mehr Möglichkeiten, Probleme zwischen verschiedenen Anbietern zu beseitigen.

Doch Kontrolle schafft nicht augenblicklich Reife. Die ersten Produktionsbereitstellungen werden Probleme offenlegen, die Präsentations-Benchmarks und Referenzdesigns nicht vorhersehen können.

Helios setzt Käufer ebenso unter Druck wie Nvidia

Helios eröffnet Infrastrukturkäufern einen zweiten Rack-Scale-Weg, macht ihre Evaluierungsarbeit jedoch auch anspruchsvoller.

Eine glaubwürdige Alternative kann die Verhandlungsposition verbessern. Hyperscaler müssen ein integriertes Nvidia-Rack nicht länger mit einer Sammlung unabhängig zusammengestellter AMD-Server vergleichen.

Sie können zwei Rack-Architekturen mit jeweils 72 GPUs und ähnlichen physischen Ambitionen vergleichen. Beide kommen als koordinierte Plattformen für Training und Inferenz im Rechenzentrumsmaßstab.

Dadurch werden Beschaffungsvergleiche aussagekräftiger. Käufer können Speicher pro Rack, Scale-up-Bandbreite, Scale-out-Bandbreite, Stromversorgung, Kühlung, Software-Reife, Wartbarkeit und Workload-Ergebnisse untersuchen.

Der AMD-Deep-Dive von ServeTheHome unterstreicht zudem die Bedeutung der Wahl in der Lieferkette. Broadcom-Switching und ein offener Rack-Standard geben Herstellern mehr Spielraum, ihre Implementierungen zu differenzieren.

HPE kann Helios mit eigener Systemtechnik und Juniper-Netzwerkkompetenz kombinieren. Supermicro kann Kunden ansprechen, die bereits seine flüssigkeitsgekühlten Plattformen betreiben.

Cloud-Anbieter können MI455X-Kapazität über Managed Services bereitstellen und so kleineren Kunden die Notwendigkeit ersparen, die physischen Racks selbst zu installieren.

AMD gewinnt mit diesem Modell an Reichweite, ist aber auch darauf angewiesen, dass Partner konsistent liefern. Eine schwache Integration durch einen Hersteller könnte die Wahrnehmung der breiteren Plattform beschädigen.

Nvidias kontrolliertes Design begrenzt diese Variation. Kunden erhalten weniger architektonische Wahlmöglichkeiten, profitieren jedoch auch von einem einheitlicheren Ziel für Anwendungsoptimierung und Support.

Unternehmenskäufer sollten Offenheit daher nicht automatisch als Kostenreduzierung betrachten. Anpassbarkeit schafft nur dann Wert, wenn die Organisation über die Engineering-Kapazität verfügt, sie zu nutzen.

Ein Unternehmen, das Standardmodelle über einen Managed-Cloud-Service betreibt, interessiert sich möglicherweise stärker für bereitgestellte Tokens und Verfügbarkeit als für den zugrunde liegenden Switch-Lieferanten.

Ein Hyperscaler, der eigene Netzwerk- und Scheduling-Software entwickelt, kann veröffentlichten Schnittstellen und handelsüblichem Silizium deutlich mehr Wert beimessen.

Forscher, die mit Modellen arbeiten, deren Speicherbedarf einen einzelnen Server übersteigt, können von der 31-TB-HBM-Domäne von Helios profitieren. Dieselbe Kapazität kann größere Inferenz-Caches und mehr parallele Anfragen unterstützen.

Entwickler sollten sich dafür interessieren, weil Hardwarevielfalt die Softwareportabilität beeinflusst. Eine zweite tragfähige Rack-Architektur gibt Framework-Projekten und Modellanbietern stärkere Gründe, auch außerhalb von CUDA zu optimieren.

Dieser Prozess wird nicht automatisch stattfinden. Anwendungsteams müssen Kernel, numerisches Verhalten, Kommunikationsbibliotheken, Container-Images, Monitoring-Tools und Bereitstellungs-Workflows validieren.

Auch die breitere Branche profitiert von einem Wettbewerb der Standards. UALink und Ultra Ethernet verfügen nun über ein prominentes System, an dem sich ihre Leistung unter anspruchsvollen KI-Workloads messen lässt.

Erfolg würde mehr Switch-Anbieter, Beschleunigerentwickler und Systemhersteller zur Teilnahme ermutigen. Schwache Ergebnisse würden das Argument für proprietäre Integration stärken.

AMD setzt auch sich selbst unter Druck. Jährliche Beschleuniger-Releases erfordern, dass Rack-Design, Netzwerk, Software und Fertigungskette im selben Zeitplan voranschreiten.

Eine verzögerte Komponente kann das gesamte System zurückhalten. Die Plattform ist erst bereit, wenn Beschleuniger, CPUs, Switches, Netzwerkschnittstellen, Kühlung, Firmware, Treiber und Frameworks zusammenarbeiten.

Das Unternehmen erklärt, Helios sei in die Produktion gegangen; Auslieferungen würden bis Ende des dritten Quartals 2026 erwartet. Dieser Zeitplan positioniert das System nahe am Vera-Rubin-Rollout von Nvidia, statt eine vollständige Generation zurückzuliegen.

Das Timing verringert AMDs traditionellen Nachteil. Es nimmt dem Unternehmen jedoch auch Ausreden, falls Software oder Lieferkette die Kundenerwartungen nicht erfüllen.

Die Produktionsankündigung berichtete über geplante Deployments großer Partner. Der nächste Test ist, ob diese Zusagen zu zugänglicher Produktionskapazität werden.

Ein zu Evaluierungszwecken installiertes Rack ist nicht dasselbe wie eine Flotte, die umsatzgenerierende Workloads bedient. Käufer sollten reproduzierbare Ergebnisse über Wochen verlangen, nicht kurze Demonstrationen unter kontrollierten Bedingungen.

Drei Signale werden entscheiden, ob Helios funktioniert

Auslieferungsvolumen, unabhängige Workload-Ergebnisse und Zuverlässigkeit über mehrere Racks hinweg werden entscheiden, ob Helios den Markt verändert.

Das erste Signal ist die Produktionsauslieferung. AMD erwartet Helios-Auslieferungen bis Ende des dritten Quartals; Kunden sollten daher beobachten, welche Systeme vor Ende September eintreffen.

Namentlich genannte Installationen sind wichtig, doch Mengen sind wichtiger. Mehrere operierende Flotten würden zeigen, dass AMD und seine Partner HBM4 beschaffen, MI455X-Module paketieren, Racks montieren und flüssigkeitsgekühlte Standorte in Betrieb nehmen können.

Verzögerungen würden AMDs Timing-Argument schwächen. Nvidias installierte Basis und Produktionserfahrung werden mit jedem Quartal wertvoller, in dem Helios knapp bleibt.

Das zweite Signal ist unabhängiges Application Benchmarking. Tester benötigen vollständige Rack-Ergebnisse für aktuelle Sprachmodelle, Mixture-of-Experts-Workloads, Fine-Tuning-Jobs und Long-Context-Inferenz.

Aussagekräftige Tests sollten Latenz, Durchsatz, Stromverbrauch, Auslastung, Genauigkeit und Fehlerverhalten ausweisen. Spitzenrechenleistung allein kann nicht zeigen, ob 72 GPUs während eines realen Workloads ausgelastet bleiben.

Benchmarks sollten auch den Softwareaufwand vergleichen. Eine Plattform, die Wochen individueller Kernel-Arbeit erfordert, kann attraktive Hardwareergebnisse liefern, zugleich jedoch das Projektrisiko erhöhen.

Die aufschlussreichsten Vergleiche werden abgestimmte Modelle, Batch-Größen, Zahlenformate und Service-Level-Ziele verwenden. Andernfalls können Anbieter Einstellungen wählen, die ihre Architektur begünstigen.

Die Ergebnisse sollten sowohl speicherintensive als auch rechenintensive Workloads abdecken. Die Kapazitäts- und Bandbreitenangaben von Helios werden überzeugender, wenn Anwendungen beides ohne übermäßigen Kommunikations-Overhead nutzen können.

Das dritte Signal ist zuverlässige Multi-Rack-Skalierung. Ein Helios-Rack testet UALink über Ethernet, während größere Bereitstellungen zusätzlich Pensando Vulcano-Schnittstellen und das umgebende Ultra Ethernet-Netzwerk testen.

AMD muss zeigen, dass die Leistung vorhersehbar bleibt, wenn Jobs Rack-Grenzen überschreiten. Überlastung, kollektive Operationen, Job-Scheduling und Komponentenausfälle werden in diesem Maßstab schwieriger.

Große Kunden werden darauf achten, wie schnell ein ausgefallener Beschleuniger oder Netzwerklink isoliert werden kann. Sie werden außerdem messen, ob ein Job fortgesetzt, neu gestartet oder von einem aktuellen Checkpoint wiederhergestellt werden kann.

Starke Multi-Rack-Ergebnisse würden AMDs Open-Network-These stützen. Sie würden zeigen, dass Merchant Switching, offene Spezifikationen und Partner-Engineering ein koordiniertes KI-System liefern können.

Schwache Skalierung würde Nvidias engere Integration begünstigen. Sie würde darauf hindeuten, dass die Kontrolle über das gesamte Fabric weiterhin einen operativen Vorteil bietet, den Spezifikationen nicht erfassen können.

Diese Signale sollten beeinflussen, wie Leser künftige AMD ServeTheHome-Berichte interpretieren. Neue Diagramme und Spitzenwerte werden nützlich sein, doch Produktionsnachweise haben inzwischen mehr Gewicht als architektonische Absichten.

Helios ist nicht einfach ein weiterer Instinct-Server. Es ist AMDs Versuch, seine angesammelten Rechenzentrumsressourcen in einem wettbewerbsfähigen Produkt zu bündeln.

Der MI455X liefert Low-Precision-Rechenleistung und 432 GB HBM4. Venice übernimmt die Host-Verarbeitung, Pensando stellt Scale-out-Netzwerke bereit, und ROCm verbindet das System mit KI-Frameworks.

Das Tomahawk-6-Silizium von Broadcom stellt die zentrale Verbindung zwischen den 72 Beschleunigern bereit. Open Rack Wide-Hardware gibt Herstellern eine gemeinsame physische Grundlage.

Diese Kombination macht Helios zu AMDs bislang umfassendster Herausforderung für Nvidias KI-Infrastrukturstrategie. Sie setzt AMD jedoch auch einem anspruchsvolleren Maßstab aus.

Kunden werden das Unternehmen nicht länger allein nach Beschleunigerspezifikationen beurteilen. Sie werden Rack-Verfügbarkeit, Anwendungsleistung, Softwarequalität, Anforderungen an die Infrastruktur, Zuverlässigkeit und Support als Gesamtpaket bewerten.

Die nächste Frage ist praktisch: Werden unabhängige Betreiber AMDs Angaben reproduzieren, nachdem Helios Produktionsrechenzentren erreicht hat? Verfolgen Sie die ersten großen Bereitstellungen, vergleichen Sie vollständige Workload-Ergebnisse und beobachten Sie, ob offenes Ethernet über ein Rack hinaus effizient bleibt.