Mistral Large 4 Self-Hosting: Lehren aus harten Fehlern

Als Mistral die Gewichte für Mistral Large 4 veröffentlichte – ein Modell mit rund 1 Billion Parametern, von denen etwa 52 Milliarden pro Token aktiv sind – füllte sich mein Posteingang mit derselben Frage: Können wir das selbst betreiben? Self-Hosting von Open Weights ist plötzlich keine Bastlerfantasie mehr, sondern eine echte architektonische Option. Das bedeutet, dass Teams gleich eine Menge teurer Fehler machen werden. Ich habe bereits mehrere davon miterlebt. Dieser Artikel ist die Version mit den gesammelten Lehren: die konkreten Wege, auf denen Praktiker Self-Hosting falsch angehen, und wie die Lösung jedes Mal aussieht.

Fehler 1: „Open Weights“ als „frei nutzbar, wie man will“ verstehen

Der erste Fehler passiert, bevor überhaupt jemand eine GPU anfasst. Mistral Large 4 steht unter einer modifizierten MIT-artigen Lizenz mit einer wichtigen Ausnahme: Wenn du oder deine verbundenen Unternehmen ein Model-as-a-Service-Geschäft betreiben, brauchst du vor der kommerziellen Nutzung des Modells eine separate kommerzielle Lizenz von Mistral. Für ein Unternehmen, das Inferenz intern betreibt – etwa zum Zusammenfassen von Dokumenten oder für einen Coding-Assistenten für Mitarbeitende – ist das wahrscheinlich in Ordnung. Für ein Startup, das Inferenz weiterverkaufen will, ist es ein hartes Stoppschild, bis du Mistral angeschrieben hast.

Praktiker liegen hier in beide Richtungen falsch. Manche Teams lesen „offen“ in einer Pressemitteilung, bauen ein kommerzielles Produkt auf den Gewichten und entdecken die Einschränkung erst bei einer Due-Diligence-Prüfung für eine Finanzierungsrunde – der denkbar schlechteste Zeitpunkt. Andere reagieren über und nehmen an, die Lizenz verbiete jede kommerzielle Nutzung, obwohl sie sich in Wahrheit gegen konkurrierende Inferenzanbieter richtet. Die Lösung ist langweilig und unverzichtbar: Lass deine Rechtsabteilung den tatsächlichen Lizenztext lesen, nicht den Ankündigungsbeitrag. Ob man das „Open Weights“ oder „weight-available“ nennt – eine Unterscheidung, über die die Community lautstark und nicht ganz zu Unrecht streitet –, die technische Entscheidung sollte davon bestimmt werden, was die Bedingungen deinem Geschäft tatsächlich erlauben.

Noch eine Feinheit: Dieses Lizenzmuster ist inzwischen die Regel bei den großen Gewichtsveröffentlichungen, nicht die Ausnahme. Wenn deine Architektur den Wechsel zwischen Mistral, Qwen und anderen Frontier-Gewichtsmodellen vorsieht, brauchst du eine Lizenzmatrix statt einer einmaligen Prüfung. Bau diese Tabelle, bevor du den Cluster baust.

Fehler 2: Die Hardware nach der Marketingseite statt nach der Rechnung dimensionieren

Hier ist der Fehler, der am meisten Geld verbrennt. Ein Ingenieur liest „1 Billion Parameter“, wirft einen Blick auf die vier H200 im Serverraum der Firma und denkt, 540 GB VRAM seien schon nah genug dran. Sind sie nicht, und der Grund ist eine Rechnung, die neunzig Sekunden dauert und dir ein Quartal voller Peinlichkeit erspart.

Bei BF16-Präzision braucht eine Billion Parameter allein für die Gewichte etwa 2 TB Speicher. Quantisierst du auf 8 Bit, bist du nahe bei 1 TB. Bei 4 Bit sind es um die 500–560 GB – und da sind KV-Cache, Aktivierungen und Serving-Overhead noch nicht eingerechnet. Der 540-GB-Server passt nur für ein 4-Bit-Modell, wenn du mit einem kurzen Kontextfenster und einer Handvoll gleichzeitiger Nutzer leben kannst. Die Mixture-of-Experts-Architektur (52 Mrd. aktive Parameter pro Token) hilft bei der Rechenleistung pro Token, bringt aber für den Speicher nichts: Alle eine Billion Parameter müssen irgendwo adressierbar liegen, und bei einem MoE werden die Expert-Gewichte unvorhersehbar angesprochen. Lagerst du sie in den CPU-RAM aus, zerstört das die Latenz – bei Dense-Modellen ist das nicht so drastisch.

Die Lösung ist, vom Serving-Bedarf rückwärts zu rechnen, nicht von der Hardware vorwärts. Lege zuerst Zielkontextlänge, Parallelität und Tokens pro Sekunde fest, leite daraus die Quantisierungsstufe ab, die du dir leisten kannst, und dann die Hardware. Wenn das Ergebnis acht H200 oder ein Paar NVL72-artiger Knoten sind und dir diese Zahl einen Stich versetzt, dann ist das gut – der Stich zeigt, dass das Modell wie beabsichtigt wirkt. Das verwandte Problem haben wir in was du tun kannst, wenn deiner GPU der VRAM ausgeht behandelt. Die dortigen Optionen (Offloading, kleinere Quants, kleinere Modelle) gelten auch hier, nur im Rechenzentrumsmaßstab.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Die ehrliche Version dieser Tabelle enthält KV-Cache und Overhead. Die unehrliche Version – nur die Gewichte – ist der Grund, warum Teams am Ende ein Modell haben, das zwar lädt, aber nicht mehr als drei Nutzer bedienen kann.

Fehler 3: Quantisierung als kostenloses Mittagessen behandeln

Sobald Teams akzeptieren, dass sie quantisieren müssen, ist der nächste Fehler die Annahme, 4 Bit sei „im Grunde dasselbe Modell“. Manchmal stimmt das. Oft nicht, und die Fehlerbilder sind genau die, die dir am wichtigsten sind.

Das Muster, das ich immer wieder sehe: Ein Team misst sein 4-Bit-Deployment mit MMLU-artigen Multiple-Choice-Fragen, sieht einen Rückgang von 1 % und geht live. Dann berichten Produktivnutzer, dass lange Multi-File-Refactorings aus dem Ruder laufen oder dass Tool-Calling-JSON bei niedriger Wahrscheinlichkeit, aber hoher Häufigkeit subtil kaputt geht. Aggressive Quantisierung schadet überproportional langen, strukturierten und niedrig temperierten Aufgaben – genau den agentischen und Coding-Workloads, die ein Frontier-Modell überhaupt rechtfertigen. Der Durchschnitt bewegt sich kaum, aber das Ende der Verteilung bricht weg.

Die Lösung: Quantisiere so weit, wie dein Task-Eval es toleriert, nicht so weit, wie dein VRAM es erzwingt. Lass die Prompts deines eigenen Workloads gegen FP8-, 4-Bit- und 3-Bit-Builds laufen und vergleiche sie. Besteht 3 Bit deine Evals, herzlichen Glückwunsch, deine Hardwarerechnung hat sich gerade halbiert. Scheitert es, hilft dir kein Benchmark-Durchschnitt. Und bevorzuge native quantisierte Releases, wenn der Hersteller sie ausliefert: Mistral hat neben den BF16-Gewichten eine NVFP4-Variante veröffentlicht, und ein First-Party-Quant mit gemessenen Qualitätsabweichungen schlägt eine GPTQ-Konvertierung aus der Community, die du einen Nachmittag lang validiert hast.

Eine Quantisierungsstufe ist ein Qualitätsbudget, keine Kompressionseinstellung. Gib es dort aus, wo dein Workload den Verlust verkraften kann.

Fehler 4: API-Preis gegen GPU-Preis stellen und das Ergebnis TCO-Analyse nennen

Die klassische Tabelle: „Die API kostet 2,10 $ pro Million Output-Tokens, ein reservierter GPU-Knoten kostet X $ pro Stunde, also rechnet sich Self-Hosting ab Y Tokens pro Monat.“ Diese Tabelle ist fast immer falsch, und zwar in die teure Richtung.

