On-Premise vs. Cloud-KI: die ehrliche Kostenrechnung

Cloud-KI ist als laufende Betriebskosten (OpEx) attraktiv: kein Kapitaleinsatz, sofort startklar, Abrechnung pro Token. Für den ersten Prototyp ist das ideal — und genau das ist der psychologische Haken. Der niedrige Einstieg lässt die Gesamtkosten harmlos wirken, obwohl sie mit jeder produktiven Nutzung steigen.

On-Premise dreht das um: Hardware und Strom sind planbare, weitgehend feste Kosten (CapEx plus Betrieb). Ob Sie eine Anwendung betreiben oder fünfzig, ob tausend Anfragen am Tag oder eine Million — der Preis ändert sich kaum. Sie zahlen für Kapazität, nicht für Nutzung. Das verschiebt das Risiko: weg von einer mit dem Erfolg wachsenden Rechnung, hin zu einer einmaligen Investitionsentscheidung.

Der reine Token-Preis ist selten der ganze Preis. Häufig übersehen werden:

• Wachstum als Kostentreiber: Erfolg skaliert die Rechnung. Gerade produktive, häufig genutzte Fälle werden am teuersten — Sie werden für Ihren eigenen Erfolg bestraft.
• Preishoheit beim Anbieter: Tarife, Modelle, Kontingente und Verfügbarkeit können sich ändern. Ihre Kalkulation hängt an fremden Entscheidungen, die Sie nicht steuern.
• Compliance-Aufwand für den Transfer: Jede Übermittlung an eine externe KI verlangt Rechtsgrundlage, Prüfung und Dokumentation — Aufwand, der in keiner Token-Preisliste steht.
• Nebenkosten des Betriebs: Datenabfluss, Monitoring, Vendor-Management und die Absicherung gegen Ausfälle oder Rate-Limits des Anbieters.
• Lock-in: Ein späterer Wechsel bedeutet Umbau statt Umzug — ein Kostenrisiko, das erst am Ende sichtbar wird, wenn es am teuersten ist.

Eigenbetrieb ist nicht gratis, und wer das behauptet, rechnet genauso einseitig wie die reine Token-Liste. Realistisch einzuplanen sind:

• Anschaffung der Hardware (CapEx) — die Investition, die über ihre Nutzungsdauer abgeschrieben wird.
• Strom und Kühlung — laufend, aber planbar und vom Nutzungsvolumen weitgehend entkoppelt.
• Betrieb und Wartung — der Aufwand, ein System am Laufen zu halten, Modelle zu aktualisieren, Ausfälle abzufangen.

Genau am letzten Punkt setzt die Betriebsschicht an: Automatische Knoten-Registrierung, ein vollautomatischer Modell-Lebenszyklus und ein Dashboard senken den Betriebsaufwand, der bei nacktem Eigenbetrieb sonst am teuersten ist. Der Unterschied zwischen „eigene GPU im Keller“ und „betriebsfähige Plattform“ ist genau dieser Aufwand.

Bei Cloud-Abrechnung zahlen Sie pro Anfrage — jede Anfrage kostet, jede Nacht ohne Last kostet nichts, aber jede Lastspitze schlägt voll durch. Bei eigener Hardware ist es umgekehrt: Die Kapazität ist bezahlt, egal ob sie zu 20 % oder 90 % ausgelastet ist. Das bedeutet zweierlei. Ungenutzte Kapazität ist verlorenes Geld — aber jede zusätzliche Nutzung ist praktisch kostenlos. Wer viele Anwendungsfälle auf derselben Hardware bündelt, senkt den Preis pro Anfrage mit jeder neuen Nutzung. Auslastung ist damit der wichtigste Hebel der Wirtschaftlichkeit.

Souveränität ist kein Dogma, sondern eine Abwägung. Es gibt Fälle, in denen Miete das bessere Modell bleibt:

• Prototypen und einmalige Experimente, bei denen es auf Tempo statt auf Dauerbetrieb ankommt.
• Sehr geringe, sporadische Nutzung ohne stetige Last.
• Der Bedarf nach einem exotischen Spitzenmodell, das Sie nur selten und nicht auf eigener Hardware brauchen — sofern die Daten unkritisch sind.

Der Punkt ist nicht „Cloud ist schlecht“, sondern: Miete und Besitz haben verschiedene Stärken. Souverän ist, die Wahl bewusst zu treffen — nicht, sie einem Anbieter zu überlassen.

• Stetiges, wachsendes Volumen statt vereinzelter Aufrufe.
• Mehrere Anwendungsfälle, die dieselbe Kapazität teilen und die Auslastung erhöhen.
• Sensible Daten, bei denen der Cloud-Transfer ohnehin ausscheidet — dann ist On-Premise nicht Kür, sondern Voraussetzung.
• Planbarkeit als Ziel: ein festes Budget statt einer mit der Nutzung wachsenden Rechnung.

• Nur den Token-Preis vergleichen und Transfer-, Compliance- und Betriebskosten ausblenden.
• Die Kosten eines Pilotprojekts als Dauerzustand behandeln — die reale Rechnung kommt mit der Skalierung.
• Wachstum ignorieren: Der Fall, der heute günstig ist, ist morgen der teuerste.
• Ungenutzte Kapazität als Verschwendung sehen, statt als bezahlten Spielraum für den nächsten Anwendungsfall.