AMDs KI-Beschleuniger-Test: Der Lauf, der zweimal akzeptiert werden kann

Zusammenfassung

• AMD wird heute weniger danach beurteilt, ob Instinct-GPUs beeindruckende öffentliche Zahlen liefern können, sondern danach, ob gewöhnliche KI-Teams eine bestimmte Workload zweimal akzeptiert bekommen: einmal bei der Validierung und erneut, nachdem der nächste Treiber, das Framework, das Modell, der Kernel, das Cloud-Image oder ein Wiederherstellungsereignis die Umgebung verändert hat.
• ROCm ist zu einer echten Produktionsplattform geworden, mit öffentlichen Kompatibilitätsmatrizen, vLLM- und PyTorch-Container-Pfaden, Systemzustandsprüfungen, HIP-Portierungsleitfäden, MLPerf-Einreichungen und Bereitstellungswegen über Azure/OCI. Diese Reife offenbart auch die versteckte Arbeit: Versionspinning, Kernel-Abdeckung, kollektive Tests, modellspezifische Feinabstimmung, Quotenverwaltung, Rollback und Expertenprüfung.
• Das kommerzielle Argument ist nicht einfach nur günstigerer Speicher oder mehr Tokens pro Dollar. AMDs Q1-2026-Bericht zeigt Dynamik im Rechenzentrumssegment und Nachfrage nach Instinct MI350, aber Käufer müssen immer noch die Gesamtkosten pro akzeptiertem Beschleuniger-Durchlauf mit CUDA, cloudverwalteten Modelldiensten, etablierten SaaS-Produkten, Open-Source-CPU/GPU-Kompromissen, interner Portierung und der Option, weniger der Aufgabe zu erledigen, vergleichen.
• Wichtige Beobachtungspunkte sind Kompatibilitätsdrift, Cloud-Kapazitätsgrenzen, Lücken zwischen Benchmark und Produktion, fehlende Kernel, Framework-Regressionen, Verzögerungen bei der Fehlersuche, Verantwortung für die OEM-Integration und der Rückgriff auf CUDA. AMDs Chance ist groß, da speicherreiche Beschleuniger und ein offener Stack die Abhängigkeit von einem einzigen Anbieter verringern können; seine Last besteht darin, dass die Produktionszuverlässigkeit in den am wenigsten glamourösen Teilen des Stacks entschieden wird.

Der akzeptierte Lauf, nicht die Chip-Schlagzeile, ist die Werteinheit

Die drängende Frage für AMD ist nicht, ob ein Instinct-Beschleuniger ein beeindruckendes Modell einmal ausführen kann. Das kann er. AMD verfügt über öffentliche Hardware-, Software- und Benchmark-Evidenz, die noch vor wenigen Jahren fern schien: MI300X- und MI350-Serien-Beschleuniger, ROCm-Versionen mit aktueller Framework-Unterstützung, containerisierte vLLM- und Trainingspfade, öffentliche MLPerf-Einreichungen, Azure- und Oracle-Cloud-Instanztypen und eine wachsende Unternehmens-KI-Softwareschicht. Das Unternehmen steht nicht außerhalb des KI-Infrastrukturmarkts und bittet um Aufmerksamkeit.

Die schwierigere Frage ist, ob ein Infrastrukturteam eine echte Workload in einen akzeptierten Beschleuniger-Lauf verwandeln kann. Dieser Nenner ist strenger als ein Benchmark-Wert. Ein akzeptierter Lauf hat ein benanntes Modell oder einen Trainingsjob, einen festgelegten Container oder eine Umgebung, eine unterstützte GPU- und Betriebssystemkombination, gemessene Leistung, bekannte Kosten, Wiederholbarkeit über mehrere Durchläufe, eine Möglichkeit zur Fehlerdiagnose und einen Wiederherstellungspfad, wenn sich ein Treiber, eine Kernel-Bibliothek, die Modellarchitektur oder ein Cloud-Image ändert.

Handelt es sich um Inferenz, umfasst die Akzeptanz erfolgreiche Anforderungsbearbeitung, Latenz unter Last, Speicherverhalten, Batch-Strategie, Korrektheitsprüfungen, Beobachtbarkeit und Rollback. Handelt es sich um Training, umfasst die Akzeptanz Konvergenz oder Evidenz für die Zielqualität, Stabilität des Datenpfads, Checkpoint-Verhalten, kollektive Kommunikation, Neustartverhalten und Bedienerzeit.

Diese Einordnung ist nützlich, weil sie drei Dinge trennt, die oft miteinander vermischt werden. Modellfähigkeit ist, was das Modell leisten kann, wenn es läuft. Produktzuverlässigkeit ist, ob AMDs Hardware, ROCm, Container, Bibliotheken, Partner-Images und Dokumentation die Workload vorhersagbar ausführen lassen. Das Kundenergebnis in der Produktion ist, ob sich die tatsächliche Geschäftsaufgabe des Käufers nach Integration, Validierung, Überwachung und Berücksichtigung der Ausfallkosten verbessert. Ein Modell kann leistungsfähig sein, während die Bereitstellung fragil ist.

Ein Produkt kann sich verbessern, während ein Kunde immer noch zu viel Engineering-Zeit in die Portierung investiert. Ein Benchmark kann gültig sein, während sich das Kundenmodell, die Datengestalt oder das Service-Level-Ziel anders verhalten.

AMDs stärkstes Marktargument ist, dass viele KI-Käufer mehr Auswahl bei Beschleunigern wünschen. Sie wollen Speicherreserven, Preisdruck, Bezugsalternativen, geringere Herstellerbindung und Softwarepfade, die nicht jede ernsthafte Workload von demselben proprietären Stack abhängig machen. AMDsROCm-Seitebeschreibt einen offenen Software-Stack mit Treibern, Entwicklungswerkzeugen und APIs für GPU-Programmierung von Low-Level-Kerneln bis zu Endanwendungen. Die Seite zurMI350-Seriepräsentiert eine speicherreiche Beschleunigerfamilie, wobei MI350X und MI355X bis zu 288 GB HBM3E-Speicher und 8 TB/s theoretische Spitzenbandbreite bieten und der MI350P auf PCIe-Bereitstellung in konventionellerer Unternehmensinfrastruktur abzielt.

