Der Infrastrukturwettlauf zwischen AMD und Google verschiebt sich, da Schneider Electric Helios einsatzbereit macht

Schneider Electric und AMD haben das erste Infrastrukturdesign für Helios vorgestellt, das Racks mit 246 Kilowatt und Cluster mit bis zu 10,4 Megawatt IT-Last unterstützt. Das verändert den Infrastrukturwettbewerb zwischen AMD und Google in praktischer Hinsicht. AMD verfügt nun über einen dokumentierten Weg von den Beschleunigerspezifikationen bis hin zu einem funktionierenden Rechenzentrum mit hoher Leistungsdichte.

Die Ankündigung verschafft AMD keinen plötzlichen Leistungsvorsprung gegenüber Google, Nvidia oder einem anderen Plattformanbieter. Sie adressiert eine andere wettbewerbliche Schwäche. Der Kauf von Beschleunigern ist erst der Anfang, wenn jedes Rack zudem spezielle Stromverteilung, Flüssigkeitskühlung, Steuerungssysteme und Modellierung auf Anlagenebene erfordert.

Google hat jahrelang solche Systeme rund um seine Tensor Processing Units, kurz TPUs, entwickelt – Prozessoren, die für Machine-Learning-Workloads optimiert sind. Nvidia hat ebenfalls mit Schneider Electric an der physischen Infrastruktur seiner beschleunigten Systeme gearbeitet. AMD muss Betreiber davon überzeugen, dass Helios zu einem betriebsfähigen Cluster werden kann, ohne dass sie die unterstützende Infrastruktur selbst neu erfinden müssen.

Deshalb ist dieses Referenzdesign wichtig. Es macht Schneider Electric zu mehr als einem Ausrüstungslieferanten. Das Unternehmen wird Teil von AMDs Antwort auf vertikal integrierte KI-Infrastruktur.

Der Helios-Bauplan verbindet Chips mit einer 10,4-MW-Anlage

AMD und Schneider Electric haben die physischen Systeme rund um Helios definiert, nicht nur die Anordnung der Prozessoren innerhalb eines Racks.

Die Unternehmen stellten ihr gemeinsam entwickeltes Design am 23. Juli 2026 in San Francisco vor. Laut dem Helios-Bauplan unterstützt es modulare KI-Cluster mit bis zu 10,4 Megawatt IT-Kapazität.

Jedes Rack mit hoher Leistungsdichte kann bis zu 246 Kilowatt benötigen. Ein Rack dieser Größenordnung verbraucht ein Vielfaches der Leistung vieler herkömmlicher Unternehmensinstallationen. Zudem wird nahezu die gesamte elektrische Energie in Wärme umgewandelt, die kontinuierlich abgeführt werden muss.

Helios kombiniert AMD Instinct MI455X-Beschleuniger, EPYC-Prozessoren der sechsten Generation, Pensando Vulcano-Netzwerkschnittstellenkarten und die ROCm-Softwareumgebung. ROCm ist AMDs offener Software-Stack für die Programmierung und den Betrieb seiner Beschleuniger.

Diese Rechenkomponenten bilden nur eine Ebene. Das Referenzdesign umfasst Anlagenstromversorgung, Anlagenkühlung, IT-Flächen und Lifecycle-Software. Es legt fest, wie diese Ebenen rund um die Anforderungen von Helios zusammenarbeiten sollen.

Schneider Electric erklärt, dass sein Motivair-Kühlsystem mithilfe flüssigkeitsbasierter und hybrider Luft-Flüssigkeits-Verfahren bis zu 84 Prozent der Wärme abführen kann. Kühlmittelverteilungseinheiten, kurz CDUs, transportieren Wärme zwischen dem Rack-Kreislauf und dem Kühlsystem des Gebäudes.

Das Design nutzt außerdem ETAP-Elektromodellierung und Computational Fluid Dynamics über EcoStruxure IT Design. Computational Fluid Dynamics simuliert Luftströmungen und Temperaturverhalten, bevor die Ausrüstung am Standort eintrifft.

Betreiber können einen elektrischen digitalen Zwilling nutzen, um das Verhalten der Infrastruktur zu modellieren. AVEVAs Unified Operations Center ergänzt nach der Inbetriebnahme Überwachung und operative Transparenz. Diese Werkzeuge sollen elektrische oder thermische Konflikte früher im Bauprozess sichtbar machen.

