GPU- und KI-Workload-Kosten auf Azure steuern

GPU- und KI-Workloads durchbrechen die Kostenannahmen, auf denen die meisten Cloud-Governance-Modelle aufgebaut sind. Ein Team, das FinOps für Web-Tiers und Datenbanken im Griff hat, kann beim ersten Trainingslauf oder beim ersten produktiven LLM-Endpunkt auf der Rechnung kalt erwischt werden. Der Stundensatz einer beschleunigten SKU, multipliziert mit Leerlaufzeit und fragmentierter Allokation, erzeugt Zahlen, die Eskalationen in der Finanzabteilung auslösen statt Routineprüfungen.

Dieser Beitrag beschreibt, wie wir bei CC Conceptualise die Steuerung von GPU- und KI-Workload-Kosten auf Azure angehen — entlang der FinOps-Framework-Phasen Inform, Optimize, Operate — und welche konkreten Hebel die Rechnung tatsächlich bewegen.

Kurzfassung / Die wichtigsten Erkenntnisse

GPU-SKUs kosten pro Stunde eine Größenordnung mehr als CPU-VMs, weshalb Leerlauf und fragmentierte Allokation die dominierenden Kostentreiber sind — nicht der reine Hardware-Tarif.
Schichten Sie Ihre Commitment-Strategie: Reserved Instances oder Savings Plans für die nachgewiesene Baseline, On-Demand plus Spot für variable und fehlertolerante Arbeit.
Bei LLM-Inferenz schlagen Token-Kosten-Engineering und Modell-Routing die Hardware-Optimierung als schnellste Einsparquelle.
Machen Sie Kosten zuordenbar durch Tagging plus Kubernetes-Kostenallokation (OpenCost/Kubecost) und setzen Sie sie mit Policy-as-Code-Guardrails über Azure Policy durch.
Behandeln Sie dies als Betriebsdisziplin, nicht als einmalige Aufräumaktion: Anomalieerkennung und Kapazitäts-Right-Sizing laufen kontinuierlich.

Warum sich GPU-Kosten anders verhalten

Das Kernproblem ist Hebelwirkung. Ein regulärer CPU-Knoten im Leerlauf verschwendet ein paar Cent pro Stunde. Eine beschleunigte GPU-SKU im Leerlauf verschwendet das Zehn- bis Fünfzigfache. Da GPU-Kapazität in gefragten Regionen zudem häufig knapp ist, provisionieren Teams defensiv über — sie greifen sich Instanzen und halten sie, um später nicht ohne Zugriff dazustehen. Dieses defensive Horten ist auf Team-Ebene rational und auf Portfolio-Ebene ruinös.

Vier wiederkehrende Kostentreiber sehen wir, wenn wir ein Problem mit KI-Infrastrukturkosten analysieren:

Ungenutzte Beschleuniger — GPUs, die für einen nur zeitweise laufenden Workload provisioniert, aber nie deallokiert werden.
Überdimensionierte SKUs — ein Job, der eine GPU der Mittelklasse braucht, läuft auf einem Multi-GPU-Knoten, weil das die kopierte Vorlage war.
Fragmentierte Allokation — viele kleine Workloads, die jeweils einen Bruchteil eines Knotens halten, während der Rest brachliegt.
Unkontrollierte Inferenz — LLM-Endpunkte, bei denen der Token-Verbrauch pro Anfrage nie gemessen wird, sodass die Kosten linear mit dem Traffic steigen und es niemand bemerkt, bis es groß ist.

Nichts davon ist exotisch. Es ist das vorhersehbare Ergebnis davon, GPU-Kapazität wie CPU-Kapazität zu behandeln.

Inform: GPU- und KI-Kosten sichtbar und zuordenbar machen

Sie können nicht optimieren, was Sie nicht zuordnen können. Die erste Phase ist Transparenz, und für GPU-Workloads bedeutet das mehr Granularität, als ein Standard-Kostenexport liefert.

Beginnen Sie mit einem Tagging-Vertrag, den jede beschleunigte Ressource erfüllen muss: Kostenstelle, Projekt, Umgebung und Verantwortlicher. Ergänzen Sie dann die Allokation auf Workload-Ebene. Wenn GPUs auf Azure Kubernetes Service laufen — wo das Training und die durchsatzstarke Inferenz der meisten unserer Kunden stattfinden — schlüsseln Werkzeuge wie OpenCost oder Kubecost die geteilten Clusterkosten bis auf Namespace- und Pod-Ebene auf. Das ist der Unterschied zwischen einer einzelnen, nicht zuordenbaren Position "KI-Plattform" und einem Chargeback-Modell, das das Business akzeptiert.

Koppeln Sie dies mit Cost-Anomalieerkennung, damit ein außer Kontrolle geratener Trainingsjob oder ein fehlkonfigurierter Autoscaler in Stunden auffällt, nicht erst zum Monatsende. Die Erkennungsmechanik behandeln wir in unserem Beitrag zur Azure Cost-Anomalieerkennung; hier geht es darum, dass GPU-Ausgaben schnell genug steigen, um eine monatliche Prüfkadenz zu langsam zu machen.

Chargeback vs. Showback

Dimension	Showback	Chargeback
Funktion	Meldet Kosten je Team	Belastet die Kosten dem Budget des Teams
Verhaltenswirkung	Mäßig — nur Transparenz	Stark — reale Budgetkonsequenz
Voraussetzung	Verlässliches Tagging und Allokation	Dasselbe, plus Finanz-Buy-in und Klärungsprozess
Bester erster Schritt für	FinOps-Einsteiger	Reife FinOps-Kulturen
GPU-spezifisches Risiko	Teams ignorieren Berichte	Streit über die Genauigkeit der Cluster-Allokation

Für GPU-Workloads empfehlen wir fast immer den Start mit Showback. Die Allokationsgenauigkeit muss erst Vertrauen verdienen, bevor Sie reale Budgets daran knüpfen — andernfalls bringt die erste strittige Rechnung das gesamte Programm zum Stillstand.

Optimize: die Hebel, die die GPU-Rechnung bewegen

Hier liegen die meisten Euros. Die Hebel fallen in drei Gruppen.

1. Commitment-Strategie

Passen Sie das Commitment an die Nachfrageform an. Das ist dieselbe Disziplin wie beim regulären Compute, aber mit höherem Einsatz, weil GPU-SKUs teuer sind und sich schnell weiterentwickeln — sich auf eine SKU festzulegen, die in einem Jahr abgelöst wird, ist ein reales Risiko.

Nachfragemuster	Empfohlenes Kaufmodell	Begründung
Dauerhafte Produktionsinferenz, stetig	Reserved Instances (1–3 J.)	Höchster Rabatt auf nachgewiesene Baseline
Stetig, aber SKU-unsicher	Savings Plans	Rabatt mit Flexibilität über Familien hinweg
Variable Forschung / Experimente	On-Demand	Keine Bindung bei unvorhersehbarer Nachfrage
Fehlertolerantes Training mit Checkpointing	Spot	Bis zu ~90 % günstiger; Evictions tolerierbar

Das Muster, das wir umsetzen, ist geschichtet: Reservieren Sie nur die Baseline, die Sie aus mindestens 30 Tagen Nutzungsdaten belegen können, decken Sie die flexible Mitte mit Savings Plans ab und schieben Sie alles Unterbrechbare auf Spot. Unser Deep Dive zu Reserved Instances vs. Savings Plans vs. Spot arbeitet die Rechnung im Detail durch.

2. Auslastung und Scheduling

Commitment-Rabatte sind vergeudet, wenn die Hardware brachliegt. Der größte Einzelgewinn in den meisten Projekten besteht schlicht darin, GPUs abzuschalten, wenn sie nicht arbeiten:

Automatische Deallokation von Dev- und Experiment-GPUs nach Zeitplan (nachts, am Wochenende).
Inferenz-Endpunkte auf null skalieren, wo das Latenzbudget einen Kaltstart erlaubt.
Bin-Packing der Workloads, sodass ein Knoten nahe der Vollauslastung läuft statt vieler fraktionaler Belegungen.
Spot für Batch-Training mit häufigen Checkpoints in dauerhaften Speicher, sodass Evictions Minuten kosten und nicht den ganzen Lauf.
SKU-Right-Sizing auf den Job — profilieren Sie den tatsächlichen GPU-Speicher- und Rechenbedarf, statt eine überdimensionierte Vorlage zu kopieren.

3. Token-Kosten-Engineering für LLM-Workloads

Bei generativer KI ist die Infrastruktur oft nicht die größte Position — die Token-Rechnung ist es. Die Steuerung der KI-Workload-Kosten bedeutet hier, die Token zu steuern:

