Eigenbetrieb eines sLLM — Lohnt sich das wirklich? Kosten, Leistung und die echten Trade-offs

1. Warum der Eigenbetrieb eines sLLM verlockend erscheint

Zunächst zur Frage, warum sich so viele Organisationen für den Eigenbetrieb eines sLLM entscheiden. Die Gründe sind nicht von der Hand zu weisen — und in Teilen auch berechtigt.

1.1 Vollständige Kontrolle über sensible Daten

Das stärkste Argument ist die vollständige Datenkontrolle. Alle Prompts und Antworten bleiben innerhalb der eigenen Infrastruktur. Eine Datenweitergabe an externe Anbieter ist strukturell ausgeschlossen. Für Datenschutzbeauftragte und CISOs ist das ein eindeutiges Argument: „Unsere Daten verlassen das Haus nicht." In DSGVO-regulierten Umgebungen, insbesondere in Banken und Versicherungen, lässt sich damit jede Compliance-Prüfung einfacher bestehen.

Auch unter dem EU AI Act und den BSI C5-Anforderungen bietet der Eigenbetrieb einen klaren Vorteil: Verarbeitungsort, Verantwortlichkeit und Kontrollmechanismen liegen vollständig in der Hand der Organisation. Die meisten Sicherheitsbedenken gegenüber externen KI-Diensten entfallen strukturell.

1.2 Digitale Souveränität und langfristige Vermögensbildung

Das zweite Argument ist digitale Souveränität. Wer ein Modell auf eigenen Daten trainiert, schafft ein organisationales Asset, das unabhängig von Anbieterstrategien und Preisänderungen bleibt. Ein fein abgestimmtes Modell, das auf internen Dokumenten, Prozessen und Fachsprache basiert, kann zu einem strategischen Wettbewerbsvorteil werden — insbesondere in Branchen wie dem Gesundheitswesen oder der Finanzdienstleistung, wo proprietäres Fachwissen einen hohen Wert hat.

Für Organisationen, deren eigentlicher Auftrag der Aufbau domänenspezifischer KI-Fähigkeiten ist — etwa eine Forschungsbehörde oder ein Fachinformationsdienst — ist der Eigenbetrieb mehr als ein Mittel zum Zweck: Er ist das Ziel.

1.3 Domänenspezifische Anpassung

Das dritte Argument ist die Freiheit beim Fine-Tuning. Wer ein Modell auf eigenen Daten trainiert, kann es gezielt auf spezifische Aufgaben ausrichten — Vertragsanalyse, medizinische Dokumentation, regulatorische Berichterstattung. Die Erwartung: bessere Ergebnisse als mit einem generischen Modell, das nicht mit branchenspezifischen Quellen vertraut ist.

Alle drei Argumente haben ihre Berechtigung. Die eigentliche Frage ist, zu welchem Preis diese Vorteile erkauft werden — und ob sie sich in der Praxis wirklich realisieren lassen.

2. Die tatsächlichen Kosten — was Angebote verschweigen

Kostendiskussionen über sLLM-Eigenbetrieb beginnen häufig mit dem GPU-Server-Preis und enden dort. Die tatsächlichen Gesamtbetriebskosten (TCO, Total Cost of Ownership) liegen jedoch um ein Vielfaches höher. Auf fünf Jahre gerechnet ergibt sich folgendes Bild.

2.1 Die versteckten Initialkosten

Die häufige Annahme, dass „GPU-Server für 250.000–300.000 EUR" die gesamten Aufbaukosten abdecken, ist ein typischer Planungsfehler. Tatsächlich sind darüber hinaus erforderlich:

• Netzwerk- und Storage-Infrastruktur: Hochbandbreiten-Netzwerk-Switches, NVMe-Storage, Backup-Systeme
• Strom- und Kühlungskapazitäten: Acht H100-GPUs verbrauchen über 5 kW. Viele Rechenzentrumsumgebungen erfordern eine Nachrüstung der Kühlung und Stromversorgung.
• Sicherheitsinfrastruktur: Modellschutz, Zugriffssteuerung, Audit-Logging — gerade unter BSI C5 und DSGVO keine Optionen, sondern Pflicht.
• Personalkosten für den Initialaufbau: Die ersten drei bis sechs Monate erfordern dedizierte Ingenieurkapazitäten für Modellauswahl, Fine-Tuning und Infrastrukturaufbau.

2.2 Die eigentliche Kostentreiberin: Personal

Der größte Kostenfaktor beim sLLM-Eigenbetrieb sind nicht die GPUs, sondern qualifiziertes Personal. Für einen stabilen Betrieb werden mindestens folgende Rollen benötigt:

• MLOps-Engineer: Modell-Deployment, Betrieb, Monitoring
• KI-Engineer: Fine-Tuning, Leistungsoptimierung, Evaluation neuer Modelle
• Infrastruktur-Engineer: GPU-Server-Management, Incident Response

Das entspricht mindestens zwei, typischerweise drei bis vier Vollzeitstellen. In regulierten Branchen — Finanzwesen, Gesundheitswesen, öffentliche Verwaltung — ist die Gewinnung und Bindung solcher Profile mit marktüblichen Gehältern eine eigene organisatorische Herausforderung. Wird der Betrieb ausgelagert, steigen die Kosten weiter und es entstehen neue externe Abhängigkeiten.

2.3 Die unterschätzte Kostenposition: Modellwechsel

Am häufigsten werden die Kosten für den periodischen Basismodell-Wechsel unterschätzt. Das Open-Source-LLM-Ökosystem entwickelt sich sehr schnell. Bei jeder neuen Modellgeneration — Llama 3 zu Llama 4, oder einem Wechsel zu einer anderen Modellarchitektur — wiederholen sich folgende Arbeitsschritte:

• Fine-Tuning auf dem neuen Basismodell (Wochen bis Monate)
• Erneute Infrastrukturoptimierung
• Leistungsvergleich und Validierung
• Migrationszeitraum mit parallelem Betrieb beider Systeme

Dieser Zyklus wiederholt sich alle ein bis zwei Jahre und verursacht jeweils Kosten von 100.000–150.000 EUR. Über fünf Jahre sind mindestens zwei Wechselzyklen zu kalkulieren.

3. Die Leistungslücke — warum sie sich nicht schließt

Angenommen, die Kosten sind tragbar. Die nächste Frage lautet: Welche Leistung wird dafür erbracht? Hier zeigt sich das zweite strukturelle Problem des sLLM-Eigenbetriebs.

3.1 Warum sich die Lücke vergrößert statt zu schließen

Viele Evaluierungsberichte für sLLM-Eigenbetrieb heben hervor, dass sich Open-Source-Modelle schnell verbessern. In absoluten Punktzahlen stimmt das. Der MMLU-Pro-Score von Llama 3 8B stieg von etwa 32 Punkten auf rund 47 Punkte mit Llama 3.3 8B und Qwen 2.5 7B — ein Zuwachs von 15 Punkten in eineinhalb Jahren.

Im gleichen Zeitraum entwickelten sich kommerzielle Modelle jedoch deutlich schneller. Claude 3 Opus lag im ersten Halbjahr 2024 bei rund 68 MMLU-Pro-Punkten. Claude 3.5 Sonnet erreichte im zweiten Halbjahr 2024 etwa 76 Punkte; 2025 kommen Claude 4 Sonnet und GPT-5 auf rund 85–88 Punkte. Die Lücke wuchs von 36 Punkten (H1 2024) auf 41 Punkte (H2 2025) — trotz absoluter Verbesserung der Open-Source-Modelle.

Das eigentliche Problem liegt in der Trendentwicklung der nächsten drei Jahre. 7–8B-Modelle nähern sich einer Sättigungsgrenze um die 50 MMLU-Pro-Punkte, bedingt durch ihre Modellgröße. Kommerzielle Modelle sind dagegen in ein neues Paradigma eingetreten: Inference-Time-Scaling. OpenAIs o1/o3-Serie und Claudes Extended Thinking sind Beispiele dafür. Dieser Ansatz steigert die Leistung durch erhöhten Rechenaufwand zum Inferenzzeitpunkt — nicht durch größere Modelle. Für kleine Modelle ist er aus Kostengründen praktisch nicht anwendbar. Damit öffnet sich eine strukturelle Schere, die durch Fine-Tuning nicht zu schließen ist.

Bis 2028 ist mit einer Lücke von über 46 Punkten zu rechnen. Die Hoffnung, durch Eigenbetrieb irgendwann aufzuholen, ist durch zwei Jahre empirische Daten widerlegt. Die technologische Entwicklung zeigt in dieselbe Richtung.

Die Ursachen für die anhaltende Lücke sind strukturell:

