AMDs KI-Beschleuniger-Test: Der zweimal akzeptierte Durchlauf

Zusammenfassung

• AMD wird heute weniger danach beurteilt, ob Instinct-GPUs starke öffentliche Zahlen vorweisen können, sondern danach, ob normale 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 Produktionsoberfläche geworden, mit öffentlichen Kompatibilitätsmatrizen, vLLM- und PyTorch-Container-Pfaden, Health Checks, HIP-Portierungsanleitungen, MLPerf-Einreichungen und Azure/OCI-Bereitstellungswegen. Diese Reife legt auch die versteckte Arbeit offen: Versionsfixierung, Kernel-Abdeckung, Kollektiv-Tests, modellspezifische Optimierung, Kontingentverwaltung, Rollback und Expertenüberprüfung.
• Der kommerzielle Fall besteht nicht einfach aus günstigerem Speicher oder mehr Tokens pro Dollar. AMDs Q1-2026-Einreichung zeigt Dynamik im Rechenzentrum und Nachfrage nach Instinct MI350, aber Käufer müssen dennoch die Gesamtkosten pro akzeptiertem Beschleunigerdurchlauf mit CUDA, Cloud-verwalteten Modelldiensten, etablierter SaaS, offenen CPU/GPU-Kompromissen, interner Portierung und der Reduzierung der Aufgabe vergleichen.
• Die nützlichen Beobachtungspunkte sind Kompatibilitätsdrift, Cloud-Kapazitätsgrenzen, Lücken zwischen Benchmark und Produktion, fehlende Kernel, Framework-Regressionen, Verzögerungen bei der Fehlersuche, OEM-Integrationsverantwortung und Rückfall auf CUDA. AMDs Chance ist groß, weil speicherreiche Beschleuniger und ein offener Stack die Abhängigkeit von einem einzigen Anbieter verringern können; seine Belastung besteht darin, dass die Produktionszuverlässigkeit in den am wenigsten glamourösen Teilen des Stacks entschieden wird.

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

Die aktuelle 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-Nachweise, die vor nur wenigen Jahren noch fern erschienen wären: MI300X- und MI350-Serie-Beschleuniger, ROCm-Releases mit aktueller Framework-Unterstützung, containerisierte vLLM- und Trainingspfade, öffentliche MLPerf-Einreichungen, Azure- und Oracle Cloud-Instanzen sowie eine wachsende KI-Unternehmenssoftware-Schicht. Das Unternehmen steht nicht außerhalb des KI-Infrastrukturmarktes und bittet um Beachtung.

Die schwierigere Frage ist, ob ein Infrastrukturteam eine reale Workload in einen akzeptierten Beschleunigerdurchlauf verwandeln kann. Dieser Nenner ist strenger als eine Benchmark-Punktzahl. Ein akzeptierter Durchlauf 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 Diagnose von Fehlern und einen Wiederherstellungspfad, wenn sich ein Treiber, eine Kernel-Bibliothek, eine Modellarchitektur oder ein Cloud-Image ändert.

Handelt es sich um Inferenz, umfasst die Akzeptanz erfolgreiche Anfrageabwicklung, Latenz unter Last, Speicherverhalten, Batching-Strategie, Korrektheitsprüfungen, Beobachtbarkeit und Rollback. Handelt es sich um Training, umfasst die Akzeptanz Konvergenz- oder Zielqualitätsnachweise, Datenpfadstabilität, Checkpoint-Verhalten, kollektive Kommunikation, Neustartverhalten und Operatorzeit.

Diese Rahmung ist nützlich, weil sie drei Dinge trennt, die oft vermischt werden. Modellfähigkeit ist das, was das Modell tun kann, wenn es läuft. Produktzuverlässigkeit ist, ob AMDs Hardware, ROCm, Container, Bibliotheken, Partner-Images und Dokumentation die Workload vorhersagbar laufen lassen. Kundenergebnis in der Produktion ist, ob sich die tatsächliche Geschäftsaufgabe des Käufers verbessert, nachdem Integrations-, Validierungs-, Überwachungs- und Rückfallkosten berücksichtigt wurden. 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 Ingenieurszeit für die Portierung aufwendet. Ein Benchmark kann gültig sein, während das Modell des Kunden, die Datenform oder die Service-Level-Ziele sich anders verhalten.

AMDs stärkstes Marktargument ist, dass viele KI-Käufer mehr Beschleunigerauswahl wünschen. Sie wollen Speicherreserven, Preisdruck, Angebotsalternativen, geringere Anbieterbindung und Softwarepfade, die nicht jede ernsthafte Workload vom gleichen proprietären Stack abhängig machen. AMDsROCm-Seitebeschreibt einen offenen Software-Stack mit Treibern, Entwicklungswerkzeugen und APIs für die GPU-Programmierung von Low-Level-Kerneln bis hin zu Endbenutzeranwendungen. DieMI350-Serie-Seitepräsentiert eine speicherreiche Beschleunigerfamilie, wobei die MI350X und MI355X bis zu 288 GB HBM3E-Speicher und eine theoretische Spitzenspeicherbandbreite von 8 TB/s bieten, und die MI350P auf PCIe-Bereitstellung in konventionellerer Unternehmensinfrastruktur abzielt.

