Amazon MLS-C01: Wdrażanie, wnioskowanie i serwowanie (implementacja i operacje ML) — Przewodnik do nauki

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Część AWS Machine Learning Specialty MLS-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Wzorce wdrażania i opcje serwowania

Wybór sposobu serwowania modelu to kompromis między latencją, kosztem, przepustowością i złożonością operacyjną. Punkty końcowe SageMaker działające w czasie rzeczywistym (provisioned lub serverless) zapewniają latencję od poniżej 100 ms do kilku sekund, odpowiednią dla interaktywnych API; wybierz rodziny instancji, takie jak ml.c5/m5 dla modeli CPU, ml.g4dn lub ml.p3 dla modeli GPU, lub ml.inf1 dla taniej i wysokoprzepustowej inferencji na układach Inferentia. Inferencja asynchroniczna (Asynchronous Inference) i Batch Transform są odpowiednie dla przypadków użycia z dużymi wsadami (large-batch) lub zmienną latencją: Batch Transform jest idealny do dużych zadań offline (podziel duże obiekty S3 na fragmenty (shards) i w razie potrzeby użyj instancji ml.m5/c5 lub GPU), podczas gdy SageMaker Asynchronous Inference obsługuje większe ładunki (payloads) z kolejkowaniem dla przetwarzania wsadowego bliskiego czasowi rzeczywistemu (near-real-time). Punkty końcowe typu multi-model (Multi-model endpoints) hostują wiele modeli w jednym kontenerze, zmniejszając narzut na przechowywanie (storage overhead) dzięki ładowaniu modeli na żądanie; działają najlepiej, gdy modele są małe, mają niewielki koszt zimnego startu (cold-start), a wzorce dostępu są rzadkie (sparse). Wybierz SageMaker Serverless Inference dla nieprzewidywalnych obciążeń o niskiej przepustowości, aby uniknąć zarządzania instancjami; uważaj na zimne starty (cold starts) i ograniczony czas działania. Kluczowe kryteria decyzyjne obejmują SLO dotyczące latencji, koszt pojedynczego wywołania, wzorzec współbieżności, rozmiar modelu i tolerancję na zimny start. Częstą pułapką jest używanie punktów końcowych czasu rzeczywistego do przetwarzania wsadowego o bardzo dużej skali — jest to kosztowne; zamiast tego użyj Batch Transform, Async Inference lub wywołuj punkty końcowe z wykorzystaniem batchingu i współbieżnych workerów.

Skalowanie, kształtowanie ruchu i optymalizacja kosztów

Autoskalowanie, przesuwanie ruchu (traffic shifting) i kontrola kosztów muszą być projektowane wspólnie z topologią wdrożenia. Użyj Application Auto Scaling do skalowania wariantów punktów końcowych SageMaker za pomocą polityk śledzenia celu (target-tracking policies) opartych na metrykach wywołań lub niestandardowych metrykach CloudWatch; zdefiniuj rozsądne minimalne/maksymalne pojemności (min/max capacities) i okresy wyciszenia (cooldowns), aby uniknąć gwałtownych zmian (thrashing). Dla wdrożeń typu blue/green i canary rollouts użyj punktów końcowych z wieloma wariantami (multi-variant endpoints) lub aktualizacji EndpointConfig z procentowym podziałem ruchu i stopniowym jego zwiększaniem; zintegruj z AWS CodeDeploy, aby zautomatyzować przesuwanie ruchu. Optymalizacje kosztów obejmują przycinanie modelu (pruning), kwantyzację (FP16 lub int8), kompilację za pomocą SageMaker Neo lub AWS Neuron dla instancji Inf1 oraz przenoszenie obciążeń niewrażliwych na latencję do Batch Transform lub inferencji serverless. Instancje Spot obniżają koszty treningu, ale nie mają zastosowania do punktów końcowych czasu rzeczywistego; zamiast tego dobieraj odpowiedni rozmiar instancji (right-sizing) (CPU vs GPU vs Inferentia) i w stosownych przypadkach konsoliduj modele za pomocą punktów końcowych typu multi-model. Uważaj na pułapki, takie jak nadmierne alokowanie zasobów (over-provisioning) przy użyciu śledzenia celu bez zrozumienia przepustowości pojedynczej instancji, lub zakładanie, że punkty końcowe multi-model eliminują limity pamięci — ładowanie modelu wciąż wymaga pamięci i może zwiększyć latencję. Kompresuj również artefakty modeli (ONNX, TF SavedModel za pomocą gz) i stosuj strategie leniwego ładowania (lazy-loading), aby skrócić czas przechowywania i zimnego startu.

Edge, inferencja o niskiej latencji i umiejscowienie pre/post-processingu

