Ray bekommt eine Special Interest Group für herstellerneutrale Beschleuniger-Unterstützung

Warum eine eigene Gruppe für Beschleuniger

Die Ankündigung erschien am 20. Oktober 2026 im Anyscale-Blog, verfasst von Zhe Zhang, Mengjin Yan, Ryan O'Leary (Google) und Richard Liaw. Sie blickt darauf zurück, wie stark sich die Landschaft seit der Entstehung von Ray an der UC Berkeley vor mehr als zehn Jahren verändert hat. Damals bedeutete „verteiltes Rechnen“ CPU-Cluster mit Frameworks wie Apache Hadoop und Apache Spark, und GPUs hielten gerade erst Einzug ins maschinelle Lernen.

Heute seien Beschleuniger spezialisierter und vielfältiger geworden, schreiben die Autoren. Sie nennen mehrere Beispiele: NVIDIAs RTX 6000 Pro für flexible Workloads aus KI-Training, Inferenz, Grafik und Video, NVIDIA B200 und AMD MI355X mit deutlich größerer Speicherkapazität für größere Modelle sowie GB200 NVL72, das 72 GPUs für kommunikationsintensives Training und Inferenz verbindet. Jenseits von GPUs zielen Google Ironwood TPUs auf KI-Workloads im riesigen Maßstab, während Groq LPUs auf Inferenz mit niedriger Latenz spezialisiert sind.

Laut dem Beitrag unterstützt Ray bereits mehr als ein Dutzend Arten von Hardware-Beschleunigern, von NVIDIA- und AMD-GPUs über TPUs und Trainium bis zu Gaudi und weiteren. Die neue Gruppe soll auf dieser Basis aufbauen und systematischer dafür sorgen, dass Beschleuniger einfach nutzbar, im großen Maßstab effizient und im Produktivbetrieb zuverlässig sind.

Drei Schwerpunkte der ersten Roadmap

Der erste Schwerpunkt ist die Infrastruktur für Entwicklung und Tests. Die Gruppe wünscht sich einen dokumentierten Prozess, um Cloud- und vom Hersteller gehostete Beschleuniger in Rays Testumgebung einzubinden, gepflegte Umgebungen mit expliziten Treiber-, Laufzeit- und Abhängigkeitsversionen sowie eine breitere CI-Abdeckung. Diese soll verteilte Workloads, Fehlerbehebung und Performance-Regressionen umfassen, nicht nur grundlegende Gerätefunktionen. Der Beitrag merkt an, dass mit der Beschleunigung der Entwicklung durch agentische Softwareentwicklung sowohl menschliche Contributor als auch Coding-Agenten reproduzierbares Feedback von echter Hardware brauchen.

Der zweite Bereich ist hardwarebewusstes Scheduling. Beschleunigerknoten seien nicht mehr bloß eine Anzahl identischer Geräte, so die Autoren, denn die Leistung hänge davon ab, wie Geräte untereinander verbunden sind, wie sie zu CPUs und Netzwerkkarten stehen und wie Knoten zu Racks und TPU-Slices gruppiert sind. Geplant sind herstellerneutrale Schnittstellen zum Kennzeichnen und Beschreiben von Hardware, darunter eine einheitliche Methode, Beschleuniger-SKUs zum Marktstart zu identifizieren, eine bessere Erkennung, die Topologie und Architektur erfasst, sowie die Zusammenarbeit mit Cloud-Plattformen, da manche Informationen, etwa zu welchem Rack oder Slice ein Knoten gehört, nur von der Plattform stammen. Außerdem plant die Gruppe Ansichten für Beschleuniger und ihre Verbindungen neben Metriken im Ray-Dashboard sowie verständlichere Benutzerleitfäden.

Der dritte Bereich ist Netzwerk- und I/O-Transport. Rays Object Store wurde ursprünglich für CPU-Daten gebaut, sodass Tensoren von Beschleunigern in den Hostspeicher kopiert, serialisiert und über Standardnetzwerke gesendet werden mussten. Ray Direct Transport (RDT) wurde eingeführt, damit Actors Tensor-Referenzen über Ray weitergeben können, während die Daten direkt zwischen den Geräten fließen, mit Transportwegen wie UCX und RDMA. Die Gruppe will, dass RDT mehr Beschleuniger, Frameworks und Interconnects unterstützt, darunter TPU-ICI innerhalb eines Slices, NVLink auf demselben Knoten und GPUDirect RDMA zwischen Knoten, und dass es Initialisierung, Abbau und Fehlerbehebung in Workloads wie Reinforcement Learning und disaggregiertem Serving zuverlässig handhabt.

Zuständigkeit und Mitmachen

Der Beitrag zieht eine Grenze zwischen der Gruppe und Ray Core. Die Kernlogik für Scheduling und Platzierung bleibt in Ray Core, während die SIG Accelerator für Plug-in-Schnittstellen, CI-Tests und Reifegradstufen für Beschleuniger zuständig ist. Hardwarehersteller und Cloud-Anbieter sollen ihre eigenen Geräte-Plug-ins, Transportwege und den Day-Zero-Support für neue SKUs beisteuern und pflegen. Framework-Autoren und ML-Praktiker sollen die Roadmap an den realen Anforderungen von Workloads ausrichten.

Für Nutzer lautet das erklärte Ziel, dass Anwendungen und Bibliotheken auf Hardwarefähigkeiten statt auf herstellerspezifischen Code abzielen können und dass neue Beschleuniger bei Markteinführung mit Ray funktionieren. Zeitpläne für diese Ziele nennt die Quelle nicht.

Eingeladen sind alle, die eine Beschleuniger-Integration bauen, Training oder Inferenz im großen Maßstab auf Ray betreiben oder Cloud- und CI-Infrastruktur bereitstellen. Die Autoren verweisen auf den Ray-Slack, auf Community-Meetings zur Diskussion von Vorschlägen und Roadmap-Prioritäten sowie auf offene Beschleuniger-Issues und Pull Requests auf GitHub.