Das sind bedeutende Eingaben. Sie sind nicht das Ergebnis. Das Ergebnis ist der akzeptierte Durchlauf nach allem, was umständlich ist: unterstützte Betriebssysteme, Kernel-Versionen, Firmware, ROCm-Release, Framework-Version, Modellunterstützung, Quantisierungspfad, Scheduler-Verhalten, Health Checks, Cloud-Region, Kontingent, Image-Wartung, Protokollsichtbarkeit, Expertenzeit, fehlgeschlagene Versuche und Rückfall. Dort wird AMD wirklich getestet.

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

Das Verzeichnisobjekt für diesen Artikel ist AMD, das Unternehmen hinter Instinct-Beschleunigern, ROCm und verwandter KI-Infrastruktursoftware. Diese Grenze ist wichtig, weil AMDs Produkte die 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 Modellserving-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-Packaging und -Support Teil des Ergebnisses. Wenn ein OCI-Cluster einen Benchmark über 64 Knoten skaliert, sind Oracles Netzwerk, Speicher, Bare-Metal-Operationen und Planung Teil des Ergebnisses. Wenn ein OEM-System die richtige Firmware und Kühlungsreserve bereitstellt, ist die Integration des Serverherstellers Teil des Ergebnisses. AMD liefert zentrale Silizium- und 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 scheitern, weil eine Framework-Funktion unreif ist, ein Drittanbieter-Kernel nicht eingetroffen ist, 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 Kollektiv-Tests durchgeführt hat. Einige davon sind AMD-Verantwortlichkeiten, einige sind geteilt, und einige gehören woanders hin.

Für die Beschaffung ist die wichtige Frage nicht die moralische Schuld. Es ist, 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 verfolgt. In seinenErgebnissen des ersten Quartals 2026meldete AMD einen Umsatz von 10,3 Milliarden US-Dollar und sagte, der Umsatz des Rechenzentrumssegments betrug 5,8 Milliarden US-Dollar, ein Anstieg von 57 % gegenüber dem Vorjahr, angetrieben durch EPYC-Prozessoren und den anhaltenden Anstieg der Instinct-GPU-Auslieferungen. SeinFormular 10-Q für das erste Quartal 2026beschreibt das Rechenzentrumswachstum als hauptsächlich getrieben durch EPYC-Prozessoren der 5. Generation und Instinct MI350 Series GPUs. Das ist kommerzielle Dynamik, nicht nur eine Laborbehauptung.

Umsatzdynamik beantwortet jedoch nicht die betriebliche Frage des Käufers. Ein Cloud-Plattformteam, das AMD in Betracht zieht, muss fragen, ob der Software- und Supportpfad gewöhnlich genug für das eigene Personal ist. Ein Modellserving-Betreiber muss wissen, ob das relevante Modell das richtige Attention-Backend, den richtigen Quantisierungspfad und die richtige Batching-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 größere Speicherkapazität die zusätzliche Ingenieurszeit für die Portierung und Wartung eines zweiten Stacks überstehen.

Die rechtliche und markenrechtliche Grenze ist daher praktisch. AMD ist das Subjekt, weil es die Strategie von Instinct und ROCm kontrolliert. Aber die akzeptierte Workload ist eine Kette. Sie ist weder ein AMD-Chip isoliert noch eine glänzende KI-Behauptung eines Cloud-Anbieters isoliert.

ROCm-Reife ist in der Dokumentation sichtbar

Ein Zeichen für einen reifenden Beschleuniger-Stack ist langweilige Dokumentation. ROCm hat jetzt davon in nützlichem Umfang. AMDsKompatibilitätsmatrix, aktualisiert Ende Mai 2026 in der für diesen Artikel überprüften Version, ist nicht glamourös. Sie ist genau die Art von Artefakt, die Produktionsteams benötigen: releaseweise Kompatibilität über Betriebssysteme, GPUs und Framework-Komponenten hinweg. DieLinux-Systemanforderungengehen noch weiter, listen unterstützte und nicht unterstützte Hardware-/OS-Kombinationen auf und warnen, dass nicht unterstützte GPUs einige HIP-Runtime-Pfade ausführen können, während vorgefertigte ROCm-Bibliotheken offiziell nicht unterstützt werden und Laufzeitfehler verursachen können.

Diese Dokumentation ändert, wie AMD beurteilt werden sollte. Vor fünf Jahren hätte ein Käufer fragen können, ob ROCm in sinnvoller Weise für KI-Arbeit existiert. Im Jahr 2026 ist die bessere Frage, ob die genaue Kombination des Teams innerhalb des unterstützten Bereichs liegt und ob sie dort im Laufe der Zeit bleiben kann. MI300X, MI325X, MI350X und MI355X sind nicht austauschbare Bezeichnungen. Ubuntu, RHEL, Debian, Oracle Linux, Rocky Linux und SLES-Unterstützung können sich je nach Release und GPU unterscheiden. TensorFlow, PyTorch, JAX, Triton, RCCL, hipBLASLt und andere Komponenten bewegen sich in ihrem eigenen Rhythmus.

