Listy preferencji instancji Amazon SageMaker zastępują ręczne ponawianie prób GPU, ale nie planowanie pojemności

Amazon wprowadził listy preferencji instancji Amazon SageMaker, dzięki którym jedno żądanie szkoleniowe może obejmować do pięciu uporządkowanych opcji mocy obliczeniowej zamiast jednego, stałego typu instancji. SageMaker AI sprawdza te opcje według priorytetu i uruchamia pierwszą konfigurację z dostępną pojemnością.

Zmiana ta rozwiązuje utrzymujący się problem operacyjny. Zadania szkoleniowe SageMaker wykorzystujące GPU mogą pozostawać w stanie oczekiwania, gdy wymagany sprzęt jest niedostępny. Zespoły reagowały na to, monitorując pojemność, ponownie przesyłając zadania lub utrzymując skrypty próbujące alternatywnych konfiguracji.

AWS przenosi teraz decyzję o ponowieniu próby do zarządzanego harmonogramu. Funkcja nie tworzy jednak pojemności GPU ani nie dowodzi, że różne akceleratory poprawnie uruchomią dane obciążenie. Jej wartość zależy od tego, czy zespoły potrafią rzeczywiście uelastycznić względem sprzętu kod szkoleniowy, cele wydajnościowe i mechanizmy kontroli kosztów.

To rozróżnienie poddaje presji znaną praktykę chmurową: traktowanie typu instancji jako stałej właściwości każdego zadania. Google Cloud już kolejkowuje elastyczne żądania akceleratorów za pośrednictwem Dynamic Workload Scheduler. Użytkownicy Azure Machine Learning również planują pracę wokół regionalnych limitów przydziału mocy obliczeniowej specyficznych dla rodzin instancji. AWS czyni teraz zadeklarowaną elastyczność sprzętową podstawową częścią pojedynczych zadań SageMaker.

Co AWS zmienił dzięki listom preferencji instancji Amazon SageMaker

Jedno żądanie SageMaker może teraz wyrażać kilka akceptowalnych konfiguracji mocy obliczeniowej bez potrzeby zewnętrznego kontrolera ponawiania prób.

AWS ogłosił tę funkcję 15 września 2026 r. zarówno dla zadań szkoleniowych, jak i przetwarzania. Jest ona dostępna przez API SageMaker, SDK, narzędzia wiersza poleceń i konsolę we wszystkich Regionach AWS, w których dostępny jest SageMaker AI, zgodnie z informacją firmy o dostępności regionalnej.

Lista preferencji zawiera od dwóch do pięciu typów instancji w kolejności priorytetu. SageMaker waliduje listę, wykonuje przegląd w pamięci i wybiera pierwszą konfigurację z dostępną pojemnością. Zadanie uruchamia się tylko w jednej konfiguracji z listy.

Jeśli żadna opcja nie jest natychmiast dostępna, zadanie trafia do kolejki sterowanej zdarzeniami. SageMaker ponawia próby wraz ze zmianą pojemności, zamiast wymagać od procesu klienckiego odpytywania usługi i ponownego przesyłania żądań. Łączny czas oczekiwania można ograniczyć za pomocą MaxPendingTimeInSeconds.

Ten limit czasu dotyczy całej listy preferencji, a nie każdej opcji osobno. AWS podaje również, że ma on zastosowanie tylko wtedy, gdy co najmniej jedna konfiguracja z listy korzysta z przyspieszonej mocy obliczeniowej z rodzin takich jak ml.p, ml.g lub ml.trn.

To zachowanie ma znaczenie, ponieważ preferencja to coś więcej niż alternatywna nazwa instancji. Zespoły mogą przypisać inną liczbę instancji do każdej opcji. Zadanie może preferować dwa węzły ml.g6.48xlarge, lecz zaakceptować cztery węzły ml.g5.48xlarge, jeśli druga konfiguracja zapewnia odpowiednią łączną przepustowość.

