Die Inferenz-Rechnung, die niemand budgetiert hat

16 Mai 2026

5 Min. Lesezeit

Der State of FinOps 2026 Report ist da. Eine Zahl darin trifft jedes Team, das Modelle produktiv betreibt: 73 Prozent der befragten Organisationen berichten, dass ihre KI-Kosten die ursprüngliche Budgetplanung gesprengt haben. Wer Inferenz-Workloads verantwortet, muss die Rechnung jetzt anders aufsetzen, bevor sie die nächste Quartalsplanung diktiert.

Das Wichtigste in Kürze

Der Report liefert die Zahlen: Laut State of FinOps 2026 ist der Anteil der FinOps-Teams, die KI-Ausgaben aktiv steuern, in zwei Jahren von 31 auf 98 Prozent gestiegen. KI-Kostenmanagement ist die meistgesuchte neue Kompetenz der Branche.
Inferenz ist der Kostenblock: Die FinOps Foundation verortet 80 bis 90 Prozent der KI-Ausgaben in der Inferenz, nicht im Training. Trotzdem liegt die GPU-Auslastung im laufenden Betrieb oft bei 15 bis 30 Prozent.
Vier Schritte ordnen die Rechnung: Kosten pro Token messen, Auslastung sichtbar machen, Modell auf die Aufgabe zuschneiden, Provider-Mix öffnen. In dieser Reihenfolge.

Verwandt:KI-Ausgaben treiben FinOps-Teams in neue Budget-Fallen / KI frisst Strom, die Cloud bekommt die Rechnung

Was der FinOps-Report 2026 schwarz auf weiß zeigt

Der jährliche State of FinOps Report der FinOps Foundation basiert auf knapp 1.200 Praktikern, die zusammen mehr als 76 Milliarden Euro jährliche Cloud-Ausgaben verantworten. Die Ausgabe 2026 macht KI zur am schnellsten wachsenden Kostenkategorie. Bei KI-affinen Unternehmen liegt der Anteil der KI-Workloads am Cloud-Budget bei 18 Prozent, 2023 waren es noch vier.

Interessant ist der Sprung beim Verantwortungsbereich. Vor zwei Jahren steuerte knapp ein Drittel der FinOps-Teams überhaupt KI-Spend, jetzt sind es fast alle. Das ist keine Modeerscheinung, das ist eine Reaktion auf Rechnungen, die niemand vorhergesagt hat. Wer ein Modell hinter einen Endpunkt hängt, baut sich eine Kostenstelle, die mit jedem Request mitwächst und im Architektur-Review trotzdem oft unter ferner liefen läuft.

Der eigentliche Aufreger steckt aber nicht im Wachstum, sondern in der Verschwendung. Branchenanalysen zur Inferenz-Ökonomie zeigen 2026 ein konsistentes Bild: Ein erheblicher Teil des GPU-Budgets bezahlt Hardware, die nichts Produktives tut.

35 bis 60 %

des GPU-Cloud-Budgets eines durchschnittlichen KI-Teams gelten als vermeidbar – verursacht durch Leerlauf, falsch dimensionierte Modelle und ungenutzte Reservierungen.

Quelle: Branchenanalysen zur Inferenz-Ökonomie, 2026

Drei Stellen, an denen GPU-Geld verdunstet

Bevor man optimiert, lohnt der ehrliche Blick darauf, wohin das Geld tatsächlich fließt. In den meisten produktiven Inferenz-Setups sind es dieselben drei Lecks.

Erstens: Leerlauf. Eine GPU im Inferenz-Betrieb läuft selten an der Auslastungsgrenze. 15 bis 30 Prozent Auslastung sind ein verbreiteter Wert, abgerechnet wird trotzdem die volle Stunde. Alles unter 50 Prozent ist im Grunde rückholbares Geld. Das gilt besonders für Endpunkte mit ungleichmäßigem Traffic, die nachts genauso bereitstehen wie zur Mittagsspitze. Wer den Strom-Aspekt dieser Dauerbereitschaft unterschätzt, findet ihn in der Energie-Rechnung der Cloud wieder.

Zweitens: zu viel Präzision. Viele Deployments fahren Modelle in FP16, obwohl die Aufgabe das nicht braucht. FP8-Quantisierung auf einem H100 senkt laut Hardware-Benchmarks die Kosten pro Million Token deutlich, bei sauber geprüfter Qualität ist das für die meisten Produktiv-Workloads die bessere Wahl. Volle Präzision ist eine Entscheidung, kein Default.

Drittens: der Hyperscaler-Aufschlag. Dieselbe H100-Karte kostet bei den großen Anbietern ein Mehrfaches dessen, was spezialisierte AI-Clouds aufrufen. Das heißt nicht, dass man alles verlagern soll. Es heißt, dass ein gleichmäßig laufender Inferenz-Endpunkt auf einem Hyperscaler-On-Demand-Preis schlicht zu teuer geparkt ist.

Der Vier-Schritte-Pfad zu kalkulierbaren Inferenz-Kosten

Die Reihenfolge ist hier kein Stilmittel. Wer mit Schritt drei beginnt, optimiert ein Modell, dessen Kosten er nicht beziffern kann. Dieser Pfad funktioniert für ein bestehendes Setup mit einer Hand voll produktiver Endpunkte.

FinOps-Pfad für Inferenz-Workloads

Schritt 1

Kosten pro Token messen. Pro Modell und Endpunkt ein Tag, dann Ausgaben durch verarbeitete Token teilen. Ohne diese Kennzahl ist jede weitere Optimierung Bauchgefühl. Ein Cost-Forecast im Pull-Request macht teure Änderungen sichtbar, bevor sie live gehen.

Schritt 2

Auslastung sichtbar machen. Ein GPU-Utilization-Dashboard pro Endpunkt zeigt den Leerlauf. Dynamic Batching und Caching heben die Auslastung erfahrungsgemäß von rund 30 auf 70 Prozent und drücken die Inferenzkosten entsprechend.

Schritt 3

Modell auf die Aufgabe zuschneiden. FP8-Quantisierung mit Qualitäts-Benchmark, ein kleineres Modell für einfache Routing- oder Klassifikations-Tasks, Speculative Decoding wo Latenz zählt. Nicht jeder Request braucht das Flaggschiff.

Schritt 4

Provider-Mix öffnen. Grundlast auf Reserved- oder Committed-Preise, Spitzen über Autoscaling, stabile inferenz-lastige Workloads auf spezialisierte AI-Clouds prüfen. Preisbewegungen wie die rund achtprozentige Compute-Senkung bei Google Cloud im ersten Quartal 2026 gehören in den regelmäßigen Abgleich.

Ich habe mehr als einmal einen Nachmittag in die Modellauswahl gesteckt, nur um danach festzustellen, dass der eigentliche Hebel ein nicht konfiguriertes Autoscaling war. Wie so oft sitzt das große Geld an der unscheinbaren Stelle.

Was beim Sparen trägt und was zurückschlägt

Kostenoptimierung kann auch nach hinten losgehen. Diese Muster haben sich in der Praxis bewährt – und diese hier holen das gesparte Geld als Folgekosten zurück.

Was trägt

Kosten pro Token als sichtbare Team-Kennzahl, nicht als Quartals-Report
Quantisierung immer mit Qualitäts-Benchmark gegen das Originalmodell
Autoscaling, das auf echte Last reagiert statt auf eine Schätzung
Reservierte Kapazität für die berechenbare Grundlast, On-Demand nur für Spitzen

Was zurückschlägt

Reines Spot-Only ohne Fallback, wenn die Kapazität mitten im Traffic wegbricht
Quantisierung ohne Prüfung, die still die Antwortqualität senkt
Modell-Downsizing, das Support-Tickets statt GPU-Stunden produziert
Multi-Cloud-Verlagerung ohne die Egress-Gebühren mit einzurechnen

Der teuerste Teil einer Inferenz ist nicht die GPU-Stunde. Es ist die GPU-Stunde, in der nichts gerechnet wird.

Der Report 2026 macht aus FinOps für KI keine Kür mehr. Wenn fast jedes FinOps-Team inzwischen KI-Spend steuert, wird die Frage im nächsten Architektur-Review nicht lauten, ob ein Modell funktioniert. Sie lautet, was eine Antwort kostet. Wer diese Zahl parat hat, diskutiert auf Augenhöhe.

Häufige Fragen

Warum ist Inferenz teurer als das Training?

Training ist ein einmaliger, abgrenzbarer Aufwand. Inferenz läuft dauerhaft und skaliert mit der Nutzung. Die FinOps Foundation verortet deshalb 80 bis 90 Prozent der KI-Ausgaben in der Inferenz. Jeder zusätzliche Nutzer und jeder längere Prompt erhöht die laufende Rechnung.

Was ist die wichtigste erste Kennzahl?

Kosten pro Token, getrennt nach Modell und Endpunkt. Sie verbindet die Cloud-Rechnung mit dem fachlichen Nutzen und macht jede weitere Optimierung überhaupt erst bewertbar. Ohne diese Zahl optimiert man im Dunkeln.

Senkt Quantisierung immer die Antwortqualität?

Nicht zwangsläufig. FP8 liefert für viele Produktiv-Workloads praktisch gleichwertige Ergebnisse bei deutlich niedrigeren Kosten. Entscheidend ist ein Qualitäts-Benchmark gegen das Originalmodell, bevor die quantisierte Variante live geht.

Lohnen sich spezialisierte AI-Clouds gegenüber den Hyperscalern?

Für stabile, inferenz-lastige Workloads häufig ja, weil die GPU-Stundenpreise dort spürbar niedriger liegen. Gegenzurechnen sind Egress-Gebühren, Speicherkosten und Mindestlaufzeiten. Für stark schwankende Last oder enge Integration in einen Hyperscaler-Stack bleibt der etablierte Anbieter oft sinnvoll.

Wie verhindert man, dass Spot-Instanzen den Betrieb stören?

Spot eignet sich für unterbrechbare Aufgaben wie Batch-Inferenz, nicht für latenzkritische Endpunkte ohne Absicherung. Ein Fallback auf On-Demand-Kapazität und eine Begrenzung des Spot-Anteils an der Gesamtlast halten den Betrieb stabil, wenn die Kapazität wegbricht.