Ein akzeptierter Durchlauf benötigt diese Matrix, die 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 Pfade 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 dennoch entscheiden, ob es ein Anbieter-Image, ein Upstream-Framework-Release, einen AMD-Container, ein Cloud-Marketplace-Image, einen benutzerdefinierten Docker-Build oder ein intern gesegnetes Basis-Image verwendet. Es muss entscheiden, wie schnell es ROCm-Updates übernimmt und wie lange es einen bekannten guten Stack fixiert.

AMDsROCm 7.2.4-Versionshinweisebeschreiben ein Qualitätsrelease, das sich auf Leistungs- und Stabilitätsbehebungen für KI-Inferenzworkloads auf AMD Instinct GPUs konzentriert. Das ist beruhigend, aber es ist auch eine Erinnerung daran, dass Beschleunigersoftware eine lebende Maschine ist. Ein Release, das einen Inferenzpfad verbessert, kann Annahmen anderswo verändern. Ein neuer Kernel oder ein neues Attention-Backend kann den Durchsatz für eine Modellfamilie verbessern und auf eine andere keine Auswirkung 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 Durchlauf akzeptiert zu halten, während ROCm, PyTorch, vLLM, Modellarchitekturen, Quantisierungsmethoden und Cloud-Images sich bewegen. Ein Team, das AMD als einmaligen Hardwareersatz behandelt, wird diese Arbeit unterschätzen. Ein Team, das ROCm als zweite Produktionsplattform behandelt, mit eigenem Release-Gate und Regressions-Test-Suite, hat bessere Chancen, die Wirtschaftlichkeit real zu machen.

Container reduzieren Reibung, aber sie beseitigen nicht die Akzeptanz

AMDs praktischste Antwort auf die Angst normaler Operateure ist der containerisierte Workflow. DieROCm-vLLM-Inferenzdokumentationverweist auf ein ROCm-fähiges vLLM-Docker-Image für die Inferenz großer Sprachmodelle 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 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 Operator eine bekannte Menge von Komponentenversionen. Er ermöglicht einem Cloud- oder Plattformteam, ein wiederholbares Basis-Image zu erstellen, anstatt jede Anwendungsgruppe zu bitten, ROCm von Grund auf zusammenzubauen. Er gibt auch Supportteams eine gemeinsame Sprache: dieser Container, diese ROCm-Version, diese GPU, diese Modellfamilie, dieser Befehl, dieses Ergebnis.

Der Container ist immer noch nicht das Akzeptanzzertifikat. Ein Container kann für ein dokumentiertes Modell optimiert sein und dennoch beim Modell eines Kunden scheitern, weil die Architektur, Sequenzlänge, Quantisierungsmethode, Tokenizer, multimodaler Pfad, KV-Cache-Strategie oder benutzerdefinierte Erweiterung abweicht. Ein Container kann auf einem einzelnen Knoten laufen und dennoch einen Engpass offenbaren, wenn mehrere Knoten Gradienten austauschen oder ein burstiges Verkehrsmuster bedienen.

Ein Container kann einen guten Durchsatz liefern und dennoch das Geschäftsziel verfehlen, weil Latenzenden, Kaltstarts, Kontextlänge, Speicherfragmentierung oder Planungsverzögerungen inakzeptabel sind. Er kann auch veralten, wenn sich Upstream-vLLM oder PyTorch weiterentwickeln.

Der akzeptierte-Ausgabe-Nenner diszipliniert dies. Für 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 die Produktion zu unterstützen. Für Training oder Feintuning ist die Ausgabe nicht „das Skript lief“. Es ist eine verarbeitete Trainings- oder Bewertungsdateneinheit, die bis zur Zielqualität oder zum Checkpoint-Zustand verarbeitet wurde, mit wiederholbarer Leistung und Wiederherstellung.

Der Nenner können bediente Tokens, erfolgreiche Anfragen, abgeschlossene Batches, Trainingsstichproben, Feintuning-Jobs, Evaluierungsläufe oder akzeptierte Modellartefakte sein. Wichtig ist, dass der Nenner vor dem Kauf der Plattform sichtbar ist.

AMDs Containerarbeit kann Setup- und Optimierungszeit reduzieren, aber sie beseitigt nicht die Überprüfung. Ingenieure müssen immer noch die Zeit zählen, die 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 durch AMD, Upstream-vLLM, eine Modelländerung, ein Cloud-Image oder die Anwendung verursacht wird, aufgewendet wird.

Diese Aufgaben sind keine Mängel der Strategie. Sie sind der Preis für die Einführung eines zweiten ernsthaften Beschleuniger-Stacks.

