Uruchamiaj wiele modeli głębokiego uczenia na GPU z wielomodelowymi punktami końcowymi Amazon SageMaker

Wraz ze wzrostem tempa wdrażania sztucznej inteligencji w całej branży klienci tworzą zaawansowane modele, które wykorzystują nowe przełomy naukowe w uczeniu głębokim. Te modele nowej generacji pozwalają osiągnąć najnowocześniejszą, podobną do ludzkiej wydajności w dziedzinach przetwarzania języka naturalnego (NLP), widzenia komputerowego, rozpoznawania mowy, badań medycznych, cyberbezpieczeństwa, przewidywania struktury białek i wielu innych . Na przykład duże modele językowe, takie jak GPT-3, OPT i BLOOM, mogą tłumaczyć, podsumowywać i pisać tekst z niuansami podobnymi do ludzkich. W przestrzeni widzenia komputerowego modele dyfuzji tekstu na obraz, takie jak DALL-E i Imagen, mogą tworzyć fotorealistyczne obrazy z języka naturalnego o wyższym poziomie rozumienia wizualnego i językowego z otaczającego nas świata. Te multimodalne modele zapewniają bogatsze funkcje dla różnych dalszych zadań i możliwość dostosowania ich do określonych domen, a także zapewniają naszym klientom potężne możliwości biznesowe.

Te modele uczenia głębokiego stale rosną pod względem rozmiaru i zazwyczaj zawierają miliardy parametrów modelu w celu skalowania wydajności modelu dla szerokiej gamy zadań, takich jak generowanie obrazów, podsumowywanie tekstu, tłumaczenie języka i nie tylko. Istnieje również potrzeba dostosowania tych modeli, aby zapewnić użytkownikom hiperspersonalizowane wrażenia. W rezultacie powstaje coraz większa liczba modeli poprzez dostrajanie tych modeli do różnych dalszych zadań. Aby spełnić cele dotyczące opóźnień i przepustowości aplikacji AI, instancje GPU są preferowane w stosunku do instancji CPU (biorąc pod uwagę moc obliczeniową oferowaną przez GPU). Jednak wystąpienia GPU są drogie, a koszty mogą się sumować, jeśli wdrażasz więcej niż 10 modeli. Chociaż modele te mogą potencjalnie przynieść znaczące zastosowania sztucznej inteligencji, skalowanie tych modeli uczenia głębokiego w opłacalny sposób może być trudne ze względu na ich rozmiar i liczbę modeli.

Amazon Sage Maker Wielomodelowe punkty końcowe (MME) zapewniają skalowalny i ekonomiczny sposób wdrażania dużej liczby modeli uczenia głębokiego. MME są popularnym wyborem hostingu do hostowania setek modeli opartych na procesorach wśród klientów takich jak Zendesk, Veeva i AT&T. Wcześniej dostępne były ograniczone możliwości wdrażania setek modeli uczenia głębokiego, które wymagały akcelerowanych obliczeń za pomocą procesorów graficznych. Dziś ogłaszamy obsługę MME dla GPU. Teraz możesz wdrożyć tysiące modeli głębokiego uczenia się za jednym punktem końcowym SageMaker. MME mogą teraz uruchamiać wiele modeli na rdzeniu GPU, udostępniać instancje GPU za punktem końcowym w wielu modelach oraz dynamicznie ładować i rozładowywać modele na podstawie ruchu przychodzącego. Dzięki temu możesz znacznie obniżyć koszty i osiągnąć najlepszą wydajność cenową.

W tym poście pokazujemy, jak uruchomić wiele modeli głębokiego uczenia na GPU za pomocą MME SageMaker.

MME SageMakera

SageMaker MME umożliwiają wdrażanie wielu modeli za pojedynczym punktem końcowym wnioskowania, który może zawierać jedną lub więcej instancji. Dzięki MME każda instancja może ładować i obsługiwać wiele modeli. MME umożliwiają przełamanie liniowo rosnących kosztów hostowania wielu modeli i ponownego wykorzystania infrastruktury we wszystkich modelach.

Poniższy diagram ilustruje architekturę MME SageMaker.

SageMaker MME dynamicznie pobiera modele z Usługa Amazon Simple Storage (Amazon S3) po wywołaniu, zamiast pobierania wszystkich modeli przy pierwszym utworzeniu punktu końcowego. W rezultacie początkowe wywołanie modelu może mieć większe opóźnienie wnioskowania niż kolejne wnioskowania, które są kończone z małym opóźnieniem. Jeśli model jest już załadowany do kontenera po wywołaniu, etap pobierania i ładowania jest pomijany, a model zwraca wnioski z małym opóźnieniem. Załóżmy na przykład, że masz model, który jest używany tylko kilka razy dziennie. Jest automatycznie ładowany na żądanie, podczas gdy często używane modele są zachowywane w pamięci i wywoływane z konsekwentnie niskim opóźnieniem.

SageMaker MME z obsługą GPU

SageMaker MME z GPU działa przy użyciu Serwer wnioskowania NVIDIA Triton. Serwer wnioskowania NVIDIA Triton to oprogramowanie typu open source do obsługi wnioskowania, które upraszcza proces wnioskowania i zapewnia wysoką wydajność wnioskowania. Triton obsługuje wszystkie główne platformy szkoleniowe i wnioskowania, takie jak TensorFlow, NVIDIA® TensorRT™, PyTorch, MXNet, Python, ONNX, XGBoost, Scikit-learn, RandomForest, OpenVINO, niestandardowy C++ i inne. Oferuje dynamiczne grupowanie, współbieżne przebiegi, kwantyzację po szkoleniu i optymalną konfigurację modelu w celu uzyskania wysokowydajnego wnioskowania. Dodatkowo, serwer NVIDIA Triton Inference Server został rozszerzony o implementację Umowa MME API, aby zintegrować się z MME.

Poniższy diagram ilustruje przepływ pracy MME.

Kroki przepływu pracy są następujące:

1. SageMaker MME odbiera żądanie wywołania HTTP dla konkretnego modelu za pomocą TargetModel w żądaniu wraz z ładunkiem.
2. SageMaker kieruje ruch do właściwej instancji za punktem końcowym, w którym ładowany jest model docelowy. SageMaker rozumie schemat ruchu we wszystkich modelach MME i inteligentnie kieruje żądania.
3. SageMaker zajmuje się zarządzaniem modelem za punktem końcowym, dynamicznie ładuje model do pamięci kontenera i zwalnia model w oparciu o współdzieloną flotę instancji GPU, aby zapewnić najlepszą wydajność cenową.
4. SageMaker dynamicznie pobiera modele z Amazon S3 do wolumenu pamięci instancji. Jeśli wywołany model nie jest dostępny na woluminie magazynu instancji, model jest pobierany na wolumin magazynu instancji. Jeśli wolumen pamięci instancji osiągnie pojemność, SageMaker usuwa wszystkie nieużywane modele z wolumenu pamięci.
5. SageMaker ładuje model do pamięci kontenera NVIDIA Triton na instancji akcelerowanej przez GPU i obsługuje żądanie wnioskowania. Rdzeń GPU jest współdzielony przez wszystkie modele w instancji. Jeśli model jest już załadowany do pamięci kontenera, kolejne żądania są obsługiwane szybciej, ponieważ SageMaker nie musi go pobierać i ładować ponownie.
6. SageMaker zajmuje się kształtowaniem ruchu do punktu końcowego MME i utrzymuje optymalne kopie modeli na instancjach GPU, aby uzyskać najlepszą wydajność cenową. Kontynuuje kierowanie ruchu do instancji, w której ładowany jest model. Jeśli zasoby instancji osiągną pojemność z powodu wysokiego wykorzystania, SageMaker zwalnia z kontenera najmniej używane modele, aby zwolnić zasoby i załadować częściej używane modele.

SageMaker MME można skalować w poziomie za pomocą zasad automatycznego skalowania i udostępniać dodatkowe instancje obliczeniowe GPU w oparciu o metryki, takie jak wywołania na instancję i wykorzystanie GPU, aby obsłużyć wszelkie wzrosty ruchu na punktach końcowych MME.

Omówienie rozwiązania

W tym poście pokazujemy, jak korzystać z nowych funkcji MME SageMaker z procesorem graficznym w przypadku użycia wizji komputerowej. Do celów demonstracyjnych używamy wstępnie wytrenowanego modelu splotowej sieci neuronowej ResNet-50, który może klasyfikować obrazy na 1,000 kategorii. Omawiamy, jak wykonać następujące czynności:

• Użyj kontenera wnioskowania NVIDIA Triton w MME SageMaker, używając różnych backendów modelu Triton, takich jak PyTorch i TensorRT
• Konwertuj modele ResNet-50 na zoptymalizowany format silnika TensorRT i wdrażaj je za pomocą MME SageMaker
• Skonfiguruj zasady automatycznego skalowania dla MME
• Uzyskaj wgląd w metryki wystąpień i wywołań za pomocą Amazon Cloud Watch

Twórz artefakty modeli

W tej sekcji omówiono etapy przygotowania wstępnie wytrenowanego modelu ResNet-50 do wdrożenia na MME SageMaker przy użyciu konfiguracji modelu Triton Inference Server. Możesz odtworzyć wszystkie kroki za pomocą notatnika krok po kroku na GitHub.

W tym poście zademonstrujemy wdrożenie z dwoma modelami. Możesz jednak przygotować i wdrożyć setki modeli. Modele mogą, ale nie muszą, współdzielić te same ramy.

Przygotuj model PyTorch

Najpierw ładujemy wstępnie przeszkolony model ResNet50 za pomocą pakietu modeli torchvision. Model zapisujemy jako plik model.pt w zoptymalizowanym i serializowanym formacie TorchScript. TorchScript kompiluje przejście do przodu modelu ResNet50 w trybie przyspieszonym z przykładowymi danymi wejściowymi, więc przekazujemy jedno wystąpienie obrazu RGB z trzema kanałami kolorów o wymiarze 224 x 224.

Następnie musimy przygotować modele dla Triton Inference Server. Poniższy kod przedstawia repozytorium modelu dla zaplecza platformy PyTorch. Triton używa pliku model.pt umieszczonego w repozytorium modelu do obsługi prognoz.

resnet
├── 1
│   └── model.pt
└── config.pbtxt

Plik konfiguracyjny modelu config.pbtxt należy podać nazwę modelu (resnet), właściwości platformy i zaplecza (pytorch_libtorch), max_batch_size (128) oraz tensory wejścia i wyjścia wraz z typem danych (TYPE_FP32) Informacja. Dodatkowo możesz określić instance_group i dynamic_batching właściwości, aby uzyskać wnioskowanie o wysokiej wydajności. Zobacz następujący kod:

name: "resnet"
platform: "pytorch_libtorch"
max_batch_size: 128
input {
  name: "INPUT__0"
  data_type: TYPE_FP32
  dims: 3
  dims: 224
  dims: 224
}
output {
  name: "OUTPUT__0"
  data_type: TYPE_FP32
  dims: 1000
}

Przygotuj model TensorRT

NVIDIA TensorRT to zestaw SDK do wysokowydajnego wnioskowania głębokiego uczenia, który zawiera optymalizator wnioskowania głębokiego uczenia i środowisko uruchomieniowe, które zapewniają niskie opóźnienia i wysoką przepustowość dla aplikacji wnioskowania. Używamy narzędzia wiersza poleceń trtexec do wygenerowania serializowanego silnika TensorRT z ONNX format modelu. Wykonaj następujące kroki, aby przekonwertować wstępnie wytrenowany model ResNet-50 na NVIDIA TensorRT:

1. Wyeksportuj wstępnie przeszkolony model ResNet-50 do formatu ONNX za pomocą latarka.onnx.Ten krok uruchamia model jeden raz, aby prześledzić jego przebieg z przykładowymi danymi wejściowymi, a następnie eksportuje prześledzony model do określonego pliku model.onnx.
2. Użyj trtexec, aby utworzyć plan silnika TensorRT z model.onnx plik. Możesz opcjonalnie zmniejszyć precyzję obliczeń zmiennoprzecinkowych, albo po prostu uruchamiając je w 16-bitowych liczbach zmiennoprzecinkowych, albo kwantyzując wartości zmiennoprzecinkowe, aby obliczenia mogły być wykonywane przy użyciu 8-bitowych liczb całkowitych.

Poniższy kod przedstawia strukturę repozytorium modelu dla modelu TensorRT:

resnet
├── 1
│   └── model.plan
└── config.pbtxt

Dla modelu TensorRT określamy tensorrt_plan jako platformę i wprowadź specyfikacje Tensora obrazu o wymiarach 224 x 224, który ma kanały kolorów. Tensor wyjściowy o 1,000 wymiarach jest typu TYPE_FP32, odpowiadające różnym kategoriom obiektów. Zobacz następujący kod:

