AMD Instinct MI350P Server-Upgrade: Kaufen oder mieten?

Ein AMD Instinct MI350P kann laut offizieller AMD-Produktseite mit bis zu 600 W betrieben und auf 450 W konfiguriert werden. Das führt zur wichtigsten Entscheidung: Wenn Ihr Server, Ihre Stromversorgung, Ihre Kühlung und Ihr ROCm-Betrieb bereits belastbar geprüft sind, kann sich ein Upgrade lohnen. Bei schwankender Last, unklarer Softwaremigration oder fehlenden Hardware-Verantwortlichen sollten Sie zunächst AI-Rechenzeit mieten.

Symptom: Die Karte passt mechanisch in den Server, aber Strom, Firmware, Luftstrom oder Software sind nicht abgenommen.
Schnellste Lösung: Erst eine kurze GPU-Testphase mit repräsentativen Modellen durchführen; erst danach kaufen oder dauerhaft auf einen Hybridbetrieb wechseln.

Diese Analyse richtet sich an Unternehmens-IT-Teams, die vorhandene AI-Server erweitern möchten, an Start-ups mit wechselnder Inferenzlast sowie an Plattformverantwortliche, die Investitions- und Migrationsrisiken begrenzen müssen.

Die Karte ist PCIe-kompatibel, aber kein „Einstecken und loslegen“

Die Bezeichnung PCIe GPU beschreibt zunächst den Steckplatz und die elektrische Anbindung. Sie beweist nicht, dass ein bestehender Server die Karte produktionsfähig betreiben kann. AMD nennt für die MI350P unter anderem ein PCIe-5.0-x16-Interface, eine passive Kühlung, eine Bauform mit voller Bauhöhe und zwei Steckplätzen sowie eine maximale Board Power von 600 W. Diese Eigenschaften müssen zum konkreten Servermodell passen und dürfen nicht aus Angaben zu anderen Karten der MI350-Familie abgeleitet werden. Die MI350P-Produktbroschüre von AMD ist deshalb nur der erste Prüfpunkt, nicht die vollständige Kompatibilitätsfreigabe.

Mindestens fünf technische Grenzen werden in der Praxis häufig unterschätzt:

1. Stromversorgung: Ein vorhandenes Netzteil kann zwar die rechnerische Gesamtleistung des Servers abdecken, aber die benötigten 12V-2x6-Anschlüsse oder die Lastverteilung auf den Stromschienen nicht bereitstellen.
2. Passive Kühlung: Eine passive Karte ist auf den Luftstrom des zertifizierten Servergehäuses angewiesen. Ein normaler Tower oder ein Server mit ungeeigneter Lüftersteuerung kann die Karte nicht zuverlässig kühlen.
3. Steckplatz und Abstand: Zwei Steckplätze Breite, volle Bauhöhe und die Kartenlänge von 267 mm müssen mit Rückwand, benachbarten Karten, Laufwerksträgern und Kabelwegen abgeglichen werden. Diese Werte stammen aus der AMD-Produktdokumentation. (amd.com)
4. Firmware und BIOS: PCIe-Bifurcation, Above-4G-Decoding, Resizable BAR, IOMMU, NUMA-Zuordnung und aktuelle Server-Firmware können für Stabilität und Gerätesichtbarkeit relevant sein.
5. Betriebsverantwortung: Nach dem Einbau müssen GPU-Treiber, ROCm-Version, Kernel, Container-Images, Monitoring, Firmware und Ersatzteilprozesse zusammenpassen.

Ein Server ist daher erst dann ein Upgrade-Kandidat, wenn Herstellerfreigabe, Strompfad, Kühlprofil, Firmware und Softwarestack gemeinsam bestätigt wurden. Eine bloße mechanische Passform reicht nicht.

Die drei Wege im direkten Vergleich

Die Entscheidung lässt sich nicht allein über den Kaufpreis der GPU treffen. Entscheidend ist, wie lange die Last besteht, wie sicher die ROCm-Migration ist und wer Fehler außerhalb der Anwendung behebt.

Die Bewertung in der folgenden Tabelle ist ein redaktionelles Entscheidungsmodell und kein Benchmark. Sie hilft Ihnen, die relevanten Bedingungen zu gewichten.

Die Punkte sind als Entscheidungshilfe gedacht: Fünf von fünf bedeutet nicht, dass eine Variante immer billiger ist, sondern dass sie unter den beschriebenen Bedingungen das geringere Fehlentscheidungsrisiko bietet.

Für Teams mit vorhandenen Servern zählt die Abnahme, nicht die Produktwerbung

