AMD SemiAnalysis: AMDs CUDA-Herausforderung trifft auf die Realität von Rack-Systemen

AMD präsentierte auf der Advancing AI 2026 seine bislang stärkste Herausforderung für CUDA – trotz zweier operativer Probleme, die glaubwürdigen Wettbewerb noch immer von verlässlichem Einsatz trennen. Die jüngste AMD-SemiAnalysis-Bewertung konstatiert erhebliche Softwarefortschritte, Verbesserungen durch agentengenerierte Kernel und eine deutlich wettbewerbsfähigere MI455X-Architektur. Sie stellt jedoch auch instabile interne Entwicklungscluster und einen schwierigen Produktionshochlauf von Helios fest.

Diese Kombination erzählt die eigentliche Geschichte. AMD wirkt nicht länger durch einen grundsätzlich unbrauchbaren Software-Stack ausgebremst. Stattdessen scheint das Unternehmen durch Umsetzung, Testkapazitäten und die Herausforderung begrenzt, 72 hochentwickelte Beschleuniger in ein verlässliches Produktionssystem zu verwandeln.

Nvidia bleibt der wichtigste Gegner, weil CUDA mehr als eine Programmierschnittstelle ist. Dazu gehören ausgereifte Bibliotheken, getestete Frameworks, Bereitstellungsrezepte, Netzwerktechnik und über Jahre angesammeltes Entwicklerwissen. AMD muss diese Vorteile weniger relevant machen und zugleich Hardware ausliefern, die auf Rack-Ebene funktioniert.

AMD Advancing AI 2026 hat die Bedingungen des Wettbewerbs verändert

AMD ist von vielversprechenden Verbesserungen einzelner Beschleuniger dazu übergegangen, eine vollständige Alternative für hochmoderne KI-Infrastruktur zu präsentieren.

Bei seiner Veranstaltung am 22. und 23. Juli in San Francisco stellte AMD den Instinct MI455X, das Rack-Design Helios und ROCm.AI in den Mittelpunkt. Das Unternehmen hob zudem Partnerschaften mit Anthropic, Microsoft, OpenAI, Cerebras und weiteren wichtigen Käufern von KI-Infrastruktur hervor.

Die Advancing AI event positionierte den MI455X als AMDs leistungsstärksten Beschleuniger und ROCm.AI als KI-gestützte Entwicklungsplattform. AMD erklärte, Anthropic plane den Einsatz von GPUs der MI450-Serie mit bis zu zwei Gigawatt Leistung. Microsoft plane ebenfalls die Bereitstellung von Helios-basierter Infrastruktur.

Diese Kundenzusagen sind relevant, weil sie AMD über isolierte Benchmark-Demonstrationen hinausführen. Spitzenlabore und Cloud-Anbieter müssen Tausende Beschleuniger über wechselnde Modelle, Frameworks und Netzwerkkonfigurationen hinweg betreiben. Ein Chip, der in einem kontrollierten Test gut abschneidet, wird nicht automatisch zu einer tragfähigen Flotte.

Helios ist AMDs Antwort auf diese Anforderung auf Flottenebene. Das Design kombiniert 72 MI455X-GPUs, 18 EPYC-„Venice“-CPUs, Pensando-Netzwerktechnik und ein geswitchtes Scale-up-Fabric. Scale-up-Netzwerke verbinden Beschleuniger innerhalb eines Racks, damit sie an einer großen Arbeitslast zusammenarbeiten können.

AMD zufolge bietet ein vollständiges Rack 31 TB HBM4-Speicher und 260 TB/s aggregierte Scale-up-Bandbreite. Angegeben werden 2,9 ExaFLOPS FP4-Rechenleistung und 1,4 ExaFLOPS FP8-Rechenleistung. Dabei handelt es sich um maximale Unternehmensspezifikationen, nicht um unabhängige Messungen nachhaltiger Anwendungsleistung.

Auch das physische Design markiert einen wichtigen Architekturwechsel. MI300X bis MI355X nutzten eine Punkt-zu-Punkt-Topologie mit acht GPUs. Helios verbindet 72 GPUs über 12 Broadcom-Tomahawk-6-Switches in einem einstufigen All-to-All-Netzwerk.

Damit ist MI455X AMDs erste ernsthafte Antwort auf Nvidias 72-GPU-Systeme auf Rack-Ebene. Zugleich setzt dies AMD einer anderen Klasse technischer Probleme aus. Signalintegrität, Verkabelung, Kühlung, Switch-Integration, Fertigungsausbeute und Wartbarkeit beeinflussen nun die Leistung ebenso stark wie der Beschleuniger selbst.

Die Veranstaltung veränderte daher die zentrale Frage. Käufer müssen nicht länger fragen, ob AMD einen schnellen KI-Chip herstellen kann. Sie müssen fragen, ob AMD ein vollständiges System mit vorhersehbarem Softwareverhalten liefern kann.

Diese Unterscheidung erklärt, warum die neue AMD-SemiAnalysis-Einschätzung günstiger ausfällt, ohne unkritisch zu werden. Die Analyse räumt AMD eine deutlich höhere Chance auf Marktanteilsgewinne ein als zuvor. Sie benennt jedoch auch zwei Risiken, die diesen Fortschritt weiterhin entgleisen lassen können.

Ein Risiko liegt unterhalb der Software-Demonstrationen: AMDs interne Testinfrastruktur bleibt instabil. Das andere steckt im physischen Rack: Helios steht Berichten zufolge vor einem langsamen und komplizierten Produktionshochlauf.

Diese Risiken sind unmittelbar miteinander verbunden. AMD benötigt verlässliche Hardwarecluster, um Software fortlaufend zu testen, während Kunden verlässliche Software benötigen, bevor sie neue Hardware in großem Maßstab akzeptieren. Schwächen auf einer der beiden Seiten verlangsamen die gesamte Plattform.

Warum Nvidias CUDA-Burggraben endlich unter Druck gerät

Agentenbasierte Entwicklung verringert den Arbeitsvorteil hinter CUDA, beseitigt aber nicht Nvidias Vorsprung bei validierten Systemen.

CUDA wurde zum Burggraben, weil Entwickler funktionierende Leistung erreichen konnten, ohne jede Schicht neu aufzubauen. Nvidia investierte in Compiler, optimierte Bibliotheken, Debugging-Tools, Kommunikationssoftware und Integrationen mit weit verbreiteten Frameworks. Jeder erfolgreiche Einsatz fügte Dokumentation, Beispiele und geschulte Ingenieure hinzu.

Diese Anhäufung schuf einen Rückkopplungseffekt. Mehr Kunden zogen mehr Softwareinvestitionen an, wodurch Nvidia-Hardware für den nächsten Kunden sicherer wurde. Selbst wenn konkurrierende Chips attraktive Spezifikationen boten, brachte eine Migration technische und organisatorische Kosten mit sich.

AMDs neues Argument greift die Arbeitskomponente dieses Kreislaufs an. Coding-Agenten können Repositories durchsuchen, Fehler identifizieren, Patches vorschlagen, Tests ausführen und Performance-Experimente wiederholen. Sie können viele eng umrissene Aufgaben parallel erledigen und damit die Bedeutung reiner Entwicklerkapazität verringern.

SemiAnalysis beschreibt den Einsatz kleiner Teams mit Coding-Agenten, um neue Modelle über vLLM und SGLang hinweg zu aktivieren. Die Agenten beschaffen Bereitstellungsrezepte, erstellen Testinfrastruktur, überwachen physische Testsysteme, diagnostizieren Engine-Fehler und reichen Upstream-Korrekturen ein. Laut Bericht war dieser Workflow vor einigen Monaten nicht mit derselben Geschwindigkeit praktikabel.

Besonders relevant ist dies für Kernel. Ein GPU-Kernel ist Low-Level-Code, der eine mathematische Operation auf die Ausführungseinheiten und die Speicherhierarchie eines Prozessors abbildet. Die Qualität eines Kernels kann darüber entscheiden, ob starke Hardware-Spezifikationen in nützliche Anwendungsleistung übersetzt werden.

AMD stellte GEAK, kurz für Generating Efficient AI-Centric Kernels, vor, um Teile dieser Arbeit zu automatisieren. Das System profiliert eine Arbeitslast, schlägt Implementierungen vor, misst sie auf echter Hardware, prüft die Korrektheit und behält erfolgreiche Änderungen bei.

AMDs GEAK framework kann Triton-, TileLang-, FlyDSL-, HIP- und Composable-Kernel-Backends ansteuern. Die vierte Version erweitert den Prozess von einzelnen Kerneln auf vollständige vLLM- oder SGLang-Serving-Workloads.