name: "resnet"
platform: "tensorrt_plan"
max_batch_size: 128
input {
  name: "input"
  data_type: TYPE_FP32
  dims: 3
  dims: 224
  dims: 224
}
output {
  name: "output"
  data_type: TYPE_FP32
  dims: 1000
}
model_warmup {
    name: "bs128 Warmup"
    batch_size: 128
    inputs: {
        key: "input"
        value: {
            data_type: TYPE_FP32
            dims: 3
            dims: 224
            dims: 224
            zero_data: false
        }
    }
}

Przechowuj artefakty modeli w Amazon S3

SageMaker spodziewa się artefaktów modeli w .tar.gz format. Powinny również spełniać wymagania dotyczące pojemników Triton, takie jak nazwa modelu, wersja, config.pbtxt pliki i nie tylko. tar folder zawierający plik modelu jako .tar.gz i prześlij go do Amazon S3:

!mkdir -p triton-serve-pt/resnet/1/
!mv -f workspace/model.pt triton-serve-pt/resnet/1/
!tar -C triton-serve-pt/ -czf resnet_pt_v0.tar.gz resnet
model_uri_pt = sagemaker_session.upload_data(path="resnet_pt_v0.tar.gz", key_prefix="resnet-mme-gpu")
!mkdir -p triton-serve-trt/resnet/1/
!mv -f workspace/model.plan triton-serve-trt/resnet/1/
!tar -C triton-serve-trt/ -czf resnet_trt_v0.tar.gz resnet
model_uri_trt = sagemaker_session.upload_data(path="resnet_trt_v0.tar.gz", key_prefix="resnet-mme-gpu")

Teraz, gdy przesłaliśmy artefakty modeli do Amazon S3, możemy utworzyć MME SageMaker.

Wdrażaj modele za pomocą MME

Obecnie wdrażamy model ResNet-50 z dwoma różnymi backendami frameworka (PyTorch i TensorRT) w MME SageMaker.

Pamiętaj, że możesz wdrożyć setki modeli, a modele mogą korzystać z tej samej struktury. Mogą również korzystać z różnych frameworków, jak pokazano w tym poście.

Używamy AWS SDK dla Pythona (Boto3) Pszczoła utwórz_model, stwórz_konfigurację_punktu końcowego, utwórz_punkt końcowy stworzyć MME.

Zdefiniuj pojemnik do serwowania

W definicji kontenera zdefiniuj model_data_url aby określić katalog S3, który zawiera wszystkie modele używane przez MME SageMaker do ładowania i obsługi prognoz. Ustawić Mode do MultiModel aby wskazać, że SageMaker tworzy punkt końcowy ze specyfikacjami kontenera MME. Ustawiamy kontener z obrazem, który obsługuje wdrażanie MME z GPU. Zobacz następujący kod:

container = {
"Image": ,
"ModelDataUrl": ,
"Mode": "MultiModel"
}

Utwórz obiekt wielomodelowy

Użyj klienta SageMaker Boto3, aby utworzyć model za pomocą create_model API. Definicję kontenera przekazujemy do API tworzenia modelu wraz z ModelName i ExecutionRoleArn:

create_model_response = sm_client.create_model(
    ModelName=, ExecutionRoleArn=role, PrimaryContainer=container
)

Zdefiniuj konfiguracje MME

Utwórz konfiguracje MME za pomocą create_endpoint_config Boto3 API. Określ przyspieszoną instancję obliczeń GPU w InstanceType (używamy typu instancji g4dn.4xlarge). Zalecamy skonfigurowanie punktów końcowych z co najmniej dwiema instancjami. Dzięki temu SageMaker może zapewnić zestaw prognoz o wysokiej dostępności w wielu strefach dostępności dla modeli.

Opierając się na naszych ustaleniach, możesz uzyskać lepszą wydajność cenową na instancjach zoptymalizowanych pod kątem ML z pojedynczym rdzeniem GPU. Dlatego obsługa MME dla funkcji GPU jest włączona tylko dla instancji z jednym rdzeniem GPU. Aby uzyskać pełną listę obsługiwanych instancji, zobacz Obsługiwane typy instancji GPU.

create_endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=,
    ProductionVariants=[
        {
            "InstanceType": "ml.g4dn.4xlarge",
            "InitialVariantWeight": 1,
            "InitialInstanceCount": 2,
            "ModelName": ,
            "VariantName": "AllTraffic",
        }
    ],
)

Utwórz MME

Przy poprzedniej konfiguracji punktu końcowego tworzymy MME SageMaker przy użyciu utwórz_punkt końcowy API. SageMaker tworzy MME, uruchamia instancję obliczeniową ML g4dn.4xlarge i wdraża na nich modele PyTorch i TensorRT ResNet-50. Zobacz następujący kod:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=, EndpointConfigName=
)

