On-Premises oder Cloud-LLMs? Wann sich Self-Hosted-Modelle für Unternehmen lohnen

Die drei Betriebsmodelle, um die es eigentlich geht

Wer „On-Premises vs. Cloud" diskutiert, vergleicht oft Dinge, die sich technisch nur teilweise überdecken. Sinnvoller ist es, drei reale Betriebsmodelle zu unterscheiden, zwischen denen sich die meisten Unternehmensentscheidungen tatsächlich abspielen.

Das erste Modell ist die API-basierte Nutzung kommerzieller Modelle. Anfragen gehen an einen externen Anbieter, das Modell läuft auf dessen Infrastruktur, das eigene System schickt Texte hin und bekommt Antworten zurück. Das ist heute der Default für die große Mehrheit der KI-Anwendungen — günstig im Einstieg, schnell betriebsbereit, ohne eigenes Rechenzentrum.

Das zweite Modell ist dediziertes Hosting in einer Cloud-Region oder einer kontrollierten Cloud-Umgebung. Das Modell läuft auf zugewiesenen Ressourcen in einer bestimmten Region, oft mit zusätzlichen Vereinbarungen über Datenfluss und Aufbewahrung. Es bleibt eine Cloud-Lösung, aber mit klarer örtlicher und vertraglicher Eingrenzung.

Das dritte Modell ist echtes Self-Hosting: ein offen verfügbares Modell läuft auf eigener oder selbst beschaffter Hardware, im eigenen Rechenzentrum oder in einer dafür gemieteten Cloud-Instanz, die das Unternehmen selbst betreibt. Hier liegen Modell, Inferenz, Versionierung und Betrieb vollständig im eigenen Verantwortungsbereich.

Die Wahl zwischen diesen drei Modellen ist keine reine Hosting-Frage. Sie hat spürbare Folgen für Modellauswahl, Latenz, Kosten, Geschwindigkeit der Iteration und für die Anforderungen an das eigene Team. Welches Modell überhaupt für welchen Use Case in Frage kommt, hängt eng mit dem Thema LLM-Auswahl für Unternehmen zusammen.

Was sich für viele Unternehmen heute realistisch lohnt

Für die Mehrheit der KI-Anwendungen, die wir in Projekten begleiten, ist die ehrliche Antwort: API-basierte Nutzung kommerzieller Modelle. Das hat weniger mit Bequemlichkeit zu tun als mit dem realen Verhältnis von Aufwand und Wirkung.

API-Nutzung verlangt kein eigenes Modell-Operations-Team, keine Hardware-Beschaffung und kein laufendes Versionsmanagement von Modellen. Sie erlaubt schnelle Wechsel zwischen Modellen und Anbietern und nutzt die kontinuierlichen Verbesserungen, die im kommerziellen Modell-Markt heute fast monatlich passieren. Für Use Cases mit überschaubarem Volumen liegt der Gesamtkostenvorteil der API über Jahre hinweg.

Self-Hosting wird interessanter, sobald sehr hohe Anfragelast vorliegt, sehr enge Anforderungen an Datenfluss und Datenort gelten oder sehr spezifische Modelle gebraucht werden, die sich kommerziell nicht beziehen lassen. In Zwischenfällen ist häufig dediziertes Cloud-Hosting der richtige Mittelweg — kontrollierter als die Standard-API, ohne den vollen Betriebsaufwand eines eigenen Modell-Stacks.

Wann Self-Hosting tatsächlich Sinn ergibt

Drei Konstellationen sprechen ernsthaft für echtes Self-Hosting. Sie sind seltener, als die öffentliche Diskussion vermuten lässt.

Erstens: regulatorische oder vertragliche Anforderungen, die einen bestimmten Datenort oder eine vollständige Kontrolle über die Verarbeitungsumgebung verlangen. Solche Anforderungen sind in einigen Branchen real und nicht verhandelbar. Wer in dieser Lage ist, kennt sie meist schon vor dem ersten KI-Projekt; eine architektonische Bewertung ersetzt allerdings nicht die rechtliche Prüfung im Einzelfall.

Zweitens: extrem hohe Anfragevolumina, bei denen die nutzungsabhängigen Kosten kommerzieller APIs die Investition in eigene oder gemietete GPU-Infrastruktur spürbar übersteigen würden. Das gilt vor allem für hochfrequente, eng definierte Aufgaben — also Setups, in denen ohnehin häufig ein fine-getuntes kleineres Modell wirtschaftlicher ist als ein großes Allzweckmodell.

Drittens: sehr spezifische Modellanforderungen, die sich kommerziell nicht abbilden lassen — etwa bestimmte Sprachen, Domänen oder Verhaltensanforderungen, die nur mit einem offen verfügbaren Modell und eigener Anpassung erreichbar sind. In der Praxis ist das ein deutlich kleinerer Teil der Use Cases, als oft angenommen wird.

In allen anderen Fällen ist Self-Hosting selten der wirtschaftlichste Weg. Es kann ihn als politische oder strategische Entscheidung trotzdem geben — dann sollte das aber bewusst so benannt sein, nicht als technische Notwendigkeit verkleidet.

Die unsichtbare Hälfte: was beim Self-Hosting wirklich kostet

In Pitches für Self-Hosting taucht meistens eine Tabelle auf, die GPU-Stunden mit API-Kosten vergleicht. Diese Rechnung ist fast nie vollständig. Die spürbar größeren Kosten liegen woanders.

Da ist der Modell-Lebenszyklus. Modelle altern, neue Versionen kommen, Sicherheitsupdates müssen eingespielt werden, Fine-Tuning-Stände müssen reproduzierbar bleiben. Wer diesen Zyklus selbst übernimmt, betreibt eine kleine Modell-Plattform — mit allen Anforderungen an Versionierung, Tests und Rückrollbarkeit, die das mit sich bringt.

Da ist die Infrastruktur. GPU-Beschaffung ist zyklisch, Verfügbarkeit schwankt, Stromkosten und Kühlung sind nicht trivial. Wer in der Cloud Self-Hosting betreibt, hat zwar diese Sorgen weniger, zahlt dafür aber dauerhaft für reservierte Kapazität, auch wenn die Last ungleichmäßig ist.

Da ist das Betriebs- und Beobachtungskonzept. Latenz, Auslastung, Modell-Drift, Antwortqualität, Rate Limits — alles, was bei der API der Anbieter mit übernimmt, muss bei Self-Hosting selbst gebaut und gepflegt werden. Diese Disziplin überschneidet sich direkt mit dem Bereich LLM-Monitoring und Observability und gehört unbedingt vor den ersten produktiven Lauf.

Und da ist das Personal. Self-Hosted-LLMs zu betreiben ist eine eigene Disziplin, für die qualifiziertes Personal heute knapp und teuer ist. Eine Plattform, die niemand wirklich verantwortet, ist im Betrieb gefährlich. Eine, die ein Team kontinuierlich pflegt, ist es nicht — kostet aber das ganze Jahr, nicht nur zur Einführung.

Hybride Setups als realistische Antwort

In der Praxis entsteht selten ein reines „alles API" oder „alles Self-Hosted". Der Regelfall ist eine bewusste Aufteilung, in der jede Aufgabe das Betriebsmodell bekommt, das ihr am besten passt.

Eine typische hybride Architektur nutzt kommerzielle APIs für anspruchsvolle Allzweck-Aufgaben — komplexe Analyse, Mehrsprachigkeit, schwierige Reasoning-Aufgaben — und ein selbst gehostetes oder dediziert betriebenes kleineres Modell für hochfrequente, eng definierte Teilaufgaben mit besonderen Anforderungen an Latenz, Datenfluss oder Kosten. Eine Anwendung kann beide Modelle gleichzeitig nutzen, ohne dass das aus Anwendungssicht sichtbar wird.

Damit so eine Architektur dauerhaft tragbar bleibt, müssen Modellanbindungen so gebaut sein, dass sie austauschbar bleiben. Eine standardisierte Verbindungsschicht zwischen KI-Anwendung und genutzten Werkzeugen — etwa über das Model Context Protocol — vereinfacht solche hybriden Setups erheblich, weil sie die Hosting-Frage von der Anwendungslogik entkoppelt.

Im selben Geist gehört eine bewusste Trennung zwischen Modellanbindung und Anwendungslogik in jede Architektur, die sich nicht früh in einen Anbieter verheiraten will. Das hat weniger mit Misstrauen gegenüber dem Anbieter zu tun und mehr mit der schlichten Beobachtung, dass die Modell-Landschaft sich schneller verändert als jede Anwendung.

Wie man die Entscheidung sauber strukturiert

Vier Fragen helfen, die Entscheidung jenseits von Bauchgefühl zu führen.

Erstens: Welche Anforderungen an Datenfluss und Datenort sind hart, welche sind weich? Harte Anforderungen sind regulatorisch oder vertraglich verbindlich und nicht verhandelbar. Weiche Anforderungen sind Wünsche oder Risikoeinschätzungen, die sich oft mit dediziertem Cloud-Hosting oder vertraglichen Vereinbarungen adressieren lassen, ohne in vollständiges Self-Hosting zu kippen.

Zweitens: Wie hoch ist die zu erwartende Anfragelast — heute und in zwei Jahren? Niedrige bis mittlere Last spricht fast immer für API-basierte Nutzung. Sehr hohe Last in einem stabilen Use Case kann einen kostengünstigen Wechsel zu Self-Hosted oder fine-getunten kleineren Modellen rechtfertigen.

Drittens: Welches Modell ist überhaupt nötig? Wenn ein hochkarätiges Allzweckmodell die Aufgabe trägt, ist die Frage real, denn solche Modelle gibt es heute überwiegend kommerziell. Wenn ein kleineres oder spezialisiertes Modell genügt, wird Self-Hosting plötzlich realistischer und in vielen Fällen auch wirtschaftlich.

Viertens: Welches Team baut und betreibt das? Self-Hosting ohne ein Team, das es dauerhaft trägt, ist eine schlechte Idee. API-Nutzung mit einem Team, das die Anwendung sauber baut, schlägt eine prestigeträchtige Self-Hosted-Plattform, die niemand wirklich pflegt.

Typische Fehler in dieser Entscheidung

Der häufigste Fehler ist, Self-Hosting als Default zu wählen, weil es „kontrollierter" klingt. Kontrolle ohne Kompetenz und Kapazität ist keine Kontrolle, sondern Risiko. Eine API mit einem klaren Vertrag und einem disziplinierten Anwendungs-Stack ist in den meisten Fällen besser kontrolliert als ein eigener Modell-Stack ohne Pflege.

Der zweite Fehler ist, Self-Hosting als reine Kostenfrage zu rechnen. Die zentrale Frage ist nicht „was kostet eine Stunde GPU?", sondern „was kostet ein funktionierender, gepflegter, beobachteter Modell-Betrieb über drei Jahre?".

Der dritte Fehler ist, die Hosting-Entscheidung vor der Build-vs.-Buy-Frage zu treffen. Wer das tut, schneidet sich Optionen ab, bevor klar ist, welche Lösung überhaupt die richtige ist.

Der vierte Fehler ist, sich an einen Anbieter zu binden, ohne es zu merken. API-Nutzung ist sinnvoll, aber sie sollte sauber von der Anwendungslogik getrennt sein, damit ein Wechsel später möglich bleibt. Lock-in entsteht selten durch eine bewusste Entscheidung, häufig durch dauerhaftes Aufschieben.

Wann externe Unterstützung sinnvoll ist

Für eine einzelne klar geschnittene Anwendung lässt sich diese Frage intern beantworten, sobald Datenanforderungen, Last und Modellbedarf realistisch eingeschätzt sind. Sobald aber mehrere Anwendungen, regulierte Datenbestände oder strategische Plattformfragen ins Spiel kommen, lohnt sich ein Blick von außen — bevor sich Architekturentscheidungen verfestigen, die später nur teuer zu korrigieren sind.

Wir arbeiten mit Unternehmen, die diese Wahl bewusst treffen wollen — nicht aus Reflex, sondern entlang ihres tatsächlichen Bedarfs. Wenn das zu Ihrer Situation passt, sprechen Sie uns an, am besten zu Beginn — wenn Use Cases, Anforderungen und Architektur noch gestaltbar sind. Den passenden Rahmen dafür bieten wir über AI Engineering und unser AI Consulting.