Ray gründet Special Interest Group für die Unterstützung von Beschleunigern

Warum Ray eine Beschleunigergruppe einrichtet

Laut der Ankündigung sah die Computerlandschaft ganz anders aus, als Ray vor mehr als zehn Jahren an der UC Berkeley entstand. Damals bedeutete "verteiltes Rechnen" CPU-Cluster, auf denen Frameworks wie Apache Hadoop und Apache Spark liefen, und GPUs begannen gerade erst, aus Grafik und wissenschaftlichem Rechnen ins maschinelle Lernen vorzudringen.

Heute steht beschleunigtes Rechnen im Zentrum der Entwicklung und des Betriebs von KI, und die Hardware ist spezialisierter und vielfältiger geworden. Der Beitrag nennt mehrere Beispiele:

• NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs, die Workloads aus KI-Training, Inferenz, Grafik und Video unterstützen.
• NVIDIA HGX B200, das deutlich mehr Speicherkapazität für größere Modelle bietet, sowie NVIDIA GB200 NVL72, das 72 NVIDIA-Blackwell-GPUs für kommunikationsintensives Training und Inferenz in großem Maßstab verbindet.
• AMD MI355X, das ebenfalls reichlich Speicherkapazität für große Modelle bereitstellt.
• Google Ironwood TPUs, die auf KI-Workloads in riesigem Maßstab zielen.
• NVIDIA Groq 3 LPUs, die auf Inferenz mit niedriger Latenz spezialisiert sind.

Ray unterstützt bereits mehr als ein Dutzend Arten von Hardwarebeschleunigern, von NVIDIA- und AMD-GPUs über TPUs bis hin zu Trainium, Gaudi und weiteren. Die neue SIG 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. Sie bringt Hardwarehersteller, Ray-Contributor und Anwendungsentwickler zusammen.

Drei Schwerpunkte: Tests, Scheduling und Netzwerke

Die erste Roadmap umfasst drei Bereiche. Der erste ist die Entwicklungs- und Testinfrastruktur. Laut SIG braucht verlässliche Beschleunigerunterstützung einen dauerhaften Hardwarezugang, damit Contributor Änderungen validieren, Fehler reproduzieren und Regressionen erkennen können. Da agentisches Software Engineering die Entwicklung beschleunige, benötigten sowohl menschliche Contributor als auch Coding-Agenten reproduzierbares Feedback von echter Hardware. Geplant sind gemeinsamer Hardwarezugang über einen dokumentierten Prozess, mit dem Cloud- und herstellergehostete Beschleuniger in die Infrastruktur von Ray eingebunden werden, gepflegte Umgebungen mit expliziten Treiber-, Runtime- und Abhängigkeitsversionen, eine breitere CI-Abdeckung, die verteilte Workloads, Fehlerbehebung und Performance-Regressionen einschließt, sowie klare Zuständigkeiten für die Pflege des Aufbaus.

Der zweite Bereich ist hardwarebewusstes Scheduling. Der Beitrag argumentiert, Beschleunigerknoten seien nicht länger nur eine Anzahl identischer Geräte, denn die Leistung hängt davon ab, wie die Geräte untereinander verbunden sind, wie sie zu CPUs und Netzwerkkarten stehen und wie Knoten zu Racks und TPU-Slices gruppiert sind. Ziel ist es, Ray über Hersteller und Plattformen hinweg ein genaues, konsistentes Bild dieser Struktur zu geben, damit der Scheduler Tasks und Actors auf passender Hardware platzieren kann. Zu den Prioritäten zählen gemeinsame herstellerneutrale Schnittstellen zum Kennzeichnen und Beschreiben von Hardware, ein dokumentierter Erweiterungspunkt samt Checkliste für Hersteller, die einen neuen Beschleuniger anbinden, eine gehärtete Erkennung, die Topologie und Architektur erfasst, die Zusammenarbeit mit Cloud-Anbietern, da manche Informationen wie die Zugehörigkeit zu Rack oder Slice nur von der Plattform stammen, Hardwareansichten neben Beschleunigermetriken im Ray Dashboard sowie klarere Benutzerleitfäden.

Schnellere Datenübertragung zwischen Geräten

Der dritte Bereich sind Netzwerke und I/O-Transport. Die Ankündigung hält fest, dass das Verschieben von Daten zwischen Beschleunigern oft ebenso wichtig sei wie die Berechnung selbst. Workloads wie Reinforcement Learning in großem Maßstab müssen große Gewichts-Tensoren von Modellen vom Training zu Inferenz-Workern über Geräte und Knoten hinweg übertragen.

Rays Object Store wurde historisch für CPU-Daten gebaut, sodass Beschleuniger-Tensoren in den Hostspeicher kopiert, serialisiert und über übliche Host-Netzwerke gesendet werden mussten. Ray Direct Transport (RDT) wurde eingeführt, damit Actors Referenzen auf Tensoren über Ray weitergeben können, während die Daten selbst direkt zwischen den Geräten fließen, und zwar über Hochleistungstransporte wie UCX und RDMA.

Die SIG will erreichen, dass dies über verschiedene Beschleuniger, Frameworks und Netzwerk-Fabrics hinweg zuverlässig funktioniert und dabei Rays vertrautes Programmiermodell erhalten bleibt. Zu den Prioritäten gehört, in RDT mehr Beschleuniger, Frameworks und Interconnects zu unterstützen, damit Ray den schnellsten Pfad wählen kann, etwa TPU-ICI innerhalb eines Slice, NVIDIA NVLink für Scale-up oder GPUDirect RDMA für Scale-out. Hinzu kommen saubere Initialisierung, Abbau und Fehlerbehebung für jeden Transport sowie validierte Deployment-Rezepte mit Benchmarks, Diagnosen und Transportmetriken, die von Cloud- und Hardwareanbietern veröffentlicht werden.

Umfang und Mitmachen

Die zentrale Scheduling- und Platzierungslogik bleibt in Ray Core. Die SIG Accelerator wird dafür zuständig sein, die Plug-in-Schnittstellen, CI-Tests und Reifegradstufen für Beschleuniger in Ray zu definieren. Hardwarehersteller und Cloud-Anbieter sollen ihre eigenen Geräte-Plug-ins, Transporte und den Day-Zero-Support für neue SKUs beisteuern und pflegen, während Framework-Autoren und ML-Praktiker die Roadmap am realen Bedarf der Workloads ausrichten.

Die Gruppe lädt Integratoren von Beschleunigern, Teams, die Training oder Inferenz in großem Maßstab auf Ray betreiben, sowie Anbieter von Cloud- und CI-Infrastruktur zur Teilnahme ein. Mitmachen kann man über den Ray Slack, über Community-Meetings, in denen Vorschläge besprochen und Roadmap-Prioritäten geprüft werden, sowie über offene beschleunigerbezogene Issues und Pull Requests auf GitHub.

Für Nutzer lautet das erklärte Ziel ein klarerer, herstellerneutraler Weg, wie neue Hardware in Ray unterstützt wird, mit besseren Tests und mehr Einblick in den Aufbau von Clustern. Zeitpläne für einzelne Punkte der Roadmap nennt der Beitrag nicht.