Das sind bedeutsame Eingangsgrößen. Sie sind nicht das Ergebnis. Das Ergebnis ist der akzeptierte Lauf, nachdem alles Unbequeme einbezogen wurde: unterstützte Betriebssysteme, Kernel-Versionen, Firmware, ROCm-Release, Framework-Version, Modellunterstützung, Quantisierungspfad, Scheduler-Verhalten, Systemzustandsprüfungen, Cloud-Region, Quoten, Image-Wartung, Log-Einsicht, Expertenzeit, fehlgeschlagene Versuche und Fallback. Dort wird AMD wirklich getestet.

AMDs Grenze ist der Beschleuniger- und Software-Stack, nicht jedes Cloud-Ergebnis

Die Verzeichnis-Entität für diesen Artikel ist AMD, das Unternehmen hinter den Instinct-Beschleunigern, ROCm und der dazugehörigen KI-Infrastruktursoftware. Diese Grenzziehung ist wichtig, weil AMDs Produkte Kunden über mehrere Oberflächen erreichen. Einige Teams kaufen OEM-Server. Einige mieten Azure ND MI300X v5 VMs. Einige nutzen Oracle Cloud Infrastructure Bare-Metal-GPU-Instanzen. Einige evaluieren AMD Developer Cloud oder Partner-Clouds. Einige erhalten AMD-Hardware über eine verwaltete Plattform oder einen Model-Serving-Anbieter. In jedem Fall hängt die akzeptierte Workload gleichzeitig von AMD-Komponenten und Nicht-AMD-Komponenten ab.

Diese Grenze verhindert zwei Fehler. Der erste besteht darin, AMD jede Cloud-Provider-Operation gutzuschreiben. Wenn ein Azure-VM-Image Treiber sauber installiert, sind Microsoft-Verpackung und -Support Teil des Ergebnisses. Wenn ein OCI-Cluster einen Benchmark über 64 Knoten skaliert, sind Oracles Netzwerk, Speicher, Bare-Metal-Betrieb und Scheduling Teil des Ergebnisses. Wenn ein OEM-System die richtige Firmware und Kühlung bereitstellt, ist die Integration des Serveranbieters Teil des Ergebnisses. AMD liefert das zentrale Silizium und die Software, aber der Kunde akzeptiert ein System.

Der zweite Fehler besteht darin, AMD für jeden Workload-Fehler verantwortlich zu machen, ohne die Schicht zu lokalisieren. Ein Modell kann fehlschlagen, weil eine Framework-Funktion unausgereift ist, ein Drittanbieter-Kernel nicht bereitsteht, ein Cloud-Image veraltet ist, eine Anwendung CUDA-spezifisches Verhalten voraussetzt, ein Container eine nicht passende Bibliothek zieht, ein Scheduler Geräte falsch isoliert oder ein Kunde vor dem Training keine kollektiven Tests durchgeführt hat. Einige dieser Ursachen liegen in AMDs Verantwortung, einige sind geteilt und einige liegen anderswo.

Für die Beschaffung ist die wichtige Frage nicht die moralische Schuld. Es ist die Frage, wer das Problem schnell genug diagnostizieren kann und wer die Kosten trägt, während die Workload blockiert ist.

AMDs öffentliche Einreichungen zeigen, warum das Unternehmen diese Oberfläche aggressiv vorantreibt. In denErgebnissen des ersten Quartals 2026meldete AMD einen Umsatz von 10,3 Milliarden US-Dollar und erklärte, der Umsatz im Rechenzentrumssegment habe 5,8 Milliarden US-Dollar betragen, ein Plus von 57 % gegenüber dem Vorjahr, angetrieben von EPYC-Prozessoren und der fortgesetzten Steigerung der Instinct-GPU-Auslieferungen. DerQ1-2026-10-Q-Berichtbeschreibt das Wachstum im Rechenzentrumsbereich als vorrangig getrieben von EPYC-Prozessoren der 5. Generation und Instinct MI350-Serie GPUs. Das ist kommerzielle Dynamik, nicht nur eine Laborbehauptung.

Doch Umsatzdynamik beantwortet nicht die operative Frage des Käufers. Ein Cloud-Plattformteam, das AMD in Betracht zieht, muss sich fragen, ob der Software- und Support-Pfad gewöhnlich genug für das eigene Personal ist. Ein Model-Serving-Betreiber muss wissen, ob das relevante Modell das richtige Attention-Backend, den Quantisierungspfad und die Batch-Strategie nutzen kann. Ein Trainingsteam muss wissen, ob kollektive Kommunikation, Checkpointing und Neustartverhalten im erforderlichen Maßstab funktionieren.

Ein Finanzteam muss wissen, ob niedrigere Beschleunigerkosten oder höhere Speicherkapazität die zusätzliche Engineering-Zeit für die Portierung und Wartung eines zweiten Stacks überwiegen.

Die rechtliche und markenbezogene Grenzziehung ist daher praktisch. AMD ist der Gegenstand, weil es die Instinct- und ROCm-Strategie kontrolliert. Aber die akzeptierte Workload ist eine Kette. Sie ist kein isolierter AMD-Chip und auch keine isolierte, glanzvolle KI-Behauptung eines Cloud-Anbieters.

Die ROCm-Reife zeigt sich im Papierkram

Ein Zeichen eines reifenden Beschleuniger-Stacks ist langweilige Dokumentation. ROCm hat diese nun in nützlichem Umfang. AMDsKompatibilitätsmatrix, die Ende Mai 2026 in der für diesen Artikel überprüften Version aktualisiert wurde, ist nicht glamourös. Sie ist genau die Art von Artefakt, die Produktionsteams benötigen: Release-übergreifende Kompatibilität über Betriebssysteme, GPUs und Framework-Komponenten hinweg. Die SeiteLinux-Systemanforderungengeht weiter, listet unterstützte und nicht unterstützte Hardware-/Betriebssystem-Kombinationen auf und warnt, dass nicht unterstützte GPUs einige HIP-Laufzeitpfade ausführen können, während vorkompilierte ROCm-Bibliotheken nicht offiziell unterstützt werden und Laufzeitfehler verursachen können.

Diese Dokumentation ändert die Art, wie AMD beurteilt werden sollte. Vor fünf Jahren mochte ein Käufer fragen, ob ROCm in sinnvoller Weise für KI-Arbeiten existierte. Im Jahr 2026 ist die bessere Frage, ob die genaue Kombination des Teams innerhalb der unterstützten Envelope liegt und ob sie dort über die Zeit bleiben kann. MI300X, MI325X, MI350X und MI355X sind keine austauschbaren Bezeichnungen. Die Unterstützung für Ubuntu, RHEL, Debian, Oracle Linux, Rocky Linux und SLES kann je nach Release und GPU variieren. TensorFlow, PyTorch, JAX, Triton, RCCL, hipBLASLt und andere Komponenten bewegen sich in ihrem eigenen Takt.

Ein akzeptierter Lauf erfordert, dass diese Matrix in einen Bereitstellungsvertrag umgewandelt wird.

Hier ist AMDs Offenheit sowohl Vorteil als auch Verpflichtung. Ein offener Stack kann die Angst vor einem geschlossenen Ökosystem verringern. Er kann Entwicklern erlauben, mehr vom Pfad zu inspizieren, zu patchen, zu bauen und zu integrieren. Er kann Portabilitätsstrategien durch HIP und ROCm-Bibliotheken unterstützen. Aber offen bedeutet nicht mühelos. Es bedeutet oft, dass der Käufer mehr Kombinationen zur Verfügung hat und daher mehr Kombinationen testen muss.

Ein Produktionsteam muss immer noch entscheiden, ob es ein Anbieter-Image, ein Upstream-Framework-Release, AMD-Container, ein Cloud-Marketplace-Image, einen benutzerdefinierten Docker-Build oder ein intern freigegebenes Basis-Image verwenden will. Es muss entscheiden, wie schnell es ROCm-Updates übernimmt und wie lange es einen als gut bekannten Stack beibehält.

AMDsROCm 7.2.4-Veröffentlichungshinweisebeschreiben ein Qualitäts-Release, das sich auf Leistungs- und Stabilitätskorrekturen für KI-Inferenz-Workloads auf AMD Instinct GPUs konzentriert. Das ist beruhigend, erinnert aber auch daran, dass Beschleuniger-Software eine lebende Maschinerie ist. Ein Release, das einen Inferenzpfad verbessert, kann Annahmen an anderer Stelle verändern. Ein neuer Kernel oder ein Attention-Backend kann den Durchsatz für eine Modellfamilie verbessern und keine Wirkung auf eine andere haben. Ein Container-Update kann einen Fehler beheben und gleichzeitig das Speicherverhalten ändern. Der Akzeptanztest muss wiederholt werden, wenn sich der Stack ändert.

Für viele Käufer ist dies die eigentliche Kostenlinie. Die erste erfolgreiche Portierung auf ROCm ist wichtig, aber die wiederkehrende Arbeit besteht darin, den Lauf akzeptiert zu halten, während ROCm, PyTorch, vLLM, Modellarchitekturen, Quantisierungsmethoden und Cloud-Images sich weiterentwickeln. Ein Team, das AMD als einmaligen Hardware-Ersatz behandelt, wird diese Arbeit unterschätzen. Ein Team, das ROCm als zweite Produktionsplattform mit eigener Release-Freigabe und Regressionsprüfung behandelt, hat bessere Chancen, die Wirtschaftlichkeit real werden zu lassen.

Container verringern Reibung, beseitigen aber nicht die Akzeptanz

AMDs praktischste Antwort auf die übliche Betreiberangst ist der containerisierte Workflow. DieROCm vLLM-Inferenzdokumentationverweist auf ein ROCm-fähiges vLLM-Docker-Image für Large-Language-Model-Inferenz auf MI355X-, MI350X-, MI325X- und MI300X-GPUs. Sie beschreibt einen Container, der ROCm, PyTorch und vLLM mit Optimierungen für AMD Instinct Rechenzentrums-GPUs integriert. DiePyTorch-Trainingsdokumentationlistet voroptimierte Modellfamilien über Llama, OpenAI, DeepSeek, Qwen, Stable Diffusion, Flux, NCF und DLRM hinweg auf. DieMegatron-LM-Dokumentationbietet einen versionierten Container-Pfad mit ROCm, PyTorch, Transformer Engine, Flash Attention, hipBLASLt, Triton und RCCL-Komponenten.

Dies ist wichtig, weil ein funktionierender Container oft der kürzeste Weg von der Beschaffungsneugier zu einem ersten akzeptierten Ergebnis ist. Er verengt den Suchraum. Er gibt dem Betreiber einen bekannten Satz von Komponentenversionen. Er ermöglicht einem Cloud- oder Plattformteam, ein wiederholbares Basis-Image zu erstellen, anstatt jede Anwendungsgruppe zu bitten, ROCm von Grund auf zusammenzustellen. Er gibt auch Support-Teams ein gemeinsames Vokabular: dieser Container, diese ROCm-Version, diese GPU, diese Modellfamilie, dieser Befehl, dieses Ergebnis.

Der Container ist dennoch nicht das Akzeptanzzertifikat. Ein Container kann für ein dokumentiertes Modell optimiert sein und dennoch am Kundenmodell scheitern, weil die Architektur, Sequenzlänge, Quantisierungsmethode, der Tokenizer, der multimodale Pfad, die KV-Cache-Strategie oder eine benutzerdefinierte Erweiterung abweichen. Ein Container kann auf einem einzelnen Knoten laufen und dennoch einen Engpass offenbaren, wenn mehrere Knoten Gradienten austauschen oder ein stoßartiges Verkehrsmuster bedienen.

Ein Container kann guten Durchsatz liefern, während er das Geschäftsziel verfehlt, weil Latenzausläufer, Kaltstarts, Kontextlänge, Speicherfragmentierung oder Verzögerungen im Scheduling nicht akzeptabel sind. Er kann auch veralten, wenn sich Upstream-vLLM oder PyTorch weiterentwickeln.

Der Nenner der akzeptierten Ausgabe diszipliniert dies. Bei der Inferenz ist die Ausgabe nicht "vLLM gestartet." Es ist eine gesteuerte, modellgestützte Aktion oder Antwort, die unter einem definierten Serviceziel geliefert wird, mit ausreichender Beobachtbarkeit und Rollback, um den Produktionsbetrieb zu unterstützen. Beim Training oder Fine-Tuning ist die Ausgabe nicht "das Skript lief." Es ist eine Trainings- oder Evaluierungsdateneinheit, die auf die Zielqualität oder den Checkpoint-Zustand verarbeitet wurde, mit wiederholbarer Leistung und Wiederherstellung.

Der Nenner können bediente Tokens, erfolgreiche Anfragen, abgeschlossene Batches, Trainingsproben, Fine-Tuning-Jobs, Evaluierungsläufe oder akzeptierte Modellartefakte sein. Was zählt, ist, dass der Nenner sichtbar ist, bevor die Plattform gekauft wird.