Diese Unterscheidung ist wichtig. Die Beschleunigung einer einzelnen Operation liefert wenig Nutzen, wenn die Anwendung dadurch lediglich an anderer Stelle eingeschränkt wird. End-to-End-Optimierung ermöglicht es dem Agenten, den nächsten Engpass zu finden und festzustellen, ob eine lokale Beschleunigung den gesamten Serving-Durchsatz verbessert.

Hyperloom ergänzt diesen Prozess um Orchestrierung. Es profiliert einen Inferenzdienst, wählt Engpässe aus, startet Optimierungsagenten und validiert Kandidaten durch End-to-End-Vergleiche. AMD präsentiert es als Teil des umfassenderen ROCm.AI workflow.

SemiAnalysis fand Hinweise darauf, dass dieser Ansatz messbare Verbesserungen erzielen kann. Der Bericht nennt eine End-to-End-Verbesserung von rund 21,8 % durch eine MI355X-Neufassung für dichte lineare Operationen. Er verweist zugleich auf Workloads, bei denen Verbesserungen nahe einer deutlich niedrigeren Grenze stagnierten.

Diese Vorbehalte sind wichtig, weil generierter Code Schwächen eines Benchmarks ausnutzen kann. Ein Agent könnte einen Test verändern, eine verbotene optimierte Bibliothek aufrufen oder versehentlich die unveränderte Ausgangsbasis messen. Schnellere Ergebnisse bedeuten nichts, wenn der Vergleich ungültig ist.

AMD hat Schutzmechanismen gegen diese Verhaltensweisen ergänzt. GEAK kann Änderungen an geschützten Testdateien verhindern, während verwandte Evaluierungstools fest codierte Erfolgssignale und Aufrufe verbotener Bibliotheken erkennen. Diese Kontrollen machen aus agentischer Optimierung ein Engineering-System statt einer Demonstration von Codegenerierung.

Dies ist der stärkste Mechanismus, der CUDAs Burggraben schwächt. Offener Code bietet Agenten mehr Material zum Prüfen, Ändern und Testen. AMDs Compiler-Komponenten, Kernel und Framework-Beiträge schaffen eine zugängliche Oberfläche für automatisierte Verbesserungen.

Offener Zugang allein garantiert jedoch keine Produktionsqualität. Agenten beschleunigen sowohl nützliche Änderungen als auch plausible Fehler. Die Plattform, die generierte Arbeit validiert, gewinnt mit zunehmender Änderungsmenge an Bedeutung.

Nvidia gerät daher in einem Teil seines Vorteils unter Druck: beim Engineering-Durchsatz. Geschützt bleibt das Unternehmen durch einen anderen Teil, die Tiefe seiner Validierung und Erfahrung mit bereitgestellten Systemen.

Das AMD-SemiAnalysis-Urteil zur Software ist besser, aber nicht vollständig

ROCm hat messbare Fortschritte gemacht, doch AMD fehlt weiterhin die Disziplin kontinuierlicher Tests, die für grundlegendes Vertrauen nötig ist.

Die deutlichste Verbesserung ist AMDs engere Abstimmung mit Upstream-Frameworks. Upstream-Unterstützung bedeutet, dass Änderungen in die zentralen vLLM- oder SGLang-Projekte einfließen, anstatt in AMD-spezifischen Forks zu verbleiben. Das verringert den Wartungsaufwand und bietet Nutzern einen vertrauteren Bereitstellungsweg.

SemiAnalysis merkt an, dass stabile ROCm-Unterstützung im Januar 2026 in Upstream-vLLM-Releases aufgenommen wurde, gefolgt von Nightly-Builds. Änderungen im Juni fügten AMD-Mirrors und Gates für acht wichtige Testgruppen hinzu. Dazu gehörten Abdeckung für Attention, Engine, API-Korrektheit, multimodale Funktionen und spekulatives Decoding.

SGLang führte zudem Nightly-Tests für verteilte MI355X-Inferenz ein. Die Tests umfassten disaggregiertes Serving für neue Modelle und schlossen später Kombinationen aus Attention, Expert Parallelism und spekulativem Decoding ein. Damit wurden einige AMD-Konfigurationen von einmaligen Rezepten zu wiederholter Validierung weiterentwickelt.

