ModCon 2026: MAX über mehrere Hardware-Plattformen prüfen

Stand: 18.08.2026. Zuletzt aktualisiert am 18.08.2026; geprüft wurden die offiziellen ModCon-, MAX-, Mojo- und Qualcomm-Veröffentlichungen sowie die verfügbare Container- und Versionsdokumentation.

Die offizielle MAX-Dokumentation beschreibt mit max-full bereits einen Container, der auf AMD- und NVIDIA-GPUs eingesetzt werden kann. Das ist ein belastbarer Startpunkt, aber noch kein Beweis für identische Produktionsleistung oder vollständige Hardware-Parität. Unsere Empfehlung für ModCon 2026 MAX über mehrere Hardware-Plattformen lautet deshalb: Produktivsystem nicht sofort umstellen, sondern ab dieser Woche einen begrenzten Doppelbetrieb mit klarer Rückfalloption starten. Erst wenn Zielmodell, Messwerte, Abhängigkeiten, Betriebsprozesse und Ausstiegspfad nachweisbar funktionieren, sollte MAX in eine formelle Migrationsbewertung gelangen. (MAX-Containerdokumentation)

Diese Analyse richtet sich an Infrastrukturverantwortliche, die NVIDIA- und AMD-Kapazitäten planen und ihre Abhängigkeit von einem einzelnen Hardwareanbieter verringern möchten. Sie ist außerdem für Entwicklerteams gedacht, die selbst gehostete Modelle betreiben, sowie für Ingenieure, die sich für Mojo 1.0 interessieren, aber vor allem wissen müssen, ob daraus ein belastbarer Inferenzbetrieb entsteht.

Die richtige Entscheidung beginnt nicht mit der Keynote

ModCon 2026 ist offiziell für den 18.08.2026 in San Francisco angekündigt. Die Veranstalter stellen Hardware-Flexibilität, MAX, Mojo und neue Plattformen in den Mittelpunkt und haben eine Live-Übertragung vorgesehen. In der Ankündigung wird ausdrücklich beschrieben, dass Modelle, Code und Container über NVIDIA, AMD und weitere Hardware laufen sollen. Das ist für eine technische Neubewertung relevant, ersetzt aber keine eigene Abnahme. (offizielle ModCon-Ankündigung)

Für die Investitionsentscheidung müssen wir drei Ebenen trennen:

1. Vorführung: Ein Modell startet in einer kontrollierten Demonstration.
2. Produktverfügbarkeit: Ein Paket, Container oder eine Version kann heruntergeladen und reproduziert werden.
3. Produktionsmigration: Der Dienst erfüllt unter eigener Last die Anforderungen an Antwortzeit, Verfügbarkeit, Überwachung, Wiederanlauf und Kosten.

Zwischen diesen Ebenen liegen häufig die teuersten Arbeiten. Ein Demo-Container kann zwar auf AMD und NVIDIA starten, während ein internes Modell wegen eines benutzerdefinierten Operators, einer bestimmten Quantisierung oder einer nicht unterstützten Cache-Strategie trotzdem nicht migrierbar ist.

Für unsere Bewertung gilt daher eine einfache Mindestschwelle:

• Das offizielle Artefakt muss verfügbar und versionierbar sein.
• Das eigene Zielmodell muss ohne versteckte manuelle Änderungen laufen.
• Messungen müssen mit festgehaltenen Parametern wiederholbar sein.
• Ein Fehler muss innerhalb des bestehenden Betriebsprozesses zu einer bekannten Alternative zurückführen.

Benötigt der Produktionsbetrieb direkt nach ModCon 2026 einen Wechsel zu MAX? Nein. Die Konferenz sollte eine technische Nachprüfung auslösen, aber keine automatische Beschaffungsentscheidung. Wer heute einen stabilen Dienst betreibt, sollte diesen zunächst unverändert lassen und MAX parallel mit begrenztem Verkehr, festen Tests und abgeschalteter automatischer Vollmigration prüfen.

Hardware-Abdeckung muss bis zur konkreten Kombination reichen