AMDs Container-Arbeit kann Einrichtungs- und Abstimmungszeit reduzieren, beseitigt aber nicht die Überprüfung. Ingenieure müssen immer noch die Zeit aufwenden für die Auswahl des Images, die Validierung des Modells, das Patchen von Inkompatibilitäten, das Schreiben von Bereitstellungsvorlagen, das Setzen von Umgebungsvariablen, die Überwachung des GPU-Speichers, die Interpretation von ROCm-Fehlern, den Vergleich des Durchsatzes mit Alternativen und die Entscheidung, ob eine Regression von AMD, Upstream-vLLM, einer Modelländerung, einem Cloud-Image oder der Anwendung verursacht wird. Diese Aufgaben sind keine Mängel der Strategie.

Sie sind der Preis für die Einführung eines zweiten ernsthaften Beschleuniger-Stacks.

Die Käuferfrage ist, ob dieser Preis niedriger ist als der Nutzen. Wenn AMDs Speicherkapazität einem Team erlaubt, ein größeres Modell pro Knoten zu bedienen, Replikate zu konsolidieren, die knotenübergreifende Kommunikation zu reduzieren oder einen teureren Beschleuniger zu vermeiden, kann die Antwort ja sein. Wenn die Workload innerhalb dokumentierter Container bleibt und gängige Modellfamilien nutzt, wird die Antwort einfacher. Wenn die Workload auf benutzerdefinierten CUDA-Erweiterungen, ungewöhnlichen Kernels, strikten Latenzanforderungen oder einer Anbieterregion beruht, in der AMD-Kapazität knapp ist, wird die Antwort schwieriger.

Benchmarks sind nützlich, wenn sie als Akzeptanzbeleg behandelt werden, nicht als Schicksal

Öffentliche Benchmark-Belege sind inzwischen stark genug, dass sie nicht abgetan werden können. MLCommons gab bekannt, dass die RundeMLPerf Training v6.024 einreichende Organisationen umfasste, darunter AMD, Azure, Dell, HPE, NVIDIA, Oracle, Supermicro und andere. Diese Breite zählt. MLPerf ist keine private Folie mit ungenannten Bedingungen. Es handelt sich um regelgesteuerte Benchmark-Evidenz, und Trainingsbenchmarks messen vollständige Systeme, die Modelle auf eine Zielqualitätsmetrik bringen.

AMDs eigeneMLPerf Training v6.0-Diskussionist spezifischer. AMD gibt an, dass seine MI355X-Plattform eine 3,5-fache Generationenverbesserung beim Fine-Tuning von Llama 2-70B von der ersten MI300X-Einreichung zur MI355X-Einreichung zeigte und dass die MI355X innerhalb von 5 % an die NVIDIA B200 beim Llama 2-70B Fine-Tuning und innerhalb von 6 % beim Llama 3.1-8B Pre-Training in den genannten MLPerf Training 6.0-Vergleichen herankam. AMD gibt außerdem an, dass die Runde seine erste Mehrknoten-Trainingseinreichung und 10 Ökosystempartner umfasste, die auf AMD Instinct-Plattformen einreichten.

Oracles öffentliche Diskussion seiner FLUX.1 MLPerf Training v6.0-Einreichung fügt eine weitere Art von Evidenz hinzu. Oracle meldete eine verifizierte Trainingszeit von 74,44 Minuten auf 512 AMD Instinct MI300X GPUs über 64 OCI BM.GPU.MI300X.8-Knoten, wobei alle zehn Läufe die Zielqualität erreichten. Das ist keine normale Unternehmensbereitstellung und keine pauschale Aussage über jeden Kunden. Aber es ist bedeutsam, weil es mehr als Einzel-GPU-Arithmetik testet. Es betrifft verteiltes Training, Cluster-Netzwerk, ROCm-Kernel, Datenplatzierung, Knotenkoordination und Wiederholungsläufe.

Der Fehler ist, dies als Schicksal für die eigene Workload eines Käufers zu lesen. Ein Benchmark kann unter Regeln akzeptiert werden und dennoch weit von einer Kunden-Workload entfernt sein. MLPerf-Modelle, Datensätze, Präzisionseinstellungen, Softwareversionen und Einreichungsregeln sind bekannt; Kunden-Workloads können unordentlicher sein. Das Modell kann einen benutzerdefinierten Operator haben. Der Serving-Pfad kann Retrieval, Sicherheitsfilter, Logging, strukturierte Ausgabe, Tool-Aufrufe, Adapter, langen Kontext oder multimodale Vorverarbeitung umfassen.

Das Training kann Datenbereinigung, Checkpoint-Richtlinien, Experimentverfolgung, Spot-/unterbrechbare Kapazität oder Compliance-Kontrollen einschließen. Nichts davon entkräftet MLPerf. Es besagt nur, dass der Benchmark eine Quelle von Evidenz ist, nicht die vollständige Beschaffungsantwort.

Der richtige Gebrauch dieser Ergebnisse ist vergleichende Disziplin. AMD hat gezeigt, dass sein Stack an anspruchsvollen, öffentlichen, regelgebundenen Tests teilnehmen kann. Das verringert das Risiko, dass der Käufer eine rein theoretische Alternative in Betracht zieht. Es gibt Teams auch einen Satz von Fragen an die Hand: Welcher exakte Software-Stack hat das Ergebnis hervorgebracht? Welche Modellfamilie wurde getestet? Wie viele Läufe erreichten die Zielqualität? Wie war der Maßstab? Was ging während der Vorbereitung kaputt? Welche Partnersysteme reproduzierten ähnliche Ergebnisse? Was passiert, wenn sich das Modell ändert?

Welche Systemzustandsprüfungen wurden vor der Workload durchgeführt?

Mit anderen Worten: MLPerf sollte Käufer sorgfältiger machen, nicht entspannter. Es beweist, dass AMD in ernsthafte Evaluierungen gehört. Es beweist nicht, dass ein Käufer die Evaluierung überspringen kann.

Cloud-Zugang macht aus der Hardware-Frage eine Kapazitäts- und Verantwortungsfrage

