Mistral Small 4 lokal ausführen

Mistral Small 4 ist ein neu veröffentlichtes multimodales KI-Modell von Mistral AI (März 2026), das Inference, Reasoning, Coding und multimodale Fähigkeiten in einer einzigen Architektur vereint. Es bietet ein 256K-Kontextfenster, ein Mixture-of-Experts-(MoE)-Design (~119B Gesamtparameter, ~6.5B aktiv pro Token) und liefert schnellere Inferenz (bis zu 40% geringere Latenz), während es in Benchmarks vergleichbare offene Modelle wie GPT-OSS 120B übertrifft.

Für den lokalen Betrieb benötigen Sie GPUs mit viel Speicher (≥48GB VRAM empfohlen) oder quantisierte Deployments sowie Frameworks wie Transformers, vLLM oder Ollama.

Was ist Mistral Small 4?

Ein einziges Modell für viele Aufgaben

Mistral Small 4 ist am besten als „Allrounder“ zu verstehen: Es kombiniert die Stärken von Mistrals bisherigen Instruction-, Reasoning- und Coding-Familien in einem Modell. In der eigenen Releasesprache des Unternehmens ist Small 4 das erste Mistral-Modell, das die Fähigkeiten von Magistral für Reasoning, Pixtral für multimodale Aufgaben und Devstral für agentisches Coding vereint. Es akzeptiert Text- und Bildeingaben, gibt Text aus und ist für Chat, Coding, agentische Workflows, Dokumentenverständnis, Recherche und visuelle Analyse gedacht.

Warum diese Veröffentlichung wichtig ist

Praktisch bedeutet das, dass Mistral Small 4 den Wechsel zwischen Modellen reduziert. Anstatt einen Prompt an ein schnelles Instruct-Modell, einen zweiten an ein Reasoning-Modell und einen dritten an ein Vision-Modell zu routen, können Sie einen einzigen Endpunkt verwenden und die Einstellung reasoning_effort nach Bedarf anpassen. Mistral sagt explizit, dass reasoning_effort="none" schnelle, leichtgewichtige Antworten liefert, die mit Chat im Stil von Small 3.2 vergleichbar sind, während reasoning_effort="high" tieferes, ausführlicheres Reasoning ähnlich den früheren Magistral-Modellen erzeugt.

Leistungsbenchmarks von Mistral Small 4

Wichtigste Leistungs-Highlights

👉 Damit ist es ideal für produktionsreife KI-Systeme.

Architektur (zentraler technischer Einblick)

• Modelltyp: Mixture-of-Experts (MoE)
• Gesamtparameter: ~119B
• Aktive Parameter pro Token: ~6.5B
• Experts: ~128 (4 aktiv pro Forward-Pass)

👉 Diese Architektur ermöglicht Intelligenz großer Modelle zu Kosten kleiner Modelle und eignet sich im Vergleich zu dichten Modellen ideal für lokale Bereitstellungen.

Bereitstellungsanforderungen für Mistral Small 4

Offizielle Mindest- und empfohlene Infrastruktur

Mistral ist hier ungewöhnlich explizit. Mindestinfrastruktur sind 4x NVIDIA HGX H100, 2x NVIDIA HGX H200 oder 1x NVIDIA DGX B200. Die empfohlene Konfiguration für optimale Leistung ist 4x HGX H100, 4x HGX H200 oder 2x DGX B200. Das ist ein starkes Signal, dass der vollständig offizielle Pfad auf Rechenzentrumsmaschinen und nicht auf eine einzelne Consumer-GPU abzielt.

Was das in der Praxis bedeutet

Mistral Small 4 ist Open-Weight und für seine Größe effizient, aber es ist immer noch ein 119B-MoE-System mit einem 256K-Kontextfenster. In realen Deployments bedeutet diese Kombination, dass der Speicherbedarf mit wachsender Kontextlänge schnell steigt und anhaltende Leistung üblicherweise von Multi-GPU-Tensor-Parallelismus und effizienter Serving-Software abhängt. Deshalb empfehlen wir vLLM als primäre Self-Deployment-Engine und die Bereitstellung OpenAI-kompatibler Serving-Muster, anstatt Single-Machine-„läuft einfach“-Defaults.

Empfohlene Einrichtung (Professional)

Warum Hardware wichtig ist

Denn:

• 119B-Parameter-Modell (selbst als MoE)
• Großes Kontextfenster (256K Tokens)
• Multimodale Verarbeitung

👉 Ohne Optimierung ist es für Consumer-GPUs zu schwer.

Mistral Small 4 lokal ausführen (Schritt für Schritt)

Schritt 1) Gewichte beziehen und Zugriffsbedingungen akzeptieren

vLLM bezieht Gewichte standardmäßig von Hugging Face, daher benötigen Sie ein Hugging-Face-Access-Token mit READ-Berechtigung und müssen die Bedingungen auf der Model-Card akzeptieren. Für ein praktisches lokales Setup bereiten Sie eine Linux-Maschine mit NVIDIA-Treibern, CUDA-kompatibler Laufzeitumgebung, Python und genügend GPU-Speicher für den gewählten Checkpoint vor. Wenn Sie die Artefakte bereits in Ihrem eigenen Storage haben, können Sie die Hugging-Face-Einrichtung überspringen und vLLM stattdessen auf den lokalen Pfad verweisen.

Schritt 2) Den offiziell empfohlenen Server-Stack verwenden

Empfohlen wird die Selbst-Bereitstellung über vLLM, das als hochoptimiertes Serving-Framework beschrieben wird, das eine OpenAI-kompatible API bereitstellen kann. Die Self-Deployment-Dokumente erwähnen auch TensorRT-LLM und TGI als Alternativen, aber vLLM ist der empfohlene Weg für diese Modellfamilie.

Schritt 3) Das von Mistral empfohlene Docker-Image ziehen oder vLLM manuell installieren

Mistral Small 4 empfiehlt die Verwendung eines benutzerdefinierten Docker-Images mit den erforderlichen Korrekturen für Tool-Calling und Reasoning-Parsing oder die manuelle Installation eines gepatchten vLLM-Builds. Die Model-Card stellt ein benutzerdefiniertes Image bereit und weist darauf hin, dass Mistral mit dem vLLM-Team zusammenarbeitet, um die Änderungen upstream einzubringen.

Ein praktischer Startpunkt ist:

docker pull mistralllm/vllm-ms4:latestdocker run -it mistralllm/vllm-ms4:latest

Schritt 4) Modell serven

Der von Mistral empfohlene Serverbefehl lautet:

vllm serve mistralai/Mistral-Small-4-119B-2603-NVFP4 \  --max-model-len 262144 \  --tensor-parallel-size 2 \  --attention-backend TRITON_MLA \  --tool-call-parser mistral \  --enable-auto-tool-choice \  --reasoning-parser mistral \  --max_num_batched_tokens 16384 \  --max_num_seqs 128 \  --gpu_memory_utilization 0.8

Dieser Befehl ist der wichtigste praktische Hinweis der gesamten Local-Story: Er zeigt, dass das Modell mit einem leistungsfähigen GPU-Backend, einem langen Kontextfenster und aktivierten, Mistral-spezifischen Tool- und Reasoning-Parsern betrieben werden soll.

Schritt 5) Ihre Anwendung mit dem lokalen Endpunkt verbinden

Da vLLM eine OpenAI-kompatible REST-API bereitstellt, können Sie bestehenden OpenAI-SDK-Code in der Regel auf http://localhost:8000/v1 zeigen lassen und den Großteil Ihrer Anwendungslogik unverändert lassen. Mistrals Beispiel verwendet base_url="http://localhost:8000/v1" und einen leeren API-Schlüssel, was ein gängiges Muster für die lokale Entwicklung ist.

from openai import OpenAIclient = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")resp = client.chat.completions.create(    model="mistralai/Mistral-Small-4-119B-2603-NVFP4",    messages=[{"role": "user", "content": "Summarize the document in five bullets."}],    temperature=0.7,    reasoning_effort="none",)print(resp.choices[0].message.content)

Schritt 6) Auf Geschwindigkeit oder Qualität abstimmen