Wenn Sie bereits AI-Server im Rack betreiben, beginnen Sie mit einer technischen Bestandsaufnahme. Prüfen Sie das exakte Servermodell, die vom Hersteller freigegebenen GPU-Konfigurationen, die Zahl der nutzbaren PCIe-Steckplätze, die Netzteilredundanz und die Kühlluftführung. Die AMD-Produktseite nennt zwar eine mögliche Konfiguration von bis zu acht Karten pro Server, daraus folgt jedoch nicht, dass Ihr bestehendes System diese Bestückung unterstützt. (amd.com)

Zusätzlich müssen Sie die Wartungsrealität bewerten:

• Gibt es ein geplantes Wartungsfenster für Einbau, BIOS-Update und Treiberwechsel?
• Wer übernimmt die Abnahme, wenn die GPU zwar erkannt wird, aber unter Dauerlast Fehler produziert?
• Bleibt die Herstellergarantie des Servers bei einer nicht zertifizierten GPU-Bestückung erhalten?
• Sind Ersatzkarte, Kabel, Netzteil und Lüfter kurzfristig verfügbar?
• Können Sie den Server bei einem Fehler ohne laufende Produktionslast isolieren?

Für ein Unternehmen mit stabiler, täglicher Inferenzlast ist ein lokales Upgrade attraktiv, weil die Kapazität nicht von einer externen Verfügbarkeit abhängt. Der Vorteil entsteht aber erst, wenn der Server als Gesamtsystem abgenommen wurde. Die GPU allein ist keine betriebsbereite Plattform.

Kann ein vorhandener AI-Server die MI350P einfach aufnehmen?
Nur wenn der konkrete Serverhersteller diese Karte oder eine technisch gleichwertige Konfiguration freigibt und Sie Stromversorgung, Kühlung, Firmware, PCIe-Topologie und Betriebssystem gemeinsam validieren. Prüfen Sie deshalb die AI-Server-Kompatibilität vor dem Hardwarekauf, statt sich auf die PCIe-Bezeichnung zu verlassen.

Für ROCm-Einsteiger ist ein kurzer Testlauf meist der bessere erste Schritt

Die MI350P wird in der aktuellen ROCm-Dokumentation als gfx950 geführt. Die ROCm-Kompatibilitätsmatrix und die aktuellen ROCm-Versionshinweise zeigen zugleich, dass GPU-Unterstützung immer mit Betriebssystem, Kernel, Treiberversion und konkreter Softwareversion betrachtet werden muss. (rocm.docs.amd.com)

Die entscheidende Frage lautet nicht, ob ein offizielles Beispiel läuft. Entscheidend ist, ob Ihre Anwendung unter realistischen Bedingungen korrekt und reproduzierbar läuft. Prüfen Sie insbesondere:

• CUDA-spezifische Operatoren und eigene Erweiterungen,
• HIP- oder ROCm-Ersatzpfade,
• Container-Basisimages und Treiberbindung,
• PyTorch-, JAX-, Triton- oder SGLang-Versionen,
• Quantisierung, Batch-Größe und Kontextlänge,
• Metriken für GPU-Auslastung, HBM-Nutzung, Latenz und Fehlerraten.

Sollten Sie beim ersten ROCm-Einsatz sofort eine Karte kaufen?
In der Regel nicht. Wenn Ihre Anwendung bisher auf einem anderen GPU-Softwarestack basiert, ist eine kurze Mietphase sinnvoller, weil Sie die tatsächliche Migrationsarbeit an Ihren eigenen Modellen messen. Erst wenn Korrektheit, Latenz, Wiederanlauf und Monitoring abgenommen sind, wird der Kauf zu einer belastbaren Entscheidung.

Ein einzelner erfolgreicher Start sagt wenig über die Produktionsreife aus. Ein Modell kann mit einer kleinen Testanfrage funktionieren, aber bei höherer Parallelität, längeren Kontexten oder einem anderen Quantisierungsformat an einem fehlenden Kernel scheitern.

Hinweis: Übertragen Sie weder Leistungswerte noch Kompatibilitätsannahmen von MI350X oder MI355X auf MI350P. AMD führt die Modelle separat; die MI350P besitzt eigene Angaben zu Speicher, Leistungsgrenze, Partitionierung und Servereinsatz.

Schwankende Produktlast spricht für elastische Kapazität

AI-Produktteams haben häufig eine andere Kostenstruktur als klassische Rechenzentrumsabteilungen. Ihre Last entsteht nicht nur durch den Regelbetrieb, sondern auch durch Modelltests, neue Versionen, zeitlich begrenzte Kampagnen, Lasttests und kurzfristige Kundenprojekte.

Bei stark schwankender Nutzung entstehen beim Kauf mehrere versteckte Kosten:

