AWS publiceerde op 28 oktober 2026 een voorbeeld voor gedistribueerde training met Ray Train op Amazon EKS. Het gebruikt de gepubliceerde Ray Train-container ongewijzigd voor de Ray-head en workers, en zet Qwen2.5-1.5B met PyTorch FSDP en bfloat16 op twee g6.12xlarge-instanties met samen acht NVIDIA L4-GPU’s. Voor de EFA-verbinding moeten de GPU-workers in dezelfde VPC en Availability Zone staan.

Wat het voorbeeld opzet

Een m7i.xlarge-systeemnode host de KubeRay-operator en een Ray-head zonder GPU’s. De twee GPU-instanties draaien elk één Ray-workerpod met vier GPU’s en één EFA-interface. Ray Train verdeelt de acht workers over die instanties.

NodeConfiguratie in het voorbeeldRol
SysteemnodeEén m7i.xlargeHost de KubeRay-operator en de GPU-loze Ray-head.
GPU-workersTwee g6.12xlarge-instanties, elk met vier NVIDIA L4-GPU’s en één EFA-interfaceDraaien elk één workerpod voor Ray Train.

Vereisten en plaatsing van EFA

Plan de GPU-nodes in één VPC en één Availability Zone. AWS vermeldt dat EFA-verkeer niet tussen Availability Zones of VPC’s kan lopen. Gewoon IP-verkeer via ENA is een afzonderlijk netwerkpad en blijft routeerbaar. AWS noemt g6.12xlarge als een EFA-ondersteund instantietype, maar de beschikbaarheid van zulke instanties verschilt per regio. Controleer daarom de ondersteuning in de AWS-regio die je wilt gebruiken voordat je de infrastructuur aanmaakt.

Voor de twee g6.12xlarge-instanties noemt AWS een vereiste van 96 G-family On-Demand-vCPU’s, of een bestaande On-Demand Capacity Reservation. De voorbeeldarchitectuur gebruikt private subnetten binnen één VPC en een NAT Gateway om downloads mogelijk te maken.

Ray Train en EFA configureren

Het voorbeeld gebruikt de gepubliceerde image-tag public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1 voor zowel de Ray-head als de workers. AWS vermeldt in die container Ray 2.58.0, PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2 en NCCL 2.29.7.

Elke workerpod vraagt vier GPU’s en één EFA-device aan. De configuratie stelt de Kubernetes-GPU-aanvraag gelijk aan Ray’s num-gpus, zodat beide systemen dezelfde capaciteit zien. AWS gebruikt ook deze omgevingsvariabelen voor de netwerklaag:

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

De resourceaanvragen en -limieten zijn gelijk: per workerpod 4 GPU’s, 1 EFA-device, 40 CPU en 160Gi geheugen. De voorbeeldconfiguratie gebruikt verder het node-label nvidia.com/gpu.present=true voor de GPU-nodes.

Het cluster maken en de job indienen

Conceptdiagram met een AWS-regio, meerdere Availability Zones en een VPC. Een EFA-verbinding koppelt twee GPU-workerblokken binnen dezelfde VPC en zone; paden over grenzen zijn doorgestreept.

Volg de afhankelijkheden in deze volgorde:

  1. Configureer scripts/env.sh. Stel de cluster-, regio-, node-, image- en trainingsvariabelen in. Zo gebruiken de infrastructuur- en jobstappen dezelfde configuratie.
  2. Controleer de capaciteit en maak de infrastructuur aan. Voer deploy_all.sh uit om de capaciteit te controleren en het EKS-cluster en de nodegroep aan te maken. Met --plan bekijk je de geplande infrastructuuracties.
  3. Installeer of controleer de GPU- en EFA-deviceplugins. Kubernetes moet de GPU’s en EFA-devices als toewijsbare resources op de GPU-nodes herkennen.
  4. Installeer KubeRay. De operator beheert de RayCluster-resource binnen Kubernetes.
  5. Pas de Ray-jobconfiguratie toe en dien de job in. deploy_ray_train_job.sh genereert en past het manifest toe, controleert de beschikbare resources en start de RayCluster. De voorbeeldprocedure dient de job vanuit de Ray-head-pod in via kubectl exec; poort 8265 wordt daarbij niet buiten het cluster opengesteld. Met --train voert het script de trainingsstap na de infrastructuursetup uit.

Controleren of NCCL EFA gebruikt

Controleer vóór het starten van de workers of de GPU- en EFA-resources op elke GPU-node beschikbaar zijn. Bekijk daarna in de NCCL-uitvoer welk transport is gekozen. In de beschreven netwerkroute loopt verkeer van NCCL via de AWS OFI NCCL-plugin en libfabric naar EFA.

Ontbreekt de EFA-resourceaanvraag of is EFA niet beschikbaar voor de pod, dan kan NCCL terugvallen op sockets en TCP. De job kan dan nog draaien zonder het bedoelde EFA-transport. De controles van het voorbeeld laten zien of EFA in de gekozen NCCL-route zit.

Wat de run laat zien

De code genereert willekeurige token-ID’s; het voorbeeld traint dus niet op een echte dataset. AWS noemt het vervangen van die input door een Ray Data- of DataLoader-pijplijn als stap naar een training met echte data.

AWS meldt dat de EFA-route in het voorbeeld met ongewijzigde code tweemaal de throughput van TCP haalde. De tutorial geeft daarvoor geen numerieke benchmarkwaarden of testcondities, dus die verhouding beschrijft AWS’ sample en geen algemene prestatiegarantie.