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.
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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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.