Mistral Large 4 lokal ausführen: Hardware, VRAM und Vorbereitung

Kann ich Mistral Large 4 heute schon lokal ausführen?

Nein. Stand 6. Oktober 2026 ist das Hugging-Face-Repo mistralai/Mistral-Large-4.0-1T05-A52B als kommende Veröffentlichung ohne Dateien gelistet. Der Launch-Beitrag von Mistral verspricht die Gewichte bis Monatsende; die Hugging-Face-Seite nennt als voraussichtlichen Termin den 31. Oktober, mehrere Medien berichten vom 27. Oktober.

Lizenz, Dateipräzision (BF16, FP8 oder ein 4-Bit-Format) und eine empfohlene Hardware-Liste hat Mistral noch nicht bekanntgegeben. Alles Folgende ist Rechnung auf Basis der veröffentlichten Parameterzahl – so kannst du deine Hardware jetzt budgetieren und die genaue Dateigröße am Release-Tag bestätigen.

Wenn du das Modell nur nutzen willst, brauchst du das alles nicht: Auf unserer Startseite chattest du schon jetzt mit Large 4 – mit einem kostenlosen Konto und 15 Credits pro Tag.

Speicherbedarf der Gewichte nach Präzision

Der Speicher für die Gewichte ist simpel: Parameter × Bytes pro Parameter. Large 4 hat insgesamt 1,05 Billionen Parameter (1,05e12). In einem Mixture-of-Experts-Modell muss jeder Experte im Speicher liegen, auch wenn pro Token nur 49 Mrd. Parameter genutzt werden.

Echte quantisierte Dateien sind etwas größer als die reine Bitzahl, weil sie zusätzlich Skalierungsfaktoren speichern. Ein Format mit durchschnittlich 4,5 Bit pro Gewicht ergibt zum Beispiel 1,05e12 × 4,5 / 8 = 590,6 GB statt 525 GB. Der Vision-Encoder mit 1,6 Mrd. Parametern fällt kaum ins Gewicht: 1,6e9 × 2 Byte = 3,2 GB bei BF16.

Welche GPU-Setups für Mistral Large 4 reichen

Ein Node mit 8× B200 ist das bequemste Einzel-Node-Ziel für FP8; 8× H200 fasst die FP8-Gewichte mit nur etwa 78 GB Reserve; 8× H100 funktioniert nur mit 4-Bit. Die Tabelle stellt den Gesamtspeicher jeder Gewichtsgröße gegenüber und zeigt, was für KV-Cache und Laufzeit-Overhead übrig bleibt.

Für BF16-Gewichte brauchst du zwei Nodes mit je 8× H200. Eine Workstation mit 512 GB Unified Memory fasst die 4-Bit-Gewichte nicht und bräuchte eine Quantisierung mit 3 Bit oder weniger.

KV-Cache: der Speicher zusätzlich zu den Gewichten

Über die Gewichte hinaus brauchst du Speicher für den KV-Cache, der Keys und Values für jeden Token jeder aktiven Unterhaltung hält. Er wächst linear mit der Kontextlänge und mit der Zahl der Nutzer, die du gleichzeitig bedienst.

Die Formel lautet: KV-Cache in Bytes = 2 (Keys und Values) × Layer × KV-Heads × Head-Dimension × Bytes pro Wert × Token × parallele Sequenzen. Layer-Zahl und Attention-Aufbau von Large 4 hat Mistral noch nicht veröffentlicht; sie stehen in der Modellkonfiguration, sobald die Gewichte erscheinen, und dann ergeben sich die genauen Kosten pro Token aus dieser Formel.

Eine Beispielrechnung für einen Cache mit 100 KB pro Token: Eine Unterhaltung, die den vollen Kontext von 524.288 Token füllt, braucht 524.288 × 100 KB ≈ 52,4 GB, während 8 Nutzer mit je 32.768 Token 8 × 32.768 × 100 KB ≈ 26,2 GB brauchen. Auf 8× H200 mit FP8 bleibt von den 78 GB Reserve dann wenig für Aktivierungen übrig – lange Kontexte brauchen dort einen FP8-KV-Cache oder kürzere Limits.

• Halbiere den Cache, indem du ihn in FP8 statt BF16 speicherst, wo deine Inference-Engine das unterstützt.
• Begrenze die Kontextlänge auf das, was du wirklich brauchst; 32.768 Token sind 1/16 des API-Fensters von 524.288 Token.
• Begrenze auf knappen Setups die Zahl paralleler Sequenzen, statt den Server Speicher für viele Nutzer vorab reservieren zu lassen.

Software-Support: vLLM, SGLang, llama.cpp und Ollama

Stand 6. Oktober 2026 ist in vLLM, SGLang, llama.cpp und Hugging Face Transformers kein Support für Mistral Large 4 angekündigt; eine Suche in deren GitHub-Issues und Pull Requests ergab keine modellspezifische Arbeit. Ollama und LM Studio bauen auf GGUF-Dateien im Stil von llama.cpp auf und hängen daher davon ab, dass dieser Support zuerst kommt.

Die Vorgängergeneration zeigt den wahrscheinlichen Weg. Mistral Large 3 kam mit FP8-Gewichten, einer NVFP4-Variante und vLLM-Support ab dem ersten Tag (vLLM 1.12.0 oder neuer mit mistral_common 1.8.6 oder neuer). Die Modellkarte empfiehlt für FP8 einen einzelnen Node mit B200 oder H200 und für NVFP4 einen einzelnen Node mit H100 oder A100.

Warum die Geschwindigkeit von den 49 Mrd. aktiven Parametern abhängt

Die Gesamtzahl der Parameter bestimmt, wie viel Speicher du brauchst; die aktiven Parameter bestimmen, wie viel Arbeit jeder Token kostet. Mistral Large 4 aktiviert pro Token 49 Mrd. Parameter (52 Mrd. inklusive Embedding- und Output-Layer). Bei FP8 liest jeder erzeugte Token also grob 49e9 × 1 Byte = 49 GB an Gewichten.

Deshalb kann ein MoE-Modell mit 1,05 Bio. Parametern schneller generieren, als seine Größe vermuten lässt: Artificial Analysis hat über die gehostete API 116,1 Output-Token pro Sekunde gemessen. Deine eigene Geschwindigkeit hängt von der Speicherbandbreite der GPUs ab und davon, wie die Experten auf die Karten verteilt sind.

Jetzt vorbereiten, am Release-Tag herunterladen

Schaff zuerst Platz auf der Festplatte: Schon der FP8-Download umfasst etwa 1,05 TB, eine BF16-Kopie wären rund 2,1 TB. Mit diesen Befehlen prüfst du den Speicherplatz und lädst das Repo, sobald Mistral die Dateien veröffentlicht.

• Nutze das Modell schon heute im Chat auf unserer Startseite – ganz ohne Einrichtung.
• Entwickle jetzt gegen die gehostete API (siehe unsere API-Anleitung und API-Preise) und stell den Endpunkt später auf deinen eigenen Server um.
• Datum, Lizenz und Dateiformate der Gewichte verfolgst du auf unseren Seiten zu Hugging Face und zu den Updates.

# Weight size in GB for a given precision (bytes per parameter)
python3 -c "print(1.05e12 * 1 / 1e9, 'GB at FP8'); print(1.05e12 * 0.5 / 1e9, 'GB at 4-bit')"

# Make sure the target disk has room (about 1.05 TB for FP8)
df -h /models

# Download after the weights are published on Hugging Face
hf download mistralai/Mistral-Large-4.0-1T05-A52B --local-dir /models/mistral-large-4