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 Oktober 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. Metas neueres Modell Muse Glimmer 30B steht dagegen unter Apache 2.0.
- 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. Bei Gemma steht Gemma 4 unter Apache 2.0, Gemma 1 bis 3 unter den Gemma Terms of Use.
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. Die Bedingungen einzelner Modelle vergleicht LLM-Lizenzen für kommerzielle Nutzung.
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; die Lizenz variiert je Release. Qwen3.8-27B (August 2026) ist ein dichtes Modell mit 27 Mrd. Parametern für Text, Bild und Video unter Apache 2.0, Qwen3.8-Flash-Next steht dagegen unter der Qwen Community License.
- 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; die V4-Modelle stehen unter MIT.
- Meta - Llama 4 mit verbreitetem Ökosystem und breiter Runtime-Unterstützung unter einer eigenen Community-Lizenz. Muse Glimmer 30B (August 2026) steht unter Apache 2.0, verarbeitet Text und Bild und ist laut Modellkarte in 4 Bit für GPUs mit 24 GB ausgelegt.
- Gemma - Modellfamilie von Google; Gemma 4 unter Apache 2.0, ältere Versionen unter den Gemma Terms of Use.
- Granite - IBM Granite 4.2 (August 2026) in 3B, 8B und 30B unter Apache 2.0, dichte Textmodelle.
- Kolibri - Aleph Alpha Kolibri-1 (Oktober 2026) unter Apache 2.0, ein Mixture-of-Experts-Modell für Deutsch und Englisch mit laut Modellkarte 78,1 Mrd. Parametern, davon 3,46 Mrd. aktiv.
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. Welche konkreten Modelle auf 24 GB, 96 GB oder 128 GB passen, vergleicht der Beitrag Llama 4 vs. Qwen 3.5 vs. DeepSeek V4.
Wie man das Modell auswählt
Ein pragmatischer Weg in sechs Schritten:
- Aufgaben und Ausschlusskriterien definieren - erwartete Antwort, unzulässige Fehler und erforderliche Sprachen festlegen.
- Kandidaten vorfiltern - Lizenz, Kontext, Runtime-Unterstützung, Modellkarte und Hardwaregrenze prüfen.
- Eigenen Testsatz erstellen - 30 bis 100 repräsentative Fälle einschließlich schwieriger und unerwünschter Eingaben.
- End-to-End messen - Modell zusammen mit Prompt, RAG, Tools und Ausgabevalidierung testen.
- Betrieb testen - Parallelität, Lastspitze, Fehler, Update und Rollback einbeziehen.
- Freigabe dokumentieren - Modell-ID, Hash oder Version, Lizenzstand, Quantisierung, Runtime und Messergebnisse festhalten.
Welche Fähigkeiten wirklich getestet werden
Ein sinnvoller Evaluationsbogen trennt:
| Dimension | Beispielmessung |
|---|---|
| Fachliche Richtigkeit | erwartete Kernaussagen und verbotene Erfindungen |
| Deutsch und Mehrsprachigkeit | Terminologie, Ton, Übersetzung und gemischte Eingaben |
| RAG und Quellenbindung | Antwort nur aus bereitgestellten Belegen, korrekte Zitate |
| Strukturierte Ausgabe | valides JSON gegen ein Schema, stabile Feldbelegung |
| Tool Calling | richtiges Tool, richtige Parameter, keine Aktion ohne Freigabe |
| Sicherheit | Prompt-Injection, Geheimnisabfluss und unzulässige Systembefehle |
| Betrieb | Zeit bis zum ersten Token, Gesamtlatenz, Durchsatz und Fehlerrate |
„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
- Meta: Muse Glimmer 30B, Model Card (Apache 2.0)
- Qwen: Qwen3.8-27B, Model Card
- IBM: Granite 4.2 30B, Model Card
- Aleph Alpha: Kolibri-1, Model Card
- Google: Gemma 4 License
- Google: Gemma Terms of Use
- Ollama-Dokumentation: Kontext, Parallelität und Speicher










