Per distribuire su Amazon EKS l’esempio AWS di training distribuito con Ray Train, usa il container Ray pubblicato e configura due istanze g6.12xlarge con otto GPU NVIDIA L4. I worker che comunicano tramite Elastic Fabric Adapter (EFA) devono trovarsi nella stessa zona di disponibilità (Availability Zone) e nella stessa VPC. Il job d’esempio addestra Qwen2.5-1.5B con PyTorch FSDP e bfloat16, ma usa ID di token casuali anziché un dataset reale.

L’architettura del cluster

Il campione separa il nodo di coordinamento dai due nodi GPU. Un’istanza m7i.xlarge ospita il Ray head senza GPU e l’operatore KubeRay; ciascuna istanza worker g6.12xlarge contiene quattro NVIDIA L4 e un’interfaccia EFA. Ray Train avvia un worker per GPU, per un totale di otto.

ComponenteConfigurazione dell’esempioRuolo
Nodo di sistemaUn’istanza m7i.xlargeOspita l’operatore KubeRay e il Ray head, che non usa GPU.
Nodi workerDue istanze g6.12xlarge, ciascuna con quattro GPU NVIDIA L4 e un’interfaccia EFAEseguono gli otto worker Ray Train, uno per GPU.

AWS usa lo stesso Ray Train Deep Learning Container (DLC) pubblicato per il Ray head e i worker, senza creare un’immagine personalizzata. Il tag dell’esempio è public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1. La versione del container elenca Ray 2.58.0, PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2 e NCCL 2.29.7.

Il tag v1.1 è un tag di versione minore: AWS specifica che i tag vX.Y possono cambiare con le ricostruzioni di sicurezza. Per mantenere la stessa build originale, AWS indica il tag completo vX.Y.Z; per esecuzioni identiche a livello di byte, indica il digest dell’immagine.

Prerequisiti e posizionamento di EFA

Per le due istanze g6.12xlarge, il tutorial richiede 96 vCPU G-family On-Demand oppure una On-Demand Capacity Reservation già disponibile. AWS elenca g6.12xlarge tra i tipi di istanza compatibili con EFA, ma la disponibilità varia in base alla Regione: controllala nella Regione scelta prima di creare il cluster.

Il traffico EFA non attraversa i confini di una Availability Zone né quelli di una VPC. I worker devono quindi condividere entrambe. Il normale traffico IP dell’interfaccia ENA è distinto e può essere instradato attraverso quei confini.

Le istanze del campione si trovano in subnet private della stessa VPC; un NAT Gateway consente di scaricare il container e i pesi del modello. La stima di AWS per i quattro passaggi di configurazione in una Regione nuova è di 20-30 minuti.

Configurare Ray Train e i worker

Nel file scripts/env.sh imposta le variabili del cluster, della Regione, dei nodi, dell’immagine e del training. Nel manifest, ogni pod worker richiede e limita quattro GPU, un dispositivo EFA, 40 CPU e 160Gi di memoria. Il valore num-gpus di Ray deve corrispondere alle GPU richieste a Kubernetes.

La configurazione del pod deve richiedere la risorsa EFA, esposta come vpc.amazonaws.com/efa: 1. Il campione imposta inoltre queste variabili d’ambiente:

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

Il percorso di comunicazione è NCCL, plugin AWS OFI NCCL, libfabric ed EFA. Se la richiesta della risorsa EFA manca o EFA non è disponibile al pod, NCCL può passare ai socket TCP.

Creare il cluster e inviare il job

Due worker GPU collegati tramite EFA nella stessa VPC e Availability Zone; i percorsi tra zone o VPC diverse sono barrati.

Segui l’ordine delle dipendenze: prima la capacità e l’infrastruttura, poi i plugin e KubeRay, infine il cluster Ray e il job.

  1. Configura scripts/env.sh. Inserisci le variabili di cluster, Regione, nodi, immagine e training: gli script successivi le usano per creare l’infrastruttura e avviare il workload.
  2. Esegui deploy_all.sh. Lo script controlla la capacità e crea il cluster EKS e il node group. L’opzione --plan mostra in anteprima le azioni sull’infrastruttura; --train collega il training alla configurazione dell’infrastruttura.
  3. Installa o verifica i plugin GPU ed EFA. I plugin rendono disponibili a Kubernetes le risorse dei dispositivi. Controlla anche che i nodi GPU abbiano l’etichetta nvidia.com/gpu.present=true.
  4. Installa KubeRay. L’operatore gestisce la risorsa RayCluster su Kubernetes e precede la creazione del cluster Ray.
  5. Avvia deploy_ray_train_job.sh per renderizzare e applicare il manifest. Il manifest definisce il RayCluster e i pod worker con le rispettive risorse.
  6. Controlla le risorse allocabili sui nodi GPU. Verifica che ciascun nodo esponga le GPU e l’EFA prima di attendere l’avvio dei pod; il campione usa richieste e limiti uguali per ottenere la classe QoS Guaranteed di Kubernetes.
  7. Invia il job dal pod Ray head. Il campione usa kubectl exec per avviare il job dall’interno del pod. Non espone all’esterno la porta 8265 del job server.

Verificare che NCCL usi EFA

Controllare la disponibilità della risorsa nel cluster non basta: verifica anche il trasporto scelto da NCCL. Lo script d’esempio ispeziona il percorso e termina con un errore se EFA non viene usato. Se compare il fallback ai socket, ricontrolla la richiesta EFA del pod e che il dispositivo sia allocabile sul nodo.

Che cosa dimostra il training d’esempio

Il codice genera ID di token casuali. AWS descrive la sostituzione con una pipeline Ray Data o DataLoader come passaggio necessario per un fine-tuning con dati reali; l’esempio, quindi, non usa un corpus di training.

AWS riferisce che il percorso EFA ha raddoppiato il throughput rispetto a TCP con lo stesso codice del campione. La guida non fornisce valori numerici né condizioni di benchmark: il risultato riguarda quella configurazione e non stabilisce un guadagno generale per altri carichi.