Ein Compute-Angebot ist noch keine Reservierung

Kurzfassung: Bei GPU-Beschaffung müssen Angebot, Kaufbestätigung, Zahlung und nutzbares Zeitfenster getrennt im Projektplan stehen. AWS Capacity Blocks zeigen den Unterschied konkret: Ein gefundenes Angebot bleibt verfügbaritätsabhängig, eine gekaufte Reservierung zunächst zahlungsabhängig. Gleichzeitig bindet die Buchung den Käufer an einen Zeitraum, den sein eigenes Projekt auch nutzen können muss.

Im Projektplan steht der Trainingslauf bereits fest. Der Einkauf hat ein passendes GPU-Angebot gefunden, der Fachbereich reserviert Personal, und die Datenaufbereitung soll kurz vor dem Start fertig werden. Auf dem Papier passt alles. Entscheidend ist jedoch, welcher Beschaffungsschritt tatsächlich abgeschlossen wurde. Eine angezeigte Kapazität, eine bestätigte Reservierung und ein für den Einsatz vorbereitetes System sind verschiedene Dinge.

Die aktuelle AWS-Dokumentation zu EC2 Capacity Blocks macht diese Unterschiede ungewöhnlich greifbar. Das Angebot gibt es seit 2023; es ist keine neue Produkteinführung. Für heutige KI-Projekte liefert sein dokumentierter Kaufprozess aber ein brauchbares Beispiel dafür, wie Rechenkapazität beschafft und in Termine übersetzt werden sollte. Wer nur „GPU bestellt“ als Meilenstein führt, verdeckt genau die Voraussetzungen, von denen der geplante Start abhängt.

Das Angebot hält die Kapazität noch nicht fest

Mit EC2 Capacity Blocks sucht ein Unternehmen nach einer bestimmten Zahl von Instanzen, einer Dauer und einem möglichen Startzeitraum. Die zurückgegebenen Angebote enthalten unter anderem Startzeit, Availability Zone und Preis. So lässt sich ein Trainings- oder Experimentierfenster gezielt einkaufen.

AWS weist ausdrücklich darauf hin, dass Angebote nach dem Prinzip „first come, first served“ verfügbar sind. Ein gefundenes Angebot hat keinen vorab festgelegten Ablaufzeitpunkt. Daraus folgt aber gerade nicht, dass es bis zur internen Einkaufsfreigabe für den Interessenten vorgehalten wird. Der Suchtreffer beschreibt eine Kaufmöglichkeit; er ist noch kein Nachweis einer eigenen Reservierung.

Für den Einkauf hat das eine praktische Konsequenz. Wenn ein Fachbereich eine konkrete Kapazität auswählt, darf die Abstimmung über Budget, Bestellberechtigung und Termin nicht erst danach beginnen. Sonst wird ein heute sichtbares Angebot zum vermeintlich gesicherten Baustein eines Projekts, obwohl der Kauf noch offen ist. Die Organisation braucht für solche Beschaffungen einen vorbereiteten Entscheidungsrahmen: Welcher Zeitraum passt, welcher Preis ist akzeptabel, und wer darf die Buchung verbindlich auslösen?

Das verlangt keine unbegrenzte Einkaufsfreiheit. Es verlangt eine Freigabe, die zur Verfügbarkeit des Angebots passt. Ein Preisbild aus einer früheren Suche und die tatsächlich kaufbare Kapazität sollten dabei getrennt dokumentiert werden.

Kaufbestätigung und erfolgreiche Zahlung sind eigene Zustände

Nach dem Kauf bestätigt AWS unmittelbar die Reservierung. Im Konto entsteht eine Capacity Reservation mit dem Typ capacity-block und dem vereinbarten Startdatum. Ihr Zustand lautet zunächst payment-pending. Erst nach erfolgreicher Verarbeitung der Vorauszahlung wechselt er zu scheduled.

Die Abrechnungsdokumentation nennt dafür ein konkretes Verfahren: Die Zahlung wird innerhalb von fünf Minuten bis zwölf Stunden nach dem Kauf abgerechnet. Kann sie nicht spätestens fünf Minuten vor Beginn des Blocks oder innerhalb von zwölf Stunden verarbeitet werden – maßgeblich ist die früher eintretende Grenze –, wird die Kapazität freigegeben. Der Zustand wechselt zu payment-failed.

Damit ist selbst eine Kaufbestätigung noch kein ausreichender Abschlussvermerk für die Beschaffung. Die Reservierung existiert bereits, eine wesentliche Bedingung steht aber aus. Im Projektplan sollte deshalb erkennbar sein, ob die Zahlung noch läuft oder die Buchung bereits den vorgesehenen Zustand erreicht hat. Buchhaltung und Plattformbetrieb müssen denselben Vorgang betrachten können, statt eine Rechnung und eine technische Reservierung unabhängig voneinander abzulegen.

Dafür eignet sich die Reservierungskennung. AWS ordnet die Vorauszahlung in der Rechnung der Capacity-Block-ID zu. Mit dieser Kennung lassen sich das gekaufte Fenster, der Zahlungsstand und die spätere Nutzung zusammenführen. Ein Freitext wie „Cloud-Kapazität bestätigt“ verliert diese Verbindung.

Der Zustand scheduled ist ein konkreter Nachweis des dokumentierten Buchungsfortschritts. Er ersetzt keine Prüfung der Vertragsbedingungen und ist keine Zusage absoluter Ausfallfreiheit. Welche Rechte bei einer Störung bestehen, lässt sich aus einer technischen Statusbeschreibung allein nicht ableiten.

Auch der Käufer muss rechtzeitig lieferfähig sein

Die Bindung wirkt in beide Richtungen. Laut AWS können Capacity Blocks nach der Reservierung nicht storniert werden. Der Preis hängt beim Kauf von Angebot und Nachfrage ab; nach der Reservierung ändert er sich nicht. Ein später verschobener interner Datenfreigabetermin hebt diese Buchung also nicht einfach auf.

Das verschiebt die Reihenfolge der Projektentscheidung. Ein Unternehmen sollte vor dem verbindlichen Einkauf wissen, ob Datenzugriff, Softwareumgebung und verantwortliches Team zum gebuchten Termin bereit sein können. Dafür braucht es keinen vollständig abgeschlossenen Trainingslauf. Es braucht belastbare Voraussetzungen, die nicht mehr von einer völlig offenen Entscheidung abhängen.

Ein hypothetisches Beispiel: Ein Zulieferer bucht GPU-Zeit für die Anpassung eines Modells an technische Dokumente. Kurz danach stellt sich heraus, dass ein Teil des Dokumentenbestands noch nicht zur Nutzung freigegeben ist. Die Kapazität kann technisch korrekt reserviert sein und wirtschaftlich trotzdem unbrauchbar werden. Ursache wäre dann kein Lieferproblem des Cloud-Anbieters, sondern eine zu frühe Bindung des eigenen Projekts.

Ausweichkapazität allein löst dieses Risiko nicht. Bei fehlenden Daten hilft ein zweiter Anbieter wenig. Sinnvoller ist ein ausdrücklich vorbereitetes Ersatzvorhaben innerhalb desselben Nutzungsfensters, sofern dessen technische und vertragliche Voraussetzungen passen. Fehlt auch diese Möglichkeit, gehört das Risiko ungenutzter Buchungszeit in die Freigabeentscheidung.

Ein Kapazitätsnachweis ist noch kein Eigentumsnachweis

Das Cloud-Beispiel lässt sich nicht unverändert auf den Kauf eines GPU-Systems oder einen Leasingvertrag übertragen. Ein Capacity Block verschafft zeitlich begrenzten Zugang zu Instanzen. Daraus entsteht kein Eigentum an der Hardware. Beim Hardwarekauf oder Leasing müssen Liefergegenstand, Abnahme, Eigentumsübergang und Rechte nach Vertragsende jeweils aus dem konkreten Vertrag hervorgehen.

Für einen Vergleich der Angebote sollten diese Unterschiede sichtbar bleiben. Drei Jahre monatlicher Zahlungen können eine andere Leistung finanzieren als ein Kaufpreis mit späterem Restwert. Ob ein Vertrag günstig ist, hängt auch davon ab, wer Wartung trägt, welche Nutzung zugesagt wird und was nach Ablauf verbleibt. Aus der bloßen Bezeichnung „reserviert“ lässt sich weder Eigentum noch ein bestimmter Rechtsbehelf herleiten.

Die Beschaffungsakte sollte daher zwei Fragen getrennt beantworten: Welche Kapazität steht uns zu welchem Zeitpunkt unter welchen Bedingungen zu? Und was erwerben wir tatsächlich – Hardware, ein Nutzungsrecht oder eine Finanzierung mit eigenen Bedingungen? Bei einem strittigen Lieferfall braucht die rechtliche Bewertung den Vertrag und den nachweisbaren Ablauf. Eine Marktgeschichte über knappe GPUs reicht dafür nicht.

Für die Geschäftsführung bleibt eine engere, unmittelbar umsetzbare Konsequenz: Ein KI-Projekt erhält seinen festen Starttermin erst auf Basis eines passenden Kapazitätsnachweises und eines ausreichend vorbereiteten eigenen Einsatzes. Im AWS-Beispiel gehören dazu Reservierungskennung, Start- und Endzeit sowie geprüfter Zahlungszustand. Das Wort „bestellt“ ist dafür zu grob. Es verdeckt sowohl die offenen Bedingungen des Anbieters als auch die Verpflichtung des eigenen Unternehmens, das gekaufte Fenster sinnvoll zu nutzen.