Die Frage des Käufers ist, ob dieser Preis niedriger ist als der Nutzen. Wenn AMDs Speicherkapazität einem Team erlaubt, ein größeres Modell pro Knoten zu bedienen, Replicas zu konsolidieren, die knotenübergreifende Kommunikation zu reduzieren oder einen teureren Beschleuniger zu vermeiden, könnte die Antwort ja sein. Wenn die Workload innerhalb dokumentierter Container bleibt und gängige Modellfamilien verwendet, wird die Antwort einfacher. Wenn die Workload von benutzerdefinierten CUDA-Erweiterungen, ungewöhnlichen Kerneln, strengen Latenzenden oder einer Provider-Region abhängt, in der AMD-Kapazität knapp ist, wird die Antwort schwieriger.

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

Öffentliche Benchmark-Nachweise sind jetzt stark genug, dass sie nicht abgetan werden können. MLCommons sagte, dieMLPerf Training v6.0-Runde umfasste 24 einreichende Organisationen, darunter AMD, Azure, Dell, HPE, NVIDIA, Oracle, Supermicro und andere. Diese Breite ist wichtig. MLPerf ist keine private Folie mit unbenannten Bedingungen. Es ist regelgeleiteter Benchmark-Nachweis, und Trainings-Benchmarks messen vollständige Systeme, die Modelle zu einem Zielqualitätsmetrik bewegen.

AMDs eigeneMLPerf Training v6.0-Diskussionist spezifischer. AMD sagt, dass seine MI355X-Plattform eine generationsübergreifende Verbesserung um das 3,5-fache beim Llama 2-70B-Feintuning von seiner ersten MI300X-Einreichung bis zur MI355X-Einreichung zeigte und dass MI355X innerhalb von 5 % von NVIDIA B200 beim Llama 2-70B-Feintuning und innerhalb von 6 % beim Llama 3.1-8B-Pretraining in den zitierten MLPerf Training 6.0-Vergleichen lag. AMD sagt auch, dass die Runde seine erste Multi-Node-Training-Einreichung 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 Nachweis hinzu. Oracle berichtete von einer verifizierten 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 es ist keine pauschale Aussage über jeden Kunden. Aber es ist bedeutsam, weil es mehr als single-GPU-Arithmetik testet. Es betrifft verteiltes Training, Cluster-Netzwerk, ROCm-Kernel, Datenplatzierung, Knotenkoordination und wiederholte Läufe.

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

Training kann Datenbereinigung, Checkpoint-Richtlinien, Experimentverfolgung, Spot-/unterbrechbare Kapazität oder Compliance-Kontrollen umfassen. Nichts davon macht MLPerf ungültig. Es sagt nur, dass der Benchmark eine Quelle von Nachweisen ist, nicht die vollständige Beschaffungsantwort.

Die richtige Verwendung 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 eine Reihe von Fragen, die sie kopieren können: Welcher genaue Software-Stack hat das Ergebnis produziert? Welche Modellfamilie wurde getestet? Wie viele Läufe haben die Zielqualität erreicht? Was war der Maßstab? Was ist während der Vorbereitung kaputtgegangen? Welche Partnersysteme haben ähnliche Ergebnisse reproduziert?

Was passiert, wenn sich das Modell ändert? Welche Health Checks wurden vor der Workload durchgeführt?

Mit anderen Worten, MLPerf sollte Käufer rigoroser machen, nicht entspannter. Es beweist, dass AMD zu ernsthaften Evaluierungen gehört. Es beweist nicht, dass ein Käufer die Evaluierung überspringen kann.

Cloud-Zugang verwandelt die Hardware-Frage in 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 waren und dass Microsoft MI300X- und ROCm-betriebene VMs für GPT-Workloads verwendete. Microsoft veröffentlicht separat einenAzure ND MI300X v5 Linux-Treiberleitfaden, der die empfohlene Marketplace-Image-Installation und Ubuntu-Installations-/Upgrade-Szenarien abdeckt. Oracles Dokumente listenBM.GPU.MI300X.8mit acht MI300X 192 GB GPUs und BM.GPU.MI355X.8 mit acht MI355X 288 GB GPUs. AMDs OCI-Ankündigung sagte, dass OCI Supercluster mit MI300X bis zu 16.384 GPUs in einem einzigen Cluster unterstützt.

Das sind erhebliche Verfügbarkeitssignale. Sie zeigen auch, warum AMD nicht bewertet werden sollte, als ob der Kunde einen losen Chip kaufen würde. Der Cloud-Anbieter liefert die Instanzform, das Basis-Image, den Kontingentprozess, das Netzwerk, den Speicher, den Support-Workflow, die regionale Verfügbarkeit, den Wartungsplan und die Incident-Reaktion. AMD liefert den Beschleuniger und den ROCm-Stack, die innerhalb dieser Umgebung arbeiten müssen. Der Kunde liefert die Workload, Daten, Modellzugang, Bereitstellung, Tests und Akzeptanzkriterien.

Für einen Käufer entfernt der Cloud-Weg einige Kapital- und Integrationslast. Er kann Serverbeschaffung, Rechenzentrumsstrom- und Kühlungsfragen und lange Hardware-Vorlaufzeiten vermeiden. Er kann einen kurzen Proof-of-Concept-Pfad bieten. Er kann auch neue Unsicherheiten schaffen. Dass eine Cloud-Form dokumentiert ist, bedeutet nicht, dass jede Region sofort Kapazität für einen neuen Kunden hat. Das Kontingent kann 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 Schlagzeile der Beschleunigererzählung abweichen. Die Eskalation des Supports kann über den Cloud-Anbieter zu AMD führen.

