Cloud-KI vs. self-hosted: welches Betriebsmodell?

Cloud, dediziert, lokal oder hybrid belastbar vergleichen? WZ-IT bewertet Datenklassen, Qualität, Last und Betriebskosten und setzt das passende Modell einschließlich Gateway, Monitoring und Exit-Pfad um. LLM-Hosting und Betriebsmodelle ansehen

Wer KI im Unternehmen einsetzt, entscheidet heute nicht nur zwischen Cloud und eigenem Server. Zur Auswahl stehen öffentliche APIs, dedizierte Managed-Instanzen, Self-Hosting und hybride Kombinationen. Dieser Vergleich ordnet Datenschutz, Qualität, Kosten, Kontrolle und Betriebsaufwand ein. Stand August 2026.

Inhaltsverzeichnis

• Zwei Betriebsmodelle für KI
• Datenschutz und Kontrolle
• Kosten: pro Token gegen eigene Hardware
• Cloud-KI und self-hosted im Vergleich
• Wann welches Modell
• Dediziert und hybrid als weitere Optionen
• Gesamtkosten statt Tokenpreis
• Entscheidung mit eigenen Testfällen
• Wie WZ-IT die Plattform umsetzt
• Quellen

Zwei Betriebsmodelle für KI

Bei Cloud-KI nutzen Sie ein Sprachmodell als Dienst: Ihre Anwendung schickt Anfragen an die API eines Anbieters, das Modell rechnet auf dessen Servern, die Antwort kommt zurück. Sie müssen keine Hardware stellen und nichts betreiben - dafür liegen Modell und Daten in fremder Hand.

Bei self-hosted KI läuft ein konkret ausgewähltes Modell auf kontrollierter Infrastruktur (siehe Was ist lokale KI?). Den Betrieb kann das eigene Team oder ein Managed-Service-Anbieter übernehmen. Wie viel Kontrolle tatsächlich entsteht, hängt an Administration, Schlüsseln, Datenflüssen, Export und Exit, nicht allein am Begriff „self-hosted".

Datenschutz und Kontrolle

Die zentrale Datenschutzfrage lautet nicht „Cloud oder lokal?", sondern: Welche Daten werden von wem zu welchem Zweck wohin übertragen? Neben Prompt und Antwort gehören dazu Dokumente, Embeddings, Nutzungsmetadaten, Telemetrie, Fehlerberichte, Supportzugriffe und Backups.

Self-Hosting kann die Übermittlung an einen Modellanbieter vermeiden. Das gilt aber nur, wenn auch Cloud-Funktionen, Websuche, Telemetrie und externe Observability kontrolliert sind. Ollama dokumentiert beispielsweise einen lokalen Modus, in dem Cloud-Funktionen ausdrücklich deaktiviert werden können. Ein Architekturtest prüft deshalb ausgehende Verbindungen statt sich auf das Produktetikett zu verlassen. Bei Cloud-Diensten können internationale Übermittlungen unter den Voraussetzungen der DSGVO zulässig sein; sie sind eine Einzelfallprüfung und nicht automatisch verboten.

Kosten: pro Token gegen eigene Hardware

Die beiden Modelle rechnen grundverschieden ab. Cloud-KI ist meist nutzungsabhängig: Sie zahlen für Eingabe, Ausgabe, Embeddings und gegebenenfalls Tools. Das ist günstig beim Einstieg und bei sporadischer Nutzung. Bei wachsender Nutzung steigen die variablen Kosten, während eine eigene GPU bei geringer Auslastung vor allem Leerlauf produziert.

Self-hosted KI verlagert die Kosten in Kapazität und Betrieb. Neben Hardware gehören Energie, Redundanz, Speicher, Backup, Updates, Monitoring, Bereitschaft und Personal in die Rechnung. Ob es günstiger wird, entscheidet daher das reale Nutzungsprofil. Der sinnvollere Vergleichswert ist der Preis pro erfolgreich erledigter Aufgabe einschließlich Nacharbeit, nicht nur Token- oder GPU-Preis.

Cloud-KI und self-hosted im Vergleich

Wann welches Modell

Die Faustregel folgt Daten, Qualität, Last und Betrieb:

• Cloud-KI, wenn Daten und Verträge zum Dienst passen, die Last stark schwankt oder ein bestimmtes geschlossenes Modell erforderlich ist.
• Self-hosted KI, wenn Datenwege eng kontrolliert werden müssen, eine planbare Grundlast besteht oder Modell- und Plattformwechsel wichtig sind.

Dediziert und hybrid als weitere Optionen

Eine dedizierte Managed-Instanz liegt zwischen öffentlicher API und Eigenbetrieb: Ressourcen, Region und Zugriffswege werden vereinbart, der Betrieb bleibt beim Dienstleister. Eine hybride Plattform verbindet mehrere Modellziele über ein Gateway. Das kann sensible Klassen lokal halten und besondere Fähigkeiten oder Lastspitzen extern abdecken.

Ein Gateway wie LiteLLM bündelt Deployments, Fallbacks, Timeouts und Lastverteilung hinter einer Schnittstelle. Es klassifiziert Geheimnisse aber nicht automatisch. Die Anwendung muss Datenklasse, Mandant und erlaubte Ziele verlässlich übergeben. Auch Fallback-Regeln dürfen eine Anfrage nicht stillschweigend an ein Ziel mit geringerer Schutzstufe senden.

Gesamtkosten statt Tokenpreis

Ein vollständiger TCO-Vergleich enthält mindestens:

• Modell-, Embedding- und Tool-Nutzung,
• GPU oder API-Grundkosten und Leerlauf,
• Speicher, Netzwerk, Backup und Wiederherstellung,
• Hochverfügbarkeit und Ersatzkapazität,
• Updates, Sicherheitsbehebung und Monitoring,
• Qualitätssicherung und menschliche Nacharbeit,
• Migration und Exit.

Für viele Unternehmen ist ein Mischmodell wirtschaftlich: planbare Grundlast auf eigener Kapazität, kontrollierte externe Nutzung für seltene Spitzen oder spezielle Aufgaben.

Entscheidung mit eigenen Testfällen

Öffentliche Benchmarks ersetzen keine eigene Evaluation. Für einen Pilot werden 30 bis 100 repräsentative Aufgaben samt erwarteten Ergebnissen und nicht zulässigen Datenwegen festgelegt. Zwei bis vier Varianten werden anschließend nach Qualität, Quellenbindung, Latenz, Durchsatz, Kosten und Betriebsrisiko verglichen. Auch Update, Ausfall, Lastspitze und Rollback gehören in den Test.

So zeigt sich, ob ein kleineres lokales Modell genügt, eine dedizierte Instanz nötig ist oder Hybridrouting einen messbaren Vorteil bringt.

Wie WZ-IT die Plattform umsetzt

WZ-IT verbindet Architektur und Betrieb: LLM-Hosting für kontrollierte Modellendpunkte, Managed AI für den produktiven Stack und AI Cube für lokale Szenarien. Je nach Projekt gehören Gateway, Identitätsanbindung, RAG, Monitoring, Backups, Evaluation und dokumentierte Wiederherstellung dazu.

Der Ausgangspunkt ist ein messbarer Pilot. Das Ergebnis ist keine pauschale Empfehlung für „lokal" oder „Cloud", sondern eine Architektur, deren Datenwege, Qualitätsgrenzen, Kosten und Verantwortlichkeiten nachvollziehbar sind. Den technischen Unterbau beschreibt der Open-Source-LLM-Stack.

Quellen

• EU-Kommission: Regeln für internationale Datenübermittlungen
• Ollama-Dokumentation: lokaler Betrieb und Cloud-Funktionen
• LiteLLM-Dokumentation: Routing und Load-Balancing
• vLLM-Dokumentation: OpenAI-kompatibler Inferenzserver