• GPU-Kapazität bleibt außerhalb der Spitzenzeiten ungenutzt.
• Ein Server-Upgrade bindet Kapital, bevor die Nachfrage bestätigt ist.
• Neue Modelle können andere Speicher- oder Softwareanforderungen mitbringen.
• Test- und Produktionsumgebung konkurrieren um dieselbe GPU.
• Firmware- und Treiberänderungen benötigen Wartungsfenster.

Eignet sich die MI350P eher für kontinuierliche Inferenz oder für ein befristetes Projekt?
Für kontinuierliche Inferenz ist sie dann ein plausibler Kaufkandidat, wenn Ihre Last aus echten Betriebsdaten abgeleitet wurde und der Server über längere Zeiträume sinnvoll ausgelastet wird. Für befristete Projekte, Modellvergleiche und unsichere Wachstumsprognosen ist AI-Rechenzeit zunächst flexibler. Sie bezahlen dann für die benötigte Kapazität, ohne eine langfristige Hardwareentscheidung vorwegzunehmen.

Die operative Kennzahl ist nicht die theoretische Spitzenleistung, sondern die Zahl der Stunden, in denen Ihre produktive Anwendung die bereitgestellte Kapazität tatsächlich benötigt. Diese Auswertung sollten Sie aus Monitoring- und Auftragsdaten ableiten, nicht aus einer Umsatzprognose allein.

Datenschutz und externe Rechenzeit müssen getrennt bewertet werden

Ein Unternehmen kann verpflichtet sein, bestimmte Daten in einer festgelegten Umgebung zu verarbeiten. Das bedeutet nicht automatisch, dass die Hardware selbst im Eigentum des Unternehmens stehen muss. Entscheidend sind die konkreten Anforderungen an Datenstandort, Zugriff, Verschlüsselung, Protokollierung, Mandantentrennung, Löschung und administrative Rechte.

Vor einer Mietentscheidung sollten Sie deshalb einen technischen und rechtlichen Abnahmekatalog erstellen:

1. Welche Daten dürfen die eigene Umgebung verlassen?
2. Werden Eingaben, Zwischenergebnisse und Modellartefakte dauerhaft gespeichert?
3. Wer kann auf Hostsystem, Images, Logs und Sicherungen zugreifen?
4. Wie werden virtuelle Maschinen oder Container voneinander getrennt?
5. Können Sie die Löschung nach Projektende nachweisen?
6. Welche Regelungen gelten für Auftragsverarbeitung und DSGVO?

Verlinken Sie für die organisatorische Vorbereitung auch die Datenschutzinformationen von SSHMac. Für besonders sensible Anwendungen ist ein eigener Abnahmetest mit anonymisierten oder synthetischen Daten sinnvoll, bevor produktive Inhalte verarbeitet werden.

Ein lokales Upgrade hat bei der Datenhoheit einen klaren Vorteil: Netzwerkpfade und administrative Zuständigkeiten bleiben in Ihrer Hand. Es löst jedoch nicht automatisch alle Sicherheitsprobleme. Ein schlecht gepflegter Host, offene Fernzugänge oder fehlende Protokollierung können auch im eigenen Rechenzentrum ein Risiko darstellen.

Kleine Teams müssen den Betrieb als Teil der Infrastrukturkosten rechnen

Für ein kleines Team ohne eigene Hardwarestelle ist der Kauf einer GPU nicht mit dem Abschluss der Beschaffung erledigt. Benötigt werden Zuständigkeiten für Treiber, Firmware, BIOS, Kernel, Monitoring, Netzteile, Lüfter, Fehleranalyse, Ersatzteile, Kapazitätsplanung und Sicherheitsupdates.

Welche Fähigkeiten braucht ein Unternehmen für selbst betriebene AMD GPUs?
Mindestens eine verantwortliche Person muss den gesamten Pfad von der Host-Hardware bis zur Anwendung beherrschen. Dazu gehören Linux-Administration, ROCm- und Containerverwaltung, GPU-Monitoring, Logauswertung, Netzwerk- und Storage-Fehleranalyse sowie ein Verfahren für Wartung und Rollback. Ohne diese Zuständigkeit kann eine lokal gekaufte GPU bei einem Softwareupdate länger unbrauchbar bleiben als eine gemietete Umgebung.

Für kleine Teams ist ein Hybridmodell oft ein sinnvoller Mittelweg: Eine geprüfte lokale Kapazität bedient stabile oder besonders geschützte Prozesse, während Mietkapazität für Migration, Stresstests, neue Modelle und kurzfristige Spitzen genutzt wird. Das erhöht zunächst die Komplexität, verhindert aber, dass jede neue Anforderung sofort eine neue Hardwarebeschaffung auslöst.

Die fünfstufige Abnahme vor Kauf oder Dauerbetrieb