Schneider Electric zufolge kann die vollständige Konfiguration bei Volllast eine Power Usage Effectiveness, kurz PUE, von etwa 1,12 erreichen. PUE vergleicht den Gesamtenergieverbrauch einer Anlage mit der Energie, die an die Rechenausrüstung geliefert wird. Ein Wert näher an 1 bedeutet weniger Overhead, wobei die tatsächlichen Ergebnisse von Klima, Auslastung und Betriebsentscheidungen abhängen.

Das erste Design folgt den Anforderungen des American National Standards Institute für Einsätze in den Vereinigten Staaten. Schneider Electric plant, für andere Märkte eine an Standards der International Electrotechnical Commission ausgerichtete Version zu entwickeln.

Diese geografische Einschränkung ist relevant. Die Ankündigung bietet einen validierten Ausgangspunkt, nicht ein universelles Design, das lokale elektrische Vorschriften oder Bedingungen der Energieversorgung umgehen kann. Kunden benötigen weiterhin standortbezogene Ingenieursarbeit.

Der Bauplan ist laut unabhängiger Berichterstattung ohne separate Kundengebühr verfügbar. Sein eigentlicher Wert liegt in der vermiedenen Unsicherheit bei der Integration, nicht in den Beschaffungskosten des Dokuments.

Ein Referenzdesign liefert keinen Strom und sichert keinen Netzanschluss. Es kann keinen Beton gießen, keine Wasserrechte erhalten oder lokale Genehmigungsverfahren lösen. Es kann jedoch den Umfang offener technischer Fragen verringern, sobald ein geeigneter Standort vorhanden ist.

Diese Unterscheidung begründet die zentrale Spannung des Artikels. AMD hat wettbewerbsfähige Prozessoren und eine Architektur auf Rack-Ebene entwickelt. Nun braucht das Unternehmen einen wiederholbaren Weg, diese Architektur in Anlagen zu installieren, die unter realen physischen Einschränkungen gebaut werden.

Warum sich der Wettbewerb zwischen AMD und Google über Chips hinaus verlagert

Der Vergleich zwischen AMD und Google hängt zunehmend von der Anlagentechnik ab, weil dichte KI-Systeme als vollständige elektrische, thermische, vernetzte und softwaregestützte Plattformen konkurrieren.

Google betreibt seit etwa einem Jahrzehnt maßgeschneiderte KI-Infrastruktur. Das Unternehmen entwickelt TPUs, Netzwerke auf Pod-Ebene, Kühlsysteme, Software-Frameworks und viele unterstützende Rechenzentrumskomponenten innerhalb einer Organisation.

Diese Erfahrung schafft einen Vorteil, den reine Beschleunigerspezifikationen nicht erfassen können. Google kann Prozessor-Roadmaps mit den Gebäuden abstimmen, in denen diese Prozessoren betrieben werden. Außerdem kann das Unternehmen Infrastrukturänderungen in einer großen internen Flotte testen, bevor es Kapazität über Google Cloud anbietet.

Google berichtete, dass es Flüssigkeitskühlung im Gigawatt-Maßstab über mehr als 2.000 TPU-Pods hinweg innerhalb von sieben Jahren eingeführt habe. Zudem meldete das Unternehmen für diese Kühlungsinstallationen eine Verfügbarkeit von rund 99,999 Prozent. Google erläuterte diese Erfahrung bei der Vorstellung von Rack-Designs mit einem Megawatt.

Dabei handelt es sich um vom Unternehmen selbst gemeldete Zahlen und nicht um einen unabhängigen Vergleich mit AMD Helios. Sie zeigen dennoch die operative Reife, mit der konkurrierende Infrastrukturplattformen umgehen müssen.

Google entwickelte außerdem Brazos, ein rackmontiertes Flüssigkeit-zu-Luft-Kühlsystem für flüssigkeitsgekühlte Hardware in luftgekühlten Anlagen. Das Brazos-System nimmt Wärme über einen geschlossenen Flüssigkeitskreislauf auf und gibt sie anschließend in den vorhandenen Warmgang ab.

Brazos und das Helios-Design von Schneider Electric adressieren unterschiedliche Einsatzszenarien. Beide spiegeln jedoch denselben Branchendruck wider. Die Einführung von KI-Hardware stockt, wenn das Zielgebäude nicht den erforderlichen Flüssigkeitskreislauf, die elektrische Einspeisung oder die Kapazität zur Wärmeabfuhr bereitstellen kann.

AMD besitzt keine Hyperscale-Rechenzentrumsflotte, die mit der von Google vergleichbar wäre. Deshalb benötigt das Unternehmen Infrastrukturpartner, Serverhersteller, Cloud-Anbieter und Netzwerklieferanten, um Kunden einen gleichwertigen Weg zu bieten.

Schneider Electric schließt einen wesentlichen Teil dieser Lücke. Das Unternehmen bringt Stromverteilung, Kühlausrüstung, Modellierungssoftware und Anlagentechnik in AMDs Programm für Rack-Architekturen ein. HPE bietet einen weiteren Weg, indem es Helios in kommerzielle Systeme integriert.

Dieses Partnerschaftsmodell kann Flexibilität bieten. Ein Kunde ist nicht auf den Prozessor oder die Anlagenarchitektur eines einzelnen Cloud-Betreibers beschränkt. Betreiber können ein offenes Design für Colocation, Private Cloud, souveräne KI und spezialisierte Rechenprojekte anpassen.

Ein partnergeführtes Modell schafft jedoch auch Koordinierungsrisiken. Änderungen an einem Beschleuniger, Switch, einer CDU, einer Stromschiene oder einem Software-Release können mehrere Unternehmen betreffen. Die Validierung muss mit jeder wichtigen Komponenten-Roadmap Schritt halten.

Googles integriertes Modell verringert einen Teil dieser organisatorischen Distanz. Das Unternehmen kann seine TPU-, Netzwerk-, Software- und Anlagenteams durch interne Planung aufeinander abstimmen. Zudem kann es seine Infrastruktur für Workloads reservieren, die zu seiner Wirtschaftlichkeit passen.

Der Kompromiss liegt in der Kundenkontrolle. Ein Google-Cloud-Kunde nutzt die Plattform weitgehend als Managed Service. Ein Helios-Käufer kann direktere Kontrolle über die Rechenumgebung, das Anlagendesign und das Betriebsmodell erhalten.

Das macht AMD und Google nicht bei jeder Beschaffung zu direkten Alternativen. Google verkauft Cloud-Dienste und nutzt kundenspezifisches Silizium, während AMD Prozessoren und Plattformentechnologie über ein Branchen-Netzwerk vertreibt.

Dennoch vergleichen Unternehmenskäufer die resultierende Kapazität. Sie bewerten Bereitstellungszeit, Modellkompatibilität, verfügbare Regionen, operative Kontrolle, Leistung und Energieverbrauch. Die Wettbewerbseinheit wird zunehmend der funktionierende KI-Cluster statt des einzelnen Chips.

Nvidia bleibt in diesem Markt der wichtigste Bezugspunkt. Schneider Electric kündigte 2024 eine Infrastrukturkooperation mit Nvidia an, die sich auf Hochleistungsstromverteilung und Flüssigkeitskühlung für dichte Beschleuniger-Cluster konzentrierte. Diese frühere Nvidia-Kooperation zeigt, dass Schneider sich nicht für eine einzelne Beschleunigerplattform entscheidet.

Stattdessen profitiert Schneider Electric davon, dass mehrere Architekturen neue Anlagendesigns erfordern. Für AMD liefert die Beziehung Infrastruktur-Glaubwürdigkeit. Für Kunden entsteht damit neben cloudnativen TPUs und Nvidia-zentrierten Systemen eine weitere technisch ausgearbeitete Option.

Stromversorgung und Kühlung bestimmen nun den Wettbewerbsmechanismus

Der Beitrag von Schneider Electric ist relevant, weil ein 246-Kilowatt-Rack die Anlage schneller verändert als die Beschaffungstabelle.

Bei der herkömmlichen Serverplanung galt das Rechenzentrum oft als stabiler Rahmen. Käufer wählten Server aus, reservierten Rack-Positionen und prüften, ob vorhandene Strom- und Kühlkapazitäten ausreichten.

KI mit hoher Leistungsdichte kehrt diese Reihenfolge um. Workload und Beschleuniger-Roadmap prägen nun die elektrische Topologie, Rohrleitungen, Flächenanordnung, das Redundanzmodell und den Bauzeitplan. Ein für die Server von gestern entworfenes Gebäude kann die Racks von morgen nicht automatisch aufnehmen.

Bei 246 Kilowatt erfordert ein Helios-Rack eine direkte Abstimmung zwischen Rechenausrüstung und Anlagensystemen. Ein elektrisches Design muss Dauerlast, transientes Verhalten, Schutzparameter, Wartungszustände und Fehlerszenarien bewältigen.

Das Kühldesign muss genügend Flüssigkeit zu jeder Cold Plate liefern. Zudem muss es Wärme über CDUs und Anlagenkreisläufe übertragen, ohne unzulässige Temperaturänderungen oder Durchflussungleichgewichte zu verursachen.

Luftkühlung bleibt Teil des Designs, weil einige Komponenten und die umgebende Ausrüstung weiterhin Wärme in den Raum abgeben. Schneider Electric beschreibt deshalb einen hybriden Ansatz, anstatt zu behaupten, Flüssigkeit beseitige sämtliche Anforderungen auf der Luftseite.

Die Bibliothek der Referenzdesigns des Unternehmens erklärt, warum die Modellierung elektrisches Verhalten, Luftströmung und Flüssigkeitsfluss abdecken muss. Jedes Modell erkennt eine andere Fehlerklasse. Ihre Kombination kann Wechselwirkungen identifizieren, bevor Betreiber den Cluster unter Spannung setzen.

Betrachten wir einen teilweisen Ausfall der Kühlung. Die verbleibende Ausrüstung muss zusätzliche Wärme aufnehmen, oder die Rechenlast muss schnell sinken. Dieses Ereignis betrifft Anlagensteuerung, Cluster-Scheduling und möglicherweise den Fortschritt beim Modelltraining.

Eine Stromunterbrechung schafft ein weiteres ebenenübergreifendes Problem. Backup-Systeme müssen den vorgesehenen Betriebszustand unterstützen, während die Softwareumgebung unterbrochene Jobs verarbeitet. Die Resilienz der Anlage und die Resilienz der Rechenumgebung können nicht unabhängig voneinander geplant werden.

Darin liegt der Mechanismus hinter der Helios-Partnerschaft. AMD definiert das Verhalten und die Anforderungen der Computing-Plattform. Schneider Electric übersetzt diese Anforderungen in Infrastrukturkonfigurationen, die Projektteams bewerten können.

Das modulare Clusterdesign mit 10,4 Megawatt fügt eine weitere Ebene hinzu. Betreiber können Kapazitäten in wiederholbaren Blöcken planen, statt jedes Deployment von Grund auf neu zu entwerfen. Standardisierung kann die Beschaffung vereinfachen und Meinungsverschiedenheiten zwischen Ingenieuren, Auftragnehmern und Technologieanbietern verringern.

Wiederholbarkeit hilft auch Lieferanten dabei, den Gerätebedarf vorherzusagen. CDUs, Schaltanlagen, Überwachungssysteme und vorgefertigte Module können anhand bekannter Clusterkonfigurationen geplant werden. Ein wiederholtes Modul erfordert jedoch weiterhin eine standortspezifische Integration.

Die Versorgungskapazität bleibt die schwierigste Grenze. Ein ausgereiftes Design garantiert nicht, dass ein Versorger weitere 10,4 Megawatt im gewünschten Zeitrahmen liefern kann. Warteschlangen für Netzanschlüsse und Arbeiten an Umspannwerken können den Bereitstellungszeitplan für Computing-Hardware überdauern.

Auch Wasser- und Wärmeabfuhr unterscheiden sich je nach Standort. Eine Anlage benötigt abhängig von Klima und lokalen Beschränkungen möglicherweise Kältemaschinen, Trockenkühler, Kühltürme oder eine andere Konfiguration. Das Referenzdesign kann diese Umweltunterschiede nicht beseitigen.

Der angegebene PUE von etwa 1,12 verdient einen ähnlichen Kontext. Der PUE verändert sich mit Auslastung, Wetter, Redundanz, Kühlmethode und Messgrenzen. Ein modellierter Wert bei Volllast sollte nicht als garantiertes Jahresergebnis betrachtet werden.

Betreiber müssen außerdem entscheiden, wie viel Kapazität sie für Wartung und Ausfälle reservieren. Redundante Infrastruktur für zusätzliche Rechenleistung zu nutzen, kann die Auslastung im Normalbetrieb verbessern. Gleichzeitig verringert dies die verfügbare Reserve, wenn Geräte ausfallen.

Schneider Electric beschreibt diese Entscheidung als Wettbewerb zwischen zusätzlicher Rechenleistung und der ursprünglichen Redundanzstrategie. Die Entscheidung sollte ausdrücklich getroffen werden, denn ungenutzte Backup-Kapazität ist nicht automatisch kostenlose Produktionskapazität.

Google stößt trotz seines integrierten Modells an dieselben physischen Grenzen. Seine Arbeit an Flüssigkeitskühlung zeigt, dass kundenspezifische Siliziumchips das Engineering der Anlage nicht überflüssig machen. Stattdessen muss die Organisation Kühl- und Stromversorgungssysteme parallel zu jeder Computing-Generation entwickeln.

Der Wettbewerb zwischen amd und google zeigt daher zwei Ansätze für denselben Mechanismus. Google koordiniert große Teile des Stacks intern. AMD baut rund um Helios ein offenes Partnernetzwerk auf, wobei Schneider Electric eine kritische Ebene der Anlageninfrastruktur übernimmt.

Ein validiertes Design ist kein validiertes Deployment

Die zentrale Unsicherheit besteht darin, ob Kunden die modellierten Ergebnisse des Bauplans über reale Standorte, Workloads, Lieferanten und Betriebsbedingungen hinweg reproduzieren können.

Schneider Electric und AMD beschreiben das Design als gemeinsam entwickelt und validiert. Diese Validierung deutet darauf hin, dass die Komponenten und Engineering-Annahmen gemeinsam bewertet wurden. Sie belegt jedoch keine Performance im Feld über eine große installierte Basis hinweg.

Den Ankündigungen im Juli lagen keine öffentlichen Ergebnisse aus Kundendeployments bei. Die Unternehmen veröffentlichten keine Angaben zu einer fertiggestellten Helios-Anlage, die unter dem neuen Design kontinuierlich mit 246 Kilowatt pro Rack betrieben wird.

Diese Lücke ist für eine neu veröffentlichte Architektur normal. Sie begrenzt dennoch, was Käufer über Inbetriebnahmezeit, Ausfallverhalten, Komponentenverfügbarkeit und langfristige Wartung ableiten können.

Die Helios-Plattform hängt außerdem davon ab, dass die Hardware wie geplant verfügbar wird. Ihr Design umfasst MI455X-Beschleuniger, EPYC-Prozessoren der sechsten Generation und Vulcano-Netzwerkschnittstellen. Verzögerungen oder Spezifikationsänderungen können einen weiteren Validierungszyklus erzwingen.

Das Netzwerk stellt ein spezifisches Risiko dar. Helios nutzt einen offenen, Ethernet-orientierten Ansatz, der als Alternative zu Nvidias eng integrierter NVLink-Umgebung gedacht ist. Das gibt Käufern mehr Flexibilität bei Lieferanten, erhöht jedoch die Bedeutung eines noch entstehenden Partnerökosystems.

HPE hat Pläne angekündigt, Helios-basierte Systeme anzubieten, und verschafft AMD damit einen wichtigen kommerziellen Vertriebsweg. Die Umsetzung nutzt ein Accelerator-Fabric mit hoher Bandbreite und einen speziell entwickelten Switch.

Eine detaillierte Helios-Systemanalyse beschrieb eine geplante Konfiguration mit 72 MI455X-Beschleunigern. Der Bericht nannte außerdem AMDs Ziel von 31 Terabyte HBM4-Speicher und 2,9 ExaFLOPS FP4-Rechenleistung pro Rack.

Diese Werte sind Ziele, die an zukünftige Hardware gebunden sind, und keine unabhängig überprüften Produktionsergebnisse. FP4 ist ein Zahlenformat mit niedriger Präzision, das für einige KI-Inferenzaufgaben verwendet wird. Es sollte nicht direkt mit jeder Trainings- oder wissenschaftlichen Arbeitslast verglichen werden.

Software bleibt eine weitere Variable. ROCm hat seine Unterstützung für Frameworks und Modelle erweitert, doch die bloße Verfügbarkeit von Hardware garantiert keine gleichwertige Anwendungsleistung. Käufer müssen ihre tatsächlichen Modelle, Operatoren, Compiler und das Verhalten verteilter Trainingsprozesse testen.

