Eine GPU-Kapazitätsreservierung hält GPU-Instanzen eines Typs in einer Region oder Zone für Sie bereit und kostet den On-Demand-Satz, solange sie besteht, genutzt oder nicht. Sie sichert Kapazität, keinen niedrigeren Preis: Den Rabatt bringen erst Commitments, die auf die Reservierung angerechnet werden. Bei knappen GPU-Typen ist sie oft der einzige Weg, die Instanzen zum geplanten Termin zu bekommen, und zugleich ein Posten, der ohne Nutzung weiterläuft.
So funktioniert es
GPU-Kapazität wird als Instanzstunden von GPU-Familien verkauft, mit einer festen GPU-Zahl je Größe. Bei AWS reicht das von einem Achtel einer NVIDIA L4 in g6f.large über eine L4 in g6.xlarge bis zu acht H100 in p5.48xlarge, bei Azure in der Serie NC A100 v4 von einer bis vier A100. Wie die Familien benannt sind, beschreibt Virtuelle Maschinen und Instanzfamilien. Verfügbar sind die Typen nur in bestimmten Regionen und Zonen: In Frankfurt führt Google die G2-Serie in den Zonen europe-west3-a und -b, A3 High nur in europe-west3-c.
AWS
On-Demand Capacity Reservations gelten für Instanztyp, Plattform, Availability Zone und Tenancy. Sofort beginnende Reservierungen haben keine Laufzeit und lassen sich jederzeit beenden; bei Reservierungen für ein künftiges Datum legt man eine Mindestdauer fest, kann die Menge darin nicht senken, und eine Kündigung kann eine Gebühr auslösen. Berechnet wird sekundengenau, mindestens 60 Sekunden, zum On-Demand-Satz; eine darin laufende Instanz ersetzt die Reservierungsgebühr durch ihre eigene. Savings Plans und regionale Reserved Instances gelten für die Reservierung, zonale Reserved Instances nicht, und die Rabatte gehen zuerst auf laufende Instanzen, dann auf ungenutzte Reservierung. Im Cost and Usage Report 2.0 erscheint die genutzte Kapazität als BoxUsage, die ungenutzte als UnusedBox.
Capacity Blocks for ML reservieren GPU-Instanzen für 1 bis 14 Tage oder ein Vielfaches von 7 Tagen bis 182 Tage, mit Start bis zu acht Wochen im Voraus. Der Preis richtet sich nach Angebot und Nachfrage beim Kauf und wird vorab bezahlt; danach fallen nur Betriebssystemkosten an. Savings Plans und Reserved Instances gelten dafür nicht, und 30 Minuten vor dem Ende beginnt AWS, die Instanzen zu beenden.
Azure
Eine On-Demand-Kapazitätsreservierung gilt für eine VM-Größe, eine Region oder Zone und eine Menge, ohne Laufzeit. Sie kostet den Pay-as-you-go-Satz der VM-Größe, genutzt oder nicht, und Reserved Instances und Savings Plan gelten für genutzte wie ungenutzte Einheiten. Eine VM nutzt die Reservierung nur, wenn sie die Reservierungsgruppe in ihren Eigenschaften angibt; Größe und Region einer Reservierung lassen sich nicht ändern. Unterstützt werden nur bestimmte Serien, bei GPUs unter anderem NC A100 v4, NCasT4_v3 und NV ab v3; die ND-Serie und NCads H100 v5 sowie Spot VMs gehören nicht dazu.
Google Cloud
Eine Reservierung gilt für eine Zone und eine Maschinenkonfiguration einschließlich GPU-Typ und -Zahl. Sie kostet den On-Demand-Satz mit Mindestabrechnung von einer Minute, solange sie existiert; Sustained Use Discounts und Committed Use Discounts gelten wie für laufende VMs, und eine Option löscht die Reservierung automatisch zu einem gesetzten Zeitpunkt. Future Reservations reservieren bis zu ein Jahr im Voraus und mindestens 24 Stunden; für GPUs verlangt Google vorher Kontakt zum Account-Team oder Vertrieb. Ist die Anfrage genehmigt, lässt sie sich ab 56 Tagen vor Beginn nicht mehr stornieren, und der ganze Zeitraum ist zu bezahlen. Ressourcenbasierte Committed Use Discounts für GPUs setzen eine angehängte Reservierung mit denselben GPUs voraus; die ausgabenbasierten Compute Flexible CUDs decken L4 (G2) und G4 ohne Reservierung, dafür ohne zugesicherte Kapazität.
Was es für Ihre Kosten bedeutet
Kapazität und Preis sind zwei getrennte Entscheidungen. Welcher Mechanismus was leistet:
| Mechanismus | Sichert Kapazität | Senkt den Satz | Kostet ungenutzt |
|---|---|---|---|
| Kapazitätsreservierung (AWS, Azure, Google) | ja, in Region oder Zone | nein | ja, zum On-Demand-Satz |
| Future Reservation (Google), künftige Reservierung (AWS) | ja, ab dem Startdatum | nein | ja, für die zugesagte Dauer |
| Capacity Block (AWS) | ja, für die gebuchten Tage | eigener Preis, vorab bezahlt | ja, schon bezahlt |
| Savings Plans, Reserved Instances, CUDs | nur zonale RIs bei AWS, Google-CUDs mit Reservierung | ja | ja, die Zusage |
| Spot-Kapazität | nein, unterbrechbar | ja | nein |
Eine Reservierung lohnt sich, wenn die Instanzen ohne sie nicht zu bekommen wären; jede ungenutzte Stunde kostet den vollen Satz. Der Rabatt kommt aus einem Commitment, das man getrennt kauft (AWS Savings Plans, AWS Reserved Instances, Azure-Reservierungen, Committed Use Discounts von Google Cloud); welcher Typ passt, vergleicht Commitment-Rabatte der Cloud-Anbieter im Vergleich, wie man sie bemisst, Commitment-Strategie als Portfolio.
Spot-Kapazität für GPUs ist billiger, aber unterbrechbar (Spot Instances, Spot VMs und präemptive Kapazität). Für Training setzt sie Checkpoints voraus, damit ein Job am letzten Stand fortsetzt; AWS empfiehlt sie für Managed Spot Training in SageMaker, sofern der Job nicht schnell endet (Kosten für KI-Training, Fine-Tuning und Inferenz).
Leerlauf ist auf der Rechnung sichtbar: Eine laufende GPU-Instanz ohne Arbeit kostet wie eine ausgelastete (On-Demand-Preise), und ungenutzte Reservierung steht als eigene Zeile da, bei AWS als UnusedBox, bei Azure als ungenutzte Reservierung zum VM-Satz. Beides sind Leerlaufkosten (Ungenutzte und verwaiste Ressourcen); wie Knoten-Kapazität in Kubernetes an den Bedarf der Workloads heranrückt, beschreibt Kubernetes-Effizienz.
Wo es schiefgeht
- Die Reservierung überlebt das Projekt.
UnusedBox-Zeilen oder ungenutzte Reservierungen laufen Monate nach dem letzten Training weiter, weil niemand die Reservierung beendet hat. Bei Google setzt die automatische Löschung das Ende schon beim Anlegen. - Falsche Zone oder Größe reserviert. Die Instanzen laufen außerhalb der Reservierung und werden zusätzlich berechnet. Die Ursache: Die Reservierung passt nur bei gleichem Typ und gleicher Zone; bei Azure muss die VM zudem die Reservierungsgruppe angeben.
- Reservierung als Rabatt gelesen. Die Rechnung sinkt nach der Reservierung nicht. Die Ursache: Die Reservierung kostet den On-Demand-Satz; der Rabatt braucht ein Commitment, und für Capacity Blocks gilt keiner.
- Spot für Jobs, die nicht fortsetzen können. Nach jeder Unterbrechung beginnt das Training von vorn, und die bezahlten Stunden bis dahin sind verloren.
Beispiel
Azure Standard_NC24ads_A100_v4 mit einer NVIDIA A100, Linux, Germany West Central, laut Azure Retail Prices API am 2026-10-16: Pay-as-you-go 4,775 USD je Stunde, Spot 0,88242 USD je Stunde. Eine Kapazitätsreservierung über R VMs, von denen U laufen, kostet U × 4,775 USD für die VMs plus (R − U) × 4,775 USD für die ungenutzte Reservierung, zusammen R × 4,775 USD je Stunde, unabhängig von U. Über 730 Stunden sind das je reservierter Einheit 3.485,75 USD, genutzt oder nicht. Erst Reserved Instances oder ein Savings Plan senken diesen Satz, für genutzte wie ungenutzte Einheiten; Spot VMs lassen sich gar nicht reservieren.
Quellen
Gelesen am 2026-10-16. AWS On-Demand Capacity Reservations, Preise und Abrechnung der Capacity Reservations, Capacity Blocks for ML, So funktionieren Capacity Blocks, Preise und Abrechnung der Capacity Blocks, Accelerated-Computing-Instanzen und Managed Spot Training; Microsoft On-Demand-Kapazitätsreservierung, NC_A100_v4-Serie und Azure Retail Prices API mit der Abfrage für Standard_NC24ads_A100_v4; Google Reservierungen, Future Reservations, Reservierungen mit Commitments und GPU-Standorte.