Ray Train DLCs Eliminują Konieczność Budowania Obrazu w Rozproszonym Treningu na EKS

AWS opublikował 28 października przykład treningu na ośmiu GPU, który wykorzystuje Ray Train DLCs bez budowania własnego obrazu kontenera. Deep Learning Container, czyli spakowane środowisko programowe, dostarcza framework treningowy i biblioteki sieciowe. Pozostała praca dotyczy konfiguracji klastra i walidacji obciążenia.

Przykład uruchamia Qwen2.5-1.5B, model językowy, na dwóch instancjach g6.12xlarge w Amazon EKS, zarządzanej przez AWS usłudze Kubernetes. Kubernetes koordynuje aplikacje kontenerowe na wielu maszynach. AWS wykorzystuje PyTorch FSDP, metodę treningową rozdzielającą stan modelu między GPU, aby sprawdzić komunikację między instancjami.

Dzięki temu porównanie jest konkretne: środowisko treningowe utrzymywane przez AWS kontra zespół samodzielnie utrzymujący ten sam stos oprogramowania. Przykład używa jednak losowych partii tokenów, czyli losowo generowanych danych wejściowych modelu. Waliduje infrastrukturę, a nie użyteczną adaptację modelu. Zespoły otrzymują punkt wyjścia do rozproszonego wykonywania zadań, podczas gdy przygotowanie zbioru danych, ewaluacja i odtwarzanie produkcyjne pozostają odrębnymi decyzjami.

Co Ray Train DLCs zmieniają dla zespołów EKS

Natychmiastową zmianą jest dostępność udokumentowanej ścieżki od opublikowanego obrazu do zadania rozproszonego treningu. Przykład rozproszonego treningu AWS łączy pakowanie kontenera z konkretnym układem klastra. Przykład oferuje coś węższego i bardziej praktycznego niż ogólna obietnica łatwiejszego treningu.

Istotna zmiana dotyczy tego, kto utrzymuje wspólne środowisko treningowe.

Własny obraz sprawia, że zespół aplikacyjny odpowiada za złożenie jego zależności. Odpowiedzialność ta wykracza poza instalację frameworka Python. Wykonywanie na GPU i komunikacja zależą od komponentów, które muszą współpracować, w tym bibliotek poza skryptem treningowym.

Opublikowany obraz przekazuje odpowiedzialność za to składanie innemu podmiotowi. Zespoły aplikacyjne nadal decydują, czy wynikowe środowisko spełnia ich wymagania. Mogą jednak ocenić istniejący artefakt, zanim zdecydują się samodzielnie utrzymywać jego odpowiednik.

To rozróżnienie ma największe znaczenie, gdy zespół już wie, co chce trenować. Czas poświęcony na rozwiązywanie problemów kompatybilności środowiska nie poprawia bezpośrednio zbioru danych ani procesu ewaluacji. Usunięcie tej pracy z pierwszego eksperymentu daje przestrzeń do wcześniejszego zbadania obciążenia.

Ogłoszenie wymaga też precyzyjnej osi czasu. Dziennik zmian kontenera Ray Train AWS datuje pierwsze wydanie obrazu na 26 sierpnia 2026 roku, a wersję 1.1 na 1 września. Październikowa publikacja jest instrukcją wdrożenia wykorzystującą tę rodzinę kontenerów, a nie jej premierą.

Ta chronologia zmienia wartość informacyjną wiadomości. AWS dokumentuje, jak wcześniej udostępnione pakowanie wpisuje się w odtwarzalną konfigurację rozproszoną. Nacisk należy położyć na połączenie dostarczania oprogramowania z działaniem klastra, bez sugerowania nowo wynalezionego algorytmu treningowego.

Dla menedżerów inżynieryjnych decyzję łatwiej jest teraz ująć w ramy. Mogą zapytać, czy utrzymywanie osobnego obrazu treningowego zapewnia możliwości, których brakuje w opublikowanym środowisku. To bardziej konkretne niż założenie, że każdy projekt rozproszonego treningu potrzebuje własnej kompilacji kontenera.

Dla inżynierów platformowych przykład tworzy konfigurację referencyjną do porównania z lokalnymi wymaganiami. Różnice stają się wyraźnymi punktami przeglądu. Zespół może wskazać, które zmiany wynikają z jego obciążenia, a które odzwierciedlają istniejące konwencje infrastrukturalne.

Opublikowana ścieżka ułatwia też uzasadnianie wyjątków. Jeśli organizacja potrzebuje innej kompilacji frameworka lub wyspecjalizowanego rozszerzenia, taki wymóg może uzasadniać dodatkowe utrzymanie. Własny obraz wynika wtedy z udokumentowanej potrzeby, zamiast stawać się domyślnym punktem wyjścia.

Nie oznacza to uniwersalnej przydatności. Oznacza praktyczną alternatywę, którą zespoły mogą sprawdzić. Najtrafniejsza interpretacja jest taka, że AWS ograniczył zakres składania środowiska potrzebny do rozpoczęcia oceny tej konkretnej konfiguracji rozproszonego treningu.

Presja przenosi się na utrzymanie własnych obrazów

Stos kontenerów treningowych AWS obejmuje Ray, framework wykonywania rozproszonego, obok PyTorch, frameworka uczenia maszynowego. Zawiera również CUDA, platformę obliczeniową GPU NVIDIA, oraz NCCL, bibliotekę NVIDIA do komunikacji między GPU.

Komponenty sieciowe obejmują Elastic Fabric Adapter, interfejs sieciowy AWS dla silnie sprzężonych obciążeń, oraz wtyczkę AWS OFI NCCL. Wtyczka ta łączy NCCL z dostawcą sieci. AWS podaje, że przed publikacją wydań testuje połączone środowisko.

Zespół wybierający własny obraz potrzebuje teraz powodu, aby przejąć tę samą pracę integracyjną.

Nie czyni to własnych środowisk przestarzałymi. Organizacje mogą mieć wymagania dotyczące zatwierdzonych zależności, wyspecjalizowanych kompilacji lub wewnętrznej dystrybucji. Te potrzeby pozostają uzasadnione. Presja dotyczy rutynowego powielania pracy związanej z pakowaniem, którą istniejący artefakt już realizuje.

Rozważmy hipotetyczną grupę inżynieryjną badającą, czy jej zadanie treningowe może działać na wielu maszynach. Jej początkowe pytanie dotyczy zachowania rozproszonego. Budowanie osobnego obrazu wprowadza kolejne zagadnienie do zbadania, zanim grupa dotrze do tego pytania.

Utrzymywana baza może skrócić tę sekwencję. Grupa najpierw ocenia środowisko referencyjne, a następnie dokumentuje rzeczywiste niezgodności. Decyzja o dostosowaniu opiera się na dowodach zebranych podczas pracy z obciążeniem, a nie na założeniach przyjętych przed wykonaniem.

To porównanie operacyjne, a nie twierdzenie, że jeden kontener zawsze działa lepiej. Starannie utrzymywany wewnętrzny obraz może spełniać te same wymagania techniczne. Różnica dotyczy własności, procedur aktualizacji i nakładu pracy niezbędnego do utrzymania użyteczności środowiska.

Opublikowany obraz zmienia też sposób, w jaki zespoły powinny opisywać własną pracę platformową. Pakowanie mniejszej ilości oprogramowania nie oznacza mniejszego wkładu. Inżynierowie platformowi mogą poświęcić uwagę kontroli dostępu, rozmieszczeniu zasobów, obserwowalności i wymaganiom obciążeń treningowych organizacji.

Te obowiązki łatwiej rozdzielić, gdy punkt wyjścia jest współdzielony. Jeśli wiele eksperymentów korzysta z tego samego środowiska, recenzenci mogą skupić się na różnicach w kodzie i konfiguracji. Osobny obraz dla każdego eksperymentu utrudnia uporządkowanie takiego porównania.

Korzyść nadal zależy od dyscypliny wdrożeniowej. Zespoły muszą dokumentować, którego artefaktu użyły i jakie dodatkowe zależności wprowadziły. W przeciwnym razie nominalnie wspólna baza może ukrywać różne środowiska wykonawcze między zadaniami.

Ray Train DLCs oferują zatem wybór dotyczący utrzymania, a nie zwolnienie z obowiązków utrzymaniowych. AWS odpowiada za opublikowane złożenie. Organizacja wdrażająca odpowiada za kryteria akceptacji, politykę wdrożeniową i decyzję o terminie aktualizacji.

Rozsądny wewnętrzny przegląd powinien zapytać, co umożliwia własne środowisko, kto je utrzymuje i jak sprawdzana jest kompatybilność. Pytania te nie zakładają, że opublikowany kontener wygrywa. Uwidaczniają kompromis w stopniu wystarczającym do jego oceny.

Szersza implikacja jest prosta: praca specyficzna dla aplikacji powinna uzasadniać pakowanie specyficzne dla aplikacji. Gdy obciążenie pasuje do utrzymywanego środowiska, posiadanie kolejnej kompilacji staje się wyborem z ciągłymi zobowiązaniami.

FSDP sprawia, że sieć staje się częścią projektu treningu

Stos sieciowy ma znaczenie, ponieważ shardowanie zmienia sposób współpracy GPU. W w pełni shardowanym treningu FSDP rozdziela parametry, gradienty i stany optymalizatora między workery. Parametry przechowują wyuczone wartości, gradienty kierują aktualizacjami, a stany optymalizatora śledzą proces aktualizacji.

Zanim shardowana jednostka wykona obliczenia, workery zbierają potrzebne jej parametry. Po obliczeniu wstecznym synchronizują i dzielą gradienty. Zmniejsza to powielony stan, jednocześnie wprowadzając komunikację, którą projekt treningu musi uwzględnić.

Oszczędność pamięci i wymagania komunikacyjne należą do tej samej decyzji inżynieryjnej.

Ten kompromis wyjaśnia, dlaczego dostarczenie kompatybilnych bibliotek sieciowych ma praktyczną wartość. Środowisko treningowe potrzebuje czegoś więcej niż działającego importu modelu. Musi również obsługiwać wymianę danych wymaganą przez wybraną strategię rozproszoną.

Istotne porównanie nie sprowadza się po prostu do większej lub mniejszej liczby GPU. Chodzi o to, czy obciążenie korzysta na rozdzieleniu stanu po uwzględnieniu komunikacji. Udane uruchomienie potwierdza, że wykonanie działa; pomiar wydajności potwierdza, czy takie rozwiązanie jest użyteczne.

PyTorch dokumentuje różne strategie shardowania, ponieważ równowaga ta się zmienia. Pełne shardowanie rozdziela więcej stanu, podczas gdy podejścia hybrydowe łączą shardowanie w obrębie maszyny z replikacją między maszynami. Istnienie tych możliwości przemawia przeciwko traktowaniu konfiguracji referencyjnej jako uniwersalnego optimum.

DeepSpeed, inny system rozproszonego treningu, stanowi ważny punkt odniesienia w branży. Jego podejście ZeRO również dzieli stan treningowy. PyTorch wyraźnie wskazuje ZeRO Stage 3 z DeepSpeed jako inspirację dla FSDP, umieszczając przykład AWS w ramach ugruntowanego kierunku technicznego.

Ten kontekst pozwala zachować właściwe proporcje nowości. Wkład AWS dotyczy tutaj spakowanego środowiska wykonawczego i ścieżki jego wdrożenia. Podstawowa idea ograniczania powielonego stanu treningowego wyprzedza tę instrukcję.

Dla zespołów porównujących podejścia użyteczne pytanie brzmi, która strategia odpowiada ich modelowi i ograniczeniom operacyjnym. Dostępność kontenera może zmniejszyć wysiłek potrzebny do zbadania danego podejścia. Nie rozstrzyga porównania między systemami rozproszonego treningu.

Opisy sprzętu również wymagają ostrożności. AWS podaje dla g6.12xlarge cztery GPU NVIDIA L4, 192 GiB pamięci hosta i sieć 40 Gbps. Te specyfikacje opisują instancję, a nie zmierzoną przepustowość treningu dla tego obciążenia.

Wartość przepustowości sieci nie może samodzielnie odpowiedzieć na pytanie, jak szybko zakończy się eksperyment. Trening obejmuje obliczenia i komunikację, a obciążenie określa relację między nimi. Czytelnicy powinni unikać przekształcania specyfikacji sprzętowej w twierdzenia o wydajności aplikacji.

Ta sama ostrożność dotyczy szacunków pamięci. Trwały stan modelu nie obejmuje każdej alokacji wykonywanej podczas treningu. Obliczenia pośrednie, tymczasowe bufory i ustawienia obciążenia również mają znaczenie przy ocenie, czy zadanie się zmieści.

Praktyczny wniosek jest taki, że shardowanie tworzy kompromis inżynieryjny. Zmniejsza pewne wymagania pamięciowe poprzez zwiększenie koordynacji. Spakowany stos sieciowy realizuje konieczną część tego kompromisu, nie rozstrzygając, czy będzie korzystny dla każdego obciążenia.

Dlatego ścieżka komunikacji zasługuje na wyraźną weryfikację. Kontener dostarcza komponenty, natomiast eksperyment musi ustalić, jak komponenty te zachowują się w rzeczywistym klastrze.

Kontener pozostaje stały, podczas gdy konfiguracja klastra się zmienia

Przewodnik wdrożenia KubeRay AWS pokazuje, jak obraz wpisuje się w Kubernetes. KubeRay jest operatorem, czyli kontrolerem zarządzającym zasobami Ray. Jego konfiguracja RayCluster opisuje koordynujący head i pody workerów, czyli jednostki Kubernetes uruchamiające kontenery.

Przewodnik oddziela procesy robocze GPU od węzła głównego. Wymaga także zgodności między wersją Ray w obrazie, deklarowaną przez Ray liczbą GPU a przydziałem zasobów Kubernetes. Są to obowiązki konfiguracyjne związane z obrazem.

Pominięcie budowania obrazu sprawia, że konfiguracja klastra staje się jawną częścią wdrożenia.

Ta granica jest użyteczna, ponieważ rozdziela kwestie, które w innym przypadku łatwo się ze sobą mieszają. Obraz określa dostarczone środowisko programowe. Konfiguracja klastra określa, gdzie to środowisko działa i jakie urządzenia otrzymują jego procesy.

Dostępność urządzeń ma szczególne znaczenie. Biblioteka wewnątrz kontenera nie może zastąpić dostępu do urządzenia, z którego spodziewa się korzystać. Przegląd wdrożenia musi zatem obejmować zarówno spakowane zależności, jak i zasoby przypisane procesom roboczym.

Program uruchamiający Ray Train dodaje kolejną warstwę koordynacji. Jego TorchTrainer uruchamia funkcję treningową w procesach roboczych. ScalingConfig opisuje liczbę procesów roboczych oraz wymagania dotyczące akceleratorów, pozostawiając te decyzje poza pętlą treningową pojedynczego procesu roboczego.

Taki podział daje zespołom bardziej przejrzysty sposób organizowania zmian. Eksperyment z modelem nie powinien automatycznie wymagać innej topologii klastra. Zmiana pojemności klastra nie powinna automatycznie wymagać przepisania logiki treningowej modelu.

W przypadku odtwarzalnej ewaluacji użytecznym artefaktem jest pełny zestaw decyzji dotyczących wykonania. Obejmuje on tożsamość obrazu, konfigurację klastra, kod zadania i ustawienia obciążenia. Zapisanie wyłącznie nazwy modelu pozostawia zbyt wiele niewyjaśnionych kwestii.

Słowo „odtwarzalny” również zasługuje na precyzyjnie ograniczone znaczenie. Powtórzenie danych wejściowych wdrożenia różni się od zagwarantowania identycznych wyników treningu. Zespoły powinny określić, czy odtwarzają infrastrukturę, zachowanie wykonania czy wynik jakości modelu.

Opublikowana konfiguracja może pomóc ustalić pierwszy z tych elementów. Dostarcza punkt odniesienia, względem którego można oceniać lokalne modyfikacje. Nie eliminuje jednak potrzeby wyjaśnienia, dlaczego zmodyfikowana konfiguracja zachowuje się inaczej.

Zmiany w obciążeniu powinny otrzymywać taką samą uwagę jak zmiany infrastruktury. Dodawanie zależności w momencie przesyłania zadania może zachować bazowy obraz, jednocześnie zmieniając środowisko zadania. Takie dodatki również powinny znaleźć się w zapisie eksperymentu.

To właśnie tutaj dokumentacja zespołowa staje się użyteczna operacyjnie. Inżynierowie potrzebują dostępu do konfiguracji, która doprowadziła do danej obserwacji, wraz z samą obserwacją. Zrzut ekranu ukończonego zadania nie wyjaśni każdej decyzji, która za nim stoi.

Przeszukiwalna baza wiedzy może pomóc zespołom zachowywać decyzje wdrożeniowe i notatki z analiz. Wspiera to przegląd i przekazywanie pracy, nie zastępując plików konfiguracyjnych ani dzienników.

Podejście ze stałym obrazem zmienia zatem sposób organizacji złożoności. Czyni pakowanie oprogramowania wspólną bazą i pozostawia różnice wdrożeniowe widoczne w konfiguracji. Zespoły nadal muszą przeanalizować te różnice, zanim uznają konfigurację referencyjną za własny standard.

Syntetyczne uruchomienie nie potwierdza użytecznego dostrojenia modelu

Losowe dane wejściowe w przykładzie są celowym uproszczeniem. Pozwalają przetestować ścieżkę wykonania bez włączania zbioru danych do początkowej konfiguracji. Jest to właściwe dla kontroli infrastruktury, pod warunkiem że czytelnicy rozumieją, co taki wynik potwierdza.

Ukończone zadanie rozproszone i użyteczny wytrenowany model wymagają różnych dowodów.

Pierwsza kwestia dotyczy wykonania: procesy robocze uruchamiają się, uczestniczą w pracy i kończą żądane obliczenia. Druga dotyczy uczenia: wynikowy model działa akceptowalnie w zdefiniowanym zadaniu. Żaden z tych wyników nie zapewnia automatycznie drugiego.

To rozróżnienie jest szczególnie ważne, ponieważ opis dotyczy fine-tuningu, czyli dodatkowego treningu istniejącego modelu. Przykład wykonuje operacje treningowe na tym modelu. Losowe dane wejściowe nie potwierdzają poprawy w rzeczywistym zadaniu.

Zespół dostosowujący przykład musi więc zdefiniować pytanie, na które jego dane mają odpowiedzieć. Obejmuje to decyzję, co po treningu oznacza akceptowalne zachowanie. Bez takiej definicji sukces infrastrukturalny może stać się mylącym wskaźnikiem postępu produktu.

Ewaluacja zmienia również interpretację straty, czyli wartości numerycznej celu używanego podczas treningu. Zgłoszona wartość straty opisuje skonfigurowane obliczenie. Sama w sobie nie potwierdza, że dostosowany model spełnia wymaganie wdrożeniowe.

Kolejna granica dotyczy zapisanego postępu. Wytyczne Ray dotyczące trwałego przechowywania wymagają współdzielonego miejsca docelowego dla punktów kontrolnych w treningu wielowęzłowym. Punkty kontrolne zachowują stan treningu, dzięki czemu zadanie może zostać wznowione lub jego wyniki mogą zostać wykorzystane później.

Ray rozróżnia obciążenia zapisujące punkty kontrolne od uruchomień, które jedynie raportują metryki. Metryki mogą być agregowane lokalnie, gdy nie są zapisywane punkty kontrolne. Syntetyczna kontrola wykonania może więc zakończyć się bez potwierdzenia zachowania pamięci masowej potrzebnego dla dłuższego obciążenia treningowego.

To rozróżnienie ma praktyczne konsekwencje. Zespół powinien zweryfikować, czy potrafi zapisać i ponownie wczytać wymagany stan, zanim zacznie polegać na tej konfiguracji w wartościowym treningu. Ponowne uruchomienie kontenerów nie jest równoznaczne z odzyskaniem postępu eksperymentu.

Kwestia odpowiedzialności powraca również tutaj. Opublikowany obraz może dostarczać zgodne biblioteki, ale zespół wdrażający nadal określa, gdzie trafiają artefakty i kto może uzyskać do nich dostęp. Wymagania te wynikają z obciążenia i organizacji.

Twierdzenia dotyczące wydajności także wymagają własnych dowodów. Źródłowy przewodnik przedstawia konfigurację i opisuje ścieżkę jej walidacji. Nie należy go odczytywać jako niezależnego porównania pokazującego, że ten układ jest najszybszą opcją dla Qwen.

Rzetelne porównanie utrzymywałoby spójne obciążenie i warunki pomiaru, analizując jednocześnie alternatywy. W przeciwnym razie różnice w przetwarzaniu danych wejściowych lub ustawieniach treningu mogą zaciemnić to, co porównanie infrastruktury faktycznie mierzy.

Nie ma też powodu wymyślać krytycznej reakcji, aby historia wyglądała na sporną. Udokumentowane ograniczenia techniczne zapewniają wystarczający poziom weryfikacji. Właściwe pytanie brzmi, czy dowody wspierają zamierzoną decyzję operacyjną.

W przypadku infrastrukturalnego proof of concept przykład obejmuje określoną ścieżkę wykonania. Przed wdrożeniem produkcyjnym zespoły potrzebują dodatkowych dowodów dotyczących swoich danych, artefaktów, odzyskiwania i wyników zadań. Rozdzielenie tych decyzji ułatwia wykorzystanie zarówno przykładu, jak i zrozumienie jego ograniczeń.

Obserwuj rzeczywiste obciążenia, dowody dotyczące transportu i aktualizacje obrazów

Kolejne przydatne ustalenia będą wynikać z konkretnych obserwacji inżynieryjnych. W nadchodzących miesiącach czytelnicy powinni szukać dowodów łączących opublikowane środowisko z wymaganiami rzeczywistej pracy treningowej. Największe znaczenie mają trzy sygnały, w określonej kolejności.

Najmocniejsze dalsze potwierdzenie pokaże, co pozostaje powtarzalne po zastąpieniu syntetycznych danych wejściowych.

Po pierwsze, warto obserwować raporty o rzeczywistych obciążeniach, obejmujące zarówno zachowanie treningu, jak i ocenę zadania. Raport powinien jasno identyfikować model, sposób przetwarzania danych i ustawienia, aby można było zinterpretować jego wynik. Samo ukończenie nie potwierdza jakości dostosowanego modelu.

Odzyskiwanie z punktów kontrolnych powinno towarzyszyć tym dowodom. Obciążenie, które pomyślnie wznawia pracę z zapisanego stanu, odpowiada na pytanie operacyjne pozostawione otwarte przez syntetyczne uruchomienie. Wzmocniłoby to argument za przyjęciem środowiska poza początkowym testem łączności.

Rozczarowujący wynik zadania nie unieważnia automatycznie kontenera. Na rezultaty wpływają również dane i wybory treningowe. Użyteczny raport oddziela błędy wykonania od błędów modelowania, jasno wskazując, która część systemu wymaga uwagi.

Po drugie, warto szukać dowodów dotyczących transportu zestawionych z kontrolowanymi pomiarami wydajności. Dowody dotyczące transportu to obserwacje pokazujące, z której ścieżki komunikacyjnej procesy robocze rzeczywiście korzystały. Takie obserwacje powinny towarzyszyć wynikom przepustowości, zamiast być wyciągane z samej obecności instancji obsługującej EFA.

Porównanie powinno również rozróżniać łączność od efektywności. Ustalenie, że zamierzona ścieżka działa, jest konieczne do interpretacji wyniku. Nie potwierdza jednak, że obciążenie skutecznie wykorzystuje dostępny sprzęt.

Raporty ujawniające te warunki wzmocniłyby argument dotyczący pakowania. Pokazałyby, że zespoły mogą analizować zachowanie dostarczonego stosu we własnym środowisku. Niewyjaśnione różnice wskazywałyby natomiast obszary wymagające dalszej diagnostyki lub jaśniejszych wskazówek.

Po trzecie, warto obserwować, jak aktualizacje obrazu wpisują się w powtarzalne eksperymenty. Dziennik zmian AWS już rozdziela wydania i dołączone do nich komponenty. Zespoły przyjmujące kontener powinny ocenić, w jaki sposób ich własny proces aktualizacji zachowuje tożsamość wcześniejszych środowisk wykonawczych.

Digest, czyli identyfikator zawartości obrazu kontenera, pomaga zapisać artefakt użyty w konkretnym uruchomieniu. Ten zapis powinien towarzyszyć zmianom konfiguracji i obciążenia. W przeciwnym razie zespoły mogą mieć trudności z ustaleniem, która zmiana wyjaśnia odmienny rezultat.

Ten sygnał dotyczy długoterminowego uzasadnienia utrzymania Ray Train DLCs. Opublikowane środowisko zapewnia trwałą wartość, gdy organizacje mogą świadomie wdrażać aktualizacje i jasno badać regresje. Początkowe usunięcie kroku budowania jest tylko częścią tej relacji.

Czytelnicy oceniający teraz przykład powinni zacząć od zdefiniowania dowodów wymaganych przez ich decyzję. Wykorzystaj opublikowaną konfigurację jako punkt odniesienia, zapisz dokładne środowisko i oddziel testy łączności od wyników obciążenia. Następnie wprowadź rzeczywiste dane, zweryfikuj odzyskiwanie zapisanego stanu i porównuj pomiary w spójnych warunkach. Zachowaj zapis wdrożenia obok ustaleń treningowych, aby inny inżynier mógł zrozumieć, co się zmieniło. Ray Train DLCs zapewniają zespołom utrzymywane środowisko początkowe; zespół wdrażający dostarcza dowody, które czynią je odpowiednim dla jego pracy. Która część obecnego procesu treningowego rzeczywiście wymaga niestandardowego obrazu, a która skorzystałaby najpierw na ocenie tej wspólnej bazy?