25 września 2026 r. AWS opublikowało artykuł Accelerate multimodal RL training with SkyRL on Amazon SageMaker HyperPod. Przewodnik dotyczy konkretnego dalszego treningu modelu obrazu i języka Qwen3-VL-8B do nawigacji w wizualnym labiryncie. Punktem wyjścia jest punkt kontrolny po nadzorowanym dostrajaniu VisGym, a kolejną fazę prowadzi się z użyciem SkyRL i GRPO. Poniższe ustawienia i wyniki są tymi, które AWS podało dla swojego eksperymentu.

Środowisko treningowe

Opisany klaster Ray ma trzy węzły robocze z GPU i jeden węzeł główny z CPU. AWS użyło trzech instancji roboczych ml.g7e.12xlarge, co daje łącznie sześć GPU, oraz instancji głównej ml.r5d.16xlarge z 512 GB pamięci RAM. Te liczby określają skalę środowiska w przewodniku. Nie pokazują same przez się, jakie wyniki dałaby inna wielkość klastra.

Klaster jest tworzony z poziomu SageMaker Studio. Zasób Amazon FSx for Lustre zamontowany pod ścieżką /shared mieści punkty kontrolne, wagi LoRA i wyniki ewaluacji. AWS podaje też, że zaktualizowane wagi adaptera LoRA są synchronizowane przez FSx for Lustre. Wspólna lokalizacja służy więc kilku etapom tego samego przebiegu: przechowuje artefakty treningu i uczestniczy w przekazywaniu aktualizacji adaptera.

W opisanej konfiguracji sześć silników vLLM tworzących przebiegi dzieli GPU z modelem polityki podzielonym przy użyciu FSDP. To informacja o rozmieszczeniu pracy w tym eksperymencie, a nie osobny pomiar wydajności silników lub modelu polityki. Liczba silników, współdzielenie GPU i sposób synchronizacji wag należą do warunków, w których AWS uzyskało podany wynik.

Przebiegi i harmonogram pomiarów

Dla każdego polecenia dotyczącego labiryntu konfiguracja generuje osiem przebiegów. Pojedynczy epizod może mieć najwyżej 15 ruchów. Wartości te określają liczbę prób przypadających na zadanie oraz granicę epizodu w przewodniku. Na podstawie opisanego przypadku nie można stwierdzić, jak model zachowałby się przy innej liczbie przebiegów albo innym limicie ruchów.

Co 10 kroków odbywa się ewaluacja na wydzielonym zestawie 64 labiryntów. Co 20 kroków zapisywane są pełne punkty kontrolne treningu i eksporty LoRA gotowe do użycia podczas inferencji. To dwa odrębne rytmy tego samego procesu: jeden dotyczy pomiaru na wydzielonych zadaniach, drugi zapisu stanu treningu i adaptera. Podawane odsetki rozwiązań odnoszą się do wskazanego zestawu ewaluacyjnego.

Według AWS zadania są wysyłane przez zabezpieczony punkt końcowy Ray z użyciem schematu adresów sagemaker_ray:// i danych uwierzytelniających AWS. Dodatek HyperPod Observability dla EKS udostępnia w Amazon Managed Grafana cztery pulpity Ray: Ray Core, Ray Data, Ray Train i Ray Serve. Są to elementy sposobu uruchamiania i obserwowania pracy klastra, a nie dodatkowe miary skuteczności modelu w labiryncie.

Wynik opisany przez AWS

Artykuł podaje początkowy odsetek rozwiązań równy 43,75%, czyli 28 z 64 labiryntów. Najwyższy zgłoszony odsetek wynosi 96,875%, czyli 62 z 64, i przypada na krok 160. Liczby bezwzględne pokazują dokładnie, ilu zadań dotyczą procenty. Maksimum jest wynikiem podanym dla określonego kroku w tym eksperymencie.

AWS zaznacza, że wyniki mogą się różnić. Z przedstawionych danych nie wynika, czy taki sam odsetek udałoby się uzyskać przy innych hiperparametrach lub konfiguracjach labiryntów. Wynik 62 z 64 nie jest też punktem odniesienia dla innych modeli, zbiorów danych czy wdrożeń. Uzasadnione porównanie dotyczy wartości początkowej i maksimum wewnątrz przebiegu opisanego przez AWS.

Wykorzystanie adaptera

Przewodnik obejmuje także etap inferencji. Wytrenowany adapter LoRA jest umieszczany w Amazon S3, a Ray Serve zostaje skonfigurowany tak, aby dynamicznie ładować go obok modelu bazowego. Opis łączy w ten sposób zapis adaptera podczas treningu z jego późniejszym użyciem. Ustawienia klastra, harmonogram ewaluacji i liczby rozwiązanych labiryntów wyznaczają zakres tego przykładu; poza nim artykuł nie przedstawia potwierdzonych wyników.