Prompts kürzen und Antwortlänge begrenzen. Jedes Token rein und raus wird berechnet; ausschweifende System-Prompts und unbegrenzte Antworten sind im Maßstab reine Verschwendung.
Auf das kleinste Modell routen, das die Qualitätsanforderung erfüllt. Der meiste Traffic braucht nicht das größte Modell; gestuftes Routing mit einem gemessenen Qualitäts-Benchmark ist die wirkungsvollste Änderung.
Caching wiederholter oder semantisch ähnlicher Anfragen.
Batching asynchroner Workloads, um günstigere Verarbeitungsstufen zu nutzen.

Läuft Ihre generative Plattform auf Microsoft Fabric, ist die Kapazitäts-(CU-)Dimensionierung eine eigene Disziplin — wir behandeln sie separat in Fabric-Kapazitätsdimensionierung und Kosten, denn eine falsch dimensionierte Kapazität glättet Verschwendung, die Sie sonst entdecken würden.

Operate: die Disziplin am Laufen halten

Optimierung, die nicht operationalisiert wird, verfällt binnen eines Quartals. In der Operate-Phase geht es darum, die Gewinne dauerhaft zu sichern und sie automatisch durchzusetzen.

Policy-as-Code-Guardrails

Hier rechtfertigt Azure Policy seinen Platz im FinOps. Kodieren Sie Kostenregeln als durchsetzbare Kontrollen, sodass Verschwendung bereits bei der Bereitstellung verhindert wird:

GPU-SKUs beschränken auf eine Freigabeliste und so die versehentliche Bereitstellung der teuersten Beschleuniger blockieren.
Kostenstellen- und Owner-Tags verlangen, bevor eine beschleunigte Ressource erstellt werden kann — kein Tag, keine Ressource.
Regionen einschränken auf jene mit Compliance-Freigabe und vertretbaren GPU-Preisen.
Auto-Shutdown-Tags erzwingen auf GPU-Ressourcen außerhalb der Produktion.

Die Kostensteuerung so nach links zu verlagern, ist der Unterschied zwischen dem Entdecken eines Problems auf der Rechnung und dem, es gar nicht erst entstehen zu lassen. Das breitere Muster vertiefen wir in unserer Arbeit zu Cloud-Architektur-Services, wo Policy-as-Code fester Bestandteil der Landing Zone ist.

Kontinuierliche Praktiken

Wöchentliche Prüfung der GPU-Auslastung gegen die committete Kapazität.
Kontinuierliche Anomalieerkennung auf beschleunigte Ausgaben.
Quartalsweise Neubewertung der Commitments, wenn SKUs und Nachfrage sich verschieben.
Pro Release Token-Kosten-Regressionsprüfungen an LLM-Endpunkten.

In einem Plattformprojekt entfernte die Kombination aus geplanter Deallokation, Bin-Packing auf AKS mit Kubecost-gesteuerter Allokation und einer Spot-First-Trainingsqueue einen erheblichen Anteil der monatlichen GPU-Ausgaben, ohne ein einziges Forschungsteam auszubremsen — die Einsparung kam fast vollständig aus dem Beseitigen ungenutzter und fragmentierter Kapazität, nicht aus weniger Arbeit.

Eine pragmatische Reihenfolge

Wenn Sie mit einer GPU-Rechnung starten, die niemand erklären kann, gehen Sie in dieser Reihenfolge vor:

Loading diagram...

Taggen und allokieren — zuerst zuordenbare Kosten herstellen (Inform).
Leerlauf abschalten — Scheduling und Scale-to-Zero, der schnellste No-Regret-Gewinn (Optimize).
Token engineeren — für jeden LLM-Workload, bevor Sie Hardware anfassen (Optimize).
Right-Sizing und Bin-Packing — SKUs und Auslastung an die Nachfrage anpassen (Optimize).
Baseline committen — erst wenn die Nutzung belegt ist (Optimize).
Mit Policy absichern — die Gewinne festschreiben (Operate).

Diese Schritte in falscher Reihenfolge auszuführen — etwa Reservierungen einzugehen, bevor Sie die Auslastung verstehen — ist der Weg, wie Teams Verschwendung für drei Jahre festschreiben.

Wo das hingehört

Die Steuerung von GPU- und KI-Workload-Kosten ist kein Werkzeugproblem; sie ist eine Betriebsdisziplin, die Engineering, Plattform und Finanzen umspannt. Die Technologie — Azure Policy, Kubecost, Spot, Savings Plans — ist ausgereift. Was meist fehlt, ist das Zuordnungsmodell und die Durchsetzung, die es dauerhaft macht.

Wenn Sie möchten, dass ein erfahrener Architekt Ihre GPU-Kostenposition prüft und gemeinsam mit Ihnen die Commitment- und Guardrail-Strategie aufbaut, leistet genau das unsere Praxis für Cloud-Architektur und Migration. Wir haben es auf produktiven KI-Plattformen umgesetzt und beginnen gern mit einer fokussierten Bewertung statt mit einem langen Projekt.

FAQ

Warum lassen sich GPU-Kosten auf Azure schwerer steuern als CPU-Kosten?

GPU-SKUs kosten pro Stunde das Zehn- bis Fünfzigfache einer regulären CPU-VM, weshalb eine ungenutzte GPU deutlich schneller Geld verbrennt als ein ungenutzter CPU-Knoten. Hinzu kommt, dass GPU-Kapazität in beliebten Regionen oft knapp ist, was Teams zur defensiven Überprovisionierung verleitet. In der Folge schlagen kleine Ineffizienzen — Leerlauf, überdimensionierte Knoten, fragmentierte Allokation — sehr schnell in hohe Euro-Beträge um.

Sollten wir für GPU-Workloads Reserved Instances oder Savings Plans kaufen?

Das hängt von der Stabilität Ihrer GPU-Nachfrage ab. Stetige, vorhersagbare Inferenz oder dauerhaft laufende Trainings-Pipelines rechtfertigen ein ein- oder dreijähriges Commitment für den höchsten Rabatt, während variable Forschungs-Workloads mit Savings Plans oder On-Demand plus Spot besser bedient sind. Wir reservieren in der Regel nur die nachgewiesene Baseline und halten die variable Schicht flexibel, da ein Übercommitment auf schnelllebige GPU-SKUs ein häufiger und teurer Fehler ist.

Lässt sich Spot-GPU-Kapazität für das Modelltraining nutzen?

Ja, für fehlertolerantes Training, das häufig Checkpoints schreibt. Spot-GPU-Kapazität kann mit kurzer Vorwarnzeit evicted werden, daher muss der Workload den Zustand in dauerhaftem Speicher persistieren und automatisch vom letzten Checkpoint fortsetzen. Für lange Einzeldurchläufe ohne Checkpointing oder latenzsensitive Produktionsinferenz ist Spot die falsche Wahl.

Wie ordnen wir GPU- und KI-Kosten den verursachenden Teams zu?

Über eine konsequente Tagging-Strategie in Kombination mit Kubernetes-Kostenallokationswerkzeugen wie OpenCost oder Kubecost, wenn GPUs auf AKS laufen. Die Tags tragen Kostenstelle, Projekt und Umgebung, während das Allokationswerkzeug die geteilten Clusterkosten bis auf Namespace- und Workload-Ebene aufschlüsselt. Erst das macht ein belastbares Chargeback oder Showback möglich statt einer einzelnen, nicht zuordenbaren Plattformrechnung.

Was ist der größte Hebel zur Senkung der LLM-Inferenzkosten?

Token-Kosten-Engineering — die Steuerung, wie viele Input- und Output-Token jede Anfrage verbraucht, und das Routing auf das kleinste Modell, das die Qualitätsanforderung erfüllt. Prompt-Kürzung, Begrenzung der Antwortlänge, Caching und gestuftes Modell-Routing senken die Inferenzkosten meist stärker als jede Infrastrukturänderung. Hardware-Optimierung zählt, aber die größten und schnellsten Einsparungen liegen in der Token-Rechnung.

Wie helfen Policy-as-Code-Guardrails bei der GPU-Kostensteuerung?

Azure Policy erlaubt es, Kostenregeln als durchsetzbare Kontrollen zu kodieren — etwa die Beschränkung zulässiger GPU-SKUs, die Pflicht zu Kostenstellen-Tags vor der Erstellung einer Ressource oder das Blockieren teurer Regionen. Das verlagert die Kostensteuerung nach links und verhindert Verschwendung bereits bei der Bereitstellung statt erst auf der Rechnung des Folgemonats. So wird aus FinOps-Absicht ein automatisierter Guardrail, der über Subscriptions hinweg skaliert.