Kostenfalle KI So treibt die KI-Infrastruktur die Cloud-Rechnung in die Höhe

Ein Gastkommentar von Laurent Gil* 10 min Lesedauer

Anbieter zum Thema

Niedrige GPU-Auslastung, falsch dimensionierte Kubernetes-Cluster und ungeeignete Modell-Tiers verursachen vermeidbare Cloud-Kosten. Warum Automatisierung und kontinuierliche Optimierung wirtschaftlich zunehmend an Bedeutung gewinnen.

KI verändert die Wirtschaftlichkeit von Cloud-Infrastrukturen grundlegend. Wer Ressourcen weiterhin statisch bereitstellt, zahlt oft deutlich mehr als technisch erforderlich wäre.(Bild: ©  Zamrznuti tonovi - stock.adobe.com)
KI verändert die Wirtschaftlichkeit von Cloud-Infrastrukturen grundlegend. Wer Ressourcen weiterhin statisch bereitstellt, zahlt oft deutlich mehr als technisch erforderlich wäre.
(Bild: © Zamrznuti tonovi - stock.adobe.com)

Kubernetes-Cluster laufen mit einer durchschnittlichen CPU-Auslastung von 8 Prozent. Nicht 8 Prozent nachts, nicht 8 Prozent am Wochenende. 8 Prozent über das gesamte Jahr hinweg, gemessen bei Zehntausenden von Organisationen auf Amazon Web Services (AWS), Google Cloud Platform (GCP) und Azure. Diese Zahl stammt aus dem „2026 State of Kubernetes Optimization Report“ von Cast AI, der auf gemessenen Daten aus produktiven Clustern basiert und nicht auf Umfrage-Ergebnissen. Die Zahl deutet darauf hin, dass ein großer Teil der reservierten Rechenkapazität in der Produktion nicht in nutzbare Arbeit umgesetzt wird, während die Cloud-Rechnung weiter wächst.

Das ist die Ausgangslage, bevor KI-Workloads überhaupt ins Spiel kommen. Derselbe Bericht stellte eine durchschnittliche Speicherauslastung von 20 Prozent fest, nach 23 Prozent im Vorjahr, sowie eine durchschnittliche GPU-Auslastung von 5 Prozent in den analysierten Kubernetes-Clustern von Unternehmen.

Das sind die Kosten von zu hoch angesetzten Ressourcen

Cloudbasierte Infrastruktur hat die Bereitstellung radikal vereinfacht. Dadurch hat sie zugleich einen Großteil der Reibung beseitigt, die früher Effizienz erzwang. Organisationen müssen Kapazitäten nicht mehr Monate im Voraus planen, Hardware-Käufe rechtfertigen oder mit den Folgen einer schlechten Prognose leben. Teams können einfach mehr bereitstellen. Das Ergebnis ist eine Kultur der Überprovisionierung, die fest in der Arbeitsweise von Engineering-Teams verankert ist: Ressourcen-Anforderungen im Sprint Planning hoch ansetzen, sie selten erneut prüfen und ungenutzte Reserven als akzeptable Kosten für Zuverlässigkeit betrachten.

Während des größten Teils des vergangenen Jahrzehnts war dieser Zielkonflikt beherrschbar. Die Verschwendung war real, aber diffus – verteilt über CPU- und Speicherzuweisungen, die schwer zu messen und leicht zu ignorieren waren.

FinOps entstand als Disziplin, um diese Verschwendung sichtbar zu machen und zu steuern. Das hat geholfen. Doch FinOps behandelte weitgehend das Symptom und nicht die Ursache: eine Infrastruktur, die strukturell schwer in dem Tempo zu optimieren ist, in dem sie sich verändert. Der Bericht stellte außerdem fest, dass die CPU-Überprovisionierung im Jahresvergleich von 40 Prozent auf 69 Prozent gestiegen ist, während die Speicherüberprovisionierung bei 79 Prozent lag – ein Zeichen dafür, dass die Lücke zwischen bereitgestellter Kapazität und dem, was Workloads anfordern, größer wird, nicht kleiner.

KI-Workloads verändern die Ökonomie

Bei KI-Infrastruktur erhält dasselbe strukturelle Problem einen deutlich höheren Kostenmultiplikator.

GPU-Rechenleistung ist per Definition teuer. Mit steigender Nachfrage nach beschleunigter Rechenleistung ist ungenutzte Kapazität nicht mehr nur eine operative Ineffizienz. Sie wird zu einem Margenproblem.

In den im Bericht analysierten Kubernetes-Clustern von Unternehmen lag die durchschnittliche GPU-Auslastung bei 5 Prozent, gemessen als Anteil der bereitgestellten GPU-Rechenzyklen, die innerhalb eines Zeitraums von 24 Stunden nutzbaren Output erzeugten. Der Bericht schließt KI-Lab-Cluster aus, in denen GPUs typischerweise intensiver genutzt werden. Praktisch bedeutet das: Die bereitgestellte GPU-Kapazität läuft dem nutzbaren GPU-Compute-Output weit voraus.

