In der Werkstatt der verteilten Rechenkunst liegt seit dieser Woche eine neue Scheibe auf dem Tisch. Keine Wurst, obwohl manche Clusterverwaltung danach riecht. Eine TPU-Scheibe. Und Google erklärt im Entwicklerblog, dass Ray sie nun nicht mehr wie einen exotischen Kellerfund behandelt, sondern als ordentlichen Accelerator mit Platzkarte.
Der Anlass: Im Google-Developers-Beitrag vom 20. Juli 2026 heißt es, Google Cloud TPUs seien ab Ray 2.55 ein „first-class accelerator“ in Ray. Offizielle APIs, vorgebaute Images, Release-Pipeline statt Bastelkeller. Wer Python-Arbeit bisher mit Ray auf GPUs über Tasks und Actors verteilt hat, soll denselben Denkapparat nun Richtung TPU schieben können.
Die Scheibe ist kein Streusel
Der Haken trägt keinen roten Hut, sondern ein Interconnect-Kabel. Google beschreibt die TPU-Slice als feste Gruppe mehrerer Hosts, deren Chips über eine schnelle Verbindung zusammenhängen. Wenn ein Multi-Host-Job quer über falsche Maschinen verstreut wird, reden die Worker nicht mehr ordentlich miteinander. Dann hängt das Training nicht dramatisch, sondern bürokratisch: alle stehen da, keiner stempelt, der All-Reduce schaut auf seine Schuhe.
Für GPU-Leute übersetzt Google das ungefähr so: Stell dir eine Kiste mit schnellem Innenkabel vor. Innerhalb der Kiste flutscht es, außerhalb ist plötzlich Dorfstraße. Eine TPU-Topologie ist also nicht nur eine Zahl auf dem Einkaufszettel, sondern die Form der Scheibe. 4×4 heißt nicht „irgendwo sechzehn Chips zusammenkratzen“, sondern: diese zusammenhängende Platte, bitte unzerlegt.
GKE klebt Namensschilder, Ray hält den Hubwagen an
Damit die Sache nicht wieder im YAML-Sumpf versinkt, schiebt Google Kubernetes Engine den Ray-Operator samt KubeRay und TPU-spezifischem Webhook vor. Der Webhook markiert laut Beitrag die TPU-Hosts so, dass Ray erkennt, welche Maschinen zu derselben Slice gehören. Aus Sicht der Blechpresse ist das ein erstaunlich vernünftiger Vorgang: Erst klebt jemand Namensschilder an die Paletten, dann darf der Scheduler den Hubwagen bewegen.
Ray Core bekommt dafür eine Slice Placement Group. Die reserviert die ganze TPU-Slice atomar: alles oder nichts, keine halbe Brotscheibe mit abgerissenem Kabel. Google schreibt allerdings auch dazu, dass man diese API selten direkt anfassen soll; Ray Data, Train und Serve sollen sie in der Praxis für die Bibliotheksarbeit nutzen. Der sichtbare Bedienhebel bleibt also: Topologie angeben, Arbeit beschreiben, nicht selbst mit dem Schraubenzieher in die Interconnect-Rinne fallen.
Warum das mehr ist als Cloud-Blechsortierung
Die kleine Pointe steckt in der Normalisierung. TPUs waren lange etwas, das in vielen Köpfen eher nach Sonderraum roch: stark, schnell, aber bitte Formular A38 mit eigener Container-Gewürzmischung. Wenn Ray sie nun als regulär planbaren Accelerator führt, rückt Spezialhardware ein Stück näher an den alltäglichen Agenten-, Trainings- und Serving-Betrieb. Nicht magisch. Eher: weniger Klebeband.
Natürlich bleibt die Maschine eine Maschine. Wer sie falsch belädt, bekommt keine poetische Fehlermeldung, sondern ein hängendes verteiltes System mit sehr teuren Lämpchen. Aber genau dafür ist diese Ankündigung interessant: Sie sagt nicht „KI wird alles“, sondern „der Scheduler weiß jetzt, dass manche Scheiben nicht geschnitten werden dürfen“. Das ist in der Infrastrukturwelt fast schon Romantik.
Am Ende steht also kein goldener Zukunftsautomat, sondern eine Werkbankregel: Ray darf auf TPU, GKE hält die Slice zusammen, und wer Worker verstreut wie Büroklammern nach der Weihnachtsfeier, hört das Interconnect beleidigt schweigen.