• Investitionsgefälle: OpenAI, Anthropic und Google investieren jeweils mehrere Milliarden US-Dollar jährlich in die Modellentwicklung. Die Gesamtinvestition des gesamten Open-Source-Ökosystems erreicht diesen Wert nicht.
• Skalierungsgesetze (Scaling Laws): Die aktuelle KI-Leistung skaliert mit Modellgröße, Datenmenge und Rechenkapazität. Kommerzielle Modelle operieren im Bereich von Hunderten Milliarden bis Billionen Parametern. Realistisch einsetzbare sLLMs liegen bei 7–32B. Das entspricht einem Größenunterschied von Faktor 10–100, der sich direkt in Leistungsunterschieden niederschlägt.
• Infrastrukturvorsprung: Kommerzielle Modelle werden auf Clustern mit Zehntausenden GPUs trainiert. Eine interne Infrastruktur mit acht H100-Karten hat einen grundlegend anderen Ausgangspunkt.
• Strukturelle Barriere beim Inference-Time-Scaling: Das seit Ende 2024 dominante Paradigma ist für kleine Modelle wirtschaftlich nicht skalierbar. Kommerzielle Anbieter erschließen damit eine neue Leistungsdimension, die für den Eigenbetrieb strukturell unzugänglich bleibt.

3.2 Kann domänenspezifisches Fine-Tuning die Lücke ausgleichen?

Ein häufiges Gegenargument lautet: „Für unsere spezifischen Anwendungsfälle brauchen wir kein Universalmodell. Fine-Tuning auf Eigendaten macht unseren sLLM überlegen." Dieser Einwand enthält eine partielle Wahrheit — aber er ist als Entscheidungsgrundlage unzureichend.

Folgende Einschränkungen sind zu beachten:

• Allgemeine Sprachkompetenz als Fundament: Auch domänenspezifische Aufgaben — Vertragsanalyse, regulatorische Berichterstattung, medizinische Dokumentation — bauen auf allgemeinem Sprachverständnis und Schlussfolgerungsvermögen auf. Schwache Grundkompetenz begrenzt die domänenspezifische Leistung.
• Kontextuelles Lernen kommerzieller LLMs: Aktuelle kommerzielle Modelle adaptieren sich über RAG an domänenspezifische Daten, ohne vorheriges Training. Das reduziert den Differenzierungsvorteil von Fine-Tuning erheblich.
• Begrenzte Fine-Tuning-Wirkung: Fine-Tuning verbessert nachweislich die Domänenleistung, aber der Zugewinn übersteigt in der Praxis selten die bestehende Grundleistungslücke.

Die Frage ist nicht, ob Fine-Tuning einen Wert hat — das tut es. Die Frage ist, ob ein Proof of Concept (PoC) für die eigene Domäne durchgeführt wurde, der belegt, dass der sLLM nach Fine-Tuning tatsächlich ausreicht. Entscheidungen ohne diesen empirischen Nachweis tragen ein messbares Risiko.

4. Betriebslast — Personal und Verantwortung

Neben Kosten und Leistung wird ein dritter Aspekt regelmäßig unterschätzt: die operative Dauerlast. Ein sLLM ist kein Einmalprojekt. Er muss als lebendiges System über Jahre hinweg betrieben werden.

4.1 Personalgewinnung in einem Verkäufermarkt

KI-Ingenieure und MLOps-Spezialisten gehören zu den gefragtesten Profilen auf dem DACH-Arbeitsmarkt. Technologieunternehmen und KI-Start-ups bieten Jahresgehälter, mit denen öffentliche Körperschaften oder stark tarifgebundene Unternehmen kaum konkurrieren können. Neben dem finanziellen Aspekt entstehen bei Fremdvergabe des Betriebs neue Wissensabhängigkeiten, die die angestrebte Souveränität wieder untergraben.

4.2 Betriebsverantwortung und Haftung

Beim Eigenbetrieb verbleibt die volle Verantwortung für Ausfälle und Sicherheitsvorfälle intern. Bei Nutzung externer kommerzieller Dienste übernimmt der Anbieter die Erstreaktion bei Infrastrukturproblemen. Beim selbst betriebenen sLLM trägt die eigene Organisation allein die Verantwortung — für Hardware-Ausfälle, Qualitätsdegradation des Modells und Sicherheitsvorfälle. In regulierten Branchen, wo DSGVO-Meldepflichten und BSI-Berichtspflichten greifen, ist das ein erheblicher organisatorischer Aufwand.

4.3 Modell-Evolution als Dauerprojekt