Die akzeptierte Workload sollte daher Kapazitätsnachweise enthalten. Kann das Team die Form in der Region erhalten, in der Daten- und Compliance-Anforderungen es erlauben? Kann es genügend Kapazität für die Produktion reservieren oder nur für Ausbruchstests? Kann es den Durchlauf in einer anderen Region oder bei einem anderen Anbieter reproduzieren, falls das Kontingent verschwindet? Benötigt die Workload Bare Metal, VM-Isolierung, Kubernetes, Slurm oder eine verwaltete Modellserving-Plattform? Was ist der Rückfall, wenn AMD-Kapazität während eines Vorfalls oder Startfensters 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 Widerstandsfähigkeit nur, wenn er tatsächlich zugänglich ist, wenn er benötigt wird. Wenn der AMD-Pfad nur als kleiner Evaluierungscluster existiert, während der Produktionspfad vollständig auf CUDA bleibt, ist es eine Lernübung. Wenn der AMD-Pfad einen benannten Teil der Inferenz, des Feintunings, der Evaluierung oder der Batch-Verarbeitung unter einem definierten Ausfallplan ausführen kann, ist es strategische Hebelwirkung.

Der Unterschied ist nicht der Chip; es sind Kapazität, betriebliche Bereitschaft und Routing-Richtlinie.

Portierungskosten sind der Teil des Preises, der nicht auf dem Angebot erscheint

AMDs direkteste Herausforderung für etablierte Beschleunigersoftware ist HIP und ROCm-Portabilität. AMDsHIP-Portierungsleitfadenbeschreibt HIP als eine C++-Runtime-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 Tools wie HIPIFY plus 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.

Der praktische Rat des Leitfadens ist jedoch auch die Warnung. Portierung ist Arbeit. Sie beginnt mit einer funktionierenden CUDA-Codebasis, konvertiert dann, kompiliert, testet und optimiert in Stufen. Die einfachen Fälle können weitgehend mechanisch sein. Die schwierigen Fälle betreffen CUDA-spezifische Bibliotheken, benutzerdefinierte Kernel, Annahmen über Speicherverhalten, Build-Systeme, Inline-Assembly, Profiling-Tools, Kollektive, 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 AMDs Wirtschaftlichkeit falsch gelesen werden. Ein Beschaffungsteam kann einen niedrigeren Beschleunigerpreis, mehr Speicher pro Gerät oder bessere Verfügbarkeit sehen und annehmen, der Geschäftsfall sei offensichtlich. Das Plattformteam stellt dann fest, dass die relevante Anwendung nicht nur PyTorch aus einem sauberen Container ist. Sie enthält eine benutzerdefinierte Erweiterung, einen Serving-Wrapper, eine CUDA-only-Abhängigkeit, eine Überwachungskomponente, ein Scheduler-Plugin und Bereitstellungsskripte, die um NVIDIA-Annahmen herum geschrieben wurden. Jede Anpassung kann rational sein.

Zusammen werden sie zum Migrationsposten, der im Hardwarevergleich fehlte.

Das Gegenteil kann auch passieren. Ein Team kann das Portierungsproblem überbewerten, weil es sich an ältere ROCm-Lücken oder Consumer-GPU-Schmerzen erinnert. Wenn die Workload Mainstream-Llama- oder Qwen-Inferenz durch einen dokumentierten ROCm-vLLM-Container oder ein unterstütztes Trainingsrezept auf Instinct-Hardware ist, kann die zusätzliche Arbeit bescheiden sein. Wenn die Anwendung Standard-Framework-Pfade verwendet und das Team ein bekannt gutes Image fixieren 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 bieten.

Der richtige Vergleich ist nicht „AMD gegen NVIDIA“ im Abstrakten. Es sind Kosten pro akzeptiertem Durchlauf für eine benannte Aufgabe. Vergleichen Sie den AMD-Pfad mit dem Verbleib auf CUDA, der Nutzung eines verwalteten Cloud-/Modellanbieters, der Reduzierung der Modellgröße, der Nutzung eines Open-Source-Modells auf bestehender Kapazität, dem Kauf eines etablierten SaaS-Workflows, dem Aufbau einer eigenen Orchestrierung oder der Reduzierung der Aufgabe.

Berücksichtigen Sie Ingenieurszeit, Supportverträge, Cloud-Verpflichtungen, fehlgeschlagene Läufe, Testdatenvorbereitung, Beobachtbarkeit, Modellüberprüfung, Rollback, Incident-Abdeckung und Ausstiegskosten.

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 Beschleunigerersparnis. Die einzige schlechte Evaluierung ist die, die Hardware-Dollar zählt und Ingenieurwochen ignoriert.

Die Zuverlässigkeitsarbeit beginnt vor dem Modell

