Was ist ein Open-Source-LLM?

Ein Open-Source-LLM (Open-Source Large Language Model) ist ein großes Sprachmodell, dessen Modellgewichte öffentlich verfügbar sind und unter einer Lizenz stehen, die zumindest Forschung und meistens kommerzielle Nutzung erlaubt. Streng terminologisch unterscheiden Forschende zwischen Open Source (offene Gewichte plus offener Trainings-Code plus offene Trainings-Daten) und dem häufiger anzutreffenden Open-Weight-Modell, bei dem nur die Gewichte veröffentlicht sind, Trainings-Daten und teilweise Trainings-Code aber proprietär bleiben. Im Sprachgebrauch der KI-Praxis werden beide Begriffe oft synonym verwendet, obwohl die Unterscheidung wichtig ist: Echtes Open Source — wie es etwa bei Allen AIs OLMo oder dem Pythia-Projekt umgesetzt ist — ermöglicht vollständige Reproduzierbarkeit. Open-Weight-Modelle wie Llama 3, Mistral oder Qwen erlauben Self-Hosting, Fine-Tuning und Audit der Gewichte, lassen aber die Trainings-Daten unzugänglich. Für die Mehrzahl produktiver Anwendungen genügt Open-Weight: Self-Hosting, Reproduzierbarkeit auf Inferenz-Ebene und Souveränität sind damit erreichbar. Echtes Open Source ist primär für Forschung relevant, wo Trainings-Methodik selbst Forschungsgegenstand ist.

Die produktiv tragfähige Auswahl in 2026 deckt mehrere Größen- und Spezialisierungs-Stufen ab. Llama 3.3 70B von Meta liefert in MMLU, GSM8K und HumanEval Performance auf GPT-4-Niveau (Stand 2024) und steht unter der Llama Custom Community License — kommerzielle Nutzung erlaubt, mit Schwellen für sehr große Anwender. Mistral Large 2 (123B Parameter, Apache 2.0 für die kommerzielle Nutzung) ist die führende europäische Alternative. Aus Deutschland kommt Teuken-7B, ein Modell des OpenGPT-X-Konsortiums (Apache 2.0), das gezielt auf europäischen Sprachen trainiert wurde — vom BMBF gefördert und mit explizitem Fokus auf Souveränität. Qwen 2.5 von Alibaba ist mit Apache 2.0 ausgestattet und besonders stark in mehrsprachigen Aufgaben (CJK plus Englisch). DeepSeek-V3 und R1 haben 2025 für Aufmerksamkeit gesorgt, weil sie Reasoning-Performance auf höchstem Niveau zu vergleichsweise niedrigen Inferenz-Kosten liefern. Für spezielle Anwendungen: Phi-3.5 von Microsoft (MIT-Lizenz, kompakt 3,8B Parameter) für Edge-Inferenz; Qwen 2.5-Coder und DeepSeek-Coder für Code-Generierung; BioMistral und MedLlama für medizinische Texte. Die Auswahl wächst monatlich, die produktive Reife ist erreicht.

Die Lizenz-Landschaft bei Open-Weight-Modellen ist heterogen und verlangt vor produktivem Einsatz eine Prüfung. Die liberalen Lizenzen Apache 2.0, MIT und BSD-3 erlauben uneingeschränkte kommerzielle Nutzung, Modifikation und Re-Distribution — Mistral, Qwen 2.5 (für die meisten Größen), Phi-3, Falcon und einige Olmo-Varianten stehen darunter. Die Llama Custom Community License erlaubt kommerzielle Nutzung grundsätzlich, enthält aber zwei Einschränkungen: Eine Acceptable-Use-Policy verbietet bestimmte Anwendungsbereiche (Waffenentwicklung, Massenüberwachung, illegale Inhalte). Außerdem greift bei Anbietern mit über 700 Millionen monatlichen Nutzern eine separate Verhandlungspflicht — relevant nur für sehr große Plattformen. Eingeschränkte Forschungs-Lizenzen — etwa bei den ersten OPT-Modellen oder einigen frühen Llama-Versionen — erlauben nur akademische Nutzung und keinen kommerziellen Einsatz. Solche Modelle scheiden für produktive Use-Cases aus, sind aber für Forschungs-Setups akzeptabel. Vor produktivem Einsatz ist ein Lizenz-Audit empfehlenswert: Welche Klauseln gelten, sind Distribution und Fine-Tuning unter den Bedingungen abgedeckt, gibt es Schwellenwerte. Das Risiko liegt nicht primär in Bußgeldern, sondern in vertraglichen Konflikten beim späteren Verkauf, der Ausgliederung oder Lizenz-Compliance-Audit.

