Ein Entwickler sitzt vor seinem Terminal und versucht, eine GPU-Instanz in der Cloud zu starten. Die API antwortet nicht mit einem klaren Nein, sondern mit einem knappen Hinweis: Die angeforderte Kapazität sei derzeit nicht verfügbar, man solle es später erneut versuchen. Er weiß, dass Retry-Logik nicht helfen wird. Die Hardware, die er braucht, existiert in diesem Moment schlicht nicht in der Region, in der seine Daten liegen. Er schaut in die Dokumentation des Cloud-Anbieters und findet dort einen Satz, der ihm wie Hohn vorkommt: Die Cloud sei darauf ausgelegt, nahezu unbegrenzt zu sein, und es sei die Verantwortung des Anbieters, genügend Rechenkapazität bereitzustellen.
Dieser Satz war fünfzehn Jahre lang eine stabile Vertrauensbasis. Dann wollten alle gleichzeitig dieselben Beschleuniger kaufen – GPUs für Machine Learning, TPUs für Tensor-Berechnungen. Die Nachfrage explodierte, das Angebot blieb zurück, und die scheinbar unbegrenzte Cloud zeigte plötzlich harte Grenzen. Wer heute ernsthaft mit KI-Modellen arbeitet, kennt das Problem: Man fragt nach einem Knoten mit acht H100-GPUs, und die Antwort ist nicht „nein“, sondern „warte“. Dieses Warten kann Stunden, Tage oder Wochen dauern. Das ist keine temporäre Engpass-Situation, sondern eine strukturelle Veränderung. Wir müssen uns damit abfinden: Compute-Knappheit ist permanent. Die Frage ist nicht, ob wir mit der Knappheit leben müssen, sondern wie wir sie in unsere Architektur einbauen.
Warum die Knappheit bleibt: Die Hardware-Realität
Wer nicht tief in der Hardware-Welt lebt, braucht einen kurzen Exkurs. Eine GPU wie NVIDIA H100 ist ein allgemeiner Parallelbeschleuniger mit eigenem Hochgeschwindigkeitsspeicher, der direkt neben dem Rechenkern auf dem Chip sitzt. Eine TPU ist dagegen ein spezialisierter Chip für Matrix-Mathematik, das Herz des maschinellen Lernens. Beide haben gemeinsam, dass ihre Produktion an wenigen Engpässen hängt: dem Hochgeschwindigkeitsspeicher und der fortschrittlichen Verpackungstechnologie, die Speicher und Die verbindet. Diese Kapazitäten sind in der gesamten Industrie begrenzt. Man kann das Problem nicht mit einem größeren Cloud-Budget oder einer geduldigeren Retry-Schleife lösen. Der Flaschenhals liegt weit oberhalb des Cloud-Anbieters, in den Fertigungsstraßen, die Jahre brauchen, um neue Kapazitäten aufzubauen.
Die Nachfrage nach diesen Chips steigt schneller, als die Verpackungslinien gebaut werden können. Selbst wenn sich alle Hersteller sofort auf den Ausbau konzentrieren würden, wäre die Lücke nicht vor dem nächsten Jahrzehnt geschlossen. Wir müssen aufhören, auf das Ende des Engpasses zu warten. Stattdessen sollten wir unsere Systeme so entwerfen, dass sie auch mit einer dauerhaften Knappheit funktionieren. Genau das ist die Idee der Compute Fallback Ladder, einer Methode, die der Ingenieur Casey West beschrieben hat. Sie ist keine neue Physik, sondern eine systematische Antwort auf eine veränderte Realität.
Die Lücke in den Pattern-Katalogen
Wer die großen Musterkataloge für Cloud-Architekturen durchforstet, sucht vergeblich nach einem Muster, das das Problem „Die gewünschte Compute-Ressource ist nicht beschaffbar“ adressiert. Azure bietet Muster wie Throttling, Queue-Based Load Leveling oder Circuit Breaker – sie alle regulieren die Nachfrage gegen eine angenommene Kapazität. Google Cloud betont hohe Verfügbarkeit durch Redundanz und horizontale Skalierung. AWS setzt – wie eingangs zitiert – voraus, dass die Kapazität vorhanden ist. Kein einziges Muster behandelt den Fall, dass die Hardware selbst nicht verfügbar ist. Das ist kein Zufall, sondern eine Lücke in der gesamten Denkweise.
Diese Lücke ist die direkte Folge der ursprünglichen Cloud-Annahme: unbegrenzte Ressourcen. Jetzt, wo die Grenzen sichtbar werden, fehlt uns das Vokabular, um Lösungen zu beschreiben. Wir haben Muster für Lastspitzen, für Ausfälle, für Spitzenlast – aber nicht für das Nicht-Vorhandensein der Grundressource. Die Compute Fallback Ladder füllt genau diese Lücke. Sie ist kein weiteres Pattern neben den anderen, sondern eine Meta-Struktur, die die vorhandenen Muster wie Load Shedding oder Degraded Modes als unterste Sprossen integriert.
Die Leiter: Sprossen, Selektor und Aufstieg
Die Leiter besteht aus drei Elementen: den Sprossen, einem Selektor und einem Mechanismus zum Wiederaufstieg. Die Sprossen sind eine geordnete Liste von Ausführungszielen, von der bevorzugten Ressource hinunter zu Notlösungen. Typischerweise sieht das so aus: zuerst der bevorzugte Accelerator (z. B. H100), dann ein alternativer Accelerator (A100), dann ein kleineres Modell, das auf einen günstigeren Chip passt, dann CPU, und ganz unten gecachte Antworten oder approximative Ergebnisse. Jede Stufe erkauft sich eine höhere Wahrscheinlichkeit, tatsächlich zu laufen, mit geringerer Genauigkeit oder höherer Latenz.
Der Selektor entscheidet zur Laufzeit, welche Sprosse benutzt wird. Das ist entscheidend: Nicht beim Deployment, sondern wenn die Anfrage eintrifft, muss klar sein, welche Hardware in diesem Moment verfügbar ist. Eine statische Entscheidung wäre nach wenigen Stunden veraltet. Der Aufstiegsmechanismus sorgt dafür, dass das System zur bevorzugten Sprosse zurückkehrt, sobald Kapazität wieder da ist. Ohne diesen Mechanismus wäre die Leiter nur eine Einbahnstraße in die Degradation – ein dauerhafter Qualitätsverlust. Erst die Aufwärtsbewegung macht aus der Leiter ein Werkzeug, kein Falltür.
Casey West hat diesen Mechanismus nicht nur theoretisch beschrieben, sondern in einem Referenz-Repository implementiert. Er nutzt dafür die Custom ComputeClass in Google Kubernetes Engine, die genau diese Hierarchie aus Sprossen, Selektor und Migration abbildet. Das Objekt zeigt, dass die Idee praktisch funktioniert, und es offenbart auch die Tücken, die nur beim Bauen sichtbar werden.
Die Implementierung: Was das Objekt wirklich sagt
Beim Bauen der Leiter zeigten sich drei entscheidende Erkenntnisse. Die erste betrifft das Feld whenUnsatisfiable. Wer es weglässt, erhält den Standardwert DoNotScaleUp. Das bedeutet: Wenn die oberste Sprosse nicht verfügbar ist, skaliert das System nicht und der Pod bleibt im Zustand Pending hängen. Eine Leiter, deren unterste Sprosse „nichts liefern“ ist, ist keine Leiter. Der Wert ScaleUpAnyway ist es, der das Abstiegsszenario überhaupt ermöglicht. Man muss dieses Feld also bewusst setzen, sonst funktioniert das Muster nicht.
Die zweite Erkenntnis: activeMigration ist der eigentliche Kern. Ohne dieses Feld gibt es keinen Wiederaufstieg – man bleibt auf dem degradierten Niveau, auch wenn die bevorzugte Hardware wieder da ist. Mit optimizeRulePriority sorgt GKE dafür, dass bei verfügbarer Kapazität ein neuer Knoten der oberen Sprosse erstellt wird, der untere abgeschaltet und das Workload hinüberwandert. Das dauert – in Wests Test waren es fünf Minuten und 41 Sekunden für einen kompletten Zyklus. Das muss man einplanen, wenn man die Leiter als Teil der Architektur nutzt.
Drittens: Abstieg und Aufstieg sind nicht symmetrisch. Der Abstieg sollte niemals eine Hysterese haben, denn wenn die Hardware fehlt, kann man nicht warten. Der Aufstieg dagegen braucht eine Dämpfung, sonst flattert das System zwischen den Sprossen hin und her. Im Referenz-Repository gibt es daher einen Parameter promotion_hysteresis, der festlegt, wie oft eine höhere Sprosse verfügbar sein muss, bevor gewechselt wird. Außerdem gibt es max_degraded_seconds, das eine Warnung auslöst, wenn man zu lange im degradierten Modus arbeitet – aber keine automatische Eskalation, da diese wiederum zu Flattereffekten führen würde.
Die Mechanismen in der Cloud: Was schon existiert
Die gute Nachricht: Man muss das Rad nicht neu erfinden. Die Bausteine für die Leiter sind in den großen Clouds bereits vorhanden. Auf Google Cloud gibt es die AI Hypercomputer-Strategie mit Spot-VMs, die bis zu 91% günstiger sind, aber jederzeit beendet werden können, sowie Dynamic Workload Scheduler mit Flex-Start für bis zu sieben Tage Wartezeit. Auf AWS gibt es Capacity Blocks für ML und Spot-Instanzen für die unterste Sprosse, auf Azure Reservierungen und Spot-VMs. Was fehlt, ist das verbindende Konzept, das diese Mechanismen in eine geordnete Fallback-Struktur bringt.
Diese Struktur ist die Compute Fallback Ladder. Sie ist kein Produkt, sondern ein Architekturmuster, das sich auf verschiedene Clouds übertragen lässt. Casey West betont, dass die Idee nicht neu ist: Schon in den 1980er Jahren gab es das Cycle Scavenging, etwa das Condor-System, das ungenutzte Workstation-Zyklen einsammelte. Backfill Scheduling ist ebenfalls jahrzehntealt. Und das Brownout-Muster aus dem ICSE 2014 beschreibt, wie Systeme unter Last optionale Arbeit abwerfen. Neu ist nicht die Einzeltechnik, sondern die Zusammenführung in einer geordneten, aufsteigenden Struktur.
Was das für uns bedeutet
Die Botschaft ist klar: Compute-Knappheit wird uns nicht verlassen. Wer heute mit Machine Learning arbeitet, muss eine Fallback-Strategie für seine Compute-Ressourcen einplanen, und zwar keine einmalige Notlösung, sondern einen permanenten Bestandteil der Architektur. Das ist keine Kapitulation vor den Umständen, sondern eine notwendige Anpassung an die Realität. Die Cloud ist nicht mehr die unendliche Ressource, die sie einmal schien. Sie ist ein Markt mit begrenzten Gütern, und wer klug plant, hat verschiedene Bezugsquellen und eine Leiter, um bei Engpässen nicht komplett stillzustehen.
Die Compute Fallback Ladder ist ein konkretes Werkzeug, das uns hilft, mit dieser Knappheit umzugehen. Sie zwingt uns, über die Sprossen nachzudenken, über den Selektor zur Laufzeit und über den Wiederaufstieg. Sie macht die GPU-Knappheit in der Cloud zu einem beherrschbaren Risiko, statt zu einem Katastrophenszenario. Und sie zeigt, dass Cloud-Zuverlässigkeit nicht bedeutet, dass alles immer verfügbar ist, sondern dass wir angemessen reagieren können, wenn es nicht so ist. Das ist die gelassene Haltung, die wir brauchen: nicht Panik, sondern Vorbereitung. Die Hardware-Verfügbarkeit wird volatil bleiben, aber unsere Systeme müssen es nicht sein.
Quelle: caseywest.com