Akzeptierte Beschleunigerworkloads benötigen Preflight-Checks. AMDsSystem Health Benchmark-Leitfadensagt, Teams sollten validieren, dass AMD-Hardware korrekt konfiguriert und optimal arbeitet, bevor KI-Workloads ausgeführt werden, und verweist auf ROCm Validation Suite, RCCL-Tests, BabelStream und TransferBench. Das ist kein Papierkram. Es ist, wie ein Team vermeidet, ein Modellproblem mit einem defekten Knoten, falsch konfiguriertem IOMMU, schwacher Speicherbandbreite, schlechtem Interconnect oder einem Problem mit der kollektiven Kommunikation zu verwechseln.

In der Produktion wird diese Schicht noch wichtiger, weil die Fehlermodi mehrdeutig sind. Wenn ein Trainingsjob langsamer wird, liegt die Ursache bei ROCm, einer ausgefallenen GPU, einer degradierten Verbindung, Speichervarianz, einem Datenlader-Engpass, thermischem Verhalten, Cloud-Noisy-Neighbor-Effekten, einer Modelländerung oder einem neuen Framework-Kernel? Wenn die Inferenzlatenz ansteigt, liegt die Ursache beim Batching, KV-Cache-Druck, Anfrageform, Tokenisierung, Speicherfragmentierung, Scheduler-Platzierung, Taktverhalten, Protokollierung, Netzwerk oder einer Regression im Serving-Stack?

Ohne Health- und Baseline-Tests debattiert das Team Meinungen.

Hier muss AMD nicht nur mit Silizium konkurrieren, sondern auch mit betrieblichem Muskelgedächtnis. Viele KI-Teams haben jahrelange CUDA-Debugging-Gewohnheiten. Sie wissen, welche NVIDIA-Tools sie verwenden sollen, welche Fehler häufig sind, welchen Forenbeiträgen sie vertrauen können, welche Container-Tags sicher sind und welche Leistungszähler wichtig sind. Die ROCm-Einführung erfordert gleichwertige Gewohnheiten. AMD kann Tools und Dokumente veröffentlichen, aber Käufer brauchen immer noch Leute, die wissen, wie man sie unter Druck einsetzt. Ein Durchlauf ist nicht akzeptiert, nur 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-Health: RVS, Speicherbandbreite, GPU-Sichtbarkeit und thermische/Leistungsintegrität. Zweitens, Kommunikation: RCCL-Kollektivkorrektheit und Leistung für die Knoten- oder Clustergröße. Drittens, Framework: PyTorch, vLLM, Megatron-LM oder der gewählte Stack unter fixierten Versionen. Viertens, Workload: das tatsächliche Modell und Datenmuster, nicht nur eine Anbieterprobe.

Fünftens, Wiederherstellung: Neustart vom Checkpoint, Rückkehr zu einem bekannten guten Image, Drain eines Knotens, Reproduktion einer fehlgeschlagenen Anfrage und Dokumentation, wer handelt, wenn der Fehler auftritt.

Das mag teuer klingen. Das ist es. Aber es ist auch der einzig faire Weg, Plattformen zu vergleichen. Wenn der etablierte CUDA-Pfad jahrelange versteckte betriebliche Investitionen hat, sollte AMD nicht gebeten werden, nur den marginalen Hardwarepreis zu schlagen. Es sollte mit den Gesamtkosten für die Gesundheit des etablierten Pfades verglichen werden. 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 Durchlauf zum Laufen bringen kann, ist interessant. Eine Plattform, die die gleiche Klasse von Durchläufen nach Updates, Fehlern und Personalwechseln akzeptiert hält, ist wertvoll.

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

AMD versucht, im Stack nach oben zu rücken. DieAMD Enterprise AI Suitepositioniert sich als Verbindung von Open-Source-KI-Frameworks und generativen KI-Modellen mit einer enterprise-tauglichen Kubernetes-Plattform. AMD Inference Microservices und Referenz-Stacks sollen den Abstand zwischen Bare Metal und einem laufenden KI-Dienst verringern. Das ist strategisch notwendig. Während KI-Infrastruktur von Elite-Modelllaboren zu normalen Unternehmen wandert, wollen Käufer weniger Rohkomponenten und mehr einsetzbare Systeme.

Die Bewegung ist auch eine Reaktion auf das Wettbewerbsmuster, das von etablierten Beschleuniger-Ökosystemen gesetzt wurde. Hardware-Anbieter verkaufen zunehmend Software, Referenz-Container, Modellserver, Orchestrierung, Beobachtbarkeits-Hooks, Microservices und Enterprise-Support. Der Käufer will keine Kiste theoretischer FLOPS. Er will einen gesteuerten Workflow: dieses Modell bereitstellen, diese Anfragen routen, diese Richtlinien durchsetzen, diese Protokolle sammeln, diesen Container aktualisieren, sicher zurückrollen, dieses Team belasten und nachweisen, dass der Dienst innerhalb der Grenzen geblieben ist.

AMDs Chance ist, 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 auf dem betrieblichen Nenner konkurrieren und nicht auf dem Rohkomponentenvergleich. Ein Plattformteam könnte sich nicht dafür interessieren, welcher Kernel eine Beschleunigung geliefert hat, solange der Dienst mit weniger Reibung als erwartet bereitgestellt, beobachtet, aktualisiert und wiederhergestellt werden kann.

Das Risiko ist, dass eine höhere Suite eine neue Schicht zur Validierung schafft. Ein Kubernetes-Referenz-Stack hat immer noch Cluster-Lebenszyklus, Image-Herkunft, Netzwerkrichtlinie, Speicher, Geheimnisse, Modellregister, Autoscaling, Knoten-Drains, Upgrade-Rhythmus und Incident-Response. Inference Microservices benötigen immer noch modellspezifische Akzeptanz, Eingabevalidierung, Ausgabeüberwachung, Latenz-SLOs, Sicherheitsüberprüfung und Kostenverteilung. Eine Referenzblaupause kann den Weg verkürzen; sie kann ein Modell nicht ohne Kundenrichtlinie und -daten in eine gesteuerte Geschäftsaktion verwandeln.

Diese Unterscheidung ist wichtig für regulierte oder folgenreiche Anwendungen. Wenn ein AMD-betriebenes Modell Supportfragen beantwortet, klinische Notizen weiterleitet, rechtliches Material zusammenfasst, eine Sicherheitsaktion auslöst oder Code generiert, ist die akzeptierte Ausgabe nicht der Token. Es ist die überprüfte Aktion innerhalb eines Workflows. Der Infrastruktur-Stack muss Zuverlässigkeit bieten, aber der Kunde benötigt dennoch menschliche Überprüfungsregeln, Audit, Ausnahmebehandlung und Rückfall. AMD kann den Beschleunigerdurchlauf billiger oder portabler machen. Es besitzt nicht die Entscheidungsqualität des Kunden.

Die beste Rolle für AMDs Enterprise-Schicht ist daher pragmatisch: Zeitverschwendung bei der Installation reduziert, damit Teams mehr Zeit für die Workload-Akzeptanz aufwenden können. Wenn es lediglich die Komplexität von der ROCm-Installation in eine andere Verwaltungsebene verschiebt, werden Käufer es abwerten. Wenn es gängige Inferenz- und Trainingsmuster in wiederholbare, unterstützbare Bereitstellungen verwandelt, greift es direkt AMDs historische Schwäche an: die Angst, dass Nicht-CUDA-Pfade zu viel Ingenieursaufmerksamkeit kosten.

Der wirtschaftliche Fall muss den Rückfall zählen

Rückfall ist kein Pessimismus des Scheiterns. 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. Kehrt es zu CUDA zurück? Führt es ein kleineres Modell aus? Wechselt es zu einer verwalteten API? Hält es einen CPU-Pfad für Batch-Arbeit bereit? Verwendet es AMD für Evaluierung und NVIDIA für latenzkritisches Serving? Teilt es den Datenverkehr nach Modellfamilie auf? Verzögert es die Produktion, bis ein fehlender Kernel eintrifft?

Jeder Rückfall hat Kosten. Die Wartung von zwei Beschleuniger-Stacks kann die Verhandlungsmacht und Widerstandsfähigkeit verbessern, aber sie kann Testmatrizen verdoppeln. Das Halten von CUDA als Sicherheitspfad reduziert das Migrationsrisiko, könnte aber die etablierte Abhängigkeit bewahren, die AMD reduzieren sollte. Die Verwendung von AMD nur für Überlauf kann dazu führen, dass Ingenieure damit nicht vertraut sind, wenn Produktionsdruck auftritt. Die Verwendung von AMD für alle neuen Workloads kann das Risiko konzentrieren, wenn das Team nicht genügend ROCm-Expertise aufgebaut hat.

Der Kauf von Cloud-Kapazität für beide Pfade kann die Kontinuität verbessern und Rabatte schwächen.

Aus diesem Grund sollte die kommerzielle Frage in akzeptierten-Ausgabe-Einheiten formuliert werden. Für Inferenz zählen Sie Kosten pro Million akzeptierter Anfragen, Kosten pro erfolgreicher Tool-Aktion, Kosten pro generierter Codeänderung, die die Überprüfung besteht, oder Kosten pro gesteuerter Antwort, die unter Latenz- und Sicherheitsbeschränkungen geliefert wird. Für Training zählen Sie Kosten pro akzeptiertem Feintuning, Kosten pro Trainingslauf mit Zielqualität, Kosten pro Evaluierungsergebnis oder Kosten pro Umschulungszyklus.

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

AMDs Speicherkapazität kann in dieser Gleichung eine große Rolle spielen. Mehr HBM pro Beschleuniger kann die Notwendigkeit verringern, bestimmte Modelle zu shardieren, größere Kontexte unterstützen, Batching-Reserven verbessern oder die Bereitstellung vereinfachen. Aber Speicher allein ist nicht genug. Wenn ein Modell passt, aber sein Attention-Backend schwach ist, können die akzeptierten Kosten dennoch schlecht sein. Wenn der Durchsatz gut ist, aber Rollback unklar ist, kann ein regulierter Käufer die Bereitstellung ablehnen.

