Kubernetes-GPU-Kosten sind die Stundenpreise der GPU-Nodes, und sie fallen an, solange der Node läuft, nicht solange die GPU rechnet: Ein Pod, der eine ganze GPU anfordert und sie zu einem Fünftel auslastet, bezahlt sie ganz. Weil eine GPU-Instanz das Zehn- bis Vierzigfache eines gewöhnlichen Nodes kostet, ist die ungenutzte GPU die größte einzelne Verschwendung eines Clusters mit Beschleunigern. Diese Seite beschreibt, wie die Anbieter GPU-Nodes berechnen, wie Time-Slicing und Multi-Instance GPU (MIG) eine GPU zwischen Pods teilen und was das für die Zuordnung bedeutet, warum der Leerlauf dominiert, was Dynamic Resource Allocation ändert, und was ein Cost-Agent im Cluster über GPUs sehen kann und was nicht. GPU-Kapazität als Kaufentscheidung, Reservierungen und Kontingente behandelt GPU-Kosten im Kapitel zu KI.

So funktioniert es

Eine GPU erreicht einen Pod über eine erweiterte Ressource: Das Device Plugin des Herstellers meldet dem Kubelet je Node eine Zahl von nvidia.com/gpu, und ein Container fordert eine ganze Zahl davon an, ohne Bruchteile und ohne Limit über dem Request. Der Scheduler platziert den Pod auf einem Node mit freier GPU, und ab da gehört die GPU dem Container, ob er rechnet oder wartet. Der Preis liegt beim Node: Eine GPU-Instanz bündelt GPU, vCPU, Arbeitsspeicher und oft lokalen Speicher in einem Stundenpreis, und für die Zuordnung ist die GPU die teuerste der Ressourcen, auf die der Node-Preis aufgeteilt wird (was ein Pod kostet). Die OpenCost-Spezifikation bewertet eine GPU wie CPU mit dem Größeren aus Request und Nutzung; weil der Request ganzzahlig ist, ist er fast immer das Größere.

Zwei Verfahren teilen eine physische GPU zwischen Pods. Time-Slicing lässt den Treiber die GPU im Zeitmultiplex zwischen Containern wechseln: Das Device Plugin meldet statt einer GPU eine konfigurierte Zahl von Replikas, jeder Container fordert eine davon an und bekommt die ganze GPU für seine Zeitscheibe, ohne Speichergrenze und ohne Isolation zwischen den Containern. MIG teilt eine GPU der Klassen A100, H100 und neuer in bis zu sieben Instanzen mit eigenem Speicher und eigenen Recheneinheiten, mit Isolation in der Hardware; jede Instanz erscheint als eigene Ressource wie nvidia.com/mig-1g.10gb. Für die Zuordnung gilt: Bei Time-Slicing ist der Anteil eines Pods sein Anteil an den Replikas, nicht an der Rechenzeit; bei MIG ist er der Anteil der Instanz an der GPU, nach Speicher oder Recheneinheiten.

gar nichtTime-SlicingMIGEine physische GPU auf einem Node,ihr Preis im Preis des NodesWie geteilt?Eine ganze GPU jeContainer-Request,rechnend oder wartendRepliken statt einer GPUgemeldet: jeder Containerbekommt die ganze GPU fürseine Scheibe, kein Speicher-limit, keine IsolationBis zu sieben Instanzenmit eigenem Speicher undeigenen Recheneinheiten,in Hardware isoliert,jede eine eigene Ressource
Eine GPU gehört ganz dem Container, der sie anfordert, Time-Slicing teilt sie zeitlich ohne Isolation, und MIG zerlegt sie in eigene Instanzen

Dynamic Resource Allocation (DRA), seit Kubernetes 1.35 stabil, ersetzt die ganzzahlige erweiterte Ressource durch ResourceClaim-Objekte, über die ein Pod ein Gerät mit Eigenschaften anfordert und mehrere Container oder Pods dasselbe Gerät über einen Claim teilen. Die Zuordnung bekommt damit ein Objekt, das sagt, welcher Pod welches Gerät oder welchen Teil davon hält.

AWS

GPU-Instanzen der Familien G und P tragen die GPU im Instanzpreis und stehen im Cost and Usage Report als EC2-Instanzstunden wie jede andere; Split Cost Allocation Data verteilt Instanzen mit Beschleunigern immer nach Requests, nie nach Nutzung. EKS Auto Mode bringt die GPU-Treiber und das Device Plugin mit, mit der Verwaltungsgebühr je Instanz.

Azure

AKS-GPU-Node-Pools nutzen die N-Serien mit NVIDIA-GPUs und werden als virtuelle Maschinen berechnet, auch als Spot-VMs; AKS kann das Device Plugin installieren, MIG-Profile werden je Pool gesetzt.

Google Cloud

GKE Standard berechnet GPU-Nodes als Compute-Engine-Instanzen mit angehängter GPU, Autopilot berechnet Beschleuniger-Pods mit einem Aufschlag je GPU und Requests; Time-Sharing und MIG sind in GKE eingebaut und werden je Node-Pool konfiguriert.

Was es für Ihre Kosten bedeutet

Die Auslastung einer GPU steht in keiner Abrechnungsdatei. Was ein Cost-Agent im Cluster sieht, sind der Request des Pods, der Node und sein Preis, also die Zuordnung nach Request; was er nur mit Metriken des Treibers sieht, etwa aus dem DCGM Exporter, ist die Auslastung von Recheneinheiten und Speicher, also der Leerlauf innerhalb des Requests. Ohne diese Metriken zeigt jeder Bericht eine volle GPU je Pod, und der dominierende Posten bleibt unsichtbar. Mit ihnen wird der GPU-Leerlauf zu einer Zahl je Workload: angeforderte GPU-Stunden mal dem Anteil, in dem die GPU nicht rechnete.

ohne die MetrikenNode und Preis aus der Abrechnungs-datei, und der Request des Pods,wie der Cost-Agent ihn siehtZuordnung nach Request: eine volleGPU je Pod, der eine anfordertTreibermetriken, etwa vom DCGM-Exporter: genutzte Recheneinheitenund SpeicherGPU-Leerlauf je Workload: angeforderteGPU-Stunden mal der Anteil, in demdie GPU nicht gerechnet hatDer größte Postenbleibt unsichtbar
Abrechnungsdaten und Request zeigen eine volle GPU je Pod; erst Treibermetriken machen aus angeforderten GPU-Stunden den Leerlauf darin

Die Hebel folgen daraus. Inferenz-Dienste mit geringer Auslastung teilen sich eine GPU per Time-Slicing, wo die Latenz das zulässt, oder per MIG, wo die Isolation zählt; Batch-Jobs laufen auf Spot-GPU-Nodes, deren Unterbrechung ein Checkpoint auffängt (Spot- und Preemptible-Nodes); ein GPU-Node-Pool mit Taint und Mindestgröße null verhindert, dass ein Node ohne GPU-Pod weiterläuft (Node-Pools und Instanzauswahl). Die Zuordnungsregel für geteilte GPUs, nach Replikas, nach MIG-Instanz oder nach gemessener Auslastung, ist eine Zuordnungsregel mit Datum, und nach Nutzung zu verteilen verlangt die Metriken, die nach Request nicht nötig sind.

Wo es schiefgeht

  • Volle GPU, kaum Last. Symptom: Ein Inferenz-Dienst belegt eine GPU rund um die Uhr bei einstelliger Auslastung. Ursache: Der Request ist ganzzahlig; ohne Sharing bezahlt jeder Pod eine ganze GPU.
  • GPU-Node ohne GPU-Pod. Symptom: Ein GPU-Node läuft tagelang mit System-Pods. Ursache: Die Mindestgröße des Pools ist eins, oder ein Pod ohne GPU-Request ist dort gelandet, weil der Taint fehlt.
  • Time-Slicing als Isolation missverstanden. Symptom: Ein Container verdrängt die anderen aus dem GPU-Speicher. Ursache: Time-Slicing setzt keine Speichergrenze durch; nur MIG isoliert in der Hardware.
  • Zuordnung ohne Auslastung. Symptom: Jeder Bericht zeigt GPU-Kosten gleich dem Node-Preis, der Leerlauf fehlt. Ursache: Der Agent sieht Requests, keine Treiber-Metriken; die Auslastung ist nicht exportiert.
  • Spot-GPU ohne Checkpoint. Symptom: Ein Trainingslauf beginnt nach jeder Unterbrechung von vorn. Ursache: Der Job schreibt keine Checkpoints; die günstigere Stunde kostet die verlorene Rechenzeit.
  • Falsche Instanz für die Aufgabe. Symptom: Ein Inferenz-Dienst läuft auf einer Trainings-GPU mit 80 GB Speicher bei 6 GB Bedarf. Ursache: Die Familie wurde nach Verfügbarkeit gewählt, nicht nach dem Speicherbedarf des Modells.

Beispiel

Listenpreise, gelesen am 2026-10-21: in Frankfurt (eu-central-1) kostet eine g5.xlarge (1 GPU NVIDIA A10G mit 24 GB, 4 vCPU, 16 GiB) On-Demand unter Linux 1,258 USD je Stunde und eine g6.xlarge (1 GPU NVIDIA L4) 1,0064 USD; in Germany West Central kostet eine Standard_NC24ads_A100_v4 (1 GPU NVIDIA A100 mit 80 GB, 24 vCPU) 4,775 USD je Stunde regulär und 0,88242 USD als Spot-VM, über die Azure Retail Prices API gelesen.

Ein Pod, der die GPU einer g5.xlarge rund um die Uhr hält, kostet 1,258 × 730 = 918,34 USD im Monat; rechnet die GPU dabei 20 Prozent der Zeit, sind 734,67 USD davon Leerlauf, den nur Treiber-Metriken sichtbar machen. Teilen sich vier Dienste die GPU per Time-Slicing mit vier Replikas, trägt jeder nach Request ein Viertel, 229,59 USD. Eine A100 für 4,775 × 730 = 3.485,75 USD im Monat, per MIG in sieben Instanzen geteilt, kostet 497,96 USD je Instanz nach Anteil; als Spot-VM kostet dieselbe Maschine 0,88242 × 730 = 644,17 USD im Monat, solange sie nicht entzogen wird.

Quellen

Gelesen am 2026-10-21. Kubernetes GPUs einplanen und Dynamic Resource Allocation, NVIDIA Time-Slicing von GPUs in Kubernetes und MIG-Unterstützung in Kubernetes, OpenCost-Spezifikation, AWS Split Cost Allocation Data, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1, Microsoft GPUs in AKS und Azure Retail Prices API, Google Cloud GPU-Time-Sharing in GKE und Multi-Instance-GPUs in GKE.