Der oben beschriebene Basismodell-Wechsel ist nicht nur eine Kostenfrage, sondern auch eine operative Dauerbelastung. Bei jedem Wechselzyklus ist ein separates Projekt für Evaluation, Migrationsplanung und Umstellung zu stemmen — zusätzlich zum laufenden Betrieb. Die kognitive und zeitliche Belastung des Betriebsteams akkumuliert sich über die Jahre.

5. Wann sLLM-Eigenbetrieb die richtige Wahl ist

Eine ausgewogene Betrachtung erfordert die klare Benennung der Fälle, in denen Eigenbetrieb tatsächlich sinnvoll ist. Wenn folgende Bedingungen zutreffen, ist sLLM-Eigenbetrieb eine rational begründbare Entscheidung.

• Großunternehmen mit entsprechendem IT-Budget: TCO von 1,4–1,9 Mio. EUR über fünf Jahre ist tragbar, und ein dediziertes KI-Betriebsteam kann aufgebaut werden.
• Regulatorisch oder vertraglich erzwungene Datenisolation: In bestimmten Bereichen — sicherheitskritische Infrastruktur, Verteidigung, bestimmte Geheimhaltungsstufen — ist die Nutzung externer KI-Dienste rechtlich oder vertraglich ausgeschlossen. Hier ist Eigenbetrieb keine Wahl, sondern Pflicht.
• Domänenspezifisches KI-Modell als Kernkompetenz: Wenn das primäre Organisationsziel der Aufbau eines proprietären KI-Modells ist — etwa für ein Forschungsinstitut oder einen Fachinformationsdienst —, ist Eigenbetrieb strategisch begründet.
• Sehr hohes Anfragevolumen: Bei mehreren hunderttausend KI-Anfragen täglich kann der Eigenbetrieb gegenüber nutzungsbasierter API-Abrechnung günstiger werden.
• Klare Langfriststrategie zur Vermögensbildung: Die Organisation versteht das KI-Modell explizit als langfristiges strategisches Asset und plant entsprechend.

Wenn mehrere dieser Bedingungen erfüllt sind, lohnt sich eine eingehende Prüfung des Eigenbetriebs. Sind keine dieser Bedingungen erfüllt, sollten die Entscheidungsgrundlagen kritisch überprüft werden.

6. Typische Fehlentscheidungsmuster

In der Praxis lassen sich wiederkehrende Muster bei nicht tragfähigen sLLM-Entscheidungen beobachten. Wenn eines dieser Muster auf Ihre Situation zutrifft, empfiehlt sich eine erneute Überprüfung der Entscheidungsgrundlage.

Muster 1 — „Externe KI ist per se unsicher"

Das häufigste Muster: Aus einer abstrakten Risikowahrnehmung gegenüber externen KI-Diensten wird ohne tiefere Analyse der Schluss „also Eigenbetrieb" gezogen. Dabei existieren für externe LLM-Nutzung konkrete Sicherheitsarchitekturen — Prompt-Gateway, Datenkapsulierung, Auditierung. „Extern gleich unsicher, intern gleich sicher" ist ein Bauchgefühl, keine Risikoanalyse. Unter DSGVO und BSI C5 lässt sich externe KI-Nutzung mit geeigneten Kontrollmaßnahmen valide absichern.

Muster 2 — „Datensouveränität als Selbstzweck"

Die Entscheidung wird mit Datensouveränität begründet, ohne dass die tatsächlich zu verarbeitenden Daten klassifiziert wurden. In der Praxis zeigt sich häufig, dass ein Großteil der Anwendungsfälle öffentlich zugängliche oder pseudonymisierbare Informationen betrifft, die über geeignete Schutzmaßnahmen extern verarbeitet werden könnten. Der abstrakte Wert „Datensouveränität" darf die konkrete Szenarioanalyse nicht ersetzen.

Muster 3 — „Wettbewerber macht es auch"

Ein Wettbewerber oder eine Branchenorganisation hat sLLM-Eigenbetrieb angekündigt — und nun entsteht Handlungsdruck. Aber die Rahmenbedingungen, Anwendungsfälle und strategischen Ziele unterscheiden sich. Was für ein anderes Unternehmen richtig ist, muss für die eigene Organisation nicht gelten. Eine unabhängige Prüfung ist erforderlich.

Muster 4 — „Das Budget ist vorhanden"

Ein KI-Infrastrukturbudget wurde bewilligt und muss eingesetzt werden. Das führt dazu, dass die teuerste Option gewählt wird, weil sie am sichtbarsten ist. Vorhandene Mittel verpflichten nicht zur teuersten Lösung. Effizientere Alternativen zu wählen und Restmittel für andere Digitalisierungsmaßnahmen zu nutzen, ist rational — und gegenüber Aufsichtsgremien leichter zu begründen.