Hardware-Anforderungen skalieren mit Modellgröße und Quantisierung. Ein 7B-Modell läuft in INT8-Quantisierung auf einer einzelnen RTX 4090 oder einer A10-GPU — Hardware im Bereich 1.500 bis 5.000 Euro, betrieblich auch in Co-Location wirtschaftlich. Ein 70B-Modell benötigt in INT4-Quantisierung (AWQ oder GPTQ) etwa 40 GB GPU-Memory und läuft damit auf einer einzelnen H100 80GB oder zwei A100 40GB. In FP16 verdoppelt sich der Memory-Bedarf entsprechend. Inferenz-Engines bestimmen den Throughput. vLLM ist der breite Standard für produktive Anwendungen mit Continuous Batching und PagedAttention — auf einer H100 mit Llama-70B-INT4 typische Werte von 1.500 bis 3.000 Tokens pro Sekunde je nach Workload. SGLang ist für strukturierte Outputs (JSON-Schema, Constraint-Decoding) optimiert. TensorRT-LLM liefert die höchsten TPS-Werte auf NVIDIA-Hardware, ist engineering-aufwendiger. llama.cpp und Ollama sind die richtige Wahl für CPU-Inferenz oder Single-Node-Setups auf Apple-Silicon-Hardware. Quantisierungsverfahren zur Hardware-Reduktion: AWQ (Activation-aware Weight Quantization) und GPTQ erreichen INT4-Genauigkeit mit weniger als einem Prozent Performance-Verlust auf MMLU für 70B-Modelle. FP8-Quantisierung auf neuerer Hardware (H100, H200, B200) wird zunehmend Standard.

Für deutsche Unternehmen und Institutionen sind Open-Weight-Modelle in vier Szenarien klar überlegen. Erstens regulierte Workloads: Hochrisiko-KI nach EU AI Act verlangt Audit-Rechte und nachvollziehbare Modell-Provenienz, die Closed-API-Anbieter strukturell nicht gewähren. Open Weights erfüllen diese Anforderung von Natur aus. Zweitens vertrauliche Daten: Bei personenbezogenen oder geschäftskritischen Inhalten verbietet sich häufig der Versand an Drittstaats-APIs. Self-Hosting auf souveräner Infrastruktur löst diesen Konflikt sauber. Drittens hohes Inferenz-Volumen: Ab konstantem zweistelligem Millionen-Token-Volumen pro Monat wird selbst gehostete Inferenz wirtschaftlich gegenüber Pay-per-Token — eine H100 amortisiert sich bei mittlerer Auslastung in 12 bis 24 Monaten. Viertens Reproduzierbarkeit in Forschung und Audit: Ein Open-Weight-Modell mit Hash-fixiertem Snapshot lässt sich in einer Container-Konfiguration mitliefern. Studien und Compliance-Audits können Inferenzen Bit-für-Bit reproduzieren, was bei API-Modellen nach jedem Anbieter-Update unmöglich wird. Hybride Strategien sind in der Praxis üblich: Frontier-API für unkritische Aufgaben (Code-Assist, Marketing-Drafting), Open-Weight selbst gehostet für regulierte und vertrauliche Workloads. Eine OpenAI-kompatible Routing-Fassade vor verschiedenen Backends macht diese Aufteilung pro Anwendungsfall transparent.