AWS dopuszcza dwa modele liczby instancji. Wspólne ResourceConfig.InstanceCount może obowiązywać dla każdej preferencji albo każda preferencja może definiować własną liczbę. Łączenie tych podejść jest nieprawidłowe, jak wyjaśnia dokumentacja API.

Funkcja łączy się także z SageMaker Flexible Training Plans, które rezerwują obsługiwaną pojemność GPU na określony czas. Zadanie szkoleniowe może umieścić zgodną konfigurację wspieraną przez plan na pierwszym miejscu, a następnie wymienić alternatywy on-demand. Jeśli zarezerwowana opcja nie może zostać udostępniona, SageMaker przechodzi przez pozostałe preferencje.

Ta integracja jest ograniczona do szkoleń. Zadania przetwarzania otrzymują ten sam mechanizm uporządkowanego przełączania awaryjnego, ale nie mogą wiązać preferencji z Flexible Training Plans.

Zastosowanie do przetwarzania nadal jest istotne. SageMaker Processing uruchamia zarządzaną infrastrukturę do przygotowania danych, inżynierii cech, ewaluacji i powiązanych prac. Zadania te często tolerują szerszy zakres sprzętu niż ściśle zoptymalizowane zadania rozproszonego szkolenia.

AWS przedstawia tę zmianę jako alternatywę dla ręcznych pętli ponawiania prób i skryptów monitorujących pojemność w swoim wpisie ogłaszającym. To najbardziej bezpośrednia korzyść. Pipeline przesyła jedno zadanie, a SageMaker przejmuje wyszukiwanie pojemności w zadeklarowanych granicach.

Harmonogram nie wybiera dowolnej maszyny, którą uzna za równoważną. Przestrzega kolejności wskazanej przez klienta. Zachowuje to użyteczny podział odpowiedzialności: operatorzy decydują, które konfiguracje są prawidłowe, a SageMaker decyduje, która prawidłowa opcja może wystartować jako pierwsza.

To niewielka zmiana API o większych konsekwencjach operacyjnych. Elastyczność infrastruktury może teraz towarzyszyć definicji zadania, zamiast pozostawać w otaczającym ją kodzie orkiestracji.

Dlaczego pojemność GPU w SageMaker stała się problemem harmonogramu

Deficytowym zasobem nie jest już tylko GPU; jest nim właściwa konfiguracja klastra we właściwym Regionie we właściwym momencie.

Zespoły szkolące modele AI często omawiają akceleratory jako wymienne jednostki, lecz pojemność chmury jest podzielona między rodziny instancji, rozmiary, Regiony, pule dostępności, limity i modele rezerwacji. Klient może mieć uprawnienie do zażądania maszyny, nie oznacza to jednak, że maszyna będzie gotowa do natychmiastowego przydzielenia.

Ta fragmentacja tworzy niezręczne scenariusze obsługi błędów. Pipeline może być technicznie poprawny, a mimo to stracić wiele godzin, ponieważ wybrana konfiguracja nie może wystartować. Inżynier musi wtedy zdecydować, czy czekać, zmienić sprzęt, zmienić liczbę węzłów czy przenieść obciążenie.

Przed listami preferencji zadania szkoleniowe SageMaker wskazywały jeden typ instancji podczas przesyłania. Zespoły akceptujące alternatywy musiały kodować tę elastyczność gdzie indziej. Niektóre tworzyły funkcje ponawiające próby po błędach API. Inne przesyłały kilka wariantów i anulowały przegrane po uruchomieniu jednego z nich.

Oba wzorce wprowadzają pracę związaną z koordynacją. Wiele aktywnych żądań może komplikować obserwowalność i anulowanie. Skrypty sekwencyjnych ponowień wymagają zarządzania stanem, reguł wycofywania, obsługi limitów czasu, uprawnień oraz ochrony przed podwójnym wykonaniem.

Monitorowanie pojemności również staje się kolejnym systemem produkcyjnym. Zespół musi utrzymywać go przy zmianach zachowania SDK, ujawniać jego awarie i zapewniać, że ponownie uruchomiony kontroler nie wystartuje dwukrotnie tego samego kosztownego zadania.

Listy preferencji instancji Amazon SageMaker przejmują część tej płaszczyzny sterowania. Żądanie zadania zawiera ograniczony zestaw akceptowalnych wyników, a zarządzana usługa dokonuje wyboru po znalezieniu pojemności.

Model ten odzwierciedla zachowanie wielu rzeczywistych obciążeń. Dostrajanie, ewaluacja, przetwarzanie wstępne i eksperymentowanie z modelami często mają preferowaną konfigurację, a nie jedną konfigurację konieczną z matematycznego punktu widzenia. Zespół może preferować nowsze GPU ze względu na szybkość, ale zaakceptować starsze GPU, gdy czas rozpoczęcia jest ważniejszy.

Ta sama zasada dotyczy liczby węzłów. Dwa szybsze węzły i cztery wolniejsze mogą czasem spełnić podobny cel ukończenia pracy. Nie są one z natury równoważne, ale deweloperzy mogą je przetestować i zadeklarować, że oba warianty są akceptowalne.

AWS nie jest jedynym dostawcą, który zamienia niedobór w interfejs harmonogramu. Tryb Flex-start Google Cloud kolejkowuje żądania akceleratorów, aż wszystkie wymagane zasoby staną się dostępne. Google pozycjonuje go dla zadań szkoleniowych, które mogą tolerować elastyczny czas rozpoczęcia.

Mechanizmy się różnią. Model Google kładzie nacisk na realizację żądanego przydziału akceleratorów i czasu trwania. AWS pozwala jednemu zadaniu SageMaker przechodzić przez uporządkowany zestaw typów i liczebności. Oba podejścia proszą klientów o wyrażenie elastyczności zamiast wielokrotnego sprawdzania pojemności.

Azure Machine Learning ujawnia inną część ograniczenia. Jego limity mocy obliczeniowej są zarządzane według Regionu i rodziny VM, z osobnymi limitami dla użycia w obszarze roboczym i subskrypcji. Rodziny GPU mogą zaczynać bez domyślnego limitu dedykowanych rdzeni, zależnie od subskrypcji.

Systemy te pokazują, dlaczego dostępności akceleratorów nie można sprowadzić do strony katalogowej. Wymieniona instancja może być obsługiwana, a mimo to niedostępna dla konkretnego konta, lokalizacji, rozmiaru zadania lub okna czasowego.

W przypadku klientów AWS natychmiastowa presja dotyczy zespołów utrzymujących niestandardową logikę udostępniania zasobów. Jeśli usługa ponawiająca próby jedynie przechodzi przez typy instancji SageMaker, jej podstawowa funkcja pokrywa się teraz z funkcją platformy.

Funkcja wywiera również presję na sztywne standardy wewnętrzne, które zatwierdzają dokładnie jeden typ instancji dla każdego modelu. Standardy te upraszczały benchmarking i nadzór, lecz każdy niedobór pojemności zamieniają w blokadę. Zespoły mają teraz powód, by certyfikować kilka konfiguracji dla każdego obciążenia.

Nie eliminuje to orkiestracji. Pipeline’y nadal potrzebują zależności, śledzenia artefaktów, polityk awarii i walidacji po uruchomieniu. Zmiana zawęża zakres pracy orkiestracji, przenosząc jedną powtarzalną decyzję — która akceptowalna konfiguracja może wystartować — do samego SageMaker.

Elastyczność zastępuje logikę ponawiania prób, a nie ograniczenia pojemności

Mechanizm usprawnia wyszukiwanie dostępnej infrastruktury, ale nie może zapewnić infrastruktury, która nie istnieje.

Gdy zadanie trafia do usługi, SageMaker waliduje jego konfigurację i listę preferencji względem obsługiwanych zasobów i limitów. Harmonogram sprawdza następnie opcje jednokrotnie w zadeklarowanej kolejności. Pierwsza dostępna opcja wygrywa i rozpoczyna udostępnianie zasobów.

Jeśli każda opcja jest niedostępna, kolejka sterowana zdarzeniami oczekuje na istotną zmianę pojemności. Jest to bardziej wydajne niż ciągłe odpytywanie przez klienta, ale nadal pozostaje kolejką. Zadanie może oczekiwać do wygaśnięcia limitu czasu.

Ta granica ma znaczenie przy ocenie twierdzenia AWS, że funkcja pomaga zadaniom uruchamiać się szybciej. Porównanie dotyczy zadania przypiętego do jednej niedostępnej konfiguracji lub wolniejszego, zarządzanego przez klienta systemu ponawiania prób. AWS nie opublikował niezależnych benchmarków pokazujących medianę poprawy czasu rozpoczęcia w różnych Regionach, rodzinach instancji lub rozmiarach klastrów.

Lista nie łączy też częściowej pojemności z kilku pozycji. Jeśli preferencja wymaga ośmiu węzłów, SageMaker potrzebuje możliwości udostępnienia wybranej konfiguracji. System wybiera jedną kompletną preferencję, zamiast budować heterogeniczny klaster z dostępnych fragmentów.

To odróżnia preferencje instancji od heterogenicznych klastrów SageMaker. Heterogeniczny klaster celowo uruchamia wiele grup instancji w ramach jednego zadania szkoleniowego. Lista preferencji reprezentuje wzajemnie wykluczające się alternatywy, z których tylko jedna staje się środowiskiem obliczeniowym zadania.

Rozróżnienie to chroni spójność wykonania. Frameworki rozproszonego szkolenia zwykle oczekują znanej topologii po rozpoczęciu zadania. Wybór jednej zdefiniowanej wcześniej konfiguracji jest prostszy niż dynamiczne mieszanie architektur sprzętowych, charakterystyk sieci i profili pamięci.

Integracja z Training Plan dodaje kolejną warstwę decyzji. Preferencja może wskazywać zgodny zarezerwowany plan, podczas gdy późniejsze pozycje korzystają z pojemności on-demand. AWS ocenia zarezerwowaną opcję jako pierwszą, gdy operatorzy umieszczą ją na pierwszym miejscu.

Ta sekwencja daje organizacjom bezpośredni sposób na preferowanie przedpłaconej pojemności bez czynienia z niej jedynej ścieżki realizacji zadania. Mechanizm awaryjny może jednak zmienić wynik ekonomiczny. Alternatywa na żądanie może wiązać się z innym efektywnym kosztem, a większa liczba węzłów może tę różnicę spotęgować.

Funkcja nie wydaje się również zastępować Managed Spot Training. Managed Spot Training rozwiązuje inny kompromis, wykorzystując przerywalną pojemność EC2 Spot. AWS podaje, że takie podejście może obniżyć koszt obliczeń, choć przerwania mogą wydłużyć czas realizacji i wymagać tworzenia punktów kontrolnych.

Preferencje instancji dotyczą przede wszystkim początkowego wyboru dostępnej pojemności spośród akceptowalnych konfiguracji. Trenowanie Spot dotyczy modelu zakupu i ryzyka przerwań po uzyskaniu przez obciążenie zasobów obliczeniowych. Zespoły muszą oceniać te wymiary oddzielnie.

Najlepiej pasuje więc zadanie wrażliwe na ponowne uruchomienie, lecz elastyczne sprzętowo. Przykładem może być nocny potok ewaluacyjny, który może działać na kilku generacjach GPU. Przekroczenie porannego okna raportowania ma znaczenie, ale użycie absolutnie najszybszego akceleratora już nie.

Zespół może certyfikować kilka konfiguracji, uporządkować je według preferowanej równowagi między czasem ukończenia a oczekiwanym kosztem, a następnie ustawić maksymalny czas oczekiwania. SageMaker wybiera w obrębie tego przetestowanego zakresu.

Duże procesy wstępnego trenowania stanowią trudniejszy przypadek. Ich wzorce komunikacji, wymagania pamięciowe, zachowanie punktów kontrolnych i topologia mogą być dostrojone do jednego akceleratora oraz interkonektu. Nominalnie obsługiwana opcja awaryjna może sprawić, że zadanie będzie wolniejsze, droższe lub niestabilne.

Nowy harmonogram nie potrafi ocenić, czy taka opcja awaryjna pozostaje naukowo lub ekonomicznie uzasadniona. Ten osąd nadal należy do właściciela obciążenia.

Listy preferencji instancji Amazon SageMaker są więc deklaratywne, a nie adaptacyjne w szerokim znaczeniu. SageMaker reaguje na sygnały dotyczące pojemności, lecz nie przeprowadza benchmarków modelu, nie przepisuje ustawień rozproszonych ani nie optymalizuje listy względem terminu.

To nadal ma znaczenie. Usługi zarządzane tworzą wartość, gdy przejmują od każdego klienta powtarzalną, jasno ograniczoną odpowiedzialność i implementują ją raz. Mechanizm awaryjny dla pojemności wpisuje się w ten wzorzec, o ile klient określi uczciwe granice kompatybilności.

Kompatybilność i koszty nadal pozostają odpowiedzialnością operatora

Najważniejsze ryzyko nie polega na tym, że SageMaker wybierze niewłaściwą preferencję; polega na tym, że zespół uzna niebezpieczną preferencję za akceptowalną.

AWS wyraźnie ostrzega, że SageMaker nie weryfikuje kompatybilności między typami instancji. Usługa nie ustala, czy kontener obsługuje każdą architekturę GPU, czy jego sterowniki są zgodne ani czy konfiguracja rozproszona wymaga sieci Elastic Fabric Adapter.

Zadanie może zatem przejść walidację żądania, a mimo to zakończyć się niepowodzeniem po udostępnieniu zasobów. Taki rezultat pochłania czas uruchamiania i może osłabić oczekiwane korzyści z automatycznego mechanizmu awaryjnego.

Na szczególną uwagę zasługuje zachowanie frameworków. Możliwości CUDA, biblioteki komunikacji zbiorowej, formaty mieszanej precyzji, wyniki kompilatora i jądra specyficzne dla urządzeń mogą różnić się między generacjami akceleratorów. Nie należy zakładać, że kontener przetestowany na sprzęcie H100 będzie zachowywał się identycznie na sprzęcie A100 lub L40S.

Pamięć jest kolejną granicą. Obciążenie mieszczące się na jednym akceleratorze może przekroczyć pamięć urządzenia na innym, nawet gdy łączna teoretyczna przepustowość wydaje się podobna. Zwiększenie liczby węzłów nie rozwiązuje automatycznie ograniczeń pamięci przypadającej na urządzenie.

Rozproszona topologia również wpływa na wydajność. Zastąpienie dwóch węzłów o wysokiej przepustowości czterema wolniejszymi zmienia wolumen komunikacji, narzut synchronizacji i ekspozycję na awarie. Równa liczba GPU lub przybliżone oszacowanie mocy obliczeniowej nie gwarantują takiego samego czasu ukończenia.

Przykłady AWS ilustrują intencję, a nie uniwersalny wzór równoważności. Jeden z przykładów wymienia dwie instancje ml.g6.48xlarge przed czterema instancjami ml.g5.48xlarge. Klient musi zdecydować, czy taka relacja zachodzi dla jego modelu, rozmiaru batcha, wzorca sieciowego i stosu oprogramowania.

Zespoły powinny przeprowadzić benchmark każdej wymienionej konfiguracji z tym samym obrazem kontenera, ścieżką danych i uruchamiaczem rozproszonym, które są używane w produkcji. Powstały zapis zatwierdzenia powinien obejmować czas działania, kontrolę zbieżności, wykorzystanie zasobów, współczynnik awarii i walidację wyników.

Polityka kosztowa wymaga tej samej dyscypliny. Kolejność preferencji wyraża priorytet, a nie limit budżetowy. Opcja awaryjna z większą liczbą instancji może uruchomić się wcześniej, ale wygenerować wyższy całkowity rachunek niż opcja preferowana.

Z kolei starszy sprzęt może działać dłużej i zniwelować pozorną oszczędność na pojedynczej instancji. Istotną miarą jest kompletny wynik zadania, obejmujący opóźnienie uruchomienia, czas wykonania, ponowienia, pamięć masową oraz wszelki wpływ na kolejne terminy.

Uruchomienie tworzy także wymóg obserwowalności. Zespoły muszą rejestrować, która preferencja wygrała, jak długo zadanie czekało, dlaczego alternatywy zostały tak uporządkowane oraz czy rzeczywista wydajność odpowiadała benchmarkowi.

Bez tych zapisów automatyczny wybór staje się nieprzejrzysty. Inżynierowie mogą zauważyć większą zmienność czasu działania lub kosztu, nie wiedząc, że między uruchomieniami zmieniła się bazowa rodzina instancji.

Aktualizacji mogą wymagać również reguły zarządzania. AWS obsługuje polityki tożsamości ograniczające typy instancji SageMaker. Zatwierdzona przez organizację lista preferencji musi pozostawać w granicach tych kontroli, limitów konta i dostępności regionalnej.

Zarezerwowana pojemność wprowadza kolejne potencjalne nieporozumienie. Preferencja Flexible Training Plan może zapewnić silniejsze zobowiązanie dotyczące pojemności, ale opcja awaryjna nie zamienia niedostępnej rezerwacji w większą podaż zasobów zarezerwowanych. Przenosi zadanie na osobną, akceptowalną ścieżkę na żądanie.

Zadania przetwarzania wymagają własnego przeglądu. Opcja awaryjna oparta na CPU może mieć sens w przypadku niektórych transformacji, ale może też drastycznie zmienić czas ukończenia. Zespoły powinny unikać dodawania opcji CPU wyłącznie dlatego, że pozwala na to API.

Brak opublikowanych danych terenowych jest obecnie największą niewiadomą. AWS opisał przepływ harmonogramowania i reguły konfiguracji, ale klienci nie mają jeszcze szerokich dowodów dotyczących poprawy czasu uruchomienia w różnych warunkach niedoboru.

Przydatne pomiary powinny porównywać tę funkcję z istniejącym punktem odniesienia każdego zespołu. Obejmuje to czas od zgłoszenia do wykonania, odsetek zadań korzystających z opcji awaryjnej, wskaźniki przekroczenia limitu czasu, całkowite zużycie zasobów obliczeniowych oraz incydenty operacyjne spowodowane zmianami konfiguracji.

Te pomiary pokażą, czy elastyczność pojemności GPU w SageMaker usuwa rzeczywistą uciążliwość operacyjną, czy jedynie przenosi zmienność do mniej widocznej warstwy.

Trzy sygnały pokażą, czy funkcja działa w praktyce

Wdrożenie należy oceniać na podstawie wyników zadań, a nie liczby zespołów dodających drugi typ instancji do swojej konfiguracji.

Pierwszym sygnałem jest częstotliwość korzystania z opcji awaryjnej zestawiona z czasem uruchomienia. Zespoły powinny mierzyć, jak często SageMaker wybiera cokolwiek poniżej pierwszej preferencji i jak wpływa to na opóźnienie od zgłoszenia do startu.

Wysoki wskaźnik opcji awaryjnych przy krótszym czasie oczekiwania wspierałby główną tezę AWS. Pokazywałby, że pojemność istnieje w szerszej puli, nawet gdy preferowany typ jest ograniczony.

Wysoki wskaźnik opcji awaryjnych bez skrócenia czasu oczekiwania osłabiłby ten argument. Może to oznaczać, że wskazane alternatywy dzielą to samo regionalne wąskie gardło, żądane klastry są zbyt duże albo kolejka sterowana zdarzeniami nie poprawia istotnie realizacji tego obciążenia.

Drugim sygnałem jest zmienność wydajności i kosztów między wybranymi konfiguracjami. Każda opcja awaryjna powinna być powiązana z czasem działania, wykorzystaniem zasobów, statusem ukończenia i całkowitym zużyciem zasobów.

Stabilne wyniki wzmocniłyby argument za traktowaniem infrastruktury jako zbioru preferencji. Duże odchylenia pokazałyby, że alternatywy nie były naprawdę równoważne, nawet jeśli każda konfiguracja mogła technicznie uruchomić kontener.

Jest to szczególnie ważne w przypadku powtarzalnych potoków. Zespół może zaakceptować jedno wolniejsze uruchomienie podczas pilnego eksperymentu, ale odrzucić trwałą nieprzewidywalność w codziennym harmonogramie produkcyjnym.

Trzecim sygnałem jest sposób, w jaki AWS rozbudowuje funkcję oraz towarzyszącą jej telemetrię. Klienci powinni obserwować bogatsze zdarzenia wyboru, jaśniejsze wyjaśnienia stanu oczekiwania, narzędzia do porządkowania uwzględniającego koszty oraz szerszą integrację z mechanizmami kontroli potoków.

Wsparcie dla bardziej niuansowanych polityk również miałoby znaczenie. Operatorzy mogą ostatecznie potrzebować ograniczeń takich jak termin, granica wydatków lub wymóg, aby przepustowość opcji awaryjnej pozostawała w przetestowanym zakresie. Obecna uporządkowana lista koduje te osądy ręcznie.

Reakcje konkurentów dostarczają dodatkowego kontekstu, lecz rozstrzygające dowody będą pochodzić z operacji klientów. Google już traktuje niedobór akceleratorów jako problem harmonogramowania za pośrednictwem Dynamic Workload Scheduler. Azure ujawnia granice limitów, które kształtują możliwość uruchamiania zadań zarządzanych.

Charakterystycznym posunięciem AWS jest umieszczenie kilku akceptowalnych konfiguracji bezpośrednio w żądaniu trenowania lub przetwarzania SageMaker. Jeśli klienci osiągną szybsze uruchamianie bez niedopuszczalnej zmienności, ten model będzie trudny do zignorowania dla zarządzanych platform ML.

Test w krótkim terminie jest prosty. Wybierz jedno obciążenie elastyczne sprzętowo, przeprowadź benchmark każdej kandydackiej konfiguracji i określ maksymalny czas oczekiwania przed włączeniem automatycznej opcji awaryjnej. Następnie porównaj co najmniej kilka uruchomień ze starym procesem ponawiania.

Rejestruj wybrany typ instancji, czas w kolejce, czas wykonania, status ukończenia i całkowite użycie zasobów. Nie traktuj udanego uruchomienia jako pełnego wyniku.

Listy preferencji instancji Amazon SageMaker czynią obsługę pojemności mniej ręczną, ale nagradzają przygotowanie. Zespoły, które zwalidują swoje alternatywy, mogą usunąć kruche elementy kodu infrastruktury. Zespoły wprowadzające spekulacyjne opcje awaryjne mogą jedynie zautomatyzować wykrywanie niekompatybilności.

Przydatne pytanie nie brzmi, czy pięć opcji jest lepszych od jednej. Chodzi o to, czy organizacja potrafi zdefiniować pięć rzeczywiście akceptowalnych wyników, świadomie je uporządkować i mierzyć, co dzieje się, gdy SageMaker wybiera między nimi.