Disaggregierte Inferenz trennt Phasen des Model Serving auf unterschiedliche Ressourcen. Prefill verarbeitet den Eingabeprompt, während Decode nachfolgende Tokens erzeugt. Betreiber können diese Phasen unabhängig abstimmen, müssen jedoch Key-Value-Cache-Daten zuverlässig zwischen Knoten übertragen.

AMDs MoRI-Software übernimmt Teile dieses Transports und der Expertenkommunikation. ATOMesh ergänzt Routing, cachebewussten Lastausgleich und Orchestrierung. Zusammen zeigen diese Komponenten, dass AMD versteht, wohin sich Produktionsinferenz entwickelt.

Auch die Leistung hat sich verbessert. Die SemiAnalysis-Bewertung nennt eine 18-fache Verbesserung der Interaktivität für eine Kimi-K2.5-Konfiguration nach Upstream-Korrekturen in AITER und vLLM. AMD selbst berichtet separat über moderatere Durchsatzsteigerungen bei mehreren Basiskonfigurationen.

Der wichtige Punkt ist nicht die größte ausgewählte Zahl. Die wesentliche Veränderung besteht darin, dass Optimierungen zunehmend in öffentlichen Frameworks, Rezepten und der kontinuierlichen Integration erscheinen. Kunden können den Weg nachvollziehen, statt sich auf eine private Demonstration zu verlassen.

Dennoch bleibt die kontinuierliche Integration, kurz CI, AMDs sichtbarste Softwareschwäche. CI erstellt und testet Änderungen automatisch, damit Regressionen erkannt werden, bevor Code zusammengeführt wird. Tests, die Merges blockieren, bieten einen stärkeren Schutz, weil ein Fehler die Änderung stoppt.

SemiAnalysis berichtet, dass AMD sein Ziel verfehlte, bis zur Advancing AI 2026 mindestens 90 % der vLLM-Gating-Abdeckung von CUDA zu erreichen. Als Gründe nennt der Bericht unter anderem instabile interne Cluster und die Umverteilung von Kapazitäten durch die Führung vom vLLM-Team.

Der Bericht besagt außerdem, dass AMDs Tests für Kubernetes-Inferenz mit seiner Pollara-Netzwerkschnittstelle deutlich hinter Nvidias ConnectX-Abdeckung zurückblieben. Kubernetes ist wichtig, weil viele Produktions-Inferenzdienste es zur Planung und Verwaltung verteilter Workloads nutzen.

Diese Behauptungen stammen aus der detaillierten Bewertung, nicht von AMD. AMD hat die berichteten Cluster-Umschichtungen oder die dahinterstehenden internen Kapazitätsentscheidungen nicht öffentlich bestätigt.

Dennoch stützen die externen Symptome die grundsätzliche Sorge. Öffentliche Dashboards belegen bislang keine umfassende CUDA-Gleichwertigkeit. Einige hochrelevante AMD-Pfade verfügen nicht über automatische Performance-Gates, Genauigkeitstests oder Hardware-Runner.

Diese Schwäche wird gravierender, wenn Agenten mehr Code generieren. Schnellere Patch-Erstellung erhöht die Zahl der Kombinationen, die getestet werden müssen. Modelle, numerische Formate, Batch-Größen, Netzwerktopologien und Parallelisierungsstrategien können auf unerwartete Weise zusammenwirken.

Eine Konfiguration kann überzeugend wirkende Ausgaben erzeugen und dennoch falsche Antworten liefern. SemiAnalysis identifizierte frühere Genauigkeitsfehler bei verteilter Attention und expert-parallelen Pfaden. Mehrere wurden behoben, doch mindestens ein batch-spezifischer Genauigkeitsrückgang war zum Veröffentlichungszeitpunkt weiterhin offen.

Dieses Beispiel verdeutlicht den Unterschied zwischen Funktionsverfügbarkeit und Plattformreife. Eine Optimierung kann in einem ausgewählten Rezept funktionieren, ohne unter Produktionsbedingungen zuverlässig zu arbeiten. Der CUDA-Burggraben liegt teilweise in genau diesen unspektakulären Sonderfällen.

AMD hat seine Software-Positionierung, Release-Kadenz, Dokumentation und Upstream-Beteiligung verbessert. Der nächste Schritt ist organisatorischer Natur. Testcluster müssen zu stabiler Infrastruktur werden, nicht zu temporären Kapazitäten, die Teams bei internen Nachfragespitzen verlieren.

Helios MI455X macht aus einer Chip-Herausforderung eine Produktionsherausforderung