Was sie übersieht, ist die Auslastung. Eine API gibt dir 100 % Auslastung fremder Kapazität, abgerechnet pro Token. Dein eigener Cluster liefert dir die Auslastung, die dein Traffic-Muster hergibt, und die meisten internen Workloads sind schubweise: tagsüber stark, nachts untätig, rund um Releases spitzig. Ein auf Spitzenlast dimensionierter Cluster steht den größten Teil des Tages halb leer. Dazu kommen Kosten, die nie in der Tabelle auftauchen: eine Bereitschaftsrotation für einen Serving-Stack, der jetzt vLLM-Upgrades, CUDA-Treiber-Inkompatibilitäten und den Pager um 2 Uhr nachts umfasst, wenn der KV-Cache fragmentiert; der ständige Modell-Update-Aufwand (validierst du jedes neue Gewichtsrelease erneut? Deine Eval-Suite sagt ja) und die Opportunitätskosten des ML-Ingenieurs, der jetzt GPU-Babysitter ist statt Produkte zu bauen.

Dazu kommt ein bewegliches Ziel, das niemand einpreist. Mistral hat den API-Preis für dieses Modell zwischen Preview und finaler Version fast halbiert: Input-Tokens fielen von 1,36 $ auf 0,70 $ pro Million. Jede ROI-Rechnung für Self-Hosting, die auf dem alten Preis basiert, ist inzwischen Fiktion. Frontier-Inferenz wird im Quartalsrhythmus billiger, deine Hardware wertet auf einem mehrjährigen Rhythmus ab. Diese Asymmetrie ist der stille Killer vieler Self-Hosting-Business-Cases.

Die Konsequenz: Betreibe selbst nur aus Gründen, die die API strukturell nicht bieten kann. Diese Gründe gibt es, und sie sind real – aber „günstiger bei Skalierung“ gehört bei den Größenordnungen, in denen die meisten Unternehmen tatsächlich arbeiten, selten dazu.

Wann Self-Hosting tatsächlich gewinnt

Wann lohnt es sich also, Gewichte der Mistral-Klasse lokal zu betreiben statt die API zu nutzen? Nachdem ich gesehen habe, wie Teams es richtig und falsch machen, fallen die Gewinnszenarien in vier Gruppen:

• Datenresidenz und Souveränität. Regulierte Branchen, verteidigungsnahe Arbeit und EU-Organisationen mit strengen Jurisdiktionsanforderungen. Eine Einschränkung, die ich in freier Wildbahn gesehen habe: Ein Unternehmen durfte aus Compliance-Gründen keine Modelle chinesischer Herkunft verwenden. Offene Gewichte eines europäischen Labors mit prüfbarer Herkunft lösten ein Problem, das kein API-Vertrag lösen konnte.
• Air-Gapped- oder zeitweise verbundene Umgebungen. Wenn das Netzwerk nicht zuverlässig existieren kann, sind lokale Gewichte die ganze Architektur. Dieses Muster haben wir in dem Aufbau eines LLM, das offline funktioniert, untersucht.
• Dauerhafte, planbare Workloads mit hohem Volumen. Batch-Dokumentenverarbeitung, die rund um die Uhr mit konstantem Durchsatz läuft, kann die Preise pro Token tatsächlich schlagen – weil sie das Auslastungsproblem konstruktionsbedingt löst.
• Feintuning und Modifikation. Du kannst das Modell einer fremden API nicht über das hinaus feintunen, was deren Fine-Tuning-Endpunkt erlaubt. Die Gewichte zu besitzen heißt, die Trainingsschleife zu besitzen: weiteres Pretraining auf Domänenkorpora, eigenes Alignment, Destillation in kleinere Deployments.

Auffällig ist, was nicht auf der Liste steht: Latenz. Ein MoE-Modell mit einer Billion Parameter selbst zu hosten, ergibt keine geringere Latenz als eine gut ausgestattete API, es sei denn, du gibst aggressiv Geld für spekulatives Decoding und auf Batch-1 optimiertes Serving aus. Und auch das fehlt: „Abhängigkeit von einem Anbieter vermeiden“. Die Gewichte, die du heute herunterlädst, sind innerhalb eines Jahres zwei Generationen hinter dem Stand, und du stehst wieder vor derselben Entscheidung. Das ist übrigens ein gutes Argument für den Archivierungsinstinkt, den manche Praktiker haben: lokale Kopien wichtiger Gewichtsreleases aufzubewahren. Speicher ist billig, Optionen sind wertvoll.

Ehrlich betrachtet sind Open Weights und APIs eher Ergänzungen als Konkurrenten. Mehrere Teams, die ich kenne, fahren einen Hybridbetrieb: die API für schubweisen interaktiven Traffic, lokale Gewichte für den regulierten oder batchlastigen Anteil. Die Fähigkeiten übertragen sich – deine vLLM-Konfiguration, dein Eval-Harness und deine Prompt-Templates funktionieren in beiden Welten. Wenn du die operativen Grundlagen lernen willst, bevor du dich auf Frontier-Maßstab festlegst, deckt unser Leitfaden zum lokalen Betrieb großer Sprachmodelle auf eigener Hardware den gesamten Serving-Stack ab.

Fehler 5: Mit Benchmarks statt mit dem eigenen Workload evaluieren

Der letzte Fehler ist der, der alle anderen wieder zunichtemacht. Ein Team macht alles richtig – Lizenz geprüft, Hardware dimensioniert, Quantisierung an öffentlichen Benchmarks getestet – und liefert dann ein Modell aus, das Nutzer hassen, weil die Evals nie gemessen haben, was die Nutzer tatsächlich tun.

Öffentliche Benchmarks beantworten die Frage „Ist dieses Modell generell leistungsfähig?“. Sie beantworten nicht: „Klassifiziert dieses Modell unsere Support-Tickets mit dem Ton und Format, das wir brauchen, in 4 Bit, unter unserer Parallelitätslast?“ Wir haben bereits darüber geschrieben, warum KI-Benchmarks 90 % der realen Arbeit verfehlen, und Self-Hosting macht die Lücke schärfer, nicht weicher: Du bist jetzt für jede Variable verantwortlich, die der API-Anbieter früher verwaltet hat. Der Deployment-Stack, die Sampler-Einstellungen, die Konventionen für Systemprompts, mit denen das Modell trainiert wurde – alles liegt bei dir, und alles kannst du falsch machen.

Die Lösung ist ein dreistufiges Eval, das du bevor du dich auf Hardware festlegst aufbaust:

1. Ein Golden Set aus der Produktion. Einige hundert echte Prompts mit geprüften Idealantworten, die deine tatsächliche Aufgabenverteilung abdecken – inklusive der langen, unordentlichen, mehrstufigen Fälle.
2. Ein Regressions-Harness. Jeder Kandidat (API vs. lokal, FP8 vs. 4 Bit, alte Gewichte vs. neues Release) läuft automatisch durch das Golden Set. Bewerte mit einem starken Judge-Modell plus stichprobenartiger menschlicher Prüfung; vertraue dem Judge bei strukturierten Ausgaben nicht blind.
3. Eine Schattenphase. Betreibe das lokale Deployment zwei Wochen lang parallel zur API auf dem Live-Traffic, vergleiche die Ausgaben und miss die reale Latenz unter realer Last. Genau hier kommen die Fehler bei der KV-Cache-Dimensionierung und die Ausreißer der Quantisierung tatsächlich zum Vorschein.

Dieses Harness zahlt sich beim ersten neuen Gewichtsrelease aus, denn dann kannst du „Sollen wir upgraden?“ innerhalb eines Nachmittags mit Daten beantworten statt in einer Besprechung mit Bauchgefühl.

Die eigentliche Lehre: Open Weights haben die Frage verändert, nicht die Antwort

Vor einem Jahr war „Sollen wir ein Frontier-Modell selbst hosten?“ eine Hypothese – die Frontier war nicht herunterladbar. Mistral Large 4 hat zusammen mit der Welle anderer Billionen-Parameter-Releases daraus eine reale Entscheidung mit echtem Geld gemacht. Der Entscheidungsrahmen hat sich aber nicht geändert; er ist nur verpflichtend geworden.

Betreibe selbst, wenn Souveränität, Konnektivität, dauerhaftes Volumen oder der Bedarf, das Modell zu verändern, es verlangen. Zahl für die API, wenn dein Traffic schubweise ist, dein Team klein ist und dein Differenzierungsmerkmal das Produkt und nicht der Inferenz-Stack ist. Und was du auch wählst: Mach die Speicher-Rechnung in neunzig Sekunden, lies die Lizenz und bau das Eval-Harness, bevor du irgendetwas unterschreibst. Die Gewichte sind jetzt offen. Die Fehler leider auch.