„Eine gemeinsame Softwareebene“ klingt zunächst eindeutig, ist technisch aber mehrschichtig. Für jede Zielplattform müssen mindestens Modellformat, Container, Graph-Compiler, Kernels, Treiber, Laufzeit, Gerätezugriff und Orchestrierung betrachtet werden.

Die aktuelle MAX-Containerdokumentation nennt mehrere Varianten: einen hardwareübergreifenden max-full-Container sowie getrennte AMD- und NVIDIA-Varianten. Für NVIDIA wird ein GPU-Gerätezugriff im Container beschrieben; für AMD sind unter anderem Gerätepfade und Gruppenberechtigungen erforderlich. Schon daran zeigt sich, dass ein gemeinsamer Container nicht automatisch eine identische Infrastrukturkonfiguration bedeutet. (MAX-Containerdokumentation)

Die offizielle Dokumentation empfiehlt für unterstützte Modelle GPU-Instanzen, die den MAX-Systemanforderungen entsprechen, und nennt Beispiele für NVIDIA- und AMD-Umgebungen. Das ist ein Hinweis auf die vorgesehene Betriebsrichtung, aber keine Zusage, dass jedes Modell, jede Treiberversion und jede Hardwaregeneration dieselbe Qualität erreicht. (MAX-Systemanforderungen und Modellhinweise)

Kann MAX auf AMD und NVIDIA denselben Modellservice ausführen? Für den dokumentierten Containerpfad lautet die Antwort: grundsätzlich ja, sofern Modell, Version und Hardwarekombination unterstützt werden. Für die Produktionsplanung muss die Antwort jedoch enger formuliert werden: Derselbe Servicevertrag ist nur dann nachgewiesen, wenn dieselben API-Antworten, Modellgewichte, Tokenisierungsregeln, Fehlercodes, Metriken und Betriebsbefehle auf beiden Plattformen reproduzierbar funktionieren.

Achtung: „Das Modell startet“ ist nur ein Kompatibilitätstest. Erst ein längerer Lastlauf mit identischem Eingabeprofil zeigt, ob Speicherbedarf, Antwortzeit und Fehlerverhalten tatsächlich für den eigenen Dienst ausreichen.

Bei Apple Silicon ist zusätzliche Vorsicht angebracht. Modular hat bereits beschrieben, dass MAX-Modelle auf Apple-Silicon-GPUs laufen können und dass M1- bis M5-Systeme in aktuellen Nightly-Versionen berücksichtigt wurden. Gleichzeitig weist die Veröffentlichung auf unterschiedliche Generationen und begrenzte Testabdeckung hin. Das ist ein brauchbarer Pfad für Entwicklung und Validierung, aber nicht automatisch ein Produktionsversprechen für jedes Modell. (Apple-Silicon-Hinweise von Modular)

Für Qualcomm NPU gilt eine noch strengere Beweisregel. Qualcomm hat nach dem Abschluss der Übernahme von Modular am 29.07.2026 erklärt, dass Mojo, MAX und Modular Cloud als Produkte und Marken fortgeführt werden sollen und dass die offene, heterogene Ausrichtung weitergeführt wird. Daraus lässt sich eine strategische Richtung ableiten, aber noch keine konkrete NPU-Kompatibilität für einen produktiven Inferenzdienst. (Qualcomm-Mitteilung zur Übernahme)

Leistung wird erst durch reproduzierbare Messung vergleichbar

Herstellerdaten und Konferenzdemonstrationen können zeigen, welches Potenzial eine Plattform besitzt. Für eine Kapazitätsplanung sind sie jedoch nur dann verwertbar, wenn das eigene Team die Messung unter vergleichbaren Bedingungen wiederholen kann.

Die Dokumentation und Veröffentlichungen von Modular enthalten bereits Leistungs- und Kompatibilitätsaussagen zu verschiedenen Hardwarepfaden. Frühere MAX-Veröffentlichungen nannten beispielsweise konkrete NVIDIA-GPU-Modelle und benchmarkbasierte Durchsatzwerte. Solche Zahlen dürfen nicht ohne Modellversion, Eingabelänge, Ausgabelänge, Batch-Strategie, Quantisierung und Auslastung auf einen anderen Dienst übertragen werden. (MAX-24.6-Veröffentlichung mit Benchmark-Kontext)

Wie lässt sich prüfen, ob MAX-Leistungsdaten reproduzierbar sind? Wir würden die Messung in fünf Schichten aufbauen:

1. Modell festschreiben: Exakter Modellname, Commit oder Gewichtsstand und Tokenizer werden dokumentiert.
2. Numerik festschreiben: Präzision, Quantisierung, KV-Cache-Einstellungen und maximale Kontextlänge dürfen zwischen den Plattformen nicht unbemerkt wechseln.
3. Verkehrsprofil festschreiben: Eingabe- und Ausgabelänge, Parallelität, Batch-Größe und Anfragerhythmus werden als Testdatei versioniert.
4. Messgrößen trennen: Durchsatz, Zeit bis zum ersten Token, Zeit zwischen Tokens, Fehlerrate, Arbeitsspeicher und Dauerlast werden separat erfasst.
5. Wiederholung durchführen: Jeder Test wird nach dem Aufwärmen mehrfach wiederholt und zusätzlich als längerer Stabilitätslauf ausgeführt.

Ein fairer Vergleich besteht also nicht aus „AMD gegen NVIDIA“ als abstraktem Duell, sondern aus einer exakt definierten Kombination:

Die häufigste Fehlentscheidung entsteht, wenn nur der beste Durchsatz veröffentlicht oder intern weitergereicht wird. Für den Einkauf ist dagegen oft die Kombination aus 95. Perzentil der Antwortzeit, nutzbarer Dauerlast und notwendiger Sicherheitsreserve wichtiger als ein kurzer Spitzenwert.

Besonders kritisch sind Modelle mit eigenen Kernels, ungewöhnlicher Quantisierung oder mehreren Eingabearten. Ein Textmodell kann auf zwei Plattformen problemlos starten, während Bildverarbeitung, Tool-Aufrufe oder lange Kontexte einen nicht unterstützten Operator aktivieren. Genau deshalb sollte der Test nicht nur den einfachsten Prompt enthalten, sondern die häufigsten und teuersten Produktionsfälle.

Migration betrifft Container, Monitoring und Rückfallpfade

Der Quellcode ist nur ein Teil des Migrationsaufwands. Ein bestehender Inferenzdienst besteht typischerweise aus Modellgewichten, Download- und Cache-Logik, Container-Images, API-Schicht, Authentifizierung, Monitoring, Alarmierung, Kapazitätsplanung und Rollback-Skripten.

Ein MAX-Pilot sollte deshalb mindestens folgende Fragen beantworten:

• Bleibt die vorhandene OpenAI-kompatible API unverändert?
• Können Modellgewichte und Tokenizer aus der bestehenden Registry übernommen werden?
• Müssen eigene Operatoren neu implementiert oder ersetzt werden?
• Funktionieren Quantisierung und KV-Cache mit derselben Genauigkeit?
• Werden strukturierte Logs und Metriken in die vorhandene Überwachung übernommen?
• Kann die Skalierung nach GPU-Speicher, Anfragezahl und Antwortzeit ausgelöst werden?
• Ist der Rückfall auf den bisherigen Dienst mit einer Konfigurationsänderung möglich?

Die Containerdokumentation beschreibt strukturierte JSON-Logs und Konfigurationsmöglichkeiten für die Log-Ausgabe. Das ist für die Betriebsintegration nützlich, muss aber im eigenen Monitoring validiert werden: Ein Logformat kann technisch vorhanden sein, während Dashboard, Alarmregel oder Datenschutzfilter noch nicht angepasst sind. (MAX-Logging-Dokumentation)

Mojo 1.0 ist in dieser Bewertung kein automatischer Reifeindikator. Die offizielle Mojo-Seite beschreibt eine noch junge Sprache, eine offene Standardbibliothek und den geplanten weiteren Open-Source-Ausbau des Compilers. Die dort angegebene stabile Fassung wurde zuletzt als Beta-Version geführt; daher müssen Sprachstabilität, Compilerumfang, Lizenzierung und API-Garantien nach dem ModCon-Termin anhand der tatsächlichen Release-Artefakte geprüft werden. (offizielle Mojo-Dokumentation)