Google kann wichtige Workloads für TPUs über JAX, XLA und seine interne Softwareumgebung optimieren. Nvidia verfügt über eine lang etablierte CUDA-Entwicklerbasis. AMD muss beweisen, dass sein offener Stack Abhängigkeiten reduziert, ohne übermäßige Integrationsarbeit auf Kunden zu übertragen.

Ein Referenzdesign kann den Bauplan für die Anlage lösen, während die Migration von Anwendungen ungelöst bleibt. Diese Grenze ist für Enterprise-Teams wichtig, die die Gesamtkosten eines Wechsels der Accelerator-Plattform bewerten.

Auch die Wartung stellt einen weiteren Test dar. Flüssigkeitskreisläufe bringen Pumpen, Verbindungen, Sensoren, Verteiler und Serviceverfahren in die Nähe teurer Computing-Hardware. Betreiber benötigen Nachweise zu Leckagen, Filtration, Kühlmittelqualität, Komponentenaustausch und Mitarbeiterschulung.

Auch die Zahl von 84 Prozent Wärmeabfuhr erfordert eine sorgfältige Interpretation. Schneider Electric erklärt, dass seine vorgeschlagenen Kühlansätze in der Lage sind, diesen Anteil über Flüssigkeit abzuführen. Die verbleibende thermische Last und die Betriebsbedingungen bestimmen weiterhin den Kühlbedarf auf Raumebene.

Dieselbe Vorsicht gilt für die Bereitstellungsgeschwindigkeit. Ein vorentwickeltes Design kann die Planung verkürzen und doppelte Arbeit reduzieren. Es kann jedoch keine schnellere Bauausführung garantieren, wenn Transformatoren, Schaltanlagen, Kältemaschinen, Beschleuniger oder Netzausbauten weiterhin Engpässe darstellen.

Hinzu kommt eine kommerzielle Frage. Käufer müssen entscheiden, ob eine größere architektonische Auswahl den Betrieb einer stärker verteilten Lieferantenbeziehung rechtfertigt. Einige werden einen Cloud-Service bevorzugen, der die Anlage hinter einer API verbirgt.

Andere werden direkte Kontrolle, lokale Datenresidenz oder Unabhängigkeit von einer Cloud-Plattform schätzen. Projekte für souveräne KI und spezialisierte Cloud-Anbieter dürften diese Option besonders prüfen.

Diese Spannung macht die AMD-Strategie glaubwürdig, aber noch nicht abgeschlossen. Schneider Electric hat eine Kategorie der Unsicherheit reduziert. Kundendeployments müssen nun zeigen, ob das kombinierte System außerhalb einer modellierten Umgebung konsistent funktioniert.

Drei Signale werden zeigen, ob AMD die Infrastrukturlücke schließen kann

Die nächste Phase hängt von Betriebsnachweisen, Partnerlieferungen und wiederholbarer Kundenakzeptanz ab – nicht von einer weiteren Runde architektonischer Behauptungen.

Das erste Signal ist ein abgeschlossenes Kundendeployment mit dem Design von Schneider Electric. Die aussagekräftigsten Nachweise würden gemessene Rackdichte, Inbetriebnahmezeit, Kühlleistung, Verfügbarkeit und PUE bei realistischen Veränderungen der Workload umfassen.

Ein Pilotprojekt würde bestätigen, dass der Bauplan die Designumgebung verlassen kann. Mehrere Deployments in unterschiedlichen Klimazonen und Anlagentypen würden eine stärkere Schlussfolgerung über die Wiederholbarkeit stützen.

Ein Ergebnis nahe dem genannten PUE von 1,12 bei Volllast würde die Effizienzargumentation der Unternehmen stärken. Ein Ergebnis deutlich über diesem Wert würde das Design nicht automatisch widerlegen, aber die Bedeutung der Standortbedingungen offenlegen.

Käufer sollten außerdem beobachten, wie Betreiber mit Ausfällen und Wartung umgehen. Ein Cluster mit hoher Dichte muss wartbar bleiben, wenn eine CDU, eine Pumpe, eine elektrische Komponente oder ein Computing-Tray Aufmerksamkeit erfordert.

Das zweite Signal ist eine koordinierte Lieferung von AMDs Hardware- und Netzwerkpartnern. MI455X-Beschleuniger, neue EPYC-Prozessoren, Vulcano-Schnittstellen, Switches, Server und Anlagenkomponenten müssen Projekte in kompatiblen Zeitplänen erreichen.

Eine Referenzarchitektur verliert an Wert, wenn eine wesentliche Komponente eine lange Verzögerung verursacht. Umgekehrt würde eine synchronisierte Verfügbarkeit zeigen, dass AMDs Partnermodell wie eine kohärente Plattform funktionieren kann.

Interoperabilitätstests werden besonders wichtig sein. Kunden benötigen Nachweise, dass Änderungen an Servern, Switches, Software, Stromversorgung und Kühlung keine wiederholten Redesign-Zyklen verursachen.

Die kommerziellen Helios-Systeme von HPE werden einen frühen Test liefern. Weitere Serverhersteller oder Cloud-Betreiber, die dieselben Annahmen auf Rack-Ebene übernehmen, würden die Standardisierung stärken.

Das dritte Signal ist die Akzeptanz von Workloads im Vergleich zu Google TPUs und Nvidia-Systemen. AMD muss nicht jeden Käufer dazu bewegen, diese Plattformen zu ersetzen. Es benötigt genügend Produktions-Workloads, um Helios als zuverlässige Alternative zu etablieren.

Diese Nachweise sollten Trainings- und Inferenzanwendungen umfassen, nicht nur Spitzenwerte aus Benchmarks. Betreiber werden nutzbare Leistung, Softwareaufwand, Clusterverfügbarkeit, Energieverbrauch und die Geschwindigkeit des Kapazitätsausbaus untersuchen.

Googles eigene Infrastrukturentwicklung bietet einen nützlichen Referenzpunkt. Seine lange Geschichte der Flüssigkeitskühlung zeigt, dass sich operatives Wissen über Hardwaregenerationen hinweg ansammelt. AMD und Schneider Electric müssen über Kunden und Partner beginnen, eine vergleichbare Erfolgsbilanz aufzubauen.

Der Vergleich amd google wird unvollkommen bleiben, weil die Unternehmen unterschiedliche Positionen im Markt einnehmen. Google betreibt eine integrierte Cloud- und Custom-Silicon-Plattform. AMD liefert eine offene Architektur, die andere Unternehmen bereitstellen.

Doch genau dieser Kontrast macht das neue Design relevant. Es gibt Käufern die Wahl zwischen der Nutzung einer integrierten Plattform und dem Aufbau eines validierten, partnerbasierten Systems unter ihrer Kontrolle.

Nvidia wird das Ergebnis ebenfalls prägen. Seine Rack-Scale-Systeme, Softwarebasis und Infrastrukturpartnerschaften setzen den Maßstab für die Reife von Deployments. Wenn Nvidia schneller vorankommt, muss AMDs offene Architektur dies durch Flexibilität, Verfügbarkeit oder die Wirtschaftlichkeit von Workloads ausgleichen.

Schneider Electric hat Anreize, jede große Plattform zu unterstützen. Diese neutrale Position kann Kunden dabei helfen, Anforderungen an Anlageninfrastruktur zu vergleichen, ohne eine Accelerator-Roadmap als dauerhaft anzusehen.

Für technische Teams und Beschaffungsteams ist die unmittelbare Maßnahme konkret. Modellieren Sie zunächst die vorgesehenen Workloads und prüfen Sie dann, ob der gewählte Standort deren Anforderungen an Elektrik, Thermik, Netzwerk und Resilienz erfüllen kann.

Teams, die große Infrastrukturankündigungen bewerten, benötigen außerdem eine dauerhafte Möglichkeit, Engineering-Annahmen mit späteren Betriebsnachweisen zu verknüpfen. Eine durchsuchbare technische Wissensdatenbank kann Designunterlagen, Testergebnisse und Lieferantenentscheidungen zugänglich halten, während sich Projekte verändern.

Das Design von Schneider Electric entscheidet das Rennen um Beschleuniger nicht. Es führt AMD in die schwierigere Phase, in der Rack-Spezifikationen Versorgungsgrenzen, Bauzeitpläne, Kühlungsausfälle und Produktions-Workloads überstehen müssen.

Werden Helios-Kunden gemessene Ergebnisse veröffentlichen, die dem Bauplan entsprechen, und werden Partner jede Ebene termingerecht liefern? Das sind nun die entscheidenden Tests. Beobachten Sie die ersten Betriebsstandorte, die koordinierte Hardwareverfügbarkeit und die Workload-Akzeptanz, bevor Sie einen Sieger im Infrastrukturwettlauf zwischen AMD und Google ausrufen.