Zmniejsz koszty wdrażania modeli średnio o 50%, korzystając z najnowszych funkcji Amazon SageMaker | Usługi internetowe Amazona

Wdrażając modele do środowiska produkcyjnego, organizacje nieustannie szukają sposobów optymalizacji wydajności swoich podstawowych modeli (FM) działających na najnowszych akceleratorach, takich jak Inferencja AWS i procesory graficzne, dzięki czemu mogą obniżyć koszty i zmniejszyć opóźnienia w odpowiedzi, aby zapewnić użytkownikom końcowym najlepsze doświadczenia. Jednak niektóre FM nie wykorzystują w pełni akceleratorów dostępnych w instancjach, w których są wdrażane, co prowadzi do nieefektywnego wykorzystania zasobów sprzętowych. Niektóre organizacje wdrażają wiele FM w tej samej instancji, aby lepiej wykorzystać wszystkie dostępne akceleratory, ale wymaga to złożonej orkiestracji infrastruktury, która jest czasochłonna i trudna w zarządzaniu. Gdy wiele FM korzysta z tej samej instancji, każdy FM ma własne potrzeby w zakresie skalowania i wzorce użytkowania, co utrudnia przewidzenie, kiedy należy dodać lub usunąć instancje. Na przykład jeden model może służyć do zasilania aplikacji użytkownika, w której użycie może gwałtownie wzrosnąć w określonych godzinach, podczas gdy inny model może mieć bardziej spójny wzorzec użycia. Oprócz optymalizacji kosztów klienci chcą zapewnić użytkownikom końcowym najlepszą obsługę poprzez zmniejszenie opóźnień. Aby to zrobić, często wdrażają wiele kopii FM, aby równolegle przesyłać żądania użytkowników. Ponieważ dane wyjściowe FM mogą obejmować od jednego zdania do wielu akapitów, czas potrzebny do wykonania żądania wnioskowania jest bardzo zróżnicowany, co prowadzi do nieprzewidywalnych skoków opóźnień, jeśli żądania są kierowane losowo między instancjami. Amazon Sage Maker obsługuje teraz nowe możliwości wnioskowania, które pomagają zmniejszyć koszty wdrożenia i opóźnienia.

Możesz teraz tworzyć punkty końcowe oparte na komponentach wnioskowania i wdrażać modele uczenia maszynowego (ML) w punkcie końcowym SageMaker. Komponent wnioskowania (IC) abstrahuje model ML i umożliwia przypisanie procesorów, procesorów graficznych lub Neuron AWS akceleratory i zasady skalowania na model. Komponenty wnioskowania oferują następujące korzyści:

• SageMaker optymalnie umieści i spakuje modele w instancjach ML, aby zmaksymalizować wykorzystanie, co prowadzi do oszczędności.
• SageMaker przeskaluje każdy model w górę i w dół w oparciu o konfigurację, aby spełnić wymagania aplikacji ML.
• SageMaker będzie skalował się, aby dynamicznie dodawać i usuwać instancje, aby zapewnić dostępność pojemności przy jednoczesnym ograniczeniu do minimum mocy obliczeniowej bezczynności.
• Można skalować w dół do zera kopii modelu, aby zwolnić zasoby dla innych modeli. Możesz także określić, czy ważne modele mają być zawsze załadowane i gotowe do obsługi ruchu.

Dzięki tym funkcjom możesz obniżyć koszty wdrożenia modelu średnio o 50%. Oszczędności będą się różnić w zależności od obciążenia pracą i wzorców ruchu. Weźmy prosty przykład, aby zilustrować, jak pakowanie wielu modeli w jednym punkcie końcowym może zmaksymalizować wykorzystanie i obniżyć koszty. Załóżmy, że masz aplikację do czatowania, która pomaga turystom zrozumieć lokalne zwyczaje i najlepsze praktyki, zbudowaną przy użyciu dwóch wariantów Lamy 2: jednego dostosowanego dla gości z Europy i drugiego dla gości z Ameryki. Oczekujemy ruchu dla modelu europejskiego w godzinach 00:01–11:59 UTC i modelu amerykańskiego w godzinach 12:00–23:59 UTC. Zamiast wdrażać te modele we własnych, dedykowanych instancjach, w których przez połowę czasu będą przestawać działać, możesz teraz wdrożyć je na jednym punkcie końcowym, aby zaoszczędzić koszty. Możesz zmniejszyć skalę modelu amerykańskiego do zera, gdy nie jest to potrzebne, aby zwolnić moce produkcyjne dla modelu europejskiego i odwrotnie. Pozwala to efektywnie wykorzystywać sprzęt i unikać marnotrawstwa. Jest to prosty przykład użycia dwóch modeli, ale można łatwo rozszerzyć ten pomysł, aby spakować setki modeli w jednym punkcie końcowym, który będzie automatycznie skalowany w górę i w dół w zależności od obciążenia.

