AWS’ Beispiel für verteiltes Training mit Ray Train auf Amazon EKS nutzt den veröffentlichten Ray Train Deep Learning Container unverändert: Ein Qwen2.5-1.5B-Modell wird mit PyTorch FSDP und bfloat16 auf acht NVIDIA-L4-GPUs in zwei g6.12xlarge-Instanzen verteilt. Für den EFA-Datenverkehr müssen beide GPU-Instanzen in derselben Verfügbarkeitszone und derselben VPC liegen.

Was das Beispiel aufbaut

Ein m7i.xlarge-Systemknoten hostet den KubeRay-Operator und den GPU-freien Ray-Head. Dazu kommen zwei g6.12xlarge-Instanzen als GPU-Worker. Jede stellt vier NVIDIA-L4-GPUs und eine EFA-Schnittstelle bereit; Ray Train verteilt den Lauf auf acht Worker.

KomponenteKonfiguration im BeispielAufgabe
SystemknotenEine m7i.xlarge-InstanzHostet den KubeRay-Operator und den Ray-Head ohne GPUs.
GPU-WorkerZwei g6.12xlarge-Instanzen, jeweils mit vier NVIDIA-L4-GPUs und einer EFA-SchnittstelleFühren die verteilten Trainings-Worker aus.

Voraussetzungen und EFA-Platzierung

Für die beiden g6.12xlarge-Instanzen setzt AWS 96 vCPUs an On-Demand-Kapazität der G-Familie oder eine bestehende On-Demand-Kapazitätsreservierung voraus. AWS führt g6.12xlarge als EFA-fähigen Instanztyp; welche unterstützten Typen verfügbar sind, hängt von der Region ab.

EFA-Datenverkehr kann laut AWS-Dokumentation zu EFA weder Verfügbarkeitszonen noch VPC-Grenzen überschreiten. Prüfe daher vor dem Aufbau des Clusters die EFA-Unterstützung in der gewählten Region und plane beide GPU-Worker in derselben VPC und Verfügbarkeitszone. Gewöhnlicher IP-Verkehr über ENA ist davon getrennt und bleibt routbar.

Ray Train und EFA konfigurieren

Das Beispiel verwendet für Ray-Head und Worker denselben veröffentlichten Container, ohne ein eigenes Image zu bauen: public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1. AWS nennt dafür Ray 2.58.0, PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2 und NCCL 2.29.7.

Jeder Worker-Pod fordert vier GPUs und ein EFA-Gerät an. Kubernetes und Ray müssen dieselbe GPU-Zahl erhalten; im Beispiel wird Ray’s num-gpus aus derselben Variable wie die GPU-Anforderung des Pods abgeleitet. Die Pods setzen außerdem jeweils 40 CPUs und 160Gi Speicher an. Anforderungen und Limits sind gleich gesetzt.

Für den Netzwerkpfad verwendet das Beispiel diese Variablen:

FI_PROVIDER=efa
NCCL_NET_PLUGIN=ofi
NCCL_SOCKET_IFNAME=eth0
NCCL_DEBUG=INFO

Der Pod fordert zusätzlich vpc.amazonaws.com/efa: 1 an. Fehlt diese Anforderung oder ist EFA nicht verfügbar, kann NCCL auf Socket-Kommunikation über TCP zurückfallen.

Cluster bereitstellen und Job starten

Schematische Netzwerkübersicht mit einem EFA-Pfad zwischen zwei GPU-Workern in derselben Verfügbarkeitszone und VPC sowie getrennten, blockierten EFA-Pfaden über Zonengrenzen und zwischen VPCs.

Führe die Schritte in dieser Reihenfolge aus, damit Kapazität, Geräte und Ray-Komponenten verfügbar sind, bevor der Trainingsjob startet.

  1. Konfiguriere scripts/env.sh. Trage Cluster, Region, Knotentypen, Container und Trainingswerte ein. Das Skript bündelt die Einstellungen, die die folgenden Bereitstellungsschritte benötigen.
  2. Prüfe die Kapazität und erstelle Cluster und Knotengruppe. deploy_all.sh prüft die Kapazität und legt die Infrastruktur an. --plan zeigt die vorgesehenen Infrastrukturaktionen vorab an.
  3. Installiere oder prüfe die GPU- und EFA-Geräte-Plug-ins. Sie machen GPU- und EFA-Ressourcen für Kubernetes-Pods verfügbar.
  4. Installiere KubeRay. Der Operator verwaltet anschließend den RayCluster in Kubernetes.
  5. Rendere und wende das RayCluster-Manifest an. Starte dafür deploy_ray_train_job.sh; das Skript prüft auch, welche GPU- und EFA-Ressourcen auf den GPU-Knoten verfügbar sind.
  6. Reiche den Trainingsjob aus dem Ray-Head-Pod ein. Das Beispiel nutzt dafür kubectl exec. Der Ray-Jobserver läuft auf Port 8265, wird aber nicht außerhalb des Clusters freigegeben.

Die Knoten liegen in privaten Subnetzen einer VPC. Ein NAT-Gateway ermöglicht Downloads, darunter den veröffentlichten Container und die Modellgewichte von Hugging Face.

Ressourcen und EFA-Nutzung prüfen

Vor dem Start sollten die GPU- und EFA-Ressourcen auf jedem GPU-Knoten als verfügbar ausgewiesen sein. Das Beispiel verwendet außerdem das Knotenlabel nvidia.com/gpu.present=true. Gleiche Kubernetes-Anforderungen und Limits sorgen in dieser Konfiguration für die QoS-Klasse Guaranteed.

Prüfe nach dem Start, welchen Transport NCCL tatsächlich gewählt hat. AWS’ Beispielskript kontrolliert, ob EFA im NCCL-Pfad liegt, und bricht ab, wenn das nicht der Fall ist. So lässt sich ein TCP-Fallback von einer tatsächlich genutzten EFA-Verbindung unterscheiden.

Trainingsdaten und Leistungsangabe

Der Lauf verwendet zufällig erzeugte Token-IDs und keinen echten Trainingsdatensatz. Für ein Fine-Tuning mit realen Daten muss die Eingabe laut AWS durch eine Datenpipeline mit Ray Data oder einem DataLoader ersetzt werden.

AWS berichtet für den Beispielcode von einem doppelt so hohen Durchsatz über EFA wie über TCP. Diese Angabe bezieht sich auf den beschriebenen Beispiel-Lauf; AWS nennt sie nicht als allgemeine Leistungsgarantie.