Mistral Large on-premise betreiben: Guide 2026

Pexon Consulting | 9 Min. Lesezeit | 15.07.2026

TL;DR

Mistral Large 3 (Apache 2.0, Release 2. Dezember 2025) lässt sich als open-weight Modell komplett im eigenen Rechenzentrum betreiben, statt Daten an eine API zu schicken. Pexon Consulting (80 Mitarbeiter, Deutschland, Microsoft Partner) baut den Betrieb via vLLM auf einem 8xH100-Node auf, DSGVO-konform und ohne Vendor-Lock-in. Produktiv in sechs Wochen.

Warum open-weight Mistral lokal statt über die API

Die kurze Antwort: weil bei einer API jeder Prompt und jedes Dokument den eigenen Verantwortungsbereich verlässt, und weil Apache 2.0 bei Mistral Large 3 die Gewichte tatsächlich zu deinem Eigentum macht. Für regulierte Branchen ist das kein Komfort-Thema, sondern die Voraussetzung überhaupt.

Wir sehen den Inbound dazu gerade fast täglich: „Wir wollen lokale KI-Infra für Mistral Large 3.“ Meist steckt eine von drei Motivationen dahinter, oft alle drei gleichzeitig.

Datensouveränität ist der Haupttreiber. Bei einer Cloud-API gehen Prompts, Kontext-Dokumente und teils auch Ausgaben durch fremde Infrastruktur. Bei Patientenakten, Schadensmeldungen oder Konstruktionsdaten ist das ein Problem, das kein Auftragsverarbeitungsvertrag vollständig auflöst. On-premise verlassen die Daten das eigene Netz nicht.

Der zweite Treiber sind Kosten bei hohem Volumen. Eine API rechnet pro Token. Solange du experimentierst, ist das billig. Sobald ein Assistent hunderte Mitarbeiter täglich bedient, kippt die Rechnung. Ab einer gewissen Auslastung ist eigene Hardware pro Token günstiger, und die Kosten sind vorher bekannt statt nach dem Monatsende.

Der dritte ist Lock-in. Ein API-Modell kann sich ändern, teurer werden oder verschwinden. Mit den lokalen Gewichten unter Apache 2.0 bestimmst du selbst, wann du das Modell wechselst. Genau das unterscheidet open-weight von „Open-Source-Marketing“: Bei Mistral Large 3 sind Basis- und Instruct-Version unter Apache 2.0 freigegeben, kommerziell nutzbar, self-hostbar, ohne Research-Only-Klausel.

Unsere klare Empfehlung: Wer nur einen Chatbot für unkritische FAQ will, braucht das nicht. Wer regulierte Daten verarbeitet oder ein hartes Datenschutz-Mandat hat, sollte on-premise nicht als Nice-to-have behandeln, sondern als Default.

Was Mistral Large 3 technisch ist

Mistral Large 3 ist ein Sparse-Mixture-of-Experts-Modell mit 675 Milliarden Gesamt-Parametern, von denen pro Token nur rund 41 Milliarden aktiv sind. Die Modell-ID lautet mistral-large-2512 (die 2512 steht für Dezember 2025), der API-Alias ist mistral-large-latest. Das Kontextfenster liegt bei 256.000 Token, und das Modell versteht neben Text auch Bilder.

Der MoE-Aufbau ist der Grund, warum das Modell überhaupt bezahlbar lokal läuft. Bei einem dichten 675B-Modell müsstest du alle Parameter pro Token rechnen. Bei MoE aktiviert ein Router nur einen Bruchteil der Experten. Die Gewichte müssen zwar komplett in den VRAM, aber die Rechenlast pro Token entspricht eher einem 40B-Modell. Das macht den Unterschied zwischen „läuft auf einem Node“ und „braucht ein halbes Rechenzentrum“.

Trainiert wurde das Modell auf NVIDIA-Hopper-GPUs. Mistral hat gemeinsam mit NVIDIA die Inferenz für TensorRT-LLM und vLLM optimiert, und es gibt einen komprimierten Checkpoint, der laut Hersteller auf einem einzelnen 8xA100- oder 8xH100-Node via vLLM läuft. Das ist die Ansage, an der wir unsere Hardware-Planung ausrichten.

Welche Hardware und wie viel VRAM

Direkt zur Zahl: Das unquantisierte Modell in FP8 braucht allein für die Gewichte rund 675 GB VRAM, mit Overhead für Aktivierungen und Framework-State landest du bei etwa 710 GB, KV-Cache noch nicht eingerechnet. In 4-Bit-Quantisierung sinkt das auf grob 355 GB. Das ist keine Workstation-Hardware, das ist ein GPU-Server.

Wir raten in den meisten Fällen zu einem 8xH100- oder 8xH200-Node in FP8. Q4 spart Hardware, kostet aber Genauigkeit, und bei einem Modell, das du wegen Datenschutz und Qualität lokal betreibst, ist das oft der falsche Sparhebel. Wenn dein Use-Case latenzunkritisch ist und viele parallele Anfragen fährt, kann Q4 auf 4xH200 trotzdem die wirtschaftlichere Wahl sein. Das entscheidet die Auslastung, nicht das Datenblatt.

Ein Punkt, den viele unterschätzen: Der KV-Cache skaliert mit Kontextlänge und Parallelität. 256k Kontext klingt gut, frisst aber massiv Speicher, sobald mehrere Nutzer lange Dokumente gleichzeitig schicken. Wer den VRAM knapp auf die Gewichte plant, läuft im Produktivbetrieb in Out-of-Memory-Fehler. Plane Headroom ein.

Betrieb via vLLM

vLLM ist unsere Standard-Inference-Engine für Mistral Large 3, weil Mistral und NVIDIA die Unterstützung offiziell mitgebaut haben. Die Engine bringt Tensor-Parallelismus, PagedAttention für effizienten KV-Cache und einen OpenAI-kompatiblen Endpoint mit, sodass bestehende Clients ohne Umbau anbinden. Stand 15. Juli 2026 ist die aktuelle Version vLLM v0.25.1, das Projekt hat 86.259 GitHub-Sterne (Abruf 15.07.2026).

Der Kern des Betriebs ist ein einziger Befehl. Hier die Variante für einen 8-GPU-Node in FP8:

# vLLM v0.25.1, Stand Juli 2026
# Startet Mistral Large 3 als OpenAI-kompatiblen Endpoint auf 8 GPUs.
# tensor-parallel-size = Anzahl GPUs, auf die das Modell verteilt wird.
vllm serve mistralai/Mistral-Large-3-Instruct-2512 
  --quantization fp8 
  --tensor-parallel-size 8 
  --max-model-len 32768 
  --gpu-memory-utilization 0.90 
  --served-model-name mistral-large 
  --host 0.0.0.0 --port 8000
# max-model-len bewusst kleiner als 256k gesetzt: schont den KV-Cache.
# Volle 256k nur, wenn der Use-Case es wirklich braucht.

Danach sprichst du den Endpoint wie die OpenAI-API an, nur eben gegen deinen eigenen Server:

# Test-Anfrage gegen den lokalen Endpoint.
# Kein Token verlässt das eigene Netz.
curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "mistral-large",
    "messages": [
      {"role": "user", "content": "Fasse den Vertragsentwurf in drei Sätzen zusammen."}
    ],
    "temperature": 0.2
  }'

Was dieser Befehl nicht liefert, ist der Produktivbetrieb. Ein vllm serve auf einem Node ist ein POC. Was fehlt, ist Redundanz, damit ein GPU-Ausfall nicht den ganzen Dienst killt, ein Reverse-Proxy mit Authentifizierung, Monitoring auf Latenz und VRAM-Auslastung, und ein Update-Pfad für neue vLLM-Versionen ohne Downtime. Genau da beginnt die eigentliche Arbeit.

DSGVO und Datensouveränität