W tym poście pokażemy nowe możliwości punktów końcowych SageMaker opartych na układach scalonych. Przeprowadzimy Cię również przez proces wdrażania wielu modeli przy użyciu komponentów wnioskowania i interfejsów API. Na koniec szczegółowo opisujemy niektóre nowe możliwości obserwowalności oraz konfigurowania zasad automatycznego skalowania dla modeli i zarządzania skalowaniem instancji dla punktów końcowych. Modele można także wdrażać za pomocą naszego nowego, uproszczonego, interaktywnego interfejsu użytkownika. Obsługujemy również zaawansowane możliwości routingu, aby zoptymalizować opóźnienia i wydajność obciążeń wnioskowania.

Cegiełki

Przyjrzyjmy się bliżej i zrozumiejmy, jak działają te nowe możliwości. Poniżej znajduje się nowa terminologia dotycząca hostingu SageMaker:

• Składnik wnioskowania – Obiekt hostujący SageMaker, którego można użyć do wdrożenia modelu w punkcie końcowym. Można utworzyć komponent wnioskowania, podając następujące informacje:
  • Model SageMaker lub specyfikacja obrazu i artefaktów modelu zgodnych z SageMaker.
  • Oblicz wymagania dotyczące zasobów, które określają potrzeby każdej kopii modelu, w tym rdzeni procesora, pamięci hosta i liczby akceleratorów.
• Kopia modelu – Kopia uruchomieniowa komponentu wnioskowania, która może obsługiwać żądania.
• Automatyczne skalowanie instancji zarządzanej – Możliwość hostingu SageMaker umożliwiająca skalowanie w górę lub w dół liczby instancji obliczeniowych używanych w punkcie końcowym. Skalowanie instancji reaguje na skalowanie komponentów wnioskowania.

Aby utworzyć nowy komponent wnioskowania, możesz określić obraz kontenera i artefakt modelu lub możesz użyć modeli SageMaker, które być może już utworzyłeś. Należy także określić wymagania dotyczące zasobów obliczeniowych, takie jak liczba rdzeni procesora hosta, pamięć hosta lub liczba akceleratorów potrzebnych do uruchomienia modelu.

Podczas wdrażania komponentu wnioskowania można określić MinCopies aby mieć pewność, że model jest już załadowany w wymaganej ilości, gotowy do obsługi żądań.

Masz także możliwość ustawienia zasad w taki sposób, aby komponent wnioskowania kopiował skalę do zera. Na przykład, jeśli nie masz obciążenia działającego na IC, kopia modelu zostanie zwolniona. Może to zwolnić zasoby, które można zastąpić aktywnymi obciążeniami w celu optymalizacji wykorzystania i wydajności punktu końcowego.

W miarę zwiększania się lub zmniejszania żądań wnioskowania liczba kopii układów scalonych może również być skalowana w górę lub w dół w oparciu o zasady automatycznego skalowania. SageMaker zajmie się rozmieszczeniem, aby zoptymalizować pakowanie Twoich modeli pod kątem dostępności i kosztów.

Ponadto, jeśli włączysz automatyczne skalowanie instancji zarządzanych, SageMaker będzie skalować instancje obliczeniowe zgodnie z liczbą komponentów wnioskowania, które muszą zostać załadowane w danym momencie, aby obsłużyć ruch. SageMaker skaluje instancje i spakuje instancje oraz komponenty wnioskowania w celu optymalizacji kosztów przy jednoczesnym zachowaniu wydajności modelu. Chociaż zalecamy korzystanie ze skalowania instancji zarządzanych, możesz także samodzielnie zarządzać skalowaniem, jeśli tak zdecydujesz, za pomocą automatycznego skalowania aplikacji.

SageMaker ponownie zrównoważy komponenty wnioskowania i zmniejszy instancje, jeśli nie będą już potrzebne komponentom wnioskowania, co obniży Twoje koszty.

Opis interfejsów API

SageMaker wprowadził nową jednostkę o nazwie InferenceComponent. To oddziela szczegóły hostowania modelu uczenia maszynowego od samego punktu końcowego. The InferenceComponent umożliwia określenie kluczowych właściwości hosta modelu, takich jak model SageMaker, którego chcesz użyć, lub szczegóły kontenera i artefakty modelu. Określasz także liczbę kopii samych komponentów do wdrożenia oraz liczbę wymaganych akceleratorów (akceleratorów GPU, Inf lub Trn) lub procesorów (vCPU). Zapewnia to większą elastyczność w korzystaniu z jednego punktu końcowego dla dowolnej liczby modeli, które planujesz wdrożyć w nim w przyszłości.

Przyjrzyjmy się wywołaniom API Boto3 w celu utworzenia punktu końcowego z komponentem wnioskowania. Pamiętaj, że istnieją pewne parametry, które omówimy w dalszej części tego postu.

Poniżej znajduje się przykładowy kod dla CreateEndpointConfig:

sagemaker_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, "ModelDataDownloadTimeoutInSeconds": model_data_download_timeout_in_seconds, "ContainerStartupHealthCheckTimeoutInSeconds": container_startup_health_check_timeout_in_seconds, {"ManagedInstanceScaling": { "Status": "ENABLED", "MinInstanceCount": initial_instance_count, "MaxInstanceCount": max_instance_count, } }, }],
)

Poniżej znajduje się przykładowy kod dla CreateEndpoint:

sagemaker_client.create_endpoint( EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name,
)

Poniżej znajduje się przykładowy kod dla CreateInferenceComponent:

sm_client.create_inference_component( InferenceComponentName=inference_component_name, EndpointName=endpoint_name, VariantName=variant_name, Specification={ "Container": { "Image": inference_image_uri, "ArtifactUrl": s3_code_artifact, }, "StartupParameters": { "ModelDataDownloadTimeoutInSeconds": 300, "ContainerStartupHealthCheckTimeoutInSeconds": 600, }, "ComputeResourceRequirements": {"NumberOfAcceleratorDevicesRequired": 1, "MinMemoryRequiredInMb": 1024} }, RuntimeConfig={"CopyCount": 1},
)

To oddzielenie InferenceComponent do punktu końcowego zapewnia elastyczność. Możesz hostować wiele modeli w tej samej infrastrukturze, dodając je lub usuwając w miarę zmiany wymagań. W razie potrzeby każdy model można niezależnie aktualizować. Dodatkowo możesz skalować modele zgodnie z potrzebami biznesowymi. InferenceComponent pozwala także kontrolować wydajność poszczególnych modeli. Innymi słowy, możesz określić, ile kopii każdego modelu ma być hostowanych. To przewidywalne skalowanie pomaga spełnić określone wymagania dotyczące opóźnień dla każdego modelu. Ogólnie, InferenceComponent zapewnia znacznie większą kontrolę nad hostowanymi modelami.

W poniższej tabeli przedstawiamy bezpośrednie porównanie podejścia wysokiego poziomu do tworzenia i wywoływania punktu końcowego bez InferenceComponent i z InferenceComponent. Należy zauważyć, że funkcja CreateModel() jest teraz opcjonalna w przypadku punktów końcowych opartych na układach scalonych.

Wprowadzenie InferenceComponent pozwala na skalowanie na poziomie modelu. Widzieć Zagłęb się w automatyczne skalowanie instancji i układów scalonych aby uzyskać więcej informacji na temat sposobu InferenceComponent działa z automatycznym skalowaniem.

Podczas wywoływania punktu końcowego SageMaker możesz teraz określić nowy parametr InferenceComponentName trafić w żądany InferenceComponentName. SageMaker zajmie się przekierowaniem żądania do instancji obsługującej żądane żądanie InferenceComponentName. Zobacz następujący kod:

smr_client = boto3.client("sagemaker-runtime") response_model = smr_client.invoke_endpoint( InferenceComponentName=inference_component_name, EndpointName=endpoint_name, Body=payload, ContentType="application/json", )

Domyślnie SageMaker wykorzystuje losowe kierowanie żądań do instancji obsługujących punkt końcowy. Jeśli chcesz włączyć routing najmniejszej liczby zaległych żądań, możesz ustawić strategię routingu w konfiguracji punktu końcowego RoutingConfig:

sm_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, ... 'RoutingConfig': { 'RoutingStrategy': 'LEAST_OUTSTANDING_REQUESTS' } }],
)

Najmniej oczekujących żądań kieruje trasy do określonych instancji, które mają większą zdolność do przetwarzania żądań. Zapewni to bardziej jednolite równoważenie obciążenia i wykorzystanie zasobów.

Oprócz CreateInferenceComponentdostępne są teraz następujące interfejsy API:

• DescribeInferenceComponent
• DeleteInferenceComponent
• UpdateInferenceComponent
• ListInferenceComponents

Dzienniki i metryki InferenceComponent

InferenceComponent logi znajdują się w /aws/sagemaker/InferenceComponents/<InferenceComponentName>. Wszystkie logi wysyłane do stderr i stdout w kontenerze są wysyłane do tych logów Amazon Cloud Watch.

Wraz z wprowadzeniem punktów końcowych opartych na układach scalonych istnieje teraz możliwość przeglądania dodatkowych metryk instancji, metryk komponentów wnioskowania i metryk wywołań.

W przypadku instancji SageMaker można teraz śledzić GPUReservation i CPUReservation metryki, aby zobaczyć zasoby zarezerwowane dla punktu końcowego na podstawie wdrożonych komponentów wnioskowania. Te metryki mogą pomóc w dostosowaniu zasad dotyczących punktów końcowych i automatycznego skalowania. Można także wyświetlić zagregowane metryki powiązane ze wszystkimi modelami wdrożonymi w punkcie końcowym.

SageMaker udostępnia także metryki na poziomie komponentu wnioskowania, co pozwala uzyskać bardziej szczegółowy obraz wykorzystania zasobów wdrożonych komponentów wnioskowania. Dzięki temu można uzyskać wgląd w to, jak duże jest zagregowane wykorzystanie zasobów, np GPUUtilizationNormalized i GPUMemoryUtilizationNormalized dla każdego wdrożonego komponentu wnioskowania, który może mieć zero lub wiele kopii.

Na koniec SageMaker udostępnia metryki wywołań, które teraz łącznie śledzą wywołania dla komponentów wnioskowania (Invocations) lub na utworzoną kopię (InvocationsPerCopy)

Aby zapoznać się z pełną listą metryk, zobacz Metryki wywołań punktów końcowych SageMaker.

Automatyczne skalowanie na poziomie modelu

Aby zaimplementować opisane przez nas zachowanie automatycznego skalowania, podczas tworzenia konfiguracji punktu końcowego i komponentu wnioskowania SageMaker należy zdefiniować odpowiednio początkową liczbę instancji i początkową liczbę kopii modelu. Po utworzeniu punktu końcowego i odpowiednich układów scalonych, aby zastosować automatyczne skalowanie na poziomie układu scalonego, należy najpierw zarejestrować cel skalowania, a następnie powiązać politykę skalowania z układem scalonym.

Realizując politykę skalowania, używamy SageMakerInferenceComponentInvocationsPerCopy, czyli nowa metryka wprowadzona przez SageMaker. Przechwytuje średnią liczbę wywołań na kopię modelu na minutę.

aas_client.put_scaling_policy( PolicyName=endpoint_name, PolicyType='TargetTrackingScaling', ServiceNamespace=service_namespace, ResourceId=resource_id, ScalableDimension=scalable_dimension, TargetTrackingScalingPolicyConfiguration={ "PredefinedMetricSpecification": { "PredefinedMetricType": "SageMakerInferenceComponentInvocationsPerCopy", }, "TargetValue": autoscaling_target_value, "ScaleInCooldown": 300, # default "ScaleOutCooldown": 300, # default },
)

Po ustawieniu zasad skalowania SageMaker tworzy dwa alarmy CloudWatch dla każdego celu automatycznego skalowania: jeden uruchamiający skalowanie w poziomie, jeśli występuje alarm przez 3 minuty (trzy 1-minutowe punkty danych), i drugi uruchamiający skalowanie w przypadku alarmu przez 15 minut (15 1-minutowych punktów danych), jak pokazano na poniższym zrzucie ekranu. Czas uruchomienia akcji skalowania jest zwykle o 1–2 minuty dłuższy niż te minuty, ponieważ opublikowanie metryk w CloudWatch przez punkt końcowy zajmuje trochę czasu, a także zajmuje trochę czasu AutoScaling reagować. Okres ostygnięcia to czas (w sekundach) po zakończeniu działania skalowania w poziomie lub w poziomie, zanim będzie można rozpocząć kolejne działanie skalowania w poziomie. Jeśli czas schładzania skalowania w poziomie jest krótszy niż czas aktualizacji punktu końcowego, nie ma to żadnego efektu, ponieważ nie jest możliwa aktualizacja punktu końcowego SageMaker, gdy jest on w trybie Aktualizacja stan.

Pamiętaj, że konfigurując automatyczne skalowanie na poziomie układu scalonego, musisz upewnić się, że MaxInstanceCount parametr jest równy lub mniejszy niż maksymalna liczba układów scalonych, które może obsłużyć ten punkt końcowy. Na przykład, jeśli punkt końcowy jest skonfigurowany tak, aby miał tylko jedną instancję w konfiguracji punktu końcowego, a ta instancja może obsługiwać maksymalnie cztery kopie modelu, wówczas MaxInstanceCount powinna być równa lub mniejsza niż 4. Można jednak także skorzystać z funkcji zarządzanego automatycznego skalowania udostępnianej przez SageMaker, aby automatycznie skalować liczbę instancji na podstawie wymaganej liczby kopii modelu, aby zaspokoić zapotrzebowanie na więcej zasobów obliczeniowych. Poniższy fragment kodu demonstruje, jak skonfigurować skalowanie wystąpień zarządzanych podczas tworzenia konfiguracji punktu końcowego. W ten sposób, gdy automatyczne skalowanie na poziomie układu scalonego wymaga większej liczby instancji do przechowywania kopii modelu, SageMaker automatycznie przeskaluje liczbę instancji, aby umożliwić pomyślne skalowanie na poziomie układu scalonego.

sagemaker_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ExecutionRoleArn=role, ProductionVariants=[{ "VariantName": variant_name, "InstanceType": instance_type, "InitialInstanceCount": initial_instance_count, "ModelDataDownloadTimeoutInSeconds": model_data_download_timeout_in_seconds, "ContainerStartupHealthCheckTimeoutInSeconds": container_startup_health_check_timeout_in_seconds, {"ManagedInstanceScaling": { "Status": "ENABLED", "MinInstanceCount": initial_instance_count, "MaxInstanceCount": max_instance_count, } }, }],
)

Możesz zastosować wiele zasad automatycznego skalowania w odniesieniu do tego samego punktu końcowego, co oznacza, że ​​będziesz mógł zastosować tradycyjne zasady automatycznego skalowania do punktów końcowych utworzonych za pomocą układów scalonych oraz skalować w górę i w dół w oparciu o inne metryki punktu końcowego. Aby uzyskać więcej informacji, zobacz Zoptymalizuj wdrożenia uczenia maszynowego dzięki automatycznemu skalowaniu w Amazon SageMaker. Jednak mimo że jest to możliwe, nadal zalecamy używanie skalowania wystąpień zarządzanych zamiast samodzielnego zarządzania skalowaniem.

Wnioski

W tym poście wprowadziliśmy nową funkcję w wnioskowaniu SageMaker, która pomoże zmaksymalizować wykorzystanie instancji obliczeniowych, skalować do setek modeli i zoptymalizować koszty, zapewniając jednocześnie przewidywalną wydajność. Ponadto udostępniliśmy przewodnik po interfejsach API i pokazaliśmy, jak skonfigurować i wdrożyć komponenty wnioskowania dla obciążeń.

Wspieramy również zaawansowane możliwości routingu aby zoptymalizować opóźnienia i wydajność obciążeń wnioskowania. SageMaker może pomóc w optymalizacji obciążeń wnioskowania pod kątem kosztów i wydajności oraz zapewnić szczegółowość zarządzania na poziomie modelu. Stworzyliśmy zestaw notesów który pokaże Ci, jak wdrożyć trzy różne modele, używając różnych kontenerów i stosując zasady automatycznego skalowania w GitHub. Zachęcamy Cię do rozpoczęcia od notebooka 1 i już dziś zapoznaj się z nowymi możliwościami hostingu SageMaker!

O autorach

