Die versteckten Kosten der Cloud

Kapitel 5 — Die versteckten Kosten der Cloud

Die vorherrschende Erzählung der letzten fünf Jahre besagt, dass die Cloud kostengünstig, skalierbar und einfach ist. Für viele Workloads ist das vollkommen richtig. Für unternehmenskritische RAG-Anwendungen trifft dies jedoch immer häufiger nicht zu. Und der Zeitpunkt, an dem Sie das bemerken, ist in der Regel im ersten Quartal, wenn die Rechnung eintrifft.

Nehmen wir den am häufigsten unterschätzten Kostenpunkt: die APIs der Bilderkennungsmodelle. Wenn ein Unternehmen sein Fotoarchiv in eine moderne RAG-Anwendung einbindet, muss jedes Foto von einem multimodalen Modell "beschrieben" werden, das Inhalte, Objekte, Kontext, eventuell überlagerte Texte, Stimmung und Komposition extrahiert. Ein großer europäischer Modellanbieter – noch namentlich nicht genannt – bot 2025 ein ausgezeichnetes Modell der Qwen-Familie mit 32 Milliarden Parametern zu einem interessanten Preis pro Bild an. Das Problem, das erst im Feld und nach monatelanger Produktion entdeckt wurde: unter Last kürzte der Anbieter die Antworten. Nicht immer, nicht vorhersagbar, nicht wenn das Testteam davor stand: zufällig. Ein von zehn Fotos, manchmal eines von fünf, kam mit einem abgeschnittenen, schlecht geparsten JSON zurück, mit unvollständigen oder fehlenden Metadaten. Die Zeiten schossen von zehn Sekunden auf zweihundert Sekunden pro Bild hoch, ohne erkennbares Muster. Die Kosten für Wiederholungsversuche – denn Wiederholungsversuche werden bezahlt, jeder Aufruf, auch der, den der Server abbricht – waren höher als erwartet. Die Datenbank war uneinheitlich: einige Fotos reich an Metadaten, andere abgeschnitten. Und das Team konnte das Problem in Testumgebungen nicht reproduzieren, da die Last in Tests gering war und alles funktionierte.

Die Lösung kam in drei Teilen: ein kompakterer Prompt (kürzere Antworten werden weniger oft abgeschnitten), eine intelligente Retry-Logik (wenn die Antwort länger als fünfzig Sekunden dauert und leer zurückkommt, wird sie sofort wiederholt) und – wenn das Volumen dies rechtfertigt – die Möglichkeit, die Cloud ganz zu überspringen und das Visionsmodell auf einer lokalen, langsameren, aber deterministischen GPU auszuführen. Die richtige Architektur ist aus dieser Erfahrung heraus weder "immer Cloud" noch "immer lokal". Sie ist "wähle für jeden Aufruf, basierend darauf, was in diesem Moment benötigt wird".

Dann ist da noch das Kapitel der Abfragen. Jede Benutzersuche löst in einem klassischen, Cloud-nativen RAG eine Kaskade von kostenpflichtigen API-Aufrufen aus. Eine für das Embedding der Frage. Eine für die Intent-Klassifizierung (welche Art von Frage ist das?). Eine für das Neusortieren der Dokumente. Eine für die Generierung der endgültigen Antwort. Jede kostet einen Bruchteil eines Cent. Für einen internen Dienst mit fünfzig Benutzern und zehntausend Abfragen pro Tag – das ist nicht wenig, aber auch keine riesige Zahl für ein mittelständisches Unternehmen – beläuft sich die monatliche Rechnung auf Beträge, die selbst einem nachsichtigen CFO die Nase rümpfen lassen würden. Und das Wachstum ist linear: verdoppeln Sie die Benutzer, verdoppeln Sie die Rechnung. Es gibt keine Skaleneffekte bei den verbrauchten Token, nicht für Sie.

Es gibt auch ein Problem, das 2025 im Verborgenen lag und 2026 ins Zentrum rückte: Jede einzelne Anfrage sendet Teile von Unternehmensdokumenten – manchmal vertraulich, manchmal durch Geheimhaltungsvereinbarungen (NDAs) geschützt, manchmal unterliegen sie branchenspezifischen Vorschriften – an die Server eines externen Anbieters in Rechtsgebieten, die nicht immer mit Ihren übereinstimmen, mit Protokollierungsrichtlinien, die nicht immer klar sind. Mehr als ein europäisches Unternehmen hat in den letzten achtzehn Monaten erst bei einer Prüfung – in der Regel aufgrund eines besorgten Kunden oder einer ISO-Zertifizierung – festgestellt, dass seine Verträge, Preislisten und technischen Spezifikationen von Infrastrukturen außerhalb der EU verarbeitet (und potenziell zu Zwecken der "Dienstleistungsverbesserung" protokolliert) wurden. Die Überraschung hat in der Regel mehr gekostet als die Einsparungen bei der lokalen Hardware, die man vermeiden wollte.

Die Alternative ist nicht der gegenteilige Dogmatismus. "Keine Cloud, sondern lokal ja" ist genauso falsch wie "Immer Cloud". Die Alternative ist eine Architektur, die es Ihnen ermöglicht, für jeden einzelnen Teil der Pipeline – Embedding, Klassifizierung, Re-Ranking, Vision, endgültige Generierung – zu wählen, ob Sie ein Cloud-Modell oder ein lokales Modell verwenden, und Ihre Meinung an einem Tag zu ändern, nicht in einem Quartal. Dies erfordert ein Design, bei dem die Anbieter austauschbar sind, bei dem kein Teil an den Namen eines bestimmten Unternehmens gebunden ist, bei dem der Wechsel von Regolo zu Ollama (oder umgekehrt) eine Konfigurationszeile ist, nicht eine Umschreibung. Und das war bis vor kurzem selten. Beliebte Frameworks waren trotz der Fassade von "Provider-Agnostik" tatsächlich sehr mit jemandem verheiratet.