Welches LLM selbst hosten? Modelle und Lizenzen

Modell, Runtime und GPU anhand echter Aufgaben auswählen? WZ-IT vergleicht konkrete Modellversionen mit Ihrem Testsatz, prüft Lizenzen und dimensioniert Inferenz, Parallelität und Betrieb gemeinsam. GPU-Server und Modellbetrieb ansehen

„Welches LLM soll ich selbst hosten?" lässt sich nicht über eine Rangliste beantworten. Ein produktives Modell muss konkrete Aufgaben in den benötigten Sprachen lösen, auf der vorgesehenen Runtime stabil laufen, rechtlich nutzbar sein und unter realer Parallelität wirtschaftlich bleiben. Dieser Artikel zeigt einen reproduzierbaren Auswahlprozess. Stand August 2026.

Inhaltsverzeichnis

• Nicht "das beste" Modell, sondern das passende
• Modellgröße nach Anwendungsfall
• Die Lizenz entscheidet mit
• Offene Modellfamilien im Überblick
• Wie man das Modell auswählt
• Welche Fähigkeiten wirklich getestet werden
• VRAM, Kontext und Parallelität
• Vom Modelltest zum sicheren Betrieb
• Wie WZ-IT die Auswahl und den Betrieb umsetzt
• Quellen

Nicht "das beste" Modell, sondern das passende

Ranglisten und Benchmarks verleiten dazu, immer das größte, neueste Modell wählen zu wollen. Für den produktiven Betrieb ist das selten die richtige Entscheidung. Ein Modell, das eine klar umrissene Aufgabe zuverlässig löst und auf der vorhandenen GPU läuft, ist wertvoller als ein Spitzenmodell, das die Hardware sprengt oder dessen Lizenz den Einsatz einschränkt.

Die Wahl fällt entlang mehrerer Achsen: Aufgabenqualität, Sprache, Lizenz, Kontext, Tool- und Ausgabeformate, Hardware, Parallelität, Latenz und Betriebsreife. Ein Modell kann im Chat überzeugen und dennoch für zuverlässige JSON-Ausgaben, deutsche Fachtexte oder hohe Gleichzeitigkeit ungeeignet sein.

Modellgröße nach Anwendungsfall

Die Parameterzahl ist der wichtigste Hebel für Hardware-Bedarf und Fähigkeit. Die Faustregel: so groß wie nötig, nicht so groß wie möglich.

• Kleinere Modelle (einstelliger Milliarden-Bereich) reichen für klar umrissene Aufgaben - Klassifikation, einfache Zusammenfassungen, strukturierte Extraktion - und laufen auf bescheidener Hardware.
• Mittlere Modelle decken einen breiten Alltag ab: Wissensabruf per RAG, Entwürfe, Assistenzfunktionen.
• Große Modelle bringen die breitesten Fähigkeiten, verlangen aber deutlich mehr GPU-Speicher und rechnen langsamer.

Bei Mixture-of-Experts-Modellen ist pro Token oft nur ein Teil der Parameter aktiv. Die Gewichte müssen je nach Runtime und Verteilung dennoch gespeichert beziehungsweise über GPUs verteilt werden. „Aktive Parameter" sind deshalb keine vollständige VRAM-Angabe. Wie Gewichte, KV-Cache und Parallelität zusammenwirken, zeigt GPU und VRAM dimensionieren.

Die Lizenz entscheidet mit

Ein oft übersehener Punkt: Nicht jedes „offene" Modell ist unter denselben Bedingungen nutzbar. Geprüft wird die konkrete Repository- und Modellversion, nicht die Marke.

• Permissive Lizenzen wie Apache 2.0 oder MIT erlauben typischerweise breite kommerzielle Nutzung, enthalten aber weiterhin Bedingungen, etwa Lizenz- und Hinweistext. Konkrete Qwen-, Mistral- oder DeepSeek-Releases können darunter stehen.
• Community- und modellspezifische Lizenzen enthalten zusätzliche Bedingungen. Metas Llama-Lizenz umfasst unter anderem Namensnennung, Acceptable Use und besondere Bedingungen ab einer sehr großen Nutzerzahl.
• Innerhalb einer Familie können Bedingungen wechseln. Mistral veröffentlicht beispielsweise Modelle unter Apache 2.0, andere konkrete Releases aber unter einer eigenen kommerziell relevanten Lizenz. Auch bei Gemma gelten eigene Nutzungsbedingungen.

Zusätzlich sind Gewichtungen, Inferenzcode, Tokenizer, Fine-Tunes und Datensätze getrennt zu betrachten. Eine permissive Modelllizenz ist oft einfacher, aber kein Freibrief und keine Aussage über Datenschutz oder Ergebnisqualität.

Offene Modellfamilien im Überblick

Modellfamilien eignen sich zur Marktübersicht, die Freigabe erfolgt aber immer für eine konkrete Version:

