Żeby rozpocząć wdrożenie NVIDIA Nemotron 3.5 Super VL na standardowym Amazon EKS, potrzebujesz dostępu do instancji P5en.48xlarge albo P6-b200.48xlarge, lokalnie zainstalowanych Git i Docker oraz poświadczeń AWS z uprawnieniami do EC2, EKS i FSx for Lustre. Przykład AWS opisuje też początkową konfigurację klastra, a osobno przedstawia wdrożenie w EKS Auto Mode i SageMaker HyperPod EKS.
AWS opublikowała swój przegląd architektury i pomiarów 29 października 2026 r. Model ma 120 mld parametrów łącznie i aktywuje 12 mld na token. Przyjmuje tekst, obrazy, dokumenty i wideo, a generuje tekst. Raport techniczny NVIDIA opisuje jego skalę; praktyczny start zależy jednak przede wszystkim od dostępu do wymaganych zasobów AWS.
Co przygotować przed uruchomieniem przykładu AWS
Przykład AWS wymaga konta z dostępem do instancji P5en.48xlarge lub P6-b200.48xlarge. W zależności od konta może być potrzebne zwiększenie limitu usługi albo rezerwacja pojemności. Na komputerze, z którego przygotujesz klaster, potrzebujesz Git i Docker. Poświadczenia AWS muszą pozwalać zarządzać EC2, EKS i FSx for Lustre.
To wymagania ścieżki opisanej w przykładzie AWS dla Nemotron. Sprawdź dostęp do instancji i uprawnienia przed rozpoczęciem konfiguracji klastra.
Pierwsze kroki ze standardowym EKS
Przykład prowadzi najpierw przez przygotowanie klastra standardowego EKS. Ta początkowa sekwencja kończy się sprawdzeniem węzłów; kolejne etapy obejmują sterowniki i operatory Kubernetes, walidację, pobranie wag modelu, wdrożenie, testy oraz usunięcie utworzonych zasobów.
- Sklonuj repozytorium
aws-do-eksi przejdź do jego katalogu. Stąd uruchomisz skrypty pomocnicze używane w dalszych krokach. - Ustaw region skryptem
./config.sh. Dzięki temu dalsza konfiguracja klastra będzie korzystać z wybranego regionu AWS. - Zbuduj lokalny obraz kontenera pomocniczego przez
./build.sh, a następnie uruchom go poleceniem./run.sh. Sprawdź jego stan za pomocą./status.shi otwórz powłokę kontenera przez./exec.sh. - W kontenerze skonfiguruj poświadczenia poleceniem
aws configure. Wybierz manifest klastra przez./env-config.sh, a jego ustawienia zmień w./eks-config.sh. - Utwórz klaster skryptem
./eks-create.sh. AWS podaje, że ten etap może potrwać do 30 minut. - Sprawdź węzły poleceniem
kubectl get nodes. To pozwala zobaczyć węzły utworzonego klastra przed przejściem do dalszych etapów przykładu.
AWS wymienia także EKS Auto Mode i SageMaker HyperPod EKS. W przypadku EKS Auto Mode AWS zarządza skalowaniem oraz obsługą GPU i EFA. Zgodnie z opisem AWS te same manifesty Kubernetes służą we wszystkich trzech wariantach orkiestracji. Przykład obejmuje również wybór EBS z FSx albo samego FSx, precyzji BF16 lub NVFP4 oraz zagregowanego lub rozdzielonego sposobu serwowania.
Minimalna liczba GPU dla vLLM
AWS podaje poniższe minima GPU dla uruchamiania modelu przez vLLM, zależnie od akceleratora i precyzji checkpointu:
| Model GPU | BF16, minimum GPU | NVFP4, minimum GPU |
| B200/GB200 | 8 | 2 |
| B300/GB300 | 4 | 1 |
| H200 | 8 | 4 |
| H100 | 16 | 8 |
Liczby te określają minima dla modelu w vLLM. Nie opisują kompletnego klastra: jego konfiguracja obejmuje też węzły CPU i GPU, magazyn wag oraz sieć. W architekturze przedstawionej przez AWS obrazy kontenerów trafiają do ECR, wagi są przechowywane we współdzielonym FSx for Lustre, a węzły GPU komunikują się przez EFA.
Jak czytać porównanie opóźnień AWS
AWS raportuje, że w opisanym teście wdrożenie rozdzielone osiągnęło niższy czas do pierwszego tokenu (TTFT), a opóźnienie między kolejnymi tokenami (ITL) było zbliżone do wyniku wdrożenia zagregowanego. Wykres opisuje Nemotron 3.5 Super VL 120B-A12B w BF16 na H200, z wejściem o długości 1 024 tokenów i wyjściem o długości 512 tokenów. Test obejmował poziomy współbieżności od 1 do 128 i jedno uruchomienie dla każdej komórki wykresu.
Konfiguracje różniły się liczbą akceleratorów: zagregowana korzystała z 8 GPU, a rozdzielona z 16. Raportowany wynik dotyczy więc tych dwóch konfiguracji. Przy ocenie własnego klastra warto zestawić oba sposoby serwowania przy takiej samej liczbie GPU i tym samym obciążeniu.
Jak mierzyć wydajność własnego obciążenia
AWS opisuje dwa etapy pomiaru. Najpierw test all-reduce z biblioteki NCCL służy do sprawdzenia działania klastra i sieci. Aktywność widoczna na GPU i adapterach EFA podczas testu wskazuje, że infrastruktura działa zgodnie z oczekiwaniami opisanymi przez AWS.
Do pomiaru samego serwowania AWS wskazuje NVIDIA aiperf. Narzędzie mierzy TTFT, ITL i przepustowość przy różnych poziomach współbieżności. AWS wiąże wzrost ITL z potrzebą sprawdzenia pojemności dekodowania, a wzrost TTFT z pojemnością fazy prefill, która przetwarza prompt przed generowaniem odpowiedzi. Dzięki temu pomiar pozwala ocenić zachowanie konkretnego obciążenia, zamiast opierać decyzję o konfiguracji na samym wyniku testu AWS.
