AWS veröffentlicht Ray Train DLC zur Vereinfachung des verteilten KI-Trainings auf EKS

Amazon Web Services (AWS) hat den Ray Train Deep Learning Container (DLC) veröffentlicht, ein vorkonfiguriertes Image, das das verteilte Training von Machine-Learning-Modellen auf Amazon Elastic Kubernetes Service (EKS) vereinfachen soll. Das im Oktober 2026 veröffentlichte Container-Bundle enthält Ray, PyTorch sowie die erforderlichen Netzwerk-Bibliotheken für Hochleistungsrechnen und ermöglicht es Ingenieuren, Multi-Node-Training-Jobs bereitzustellen, ohne komplexe Abhängigkeitsketten verwalten zu müssen.

Was ist passiert?

Der Hauptengpass beim Skalieren von PyTorch-Trainings über Cluster hinweg liegt oft nicht im Modellcode selbst, sondern in der Container-Infrastruktur. Ingenieure verbringen häufig erhebliche Zeit damit, CUDA-Runtimes, PyTorch-Builds, die NVIDIA Collective Communications Library (NCCL) und Userspace-Bibliotheken für den Elastic Fabric Adapter (EFA) aufeinander abzustimmen. Inkonsistenzen zwischen diesen Komponenten können zu stiller Leistungseinbußen führen, bei denen NCCL auf langsamere TCP-Sockets zurückgreift, anstatt hochgeschwindigkeitsfähige EFA-Verbindungen zu nutzen. Um dies zu beheben, hat AWS ein einheitliches Image zusammengestellt, getestet und im Amazon Elastic Container Registry (ECR) Public Repository veröffentlicht.

Dieses neue DLC wird von AWS gebaut und gewartet, wobei der Stack gepatcht und durch Multi-Node-EFA- und KubeRay-Trainingstests validiert wird. Die Veröffentlichung umfasst Ray 2.58.0, PyTorch 2.13.0, CUDA 13.0.2 und NCCL 2.29.7 sowie das AWS OFI NCCL Plugin, das NCCL mit EFA verbindet. Durch die Bereitstellung als öffentliches Image entfällt für Teams die Notwendigkeit, eigene Container-Images für jedes Update dieser zugrunde liegenden Bibliotheken zu erstellen und zu warten.

Der begleitende technische Leitfaden zeigt, wie dieses DLC verwendet wird, um das Qwen2.5-1.5B-Modell unter Verwendung von PyTorch Fully Sharded Data Parallel (FSDP) auf acht NVIDIA L4 GPUs feinabzustimmen. Das Setup nutzt zwei g6.12xlarge-Instanzen in einer einzigen Availability Zone, verwaltet vom KubeRay-Operator. Diese Konfiguration ermöglicht es, dass inter-node Kollektivoperationen sofort über EFA ausgeführt werden, da das DLC bereits den erforderlichen Netzwerk-Stack enthält.

Wie funktioniert es?

Das Ray Train DLC fungiert als ein einzelnes, rollenneutrales Image, das sowohl für Ray-Head- als auch für Worker-Pods dient. Auf Kubernetes verwendet der KubeRay-Operator ein RayCluster-Manifest, um die erforderlichen Pods zu erstellen und die Worker auf den Head-Node zur Koordination zu verweisen. Da das Image alle notwendigen Treiber und Bibliotheken enthält, müssen Benutzer keine benutzerdefinierten Images erstellen. Stattdessen konfigurieren sie den Cluster über Umgebungsvariablen und Ressourcenanforderungen im Kubernetes-Manifest.

Die Netzwerkkommunikation wird automatisch über vorkonfigurierte Umgebungsvariablen gehandhabt. Das DLC verwendet standardmäßig EFA für die Kommunikation über die Einstellung FI_PROVIDER=efa und schließt Loopback-Schnittstellen aus der NCCL-Konfiguration aus. Wenn ein Job zusätzliche Python-Pakete erfordert, die nicht im Basis-Image enthalten sind, installiert die runtime_env-Funktion von Ray diese zum Zeitpunkt der Übermittlung, wobei das Basis-Image unverändert bleibt. Diese Trennung stellt sicher, dass der Container stabil bleibt, während Flexibilität für spezifische experimentelle Anforderungen gewährleistet wird.

Innerhalb des Containers verwaltet Ray Train die Bildung der verteilten Prozessgruppe. Ingenieure schreiben ihre Trainingsschleife als Standard-Python-Funktion, die Ray über alle verfügbaren GPUs hinweg ausführt. Für FSDP-Workloads teilt Ray Modellgewichte, Gradienten und Optimizer-Zustände auf die GPUs auf, was den Speicherbedarf pro Gerät reduziert. Das DLC stellt sicher, dass der schwere Kommunikationsverkehr, der durch FSDG-Gather- und Reduce-Scatter-Operationen erzeugt wird, über die hochbandbreitenfähige EFA-Schnittstelle statt über Standard-Netzwerk-Sockets läuft.

Wichtige Details

• Image Tag: Das Beispiel verwendet public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1, welches Ray 2.58.0 und PyTorch 2.13.0 enthält.
• Hardwareunterstützung: Die Referenzarchitektur verwendet g6.12xlarge-Instanzen mit NVIDIA L4 GPUs und EFA-Schnittstellen, bereitgestellt in einer einzelnen Availability Zone.
• Netzwerk-Stack: Enthält CUDA 13.0.2, NCCL 2.29.7 und das AWS OFI NCCL Plugin, getestet, um die Nutzung von EFA anstelle eines TCP-Fallbacks sicherzustellen.
• Konfigurationsmethode: Clusterform und Transport-Einstellungen werden über Umgebungsvariablen und Kubernetes-Ressourcenanforderungen definiert, nicht durch Neuaufbau des Images.
• Kostenschätzung: Das Beispiel-Setup kostet ungefähr 9,50 USD pro Stunde, einschließlich zweier GPU-Instanzen, des EKS-Control-Planes und eines NAT Gateways.
• Treiberkompatibilität: Der Container-Entrypoint aktiviert automatisch CUDA Forward-Compatibility-Bibliotheken, wenn der NVIDIA-Treiber des Hosts älter ist als die CUDA-Version des Images.

Warum ist das wichtig?

Für Software-Ingenieure und ML-Teams reduziert diese Veröffentlichung den operativen Aufwand für verteiltes Training erheblich. Das Verwalten kompatibler Versionen von CUDA-, NCCL- und EFA-Treibern ist ein fragiler Prozess, der oft zu subtilen Leistungsproblemen führt. Durch die Bereitstellung eines getesteten öffentlichen Images ermöglicht AWS Teams, sich auf die Modellsentwicklung statt auf das Debugging der Infrastruktur zu konzentrieren. Die Möglichkeit, bestimmte Versionen festzulegen oder bewegliche Tags für Sicherheitsupdates zu verwenden, bietet Flexibilität sowohl für reproduzierbare Forschung als auch für Produktionsstabilität.

Die Integration mit KubeRay und EKS vereinfacht zudem das Cluster-Management. Ingenieure können ihre gesamte Trainingsinfrastruktur in einem einzigen Manifest definieren, indem sie GPU-Anzahlen und EFA-Schnittstellen als Standard-Kubernetes-Ressourcen angeben. Dieser Ansatz nutzt vorhandene Kubernetes-Tools und vermeidet die Notwendigkeit benutzerdefinierter Skripte zur Verwaltung von Ray-Cluster-Lebenszyklusereignissen. Das Ergebnis ist ein zuverlässigerer und skalierbarer Weg, Feinabstimmungs-Jobs für große Sprachmodelle auf der AWS-Infrastruktur auszuführen.

Was Sie tun können

• Beispiel-Repository prüfen: Greifen Sie auf den bereitgestellten Code und die Manifeste zu, um die Struktur eines Ray Train Jobs auf EKS zu verstehen.
• Quota-Verfügbarkeit prüfen: Stellen Sie sicher, dass Ihr AWS-Konto über ausreichende On-Demand-Kapazität für G-Familien-Instanzen verfügt, insbesondere 96 vCPUs für die beiden g6.12xlarge-Nodes.
• Erforderliche Tools installieren: Richten Sie AWS CLI v2, eksctl, kubectl, Helm und envsubst ein, um den Cluster zu verwalten und Jobs zu übermitteln.
• DLC lokal testen: Ziehen Sie das öffentliche Image aus ECR, um die Kompatibilität mit Ihrer lokalen Entwicklungsumgebung zu überprüfen, bevor Sie es auf dem Cluster bereitstellen.
• Umgebungsvariablen konfigurieren: Verwenden Sie das bereitgestellte scripts/env.sh, um Cluster-Parameter wie Region, Instanztyp und Image Tag festzulegen.
• Netzwerkperformance überwachen: Aktivieren Sie NCCL_DEBUG=INFO in Ihrem Manifest, um zu bestätigen, dass EFA für die Inter-Node-Kommunikation während des Trainings verwendet wird.