Wird Mojo 1.0 die bestehende Inferenzentscheidung automatisch verändern? Nein. Mojo 1.0 kann den langfristigen Wartungs- und Erweiterungspfad attraktiver machen, ist aber kein Beweis dafür, dass ein vorhandener Python-, Container- oder Serving-Stack ohne Anpassung produktionsreif auf mehreren Hardwaretypen läuft. Die richtige Frage lautet nicht „Ist Mojo 1.0 veröffentlicht?“, sondern „Welche Teile unseres Dienstes hängen nachweislich von Mojo, MAX oder einem bestimmten Hardwarebackend ab?“.

Für Teams mit eigenen Kernels ist die Versionsstrategie besonders wichtig. Die offizielle Dokumentation beschreibt schnelle Weiterentwicklung und regelmäßige Nightly-Veröffentlichungen; historische MAX-Veröffentlichungen zeigen außerdem, dass Hardware- und Treiberunterstützung sich mit neuen Compiler- und CUDA-Anforderungen verändern kann. In einem produktiven Umfeld müssen daher stabile Version, Nightly-Nutzung, Sperrdatei, Kompatibilitätsprüfung und Rückrollversion ausdrücklich festgelegt werden. (Mojo-FAQ zur Entwicklungs- und Versionsstrategie)

Betriebssicherheit entscheidet über den tatsächlichen Nutzen

Eine Plattform ist für den Produktionseinsatz erst dann interessant, wenn Fehler nicht nur erkannt, sondern auch beherrscht werden. Für MAX sollten Verantwortliche vor einem Umstieg mindestens diese Betriebsfälle testen:

• Prozessabbruch während einer laufenden Anfrage;
• nicht verfügbarer oder beschädigter Modell-Cache;
• GPU-Speicherknappheit;
• Treiber- oder Gerätefehler;
• fehlerhafte Modellinitialisierung;
• Überlastung durch parallele Anfragen;
• Upgrade auf eine neue MAX-Version;
• Rückkehr auf das bisherige Inferenzsystem.

Die Fähigkeit, dieselbe Anwendung auf AMD und NVIDIA zu starten, reduziert möglicherweise die Abhängigkeit von einer Hardwareplattform. Sie beseitigt aber nicht automatisch die Abhängigkeit von bestimmten Treiberversionen, Container-Tags, Kernelpaketen oder Modellimplementierungen. Das Risiko verschiebt sich daher teilweise von der Hardwareebene in die Versionierung und in die Abnahmeprozesse.

Für strenge SLA-Anforderungen sollte die Entscheidung erst fallen, wenn ein längerer Dauertest, ein kontrollierter Rollback und ein dokumentierter Incident-Ablauf erfolgreich waren. Für Entwicklungsumgebungen, interne Werkzeuge oder nicht kritische Batch-Verarbeitung kann ein Preview- oder Nightly-Pfad dagegen früher vertretbar sein, sofern Datenzugriff, Datenschutz und Kosten getrennt bewertet werden.

Wenn Sie die Validierung auf Apple Silicon oder einer gemieteten Mac-Umgebung durchführen möchten, sollte der Test ausdrücklich zwischen CPU-, GPU- und NPU-Pfad unterscheiden. Eine Anwendung, die auf einem Mac startet, beweist nicht, dass derselbe Speicherpfad, dieselbe Parallelisierung oder dieselbe Modellabdeckung wie auf einer Rechenzentrums-GPU verfügbar ist. Für die Sicherheits- und Datenschutzprüfung können Sie die Hinweise zu Datenschutz und sicherem Fernzugriff heranziehen.

Die Entscheidungsmatrix trennt Weiterprüfen, Pilot und Pause

Die folgende Bewertung ist bewusst konservativ. Sie soll keine allgemeine MAX-Bewertung ersetzen, sondern verhindern, dass eine einzelne Demo eine Beschaffungs- oder Produktionsentscheidung dominiert.

