Dans son tutoriel publié le 28 octobre 2026, AWS décrit un entraînement Ray Train sur Amazon EKS avec le conteneur Ray Train publié, sans création d’image personnalisée. L’exemple exécute Qwen2.5-1.5B avec PyTorch FSDP en bfloat16 sur huit GPU NVIDIA L4 répartis entre deux instances g6.12xlarge. Pour que le trafic EFA relie les workers, ceux-ci doivent se trouver dans la même zone de disponibilité et le même VPC.

Ce que déploie l’exemple AWS

Un nœud système m7i.xlarge héberge l’opérateur KubeRay et le Ray head, qui n’utilise pas de GPU. Deux instances g6.12xlarge fournissent les ressources de calcul. Chaque instance accueille un pod worker doté de quatre GPU et d’une interface EFA.

ComposantConfiguration de l’exempleRôle
Nœud systèmeUn m7i.xlarge, sans GPU pour le Ray headHéberge le Ray head et l’opérateur KubeRay
Workers GPUDeux g6.12xlarge, quatre NVIDIA L4 et une interface EFA par instanceExécutent les huit workers Ray Train

AWS utilise le même conteneur publié pour le Ray head et les workers : public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1. Le tutoriel indique Ray 2.58.0, PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2 et NCCL 2.29.7.

Le tag v1.1 peut évoluer lors de reconstructions de sécurité. AWS indique que les tags complets vX.Y.Z restent associés à la version initiale du build; un digest permet de retrouver des exécutions identiques octet par octet.

Prérequis et placement d’EFA

Pour les deux g6.12xlarge, AWS demande 96 vCPU de capacité G-family à la demande, ou une réservation de capacité à la demande déjà disponible. AWS classe g6.12xlarge parmi les instances compatibles avec EFA, mais la disponibilité des types compatibles varie selon la région. Vérifiez la région visée avant de créer le cluster.

Le trafic EFA ne traverse ni les zones de disponibilité ni les VPC. Le trafic IP ordinaire de l’ENA suit un chemin distinct et reste routable.

Placer les workers pour que l’EFA fonctionne

[IMAGE GENERATED: 388f517b06e900963c6b04ced03e16d2592c1a331d800036e1eabf5f86d74d78]

Configurer Ray Train et EFA

Schéma conceptuel d’un VPC traversant plusieurs zones de disponibilité, avec une liaison EFA entre deux workers dans la même zone et des chemins interzones ou inter-VPC barrés.

Dans scripts/env.sh, renseignez les variables de cluster, de région, de nœuds, d’image et d’entraînement. Les pods workers de l’exemple demandent chacun quatre GPU, une ressource EFA, 40 unités CPU et 160Gi de mémoire; leurs demandes et limites sont identiques. AWS relie aussi le nombre de GPU annoncé à Ray au nombre demandé dans Kubernetes.

Le manifeste demande une ressource EFA avec vpc.amazonaws.com/efa: 1. Le conteneur configure les variables suivantes pour le transport :

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

Les nœuds GPU portent le label nvidia.com/gpu.present=true. AWS utilise des sous-réseaux privés dans un VPC et une passerelle NAT pour télécharger le conteneur et les poids du modèle depuis Hugging Face. Le travail est soumis depuis le pod Ray head; le tutoriel n’expose pas le port 8265 à l’extérieur du cluster.

Déployer le cluster et envoyer le travail

Suivez ces étapes dans l’ordre afin que les ressources Kubernetes et les dépendances Ray soient prêtes avant le lancement de l’entraînement.

  1. Configurez scripts/env.sh. Renseignez le cluster, la région, les nœuds, l’image et les paramètres d’entraînement pour que les scripts utilisent la configuration souhaitée.
  2. Prévisualisez les actions d’infrastructure. Utilisez l’option --plan de deploy_all.sh pour examiner le plan avant de provisionner les ressources.
  3. Sondez la capacité et créez l’infrastructure. Exécutez deploy_all.sh pour vérifier la capacité, créer le cluster EKS et établir le groupe de nœuds.
  4. Installez ou vérifiez les modules GPU et EFA. Le plug-in GPU et le plug-in EFA doivent rendre leurs ressources accessibles à Kubernetes.
  5. Installez KubeRay. L’opérateur doit être en place avant la création du RayCluster.
  6. Générez et appliquez le manifeste Ray. Exécutez deploy_ray_train_job.sh pour préparer et appliquer la configuration des workers.
  7. Vérifiez les ressources allouables. Contrôlez que chaque nœud GPU annonce les ressources GPU et EFA attendues avant d’attendre que les pods démarrent.
  8. Soumettez le job depuis le Ray head. L’exemple utilise kubectl exec pour lancer le travail depuis le pod head. L’option --train permet d’enchaîner l’entraînement après la configuration de l’infrastructure.

Vérifier les ressources et le transport NCCL

Contrôlez que le label GPU est présent, que les nœuds annoncent des ressources GPU et EFA et que chaque pod demande les quatre GPU et l’interface EFA prévus. Des demandes et limites identiques donnent aux pods la classe de qualité de service Kubernetes Guaranteed utilisée par l’exemple.

NCCL peut retomber sur les sockets TCP si le pod ne demande pas la ressource EFA ou si le chemin EFA n’est pas accessible. Le script AWS vérifie le transport choisi par NCCL et s’arrête en erreur si EFA n’est pas utilisé. Le chemin de communication visé passe par le plug-in AWS OFI NCCL, libfabric et EFA.

Ce que l’exécution permet de conclure

Le code génère des identifiants de tokens aléatoires. AWS conseille de les remplacer par un pipeline Ray Data ou DataLoader pour entraîner le modèle sur un jeu de données réel.

AWS rapporte que, dans son exemple et avec le même code, le débit via EFA était deux fois supérieur à celui obtenu via TCP. Ce résultat concerne le scénario présenté par AWS; il ne constitue pas une garantie générale de gain de performance.