Amazon MLA-C01: Optymalizacja kosztów dla obciążeń ML — 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.
Podstawowa koncepcja: skąd biorą się koszty i jakie masz możliwości ich optymalizacji
Koszt obciążeń roboczych uczenia maszynowego (ML) wynika z trzech podstawowych kategorii: mocy obliczeniowej do trenowania i wnioskowania, przechowywania i transferu danych dla zbiorów danych i punktów kontrolnych (checkpoints) oraz kosztów operacyjnych wynikających z niewykorzystanej lub źle zaopatrzonej infrastruktury. Trenowanie jest często największą pojedynczą pozycją kosztową, gdy trenujesz duże modele lub przeprowadzasz wiele eksperymentów. Koszt wnioskowania dominuje, gdy udostępniasz modele na dużą skalę lub wymagasz niskich opóźnień dla aplikacji interaktywnych. Główne dźwignie optymalizacji to wybór rodziny i rozmiaru instancji, opcje zakupu (on-demand vs Spot vs Savings Plans), wzorce cyklu życia modelu (przetwarzanie wsadowe vs. czas rzeczywisty vs. serverless) oraz optymalizacje środowiska uruchomieniowego, takie jak kompilacja modelu, buforowanie i konsolidacja instancji.
Techniki operacyjne przekładają te dźwignie na praktykę. Używaj zarządzanego trenowania Spot (managed Spot training) z punktami kontrolnymi (checkpointing), aby obniżyć koszty obliczeniowe trenowania nawet o 70% w porównaniu z instancjami on-demand, ale połącz je z checkpointingiem (parametr CheckpointConfig → S3Uri w CreateTrainingJob) i flagą EnableManagedSpotTraining ustawioną na true w CreateTrainingJob, aby zadania mogły być wznawiane po przerwaniu. Dobieraj odpowiedni rozmiar instancji (right-sizing), profilując rzeczywiste zużycie CPU/GPU/IO (metryki CloudWatch, takie jak GPUUtilization, HostCPUUtilization i ślady profilera z SageMaker Debugger), a następnie przełączaj się na rodziny instancji obliczeniowych pasujące do charakterystyki obciążenia (ml.c5/ml.c6 dla CPU, ml.g5/ml.p4 dla GPU, ml.r5 dla zadań wymagających dużej ilości pamięci). W przypadku wnioskowania preferuj modele o kosztach proporcjonalnych do użycia: używaj wnioskowania serverless (wariant produkcyjny w CreateEndpointConfig z ServerlessConfig → MemorySizeInMB i MaxConcurrency) dla obciążeń o nieregularnym, niskim natężeniu ruchu; używaj punktów końcowych dla wielu modeli (multi-model endpoints) lub kompilacji modeli (SageMaker Neo), aby zmniejszyć wymagania dotyczące instancji dla wielu małych modeli; a duże lub niewrażliwe na opóźnienia obciążenia przenieś do transformacji asynchronicznych lub wsadowych (AsyncInferenceConfig i Batch Transform).
Kluczowe usługi i konfiguracja
Amazon SageMaker udostępnia jawne mechanizmy kontroli kosztów. Aby obniżyć koszty trenowania, używaj zarządzanego trenowania Spot: w API CreateTrainingJob ustaw EnableManagedSpotTraining=true, dołącz CheckpointConfig.S3Uri i ustaw MaxWaitTimeInSeconds > MaxRuntimeInSeconds, aby umożliwić pozyskanie pojemności Spot. W SageMaker Python SDK możesz ustawić estimator.use_spot_instances=True, estimator.max_wait oraz estimator.checkpoint_s3_uri na lokalizację punktu kontrolnego w S3. Aby uzyskać powtarzalne, niskie opóźnienia w kolejnych zadaniach trenowania, utrzymuj kontenery w stanie „ciepłym” (warm), wykorzystując SageMaker Processing lub trenując kontenery na stałej, zaopatrzonej infrastrukturze, gdy wymaga tego tempo eksperymentowania; w przeciwnym razie skróć czas uruchamiania kontenerów, używając mniejszych obrazów kontenerów, gotowych kontenerów SageMaker lub ponownie wykorzystując stałą instancję treningową w środowisku deweloperskim.
Do kontroli kosztów wnioskowania, CreateEndpointConfig/UpdateEndpointConfig obsługuje wiele strategii. Użyj ServerlessConfig w ProductionVariants, aby pozwolić SageMaker zarządzać skalowaniem i rozliczać za wywołanie i pamięć, a nie za pełne godziny pracy instancji; ServerlessConfig wymaga podania wartości MemorySizeInMB i MaxConcurrency. Dla stabilnych obciążeń o dużej przepustowości używaj instancji Provisioned i stosuj polityki śledzenia celu (target tracking) Application Auto Scaling do punktu końcowego, aby uniknąć nadmiernego alokowania zasobów (over-provisioning). Punkty końcowe dla wielu modeli (Multi-model endpoints) redukują koszty, gdy hostujesz wiele rzadko używanych modeli, dzięki współdzieleniu jednego kontenera i ładowaniu artefaktów modeli z S3 na żądanie. Aby uzyskać rekomendacje dotyczące doboru zasobów dla modelu, wywołaj CreateInferenceRecommendationsJob w usłudze Inference Recommender, która dostarcza wskazówek dotyczących typu instancji, rozmiaru partii (batch size) oraz opóźnień/przepustowości.
Zobowiązania rozliczeniowe najlepiej obsługiwać za pomocą SageMaker Savings Plans lub AWS Compute Savings Plans. Kup Savings Plan za pośrednictwem konsoli AWS Billing, aby zobowiązać się do wydatków na poziomie $/godzinę w okresie 1 roku lub 3 lat; daje to zniżkę na zasoby obliczeniowe SageMaker on-demand (trenowanie i hosting) we wszystkich rodzinach instancji. Pamiętaj, że Savings Plans dotyczą użycia on-demand i nie mają zastosowania do instancji Spot, dlatego łącz strategie: kupuj Savings Plans dla bazowego, stałego zużycia, a instancji Spot używaj do nieregularnych lub eksperymentalnych zadań trenowania.
Wzorce projektowe i kompromisy
Wzorzec zarządzanych instancji Spot z checkpointingiem to podstawowe rozwiązanie dla długich lub dużych rozproszonych zadań treningowych. Wymaga on minimalnych zmian w kodzie: włączenia EnableManagedSpotTraining, podania CheckpointConfig.S3Uri i ustawienia odpowiedniej wartości MaxWaitTimeInSeconds w celu tolerowania harmonogramowania instancji Spot. Kompromisem jest złożoność ponownego uruchamiania i nieco dłuższy całkowity czas wykonania (wall-clock time), jeśli przerwania instancji Spot są częste; zyskiem jest natomiast radykalna redukcja kosztów. W przypadku iteracyjnych eksperymentów, gdzie opóźnienie startowe (startup latency) między kolejnymi zadaniami jest kluczowe, należy utrzymywać „ciepłe” środowisko deweloperskie: używać mniejszych, alokowanych instancji ml.m5 lub ml.c5 z wstępnie załadowanymi danymi na NVMe/lokalnym cache lub uruchamiać wiele eksperymentów jako lokalne zadania przetwarzania na tej samej instancji za pomocą SageMaker Processing lub notatników Studio. Zwiększa to koszt bazowy, ale skraca całkowity czas cyklu.
W przypadku inferencji należy wybierać między endpointami serwerowymi (serverless) a alokowanymi (provisioned) w zależności od charakterystyki ruchu. Inferencja serwerowa (ServerlessConfig) eliminuje potrzebę planowania pojemności i jest najtańsza dla sporadycznego, nieprzewidywalnego ruchu, ponieważ płaci się za każde wywołanie i alokację pamięci. Kompromisem jest opóźnienie zimnego startu (cold start latency) i limity rozmiaru; w przypadku ścisłych umów SLA dotyczących niskich opóźnień (low-latency) preferowane są instancje alokowane z autoskalowaniem. Warto też rozważyć optymalizację modelu za pomocą SageMaker Neo w celu zmniejszenia liczby instancji. Gdy trzeba hostować wiele modeli, ale ruch na każdy z nich jest niski, endpointy wielomodelowe (multi-model endpoints) konsolidują użycie dysku i pamięci oraz obniżają koszt na model kosztem nieco dłuższego ładowania przy zimnym starcie dla niezaładowanego modelu.
Dobór odpowiedniego rozmiaru (right-sizing) powinien opierać się na obserwacji, a nie na zgadywaniu. Użyj profilowania SageMaker Debugger oraz CloudWatch do zbierania metryk GPUUtilization i DiskReadOps; następnie uruchom zadanie Inference Recommender (CreateInferenceRecommendationsJob), aby zweryfikować klasę/typ instancji i wydajność. Jeśli wymagania dotyczące opóźnień modelu są rygorystyczne, rozważ kwantyzację modelu, kompilację za pomocą SageMaker Neo lub użycie akceleratorów Elastic Inference, aby dołączyć ułamkową moc GPU do inferencji na instancjach CPU. Elastic Inference pozwala dołączyć mały akcelerator do instancji CPU, zmniejszając koszt w porównaniu do pełnych instancji GPU dla niektórych modeli.
Częste pułapki i kryteria decyzyjne
Częstym błędem jest stosowanie jednej metody optymalizacji kosztów do wszystkich obciążeń roboczych. Savings Plans są potężnym narzędziem dla stałego, bazowego wykorzystania, ale powinny być łączone z instancjami Spot dla obciążeń eksperymentalnych i architekturą serverless dla wnioskowania o charakterze skokowym. Nie należy zakładać, że instancje Spot są darmowe — wymagają one checkpointingu i logiki treningu odpornej na przerwy; należy skonfigurować CreateTrainingJob.CheckpointConfig i EnableManagedSpotTraining oraz obliczyć MaxWaitTimeInSeconds, który odzwierciedla, jak długo akceptujemy opóźnienie w uruchomieniu zadania. Kolejną pułapką jest zaniedbywanie telemetrii: bez profilowania (za pomocą SageMaker Debugger, CloudWatch i Inference Recommender) ryzykujesz nadmierne alokowanie zasobów (over-provisioning) lub wybór rodziny instancji o niedopasowanej charakterystyce CPU, GPU i pamięci. Wreszcie, wnioskowanie w trybie serverless upraszcza koszty, ale może wprowadzać nieprzewidywalne zimne starty (cold starts); należy mierzyć opóźnienie end-to-end podczas korzystania z ServerlessConfig i w przypadku rygorystycznych umów SLA powrócić do endpointów z alokowanymi zasobami (provisioned) i autoskalowaniem.
Praktyczny problem: Scenariusz użycia
Firma: FinSight Analytics. Wyzwanie: FinSight musi zbudować potok (pipeline) do wykrywania oszustw, który często trenuje się na logach transakcji i profilach klientów przechowywanych w S3, utrzymuje izolację danych, wspiera zarządzanie wersjami modeli z ręcznym zatwierdzaniem przed wdrożeniem produkcyjnym, redukuje koszty treningu dla codziennych nocnych zadań, minimalizuje opóźnienie startowe dla poszczególnych zadań podczas szybkiej eksperymentacji oraz obsługuje endpoint czasu rzeczywistego o niskim opóźnieniu, z uwzględnieniem wrażliwości kosztowej na skokowy ruch.
Scentralizowane, bezpieczne repozytorium danych i modeli. Przechowuj dane w zabezpieczonym buckecie S3 z domyślnym szyfrowaniem i politykami bucketu, które ograniczają dostęp do roli wykonawczej SageMaker. Rejestruj modele w SageMaker Model Registry; użyj kroku
RegisterModelw SageMaker Pipelines, aby tworzyć pakiety modeli zModelApprovalStatusdomyślnie ustawionym na „PendingManualApproval”. Zaimplementuj przepływ pracy wymagający ręcznego zatwierdzenia, tworząc potok SageMaker Pipeline, który generuje pakiet modelu i krok ręcznego zatwierdzenia; gdy upoważnieni recenzenci zakończą walidację, wywołująboto3 sagemaker.update_model_package(ModelPackageName=..., ModelApprovalStatus='Approved'), aby zezwolić na wdrożenie. Uzasadnienie: Model Registry zapewnia scentralizowane wersjonowanie, aModelApprovalStatusintegruje się bezpośrednio z API SageMaker, minimalizując potrzebę niestandardowych operacji.Efektywny kosztowo codzienny nocny trening. Użyj zarządzanego treningu na instancjach Spot (managed Spot training), tworząc zadania treningowe z
EnableManagedSpotTraining=true, dołączCheckpointConfig.S3Uri, aby utrwalać stan optymalizatora, i ustaw odpowiednioMaxRuntimeInSecondsorazMaxWaitTimeInSeconds, aby zadania mogły być wznawiane po przerwaniach instancji Spot. Połącz to z zakupem bazowego planu Savings Plan o wielkości pokrywającej średnie zużycie godzin on-demand na trening i wnioskowanie, aby zredukować stałe koszty, a instancji Spot używaj do eksperymentów, gdzie przerwy są dopuszczalne. Uzasadnienie: Zarządzany trening Spot redukuje koszty obliczeniowe przy minimalnych zmianach w kodzie; Savings Plans mają zastosowanie do bazowego wykorzystania on-demand, obniżając przewidywalne wydatki.Redukcja opóźnienia startowego podczas eksperymentacji. Dla interaktywnych cykli eksperymentalnych utrzymuj stały profil instancji deweloperskiej (np.
ml.c5lubml.m5) w SageMaker Studio lub małą, dedykowaną instancję Notebook z wstępnie załadowanymi zbiorami danych na EBS/NVMe i ponownie wykorzystuj to środowisko do wielu szybkich przebiegów treningowych. Dla produkcyjnych zadań nocnych nadal używaj zarządzanego treningu Spot z checkpointingiem. Uzasadnienie: Stałe środowisko pozwala uniknąć zimnych startów kontenerów i poprawia szybkość iteracji, jednocześnie zachowując oszczędności kosztowe dla ciężkich zadań.Obsługa w czasie rzeczywistym o niskim opóźnieniu i wrażliwości na koszty. Wdróż zatwierdzony model na alokowanym (provisioned) endpoincie, aby uzyskać bazowe niskie opóźnienie, i dołącz do niego politykę Application Auto Scaling w celu skalowania w dół poza godzinami szczytu. Dla nieprzewidywalnych skoków ruchu zastosuj opcję wnioskowania Serverless dla modeli o małym wolumenie lub użyj wnioskowania asynchronicznego (
AsyncInferenceConfigzS3 OutputConfig) dla ciężkich zadań scoringu wsadowego, które nie wymagają działania w czasie rzeczywistym. Zastosuj kompilację SageMaker Neo do modelu przed wdrożeniem, aby zmniejszyć jego zapotrzebowanie na zasoby CPU/GPU. Uzasadnienie: Połączenie alokowanych zasobów z autoskalowaniem zapewnia stałe niskie opóźnienie i kontrolę kosztów; endpointy serverless lub asynchroniczne obsługują skokowe lub wsadowe obciążenia w sposób bardziej efektywny kosztowo, a Neo zmniejsza wymagania dotyczące instancji.
Takie podejście łączy EnableManagedSpotTraining z CheckpointConfig w celu redukcji kosztów treningu, SageMaker Model Registry i UpdateModelPackage do obsługi ręcznych zatwierdzeń, stałą instancję deweloperską dla zmniejszenia opóźnienia startowego oraz mieszankę modeli alokowanych (provisioned), serverless i skompilowanych w celu optymalizacji kosztów wnioskowania.
← Generatywna AI i modele fundamentalne · Wszystkie domeny · Wizja komputerowa →
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 →