Wenn Sie das Modell lokal testen, empfiehlt sich reasoning_effort="high" für komplexe Prompts und temperature=0.7 in diesem Modus, während niedrigere Temperaturen passender sind, wenn Reasoning deaktiviert ist. Dieselbe Model-Card trennt zudem den FP8-Checkpoint für beste Genauigkeit vom NVFP4-Checkpoint für Durchsatz und geringere Speichernutzung, sodass die richtige Konfiguration davon abhängt, ob Sie auf Qualität, Geschwindigkeit oder Hardware-Footprint optimieren.

Schritt 7: Optional – Über Ollama ausführen (vereinfacht)

ollama run mistral-small-4

👉 Am besten geeignet für:

• Lokale Entwicklung
• Schnelles Setup

Mistral Small 4 vs GPT-OSS vs Qwen 3.5 (vollständiger Vergleich)

Mistral Small 4: extrem effizientes MoE

• 119B Gesamtparameter
• ~6.5B aktiv pro Token
• 128 Experts (4 aktiv)
• Multimodal (Text + Bild)

👉 Kerngedanke: sehr große Kapazität bei geringer Rechenlast pro Token

Das führt zu:

• Hoher Leistung
• Niedriger Latenz
• Geringeren Inferenzkosten

GPT-OSS: praktisches MoE für den Einsatz

• 120B-Version: ~117B gesamt / 5.1B aktiv
• 20B-Version: ~21B gesamt / 3.6B aktiv
• Nur Text

👉 Kerngedanke: leistungsfähige Modelle auf minimaler Hardware betreiben

• Lässt sich auf einer einzelnen H100-GPU betreiben
• Starke Tool-Nutzung / strukturierte Ausgaben

Qwen 3.5: Skalierung hoher Leistungsfähigkeit

• Bis zu 122B Parameter
• Höhere Anzahl aktiver Parameter (~20B+)
• Multimodal + stark mehrsprachig

👉 Kerngedanke: Fähigkeiten maximieren, auch wenn die Rechenkosten steigen

Vergleich der Leistungsbenchmarks

Mit aktiviertem Reasoning erreicht oder übertrifft Small 4 GPT-OSS 120B bei LCR, LiveCodeBench und AIME 2025 und erzeugt dabei kürzere Ausgaben. Mistral nennt ein Beispiel, in dem Small 4 0.72 auf AA LCR mit nur 1.6K Zeichen erreicht, während vergleichbare Qwen-Ergebnisse 5.8K–6.1K Zeichen benötigten, und sagt, dass Small 4 GPT-OSS 120B auf LiveCodeBench übertrifft, während 20% weniger Ausgabe erzeugt wird.

Welche ist die beste lokale Wahl?

Meine Einschätzung: Mistral Small 4 ist die beste „Single-Model“-Wahl, wenn Sie eine ausgewogene lokale oder private Bereitstellung mit starkem General-Chat, Coding, agentischer Arbeit und Multimodalität suchen. GPT-OSS ist die klarste Wahl, wenn Sie ein offen verfügbares OpenAI-Modell mit sehr expliziter Anleitung zur lokalen Bereitstellung wollen, insbesondere die kleinere 20B-Version. Qwen3.5 ist die breiteste Familie und die richtige Option, wenn Ihnen mehrsprachige Abdeckung, mehrere Größen und flexible lokale Serving-Optionen am wichtigsten sind.

Wenn Sie auf diese führenden Open-Source-Modelle per API zugreifen möchten und den Anbieter nicht wechseln wollen, empfehle ich CometAPI, es stellt GPT-oss-120B und Qwen 3.5 plus API etc. bereit.

Anders gesagt: Sie können Small 4 als gehostetes Modell konsumieren oder die Gewichte ziehen und es auf Ihrer eigenen Infrastruktur selbst hosten.

Fazit

Small 4 ist eine sehr gute Wahl, wenn Sie ein Open-Weight, multimodales, reasoning-fähiges Modell benötigen, das self-hosted werden, feinabgestimmt und in bestehende OpenAI-Style-Anwendungsstacks integriert werden kann. Es ist besonders attraktiv für Teams, denen Bereitstellungskontrolle, Datenresidenz und geringere marginale Tokenkosten wichtig sind und die dennoch ein modernes, vielseitiges Modell wollen.

Bereit für den Zugriff auf Mistral Small 4? Dann kommen Sie zu CometAPI!