Open-Weight-Modelle für echte Datensouveränität: Llama 4, Qwen 3, Mistral

Noch vor zwei Jahren war die Sache klar: Wer ernsthafte KI-Leistung wollte, mietete sie als API bei einem der großen US-Anbieter. Frei verfügbare Modelle galten als nette Spielwiese, aber nicht als Produktivlösung. 2026 hat sich dieses Bild gedreht. Offene Modelle mit frei zugänglichen Gewichten haben die Leistungslücke zu den proprietären Frontier-Systemen so weit geschlossen, dass sie für den Großteil der betrieblichen Aufgaben eine vollwertige Alternative sind – und das mit dem entscheidenden Vorteil, dass sie vollständig auf der eigenen Infrastruktur laufen.

Für den Mittelstand mit Datenschutzanforderungen, Geschäftsgeheimnissen oder schlicht dem Wunsch nach planbaren Kosten ist das ein Paradigmenwechsel. Dieser Artikel ordnet die wichtigsten Modelle ein – Llama 4, Qwen 3 und Mistral Large 3 –, erklärt die Architektur dahinter und zeigt, welcher Serving-Stack zu welchem Workload passt.

Die Open-Weight-Landschaft 2026

Drei Modellfamilien dominieren 2026 den Markt der frei verfügbaren Gewichte. Sie unterscheiden sich erheblich in Architektur, Lizenz und Hardware-Profil – und genau diese Unterschiede entscheiden darüber, welches Modell für welchen Anwendungsfall geeignet ist.

Llama 4 Scout und Maverick

Metas Llama-4-Generation setzt durchgängig auf eine Mixture-of-Experts-Architektur. Llama 4 Scout aktiviert rund 17 Milliarden Parameter pro Token bei einer Gesamtkapazität von etwa 109 Milliarden Parametern. Das herausragende Merkmal ist das Kontextfenster: Mit bis zu 10 Millionen Token Long-Context-Fähigkeit verschiebt Scout die Grenze dessen, was an einem Stück verarbeitet werden kann, deutlich nach oben. Dank Int4-Quantisierung lässt sich das Modell auf einer einzelnen H100-GPU betreiben.

Llama 4 Maverick teilt sich die rund 17 Milliarden aktiven Parameter, schöpft aber aus einem deutlich größeren Pool von etwa 400 Milliarden Gesamtparametern. In multimodalen Benchmarks – also bei Aufgaben, die Text und Bild kombinieren – schlägt Maverick laut Metas eigenen Veröffentlichungen GPT-4o. Das ist bemerkenswert, weil es zeigt, dass offene Gewichte nicht mehr nur „fast so gut" sind, sondern in einzelnen Disziplinen die Referenz übertreffen.

Qwen 3

Die Qwen-3-Familie von Alibaba bietet ein breites Spektrum an Modellgrößen, von kompakten Dense-Modellen bis zu MoE-Varianten. Die Open-Weight-Versionen liegen typischerweise nur etwa 5 bis 10 Prozent hinter den proprietären Top-Versionen – ein Abstand, der in der Praxis für die meisten Geschäftsaufgaben kaum spürbar ist. Qwen 3 glänzt besonders bei mehrsprachigen Aufgaben und im Coding, was es zu einer beliebten Basis für fine-getunte Spezialmodelle macht.

Mistral Large 3

Für europäische Unternehmen besonders relevant: Mistral Large 3 stammt aus Frankreich und steht unter der freizügigen Apache-2.0-Lizenz. Das bedeutet kommerzielle Nutzung ohne Lizenzgebühren und ohne die Nutzungsbeschränkungen, die manche andere Modelllizenzen mitbringen. Die EU-Herkunft ist nicht nur ein Marketing-Argument, sondern erleichtert die rechtliche Bewertung im Rahmen von DSGVO und EU AI Act erheblich.

MoE: Warum aktive Parameter zählen

Der wichtigste Begriff, um die Llama-4- und Qwen-3-Modelle zu verstehen, ist Mixture-of-Experts (MoE). Wer nur auf die Gesamtparameterzahl schaut, zieht falsche Schlüsse über den tatsächlichen Hardware-Bedarf.

Das Prinzip: nur ein Teil arbeitet mit

In einem klassischen Dense-Modell durchläuft jedes Token sämtliche Parameter. Ein MoE-Modell ist stattdessen in viele spezialisierte „Experten" unterteilt. Ein Routing-Mechanismus wählt für jedes Token nur einen kleinen Teil dieser Experten aus. Bei Llama 4 Scout werden so von 109 Milliarden Gesamtparametern nur rund 17 Milliarden pro Token tatsächlich aktiviert.

Der praktische Effekt: Die Rechenlast pro Token richtet sich nach den aktiven Parametern, nicht nach der Gesamtzahl. Sie erhalten also die Wissenskapazität eines sehr großen Modells, zahlen aber bei der Inferenz nur für einen Bruchteil davon. Das ist der Grund, warum große Modelle überhaupt auf Enterprise-Hardware budgetierbar werden.

Was das für die Praxis bedeutet

• Geringere Rechenlast bei großer Kapazität: Ein MoE-Modell mit 109B Gesamt- und 17B aktiven Parametern rechnet pro Token ungefähr so schnell wie ein 17B-Dense-Modell, „weiß" aber deutlich mehr.
• Budgetierbarkeit: Die Inferenzkosten skalieren mit den aktiven Parametern – das macht große Modelle für den Mittelstand erst zugänglich.
• VRAM bleibt die Hürde: Im Speicher müssen weiterhin alle Experten vorgehalten werden. Hier setzt Expert-Offloading an, das selten genutzte Experten in den Hauptspeicher auslagert und VRAM-Spitzen reduziert.

Hardware- und VRAM-Planung

Die zentrale Frage bei jedem On-Premise-Projekt lautet: Welche GPU brauche ich? Die Antwort hängt an drei Faktoren – den aktiven Parametern, der Kontextlänge und dem KV-Cache.

Quantisierung als Türöffner

Quantisierung reduziert die Präzision der Modellgewichte, etwa von 16 auf 4 Bit. Das senkt den Speicherbedarf drastisch, bei modernen Verfahren mit nur geringem Qualitätsverlust. Erst durch Int4-Quantisierung passt Llama 4 Scout überhaupt auf eine einzelne H100. Für viele mittelständische Szenarien ist die quantisierte Variante die wirtschaftlich einzig sinnvolle Wahl – und qualitativ vollkommen ausreichend.

Der KV-Cache wächst mit dem Kontext

Ein oft unterschätzter Posten ist der KV-Cache (Key-Value-Cache). Er speichert Zwischenergebnisse für jedes bereits verarbeitete Token und wächst linear mit der Kontextlänge. Gerade bei Long-Context-Workloads – Scout kann theoretisch 10 Millionen Token verarbeiten – kann der KV-Cache mehr VRAM beanspruchen als das Modell selbst. KV-Cache-Quantisierung verkleinert diesen Posten und entlastet Long-Context-Anwendungen spürbar.

Blackwell verbessert die Effizienz

Mit NVIDIAs Blackwell-Generation verbessert sich vor allem die Energieeffizienz: Die Tokens-per-Watt steigen deutlich gegenüber der vorherigen Hopper-Generation (H100). Für den Dauerbetrieb eines KI-Systems sind das relevante Betriebskosten – bei steigenden Strompreisen oft der größte laufende Posten überhaupt.

Modell	Aktiv / Gesamt	Kontext	Typischer GPU-Bedarf
Llama 4 Scout	~17B / ~109B (MoE)	bis 10M Token	1× H100 mit Int4
Llama 4 Maverick	~17B / ~400B (MoE)	~1M Token	Multi-GPU-Node
Qwen 3	Dense + MoE-Varianten	bis ~256K Token	1–4 GPUs je nach Größe
Mistral Large 3	Dense (Apache 2.0)	~128K Token	Multi-GPU-Node

Die Zahlen sind als Orientierungswerte zu verstehen – der reale Bedarf hängt immer vom konkreten Workload ab. Wir helfen bei der Auslegung im Rahmen unseres KI-Full-Stack-Providings, von der GPU-Auswahl bis zur fertigen Inferenz-Plattform.

Serving-Stack: vLLM vs. SGLang

Ein Modell herunterzuladen ist trivial. Es so zu betreiben, dass es viele gleichzeitige Anfragen mit guter Latenz und hoher GPU-Auslastung bedient, ist die eigentliche Ingenieursaufgabe. Hier kommt der Model-Serving-Stack ins Spiel.

vLLM – der Durchsatz-Champion

vLLM hat sich als De-facto-Standard für hochskalierende Inferenz etabliert. Sein Kernmerkmal ist PagedAttention, eine speichereffiziente Verwaltung des KV-Cache, kombiniert mit Continuous Batching. Damit lassen sich viele Anfragen parallel verarbeiten, ohne dass die GPU auf langsame Einzelanfragen warten muss. Für klassische Inferenz mit hohem Anfragevolumen – etwa einen Chatbot mit vielen gleichzeitigen Nutzern – ist vLLM die erste Wahl.

SGLang – stark bei RAG und Dialog

SGLang ist auf Workloads optimiert, bei denen sich Teile des Kontexts zwischen Anfragen wiederholen. Durch RadixAttention werden gemeinsame Präfixe im KV-Cache wiederverwendet. Genau das ist der Fall bei RAG-Anwendungen mit immer ähnlichem System-Prompt und bei Multi-Turn-Dialogen, in denen die Konversationshistorie mitwächst. Hier kann SGLang spürbar effizienter sein als ein generischer Serving-Stack.

TGI tritt in den Hintergrund

Text Generation Inference (TGI) war lange ein verbreiteter Serving-Stack, wird 2026 aber schrittweise depreciert. Für Neuprojekte empfiehlt sich daher der direkte Einstieg mit vLLM oder SGLang, um nicht auf eine auslaufende Technologie zu setzen.

Datensouveränität und Lock-in

Der eigentliche strategische Wert offener Gewichte liegt nicht in der Lizenzersparnis, sondern in der Kontrolle. Wer auf eine einzelne API angewiesen ist, hängt von deren Preisgestaltung, Verfügbarkeit, Nutzungsbedingungen und Modellversionen ab – allesamt Faktoren, die der Anbieter jederzeit ändern kann.

DSGVO by Design

Wenn das Modell auf Ihrer eigenen Infrastruktur läuft, verlassen die verarbeiteten Daten Ihr Unternehmen schlicht nicht. Damit entfällt die gesamte rechtliche Konstruktion aus Auftragsverarbeitungsverträgen, Drittlandtransfers und Standardvertragsklauseln, die Cloud-KI mit sich bringt. Das ist Datenschutz nicht als nachträgliche Maßnahme, sondern als Eigenschaft der Architektur – DSGVO by Design.

Unabhängigkeit und Wahlfreiheit

• Keine Anbieterabhängigkeit: Offene Gewichte eliminieren die Abhängigkeit von einem einzelnen API-Anbieter. Fällt ein Modell weg oder ändert sich die Lizenz, wechseln Sie das Modell, nicht die gesamte Plattform.
• Fine-getunte Vielfalt: Für die etablierten offenen Basismodelle existieren Hunderte fine-getunte Varianten – für Recht, Medizin, Coding oder einzelne Sprachen. Sie können das Modell wählen, das exakt zu Ihrer Domäne passt.
• Modellwechsel ohne Migration: Da das Serving über standardisierte Schnittstellen läuft, lässt sich ein Modell gegen ein anderes austauschen, ohne die umgebende Anwendung neu zu bauen.

Für Unternehmen, die ihre KI langfristig strategisch verankern wollen, ist diese Unabhängigkeit oft mehr wert als die letzten paar Prozentpunkte Benchmark-Leistung. Eine fundierte Gegenüberstellung der Optionen liefert unser KI-Modellvergleich.

Leistungs-Gap realistisch einordnen

Die berechtigte Frage lautet: Wenn offene Modelle so gut sind, warum gibt es überhaupt noch proprietäre Frontier-Systeme? Die ehrliche Antwort: Auf den anspruchsvollsten Benchmarks liegen die offenen Modelle weiterhin etwa 5 bis 10 Prozent zurück. Entscheidend ist aber, wie relevant dieser Abstand in der Praxis ist.

Wann der Abstand spürbar ist – und wann nicht

Für die allermeisten Geschäftsaufgaben – Dokumente zusammenfassen, E-Mails entwerfen, interne Wissensfragen beantworten, strukturierte Daten extrahieren – ist ein Unterschied von 5 bis 10 Prozent praktisch nicht wahrnehmbar. Spürbar wird er erst an den Rändern: bei sehr komplexen mehrstufigen Reasoning-Aufgaben oder spezialisierten Coding-Problemen.

Fine-Tuning schließt die Lücke

Hier kommt ein oft übersehener Hebel ins Spiel: Ein auf Ihre Domänendaten fine-getuntes offenes Modell übertrifft auf Ihren spezifischen Aufgaben häufig ein generisches Frontier-Modell. Das allgemeine Modell weiß viel über alles – das spezialisierte Modell weiß genau das, was Sie brauchen. Diese Anpassbarkeit ist ein struktureller Vorteil offener Gewichte, den eine geschlossene API gar nicht bieten kann.

Der ROI verschiebt sich

Hinzu kommt die Wirtschaftlichkeit. Nach der Hardware-Investition sind die Grenzkosten pro Anfrage bei Self-Hosting nahezu null. Wer hohe Anfragevolumina hat, erreicht den Break-even gegenüber API-Kosten oft binnen Monaten. Damit verschiebt sich die Rechnung: Selbst wenn ein offenes Modell minimal schwächer ist, kann es über die Gesamtkosten betrachtet die klar bessere Entscheidung sein.

Auswahl- und Einstiegs-Strategie

Der Weg zum produktiven Open-Weight-Setup lässt sich in vier klare Schritte gliedern. Die Reihenfolge ist wichtig: Wer mit der Modellgröße statt mit dem Use Case beginnt, überdimensioniert fast immer.

1. Use Case definieren: Klären Sie zuerst, worum es geht – freier Chat, RAG-gestützte Wissensfragen, Coding-Assistenz oder multimodale Auswertung von Text und Bild. Jedes Profil stellt andere Anforderungen an Modell und Serving.
2. Modellgröße an GPU und Latenzziel ausrichten: Wählen Sie das Modell nach der verfügbaren Hardware und Ihrem Latenzziel, nicht nach dem größtmöglichen Benchmark-Wert. Ein MoE-Modell wie Scout liefert auf einer H100 ein hervorragendes Verhältnis aus Kapazität und Kosten.
3. Mit quantisierter Variante starten: Beginnen Sie mit einer Int4-Variante. Sie ist günstiger im Betrieb und qualitativ meist ausreichend. Optimieren können Sie später gezielt dort, wo die Qualität wirklich knapp wird.
4. Serving-Stack zum Workload wählen: vLLM für durchsatzlastige, klassische Inferenz; SGLang für RAG und Multi-Turn-Dialoge. Setzen Sie nicht auf TGI, das auslaufende Technologie ist.

Ob Sie ein schlüsselfertiges KI-System bevorzugen oder den gesamten Stack als Managed Service beziehen möchten – beide Wege führen zu einer souveränen, auf Ihre Anforderungen zugeschnittenen Lösung. Wichtig ist, mit einem klar umrissenen ersten Use Case zu starten und von dort zu skalieren.

Eine ergänzende Perspektive auf die Speicherformate für Self-Hosting bietet das Stichwort GGUF, das insbesondere für CPU- und Hybrid-Inferenz relevant ist. Welcher Weg für Ihr Unternehmen der richtige ist, klären wir am besten im direkten Gespräch.

Häufig gestellte Fragen zu Open-Weight-Modellen

Was bedeutet Open-Weight im Unterschied zu Open Source?

Open-Weight heißt, dass die trainierten Modellgewichte frei verfügbar und self-hostbar sind. Der Trainingscode oder die Daten sind nicht zwingend offen. Für Datensouveränität ist entscheidend, dass das Modell lokal laufen kann.

Reicht eine einzelne GPU für Llama 4 Scout?

Mit Int4-Quantisierung passt Llama 4 Scout auf eine einzelne H100. Der tatsächliche VRAM-Bedarf hängt zusätzlich von der genutzten Kontextlänge und dem KV-Cache ab.

Wie groß ist der Leistungsabstand zu GPT-5 oder Claude?

Auf vielen Benchmarks liegen Open-Weight-Modelle nur etwa 5–10% zurück, für die meisten Geschäftsaufgaben praktisch nicht spürbar. Fine-Tuning auf eigene Domänendaten schließt die Lücke oft weiter.

vLLM oder SGLang – was soll ich nehmen?

vLLM glänzt bei hohem Batch-Durchsatz und klassischer Inferenz, SGLang bei RAG und Multi-Turn-Dialogen. Die Wahl richtet sich nach Ihrem Workload.