Helios ist technisch glaubwürdig, doch sein komplexes Rack-Design schafft eine Fertigungsprüfung, der AMD in diesem Maßstab bislang nicht ausgesetzt war.

Das Helios-Rack-Design nutzt offene Standards über Rack, Scale-up-Netzwerk und Scale-out-Netzwerk hinweg. Dadurch erhalten Kunden mehr Komponentenauswahl als bei einem eng proprietären System.

Offenheit schafft jedoch auch Koordinationskosten. Nvidia entwickelt seine GPUs, NVLink-Fabric, NVSwitch-Komponenten, Netzwerkprodukte und Referenzsysteme als eine vertikal integrierte Plattform. AMD stützt sich stärker auf Standardkomponenten und externe Fertigungspartner.

Helios verwendet Broadcom-Tomahawk-6-Switches für seine Scale-up-Fabric. Laut SemiAnalysis ist jede GPU über 72 Lanes mit 200-Gigabit-Ethernet angebunden, was 1,8 TB/s unidirektionale Scale-up-Bandbreite bereitstellt. Zwölf Switch-Chips verbinden die 72 Beschleuniger des Racks.

Die Topologie ist eine deutliche Verbesserung gegenüber AMDs früheren Acht-GPU-Systemen. Sie sollte größere Workloads innerhalb einer Scale-up-Domäne ermöglichen. Gleichzeitig bleibt ein Teil der Switch-Kapazität ungenutzt, weil die Standardkomponente nicht speziell für 72 GPUs ausgelegt wurde.

Die größere Sorge betrifft die physische Signalübertragung. SemiAnalysis berichtet, dass viele Scale-up-Verbindungen Retimer benötigen, die über lange Kupferwege abgeschwächte elektrische Signale wiederherstellen. Die Lieferkettenanalyse schätzt mehr als 550 Broadcom-Ethernet-Retimer pro Rack.

Der Bericht besagt zudem, dass in einer geplanten Bereitstellung rund 85 % der relevanten Verbindungen Retiming benötigen. Das erhöht die Zahl der Komponenten, den Stromverbrauch, die Wärmeentwicklung, den Validierungsaufwand und die potenziellen Fehlerquellen. AMD hat diese Schätzungen nicht unabhängig bestätigt.

Helios verwendet außerdem eine komplexe Kupfer-Backplane und Flyover-Kabel. Flyover-Kabel können die Signalintegrität verbessern, indem sie längere Leiterplattenpfade vermeiden. Sie können jedoch Montage, Luftstrom, Wartungszugang und Fertigung in hohen Stückzahlen erschweren.

SemiAnalysis schätzt, dass ein Rack über seine Scale-up-Verbindungen hinweg 10.368 differentielle Kupferpaare enthält. Selbst wenn jede einzelne Verbindung verstanden ist, stellt die wiederholte Montage und Validierung dieses Systems ein erhebliches Produktionsproblem dar.

Das ist mit der Einordnung als „production ramp hell“ gemeint. Die Formulierung belegt nicht, dass Helios gescheitert ist. Sie beschreibt den schwierigen Übergang von einem funktionierenden Referenzsystem zu wiederholbar produzierbaren Hochvolumensystemen, die von mehreren Partnern gebaut werden.

AMD beschreibt Helios als Referenzdesign, nicht als fertiges Produkt, das direkt von AMD verkauft wird. OEM- und ODM-Partner werden auf Basis dieses Bauplans Systeme unter eigenen Marken bauen. Dieses Modell erweitert die Lieferantenbasis, verteilt aber die Verantwortung auf mehr Organisationen.

Das Unternehmen erwartet Volumenbereitstellungen in der zweiten Hälfte des Jahres 2026. Microsofts Zusage verschafft der Plattform eine wichtige Validierungschance. Anthropic und weitere angekündigte Partner liefern Nachfragesignale, wobei angekündigte Kapazität nicht gleich installierter und abgenommener Kapazität ist.

Der MI455X selbst verfügt über starke Spezifikationen. AMD nennt 432 GB HBM4-Speicher pro Beschleuniger, CDNA-5-Architektur und native Unterstützung für mehrere Niedrigpräzisionsformate. Die Architektur übernimmt zudem eine Wave-Größe von 32 Threads und bringt Teile ihres Ausführungsmodells näher an Nvidia heran.

