Przykład AWS uruchamia Qwen2.5-1.5B z PyTorch FSDP na Amazon EKS, używając opublikowanego kontenera Ray Train, dwóch instancji g6.12xlarge i ośmiu procesorów NVIDIA L4. Żeby workery korzystały z EFA, muszą działać w tej samej strefie dostępności i tej samej VPC. Poniżej znajdziesz kolejność konfiguracji, wdrożenia i kontroli transportu.

Co uruchamia przykład AWS

AWS opisuje klaster z jednym węzłem systemowym m7i.xlarge oraz dwoma węzłami GPU g6.12xlarge. Węzeł systemowy obsługuje operator KubeRay i bezprocesorowy Ray head, który koordynuje pracę klastra. Każdy węzeł GPU uruchamia pod workera z czterema kartami NVIDIA L4; łącznie Ray Train tworzy ośmiu workerów.

KomponentKonfiguracja przykładuRola
Węzeł systemowyJedna instancja m7i.xlargeOperator KubeRay i Ray head bez GPU
Workery GPUDwie instancje g6.12xlarge, po cztery NVIDIA L4 i jednym interfejsie EFAOsiem workerów Ray Train, po cztery na instancję

Przykład używa PyTorch FSDP (Fully Sharded Data Parallel), czyli rozproszonego trenowania z podziałem parametrów modelu, oraz formatu bfloat16. AWS korzysta z opublikowanego obrazu public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1 bez budowania własnego kontenera. Wymieniony w tutorialu stos obejmuje Ray 2.58.0, PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2 i NCCL 2.29.7.

Wymagania i rozmieszczenie workerów EFA

AWS podaje wymóg 96 vCPU w instancjach G-family On-Demand dla dwóch węzłów g6.12xlarge albo istniejącej rezerwacji On-Demand Capacity Reservation. Dokumentacja AWS wymienia g6.12xlarge jako typ obsługujący EFA, ale dostępność obsługiwanych instancji zależy od regionu. Przed tworzeniem klastra sprawdź więc dostępność tego typu w wybranym regionie.

Ruch EFA nie przechodzi między strefami dostępności ani między VPC. Umieść oba workery w tej samej strefie i VPC. Zwykły ruch IP obsługiwany przez ENA to osobna ścieżka i pozostaje routowalny.

[DIAGRAM:388f517b06e900963c6b04ced03e16d2592c1a331d800036e1eabf5f86d74d78]

Przykład korzysta z prywatnych podsieci w jednej VPC i bramy NAT do pobierania obrazu oraz wag modelu. Węzeł GPU g6.12xlarge ma cztery procesory NVIDIA L4, 48 vCPU, 192 GiB pamięci, sieć 40 Gbit/s i jeden interfejs EFA.

Konfiguracja Ray Train i EFA

W scripts/env.sh ustaw parametry klastra, region, węzły, obraz i trening. Konfiguracja workerów musi przydzielać każdemu podowi cztery GPU i jedno urządzenie EFA. W przykładzie żądania zasobów Kubernetes są równe limitom: po 40 CPU i 160Gi pamięci na pod. Liczba GPU przekazywana do Ray (num-gpus) pochodzi z tej samej zmiennej co żądanie GPU Kubernetes.

Ustawienia środowiska dla ścieżki EFA w przykładzie to:

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

Pod musi też żądać zasobu vpc.amazonaws.com/efa: 1. To pozwala wtyczce urządzeń udostępnić interfejs EFA podowi. Jeśli tego żądania zabraknie, NCCL może przejść na sockety TCP. Węzły GPU powinny mieć etykietę nvidia.com/gpu.present=true; równe żądania i limity zasobów zapewniają podom klasę jakości Guaranteed w Kubernetes.

Znacznik obrazu v1.1 jest wersją vX.Y, która może zmieniać się wraz z przebudowami bezpieczeństwa. Pełny znacznik vX.Y.Z pozostaje przypisany do pierwotnej kompilacji wydania, a skrót obrazu pozwala wskazać identyczne bajtowo artefakty.

Kolejność wdrożenia klastra i zadania

Schemat regionu z kilkoma strefami dostępności i VPC; dwa workery GPU łączy EFA w obrębie tej samej strefy i VPC.
  1. Skonfiguruj scripts/env.sh. Wpisz ustawienia klastra, regionu, węzłów, obrazu i treningu, aby skrypty wdrożeniowe używały właściwych parametrów.
  2. Uruchom deploy_all.sh. Skrypt sprawdza pojemność i tworzy klaster EKS oraz grupę węzłów. Opcja --plan pozwala wcześniej wyświetlić plan działań infrastrukturalnych.
  3. Zainstaluj lub sprawdź wtyczki GPU i EFA. Zanim uruchomisz workery, upewnij się, że Kubernetes może udostępnić im oba rodzaje zasobów.
  4. Zainstaluj KubeRay. Operator zarządza zasobem RayCluster w Kubernetes.
  5. Uruchom deploy_ray_train_job.sh, aby wygenerować i zastosować manifest. Manifest opisuje RayCluster i konfigurację podów workerów.
  6. Sprawdź zasoby dostępne na węzłach GPU. Zweryfikuj, że każdy węzeł udostępnia GPU i EFA przed oczekiwaniem na gotowość podów.
  7. Uruchom klaster Ray i wyślij zadanie z poda Ray head. Tutorial korzysta z kubectl exec; port 8265 nie jest wystawiany poza klaster. Opcja --train łączy konfigurację infrastruktury z uruchomieniem treningu.

Jak sprawdzić, czy NCCL używa EFA

Sprawdź dostępność zasobów GPU i EFA na węzłach oraz wybrany przez NCCL transport. W ścieżce EFA komunikacja przebiega przez NCCL, wtyczkę AWS OFI NCCL, libfabric i EFA. Skrypt przykładu zgłasza błąd, jeśli EFA nie znalazło się na tej ścieżce.

Log NCCL_DEBUG=INFO pomaga sprawdzić wybrany transport. Jeśli konfiguracja EFA lub dostęp do urządzenia nie działa, zadanie może nadal korzystać z socketów TCP. Sam fakt, że pod wystartował, nie wystarcza więc do stwierdzenia, że komunikacja między węzłami odbywa się przez EFA.

Dane treningowe i wynik opisany przez AWS

Kod przykładu generuje losowe identyfikatory tokenów, a nie dane z rzeczywistego korpusu. AWS wskazuje, że trening na własnych danych wymaga zastąpienia tego wejścia potokiem Ray Data albo DataLoader.

AWS podaje, że w opisanym przykładzie ścieżka EFA zapewniła dwukrotnie większą przepustowość niż TCP przy niezmienionym kodzie. To wynik przypisany temu uruchomieniu, nie ogólna obietnica wydajności EFA.