Wie KI die Cloud-Ökonomie verändert

Kubernetes-Cluster laufen mit einer durchschnittlichen CPU-Auslastung von 8 Prozent. Nicht 8 Prozent nachts, nicht 8 Prozent am Wochenende, sondern 8 Prozent über das gesamte Jahr hinweg, gemessen über Zehntausende von Organisationen auf AWS, GCP und Azure.

Diese Erkenntnis stammt aus dem „2026 State of Kubernetes Optimization Benchmark Report“ von Cast AI und zeigt, dass der Großteil der reservierten Rechenkapazität in Produktionsumgebungen ungenutzt bleibt, während die Cloud-Rechnung weiter steigt.

Cloudbasierte Infrastruktur hat die Bereitstellung radikal vereinfacht. Gleichzeitig hat sie damit einen Großteil der Reibung beseitigt, die früher Effizienz erzwungen hat. Kapazitäten mussten nicht mehr Monate im Voraus geplant, Hardwarekäufe nicht mehr gerechtfertigt und die Folgen schlechter Prognosen nicht mehr getragen werden. Organisationen konnten einfach mehr bereitstellen. Das Ergebnis ist eine Kultur der Überprovisionierung, die fest in der Arbeitsweise von Engineering-Teams verankert ist. Typischerweise bedeutet das: Ressourcenanforderungen werden während der Sprint-Planung hoch angesetzt, später nie wieder überprüft, und ungenutzte Rechenkapazität wird als akzeptabler Preis für Zuverlässigkeit behandelt.

Während des größten Teils des vergangenen Jahrzehnts war dieser Kompromiss beherrschbar. Die Verschwendung war real, aber diffus – verteilt über CPU- und Speicherallokationen, die schwer zu messen und leicht zu ignorieren waren. FinOps entstand als Disziplin, um diese Verschwendung sichtbar zu machen und zu steuern. Das half, behandelte aber weitgehend das Symptom und nicht die Ursache: Infrastruktur ist strukturell schwer mit der Geschwindigkeit zu optimieren, mit der sie sich verändert.

KI-Workloads verändern die Rechnung

Bei KI-Infrastruktur erhält dasselbe strukturelle Problem einen deutlich höheren Kostenmultiplikator. GPU-Compute ist per Definition teuer. Eine einzelne H200 auf AWS kostet beispielsweise rund 10 US-Dollar pro Stunde On-Demand, sofern die Kapazität verfügbar ist. Der Bericht von Cast AI ergab, dass nur 5 Prozent der GPUs aktiv genutzt werden, während die verbleibenden 95 Prozent aufgrund des Missverhältnisses zwischen sprunghaften Nachfragemustern und statischen Bereitstellungsmodellen ungenutzt bleiben. Die finanziellen Auswirkungen lassen sich kaum ignorieren.

Das Nachfrageprofil verschärft das Problem zusätzlich. Bei KI-Inferenz können Organisationen nicht einfach eine dynamische Replica-Anzahl konfigurieren und das Problem damit als gelöst betrachten, denn standardmäßig ist eine einzelne GPU an ein einzelnes Modell gebunden. Ist die Kapazität ausgeschöpft, ist die Bereitstellung zusätzlicher GPUs aufgrund anhaltender Lieferengpässe und begrenzter Verfügbarkeit selten unkompliziert. Statische Bereitstellung, die für Kubernetes bereits das falsche Modell war, passt besonders schlecht zu KI-Infrastruktur – ist aber zum Standard geworden, weil es keine einfachen Alternativen gibt. Das ist einer der Hauptgründe, warum GPU-Sharing an Bedeutung gewinnt. Für kleine Modelle oder große GPUs werden beispielsweise MIG und andere GPU-Sharing-Techniken zunehmend üblich. Es ist das Äquivalent zu VPA und HPA für GPUs.

Hinzu kommt die Token-Optimierung. Die Unterschiede zwischen Modellklassen können bei der Preisgestaltung pro Token eine Größenordnung ausmachen. Organisationen, die jede Anfrage an ein Top-Tier-Modell weiterleiten, selbst wenn günstigere Klassen für die meisten Anfragen die Qualitätsanforderungen erfüllen würden, geben strukturell zu viel aus – auf eine Weise, die ohne Kostenattribution auf Anfrageebene und SLO-Bewertung nahezu unmöglich zu erkennen ist. Traditionelle FinOps-Tools, ursprünglich für Cloud Computing entwickelt, haben mit den Kosten von LLM-APIs nicht Schritt gehalten.

Warum die Optimierungslücke weiter wächst

Die Lücke zwischen dem, was Organisationen ausgeben, und dem, was sie ausgeben sollten, schließt sich nicht – sie wird sogar größer. Dafür gibt es strukturelle Gründe. Erstens ist die Feedbackschleife zu langsam. Wenn eine Kostenanomalie in einem Dashboard oder in einer Quartalsprüfung auftaucht, ist die Verschwendung bereits eingetreten, oft über Wochen hinweg. Cloud-Kosten sind ein Echtzeitproblem, das wie ein Batch-Problem behandelt wird.

Zweitens besitzen die Teams, die das Verhalten der Workloads verstehen, nicht das Cloud-Budget, und die Teams, die das Budget besitzen, haben nicht den technischen Kontext, um zu wissen, welche Pods überprovisioniert sind. Die Optimierungsarbeit, die zwischen diesen beiden Funktionen liegt, hat oft keine klare Zuständigkeit und erhält deshalb zu wenig Aufmerksamkeit. Traditionelle Initiativen wie Dashboards und häufigere Reviews tragen wenig dazu bei, diese strukturelle Lücke zu schließen. Was sie letztlich schließt, ist die Verlagerung der Optimierung von periodischen, manuellen Eingriffen hin zu kontinuierlicher, automatisierter Anpassung.

Drittens ist die Komplexität tatsächlich hoch. Im großen Maßstab haben Organisationen es mit Hunderten von Nodes, mehreren GPU-Instanztypen und Dutzenden von Workloads mit unterschiedlichen Nachfrageprofilen zu tun. Manuelle Optimierung ist nicht möglich, denn die Angriffsfläche ist zu groß und verändert sich zu schnell, als dass ein Team sie mit Tabellenkalkulationen und monatlichen Reviews abdecken könnte.

Die nächste Phase: Effizienz als finanzielle Notwendigkeit

Die erste Phase der Cloud-Einführung drehte sich um Geschwindigkeit: schneller bereitstellen, schneller skalieren, schneller handeln. Infrastruktureffizienz war zweitrangig, und viele Organisationen arbeiten noch immer mit diesem Denkmodell.

Die zweite Phase, die für Organisationen mit signifikanter KI-Infrastruktur bereits begonnen hat, konzentriert sich auf Effizienz. Nicht, weil Effizienz tugendhafter geworden wäre, sondern weil die Kosten der Ineffizienz eine Schwelle überschritten haben, ab der sie sich materiell auf Margen, Kapitalallokation und Wettbewerbsposition auswirken. Die praktische Antwort besteht darin, Agenten einzusetzen, die Ressourcen autonom passend dimensionieren, die Instanzauswahl optimieren, Workloads an geeignete Compute-Tiers weiterleiten und GPU-Zuteilungen an die tatsächliche Nachfrage anpassen.

Die Situation hat eine gewisse Ironie. KI-Workloads erzeugen den größten Cloud-Kostendruck, den die Branche bisher erlebt hat, und KI-gestützte Automatisierung ist die einzige praktikable Möglichkeit, diesem Druck in dem Maßstab zu begegnen, in dem moderne Infrastruktur betrieben wird. Manuelle Optimierung kann mit der Veränderungsgeschwindigkeit nicht Schritt halten, denn die Schleife muss kontinuierlich geschlossen werden – nicht quartalsweise.

Was das für Finanz- und Engineering-Führungskräfte bedeutet

Engineering-Teams wurden historisch dafür belohnt, schnell zu liefern und Zuverlässigkeit sicherzustellen. Kosteneffizienz gehörte typischerweise nicht zu ihrer Verantwortung und war manchmal eine nachträglich auferlegte Einschränkung. Diese Anreizstruktur ergab Sinn, solange Rechenleistung im Verhältnis zum Wert der Engineering-Geschwindigkeit billig war.

Die Organisationen, die in der nächsten Phase der KI-Einführung im Vorteil sein werden, sind diejenigen, die die Schleife zwischen Infrastrukturentscheidungen und finanziellen Ergebnissen am schnellsten schließen. Das erfordert eine Veränderung dessen, was Engineering-Teams messen, wofür sie verantwortlich gemacht werden und wie schnell das Feedback zwischen Ausgaben und Verhalten die Menschen erreicht, die handeln können. Tools und Automatisierung müssen mit der Geschwindigkeit Schritt halten, mit der sich die Kosten von KI-Infrastruktur bewegen.

Token-Ökonomie

Die Welt läuft auf Tokens, und jeder Prompt, jede Completion, jede Agentenschleife verbraucht sie. Mit der beschleunigten KI-Einführung wird der Token-Verbrauch zum am schnellsten wachsenden Posten in Cloud-Budgets – nahezu ohne die Kosten-Transparenzinfrastruktur, die Organisationen im vergangenen Jahrzehnt für CPU und Speicher aufgebaut haben.

Das Problem beginnt bei der Modellklasse. Frontier-Modelle der großen Labore verlangen Premiumpreise auf Grundlage der Annahme, dass Workloads ihre höchsten Leistungs- und Reasoning-Fähigkeiten benötigen. In vielen Fällen ist dieses Maß an Leistungsfähigkeit jedoch unnötig. Ein großer Teil der Enterprise-Inferenz-Workloads – Zusammenfassung, Klassifizierung, Extraktion, interne Tools, Routing-Logik – besteht aus Aufgaben, bei denen ein gut abgestimmtes Open-Source-Modell gleichwertige Ergebnisse zu einem Bruchteil der Kosten pro Token liefert. Organisationen, die jede Anfrage standardmäßig an GPT-5 oder Claude Opus senden, nur weil diese in ersten Demonstrationen verwendet wurden, treffen keine durchdachten Architekturentscheidungen. Stattdessen führen sie erhebliche und oft unsichtbare Ineffizienzen im großen Maßstab ein, vor allem weil nur wenige Organisationen qualitätsbereinigte Kosten auf Anfrageebene messen.

Rate-Limiting verschärft dieses Problem zusätzlich. Wenn eine Organisation für Inferenz von einer Drittanbieter-API abhängig ist, kontrolliert der Anbieter die Durchsatzobergrenze. Diese Grenze interessiert sich nicht für Traffic-Spitzen, Produkteinführungen oder Batch-Jobs zum Quartalsende. Die natürliche Reaktion von Finanz- und Engineering-Führungskräften bestand darin, Tokens zu rationieren – durch Quoten, Zugangsbeschränkungen und verlangsamte Feature-Rollouts. Diese Reaktion wirkt verantwortungsvoll, ist aber nicht praktikabel. Sie ist das Äquivalent dazu, einem Engineering-Team zu sagen, dass der Laptop-Akku nur fünf Stunden hält und einmal pro Tag aufgeladen werden kann. Diese Rationierung löst das Kostenproblem nicht, sondern schafft zusätzliche Produktivitätsprobleme.

Die eigentliche Antwort besteht darin, optimierte Tokens zu finden und genug davon auszuführen, damit Rationierung irrelevant wird. Optimierte Tokens stammen aus Open-Source-Modellen, die auf der eigenen Infrastruktur einer Organisation bereitgestellt werden. Die Qualitätslücke zwischen Frontier-APIs und Open-Source-Alternativen hat sich drastisch verkleinert. Für einen erheblichen Teil der Produktions-Workloads ist sie praktisch geschlossen. Wenn Inferenz auf GPUs ausgeführt wird, nähern sich die Grenzkosten eines zusätzlichen Tokens null. Statt pro Aufruf zu zahlen, bezahlen Organisationen für Rechenkapazität – und wenn diese Kapazität gut ausgelastet ist, sind die Stückkosten grundlegend anders.

GPU-Flotten

Die nächste Herausforderung liegt im Management von GPU-Flotten, wo die Infrastrukturauslastung entscheidend für die Wirtschaftlichkeit von KI-Bereitstellungen wird. Eine GPU, die zwischen Inferenzanfragen ungenutzt bleibt, ist reine Verschwendung. Die Auslastungsprofile für KI-Inferenz folgen Nachfragekurven, die auf Flottenebene hochgradig vorhersehbar sind, selbst wenn sie auf Anfrageebene unvorhersehbar sind – etwa Geschäftszeiten in einer Region, ruhige Zeiten in einer anderen und ein nächtlicher Batch in einer dritten.

Eine Organisation mit Nutzern in Asien, Europa und den USA betreibt drei sich überschneidende Nachfragekurven auf derselben zugrunde liegenden Hardware. APAC erreicht Spitzenwerte, während die USA schlafen. Europa fährt hoch, wenn APAC herunterfährt. Die USA übernehmen, wenn Europa dunkel wird. Werden diese Regionen als isolierte Kapazitätspools behandelt, erscheint jede Region den Großteil des Tages unterausgelastet. Werden sie als eine einzige Flotte mit autonomer Workload-Verteilung betrachtet, laufen dieselben GPUs über alle drei Regionen hinweg mit deutlich höherer Auslastung. Zunehmend setzen Organisationen Ansätze wie GPU-Time-Sharing und Cross-Fleet-Routing auf der Inferenzebene ein, um Nachfrage und verfügbare Kapazität in Echtzeit dynamisch aufeinander abzustimmen, ungenutzte Infrastruktur zu reduzieren und den Bedarf an manuellen Eingriffen zu begrenzen. Plattformen wie kimchi.dev sind Teil einer breiteren Welle von Infrastruktur-Tools, die diese Art automatisierter Inferenzoptimierung unterstützen sollen.

Missverständnisse rund um Latenz

Ein Einwand, der in diesen Gesprächen immer wieder auftaucht, ist Latenz. Das Argument lautet, dass Inferenz-Workloads latenzsensibel seien und gemeinsam genutzte, verteilte GPU-Flotten die Antwortzeitanforderungen von Produktionsanwendungen nicht erfüllen könnten. Das ist weitgehend ein Missverständnis dessen, worauf es bei Inferenz ankommt. Die Kennzahl, die Nutzererlebnis und Durchsatzökonomie bestimmt, ist nicht die Time-to-First-Token, sondern die Gesamtzahl der pro Sekunde über die Flotte hinweg generierten Tokens. Eine Infrastruktur, die Durchsatz gegenüber der Latenz einzelner Anfragen priorisiert, bedient mehr Nutzer, verarbeitet mehr Workloads und kostet weniger pro Output-Token. Teams, die auf eine First-Token-Antwortzeit von 100 Millisekunden auf einer leicht ausgelasteten dedizierten GPU optimieren, lösen das falsche Problem und lassen zugleich den Großteil ihrer Rechenkapazität ungenutzt.

Token und FinOps

Token FinOps ist das Kapitel, das noch nicht geschrieben wurde. Es gibt keine etablierten Frameworks zur Erfassung qualitätsbereinigter Kosten pro Anfrage, keine Standard-Benchmarks für Substitutionsraten zwischen Open-Source- und Frontier-Modellen, keine Tools für kontinuierliche Token-Routing-Optimierung, die mit dem vergleichbar wären, was für CPU und Speicher existiert. Diese Lücke schließt sich, aber langsam. Die Organisationen, die diese Fähigkeiten jetzt aufbauen – durch die Kombination von Open-Source-Modellbereitstellung, On-Premises-Inferenz und autonomem Management von GPU-Flotten –, positionieren sich vor einer Kostenkurve, die mit wachsendem Volumen von KI-Workloads nur steiler werden wird. Diejenigen, die das nicht tun, riskieren, die KI-Einführung durch Kostendruck einzuschränken und zugleich nur begrenzte Zugewinne bei Produktivität und operativer Effizienz zu erzielen.