James Park jest architektem rozwiązań w Amazon Web Services. Współpracuje z Amazon.com przy projektowaniu, budowaniu i wdrażaniu rozwiązań technologicznych w AWS, a szczególnie interesuje się sztuczną inteligencją i uczeniem maszynowym. W wolnym czasie lubi szukać nowych kultur, nowych doświadczeń i być na bieżąco z najnowszymi trendami technologicznymi. Znajdziesz go na LinkedIn.

Melanie Li, PhD, jest starszym specjalistą TAM AI/ML w AWS z siedzibą w Sydney w Australii. Pomaga klientom korporacyjnym budować rozwiązania przy użyciu najnowocześniejszych narzędzi AI/ML w AWS i zapewnia wskazówki dotyczące projektowania i wdrażania rozwiązań ML z wykorzystaniem najlepszych praktyk. W wolnym czasie uwielbia poznawać przyrodę oraz spędzać czas z rodziną i przyjaciółmi.

Marek Karp jest architektem ML w zespole Amazon SageMaker Service. Koncentruje się na pomaganiu klientom w projektowaniu, wdrażaniu i zarządzaniu obciążeniami ML na dużą skalę. W wolnym czasie lubi podróżować i odkrywać nowe miejsca.

Alana Tana jest starszym menedżerem produktu w firmie SageMaker, kierując pracami nad wnioskowaniem na dużych modelach. Pasjonuje go zastosowanie uczenia maszynowego w obszarze analityki. Poza pracą lubi przebywać na świeżym powietrzu.

Raghu Ramesza jest starszym architektem rozwiązań ML w zespole Amazon SageMaker Service. Koncentruje się na pomaganiu klientom w budowaniu, wdrażaniu i migracji obciążeń produkcyjnych ML do SageMaker na dużą skalę. Specjalizuje się w uczeniu maszynowym, sztucznej inteligencji i wizji komputerowej. Posiada tytuł magistra informatyki na Uniwersytecie UT Dallas. W wolnym czasie lubi podróżować i fotografować.

Rozbijacz Grewal jest Sr Ai/ML Specialist Solutions Architect z AWS. Obecnie skupia się na serwowaniu modeli i MLOpów na SageMakerze. Wcześniej pracował jako inżynier ds. uczenia maszynowego budując i hostując modele. Poza pracą lubi grać w tenisa i jeździć na rowerze po górskich szlakach.

Dawal Patel jest głównym architektem uczenia maszynowego w AWS. Pracował z organizacjami od dużych przedsiębiorstw po średniej wielkości start-upy w zakresie problemów związanych z przetwarzaniem rozproszonym i sztuczną inteligencją. Koncentruje się na uczeniu głębokim, w tym w domenach NLP i Computer Vision. Pomaga klientom uzyskać wnioskowanie o wysokiej wydajności modelu w SageMaker.

Saurabha Trikande jest starszym menedżerem produktu w firmie Amazon SageMaker Inference. Pasjonuje go praca z klientami i motywuje go cel, jakim jest demokratyzacja uczenia maszynowego. Koncentruje się na podstawowych wyzwaniach związanych z wdrażaniem złożonych aplikacji ML, wielodostępnych modeli ML, optymalizacji kosztów oraz zwiększaniem dostępności wdrażania modeli uczenia głębokiego. W wolnym czasie Saurabh lubi wędrować, poznawać innowacyjne technologie, śledzić TechCrunch i spędzać czas z rodziną.

Lakszmi Ramakrysznana jest głównym inżynierem w zespole platformy Amazon SageMaker Machine Learning (ML) w AWS, zapewniając techniczne przywództwo w zakresie produktu. Przez ponad 9 lat pracował na kilku stanowiskach inżynieryjnych w Amazon. Posiada tytuł licencjata w dziedzinie technologii informatycznych uzyskany w National Institute of Technology w Karnatace w Indiach oraz tytuł magistra informatyki uzyskany na Uniwersytecie Minnesota Twin Cities.

Dawid Nigenda jest starszym inżynierem ds. rozwoju oprogramowania w zespole Amazon SageMaker, obecnie pracującym nad udoskonaleniem przepływów pracy w zakresie uczenia maszynowego w środowisku produkcyjnym, a także nad uruchomieniem nowych funkcji wnioskowania. W wolnym czasie stara się dotrzymać kroku swoim dzieciom.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/machine-learning/reduce-model-deployment-costs-by-50-on-average-using-sagemakers-latest-features/