Cloud-Verfügbarkeit ist für viele Teams der schnellste Weg, AMD zu evaluieren, aber sie verändert die Form des Risikos. AMD kündigte 2024 an, dassAzure ND MI300X v5 VMsallgemein verfügbar seien und dass Microsoft MI300X- und ROCm-betriebene VMs für GPT-Workloads nutze. Microsoft veröffentlicht separat einenAzure ND MI300X v5 Linux-Treiberleitfaden, der die empfohlene Marketplace-Image-Installation und Ubuntu-Installations-/Upgrade-Szenarien abdeckt. Oracles Dokumentation listetBM.GPU.MI300X.8mit acht MI300X 192 GB GPUs und BM.GPU.MI355X.8 mit acht MI355X 288 GB GPUs auf. AMDs OCI-Ankündigung besagte, dass OCI Supercluster mit MI300X bis zu 16.384 GPUs in einem einzigen Cluster unterstützte.

Das sind substanzielle Verfügbarkeitssignale. Sie zeigen auch, warum AMD nicht so bewertet werden sollte, als kaufe der Kunde einen losen Chip. Der Cloud-Anbieter liefert den Instanztyp, das Basis-Image, den Quotenprozess, das Networking, den Speicher, den Support-Workflow, die regionale Verfügbarkeit, den Wartungsplan und die Incident-Response. AMD liefert den Beschleuniger- und ROCm-Stack, der in dieser Umgebung funktionieren muss. Der Kunde liefert die Workload, Daten, Modellzugriff, Bereitstellung, Tests und Akzeptanzkriterien.

Für einen Käufer beseitigt der Cloud-Weg einen Teil des Kapital- und Integrationsaufwands. Er kann Serverbeschaffung, Fragen zu Strom und Kühlung im Rechenzentrum und lange Hardware-Lieferzeiten vermeiden. Er kann einen kurzen Proof-of-Concept-Pfad bieten. Er kann aber auch neue Unsicherheiten schaffen. Dass ein Cloud-Instanztyp dokumentiert ist, bedeutet nicht, dass jede Region sofort Kapazität für einen neuen Kunden hat. Quoten können begrenzt sein. Ein verwaltetes Image kann hinter einem AMD-Release zurückbleiben oder von einem Upstream-Container abweichen.

Die Netzwerktopologie kann für einige verteilte Workloads besser geeignet sein als für andere. Preise und Rabatte können von der Schlagzeilen-Beschleunigererzählung abweichen. Support-Eskalationen können über den Cloud-Anbieter laufen, bevor sie AMD erreichen.

Die akzeptierte Workload sollte daher Kapazitätsnachweise einschließen. Kann das Team den Instanztyp in der Region beziehen, in der Daten- und Compliance-Anforderungen den Betrieb erlauben? Kann es genügend Kapazität für den Produktionsbetrieb reservieren oder nur für Burst-Tests? Kann es den Lauf in einer anderen Region oder bei einem anderen Anbieter reproduzieren, wenn die Quote verschwindet? Benötigt die Workload Bare Metal, VM-Isolation, Kubernetes, Slurm oder eine verwaltete Model-Serving-Plattform? Was ist der Fallback, wenn AMD-Kapazität während eines Vorfalls oder eines Launch-Fensters nicht verfügbar ist?

Dies ist besonders wichtig für Organisationen, die AMD nutzen, um die Abhängigkeit von einem dominanten Beschleunigeranbieter zu verringern. Ein zweiter Siliziumpfad verbessert die Resilienz nur dann, wenn er tatsächlich zugänglich ist, wenn er gebraucht wird. Existiert der AMD-Pfad nur als kleiner Evaluierungscluster, während der Produktionspfad vollständig auf CUDA verbleibt, ist es eine Lernübung. Kann der AMD-Pfad einen benannten Anteil an Inferenz, Fine-Tuning, Evaluierung oder Batch-Verarbeitung unter einem definierten Failover-Plan ausführen, ist es ein strategischer Hebel.

Der Unterschied liegt nicht im Chip, sondern in Kapazität, Betriebsbereitschaft und Routing-Politik.

Portierungskosten sind der Teil des Preises, der nicht im Angebot erscheint

AMDs direkteste Herausforderung an etablierte Beschleuniger-Software ist die HIP- und ROCm-Portabilität. AMDsHIP-Portierungsleitfadenbeschreibt HIP als eine C++-Laufzeit-API und Kernel-Sprache für AMD-GPUs, die es Entwicklern ermöglicht, CUDA-Code zu konvertieren, um auf AMD-GPUs zu laufen, und empfiehlt Werkzeuge wie HIPIFY sowie inkrementelle Portierung und Tests. Das ist ein nützlicher Weg für Anwendungen mit GPU-Code, die sich nicht einfach auf Framework-Unterstützung verlassen können.

Aber der praktische Rat des Leitfadens ist auch die Warnung. Portierung ist Arbeit. Sie beginnt mit einer funktionierenden CUDA-Codebasis, durchläuft dann Konvertierung, Kompilierung, Tests und Abstimmung in Stufen. Die einfachen Fälle mögen größtenteils mechanisch sein. Die schwierigen Fälle betreffen CUDA-spezifische Bibliotheken, benutzerdefinierte Kernel, Annahmen über das Speicherverhalten, Build-Systeme, Inline-Assembly, Profiling-Werkzeuge, kollektive Kommunikation, Attention-Kernel, Quantisierungsroutinen, benutzerdefinierte PyTorch-Erweiterungen oder Drittanbieterpakete, die ROCm nicht priorisiert haben.

Selbst wenn der Code läuft, ist die Leistungsportabilität eine separate Frage von der Korrektheit.

Hier kann die AMD-Ökonomie falsch verstanden werden. Ein Beschaffungsteam sieht vielleicht einen niedrigeren Beschleunigerpreis, mehr Speicher pro Gerät oder bessere Verfügbarkeit und nimmt an, der Business Case sei offensichtlich. Das Plattformteam stellt dann fest, dass die relevante Anwendung nicht nur PyTorch aus einem sauberen Container ist. Sie umfasst eine benutzerdefinierte Erweiterung, einen Serving-Wrapper, eine reine CUDA-Abhängigkeit, eine Überwachungskomponente, ein Scheduler-Plugin und Bereitstellungsskripte, die um NVIDIA-Annahmen herum geschrieben sind. Jede Anpassung mag für sich genommen rational sein.

Zusammen werden sie zum Migrationsposten, der im Hardwarevergleich fehlte.

Das Gegenteil kann ebenfalls eintreten. Ein Team mag das Portierungsproblem überbewerten, weil es sich an ältere ROCm-Lücken oder schmerzhafte Erfahrungen mit Consumer-GPUs erinnert. Wenn die Workload gängige Llama- oder Qwen-Inferenz über einen dokumentierten ROCm-vLLM-Container oder ein unterstütztes Trainingsrezept auf Instinct-Hardware ist, kann der inkrementelle Aufwand gering sein. Wenn die Anwendung Standard-Framework-Pfade nutzt und das Team ein als gut bekanntes Image festlegen kann, kann AMD schnell evaluiert werden.

Wenn der Hauptengpass die Speicherkapazität und nicht exotischer CUDA-Code ist, kann Instincts Speicherprofil einen echten betrieblichen Vorteil bringen.

Der richtige Vergleich ist nicht abstrakt „AMD versus NVIDIA“. Es sind die Kosten pro akzeptiertem Lauf für eine benannte Aufgabe. Vergleichen Sie den AMD-Pfad mit dem Verbleib auf CUDA, dem Einsatz eines verwalteten Cloud-/Modellanbieters, der Modellverkleinerung, der Nutzung eines Open-Source-Modells auf vorhandener Kapazität, dem Kauf eines etablierten SaaS-Workflows, dem Aufbau eigener Orchestrierung oder dem Zurückfahren der Aufgabe. Beziehen Sie Engineering-Zeit, Support-Verträge, Cloud-Verpflichtungen, fehlgeschlagene Läufe, Testdatenvorbereitung, Beobachtbarkeit, Modellprüfung, Rollback, Incident-Abdeckung und Ausstiegskosten ein.

Für einige Workloads wird AMD gewinnen, weil die Workload dokumentiert, speicherhungrig, portabel und auf dem etablierten Pfad teuer ist. Für andere wird das etablierte Software-Ökosystem gewinnen, weil die versteckten Portierungs- und Supportkosten größer sind als die Einsparung beim Beschleuniger. Die einzige schlechte Evaluierung ist die, die Hardwaredollar zählt und Ingenieurwochen ignoriert.

Die Zuverlässigkeitsarbeit beginnt vor dem Modell

Akzeptierte Beschleuniger-Workloads benötigen Vorabprüfungen. AMDsLeitfaden für Systemzustandsbenchmarksbesagt, dass Teams validieren sollten, ob AMD-Hardware korrekt konfiguriert ist und optimal läuft, bevor KI-Workloads ausgeführt werden, und verweist auf die ROCm Validation Suite, RCCL-Tests, BabelStream und TransferBench. Das ist kein Papierkram. So vermeidet ein Team, ein Modellproblem mit einem defekten Knoten, einem falsch konfigurierten IOMMU, schwacher Speicherbandbreite, schlechter Verbindung oder einem Problem der kollektiven Kommunikation zu verwechseln.

In der Produktion wird diese Schicht noch wichtiger, weil die Fehlermodi mehrdeutig sind. Wenn ein Trainingsjob langsamer wird – ist die Ursache ROCm, eine ausgefallene GPU, eine degradierte Verbindung, Speichervarianz, ein Engpass beim Datenlader, thermisches Verhalten, Cloud-Noisy-Neighbor-Effekte, eine Modelländerung oder ein neuer Framework-Kernel? Wenn die Inferenzlatenz ansteigt – ist die Ursache Batching, KV-Cache-Druck, Anforderungsform, Tokenisierung, Speicherfragmentierung, Scheduler-Platzierung, Taktverhalten, Logging, Netzwerk oder eine Regression im Serving-Stack? Ohne Zustands- und Basistests diskutiert das Team über Meinungen.

Hier muss AMD nicht nur mit Silizium wettbewerben, sondern auch mit betrieblichem Muskelgedächtnis. Viele KI-Teams haben jahrelange CUDA-Debugging-Gewohnheiten. Sie wissen, welche NVIDIA-Werkzeuge sie nutzen müssen, welche Fehler häufig sind, welchen Forenbeiträgen sie vertrauen, welche Container-Tags sicher sind und welche Leistungsindikatoren zählen. Die Einführung von ROCm erfordert äquivalente Gewohnheiten. AMD kann Werkzeuge und Dokumentation veröffentlichen, aber Käufer brauchen dennoch Leute, die wissen, wie man sie unter Druck einsetzt.

Ein Lauf ist nicht allein deshalb akzeptiert, weil er einmal an einem ruhigen Nachmittag bestanden wurde. Er ist akzeptiert, wenn das Team ihn erklären, überwachen und wiederherstellen kann.

Der betriebliche Akzeptanztest sollte mindestens fünf Schichten umfassen. Erstens, Hardware-Zustand: RVS, Speicherbandbreite, GPU-Sichtbarkeit und thermische/strombezogene Plausibilität. Zweitens, Kommunikation: kollektive RCCL-Korrektheit und Leistung für die Knoten- oder Clustergröße. Drittens, Framework: PyTorch, vLLM, Megatron-LM oder der gewählte Stack unter festgelegten Versionen. Viertens, Workload: das tatsächliche Modell und Datenmuster, nicht nur ein Anbieterbeispiel.

Fünftens, Wiederherstellung: Neustart aus einem Checkpoint, Zurücksetzen auf ein als gut bekanntes Image, Entleeren eines Knotens, Reproduzieren einer fehlgeschlagenen Anforderung und Dokumentieren, wer handelt, wenn der Fehler auftritt.

Das mag teuer klingen. Ist es auch. Aber es ist auch die einzig faire Art, Plattformen zu vergleichen. Wenn der etablierte CUDA-Pfad jahrelange versteckte betriebliche Investitionen aufweist, sollte AMD nicht nur den marginalen Hardwarepreis schlagen müssen. Es sollte mit den vollen Kosten verglichen werden, den etablierten Pfad gesund zu halten. Umgekehrt, wenn der Käufer keine starke etablierte Praxis hat und KI-Infrastruktur von Grund auf aufbaut, kann AMD früher einsteigen und einige Wechselkosten vermeiden.

Die Produktionsaufgabe ist wiederholte Akzeptanz. Eine Plattform, die einen einzigen Lauf zum Laufen bringt, ist interessant. Eine Plattform, die dieselbe Klasse von Läufen auch nach Aktualisierungen, Ausfällen und Personalwechseln akzeptiert hält, ist wertvoll.

Unternehmens-KI-Software ändert das Verkaufsversprechen, aber nicht den Nenner