On-premise-Betrieb löst das Kernproblem der DSGVO bei KI: Es findet keine Übermittlung personenbezogener Daten an einen Dritten statt, weil die Verarbeitung vollständig im eigenen Verantwortungsbereich bleibt. Kein Auftragsverarbeitungsvertrag mit einem US-Anbieter, keine Drittlandübermittlung, keine Diskussion über Schrems II. Das ist der harte juristische Vorteil, und er ist der Grund, warum wir bei CISOs und Compliance-Verantwortlichen mit diesem Setup offene Türen einrennen.

Apache 2.0 verstärkt das: Du darfst das Modell kommerziell nutzen, verändern und weitergeben, ohne Rückfrage bei Mistral. Für ein Modell dieser Größe unter einer echt permissiven Lizenz ist das 2026 immer noch die Ausnahme, nicht die Regel.

Das heißt nicht, dass DSGVO-Konformität mit dem Deployment automatisch erledigt ist. Zugriffskontrolle, Logging ohne unnötige Speicherung von Prompt-Inhalten, Löschkonzepte und ein sauberes Rollen-Management gehören dazu. Aber der teuerste und juristisch heikelste Teil, der Datenabfluss, ist mit on-premise vom Tisch. Alles Weitere ist normale IT-Security, die dein Team ohnehin beherrscht.

Häufig gestellte Fragen

Was kostet der on-premise-Betrieb von Mistral Large 3?

Der größte Posten ist die GPU-Hardware. Ein 8xH100-Node liegt je nach Beschaffung im mittleren sechsstelligen Bereich als Kauf, deutlich günstiger als Miete, wenn die Auslastung hoch ist. Dazu kommen Strom, Kühlung und Betrieb. Ab mehreren hundert aktiven Nutzern täglich ist das pro Token günstiger als die API, und die Kosten sind vorher planbar statt nutzungsabhängig.

Reicht ein Server oder brauche ich einen Cluster?

Für die meisten Enterprise-Use-Cases reicht ein einzelner 8x-GPU-Node, weil Mistral genau dafür einen komprimierten Checkpoint bereitstellt. Einen Cluster brauchst du erst, wenn Ausfallsicherheit oder sehr hohe Parallelität gefordert sind. Dann betreibst du zwei Nodes hinter einem Load-Balancer statt einen größeren.

Mistral Large 3 API oder on-premise, was ist besser?

Kommt auf Daten und Volumen an. Bei unkritischen Daten und niedrigem Volumen ist die API schneller startklar und günstiger. Sobald regulierte Daten im Spiel sind oder das Volumen hoch ist, gewinnt on-premise bei Datenschutz, Kosten und Unabhängigkeit. Die Lizenz ist bei Mistral Large 3 kein Blocker, Apache 2.0 erlaubt den Eigenbetrieb ausdrücklich.

Welche Inference-Engine soll ich nehmen, vLLM oder etwas anderes?

Für Mistral Large 3 empfehlen wir vLLM, weil Mistral und NVIDIA die Unterstützung offiziell optimiert haben und der OpenAI-kompatible Endpoint die Anbindung trivial macht. SGLang ist eine ernstzunehmende Alternative bei bestimmten Lastprofilen. Ollama ist für ein 675B-Modell im Produktivbetrieb nicht das richtige Werkzeug.

Wie lange dauert es, bis so ein Setup produktiv läuft?

Ein lauffähiger POC steht in Tagen, sobald die GPUs da sind. Der Sprung zu produktivem Betrieb mit Redundanz, SSO, Monitoring und DSGVO-sauberem Logging dauert länger. Wir setzen das als Sechs-Wochen-Pilot auf, inklusive Hardware-Dimensionierung und Betriebskonzept.

Nächster Schritt

Wenn ihr Mistral Large 3 lokal betreiben wollt und vor der Frage steht, welche Hardware und welches Betriebskonzept wirklich zu eurem Use-Case passen, klärt das ein kurzes Gespräch schneller als jede Datenblatt-Recherche.

Verwandte Themen

Externe Referenz: vLLM-Dokumentation