• Qwen - breites Spektrum an Größen und Fähigkeiten; konkrete Releases können beispielsweise Apache 2.0 verwenden.
• Mistral - europäischer Anbieter mit kompakten und größeren Modellen; die Lizenz variiert je Release.
• DeepSeek - Modelle mit Schwerpunkt auf allgemeinen, Reasoning- und Code-Aufgaben; konkrete Lizenz prüfen.
• Llama - verbreitetes Ökosystem und breite Runtime-Unterstützung unter einer eigenen Community-Lizenz.
• Gemma - Modellfamilie von Google unter eigenen Nutzungsbedingungen.

Die Liste ist keine Qualitätsrangfolge. Neue Versionen erscheinen schnell, und ein Modellname sagt wenig über deutsche Fachsprache, strukturierte Ausgabe oder die Qualität im eigenen Dokumentenbestand.

Wie man das Modell auswählt

Ein pragmatischer Weg in vier Schritten:

1. Aufgaben und Ausschlusskriterien definieren - erwartete Antwort, unzulässige Fehler und erforderliche Sprachen festlegen.
2. Kandidaten vorfiltern - Lizenz, Kontext, Runtime-Unterstützung, Modellkarte und Hardwaregrenze prüfen.
3. Eigenen Testsatz erstellen - 30 bis 100 repräsentative Fälle einschließlich schwieriger und unerwünschter Eingaben.
4. End-to-End messen - Modell zusammen mit Prompt, RAG, Tools und Ausgabevalidierung testen.
5. Betrieb testen - Parallelität, Lastspitze, Fehler, Update und Rollback einbeziehen.
6. Freigabe dokumentieren - Modell-ID, Hash oder Version, Lizenzstand, Quantisierung, Runtime und Messergebnisse festhalten.

Welche Fähigkeiten wirklich getestet werden

Ein sinnvoller Evaluationsbogen trennt:

„Größer" gewinnt nicht automatisch. Ein kleineres, spezialisiertes Modell kann bei enger Aufgabe schneller, günstiger und stabiler sein.

VRAM, Kontext und Parallelität

Der Speicherbedarf besteht aus Modellgewichten, Runtime-Overhead und KV-Cache. Der KV-Cache wächst mit Kontextlänge und gleichzeitigen Anfragen. Ollama weist darauf hin, dass die Speicheranforderung mit Parallelität mal Kontextlänge skaliert. Eine Konfiguration, die bei einer Anfrage passt, kann deshalb unter vier parallelen Nutzern überlasten.

Quantisierung reduziert den Bedarf, kann aber Qualität und unterstützte Operationen beeinflussen. Gemessen wird daher die exakte Kombination aus Modell, Quantisierung, Runtime, Kontext und Parallelität. Für einen produktiven Dienst zählen außerdem Wartungsreserve und die Frage, ob beim Update zwei Versionen kurz parallel geladen werden müssen.

Vom Modelltest zum sicheren Betrieb

Ein freigegebenes Modell bleibt versioniert. Neue Releases ersetzen nicht automatisch den laufenden Stand. Zuerst laufen Regressionstests, danach ein begrenzter Rollout und erst dann die Umschaltung. Gateway-Aliase verhindern, dass Anwendungen fest an einen Modellnamen gekoppelt werden. Monitoring erfasst Qualität, Latenz und Fehler, ohne ungeprüft sensible Prompts dauerhaft zu speichern.

Mehrere Modelle können sinnvoll sein: ein kleines Modell für Extraktion, ein stärkeres für komplexe Entwürfe und ein separates Embedding-Modell. Über LiteLLM lassen sich Routing, Limits und Fallbacks zentralisieren. Wo diese Komponenten im Gesamtbild sitzen, zeigt Was ist lokale KI?.

Wie WZ-IT die Auswahl und den Betrieb umsetzt

WZ-IT verbindet Modellvergleich mit Infrastruktur. Wir bauen einen Testsatz aus den vorgesehenen Aufgaben, prüfen konkrete Modelllizenzen, messen Qualität und Last und dimensionieren darauf GPU-Server oder LLM-Hosting. Im Managed-AI-Betrieb kommen Versionierung, Gateway, Monitoring, Updates, Backup und Rollback hinzu.

Damit wird nicht das Modell mit dem besten öffentlichen Score beschafft, sondern die kleinste belastbare Kombination, die Qualitäts- und Betriebsziele erfüllt und später austauschbar bleibt.

Quellen

• Qwen: Beispiel einer konkreten Apache-2.0-Modelllizenz
• Mistral: Mistral 7B v0.3 mit Apache-2.0-Angabe
• Mistral: Beispiel einer abweichenden modellspezifischen Lizenz
• Meta: Llama Community License
• Google: Gemma Terms of Use
• Ollama-Dokumentation: Kontext, Parallelität und Speicher