Arbeiten Sie die folgenden Punkte in dieser Reihenfolge ab. Wenn ein kritischer Punkt offen bleibt, verschieben Sie den Kauf und testen zunächst eine temporäre Umgebung.

• [ ] Server identifizieren: Exaktes Modell, BIOS-Version, CPU-Sockel, PCIe-Topologie, Netzteile, freie Steckplätze und Garantiebedingungen dokumentieren.
• [ ] Herstellerfreigabe prüfen: Kompatibilitätsliste des Serverherstellers und die konkrete MI350P-Bestückung schriftlich abgleichen; allgemeine PCIe-Kompatibilität nicht als Freigabe akzeptieren.
• [ ] Strom und Kühlung abnehmen: 12V-2x6-Anschluss, Lastverteilung, redundante Netzteile, Luftstrom, Lüfterprofil, Kartenabstand und Rackbedingungen unter Dauerlast prüfen.
• [ ] ROCm-Testumgebung erstellen: Festgelegte Linux-Version, Kernel, ROCm-Version, Container-Image und Treiber dokumentieren; keine Mischung aus zufälligen Paketständen verwenden.
• [ ] Repräsentative Modelle ausführen: Mindestens ein produktionsnahes Modell mit realistischen Eingaben, Batch-Größen, Parallelitätswerten und Quantisierung testen.
• [ ] Betriebsmetriken erfassen: Fehlerrate, End-to-End-Latenz, Durchsatz, HBM-Auslastung, GPU-Temperatur, Wiederanlaufzeit und Logqualität beobachten.
• [ ] Rollback festlegen: Vor dem produktiven Wechsel einen funktionierenden Ausgangszustand, ein Wartungsfenster und eine Rückfalloption dokumentieren.
• [ ] Kaufentscheidung protokollieren: Nur kaufen, wenn Hardware, Software, Datenanforderungen und Betriebsverantwortung jeweils eindeutig bestätigt sind.

Das ist bewusst kein synthetischer Benchmark. Ein synthetischer Test kann die Hardware belasten, ohne die Fehler zu zeigen, die in Ihrem Modell, Container oder Datenpfad auftreten.

Das passende Modell hängt von fünf Bedingungen ab

Für die abschließende Entscheidung können Sie die fünf Bedingungen getrennt bewerten:

Wählen Sie das Server-Upgrade, wenn alle fünf Kaufbedingungen erfüllt sind: kompatible Hardware, abgenommene Strom- und Kühlreserven, bestandener ROCm-Test, planbare Nutzung und ein benannter Betriebsverantwortlicher.

Wählen Sie AI-Rechenzeit, wenn mindestens zwei dieser Bedingungen noch offen sind, insbesondere bei erster ROCm-Migration, schwankender Last oder fehlendem Hardwarebetrieb.

Wählen Sie den Hybridbetrieb, wenn Ihre Kernanwendung stabile Kapazität und Datenkontrolle benötigt, während Entwicklung, Lasttests oder neue Modelle noch nicht ausreichend validiert sind.

Fazit: Erst die offene Variable testen, dann Kapital binden

Ein MI350P-Upgrade beseitigt keine unklaren Serverfreigaben, keine fehlenden ROCm-Kenntnisse und keine schwankende Nachfrage. Der Kauf eines lokalen Systems ist deshalb für Teams mit konstantem Betrieb und eigener Administration sinnvoll, nicht automatisch für jedes Unternehmen mit einem freien PCIe-Steckplatz.

Wenn Sie derzeit auf wechselnde externe Kapazität, unklare Lieferbedingungen oder eine noch nicht abgenommene Softwaremigration angewiesen sind, entstehen dort andere Nachteile: laufende Mietkosten, Abhängigkeit von Verfügbarkeit, zusätzlicher Daten- und Zugriffsprüfung sowie weniger direkte Kontrolle über Wartungsfenster. Trotzdem ist ein Miettest häufig die bessere kurzfristige Entscheidung, weil er die offenen technischen Fragen sichtbar macht, bevor Sie Server, Stromversorgung und Betriebsprozesse dauerhaft festlegen.

SSHMac ist daher besonders dann eine sinnvolle Option, wenn Sie eine zeitlich begrenzte Testumgebung, einen ROCm-Abnahmelauf oder zusätzliche Kapazität für Spitzen benötigen. Senden Sie dafür am besten Ihr Servermodell, den vorgesehenen Softwarestack, den erwarteten Betriebszeitraum und das Lastprofil ein. Über die SSHMac-Übersicht für verfügbare Lösungen können Sie anschließend prüfen, ob ein kurzer Testlauf besser zu Ihrer Entscheidung passt als ein sofortiger Hardwarekauf.