Muster 5 — „Der Anbieter empfiehlt es"

GPU-, Infrastruktur- und Systemintegrations-Anbieter haben ein natürliches Interesse an Eigenbetriebslösungen — ihr Umsatz korreliert direkt damit. Anbieterempfehlungen sind nützliche Informationsquellen, aber keine neutrale Entscheidungsgrundlage. Eine unabhängige TCO-Analyse und ein Vergleich mit Alternativen sind unabdingbar.

7. Entscheidungs-Checkliste für sLLM-Eigenbetrieb

Wenn Sie den sLLM-Eigenbetrieb ernsthaft erwägen, beantworten Sie bitte die folgenden Fragen. Überwiegen die Ja-Antworten, ist Eigenbetrieb eine rational begründete Option. Sind viele Fragen offen oder mit Nein zu beantworten, sollten Alternativen systematisch geprüft werden.

sLLM-Eigenbetrieb ist keine leichte Entscheidung. Sie binden damit erhebliche Ressourcen für fünf und mehr Jahre. Eine sorgfältige Prüfung, die alle Kostendimensionen, die Leistungsrealität und die Betriebslast berücksichtigt, ist die Mindestanforderung, bevor eine solche Verpflichtung eingegangen wird.

Häufig gestellte Fragen

Reduzieren kleinere Modelle (7B) die Kosten wesentlich?

Bei der GPU-Infrastruktur ja: Für 7B-Modelle reichen ein bis zwei H100-Karten aus, was die Anfangsinvestition deutlich senkt. Die Personalkosten, Energiekosten und der Aufwand für Modellwechsel bleiben jedoch nahezu identisch. Zudem ist die Leistungslücke bei 7B-Modellen gegenüber kommerziellen Spitzenmodellen noch größer als bei 32B-Modellen — was den Nutzwert entsprechend einschränkt.

Ist ein Hybrid-Modell aus sLLM und Gateway-Ansatz sinnvoll?

Grundsätzlich möglich: Bestimmte Abteilungen oder Anwendungsfälle nutzen den sLLM, andere den Gateway-Ansatz. Allerdings bedeutet das, zwei unterschiedliche Betriebsmodelle, Governance-Strukturen und Sicherheitsarchitekturen parallel zu managen — ein erheblicher Mehraufwand. In den meisten Fällen ist es sinnvoller, mit einem Ansatz zu beginnen und bei Bedarf zu erweitern.

Werden Open-Source-Modelle kommerzielle LLMs nicht bald einholen?

In bestimmten Benchmarks gibt es temporäre Annäherungen. In der Praxis — insbesondere bei komplexen Schlussfolgerungsaufgaben und der Verarbeitung langer Kontexte — bleibt die Lücke erheblich. Und kommerzielle Modelle stagnieren nicht: Das Inference-Time-Scaling-Paradigma öffnet eine neue Leistungsdimension, die strukturell schwer zugänglich für kleine Modelle ist. Das Muster der vorübergehenden Annäherung gefolgt von erneuter Divergenz wiederholt sich bislang mit jeder Modellgeneration.

Welches Basismodell sollte für den Eigenbetrieb gewählt werden?

Aktuell sind Llama-Modelle (Meta), Qwen-Modelle (Alibaba) und für deutschsprachige Anwendungen optimierte Varianten die gängigen Optionen. Die Wahl hängt von Lizenzbedingungen, Leistung auf der eigenen Domäne, Community-Support und konkreten Anwendungsszenarien ab. Unabhängig von der Wahl gilt: In ein bis zwei Jahren wird es bessere Modelle geben. Der Aufwand für den Wechsel muss von Anfang an eingeplant werden.

Quellen und weiterführende Literatur

• Wang et al., "MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark", 2024
• Hugging Face Open LLM Leaderboard, MMLU-Pro-Benchmark (huggingface.co/spaces/open-llm-leaderboard)
• Kaplan et al., "Scaling Laws for Neural Language Models", 2020
• Hoffmann et al., "Training Compute-Optimal Large Language Models" (Chinchilla), 2022
• Bundesamt für Sicherheit in der Informationstechnik (BSI), C5-Anforderungskatalog (Cloud Computing Compliance Criteria Catalogue), aktuelle Fassung
• Europäische Kommission, Verordnung (EU) 2024/1689 — EU AI Act, 2024