Dla środowisk o ultraniskiej latencji lub działających w trybie offline wdrażaj modele na AWS IoT Greengrass (v2) lub użyj SageMaker Edge Manager do pakowania i monitorowania modeli na urządzeniach brzegowych (edge devices); kompiluj za pomocą SageMaker Neo lub komponentów AWS IoT Greengrass i stosuj kwantyzację, aby sprostać ograniczeniom pamięci/CPU. Umieść wstępne przetwarzanie (preprocessing) i ekstrakcję cech (feature extraction) tam, gdzie minimalizuje to całkowitą latencję (end-to-end) i koszt: proste filtry mogą działać w oprogramowaniu układowym (firmware) urządzenia lub w Greengrass Lambda, natomiast batching i ciężkie transformacje powinny być realizowane na bramie brzegowej (edge gateway) lub w chmurze. Dla strumieniowych okien zdarzeń (np. 10-minutowe okna przesuwne), pozyskuj dane za pomocą Amazon Kinesis Data Streams lub Amazon MSK, użyj Kinesis Data Analytics lub Flink/Apache Spark do tworzenia okien (windowing) i agregacji, a następnie przesyłaj zagregowane cechy do punktu końcowego SageMaker lub lekkiego modelu na urządzeniu brzegowym (on-edge) — zmniejsza to ruch wychodzący z sieci (network egress) i częstotliwość wywołań modelu. Uważaj na pułapki, takie jak ignorowanie wersjonowania modeli na urządzeniach brzegowych lub niezapewnienie wystarczającej ilości pamięci masowej na urządzeniu na artefakty modeli. W przypadku mikroserwisów po stronie serwera, umieść preprocessing w tej samej lokalizacji (colocate) (API Gateway + Lambda lub ALB + Fargate), aby uniknąć narzutu związanego z zimnym wywołaniem (cold-call overhead) i zmniejszyć rozmiar ładunków (payloads) wysyłanych do modelu.

Monitorowanie, audyt, zarządzanie i obsługa danych

Operacjonalizacja ML wymaga ciągłego monitorowania kondycji modelu i zarządzania danymi. Użyj SageMaker Model Monitor do stworzenia linii bazowej (baseline) dla danych treningowych za pomocą DataQualityJob i skonfiguruj ciągłe monitorowanie w celu wykrywania dryfu danych, regresji jakości modelu, brakujących wartości i niestandardowych ograniczeń; włącz DataCaptureConfig na punktach końcowych (endpoints), aby przechwytywać dane wejściowe/wyjściowe do S3 i uruchamiać zadania Model Monitor. Aby śledzić pochodzenie danych (lineage) i prowadzić audyt na poziomie cech (features), użyj Amazon SageMaker Feature Store (magazyny online i offline) w połączeniu z AWS Glue Data Catalog i CloudTrail do śledzenia dostępu do zbiorów danych i ich transformacji; Amazon Macie oraz zadania przetwarzania Glue/SageMaker Processing mogą wykrywać i redagować dane osobowe (PII) przed treningiem. Pułapki związane z szyfrowaniem obejmują SSE-KMS: gdy obiekty S3 są szyfrowane za pomocą klucza zarządzanego przez klienta (customer-managed CMK), upewnij się, że rola wykonawcza SageMaker (execution role) ma uprawnienia kms:Decrypt i kms:GenerateDataKey, a polityka klucza CMK przyznaje dostęp; upewnij się również, że polityki bucketów S3 i punkty końcowe VPC nie blokują dostępu. W przypadku dużych dziennych obiektów S3 (np. 100 GB) unikaj pozyskiwania danych w jednym pliku — podziel je na wiele mniejszych obiektów, przechowuj w formacie Parquet z kompresją i używaj Athena/Glue do wykrywania schematu. Częste pułapki to niewystarczająco częste harmonogramy monitorowania, nieutworzenie prawidłowej linii bazowej dla Model Monitor oraz zapominanie o przyznaniu dostępu do KMS wszystkim podmiotom usługowym (service principals) (SageMaker, Glue, Lambda), które potrzebują uprawnień do deszyfracji.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Streamlytic Media prowadzi platformę do analityki podcastów na AWS. Używają Kinesis Data Streams do pozyskiwania zdarzeń użytkowników, przechowują zagregowane cechy w S3 i hostują modele w SageMaker do przewidywania zaangażowania w czasie rzeczywistym. Dane sporadycznie zawierają dane osobowe (PII) i są szyfrowane za pomocą klucza zarządzanego przez klienta w SSE-KMS.

Wyzwanie: Zapewnienie predykcji o niskim opóźnieniu na podstawie kroczącego 10-minutowego okna zdarzeń, redakcja danych osobowych (PII) przed treningiem modelu, zapewnienie, że SageMaker może odczytywać zaszyfrowane dane z S3, oraz wdrożenie ciągłego monitorowania dryfu cech.

Zalecane podejście:

1. Utwórz strumień Kinesis Data Stream do pozyskiwania zdarzeń, uruchom Kinesis Data Analytics (Flink) do utrzymywania kroczących 10-minutowych okien i emituj zagregowane cechy do S3 w formacie Parquet z partycjonowaniem cogodzinnym.
2. Wykryj i zredaguj dane osobowe (PII) używając Amazon Macie do ich odkrycia oraz zadania SageMaker Processing (lub zadania AWS Glue) do zastosowania deterministycznej redakcji/tokenizacji; przechowuj wyniki w magazynie offline Feature Store na potrzeby treningu.
3. Nadaj roli wykonawczej SageMaker uprawnienia kms:Decrypt i kms:GenerateDataKey do klucza CMK, dodaj tę rolę do polityki klucza CMK i upewnij się, że polityka bucketu S3 lub punkt końcowy VPC zezwala na dostęp dla SageMaker.
4. Wdróż model jako punkt końcowy czasu rzeczywistego SageMaker na instancjach ml.inf1, włącz DataCaptureConfig, utwórz linię bazową (baseline) dla Model Monitor na podstawie danych treningowych i skonfiguruj ciągłe monitorowanie z alertami do CloudWatch.

Uzasadnienie: Agregacja strumieniowa za pomocą Kinesis + Flink minimalizuje wolumen zdarzeń i opóźnienia; redakcja danych na etapie przetwarzania zapewnia prywatność i zgodność z regulacjami; jawne uprawnienia KMS zapobiegają błędom dostępu; punkty końcowe oparte na instancjach Inferentia i usługa Model Monitor równoważą niski koszt inferencji z obserwowalnością operacyjną.

← Trenowanie · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →