9 Min. Lesezeit

Eine H100-Stunde kostet bei AWS rund 11 Euro, bei Google etwa 10, bei Lambda Labs unter 3,70. Wer Inferenz auf einem Hyperscaler einkauft und beim nächsten Quartalsabschluss erklären muss, warum die GPU-Rechnung 40 Prozent über dem Plan liegt, hat selten ein Modellproblem. Er hat ein Budgetierungsproblem, das im Architektur-Entwurf entstanden ist.

Das Wichtigste in Kürze

• Inferenz ist kein Trainings-Cousin: Trainingsläufe sind planbare Batch-Workloads, Inferenz ist Last über die Zeit. Wer beide mit derselben Reserved-Capacity-Logik budgetiert, zahlt entweder Leerstand oder On-Demand-Aufpreise. Die Trennung der beiden Kostenarten gehört in jede FinOps-Tabelle ab Tag eins.
• Multi-Cloud ist Preis-Hebel, kein Selbstzweck: Zwischen Hyperscaler-GPU-Stunde und Neocloud-Stunde liegen Faktor 2 bis 3. Wer Workloads nach Latenz-Toleranz, Datenresidenz und Compliance-Klasse trennt, kann die preissensiblen Lasten gezielt aus dem Hyperscaler ziehen.
• Unit-Economics schlagen Capacity-Planning: Kosten pro 1.000 Tokens, pro Anfrage oder pro aktivem Nutzer sind die einzige Steuerungseinheit, die im Vorstand trägt. Ohne diese Metrik bleibt jede GPU-Diskussion ein Streit über Server-Mieten.

VerwandtDie Inferenz-Rechnung, die niemand budgetiert hat  /  38 Prozent weniger Cloud-Kosten im Maschinenbau

Wo das Budget tatsächlich verbrannt wird

Drei Posten füllen jede GPU-Rechnung, die ich in den letzten Monaten gesehen habe. Erstens: Idle-Zeit auf reservierter Hardware. Wer eine H100-Instanz für 730 Stunden im Monat reserviert hat und sie nur 220 Stunden tatsächlich auslastet, zahlt 510 Stunden Leerstand. Zweitens: On-Demand-Bursts in Lastspitzen, weil die Reserved-Kapazität nicht skaliert. Drittens: Egress-Kosten zwischen Regionen, wenn Modell-Gewichte hin- und hergeschoben werden.

Keiner dieser drei Posten ist im Modell sichtbar. Sie entstehen in der Architektur. Wer Inferenz wie einen Web-Service skaliert, also Pods rauf und runter über Kubernetes, bekommt die ersten beiden Posten geliefert. Wer Multi-Region für Latenz fährt, ohne die Modell-Gewichte regional vorzuhalten, bekommt den dritten obendrauf.

Das harte Lernen: Inferenz hat eine Lastkurve, die sich nicht aus dem Trainingslauf ableiten lässt. Sie hängt am Nutzerverhalten, an der Tageszeit, an Marketing-Wellen. Capacity-Planning ohne Lastkurven-Daten ist Glücksspiel mit dreistelligem Stundensatz.

Drei Preis-Tableaus, die jede FinOps-Tabelle braucht

Wer Multi-Cloud-Inferenz steuern will, braucht drei Preis-Tableaus parallel. Stand Q2 2026, alle Preise als Richtwert, Verhandlungssituation pro Account zwingend prüfen.

Die nominale Spanne von Faktor 3 zwischen Hyperscaler-On-Demand und Neocloud ist nicht der Endpunkt. Hyperscaler bündeln Netzwerk, Storage und Identity-Stack, was die effektive Differenz schrumpfen lässt. Neoclouds verlangen, dass Identity, Monitoring und VPC-Anbindung selbst gebaut werden. Wer das aufrechnet, landet bei realer Differenz zwischen Faktor 1,8 und Faktor 2,4.

Workload-Sortierung als FinOps-Hebel

Nicht jede Inferenz-Last gehört auf denselben Stack. Eine Sortierung in vier Klassen reicht in der Praxis aus, um 30 bis 50 Prozent der Kosten zu adressieren.

Die Sortierung schlägt durch, sobald sie verbindlich ist. Wer sie als Empfehlung kommuniziert, bekommt nach drei Monaten dieselbe Verteilung wie vorher, weil Teams den Pfad des geringsten Widerstands nehmen. Sortier-Regeln gehören in den Deployment-Workflow, nicht in ein Confluence-Dokument.

Vom Reserved-Block zur Sliding-Reserve

Klassische Reserved-Capacity ist für GPU-Inferenz die falsche Antwort. Drei-Jahres-Commitments für H100 sind selten amortisiert, weil die GPU-Generation in 18 Monaten überholt ist. Bessere Architektur: eine Sliding-Reserve aus 30 bis 50 Prozent Reserved als Sockel, 20 bis 30 Prozent Savings Plans für Flexibilität, der Rest On-Demand oder Spot.

Was im Reifeplan oft fehlt: ein expliziter Punkt zu Lieferzeiten. H100-Kapazität ist 2026 in einzelnen Regionen weiterhin knapp. Wer im Plan keine Puffer für Provisionierungs-Latenz einbaut, verschiebt das Problem auf die Operations-Ebene.

Unit-Economics als Steuerungs-Currency

Die ehrlichste FinOps-Diskussion im Vorstand findet nicht über GPU-Stunden statt, sondern über Kosten pro Output-Einheit. Drei Metriken haben sich in der Praxis bewährt: Kosten pro 1.000 Output-Tokens, Kosten pro abgeschlossener Nutzeranfrage, Kosten pro aktivem Nutzer und Monat. Welche davon greift, hängt am Produkt.

Ein Beispiel aus einem Kunden-Setup: Eine RAG-Anwendung mit etwa 80.000 Anfragen pro Tag lag bei rund 0,034 EUR pro Anfrage, davon 0,022 EUR Inferenz, 0,008 EUR Vektor-Retrieval, 0,004 EUR Logging und Observability. Erst die Aufschlüsselung machte sichtbar, dass das Logging einen Anteil hatte, der pro Quartal um 18 Prozent gewachsen war. Die Reduktion lag dort, nicht im Modell.

Wer Unit-Economics nicht jeden Monat reportet, verliert nach zwei Quartalen die Steuerungshoheit. Dann kommt der Cost-Cutting-Auftrag aus dem CFO-Büro, und die Auswahl wird hart: Modell verkleinern, Provider wechseln, Feature streichen.

Architektur-Entscheidungen mit dem größten Hebel

Drei architektonische Hebel wirken überdurchschnittlich. Erstens: Modell-Routing auf Anfrage-Ebene. Nicht jede Anfrage braucht das Top-Modell. Ein Klassifizierer vorne, der einfache Anfragen auf ein kleineres Modell oder auf Open-Source-Inferenz routet, drückt die Mischkalkulation um 20 bis 35 Prozent.

Zweitens: Caching auf Embedding- und Antwort-Ebene. Bei FAQ-nahen Use Cases liegen wiederkehrende Anfragen oft im zweistelligen Prozentbereich. Ein semantischer Cache mit kontrollierter TTL spart pro Hit den vollen Modell-Round-Trip.

Drittens: Batch-Aggregation auf API-Ebene. Wer Inferenz-Anfragen einzeln durchschiebt, zahlt pro Token den Premium-Tarif. Wer auf der Service-Schicht Mikro-Batches mit 50ms-Fenster aggregiert, hebt den GPU-Durchsatz pro Stunde um Faktor 2 bis 3 ohne Modell-Eingriff.

Diese drei Hebel sind nicht spektakulär. Sie sind Engineering-Routine. Das macht sie planbar und wiederholbar.

Was im FinOps-Reifegrad-Modell trägt

Drei Indikatoren zeigen, ob ein Team die Inferenz-Kosten im Griff hat. Erstens: Die FinOps-Verantwortung sitzt im Engineering, nicht im Controlling. Wer Cost-Reviews als externen Audit-Termin erlebt, hat keine Steuerung. Wer sie als Architektur-Review-Standard betreibt, hat sie.

Zweitens: Die Token-Kosten pro Feature sind im Produkt-Backlog sichtbar. Product Manager, die nicht wissen, was eine neue KI-Funktion an variablen Kosten erzeugt, planen blind.

Drittens: Es gibt einen geübten Pfad, ein Modell zu wechseln. Wer 18 Monate auf einem Provider sitzt und keinen dokumentierten Re-Deploy-Pfad hat, zahlt den Lock-in-Aufschlag, ohne ihn zu sehen.

Häufige Fragen

Lohnt sich Multi-Cloud-Inferenz auch unter 50.000 EUR Monatsbudget?

Selten. Der Mehraufwand für Identity-Föderation, Monitoring und VPC-Routing rechtfertigt sich erst, wenn die Einsparung den Engineering-Aufwand pro Quartal überschreitet. Unter rund 50.000 EUR Monatsbudget ist Single-Hyperscaler mit sauberem Reserved-Mix der pragmatischere Weg.

Wie wird ein realistisches Unit-Cost-Modell aufgesetzt?

Mit drei Komponenten: Inferenz-Kosten pro Token aus Provider-Bills, Infrastrukturkosten pro Anfrage aus Tracing-Daten, Logging- und Observability-Kosten aus Cost-Allocation-Tags. Wer Tags nicht durchgängig setzt, verliert die Zuordnung und schätzt im Excel.

Was ist der größte Fehler beim Wechsel zu Neoclouds?

Den Identity- und Netzwerk-Stack zu unterschätzen. Hyperscaler stellen IAM, VPC-Peering und Service-Mesh als integrierte Bausteine. Neoclouds verlangen, dass diese Bausteine selbst gebaut oder mit Cross-Cloud-Tools überbrückt werden. Wer diesen Aufwand nicht einplant, frisst die Einsparung in den ersten drei Monaten wieder auf.

Wie schnell amortisieren sich Reserved-GPU-Capacities 2026?

Bei stabiler Auslastung über 70 Prozent in der Regel innerhalb von 8 bis 12 Monaten. Unterhalb von 50 Prozent Auslastung rechnet sich Reserved gegen Spot oder On-Demand nicht mehr, weil die GPU-Generation in 18 Monaten ein Refresh sieht.

Lassen sich GPU-Kosten in der Bilanz aktivieren?

Im Mietmodell der Hyperscaler grundsätzlich nicht, das sind laufende Betriebskosten. Bei Eigen-GPU im Co-Location oder On-Prem ist eine Aktivierung möglich, mit den entsprechenden Abschreibungsregeln. Steuerlich und bilanziell sollte das mit dem CFO-Bereich abgestimmt werden, weil sich daraus auch Reporting-Pflichten ableiten.

Bildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt