Amazon MLA-C01: Wdrażanie modeli i inferencja — Przewodnik do nauki
Część AWS Machine Learning Engineer Associate MLA-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.
Punkty końcowe czasu rzeczywistego, bezserwerowe, asynchroniczne i wsadowe — podstawowe koncepcje
Inferencja w czasie rzeczywistym w Amazon SageMaker to stanowy model usługi o niskim opóźnieniu, w którym tworzysz Model, EndpointConfig i Endpoint, który alokuje zasoby obliczeniowe (typy instancji ml.*) i pozostaje dostępny do obsługi żądań za pośrednictwem API InvokeEndpoint. CreateEndpointConfig akceptuje ProductionVariants, a każdy ProductionVariant definiuje ModelName, InitialInstanceCount, InstanceType i InitialVariantWeight; możesz zmieniać ruch i pojemność za pomocą UpdateEndpointWeightsAndCapacities lub UpdateEndpoint. W przypadku przewidywalnych potrzeb o niskim opóźnieniu, alokowane punkty końcowe czasu rzeczywistego są główną opcją i obsługują wielokontenerowe potoki inferencyjne do łączenia kontenerów przetwarzania wstępnego, modelu i przetwarzania końcowego.
Inferencja bezserwerowa (Serverless Inference) eliminuje zarządzanie instancjami i jest konfigurowana na poziomie punktu końcowego za pomocą ServerlessConfig, który określa MemorySizeInMB i MaxConcurrency dla każdego ProductionVariant; SageMaker zarządza alokacją kontenerów i skaluje się do zera w stanie bezczynności, co czyni go idealnym rozwiązaniem dla obciążeń o nieregularnym natężeniu i niskiej przepustowości. Inferencja asynchroniczna (Asynchronous Inference) jest zoptymalizowana pod kątem żądań, których wykonanie zajmuje dużo czasu lub gdy klient nie wymaga synchronicznej odpowiedzi. Asynchroniczny punkt końcowy jest tworzony za pomocą AsyncInferenceConfig w CreateEndpointConfig (OutputConfig z S3OutputPath, opcjonalnym ClientConfig i MaxConcurrentInvocationsPerInstance), a klienci wywołują InvokeEndpointAsync, podając wejściowy URI S3; wyniki są zapisywane w skonfigurowanej lokalizacji wyjściowej S3. Przetwarzanie wsadowe (Batch Transform) to oddzielny typ zadania (CreateTransformJob) dla dużych obciążeń inferencyjnych w trybie offline; API wymaga TransformInput (S3DataSource z S3Uri i S3DataType), TransformOutput (S3OutputPath, Accept, AssembleWith) oraz TransformResources (InstanceType, InstanceCount). Batch Transform jest najlepszym rozwiązaniem, gdy liczy się przepustowość, a nie opóźnienie, i obsługuje dużą równoległość przetwarzania na wielu zbiorach danych.
Punkty końcowe dla wielu modeli, potoki inferencyjne, wdrożenia typu shadow i testy A/B — kluczowe usługi i konfiguracja
W przypadku hostowania wielu modeli o niskim QPS na model, punkty końcowe dla wielu modeli (SageMaker Multi-Model Endpoints, MME) pozwalają jednemu kontenerowi hostować od dziesiątek do tysięcy artefaktów modeli przechowywanych w S3 i ładować je na żądanie. Budujesz kontener serwera modeli, który implementuje wzorzec serwera dla wielu modeli SageMaker lub używasz obsługiwanego obrazu frameworka, przesyłasz spakowane modele (tarballs) do S3 i tworzysz zasób Model, który odwołuje się do kontenera. W momencie wywołania przekazujesz nazwę docelowego modelu za pomocą parametru TargetModel API InvokeEndpoint (lub nagłówka X-Amzn-SageMaker-Target-Model), aby serwer załadował ten model z S3 do pamięci. MME oszczędzają pamięć i koszty operacyjne w przypadku dużych flot modeli, ale dodają opóźnienie zimnego startu dla modeli, które nie są jeszcze załadowane w środowisku wykonawczym.
Potoki inferencyjne są implementowane jako modele wielokontenerowe, w których zasób Model wymienia Containers w określonej kolejności; punkt końcowy kieruje ładunki przez pierwszy kontener (przetwarzanie wstępne), następnie kontener modelu, a na końcu kontener przetwarzania końcowego. Zdefiniuj każdy kontener z własnym ModelDataUrl i zmiennymi środowiskowymi w CreateModel. Do testowania w stylu canary lub blue/green użyj wielu ProductionVariants w EndpointConfig i kontroluj podział ruchu za pomocą InitialVariantWeight, a później za pomocą UpdateEndpointWeightsAndCapacities. Wdrożenie typu shadow (cieniowe) można osiągnąć, wysyłając kopię każdego żądania na warstwie aplikacji do cieniowego punktu końcowego (bez wagi ruchu na produkcyjnym punkcie końcowym) lub tworząc ProductionVariant o niskiej wadze, aby infrastruktura punktu końcowego otrzymywała część lustrzanego ruchu; duplikacja żądań na warstwie aplikacji zapewnia pełną izolację eksperymentu i niezależną obserwowalność.
W celu monitorowania na żądanie i ciągłego, skonfiguruj DataCaptureConfig podczas tworzenia punktu końcowego, aby utrwalać ładunki żądań i odpowiedzi w S3. Interesujące pola DataCaptureConfig to EnableCapture (true), InitialSamplingPercentage, DestinationS3Uri i CaptureOptions (REQUEST, RESPONSE). Przechwycone dane stają się podstawą dla kontroli po wdrożeniu w SageMaker Model Monitor i SageMaker Clarify; możesz tworzyć linie bazowe za pomocą CreateMonitoringSchedule w Model Monitor i uruchamiać zadania Processing ad-hoc, które używają wbudowanego kontenera do monitorowania modeli w celu obliczania ograniczeń i metryk dryftu.
Wzorce projektowe i kompromisy
Wybierz prowizowane punkty końcowe czasu rzeczywistego (provisioned real-time endpoints), gdy potrzebujesz opóźnień rzędu od kilku do kilkunastu milisekund i możesz sobie pozwolić na stale aktywną pojemność. Jeśli głównym ograniczeniem jest koszt za minutę w stanie bezczynności, a ruch jest sporadyczny, bezserwerowe punkty końcowe (serverless endpoints) zmniejszają obciążenie operacyjne: skonfiguruj
undefined
i
undefined
dla każdego wariantu i pozwól SageMaker na automatyczne skalowanie. W przypadku obciążeń z długo trwającymi inferencjami lub wzorcami wymiany dużych payloadów, asynchroniczne punkty końcowe oddzielają cykl życia klienta od zasobów obliczeniowych; wymagają one S3 dla danych wejściowych/wyjściowych i są najbardziej odpowiednie, gdy klienci mogą odpytywać (poll) lub otrzymywać powiadomienia z S3 o zakończeniu zadania.
Punkty końcowe dla wielu modeli (Multi-model endpoints, MME) redukują duplikację pamięci i złożoność zarządzania obiektami S3, ale dodają opóźnienie zimnego startu dla każdego modelu i wymagają serwera modeli zdolnego do ładowania modeli z S3 na żądanie oraz właściwego zarządzania cyklem życia (usuwanie/LRU). Jeśli opóźnienie dla poszczególnych modeli jest krytyczne, hostuj „gorące” modele na dedykowanych ProductionVariants, a modele o niskim ruchu przenieś na MME. Potoki inferencyjne (Inference pipelines) centralizują logikę przetwarzania wstępnego i końcowego bliżej modelu, redukując kod po stronie klienta i zapewniając spójne transformacje między trenowaniem a inferencją, ale zwiększają złożoność uruchamiania punktu końcowego i wymagają solidnego projektu kontraktu kontenera (kodeki wejścia/wyjścia i typy zawartości).
Testy A/B wykorzystujące wagi ProductionVariant są proste w implementacji do podziału ruchu i zbierania metryk offline, ale gdy chcesz dublować ruch (shadowing) bez wpływu na metryki produkcyjne, preferuj mirroring na poziomie aplikacji. W przypadku progresywnych wdrożeń i automatyzacji wycofywania zmian (rollback), zintegruj
undefined
w przepływ pracy CodePipeline lub Step Functions, który obejmuje automatyczną ocenę metryk za pomocą metryk CloudWatch, alertów Model Monitor oraz ręczną akcję zatwierdzania, która warunkuje ostateczną promocję modelu.
Częste błędy i kryteria decyzyjne
Częstym błędem operacyjnym jest założenie, że Model Monitor wykryje problemy z dostępnością etykiet; Model Monitor potrafi wykrywać dryf dystrybucji cech i naruszenia jakości danych na podstawie przechwyconych żądań, ale aby mierzyć degradację metryk opartych na etykietach (F1, recall), musisz dostarczyć etykiety ground-truth z powrotem do S3 w formacie, który zadania monitorujące mogą przetworzyć, i zaplanować zadanie monitorujące, które oblicza porównanie predykcji z rzeczywistością. Kolejną pułapką jest nieodpowiednie dobranie rozmiaru ServerlessConfig.MemorySizeInMB; niewystarczająco alokowana pamięć powoduje dławienie (throttling) lub awarie kontenera, podczas gdy nadmierna alokacja zwiększa koszty. W przypadku punktów końcowych dla wielu modeli, zaniedbanie ustawienia odpowiedniego układu obiektów S3 i cyklu życia (prefiksy, manifesty modeli) spowalnia zimne starty i komplikuje polityki usuwania.
W przypadku nierównowagi klas przy wykrywaniu oszustw, preferuj ważenie natywne dla algorytmu zamiast złożonych potoków próbkowania, aby zminimalizować narzut operacyjny; na przykład XGBoost (kontener SageMaker XGBoost) obsługuje hiperparametr ‘scale_pos_weight’, który obliczasz jako negative_examples/positive_examples i przekazujesz za pomocą mapy hiperparametrów w wywołaniu CreateTrainingJob. Do ręcznego bramkowania wdrożeń użyj SageMaker Model Registry: utwórz ModelPackageGroup, wywołaj CreateModelPackage, aby zarejestrować pakiet modelu i ustaw jego status na PendingManualApproval; zewnętrzna akcja ręcznego zatwierdzania w CodePipeline lub ręczne potwierdzenie przez Step Functions + SNS może następnie wywołać UpdateModelPackage, aby ustawić ApprovalStatus = “Approved” przed uruchomieniem CreateModel lub CreateEndpoint.
Praktyczny problem: Scenariusz użycia
Firma FraudDetectCo buduje system wykrywania oszustw online, który musi konsolidować logi transakcji w S3 oraz lokalne (on-premise) tabele profili klientów w MySQL, trenować model XGBoost, wdrażać go z opóźnieniem bliskim czasu rzeczywistego, wymuszać bramkę ręcznego zatwierdzania dla wydań produkcyjnych oraz wykrywać na żądanie zarówno anomalie w zbiorze danych, jak i dryf modelu.
Agregacja i wstępne przetwarzanie danych: użyj AWS Database Migration Service (DMS) lub konektora JDBC w AWS Glue, aby ciągle replikować lokalne tabele MySQL do S3 (w formacie parquet) lub do jeziora danych opartego na Amazon RDS/zintegrowanego z Athena; skataloguj dane za pomocą AWS Glue i zarejestruj cechy w magazynie offline Amazon SageMaker Feature Store, aby zapewnić spójne wyszukiwanie cech podczas trenowania i serwowania online. Centralizuje to pochodzenie cech i wymusza polityki bezpieczeństwa S3 oraz zarządzanie przez Lake Formation w celu izolacji.
Trenowanie i obsługa nierównowagi klas: uruchom zadania treningowe SageMaker Training, używając wbudowanego kontenera SageMaker XGBoost. Oblicz stosunek etykiet w danych treningowych i ustaw hiperparametr XGBoost “scale_pos_weight” w mapie HyperParameters wywołania CreateTrainingJob, aby zaradzić nierównowadze klas przy minimalnym przetwarzaniu wstępnym. Użyj trybu Pipe dla kanału treningowego (DataSource z S3DataSource i S3DataType ustawionym na S3Prefix, oraz włącz “RecordWrapperType”:“None”, jeśli używasz trybu Pipe), aby skrócić czas uruchomienia i opóźnienie pobierania danych w kolejnych zadaniach.
Rejestr modeli i ręczne zatwierdzanie: rejestruj wytrenowane modele w SageMaker Model Registry, wywołując CreateModelPackage w ramach ModelPackageGroup. Ustaw początkowy ApprovalStatus na PendingManualApproval, zintegruj potok AWS CodePipeline zawierający akcję ręcznego zatwierdzania (AWS Manual Approval action), a po ręcznym potwierdzeniu wywołaj UpdateModelPackage z ApprovalStatus=“Approved” przed promowaniem ModelPackage do środowiska produkcyjnego za pomocą CreateModel i CreateEndpointConfig.
Topologia wdrożenia i wnioskowania: wdróż model na prowizjonowanym punkcie końcowym czasu rzeczywistego w celu uzyskania niskiego opóźnienia podczas oceny (scoring). Jeśli w przyszłości konieczne będzie hostowanie setek modeli, rozważ użycie Multi-Model Endpoint i parametru TargetModel w wywołaniu InvokeEndpoint, aby kierować żądania do konkretnych modeli przechowywanych w S3. Skonfiguruj DataCaptureConfig (EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3://
<bucket>/captures, CaptureOptions=[‘REQUEST’,‘RESPONSE’]), aby zbierać dane żądań i odpowiedzi do analizy na żądanie.Monitorowanie i wykrywanie anomalii: zaplanuj tworzenie linii bazowych (baselines) w SageMaker Model Monitor za pomocą CreateMonitoringSchedule w celu monitorowania jakości danych i dryfu cech. Aby wykrywać anomalie na poziomie zbioru danych i wizualizować je, przekaż przechwycone dane z S3 do Amazon Lookout for Metrics w celu automatycznego wykrywania anomalii oraz do Amazon QuickSight w celu tworzenia pulpitów nawigacyjnych. W celu oceny stronniczości i dryfu na żądanie, uruchom zadania przetwarzania SageMaker Clarify na przechwyconych danych lub uruchom zadanie przetwarzania Model Monitor ad-hoc (za pomocą CreateProcessingJob), które zastosuje zapisane ograniczenia linii bazowej i wygeneruje raport porównawczy.
Uzasadnienie: to podejście centralizuje cechy w celu zapewnienia powtarzalnego trenowania i serwowania z niskim opóźnieniem, wykorzystuje scale_pos_weight w XGBoost do obsługi nierównowagi klas przy minimalnej złożoności potoku, wymusza ręczne zatwierdzanie w Model Registry zintegrowanym z CodePipeline, skraca opóźnienie uruchomienia treningu dzięki użyciu trybu Pipe do strumieniowania danych treningowych oraz zapewnia zarówno automatyczne wykrywanie anomalii (Lookout for Metrics), jak i sprawdzanie sprawiedliwości/dryfu na żądanie (Clarify + Model Monitor) przy użyciu przechwyconych danych z wnioskowania.
← Ewaluacja i wybór modeli · Wszystkie domeny · MLOps i zarządzanie cyklem życia modelu →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →