Kontenery AWS Ray Serve Deep Learning przejmują rolę tam, gdzie kończy się wsparcie dla TorchServe
AWS opublikował ścieżkę migracji dla pojedynczego GPU z użyciem AWS Ray Serve Deep Learning Containers w czasie, gdy TorchServe przechodzi w bezterminowy tryb zamrożonego utrzymania. Ta zmiana ma znaczenie, ponieważ użytkownicy TorchServe nie mają już aktywnie utrzymywanego frameworka obsługującego ich produkcyjne modele PyTorch. AWS oferuje zamiast tego sprawdzony stos kontenerowy, lecz zespoły nadal muszą przepisać aplikacje obsługujące modele i zarządzać otaczającą je infrastrukturą.
Nowy przewodnik po migracji wdraża model wizualno-językowy Qwen3-VL-2B na Amazon Elastic Kubernetes Service, czyli Amazon EKS. Działa on w jednym podzie na jednej instancji g5.xlarge z jednym GPU NVIDIA A10G i 24 GB pamięci GPU. Przykład udostępnia model przez punkt końcowy HTTP na porcie 8000.
To niewielkie wdrożenie ujawnia szerszy konflikt. TorchServe niegdyś łączył archiwizację modeli, handlery, konfigurację i obsługę modeli w przepływie pracy skoncentrowanym na PyTorch. AWS Ray Serve Deep Learning Containers zastępują ten framework utrzymywanym obrazem, kodem aplikacji Ray Serve i standardowymi zasobami Kubernetes. Odpowiedzialność operacyjna zmienia formę, zamiast znikać.
AWS zamienia lukę we wsparciu TorchServe w ścieżkę migracji kontenerowej
AWS odpowiada na zamrożenie utrzymania TorchServe sprawdzonym stosem inferencyjnym, a nie zamiennikiem typu drop-in.
Oficjalna dokumentacja TorchServe wyświetla obecnie informację o ograniczonym utrzymaniu. Wynika z niej, że projekt nie jest już aktywnie rozwijany. Istniejące wydania pozostają dostępne, ale nie są planowane aktualizacje, poprawki błędów, nowe funkcje ani poprawki bezpieczeństwa.
To ostrzeżenie zmienia ocenę ryzyka dla użytkowników produkcyjnych. Stabilna aplikacja może nadal działać na istniejącym wydaniu TorchServe. Jednak każde nowe wymaganie dotyczące frameworka, systemu operacyjnego, CUDA lub bezpieczeństwa tworzy kolejną decyzję w zakresie kompatybilności dla właściciela aplikacji.
Bezpieczeństwo jest najtrudniejszym elementem do odłożenia na później. Informacja TorchServe wyraźnie ostrzega, że podatności mogą nie zostać usunięte. Organizacje mogą izolować wdrożenia i aktualizować otaczające warstwy, ale nie mogą polegać na przyszłych poprawkach upstream dla frameworka obsługującego modele.
AWS pozycjonuje swój Ray Serve Deep Learning Container, powszechnie nazywany DLC, jako wspieraną podstawę dla takich obciążeń. DLC to obraz kontenera z wybranym frameworkiem i powiązanymi zależnościami, zainstalowanymi i przetestowanymi razem. AWS publikuje oddzielne obrazy Ray Serve dla Amazon EC2 i EKS oraz dla Amazon SageMaker.
Obraz GPU bazuje na NVIDIA Amazon Linux 2023. Ta podstawa obejmuje system operacyjny i biblioteki środowiska uruchomieniowego CUDA. AWS dodaje następnie PyTorch, Ray Serve, FastAPI, Uvicorn, Hugging Face Transformers oraz narzędzia do przetwarzania obrazu, dźwięku i danych multimodalnych.
Obraz zawiera również kompilację FFmpeg z akceleracją sprzętową NVIDIA do wstępnego przetwarzania wideo. Ten szczegół ma znaczenie dla zespołów obsługujących modele łączące klatki wideo, obrazy, dźwięk i tekst. Takie obciążenia często wymagają więcej niż frameworka modelowego i serwera HTTP.
AWS twierdzi, że przed każdym wydaniem obrazu weryfikuje razem zawarte w nim komponenty. Poprawki bezpieczeństwa są stosowane podczas budowania obrazu. Takie podejście ogranicza rozbieżności wersji między środowiskiem CUDA, PyTorch, Ray Serve i warstwą serwowania aplikacji webowej.
Ta obietnica ma jasno określoną granicę. AWS wspiera i testuje kombinację kontenera, podczas gdy użytkownicy pozostają odpowiedzialni za kod modelu, konfigurację klastra, kontrolę sieciową, zasady skalowania i proces aktualizacji. Utrzymywany obraz zawęża obszar, który zespoły muszą samodzielnie składać.
Przykład nie przedstawia też Ray Serve jako transparentnego trybu kompatybilności z TorchServe. Inżynierowie piszą nową klasę obsługującą w Pythonie i wdrażają ją przez Ray Serve. Nie importują archiwum TorchServe ani nie wykorzystują ponownie całego jego interfejsu zarządzania.
To rozróżnienie utrzymuje ogłoszenie w realistycznych ramach. AWS Ray Serve Deep Learning Containers oferują wspierane miejsce docelowe dla objętych zmianą obciążeń. Nie czynią migracji produkcyjnej automatyczną ani nie eliminują potrzeby testowania wdrożeń.
Dlaczego zespoły TorchServe przejmują dziś większą część stosu GPU
Koniec aktywnego utrzymania TorchServe przenosi niepewność po stronie upstream bezpośrednio na zespoły inżynierii platformowej i uczenia maszynowego.
Usługa inferencji GPU zależy od kilku warstw rozwijających się niezależnie. Obejmują one system operacyjny, środowisko NVIDIA, biblioteki CUDA, PyTorch, zależności modelu, serwer żądań i środowisko orkiestracji. Problemy z kompatybilnością mogą wystąpić nawet wtedy, gdy kod modelu się nie zmienia.
TorchServe wcześniej zapewniał zespołom PyTorch rozpoznawalną ścieżkę pakowania i obsługi modeli. Deweloperzy mogli tworzyć archiwum modelu za pomocą torch-model-archiver, dostarczać własny handler i kontrolować zachowanie poprzez config.properties. Ten przepływ pracy tworzył własną złożoność, ale zapewniał też wspólną konwencję operacyjną.
Zamrożenie utrzymania odbiera pewność, że ta konwencja będzie nadążać za powiązanym oprogramowaniem. Zespoły mogą przypiąć każdą zależność, lecz przypinanie jedynie opóźnia kolejną decyzję. Aktualizacja systemu operacyjnego, zmiana GPU lub aktualizacja frameworka ostatecznie wymusi walidację całego stosu.
Dalsze korzystanie z TorchServe pozostaje możliwe. Projekt nie zniknął, a istniejące wydania nadal działają w wielu wdrożeniach. Problem polega na tym, że pozostanie przy nim staje się świadomym wyborem wewnętrznej odpowiedzialności, a nie wspieranym ustawieniem domyślnym.
Organizacje wybierające tę drogę potrzebują jasnego procesu bezpieczeństwa. Muszą monitorować istotne zależności, oceniać wystawione interfejsy, przebudowywać obrazy i testować poprawki bez oczekiwania na nowe wydania TorchServe. Potrzebują też planu dotyczącego podatności w samym TorchServe.
Alternatywą jest migracja, która tworzy natychmiastową pracę inżynierską. Handlery TorchServe i archiwa modeli nie stają się automatycznie wdrożeniami Ray Serve. Porównania wymagają analiza żądań, zachowanie kontroli kondycji, metryki, ładowanie modeli, przetwarzanie wsadowe i obsługa błędów.
Ray Serve zmienia podstawowy model programowania. Deweloper oznacza klasę Pythona przez @serve.deployment, inicjalizuje model w tej klasie i obsługuje przychodzące żądania HTTP przez __call__. Wywołanie .bind() rejestruje aplikację dla Ray Serve.
Ten model może wydawać się prostszy od struktury archiwum i handlerów TorchServe. Daje też deweloperom zwykłe komponowanie w Pythonie i bezpośredni dostęp do deklaracji zasobów Ray. Na przykład wdrożenie AWS żąda jednego GPU przez ray_actor_options={"num_gpus": 1}.
Jednak prostszy kod aplikacji nie oznacza prostszej eksploatacji produkcyjnej. Zespoły nadal potrzebują kontroli gotowości, uwierzytelniania, zarządzania ruchem, telemetrii, kontroli wdrożeń i procedur wycofywania zmian. Muszą zdecydować, jak wagi modelu trafiają do środowiska i jak repliki zachowują się podczas aktualizacji.
Kontener AWS przenosi kilka decyzji dotyczących kompatybilności na upstream. AWS wybiera i testuje bazowy system operacyjny, środowisko CUDA, framework i zależności obsługi modeli. Może to ograniczyć powtarzalną pracę integracyjną wymaganą przy obrazie składanym wewnętrznie.
Tworzy to również nową zależność od wydań obrazów AWS. Zespoły platformowe muszą śledzić tagi obrazów, analizować zmiany, skanować dodane przez siebie warstwy i kwalifikować nowe wersje we własnych środowiskach. Przetestowana podstawa jest użytecznym dowodem, ale nie stanowi certyfikacji na poziomie aplikacji.
Zespoły mające wymagania dotyczące zgodności potrzebują jeszcze szerszej walidacji. Muszą potwierdzić, że zawartość obrazu spełnia polityki wewnętrzne i że aktualizacje docierają w wymaganych terminach. Potrzebują też zestawień materiałowych oprogramowania i dokumentacji zarządzania podatnościami dla kompletnego obrazu.
Presja spada zatem najciężej na zespoły posiadające dojrzałe środowiska TorchServe. Zgromadziły one handlery, kroki pakowania, dashboardy i wiedzę operacyjną wokół jednego frameworka. Przejście na Ray Serve oznacza wykorzystanie tej wiedzy, podczas gdy stary system może nadal sprawiać wrażenie stabilnego.
Mniejsze wdrożenia stoją przed inną kalkulacją. Jeśli usługa ma jeden model i przewidywalny ruch, pełny stos Ray i Kubernetes może wprowadzać niepotrzebną złożoność. Wartość zależy od tego, czy organizacja już obsługuje EKS i oczekuje szerszych potrzeb skalowania.
Jak AWS Ray Serve Deep Learning Containers zmieniają model obsługi modeli
Centralnym mechanizmem jest wstępna integracja: AWS ustala bazowy stos, a Ray Serve zastępuje pakowanie i cykl życia żądań TorchServe.
Przykład AWS obsługuje Qwen/Qwen3-VL-2B-Instruct, model wizualno-językowy przetwarzający obrazy i tekst. Przyjmuje adres URL obrazu i prompt, a następnie zwraca wygenerowany opis lub odpowiedź. Model pasuje do przykładu, ponieważ wykorzystuje zarówno inferencję GPU, jak i multimodalne przetwarzanie wstępne.
AWS ładuje model przez Hugging Face Transformers. AutoProcessor przygotowuje dane wejściowe multimodalne, natomiast AutoModelForImageTextToText ładuje model z wagami o połowicznej precyzji. Następnie aplikacja przenosi te wagi na urządzenie CUDA.
Klasa obsługująca otrzymuje bezpośrednio żądanie HTTP. Wyodrębnia z JSON adres URL obrazu i prompt, przygotowuje dane wejściowe modelu, uruchamia generowanie i zwraca wynik. FastAPI i Uvicorn zapewniają podstawę obsługi aplikacji webowej zawartą w DLC.
Ten projekt usuwa trzy znane artefakty TorchServe. Nie ma archiwum modelu TorchServe, hierarchii handlerów TorchServe ani pliku config.properties. Kontrakt obsługi znajduje się w aplikacji Ray Serve i jej konfiguracji wdrożenia.
AWS wstrzykuje tę aplikację Pythona przez Kubernetes ConfigMap. ConfigMap przechowuje niejawną konfigurację lub pliki, które pod może montować w czasie działania. Pozwala to inżynierom zmieniać kod demonstracyjny bez przebudowywania obrazu kontenera.
Ta elastyczność jest użyteczna podczas oceny rozwiązania. Oddziela logikę obsługi od przetestowanego obrazu bazowego i skraca cykl edycja-wdrożenie-test. Jednak zespoły produkcyjne powinny zdecydować, czy zmienna konfiguracja odpowiada ich wymaganiom dotyczącym wydań i audytu.
Niektóre organizacje zamiast tego zbudują aplikację w obrazie pochodnym. Takie podejście tworzy niezmienny artefakt zawierający zarówno bazę AWS, jak i zatwierdzony kod obsługujący. Może poprawić odtwarzalność, choć każda zmiana aplikacji wymaga nowego budowania.
Wdrożenie rezerwuje jedno GPU za pomocą zasobu Kubernetes nvidia.com/gpu. Wybiera również węzeł GPU przez etykietę role=gpu-worker. Te ustawienia pomagają Kubernetes umieścić pod inferencyjny na docelowej instancji.
Ray otrzymuje przydział GPU przez środowisko kontenera i deklarację aplikacji. Klasa modelu żąda jednego GPU, zgodnie z pojedynczym GPU udostępnionym podowi. W większych konfiguracjach Ray może planować wdrożenia w puli zadeklarowanych zasobów.
AWS udostępnia trzy skrypty związane z przykładem. Pierwszy tworzy klaster EKS za pomocą eksctl, konfigurację sieci, dostawcę OpenID Connect i podstawowe dodatki. Drugi dodaje zarządzaną grupę węzłów GPU.
Trzeci skrypt stosuje ConfigMap i wdrożenie Kubernetes. Planuje pod Ray Serve na węźle GPU i uruchamia usługę na porcie 8000. Towarzyszące repozytorium przykładowe udostępnia te artefakty wdrożeniowe do wglądu.
Po wdrożeniu użytkownicy mogą sprawdzić pod i zweryfikować przydział GPU. Następnie mogą przekierować lokalny port 8000 do działającego wdrożenia i wysłać żądanie HTTP zawierające adres URL obrazu oraz prompt. Uruchomienie nvidia-smi wewnątrz poda potwierdza użycie GPU.
Sekwencja uruchamiania ujawnia szczegół operacyjny, który muszą uwzględniać projekty produkcyjne. AWS zauważa, że Kubernetes może zgłosić pod jako gotowy, zanim Ray Serve zacznie odpowiadać na żądania. Model może nadal się ładować po osiągnięciu przez pod tego stanu.
Odrzucone pierwsze żądanie jest akceptowalne w demonstracji, lecz niebezpieczne przy ruchu produkcyjnym. Zespoły powinny powiązać gotowość z dostępnością aplikacji, a nie wyłącznie ze stanem kontenera. Sonda powinna pozostawać nieudana, dopóki model i endpoint nie będą w stanie obsługiwać rzeczywistych żądań.
Pobieranie modeli dodaje kolejną zmienną. Demonstracja pobiera model podczas inicjalizacji aplikacji, co zależy od zewnętrznej dostępności i przepustowości sieci. Zespoły produkcyjne mogą używać pamięci lokalnej, magazynu obiektowego lub warstwy obrazu, aby kontrolować zachowanie podczas uruchamiania.
Sekrety również wymagają odrębnej obsługi. ConfigMap nie powinien zawierać tokenów dostępu ani prywatnych poświadczeń. Kubernetes Secrets, EKS Pod Identity lub inny zatwierdzony system zarządzania sekretami powinny dostarczać wymagane uwierzytelnianie.
Te decyzje pokazują, co faktycznie upraszcza DLC. Standaryzuje ono podstawę programową i zapewnia przetestowane środowisko wykonawcze. Nie decyduje jednak o tym, jak organizacja obsługuje modele, sekrety, artefakty wydań czy ekspozycję usługi.
Demonstracja z pojedynczym GPU to punkt wyjścia, a nie werdykt produkcyjny
Jeden pod na jednym GPU potwierdza ścieżkę wdrożenia, ale nie dowodzi niezawodności, efektywności ani skalowalności produkcyjnej.
AWS celowo utrzymuje niewielką architekturę referencyjną. Klaster EKS ma jeden zarządzany węzeł GPU oparty na instancji g5.xlarge. Jeden pod wykorzystuje GPU NVIDIA A10G węzła, a jeden proces Ray Serve udostępnia endpoint modelu.
Taki układ jest przydatny przy testowaniu migracji. Zespół może przełożyć handler, sprawdzić zachowanie odpowiedzi, porównać wyniki i potwierdzić dostęp do GPU bez wcześniejszego projektowania klastra rozproszonego. Ułatwia także izolowanie awarii.
Ta sama prostota ogranicza wnioski, które powinni wyciągać czytelnicy. Przykład nie przedstawia nadmiarowych replik, równoległości modelu na wielu węzłach, autoskalowania sterowanego ruchem ani odzyskiwania po awarii między strefami dostępności. Nie publikuje też porównawczych wyników opóźnień ani przepustowości.
Bez tych pomiarów artykuł nie może wykazać, że Ray Serve przewyższy określone wdrożenie TorchServe. Wydajność zależy od modelu, kształtu danych wejściowych, współbieżności, batchingu, GPU, ścieżki przetwarzania wstępnego oraz ustawień generowania. Zespoły migracyjne potrzebują własnych, reprezentatywnych testów.
Architektura zawiera również pojedynczy punkt awarii usługi. Jeśli pod zostanie zrestartowany lub węzeł GPU stanie się niedostępny, endpoint przestanie odpowiadać, dopóki Kubernetes go nie przywróci. Usługa produkcyjna zwykle potrzebuje dodatkowych replik albo zdefiniowanego celu odzyskiwania.
Skalowanie projektu wprowadza KubeRay, operator Kubernetes zalecany do zarządzania klastrami Ray. Wskazówki Ray dotyczące wdrażania na Kubernetes opisują zasób niestandardowy RayService, który łączy konfigurację klastra Ray z aplikacją Serve.
KubeRay może zarządzać podami head i worker, aktualizacjami aplikacji oraz cyklem życia klastra. Obsługuje również heterogeniczne zasoby obliczeniowe i autoskalowanie. Te funkcje czynią Ray Serve bardziej przydatnym dla potoków z wieloma modelami lub usług, które muszą rozszerzać się na wiele węzłów.
Dodają jednak także pojęcia operacyjne. Zespoły muszą rozumieć Ray head, workery, kontroler Serve, deklaracje zasobów, zasoby niestandardowe Kubernetes oraz wiele warstw logów. Rozwiązywanie problemów może obejmować zarówno płaszczyznę sterowania Kubernetes, jak i Ray.
Ten kompromis ma znaczenie przy porównywaniu alternatyw. Zespół obsługujący pojedynczy model transformera może ocenić samodzielny endpoint vLLM. Organizacja korzystająca z wielu formatów modeli może rozważyć NVIDIA Triton Inference Server. Zespoły skoncentrowane na Kubernetes mogą ocenić KServe pod kątem standaryzowanych zasobów inferencyjnych.
Opcje te rozwiązują częściowo nakładające się problemy, ale mają odmienne priorytety. Ray Serve kładzie nacisk na kompozycję aplikacji Python, wykonanie rozproszone, repliki, routing i skalowanie. TorchServe koncentrował swoje podejście na pakowaniu i udostępnianiu modeli PyTorch.
Sam AWS dokumentuje inne ścieżki serwowania. Jego aktualne wskazówki dotyczące inferencji w EKS wykorzystują vLLM Deep Learning Container do wdrażania LLM. Potwierdza to, że Ray Serve DLC jest jednym ze wspieranych wzorców, a nie uniwersalnym zamiennikiem.
Właściwy wybór zależy od obciążenia. Usługa vision-language z niestandardowym przetwarzaniem wstępnym może skorzystać z kompozycji natywnej dla Pythona w Ray Serve. Standaryzowany endpoint generowania tekstu może preferować silnik zoptymalizowany konkretnie dla dużych modeli językowych.
Ocena migracji powinna zacząć się od zgodności interfejsu. Zespoły muszą porównać schematy żądań, odpowiedzi błędów, endpointy zdrowia, uwierzytelnianie oraz limity czasu klientów. Następnie powinny zweryfikować wyniki modelu względem kontrolowanego zestawu testowego.
Kolejnym krokiem muszą być testy obciążeniowe. Inżynierowie powinni mierzyć czas zimnego startu, czas do pierwszej odpowiedzi, opóźnienie w stanie ustalonym, przepustowość, pamięć GPU i zachowanie przy nagłych wzrostach ruchu. Testy powinny obejmować tę samą konfigurację przetwarzania wstępnego i generowania, która jest używana na produkcji.
Równie istotne są testy awarii. Zespoły powinny zakończyć działanie poda, opróżnić węzeł, przerwać dostęp do modelu oraz wdrożyć nieprawidłową rewizję aplikacji. Testy te pokazują, czy zamiennik spełnia oczekiwania dotyczące odzyskiwania i wycofywania zmian.
Obserwowalność wymaga bezpośredniego mapowania. Istniejące metryki i dashboardy TorchServe nie przeniosą się bez zmian. Operatorzy muszą zdecydować, które metryki Ray, aplikacji, Kubernetes i GPU definiują zdrowie, nasycenie oraz pogorszenie jakości odczuwane przez użytkowników.
Na koniec zespoły potrzebują eksperymentu aktualizacyjnego. Powinny przejść między dwiema wersjami DLC w środowisku stagingowym i zapisać wymagane zmiany w kodzie, konfiguracji oraz modelu. Wsparcie ma ograniczoną wartość, jeśli rutynowe aktualizacje nadal są zbyt ryzykowne do wdrożenia.
Na co użytkownicy TorchServe powinni zwrócić uwagę w następnej kolejności
Kolejnym testem będzie to, czy AWS potrafi przekształcić jasny przykład migracji w niezawodną ścieżkę wydań i skalowania.
Pierwszym sygnałem jest rytm wydań Ray Serve DLC. Zespoły powinny obserwować udokumentowane tagi obrazów, wersje frameworków, kombinacje CUDA, aktualizacje bezpieczeństwa i zasady wycofywania. Przewidywalne wydania wzmocniłyby argument AWS, że obraz ogranicza długoterminowe nakłady na utrzymanie.
Informacje o wydaniach są równie ważne jak ich częstotliwość. Operatorzy muszą wiedzieć, które zależności się zmieniły i czy aktualizacja zawiera zachowania powodujące niezgodność. Potrzebują też wystarczającego okresu nakładania się wspieranych tagów, aby przetestować nowy obraz przed jego wdrożeniem.
Drugim sygnałem są wskazówki produkcyjne dotyczące gotowości, ładowania modeli i odzyskiwania po awarii. Obecny przykład przyznaje, że pod może wyglądać na gotowy, zanim Ray Serve zacznie odpowiadać. Silniejsza architektura referencyjna powinna powiązać gotowość Kubernetes z załadowanym modelem i responsywnym endpointem.
Wskazówki te powinny również obejmować magazynowanie modeli i zachowanie podczas uruchamiania. Pobieranie wag podczas inicjalizacji sprawdza się w małej demonstracji. Większe wdrożenia potrzebują powtarzalnego ładowania, kontrolowanych poświadczeń, odpowiedniego magazynu oraz sond uruchamiania dobranych do rzeczywistego rozgrzewania modelu.
Trzecim sygnałem jest wspierana ścieżka od jednego GPU do wielu replik lub węzłów. AWS kieruje czytelników do KubeRay w przypadku serwowania rozproszonego i skalowania poziomego. Przyszłe przykłady powinny pokazać, jak DLC zachowuje się w ramach wdrożenia RayService.
Referencja z wieloma replikami powinna dokumentować routing ruchu, aktualizacje kroczące, sygnały autoskalowania oraz odzyskiwanie po zniknięciu workera GPU. Powinna także oddzielać obciążenia Ray head od workerów inferencyjnych GPU, zachowując kosztowną pojemność akceleratorów dla modeli.
Zespoły nie powinny czekać na każdą dokumentację referencyjną przed rozpoczęciem oceny. Mogą już teraz zinwentaryzować usługi TorchServe i uszeregować je według ekspozycji, znaczenia biznesowego oraz trudności migracji. Endpointy dostępne z internetu zasługują na wcześniejszą uwagę niż odizolowane systemy wsadowe.
Dla każdej usługi inżynierowie mogą wymienić obecnie używane funkcje TorchServe. Obejmuje to archiwa modeli, niestandardowe handlery, workflow, batching, metryki, API zarządzania i pliki konfiguracji. Inwentaryzacja staje się konkretną listą kontrolną migracji do Ray Serve.
Niewielkie proof of concept powinno zachować istniejący kontrakt żądań i odpowiedzi. Pozostawienie klientów bez zmian izoluje migrację warstwy serwowania od szerszego przepisywania aplikacji. Umożliwia także kontrolowane porównanie ruchu między starymi i nowymi endpointami.
Ocena powinna wykorzystywać te same wagi modelu i reprezentatywne dane wejściowe. Zespoły mogą porównywać spójność wyników, opóźnienia, przepustowość, wykorzystanie GPU oraz zachowanie w przypadku błędów. Powinny również rejestrować, jak długo każda usługa odzyskuje działanie po restarcie.
Zespoły bezpieczeństwa powinny przeanalizować wynikowy obraz jako kompletny artefakt. Baza AWS może otrzymywać przetestowane zależności i poprawki na etapie budowania, lecz lokalnie dodane pakiety mogą ponownie wprowadzić podatności. Skanowanie musi być kontynuowane po dostosowaniu.
Właściciele platform powinni także określić odpowiedzialność przed migracją. AWS utrzymuje DLC, Ray utrzymuje Ray Serve, a organizacja odpowiada za swoją aplikację i wdrożenie EKS. Jasne granice zapobiegają pomyleniu wspieranego komponentu ze wspieraną usługą end-to-end.
Szersza lekcja nie polega na tym, że każdy użytkownik TorchServe musi przyjąć Ray Serve. Chodzi o to, że nieutrzymywana warstwa serwowania wymaga teraz świadomej decyzji. Pozostanie przy obecnym rozwiązaniu, migracja do Ray Serve albo wybór innego serwera tworzą odmienne modele wsparcia.
AWS Ray Serve Deep Learning Containers konkretyzują jedną z tych opcji. Nowy przykład zapewnia przetestowaną bazę, bezpośredni model programowania i działające wdrożenie EKS z pojedynczym GPU. Uwidacznia także pozostałe obowiązki.
Zacznij od jednej reprezentatywnej usługi TorchServe i przetestuj migrację przy rzeczywistych wzorcach ruchu. Jeśli DLC ograniczy pracę związaną z zależnościami bez osłabiania dostępności, zasługuje na szersze wdrożenie. Jeśli warstwa operacyjna Ray przeważy nad tą korzyścią, test ujawni to wcześnie.