AMD versucht, im Stack nach oben zu wandern. DieAMD Enterprise AI Suiteist positioniert als Verbindung von Open-Source-KI-Frameworks und generativen KI-Modellen mit einer unternehmenstauglichen Kubernetes-Plattform. AMD Inference Microservices und Referenz-Stacks sollen die Distanz zwischen Bare Metal und einem laufenden KI-Dienst verringern. Das ist strategisch notwendig. Während KI-Infrastruktur von Elite-Modelllabors zu gewöhnlichen Unternehmen wandert, wollen Käufer weniger rohe Teile und mehr bereitstellungsfähige Systeme.

Der Schritt ist auch eine Antwort auf das Wettbewerbsmuster, das etablierte Beschleuniger-Ökosysteme gesetzt haben. Hardware-Anbieter verkaufen zunehmend Software, Referenz-Container, Modellserver, Orchestrierung, Beobachtbarkeits-Hooks, Microservices und Unternehmens-Support. Der Käufer will keine Kiste mit theoretischen FLOPS. Er will einen gesteuerten Workflow: dieses Modell bereitstellen, diese Anfragen routen, diese Richtlinien durchsetzen, diese Protokolle sammeln, diesen Container aktualisieren, sicher zurückrollen, diesem Team in Rechnung stellen und nachweisen, dass der Dienst innerhalb der Grenzen blieb.

AMDs Chance besteht darin, diesen Workflow mit Open-Source-Grundlagen und weniger Lock-in anzubieten. Wenn Enterprise AI Suite, AIMs, ROCm-Container und Kubernetes-Integration die AMD-Infrastruktur leichter akzeptierbar machen, kann das Unternehmen über den betrieblichen Nenner konkurrieren, nicht über den reinen Komponentenvergleich. Ein Plattformteam mag sich nicht dafür interessieren, welcher Kernel eine Beschleunigung lieferte, wenn der Dienst mit weniger Reibung als erwartet bereitgestellt, beobachtet, aktualisiert und wiederhergestellt werden kann.

Das Risiko besteht darin, dass eine höherwertige Suite eine neue zu validierende Schicht schafft. Ein Kubernetes-Referenz-Stack hat weiterhin einen Cluster-Lebenszyklus, Image-Provenienz, Netzwerkrichtlinien, Speicher, Geheimnisse, Modellregister, Autoskalierung, Knotenentleerungen, Upgrade-Kadenz und Incident-Response. Inferenz-Microservices benötigen weiterhin modellspezifische Akzeptanz, Eingabevalidierung, Ausgabeüberwachung, Latenz-SLOs, Sicherheitsprüfung und Kostenzuordnung. Ein Referenz-Bauplan kann den Weg verkürzen; er kann ein Modell nicht ohne Kundenrichtlinien und -daten in eine gesteuerte Geschäftsaktion verwandeln.

Diese Unterscheidung ist wichtig für regulierte oder folgenreiche Nutzung. Wenn ein AMD-betriebenes Modell Supportfragen beantwortet, klinische Notizen routet, juristisches Material zusammenfasst, eine Sicherheitsaktion auslöst oder Code generiert, ist die akzeptierte Ausgabe nicht das Token. Es ist die überprüfte Aktion innerhalb eines Workflows. Der Infrastruktur-Stack muss Zuverlässigkeit bieten, aber der Kunde braucht dennoch Regeln für menschliche Überprüfung, Audit, Ausnahmebehandlung und Fallback. AMD kann den Beschleuniger-Lauf billiger oder portabler machen. Es besitzt nicht die Entscheidungsqualität des Kunden.

Die beste Rolle für AMDs Unternehmensschicht ist daher pragmatisch: Reduzieren Sie die mit Infrastrukturdetails verschwendete Zeit, damit Teams mehr Zeit für die Workload-Akzeptanz aufwenden können. Wenn sie lediglich Komplexität von der ROCm-Installation in eine andere Management-Ebene verlagert, werden Käufer dies abwerten. Wenn sie gängige Inferenz- und Trainingsmuster in wiederholbare, unterstützbare Bereitstellungen überführt, greift sie direkt AMDs historische Schwäche an: die Angst, dass nicht-CUDA-Pfade zu viel Aufmerksamkeit der Ingenieure kosten.

Der Business Case muss den Fallback berücksichtigen

Fallback ist kein Versagenspessimismus. Er ist Teil des Preises. Ein Team, das AMD für KI-Infrastruktur einführt, sollte entscheiden, was passiert, wenn die Workload die Akzeptanz verfehlt. Geht es zurück zu CUDA? Wird ein kleineres Modell betrieben? Wird zu einer verwalteten API gewechselt? Behält es einen CPU-Pfad für Batch-Arbeiten? Wird AMD für Evaluierung und NVIDIA für latenzkritisches Serving genutzt? Wird der Verkehr nach Modellfamilie aufgeteilt? Wird die Produktion verzögert, bis ein fehlender Kernel verfügbar ist?

Jeder Fallback hat Kosten. Die Pflege zweier Beschleuniger-Stacks kann Verhandlungsmacht und Resilienz verbessern, aber sie kann die Testmatrix verdoppeln. CUDA als Sicherheitspfad beizubehalten reduziert das Migrationsrisiko, kann aber die etablierte Abhängigkeit bewahren, die AMD eigentlich verringern sollte. AMD nur für Überlauf zu nutzen, kann Ingenieure unerfahren lassen, wenn Produktionsdruck entsteht. AMD für alle neuen Workloads zu verwenden, kann das Risiko konzentrieren, wenn das Team nicht genügend ROCm-Expertise aufgebaut hat. Cloud-Kapazität für beide Pfade zu kaufen, kann die Kontinuität verbessern und Rabatte schmälern.

Deshalb sollte die kommerzielle Frage in akzeptierten Ausgabeeinheiten gestellt werden. Für Inferenz zählen Sie Kosten pro Million akzeptierter Anfragen, Kosten pro erfolgreicher Werkzeugaktion, Kosten pro generierter Codeänderung, die die Prüfung besteht, oder Kosten pro gesteuerter Antwort, die unter Latenz- und Sicherheitsauflagen geliefert wird. Für Training zählen Sie Kosten pro akzeptiertem Fine-Tune, Kosten pro Trainingslauf mit Zielqualität, Kosten pro Evaluierungsergebnis oder Kosten pro Wiederholungstrainingszyklus.

Der Zähler umfasst Hardware- oder Cloud-Ausgaben, Software-Support, Personalzeit, fehlgeschlagene Läufe, Validierung, Überwachung, Migration und Fallback. Der Nenner schließt Ausgaben aus, die die Akzeptanz verfehlen.