Wywołaj model docelowy w MME

Po utworzeniu punktu końcowego możemy wysłać żądanie wnioskowania do MME za pomocą invoke_enpoint API. Określamy TargetModel w wywołaniu wywołania i przekaż ładunek dla każdego typu modelu. Poniższy kod jest przykładowym wywołaniem dla modelu PyTorch i modelu TensorRT:

runtime_sm_client.invoke_endpoint(
    EndpointName=,
    ContentType="application/octet-stream",
    Body=json.dumps(pt_payload),
    TargetModel='resnet_pt_v0.tar.gz', #PyTorch Model
)
runtime_sm_client.invoke_endpoint(
    EndpointName=, 
    ContentType="application/octet-stream", 
    Body=json.dumps(trt_payload),
    TargetModel='resnet_trt_v0.tar.gz' #TensorRT Model
)

Skonfiguruj zasady automatycznego skalowania dla GPU MME

SageMaker MME obsługują automatyczne skalowanie hostowanych modeli. Automatyczne skalowanie dynamicznie dostosowuje liczbę instancji udostępnianych dla modelu w odpowiedzi na zmiany w obciążeniu. Gdy obciążenie wzrasta, automatyczne skalowanie udostępnia więcej instancji w trybie online. Gdy obciążenie spada, automatyczne skalowanie usuwa niepotrzebne wystąpienia, dzięki czemu nie płacisz za aprowizowane wystąpienia, których nie używasz.

W poniższej polityce skalowania używamy niestandardowej metryki GPUUtilization TargetTrackingScalingPolicyConfiguration konfiguracja i ustaw a TargetValue of 60.0 dla wartości docelowej tego wskaźnika. Ta zasada autoskalowania zapewnia dodatkowe wystąpienia do MaxCapacity gdy wykorzystanie GPU przekracza 60%.

auto_scaling_client = boto3.client('application-autoscaling')

resource_id='endpoint/' +  + '/variant/' + 'AllTraffic' 
response = auto_scaling_client.register_scalable_target(
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    MinCapacity=1,
    MaxCapacity=5
)

response = auto_scaling_client.put_scaling_policy(
    PolicyName='GPUUtil-ScalingPolicy',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 60.0, 
        'CustomizedMetricSpecification':
        {
            'MetricName': 'GPUUtilization',
            'Namespace': '/aws/sagemaker/Endpoints',
            'Dimensions': [
                {'Name': 'EndpointName', 'Value':  },
                {'Name': 'VariantName','Value': 'AllTraffic'}
            ],
            'Statistic': 'Average',
            'Unit': 'Percent'
        },
        'ScaleInCooldown': 600,
        'ScaleOutCooldown': 200 
    }
)

Zalecamy użycie GPUUtilization or InvocationsPerInstance aby skonfigurować zasady automatycznego skalowania dla Twojego MME. Aby uzyskać więcej informacji, zobacz Ustaw zasady autoskalowania dla wielomodelowych wdrożeń punktów końcowych

Wskaźniki CloudWatch dla procesorów graficznych MME

SageMaker MME udostępniają następujące metryki na poziomie instancji do monitorowania:

• Liczba załadowanych modeli – Ilość modeli załadowanych do kontenerów
• Wykorzystanie GPU – Procent jednostek GPU używanych przez kontenery
• Wykorzystanie pamięci GPU – Procent pamięci GPU używanej przez kontenery
• Wykorzystanie dysku – Procent przestrzeni dyskowej wykorzystywanej przez kontenery

Te metryki pozwalają zaplanować efektywne wykorzystanie zasobów instancji GPU. Na poniższym wykresie widzimy GPUMemoryUtilization wyniosła 38.3%, gdy do kontenera załadowano ponad 16 modeli ResNet-50. Suma wykorzystania każdego pojedynczego rdzenia procesora (CPUUtilization) wynosił 60.9%, a procent pamięci używanej przez kontenery (MemoryUtilization) wyniósł 9.36%.

SageMaker MME udostępniają również metryki ładowania modelu w celu uzyskania wglądu na poziomie wywołania modelu:

• ModelŁadowanieCzas oczekiwania – Interwał czasowy do pobrania lub załadowania modelu
• Czas Rozładunku Modelu – Interwał czasowy do wyładowania modelu z kontenera
• ModelCzas Pobierania – Czas ściągnąć model z Amazon S3
• ModelCacheHit – Liczba wywołań do modelu, które są już załadowane do kontenera

Na poniższym wykresie możemy zaobserwować, że modelowi zajęło 8.22 sekundy, aby odpowiedzieć na żądanie wnioskowania (ModelLatency) i dodano 24.1 milisekundy do całkowitego opóźnienia ze względu na ogólne koszty programu SageMaker (OverheadLatency). Możemy również zobaczyć wszelkie metryki błędów z wywołań wywołania wywołania API punktu końcowego, takie jak Invocation4XXErrors i Invocation5XXErrors.

Aby uzyskać więcej informacji na temat metryk MME CloudWatch, zobacz Metryki CloudWatch dla wielomodelowych wdrożeń punktów końcowych.

Podsumowanie

W tym poście dowiedziałeś się o nowej obsłudze wielu modeli w programie SageMaker dla GPU, która umożliwia ekonomiczne hostowanie setek modeli głębokiego uczenia na sprzęcie z akceleracją obliczeniową. Dowiedziałeś się, jak korzystać z serwera NVIDIA Triton Inference Server, który tworzy konfigurację repozytorium modelu dla różnych backendów frameworka, oraz jak wdrożyć MME z automatycznym skalowaniem. Ta funkcja umożliwi skalowanie setek hiperspersonalizowanych modeli, które są precyzyjnie dostrojone pod kątem wyjątkowych doświadczeń użytkowników końcowych w aplikacjach AI. Możesz również wykorzystać tę funkcję, aby uzyskać niezbędną wydajność cenową dla aplikacji wnioskowania przy użyciu ułamkowych procesorów GPU.

Aby rozpocząć obsługę MME dla GPU, zobacz Obsługa wielu modeli punktów końcowych dla GPU.

O autorach

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

Vikrama Elango jest starszym architektem rozwiązań AI/ML w Amazon Web Services z siedzibą w Wirginii w USA. Vikram pomaga globalnym klientom z branży finansowej i ubezpieczeniowej w projektowaniu, wdrażaniu i przemyślanym przywództwie w tworzeniu i wdrażaniu aplikacji uczenia maszynowego na dużą skalę. Obecnie koncentruje się na przetwarzaniu języka naturalnego, odpowiedzialnej sztucznej inteligencji, optymalizacji wnioskowania i skalowaniu ML w całym przedsiębiorstwie. W wolnym czasie lubi podróżować, wędrować, gotować i biwakować z rodziną.

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ą.

Deepti Ragha jest inżynierem rozwoju oprogramowania w zespole Amazon SageMaker. Jej obecna praca koncentruje się na budowaniu funkcji do efektywnego hostowania modeli uczenia maszynowego. W wolnym czasie lubi podróżować, wędrować i uprawiać rośliny.

Nihil Kulkarni jest programistą korzystającym z AWS Machine Learning, koncentrującym się na zwiększaniu wydajności obciążeń uczenia maszynowego w chmurze i współtwórcą kontenerów AWS Deep Learning do szkolenia i wnioskowania. Jego pasją są rozproszone systemy głębokiego uczenia. Poza pracą lubi czytać książki, bawić się gitarą i robić pizzę.

Jiahong Liu jest architektem rozwiązań w zespole Cloud Service Provider firmy NVIDIA. Pomaga klientom we wdrażaniu rozwiązań uczenia maszynowego i sztucznej inteligencji, które wykorzystują akcelerowane obliczenia NVIDIA, aby sprostać wyzwaniom związanym ze szkoleniem i wnioskowaniem. W wolnym czasie lubi origami, projekty DIY i grę w koszykówkę.

Eliut Triana jest kierownikiem ds. relacji z programistami w zespole NVIDIA-AWS. Łączy liderów produktów Amazon i AWS, programistów i naukowców z technologami i liderami produktów firmy NVIDIA w celu przyspieszenia obciążeń Amazon ML/DL, produktów EC2 i usług AWS AI. Ponadto Eliuth jest zapalonym kolarzem górskim, narciarzem i pokerzystą.

Maksymilian Maccanti jest głównym inżynierem w AWS, obecnie pracuje w DynamoDB, byłem w zespole startowym SageMaker na re:Invent 2017 i spędziłem kolejne 5 lat na platformie hostingowej, dodając wszelkiego rodzaju funkcje, z którymi borykają się klienci. W wolnym czasie zbieram, naprawiam i gram na starych konsolach do gier wideo.