MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?

Kunden mit sensiblen Daten fragen mich immer wieder, ob offene Modelle inzwischen gut genug sind, um sie auf eigener Hardware zu betreiben. MiniMax M3 ist eines der leistungsfähigsten Open-Weight-Modelle 2026: rund 428 Milliarden Parameter, ein Kontext von einer Million Tokens und Text, Bild und Video als Eingabe. Es ist aber auch so gross, dass 'selbst betreiben' einen echten Plan braucht. Was M3 ist, was die Zahlen wirklich sagen, was der Betrieb verlangt und wann ich es einsetzen würde.

Dominik Heinrich

7. November 202611 Min. Lesezeit

1. Was M3 ist

MiniMax hat M3 am 1. Juni 2026 veröffentlicht, die Gewichte folgten direkt danach auf Hugging Face. Es ist ein nativ multimodales Mixture-of-Experts-Modell: rund 428 Milliarden Parameter insgesamt, von denen pro Token etwa 23 Milliarden aktiv sind, mit Text, Bild und Video als Eingabe und Text als Ausgabe. MiniMax hat es von Anfang an mit gemischten Modalitäten trainiert, statt Bildverstehen nachträglich anzubauen.

Das Hauptmerkmal ist das Kontextfenster von einer Million Tokens. Es beruht auf MiniMax Sparse Attention, die laut dem technischen Bericht von MiniMax den Rechenaufwand pro Token bei einer Million Tokens Kontext auf etwa ein Zwanzigstel des Vorgängers M2 senkt. M3 unterstützt ausserdem drei Denkmodi pro Anfrage: immer an, adaptiv und aus. Gerade Letzteres zählt in der Praxis, denn Tiefe gegen Latenz lässt sich so pro Aufruf abwägen statt pro Deployment.

2. Warum Mixture-of-Experts die Rechnung verändert

In einem dichten Modell arbeitet jeder Parameter an jedem Token. In einem Mixture-of-Experts-Modell schickt ein Router jedes Token an wenige spezialisierte Experten, sodass für ein einzelnes Token nur etwa 23 der 428 Milliarden Parameter arbeiten. Dadurch sind Antworten viel schneller und günstiger zu berechnen, als die Gesamtgrösse vermuten lässt, und genau deshalb ist MoE zum Standarddesign grosser offener Modelle geworden.

Der Haken ist der Speicher. Alle Experten müssen trotzdem im GPU-Speicher liegen, denn der Router kann für das nächste Token jeden von ihnen wählen. Man zahlt also beim Speicher wie für ein Modell mit 428 Milliarden Parametern und bei der Rechenleistung wie für ein viel kleineres. Für den Betrieb ist das die wichtigste Tatsache: Die Zahl der GPUs bestimmen Gesamtparameter plus Kontext, den Durchsatz dieser GPUs die aktiven Parameter.

Tipp aus der Praxis

Beim Vergleich von Hosting-Optionen die GPUs nach Gesamtparametern dimensionieren und den Durchsatz nach aktiven Parametern schätzen. Beides zu verwechseln ist der häufigste Dimensionierungsfehler bei MoE-Modellen.

What is Mixture of Experts?, IBM Technology (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

3. Die Zahlen genau lesen

MiniMax und das vLLM-Rezept nennen 59,0 % auf SWE-Bench Pro, 66,0 % auf Terminal-Bench 2.1 und 74,2 % auf MCP Atlas, alles starke Werte für agentisches Programmieren und Werkzeugnutzung. Es sind Herstellerzahlen, gemessen mit dem Setup des Herstellers. Artificial Analysis, das eigene unabhängige Tests fährt, gibt M3 auf seinem Intelligence Index 19 Punkte, unter dem Durchschnitt der Open-Weight-Modelle seiner Grössenklasse, und hält zugleich fest, dass es preiswert und pro Aufgabe schneller als der Durchschnitt ist.

Beides kann gleichzeitig stimmen. Ein Modell kann bei agentischem Programmieren und Tool-Aufrufen sehr gut sein und bei breitem Schlussfolgern oder Wissensfragen schwächer. Für Ihre Entscheidung zählt nur die Zahl aus Ihrem eigenen Testset: 30 bis 50 echte Aufgaben mit erwartetem Ergebnis, gegen M3 und gegen das heute genutzte gehostete Modell, gemessen an Qualität, Latenz und Kosten pro Aufgabe.

4. Offene Gewichte sind nicht Open Source

Die Gewichte stehen unter der MiniMax Community License, nicht unter MIT oder Apache 2.0. Kommerzielle Nutzung ist möglich, aber an Bedingungen geknüpft, also die Lizenz mit der Rechtsabteilung lesen, bevor ein Produkt darauf aufbaut, und vor jeder grösseren Version erneut, denn Lizenzen ändern sich zwischen Releases.

Die Lizenz als Teil des Artefakts behandeln. Den Lizenztext neben den Modelldateien in der eigenen Registry ablegen, festhalten, welche Version wo läuft, und diese Information für Audits leicht auffindbar machen. Ausserdem die Modellfamilien auseinanderhalten: MiniMax veröffentlicht mehrere Modelle unter derselben Marke, etwa das separate Videomodell H3, und jedes hat eigene Bedingungen. 'Wir nutzen MiniMax' ist für eine Compliance-Prüfung zu ungenau; 'wir betreiben MiniMax-M3 in dieser Revision unter dieser Lizenz für diese Anwendungsfälle' ist es nicht.

5. Was der Betrieb braucht

In BF16 sind allein die Gewichte rund 860 GB gross, in 8 Bit rund 430 GB. Dazu kommt der KV-Cache für lange Kontexte, und bei Hunderttausenden Tokens ist der auch mit Sparse Attention nicht klein. Die Standardkonfiguration des vLLM-Rezepts ist ein einzelner Node mit 8× H200, Tensor-Parallelität und BF16. Auf AMD braucht BF16 ebenfalls acht GPUs, die MXFP8-Variante läuft ab vier. MiniMax veröffentlicht einen MXFP8-Build, und das Rezept führt NVFP4- und MXFP4-Varianten für neuere Hardware.

Realistisch ist das ein dedizierter GPU-Node in Ihrer Cloud-Region oder im Rechenzentrum, keine Workstation und kein geteilter Cluster, auf dem auch Ihre Web-Apps laufen. Mit dem Rechner unten sehen, wie die Präzision den Speicherbedarf verändert, und einen reservierten GPU-Node gegen die heutigen Ausgaben für gehostete API-Aufrufe rechnen. Für viele Teams lohnt es sich erst bei hohem, stetigem Volumen oder wenn die Daten schlicht nicht hinausdürfen.

bash

# vLLM recipe default: one node, 8x H200, tensor parallel, BF16
vllm serve MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --max-model-len 65536 \
  --tensor-parallel-size 8 \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3

Tipp aus der Praxis

Zum Start war die M3-Unterstützung noch in keinem stabilen vLLM-Release; das Rezept setzt ein eigenes Container-Image. Vor dem Festschreiben von Versionen in Produktion das Rezept prüfen.

Interaktiv

Was kostet ein Mixture-of-Experts-Modell im Betrieb?

Alle Experten müssen im GPU-Speicher liegen, aber jedes Token läuft nur durch die aktiven. Speicher skaliert mit allen Parametern, Tempo mit den aktiven.

Parameter gesamt (Mrd.)428B

Aktiv pro Token (Mrd.)23B

Genauigkeit

≈ 428 GB

Gewichte im GPU-Speicher

80-GB-GPUs, mindestens

23B

Rechenaufwand pro Token, wie ein dichtes Modell dieser Grösse

Planungswert: Gewichte plus rund 15 % für KV-Cache und Laufzeit. Echter Durchsatz hängt von Batch-Grösse, Interconnect und Serving-Engine ab.

Alle Rechner und Checklisten

6. Auf Kubernetes wie einen Dienst betreiben

Das Modell auf einen eigenen GPU-Node-Pool mit Taint legen, damit nur Inferenz-Pods dort landen, und mit dem NVIDIA GPU Operator oder den GPU-Node-Images der Cloud die Treiber einheitlich halten. Auf AKS liefert ein GPU-Node-Pool mit passender VM-Grösse denselben Baustein. Die Gewichte im Object Storage oder auf einem vorab befüllten Persistent Volume nahe am Cluster cachen, denn Hunderte Gigabyte bei jedem Neustart aus dem Internet zu ziehen, macht Skalierung und Wiederherstellung zum Ausfall.

Die OpenAI-kompatible API von vLLM nur im eigenen Netz anbieten, hinter Gateway und Single Sign-on, nie direkt im Internet. Nach Warteschlangenlänge und Zeit bis zum ersten Token skalieren statt nach CPU, und auf GPU-Speicher, Fehlerraten und Token-Durchsatz alarmieren. Anfragen mit langem Kontext verdienen eigene Limits, damit jemand, der eine ganze Codebasis einfügt, nicht alle anderen ausbremst.

yaml

# Inference pod on a tainted 8-GPU node, weights from a pre-filled volume
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: vllm
      image: vllm/vllm-openai:minimax-m3
      args: ["--model", "/models/MiniMax-M3", "--tensor-parallel-size", "8",
             "--block-size", "128", "--max-model-len", "65536"]
      resources:
        limits:
          nvidia.com/gpu: 8
      volumeMounts:
        - { name: weights, mountPath: /models }
        - { name: shm, mountPath: /dev/shm }
  volumes:
    - name: weights
      persistentVolumeClaim: { claimName: minimax-m3-weights }
    - name: shm
      emptyDir: { medium: Memory, sizeLimit: 64Gi }

Tipp aus der Praxis

Image und Gewichte-Volume vorab bereitstellen, bevor sie gebraucht werden. Ein Kaltstart, der 800 GB herunterlädt, ist kein Autoscaling, sondern ein Ausfall.

Architektur für den Selbstbetrieb eines offenen Mixture-of-Experts-Modells auf Kubernetes: Ein eigener GPU-Node-Pool betreibt vLLM mit Tensor- und Experten-Parallelität, die Gewichte kommen gecacht aus dem Object Storage, eine interne OpenAI-kompatible API liegt hinter einem Gateway mit Single Sign-on, das Deployment skaliert nach Warteschlangenlänge, und Monitoring verfolgt GPU-Speicher, Latenz und Fehler. (AWS) — Selbstbetrieb eines offenen MoE-Modells: eigene GPU-Nodes, gecachte Gewichte, eine interne API hinter dem Gateway, Skalierung nach Warteschlange.

7. Wie ein Produkt betreiben, nicht wie ein Experiment

Ein selbst betriebenes Modell ist ein Dienst mit Nutzern und braucht, was jeder Dienst braucht: einen Owner, einen Versionsplan, Monitoring und einen Rückweg. Ein Model-Gateway davorsetzen, das auch die gehosteten Modelle kennt, sodass Anwendungen einen einzigen Endpoint aufrufen und das Gateway nach Datenklasse, Kosten und Qualität routet. Dann wird ein Modell-Upgrade zu einer Routing-Änderung, die sich in Sekunden zurücknehmen lässt.

Die Azure-Well-Architected-Leitlinien für KI-Workloads und die AWS Generative AI Lens betonen dieselben Betriebsgrundlagen: laufend evaluieren, Qualität überwachen und nicht nur Verfügbarkeit, Kapazität für die Spitzen planen. In der Praxis heisst das: Das Testset läuft bei jeder Modell- oder Konfigurationsänderung, ein Dashboard zeigt Qualität, Latenz und Kosten pro Aufgabe für jedes Modell nebeneinander, und jemand schaut jede Woche darauf.

8. Wo es passt

M3 glänzt, wo Daten das eigene Netz nicht verlassen dürfen, wo lange Dokumente oder ganze Codebasen in einen einzigen Kontext passen müssen und wo Agenten über eigene Werkzeuge und MCP-Server arbeiten. Es neben einem gehosteten Spitzenmodell hinter das Gateway stellen, nach Datenklasse routen und Qualität und Kosten einige Wochen an echter Arbeit vergleichen, bevor feststeht, wie viel Verkehr es bekommt.

Das Release-Tempo im Blick behalten. Im Oktober 2026 hat MiniMax mit M3.1-Flash nachgelegt: dieselbe Grössenklasse, Sparse Attention im ganzen Modell, quantisierungsbewusstes Training und spekulatives Decoding, mit dem Ziel besserer Ergebnisse und effizienterer Inferenz. Vor dem Hardwarekauf die neueste Variante prüfen. Und für die schwierigsten Denkaufgaben mit Daten, die das Netz verlassen dürfen, würde ich weiterhin mit einem gehosteten Spitzenmodell beginnen und das Testset sagen lassen, wann ein offenes aufgeholt hat.

Fazit
M3 macht Selbstbetrieb für sensible Arbeit zu einer ernsthaften Option, wenn das GPU-Budget steht. Benchmarks als Startpunkt sehen, die Lizenz prüfen und das eigene Testset entscheiden lassen.

Echte Projekte dazu

Offline-KI-Roboter auf einem ESP32

Selbst ausprobieren

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden

MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?

1. Was M3 ist

2. Warum Mixture-of-Experts die Rechnung verändert

3. Die Zahlen genau lesen

4. Offene Gewichte sind nicht Open Source

5. Was der Betrieb braucht

Was kostet ein Mixture-of-Experts-Modell im Betrieb?

6. Auf Kubernetes wie einen Dienst betreiben

7. Wie ein Produkt betreiben, nicht wie ein Experiment

8. Wo es passt

Kontakt aufnehmen