Das Nachfrageprofil macht es noch schlimmer. Bei KI-Inferenz reicht eine dynamische Anzahl von Replikaten nicht aus: Standardmäßig gilt

1 GPU = 1 Modell.

Wenn die Kapazität ausgeschöpft ist, kann nicht immer schnell eine neue GPU hinzugefügt werden, weil Kapazität möglicherweise nicht verfügbar ist. Statische Bereitstellung, die bereits für Kubernetes das falsche Modell war, passt besonders schlecht zu KI-Infrastruktur, bleibt aber verbreitet, weil es nur wenige einfache Optionen gibt. Deshalb gewinnt GPU-Sharing an Bedeutung. Für kleine Modelle oder große GPUs werden Mehr-Instanzen-GPU (MIG) und andere GPU-Sharing-Techniken zum Pendant von Vertical Pod Autoscaler (VPA) und Horizontal Pod Autoscaler (HPA) für GPUs.

Dann gibt es noch die Token-Optimierung. Die Unterschiede zwischen Modell-Tiers können bei der Preisgestaltung pro Token eine ganze Größenordnung ausmachen. Organisationen, die jede Anfrage standardmäßig an ein Top-Tier-Modell weiterleiten, obwohl günstigere Tiers bei vielen Anfragen den Qualitätsstandard erfüllen würden, treffen keinen technischen Kompromiss. Sie geben strukturell zu viel aus, und zwar auf eine Weise, die ohne Kostenzuordnung auf Anfrage-Ebene und Service-Level-Objective-Scoring (SLO) schwer zu erkennen ist. Die für Cloud Computing entwickelten Standard-FinOps-Tools haben mit den Kosten von LLM-APIs nicht Schritt gehalten.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

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 größer. Dafür gibt es strukturelle Gründe.

Erstens ist die Feedback-Schleife zu langsam. Bis eine Kostenanomalie in einem Dashboard oder einem Quartalsreview sichtbar wird, ist die Verschwendung bereits entstanden, oft über Wochen hinweg. Cloud-Kosten sind ein Echtzeitproblem, das als Batch-Problem behandelt wird.

Zweitens besitzen die Menschen, die das Verhalten der Workloads verstehen, nicht das Cloud-Budget, und die Menschen, die das Budget besitzen, haben nicht den technischen Kontext, um zu wissen, welche Pods überprovisioniert sind, welche Modelle teure Kapazität verbrauchen oder welche Workloads auf eine effizientere Platzierung verschoben werden könnten.

Die Optimierungsarbeit, die zwischen diese beiden Gruppen fällt, bekommt von niemandem Zeit. Bessere Dashboards schließen diese Lücke nicht. Häufigere Reviews schließen sie ebenfalls nicht. Das Einzige, was sie schließt, ist, die Optimierungsschleife von periodischer menschlicher Überprüfung zu kontinuierlicher automatisierter Anpassung zu verlagern.

Drittens ist die Komplexität tatsächlich schwierig. Im großen Maßstab verwalten Organisationen Hunderte von Nodes, mehrere GPU-Instanztypen und Dutzende von Workloads mit unterschiedlichen Nachfrageprofilen. Manuelle Optimierung ist kein Prozess; sie ist eine Fiktion.

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 Spot-Analyse des Berichts verdeutlicht den Punkt: Über weite Teile des Jahres 2025 liefen weniger als 2 Prozent der GPUs auf Spot Instances, während Verfügbarkeit und Preise je nach Region und Instanztyp stark variierten.

Die nächste Phase: Effizienz als finanzielles Gebot

Die erste Phase der Cloud-Einführung drehte sich um Geschwindigkeit: schneller bereitstellen, schneller skalieren, schneller vorankommen. Infrastruktureffizienz war zweitrangig. Die meisten Organisationen arbeiten noch immer mit diesem mentalen Modell.

Die zweite Phase, die für Organisationen mit bedeutender KI-Infrastruktur bereits begonnen hat, konzentriert sich auf Effizienz. Nicht, weil Effizienz tugendhafter geworden wäre, sondern weil die Kosten von Ineffizienz eine Schwelle überschritten haben, ab der sie Margen, Kapitalallokation und Wettbewerbsposition spürbar beeinflussen.

Die praktische Antwort besteht darin, Automatisierung zu nutzen, um Ressourcen richtig zu dimensionieren, die Auswahl von Instanzen zu optimieren, Workloads an geeignete Compute-Tiers zu routen und die GPU-Zuweisung an die tatsächliche Nachfrage anzupassen.

Im Bericht reduzierten Organisationen, die automatisiertes Rightsizing einsetzten, ihren bereitgestellten CPU-Footprint im Durchschnitt um etwa 50 Prozent. Das ist eine Reduzierung des Footprints, nicht die Behauptung, dass die gesamten Cloud-Ausgaben im selben Umfang sinken.

Die Ironie ist real: KI-Workloads erzeugen einen der größten Cloud-Kostendrücke, die die Branche bisher gesehen hat, und KI-gesteuerte Automatisierung ist eine der wenigen praktikablen Möglichkeiten, ihn in dem Maßstab zu adressieren, in dem moderne Infrastruktur betrieben wird. Manuelle Optimierung kann mit der Änderungsrate nicht Schritt halten. Die Schleife muss kontinuierlich geschlossen werden, nicht quartalsweise.

Was das für Führungskräfte in Finance und Engineering bedeutet

Der Wandel, der im Gange ist, ist nicht in erster Linie technisch. Er ist organisatorisch:

Engineering-Teams wurden historisch dafür belohnt, schnell zu liefern und Zuverlässigkeit aufrechtzuerhalten. Kosteneffizienz war das Problem anderer oder schlimmstenfalls eine Einschränkung, die nachträglich angewendet wurde. Diese Anreizstruktur ergab Sinn, solange Compute im Verhältnis zum Wert von Engineering-Geschwindigkeit günstig war.

Die Organisationen, die in der nächsten Phase der KI-Einführung einen Vorteil haben werden, sind nicht unbedingt diejenigen mit den größten Infrastruktur-Budgets. Es sind diejenigen, die die Schleife zwischen Infrastrukturentscheidungen und finanziellen Ergebnissen am schnellsten schließen.

Das erfordert zu verändern, was Engineering-Teams messen, wofür sie verantwortlich gemacht werden und wie schnell das Feedback zwischen Ausgaben und Verhalten die Menschen erreicht, die darauf reagieren können. Die Tools und die Automatisierung müssen mit der Geschwindigkeit Schritt halten, mit der sich die Kosten von KI-Infrastruktur bewegen.

Die nächste Phase der KI-Einführung wird nicht dadurch definiert sein, wie viel Unternehmen für Infrastruktur ausgeben. Sie wird dadurch definiert sein, wie effizient sie diese nutzen.

Token-Ökonomie: Das Kapitel, das noch nicht geschrieben wurde

Die Welt läuft zunehmend auf Tokens. Jeder Prompt, jede Completion und jede Agentenschleife verbraucht sie. Und während sich die KI-Einführung beschleunigt, wird der Token-Verbrauch zu einem sichtbareren Posten in Cloud-Budgets, oft ohne die Infrastruktur für Kostentransparenz, die Organisationen im vergangenen Jahrzehnt für CPU und Speicher aufgebaut haben.

Das Problem beginnt beim Modell-Tier. Frontier-Modelle der großen Labs sind auf einem Niveau bepreist, das davon ausgeht, dass der Anwendungsfall den Qualitätsaufschlag rechtfertigt. Viele tun das nicht. Ein großer Teil der Enterprise-Inferenz-Workloads – Zusammenfassung, Klassifizierung, Extraktion, interne Tools und Routing-Logik – sind Aufgaben, bei denen ein gut abgestimmtes Open-Source-Modell ausreichende Ergebnisse zu einem Bruchteil der Kosten pro Token liefern kann.

Der Unterschied ist nicht immer marginal. Organisationen, die jede Anfrage standardmäßig an ein Frontier-Modell weiterleiten, weil dieses im Demo verwendet wurde, treffen nicht immer eine überlegte Architekturentscheidung. Sie lassen möglicherweise in großem Maßstab Geld liegen, unsichtbar, weil nichts die qualitätsbereinigten Kosten pro Anfrage verfolgt.

Rate-Limiting verstärkt das. Wenn eine Organisation für Inferenz von einer Drittanbieter-API abhängig ist, kontrolliert der Anbieter die Durchsatzobergrenze. Diese Obergrenze passt sich nicht automatisch an eine Traffic-Spitze, einen Produktlaunch oder einen Batch-Job zum Quartalsende an. Die natürliche Reaktion von Finance- und Engineering-Führungskräften war, Tokens zu rationieren: Quoten setzen, Zugang beschränken und Funktionen langsam ausrollen. Diese Reaktion kann verantwortungsvoll wirken, riskiert aber, Produktivität zu besteuern, statt das zugrunde liegende Kostenproblem zu lösen.

Die tragfähigere Antwort ist, Tokens zu optimieren, statt sie einfach nur zu rationieren, und genügend effiziente Inferenzkapazität zu betreiben, damit Rationierung weniger notwendig wird.

Optimierte Tokens können aus Open-Source-Modellen kommen, die auf kontrollierter Infrastruktur bereitgestellt werden. Die Qualitätslücke zwischen Frontier-APIs und Open-Source-Alternativen hat sich für viele eng umrissene Produktionsaufgaben verringert. Wenn Inferenz auf gut ausgelasteter GPU-Kapazität läuft, kann die Unit Economics ganz anders aussehen als bei API-basierter Preisgestaltung. Die Organisation zahlt nicht pro Aufruf; sie zahlt für Compute-Kapazität, und der Wert dieser Kapazität hängt davon ab, wie effizient sie genutzt wird.

GPU-Flottenmanagement wird zu einer zentralen Kostendisziplin

Das führt die Diskussion zum GPU-Flottenmanagement, wo die Ökonomie besonders wichtig wird. Eine GPU, die zwischen Inferenzanfragen wartet, ist unproduktive Kapazität. Die Auslastungsprofile für KI-Inferenz folgen Nachfragekurven, die auf Flottenebene vorhersehbar sein können, selbst wenn sie auf Anfrage-Ebene unvorhersehbar sind:

Geschäftszeiten in einer Region, ruhige Stunden in einer anderen und ein nächtlicher Batch in einer dritten. Eine Organisation mit Nutzerinnen und Nutzern in Asien, Europa und den USA betreibt drei überlappende Nachfragekurven auf derselben zugrunde liegenden Hardware.

APAC erreicht seinen Peak, während die USA schlafen. Europa fährt hoch, während APAC herunterfährt. Die USA übernehmen, wenn Europa ruhig wird. Wenn sie als isolierte Kapazitätspools behandelt werden, wirkt jede Region über weite Teile des Tages unterausgelastet. Als eine einzige Flotte mit autonomer Workload-Verteilung betrachtet, können dieselben GPUs über alle drei Regionen hinweg mit deutlich höherer Auslastung laufen.

Latenz ist nicht die einzige Kennzahl, die zählt

Ein Einwand kommt in diesen Gesprächen immer wieder auf Latenz. Das Argument lautet, dass Inferenz-Workloads latenzsensibel sind und dass geteilte, verteilte GPU-Flotten die Anforderungen von Produktionsanwendungen an Antwortzeiten nicht erfüllen können.

Diese Sorge ist in einigen Anwendungsfällen berechtigt, wird aber oft zu eng gefasst. Die Kennzahl, die Nutzererfahrung und Durchsatzökonomie bestimmt, ist nicht nur Time-to-First-Token. Es sind auch die insgesamt pro Sekunde generierten Tokens über die gesamte Flotte hinweg. Infrastruktur, die Durchsatz priorisiert und zugleich angemessene Latenzziele erfüllt, kann mehr Nutzer bedienen, mehr Workloads verarbeiten und weniger pro Output-Token kosten.

Teams, die auf die schnellstmögliche First-Token-Antwort auf einer schwach ausgelasteten dedizierten GPU optimieren, optimieren möglicherweise für die falsche Einschränkung, wenn ein Großteil der Compute-Kapazität ungenutzt bleibt.

Token-FinOps ist das fehlende Framework

Token-FinOps ist das Kapitel, das noch nicht geschrieben wurde. Es gibt keine etablierten Frameworks zur Verfolgung qualitätsbereinigter Kosten pro Anfrage, keine Standard-Benchmarks für Substitutionsraten zwischen Open-Source- und Frontier-Modellen und kein ausgereiftes Tooling für kontinuierliche Token-Routing-Optimierung, das mit dem vergleichbar wäre, was es für CPU und Speicher gibt.

Diese Lücke schließt sich, aber langsam. Organisationen, die diese Fähigkeiten jetzt aufbauen und Open-Source-Modellbereitstellung, kontrollierte Inferenzinfrastruktur und autonomes GPU-Flottenmanagement kombinieren, positionieren sich vor einer Kostenkurve, die mit wachsendem KI-Workload-Volumen nur steiler werden wird. Der Rest riskiert, weiterhin Tokens zu rationieren und sich zugleich zu fragen, warum sich die Produktivitätsgewinne durch KI nicht im erwarteten Tempo materialisieren.

Über den Autor:
Laurent Gil ist Co-Founder und President von CAST AI. Das Unternehmen unterstützt Organisationen dabei, Kubernetes zu automatisieren und Cloud-native Anwendungen effizienter zu betreiben.

Mit CAST AI können Unternehmen ihre Cloud-Infrastruktur autonom optimieren, operative Komplexität reduzieren und Cloud-Kosten innerhalb weniger Minuten deutlich senken.

Laurent setzt sich dafür ein, Cloud-Management intelligenter, automatisierter und kosteneffizienter zu gestalten.

Damit unterstützt er Engineering-, DevOps- und Cloud-Teams beim Aufbau skalierbarer und leistungsfähiger Cloud-Umgebungen.

Bildquelle: CAST AI

(ID:50891793)