Wenn Cloud-Kapazität billig, aber in der erforderlichen Region nicht verfügbar ist, sind die theoretischen Kosten irrelevant.

Die realistischen Alternativen sind vielfältig. Bei NVIDIA zu bleiben, kann teuer, aber betrieblich vertraut sein. Ein verwalteter Modelldienst eines Cloud-Anbieters kann die Beschleunigerverwaltung vermeiden, aber die Kontrolle und Portabilität verringern. Ein etabliertes SaaS-Produkt kann den Geschäftsworkflow liefern, ohne GPU-Details offenzulegen, auf Kosten der Anpassung. Open Source auf vorhandener Hardware kann ausreichen, wenn die Aufgabe Latenz oder kleinere Modelle toleriert. Die Reduzierung der Aufgabe kann rational sein, wenn die Überprüfungslast den Automatisierungsgewinn übersteigt.

AMD gewinnt nur, wenn sein Pfad diese Alternativen schlägt, nachdem die versteckte Arbeit einbezogen wurde. Das ist ein strengerer Standard als „billiger als der etablierte Beschleuniger“. Es ist auch ein besserer Standard für AMD, weil es identifiziert, wo das Unternehmen Verbesserungen vornehmen kann: Support-Matrizen, Container, Modellabdeckung, Debugging-Tools, Cloud-Verfügbarkeit, Enterprise-Referenz-Stacks, Partner-Reproduzierbarkeit und workloadspezifische Nachweise.

Was als nächstes zu beobachten ist

Der erste Beobachtungspunkt ist Kompatibilitätsdrift. ROCm-Releases verbessern sich, aber jede Verbesserung schafft eine neue Versionsentscheidung. Käufer sollten verfolgen, welches ROCm-Release, welche Framework-Version, welcher Container-Tag und welche GPU-Firmware für jede Workload akzeptiert sind. Sie sollten aufzeichnen, warum ein Update übernommen wurde, welche Regressionstests bestanden wurden und wie zurückgerollt wird.

Der zweite ist Kernel- und Modellabdeckung. Öffentliche Dokumente listen gängige Modellfamilien auf, und AMD hat starke Benchmark-Nachweise, aber die KI-Modellmischung ändert sich schnell. DeepSeek-artige Mixture-of-Experts-Modelle, Long-Context-Workloads, multimodale Modelle, Videogenerierung, werkzeugnutzende Modelldienste und spezialisierte Retrieval-Systeme können verschiedene Kernel und Speicherpfade beanspruchen. Ein Käufer sollte fragen, ob seine genaue Modellarchitektur unterstützt und optimiert ist, nicht ob ein breiter Familienname in einem Blog erscheint.

Der dritte ist Cloud-Kapazität. Azure- und OCI-Oberflächen sind real, aber Kontingent, Region, Image-Wartung und Support-Routing sind betriebliche Fakten. AMDs Wettbewerbswert steigt, wenn Kunden Kapazität dort erhalten, wo sie sie benötigen, und wenn Anbieter Images aktuell halten, ohne bekannte gute Workloads zu beschädigen.

Der vierte ist Partner-Reproduzierbarkeit. AMDs MLPerf-Diskussion von Ökosystempartnern 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 wie Spezialarbeit an. Das Gegenteil ist auch wahr: Wenn Ergebnisse von einer sorgfältig abgestimmten Konfiguration abhängen, werden gewöhnliche Käufer Expertenabhängigkeit einpreisen.

Der fünfte ist menschliche Aufsicht. Selbst wenn AMD eine Workload schneller oder billiger macht, benötigen KI-Infrastrukturteams immer noch Überprüfung, Ausnahmebehandlung, Kostenverteilung 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 sind Rückfallkosten. Wenn ein Team keine klare Antwort darauf hat, was passiert, wenn ein ROCm-Pfad ausfällt, hat es die Evaluierung nicht abgeschlossen. Ein Rückfallplan sollte vor der Produktion explizit sein, nicht während eines Kundenincidents improvisiert.

Die Schlussfolgerung ist nicht, dass AMD unvorbereitet ist. Es ist, dass AMD bereit genug ist, um ernsthaft und betrieblich evaluiert zu werden. Das ist eine höhere Hürde als ein Schlagzeilen-Benchmark und ein besseres Zeichen für das Unternehmen. Instinct und ROCm müssen nicht mehr, dass der Markt an eine theoretische zweite Quelle glaubt. Sie müssen, dass Kunden Workload für Workload beweisen, dass die zweite Quelle akzeptiert, gewartet und bezahlt werden kann.

Für AMD ist die Produktionsaufgabe wiederholtes Vertrauen. Das Unternehmen hat Beschleunigerhardware, einen sichtbaren Software-Stack, öffentliche Benchmark-Nachweise 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 hat, weiß, was zu tun ist, wenn es fehlschlägt, und kann zeigen, dass die Gesamtkosten immer noch die Alternative schlagen.