Vor dem ersten Pilot sollten wir diese Punkte tatsächlich abhaken:

• [ ] Offizieller MAX-Container und konkrete Version sind intern gespeichert.
• [ ] Das Zielmodell startet auf jeder vorgesehenen Hardwarekombination.
• [ ] Modellgewichte, Tokenizer und Quantisierung sind identisch dokumentiert.
• [ ] Testdaten enthalten typische Eingabe- und Ausgabelängen.
• [ ] Durchsatz und Zeit bis zum ersten Token werden getrennt gemessen.
• [ ] Ein Dauerlasttest wurde mit festgelegter Parallelität ausgeführt.
• [ ] Spitzenverbrauch von Grafikspeicher und Arbeitsspeicher ist bekannt.
• [ ] Logs, Metriken und Alarmierungen erscheinen im bestehenden Monitoring.
• [ ] Ein fehlerhaftes Modell- oder Container-Upgrade kann zurückgerollt werden.
• [ ] Der alte Dienst bleibt während des Piloten technisch erreichbar.
• [ ] Datenschutz, Zugangskontrolle und Aufbewahrung der Testdaten sind geprüft.
• [ ] Die Kostenrechnung enthält nicht nur GPU-Zeit, sondern auch Engineering- und Betriebsaufwand.

Welche Reihenfolge ist nach ModCon 2026 sinnvoll? Zuerst sollten Sie die offiziellen Release-Artefakte und Hardwarelisten prüfen, danach ein einzelnes repräsentatives Modell auf AMD und NVIDIA ausführen, anschließend Dauerlast und Fehlerfälle testen und erst dann API-, Monitoring- und Skalierungsintegration bewerten. Die Reihenfolge verhindert, dass ein Team Wochen in Orchestrierung investiert, bevor die zentrale Modellkombination überhaupt stabil läuft.

Für offene Modelle ist außerdem eine getrennte Abnahme sinnvoll. Unsere Prüfpunkte für Modellbereitstellung und Leistungsabnahme können als ergänzende Struktur dienen, während die Entscheidung zwischen eigener Infrastruktur und einem verwalteten Dienst in einem Rahmen für selbst gehostete KI-Inferenz betrachtet werden sollte. Die verlinkten Themen ersetzen keine MAX-spezifische Messung, helfen aber dabei, Container-, Schnittstellen- und Kostenrisiken nicht isoliert zu bewerten.

Der Kostenvergleich endet nicht beim GPU-Stundensatz

Ein möglicher Vorteil von MAX über mehrere Hardwareplattformen liegt in der Beschaffungsflexibilität: Wenn ein Modell wirklich auf mehreren verfügbaren Beschleunigern mit vergleichbarer Dienstqualität läuft, kann das Team bei Engpässen oder Preisänderungen leichter ausweichen. Dieser Vorteil entsteht aber erst nach einer belastbaren Abnahme.

Der aktuelle Ansatz kann drei reale Nachteile haben: Er bindet das Team möglicherweise an eine einzelne GPU-Toolchain, erschwert kurzfristige Kapazitätswechsel und zwingt bei Hardwareengpässen zu teuren Überbrückungslösungen. Ein Wechsel auf MAX kann diese Abhängigkeit reduzieren, bringt aber zunächst neue Prüfkosten, Versionsrisiken und Integrationsarbeit mit sich. Für langfristig konstant hohe Last oder spezielle physische Schnittstellen kann der Kauf eigener Hardware weiterhin sinnvoller sein; für kurzfristige Validierung, Vergleichstests und begrenzte Migrationsphasen ist eine gemietete Mac-Umgebung von JexMac dagegen oft der risikoärmere Weg, weil die Infrastruktur nicht sofort gekauft werden muss.

Wenn die Hardwarekombination noch unklar ist, sollte daher zuerst ein kurzer, reproduzierbarer Testlauf gebucht oder aufgebaut werden. Die Entscheidung für oder gegen MAX sollte aus diesen Messwerten entstehen — nicht aus der Annahme, dass eine Konferenzdemonstration bereits dieselben Betriebsbedingungen wie der eigene Inferenzdienst abbildet.