AI-Cloud-Commitment: Capex-Tempo wird ungemütlich

Hyperscaler bauen weiter. Analysten und Earnings-Calls beschreiben aber ein flacheres Wachstumstempo der Investitionsausgaben. Für mehrjährige AI-Cloud-Verträge zählt das Szenario im Commitment: was passiert, wenn Kapazität, Preis oder Exit nicht mehr zur Leitungsentscheidung passen.

VerwandtHardware schlägt Software-Deals – Capex neu sortieren  /  Token-OPEX: Inference steuert, nicht das Seat-Budget

AI-Cloud-Vertrag meint hier die mehrjährige Vereinbarung über Rechenkapazität, Modelle oder Inference-Leistung: Volumen, Preis, Reserved Capacity und Ausstieg. Sie bindet Budget an ein Nutzungsszenario und braucht deshalb Staffelungen, Re-Opener, Portabilität und Exit-Kosten über mehrere Betriebsjahre.

Die öffentliche Debatte hängt am Aktienkurs und an einzelnen Earnings-Wochen. Im Einkauf zählt etwas anderes: mehrjährige Commitments für Cloud- und AI-Kapazität. Wer 2027 und 2028 absichert, kauft in eine Welt, in der die Investitionsausgaben der Hyperscaler absolut weiter hoch liegen können – während das Wachstumstempo der Capex-Kurve in mehreren Markt-Szenarien abflacht.

Das ist kein Widerspruch. Es ist der Unterschied zwischen Niveau und Steigung. Ein Vertrag, der nur den heutigen Rabatt maximiert, ignoriert die Steigung. Ein Vertrag, der nur die Steigung fürchtet, verschenkt Kapazität. Brauchbar ist eine Szenario-Matrix, die beide Dimensionen in Klauseln übersetzt.

Niveau bleibt. Die Steigung ändert die Verhandlung.

Absolute Capex-Niveaus der großen Cloud- und AI-Infrastrukturanbieter liegen weiter in einer Größenordnung, die Region-Kapazität, GPU-Verfügbarkeit und Enterprise-Discount-Spielraum prägt. Gleichzeitig beschreiben Analysten-Pfade und Earnings-Guidance häufiger eine Abflachung des Wachstumstempos – nicht den Stopp des Ausbaus.

Für den DACH-Einkauf folgt daraus keine Panik und kein Blankoscheck. Es folgt eine Planungsfrage: Welches Tempo steckt im internen AI-TCO-Modell? Wer linearen Hochlauf einpreist und ein Plateau bekommt, sitzt auf Commitments ohne Nutzung. Wer ein Plateau einpreist und ein Hochlauf-Szenario bekommt, steht ohne Kapazität da – und zahlt Spot-Preise.

Token- und Runtime-Kosten (siehe verwandter Beitrag zu Token-OPEX) bleiben die variable Schicht. Capex-Tempo der Anbieter steuert die Schicht darunter: wie teuer und wie knapp die physische und vertragliche Kapazität wird, auf der Inference läuft. Beide Schichten gehören in dieselbe Entscheidungsvorlage – getrennt gemessen, gemeinsam verhandelt.

Drei Szenarien, eine Vertragslogik

Statt einer Prognose reichen drei belastbare Szenarien. Jedes braucht dieselben KPIs: genutzte GPU-/TPU-Stunden, Cost-per-Outcome der Kern-Workflows, Anteil Reserved vs. On-Demand, Exit-Kosten und Time-to-Replatform in Monaten.

Die Szenarien sind Planungsrahmen. Eine Kursprognose sind sie nicht. Zahlen aus Earnings und Research nur als Eingangsannahmen, nie als Wahrheit des Vertrags.

Wer alle drei Szenarien mit denselben KPIs füllt, sieht sofort, wo der geplante Rahmenvertrag nur im Hochlauf trägt. Das ist der Punkt, an dem Einkauf und Architektur dieselbe Sprache brauchen: weniger „mehr Rabatt“ – und mehr „welche Klausel überlebt das Plateau“.

Vier Klauseln, die den Unterschied machen

Rabatte sind sichtbar. Die teuren Fehler sitzen woanders. Vier Klausel-Typen trennen einen verhandelbaren AI-Cloud-Rahmen von einem Hoffnungspapier.

1. Commitment-Staffelung statt Front-Loading. Statt 100 Prozent des Drei-Jahres-Volumens im Jahr eins bindet die Staffelung Tranchen an Nutzungsmilestones. Jede Tranche hat ein Opt-out mit Frist. Das kostet oft etwas Discount. Es spart den teureren Fehler: Commit ohne Workload.

2. Exit und Portabilität mit Messpunkt. Exit ohne Daten- und Modell-Portabilität ist Theater. Der Vertrag nennt Formate, Exportfristen und einen Testlauf pro Jahr. Wer den Testlauf scheut, weiß, dass der Exit nicht existiert.

3. Reserved Capacity mit Verfallsdatum und Umbuchung. Reservierungen ohne Umbuchung auf verwandte Skus und ohne Verfallslogik erzeugen tote Kontingente. Die Umbuchungsregel gehört in den Hauptteil, nicht in ein FAQ des Anbieters.

4. Preis- und Kapazitäts-Trigger. Wenn Region-Kapazität unter eine vereinbarte Schwelle fällt oder der Referenzpreis einer definierten SKU um mehr als X Prozent steigt, öffnet sich ein Re-Opener. X wird intern gesetzt, nicht vom Vendor-Default.

Der günstigste Cloud-Rabatt ist teuer, wenn er ein Szenario voraussetzt, das der eigene AI-Rollout nicht trägt.

Wo On-Prem-Inference den API-Default schlägt

On-Prem oder private Inference ist kein Gegenentwurf zur Cloud. Es ist der Schalter im Abflachungs- und im Hochlauf-Szenario mit knapper Kapazität. Die Entscheidung hängt an drei messbaren Größen: stabiler Workload mit hoher Token-Dichte, vorhersehbare Latenz-Anforderungen und die Fähigkeit, Eval-Suiten und Routing intern zu betreiben.

Wer diese drei Größen nicht messen kann, kauft weiter API-Default – und sollte das ehrlich so nennen. Wer sie messen kann, verhandelt die Cloud-Tranche kleiner und hält einen internen Pfad offen. Make-or-Buy bei Modellen ist dabei die zweite Achse: ein deutsches oder europäisches Modell rechnet sich oft erst, wenn Inference-Kosten und Datenresidenz in dieselbe Rechnung gehören.

Hardware-Capex im eigenen Haus (Server, Kühlung, Stromverträge) verschiebt das Risiko, löscht es nicht. Der verwandte Beitrag zur Hardware-vs-Software-Capex-Sortierung bleibt die Schwester-Diskussion. Hier zählt nur die Schnittstelle: Welche Workloads haben eine belastbare Break-even-Rechnung gegen den Hyperscaler-Pfad – und stehen die im Vertrag als Option, nicht als PowerPoint?

90 Tage bis zur nächsten Unterschrift

Der Test ist simpel: Würde dieselbe Unterschrift auch dann stehen, wenn das Capex-Wachstum der Anbieter 2027 deutlich flacher ausfällt als 2025/26? Wenn die Antwort von einem einzelnen Rabatt abhängt, ist der Vertrag zu dünn.

Häufig gestellte Fragen

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Mai 2026)