Diese Annäherung kann Reibung für Kernel-Entwickler reduzieren. Eine vereinfachte Speicherhierarchie und eine vertraute Ausführungsbreite können bestehendes Optimierungswissen leichter übertragbar machen. Native NVFP4-Unterstützung hilft AMD zudem dabei, Modell-Checkpoints auszuführen, die um Nvidias Format herum entwickelt wurden.

Keine dieser Funktionen beseitigt das Rack-Problem. Ein wettbewerbsfähiger Beschleuniger wird erst dann kommerziell wertvoll, wenn Kunden Systeme mit akzeptablen Ausbeuten erhalten, installieren, kühlen, vernetzen und betreiben können.

Die finanziellen Bedingungen rund um große Zusagen fügen eine weitere Ebene hinzu. SemiAnalysis charakterisiert eine OpenAI-Vereinbarung als Angebot aktienbasierter Rabatte, die unter bestimmten Bedingungen 105 % erreichen können. Solche Anreize können die Akzeptanz fördern, ohne eine gewöhnliche Marktnachfrage zu belegen.

Aktiengebundene Ökonomie unterscheidet sich von einem direkten Hardware-Rabatt. Ihr Wert hängt von vertraglichen Auslösern, dem künftigen Aktienwert, Bereitstellungsmeilensteinen und der Bilanzierung ab. Öffentliche Berichte liefern nicht genügend Details, um die maximale Schlagzeilenzahl als realisierten Vorteil zu behandeln.

Diese Struktur erschwert auch Wettbewerbsvergleiche. Die effektive Wirtschaftlichkeit eines Kunden kann strategische Finanzierung widerspiegeln und nicht allein Beschleunigerkosten oder Betriebseffizienz. Käufer sollten vertragliche Anreize von gemessener Leistung pro Dollar trennen.

Der relevante Test ist daher physisch und operativ. Helios muss Partnerfabriken verlassen, Abnahmetests bestehen, Produktionscluster erreichen und unter anhaltenden Workloads Verfügbarkeit aufrechterhalten. Bis dahin beschreiben seine Spezifikationen Potenzial statt installierter Fähigkeit.

AMD muss verteilte Inferenz gewinnen, nicht den Benchmark von gestern

Der nächste Burggraben ist die Fähigkeit, Netzwerk, Scheduling, Speicherbewegung und Kernel ohne fragile Sonderfälle zu kombinieren.

Single-Node-Performance bot einst eine nützliche Kurzform für den Wettbewerb bei Beschleunigern. Dieser Vergleich erfasst inzwischen weniger vom Produktions-Workload. Frontier-Inferenz verteilt Modellkomponenten und Serving-Phasen zunehmend auf viele Nodes.

Sparse Mixture-of-Experts-Modelle verstärken diesen Wandel. Diese Modelle enthalten viele spezialisierte Expert-Netzwerke, aktivieren aber für jedes Token nur eine Teilmenge. Effizientes Serving erfordert das Routing von Tokens, den Datenaustausch, die Lastverteilung zwischen Experten und genügend Speicher für den Cache.

Breiter Expert-Parallelismus verteilt diese Experten über mehr GPUs. Disaggregiertes Prefill und Decode platzieren unterschiedliche Serving-Phasen auf spezialisierten Ressourcen. Cache-Offload verschiebt gespeicherten Kontext zwischen HBM, Systemspeicher und Storage.

Jede Technik kann für sich genommen ein attraktives Ergebnis liefern. Die eigentliche Herausforderung ist die Zusammensetzung. Quantisierung, Attention-Kernel, spekulatives Decoding, Experten-Routing, Cache-Transfer und Netzwerkverhalten müssen modellübergreifend zusammenarbeiten.

SemiAnalysis argumentiert, dass diese Kombinierbarkeit Nvidias neuerer Burggraben ist. CUDA bleibt relevant, doch die Wettbewerbseinheit hat sich von einer Programmierumgebung zu einem verteilten Inferenzsystem erweitert.

AMD verfügt über glaubwürdige Komponenten. MoRI unterstützt Remote-Speicherzugriff für Expertenkommunikation und Cache-Bewegung. AITER liefert optimierte Inferenz-Kernel. ATOM und ATOMesh stellen Ausführungs- und Routing-Funktionen bereit. SGLang und vLLM bieten die etablierten Serving-Umgebungen, die Kunden erwarten.

Das Problem ist die ungleichmäßige Integration. Einige AMD-Konfigurationen kombinieren Disaggregation, verteilte Attention, Expert-Parallelismus und spekulatives Decoding. Andere erfordern deaktiviertes Graph Capture, modellspezifische Patches oder ausgewählte Batch-Größen.

Die Helios-Software befindet sich weiterhin in einem besonders frühen Stadium. SemiAnalysis fand erste PyTorch-Architekturunterstützung, aber begrenzte Tests für die wertvollsten Pfade. Einige Framework-Images konnten für MI455X gebaut werden, ohne vollständige Genauigkeits- oder Performance-Gates auf physischen MI455X-Runnern auszuführen.

Der Bericht fand außerdem frühe Unterstützung für Key-Value-Cache-Transfer ohne vollständige WideEP-Integration. Das bedeutet, dass AMD Teile des verteilten Stacks besitzt, aber noch keine zuverlässige Standardkonfiguration, die das gesamte Rack abdeckt.

Das macht ROCm nicht irrelevant. Es definiert die verbleibende Arbeit präziser. AMD muss nicht länger beweisen, dass jede einzelne Komponente existiert. Es muss beweisen, dass diese Komponenten korrekt bleiben, wenn Kunden sie kombinieren.

Auch Nvidia steht hier unter Druck. Offene Frameworks verringern den Wert, wichtige Fähigkeiten in proprietärer Software zu halten. Upstream-Projekte können Unterstützung für mehrere Beschleuniger, Netzwerkschnittstellen und Cache-Transfer-Systeme aufnehmen.

SemiAnalysis beschreibt, wie es half, AMD-Beiträge mit NIXL zu verbinden, einer Bibliothek, die mit Nvidias Arbeit an verteilter Inferenz verbunden ist. AMD-Unterstützung floss später in das Upstream-Projekt ein und zeigt, dass Teile der Softwaregrenze zu gemeinsamer Infrastruktur werden können.

Diese Entwicklung schwächt eine einfache Erzählung von Vendor Lock-in. Kunden profitieren, wenn Transport- und Orchestrierungsschichten mehrere Hardware-Backends akzeptieren. AMD profitiert, weil es weniger Engineering-Stunden für die Pflege paralleler Forks aufwenden kann.

Nvidia kontrolliert weiterhin das Tempo seiner eigenen integrierten Plattform. Seine Hardware- und Softwareteams können sich an einer festgelegten Rack-Architektur ausrichten. AMD muss dafür sorgen, dass Offenheit schnellere kollektive Verbesserung hervorbringt, als Nvidias Integration intern erzeugt.

Agentische Kernel-Generierung hilft bei lokaler Optimierung. Sie kann auch bei der Diagnose von Framework-Fehlern und der Erstellung von Upstream-Patches helfen. Sie kann keine organisatorischen Prioritäten festlegen, keine stabile Testkapazität garantieren und kein komplexes Rack fertigen.

Das Wettbewerbsgleichgewicht beruht daher auf zwei unterschiedlichen Formen der Umsetzung. AMD muss Softwareverbesserung automatisieren und zugleich die Hardwareproduktion industrialisieren. Nvidia muss seinen integrierten Vorsprung verteidigen, ohne dass Prozesse und Organisationsgröße seine Reaktion verlangsamen.

Drei Signale werden zeigen, ob AMD den CUDA-Burggraben schwächen kann

AMDs Ankündigungen werden erst strategisch wichtig, wenn sich Tests, Auslieferungen und verteilte Workloads gemeinsam verbessern.

Das erste Signal ist die öffentliche CI-Abdeckung. AMD benötigt stabile MI455X-Runner und merge-blockierende Tests über vLLM, SGLang, PyTorch, Networking und verteilte Inferenz hinweg. Sichtbare Gleichwertigkeit bei den Gates würde die Sorge über instabile interne Cluster direkt beantworten.

Ein stärkeres Ergebnis würde Genauigkeits- und Performance-Gates über mehrere Modelle, Batch-Größen, numerische Formate und Netzwerktopologien hinweg umfassen. Das Bestehen von Demonstrationsskripten reicht nicht aus. Regressionen müssen Änderungen stoppen, bevor diese Änderungen Nutzer erreichen.

Wenn AMD diese Abdeckung etabliert, wird die These zur agentischen Software deutlich stärker. Agenten können Code schnell generieren und optimieren, weil das Validierungssystem fehlerhafte Arbeit zurückweisen kann. Anhaltende Instabilität würde höhere Entwicklungsgeschwindigkeit in ein größeres Qualitätsrisiko verwandeln.

Das zweite Signal ist der Helios-Produktionshochlauf in der zweiten Hälfte des Jahres 2026. Leser sollten auf Partnerauslieferungen, Kundenabnahmen, installierte Cluster und nachhaltigen Betrieb achten, statt auf weitere Kapazitätsankündigungen.

Microsofts Bereitstellung wird besonders wichtig sein, weil sie AMD-Beschleuniger, EPYC-Prozessoren, Netzwerkkomponenten und ROCm innerhalb einer großen Cloud-Umgebung vereint. Eine Verfügbarkeit im Produktivbetrieb würde mehr als nur die Leistung der MI455X bestätigen. Sie würde die gesamte Liefer- und Softwarekette auf die Probe stellen.

Verzögerungen, begrenzte Stückzahlen oder umfangreiche Neuentwicklungen würden die Bedenken hinsichtlich Retimern, Verkabelung und Partnerkoordination stützen. Planbare Lieferungen würden zeigen, dass AMD ein ambitioniertes Referenzdesign in reproduzierbare Infrastruktur überführt hat.

Das dritte Signal ist eine zusammensetzbare verteilte Inferenz auf MI455X. AMD muss zeigen, dass WideEP, die Trennung von Prefill und Decode, Cache-Transfer, Quantisierung und spekulatives Decoding gemeinsam in Upstream-Frameworks funktionieren.

Die besten Belege werden aus reproduzierbaren Konfigurationen mit Genauigkeitsprüfungen und Ergebnissen unter realistischem Traffic stammen. Ein agentischer Workload umfasst langen Kontext, wiederholte Tool-Aufrufe, Cache-Wiederverwendung und unregelmäßige Anfragezeiten. Einfache synthetische Prompts erfassen diese Anforderungen nicht.

Wenn diese Konfigurationen zuverlässig funktionieren, wird AMD im aktuellen Systemwettbewerb antreten und nicht in einem früheren Vergleich einzelner Knoten. Bleiben sie modellspezifisch, wird CUDAs Vorteil bestehen bleiben, selbst wenn einzelne ROCm-Kernels konkurrenzfähig wirken.

Entwickler sollten sich dafür interessieren, weil eine glaubwürdige zweite Plattform die Portabilität verbessern und die Abhängigkeit von der Roadmap eines einzelnen Anbieters verringern kann. Sie kann zudem den Zugang zu speicherstarken Beschleunigern erweitern, solange Nvidia-Kapazitäten begrenzt bleiben.

Unternehmenskäufer sollten sich aus einem anderen Grund dafür interessieren. Angekündigte Rabatte, Spitzenwerte in Spezifikationen und Partnerzusagen bestimmen nicht das Betriebsrisiko. Käufer benötigen Belege zu Software-Regressionen, Bereitstellungsaufwand, Verfügbarkeit und Workload-Portabilität.

Wissensarbeiter werden das Ergebnis indirekt erleben. Wettbewerbsfähigere Inferenzinfrastruktur kann Modellverfügbarkeit, Latenz und die Wirtschaftlichkeit langlaufender Agenten beeinflussen. Diese Vorteile hängen von Zuverlässigkeit im Produktivbetrieb ab, nicht von Vergleichen auf Keynotes.

Das Urteil von AMD SemiAnalysis ist daher vorsichtig, aber folgenreich. AMD hat einen glaubwürdigen Mechanismus gefunden, um einen Teil der CUDA-Lücke zu schließen. Offene Software und Coding Agents können Jahre manueller Optimierung in schnellere, parallele Engineering-Zyklen verdichten.

Die verbleibenden Hürden sind weniger glamourös, aber entscheidender. AMD benötigt stabile Testcluster, verlässliche verteilte Komposition und ein fertigungstaugliches Helios-Rack. Nvidias Burggraben bleibt dort bestehen, wo diese operativen Details schwierig bleiben.

Beobachten Sie zunächst die öffentlichen Test-Gates, dann reale Helios-Installationen und schließlich vollständige verteilte Workloads. Wenn alle drei gleichzeitig vorankommen, wird AMD mehr als einen konkurrenzfähigen Beschleuniger geschaffen haben. Es wird eine glaubwürdige alternative Plattform aufgebaut haben.