AMDs Speicherkapazität kann in dieser Gleichung stark ins Gewicht fallen. Mehr HBM pro Beschleuniger kann die Notwendigkeit verringern, bestimmte Modelle zu sharden, größere Kontexte zu unterstützen, den Batching-Spielraum zu verbessern oder die Bereitstellung zu vereinfachen. Aber Speicher allein reicht nicht. Wenn ein Modell passt, aber sein Attention-Backend schwach ist, können die akzeptierten Kosten dennoch schlecht sein. Wenn der Durchsatz gut, aber der Rollback unklar ist, kann ein regulierter Käufer die Bereitstellung ablehnen.

Wenn Cloud-Kapazität günstig, aber in der benötigten Region nicht verfügbar ist, sind die theoretischen Kosten irrelevant.

Die realistischen Alternativen sind vielfältig. Bei NVIDIA zu bleiben mag teuer, aber betrieblich vertraut sein. Ein verwalteter Modelldienst eines Cloud-Anbieters kann das Beschleuniger-Management vermeiden, aber Kontrolle und Portabilität verringern. Ein etabliertes SaaS-Produkt kann den Geschäftsworkflow liefern, ohne GPU-Details preiszugeben, auf Kosten der Anpassbarkeit. Open Source auf vorhandener Hardware kann ausreichen, wenn die Aufgabe Latenz oder kleinere Modelle toleriert. Weniger von der Aufgabe zu tun, kann rational sein, wenn der Prüfaufwand den Automatisierungsgewinn übersteigt.

AMD gewinnt nur, wenn sein Weg diese Alternativen schlägt, nachdem die versteckte Arbeit einbezogen ist. Das ist ein strengerer Maßstab als „günstiger als der etablierte Beschleuniger“. Es ist auch ein besserer Maßstab für AMD, denn er identifiziert, wo das Unternehmen sich verbessern kann: Support-Matrizen, Container, Modellabdeckung, Debugging-Werkzeuge, Cloud-Verfügbarkeit, Unternehmens-Referenz-Stacks, Partner-Reproduzierbarkeit und Workload-spezifische Nachweise.

Worauf als Nächstes zu achten ist

Der erste Beobachtungspunkt ist Kompatibilitätsdrift. Die ROCm-Releases verbessern sich, aber jede Verbesserung schafft eine neue Versionsentscheidung. Käufer sollten nachverfolgen, welche ROCm-Version, Framework-Version, Container-Tag und GPU-Firmware für jede Workload akzeptiert sind. Sie sollten festhalten, warum ein Update vorgenommen wird, welche Regressionstests bestanden wurden und wie man zurückrollt.

Der zweite Punkt ist Kernel- und Modellabdeckung. Öffentliche Dokumente listen gängige Modellfamilien auf, und AMD hat starke Benchmark-Belege, aber die Mischung der KI-Modelle ändert sich schnell. Mixture-of-Experts-Modelle nach DeepSeek-Art, Workloads mit langem Kontext, multimodale Modelle, Videogenerierung, werkzeugnutzende Modelldienste und spezialisierte Retrieval-Systeme können unterschiedliche Kernel und Speicherpfade beanspruchen. Ein Käufer sollte fragen, ob seine exakte Modellarchitektur unterstützt und abgestimmt ist, nicht, ob ein breiter Familienname in einem Blog erscheint.

Der dritte Punkt ist Cloud-Kapazität. Die Oberflächen von Azure und OCI sind real, aber Quoten, Region, Image-Wartung und Support-Routing sind operative Fakten. Der Wettbewerbswert von AMD steigt, wenn Kunden Kapazität dort beziehen können, wo sie sie brauchen, und wenn Anbieter Images aktuell halten, ohne als gut bekannte Workloads zu brechen.

Der vierte Punkt ist Partner-Reproduzierbarkeit. AMDs MLPerf-Diskussion über Ökosystempartner ist wichtig, weil sie über ein einzelnes Referenzlabor hinausweist. Je mehr Dell, HPE, Supermicro, Cisco, Oracle, Azure und andere Partner akzeptierte Ergebnisse unter dokumentierten Bedingungen reproduzieren können, desto weniger fühlt sich die AMD-Einführung nach Spezialistenarbeit an. Das Gegenteil gilt ebenfalls: Wenn Ergebnisse von einer sorgfältig abgestimmten Konfiguration abhängen, werden normale Käufer die Expertenabhängigkeit einkalkulieren.

Der fünfte Punkt ist menschliche Aufsicht. Selbst wenn AMD eine Workload schneller oder billiger macht, benötigen KI-Infrastrukturteams immer noch Überprüfung, Ausnahmebehandlung, Kostenzuordnung und Wiederherstellung. Modellgestützte Aktionen werden wertvoll, wenn sie gesteuert werden, nicht nur, wenn sie beschleunigt werden. AMD kann helfen, die Infrastrukturkosten dieser Aktionen zu senken, aber es kann nicht die Notwendigkeit beseitigen, zu entscheiden, welche Ausgaben akzeptabel sind.

Der sechste Punkt sind Fallback-Kosten. Wenn ein Team keine klare Antwort darauf hat, was passiert, wenn ein ROCm-Pfad ausfällt, hat es die Evaluierung nicht abgeschlossen. Ein Fallback-Plan sollte vor der Produktion explizit sein, nicht während eines Kundenvorfalls improvisiert werden.

Die Schlussfolgerung ist nicht, dass AMD nicht bereit ist. Sie lautet, dass AMD bereit genug ist, um ernsthaft und operativ evaluiert zu werden. Das ist eine höhere Messlatte als ein Schlagzeilen-Benchmark und ein besseres Zeichen für das Unternehmen. Instinct und ROCm müssen den Markt nicht länger von einer theoretischen Zweitquelle überzeugen. Sie müssen Kunden gewinnen, die Workload für Workload beweisen, dass die Zweitquelle akzeptiert, gewartet und bezahlt werden kann.

Für AMD besteht die Produktionsaufgabe in wiederholtem Vertrauen. Das Unternehmen hat Beschleuniger-Hardware, einen sichtbaren Software-Stack, öffentliche Benchmark-Belege und Cloud-Wege. Der nächste Beweis ist weniger filmreif: Ein Team führt dieselbe Workload nach einem Update erneut aus, sieht dasselbe akzeptierte Ergebnis, weiß, warum es bestanden wurde, weiß, was zu tun ist, wenn es fehlschlägt, und kann zeigen, dass die Gesamtkosten immer noch die Alternative schlagen.