Wdróż BLOOM-176B i OPT-30B w Amazon SageMaker z wnioskowaniem dużego modelu Deep Learning Containers i DeepSpeed

W ciągu ostatnich kilku lat nastąpił szybki rozwój w dziedzinie uczenia głębokiego. Chociaż sprzęt uległ poprawie, tak jak w przypadku najnowszej generacji akceleratorów firm NVIDIA i Amazon, praktycy zaawansowanego uczenia maszynowego (ML) nadal regularnie napotykają problemy przy wdrażaniu swoich dużych modeli uczenia głębokiego dla aplikacji, takich jak przetwarzanie języka naturalnego (NLP).

We wcześniejszym poście dyskutowaliśmy możliwości i konfigurowalne ustawienia in Wdrożenie modelu Amazon SageMaker co może ułatwić wnioskowanie z tymi dużymi modelami. Dziś ogłaszamy nowy Amazon Sage Maker Kontener głębokiego uczenia (DLC), którego można użyć do rozpoczęcia wnioskowania o dużym modelu w ciągu kilku minut. Ten DLC pakuje jedne z najpopularniejszych bibliotek open-source do równoległego wnioskowania modeli, takie jak DeepSpeed ​​i Hugging Face Accelerate.

W tym poście używamy nowego DLC z wnioskowaniem dużego modelu SageMaker, aby wdrożyć dwa najpopularniejsze duże modele NLP: BigScience's BLOOM-176B i Meta OPT-30B z repozytorium Hugging Face. W szczególności korzystamy z Deep Java Library (DJL) obsługujących i technik równoległości tensorów z DeepSpeed, aby osiągnąć opóźnienie 0.1 sekundy na token w przypadku użycia generowania tekstu.

Nasze kompletne przykładowe notatniki można znaleźć w naszym Repozytorium GitHub.

Techniki wnioskowania na dużych modelach

Modele językowe ostatnio eksplodowały zarówno pod względem wielkości, jak i popularności. Dzięki łatwemu dostępowi z ogrodów zoologicznych modelowych, takich jak Przytulanie twarzy oraz zwiększonej dokładności i wydajności w zadaniach NLP, takich jak klasyfikacja i generowanie tekstu, praktycy coraz częściej sięgają po te duże modele. Jednak duże modele są często zbyt duże, aby zmieścić się w pamięci pojedynczego akceleratora. Na przykład model BLOOM-176B może wymagać ponad 350 gigabajtów pamięci akceleratora, co znacznie przekracza pojemność dostępnych obecnie akceleratorów sprzętowych. Wymaga to użycia technik równoległych modeli z bibliotek, takich jak DeepSpeed ​​i Hugging Face Accelerate, w celu rozłożenia modelu na wiele akceleratorów w celu wnioskowania. W tym poście używamy Duży kontener wnioskowania modelu SageMaker do generowania i porównywania opóźnień i wydajności przy użyciu tych dwóch bibliotek typu open source.

DeepSpeed ​​i Accelerate wykorzystują różne techniki do optymalizacji dużych modeli językowych pod kątem wnioskowania. Kluczową różnicą jest DeepSpeed użycie zoptymalizowanych jąder. Te jądra mogą radykalnie poprawić opóźnienie wnioskowania poprzez zmniejszenie wąskich gardeł na wykresie obliczeniowym modelu. Zoptymalizowane jądra mogą być trudne do opracowania i zazwyczaj są specyficzne dla określonej architektury modelu; DeepSpeed ​​obsługuje popularne duże modele, takie jak OPT i BLOOM, za pomocą tych zoptymalizowanych jąder. W przeciwieństwie do tego, biblioteka Accelerate Hugging Face nie zawiera zoptymalizowanych jąder w momencie pisania. Jak omawiamy w naszej sekcji wyników, ta różnica jest odpowiedzialna za znaczną część przewagi wydajności, jaką ma DeepSpeed ​​nad przyspieszeniem.

Drugą różnicą między DeepSpeed ​​a Accelerate jest rodzaj równoległości modelu. Accelerate wykorzystuje równoległość potokową do podziału modelu między ukryte warstwy modelu, podczas gdy DeepSpeed ​​używa równoległości tensorowej do podziału samych warstw. Równoległość potoków to elastyczne podejście, które obsługuje więcej typów modeli i może poprawić przepustowość, gdy używane są większe rozmiary partii. Równoległość tensorów wymaga większej komunikacji między procesorami graficznymi, ponieważ warstwy modelowe mogą być rozłożone na wiele urządzeń, ale mogą poprawić opóźnienia wnioskowania, angażując jednocześnie wiele procesorów graficznych. Możesz dowiedzieć się więcej o technikach równoległości w Wprowadzenie do równoległości modelu i Równoległość modelu.

Omówienie rozwiązania

Aby skutecznie hostować duże modele językowe, potrzebujemy funkcji i wsparcia w następujących kluczowych obszarach:

• Budowanie i testowanie rozwiązań – Biorąc pod uwagę iteracyjny charakter rozwoju ML, potrzebujemy możliwości budowania, szybkiego iterowania i testowania, jak będzie się zachowywać punkt końcowy wnioskowania, gdy te modele są hostowane, w tym możliwość szybkiego niepowodzenia. Modele te mogą być zazwyczaj hostowane tylko w większych instancjach, takich jak p4dn lub g5, a biorąc pod uwagę rozmiar modeli, rozkręcenie wystąpienia wnioskowania i uruchomienie dowolnej iteracji testowej może zająć trochę czasu. Testowanie lokalne zwykle ma ograniczenia, ponieważ do testowania potrzebujesz podobnego rozmiaru, a te modele nie są łatwe do uzyskania.
• Wdrażanie i uruchamianie na dużą skalę – Pliki modeli muszą być wczytane do instancji wnioskowania, co samo w sobie stanowi wyzwanie, biorąc pod uwagę rozmiar. Tar / Un-Tar jako przykład dla Bloom-176B zajmuje około 1 godziny na utworzenie i kolejną godzinę na załadowanie. Potrzebujemy alternatywnego mechanizmu, aby umożliwić łatwy dostęp do plików modeli.
• Ładowanie modelu jako singleton – W przypadku procesu wieloosobowego musimy upewnić się, że model zostanie załadowany tylko raz, aby nie wpaść w warunki wyścigu i nie wydać niepotrzebnych zasobów. W tym poście pokazujemy sposób ładowania bezpośrednio z Usługa Amazon Simple Storage (Amazonka S3). Działa to jednak tylko wtedy, gdy używamy domyślnych ustawień DJL. Co więcej, wszelkie skalowanie punktów końcowych musi być w stanie uruchomić się w ciągu kilku minut, co wymaga ponownego rozważenia sposobu ładowania i dystrybucji modeli.
• Ramy shardingu – Modele te zazwyczaj muszą być , zwykle za pomocą mechanizmu równoległości tensorów lub fragmentacji potoku jako typowych technik fragmentowania, a my mamy zaawansowane koncepcje, takie jak fragmentowanie Zero, zbudowane na podstawie fragmentowania tensorów. Aby uzyskać więcej informacji o technikach shardingu, zobacz Równoległość modelu. Aby to osiągnąć, możemy mieć różne kombinacje i korzystać z frameworków NIVIDIA, DeepSpeed ​​i innych. Wymaga to możliwości testowania BYOC lub używania kontenerów 1P oraz iteracji rozwiązań i przeprowadzania testów porównawczych. Możesz także przetestować różne opcje hostingu, takie jak asynchroniczne, bezserwerowe i inne.
• Wybór sprzętu – Twój wybór sprzętu zależy od wszystkich wyżej wymienionych punktów i dalszych wzorców ruchu, potrzeb przypadków użycia i rozmiarów modelu.

W tym poście używamy zoptymalizowanych jąder DeepSpeed ​​i technik równoległości tensorów do hostowania BLOOM-176B i OPT-30B na SageMaker. Porównujemy również wyniki programu Accelerate, aby zademonstrować korzyści w zakresie wydajności wynikające ze zoptymalizowanych jąder i równoległości tensorów. Aby uzyskać więcej informacji o DeepSpeed ​​i Accelerate, zobacz DeepSpeed ​​Inference: umożliwienie efektywnego wnioskowania modeli transformatorów na niespotykaną dotąd skalę i Niesamowicie szybkie wnioskowanie BLOOM z DeepSpeed ​​i Accelerate.

W tym przykładzie używamy DJLServing jako rozwiązania do obsługi modelu. DJLServing to wysokowydajne, uniwersalne rozwiązanie obsługujące model, oparte na bibliotece Deep Java Library (DJL), która jest agnostyczna dla języka programowania. Aby dowiedzieć się więcej o DJL i DJLServing, zapoznaj się z Wdrażaj duże modele w Amazon SageMaker za pomocą równoległego wnioskowania modeli DJLServing i DeepSpeed.

Warto zauważyć, że zoptymalizowane jądra mogą skutkować zmianami precyzji i zmodyfikowanym wykresem obliczeń, co teoretycznie może skutkować zmianą zachowania modelu. Chociaż może to czasami zmienić wynik wnioskowania, nie oczekujemy, że te różnice będą miały istotny wpływ na podstawowe metryki oceny modelu. Niemniej jednak zaleca się praktykom, aby podczas korzystania z tych jąder upewnili się, że dane wyjściowe modelu są zgodne z oczekiwaniami.

Poniższe kroki pokazują, jak wdrożyć model BLOOM-176B w programie SageMaker przy użyciu DJLServing i kontenera wnioskowania dużego modelu SageMaker. Kompletny przykład jest również dostępny w naszym Repozytorium GitHub.

Korzystanie z obrazu DLC DJLServing SageMaker

Użyj następującego kodu, aby użyć obrazu DLC DJLServing SageMaker po zastąpieniu regionu określonym regionem, w którym działa notebook:

763104351884.dkr.ecr..amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113
# example uri might be like 763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113

Stwórz nasz plik modelu

Najpierw tworzymy plik o nazwie serving.properties zawierający tylko jeden wiersz kodu. To mówi serwerowi modeli DJL, aby używał silnika DeepSpeed. Plik zawiera następujący kod:

engine=DeepSpeed

serving.properties to plik zdefiniowany przez DJLServing, który służy do konfigurowania konfiguracji dla poszczególnych modeli.

Następnie tworzymy nasze model.py plik, który definiuje kod potrzebny do załadowania, a następnie obsłużenia modelu. W naszym kodzie czytamy w TENSOR_PARALLEL_DEGREE zmienna środowiskowa (wartość domyślna to 1). Ustawia to liczbę urządzeń, na których dystrybuowane są moduły równoległe tensor. Zauważ, że DeepSpeed ​​udostępnia kilka wbudowanych definicji partycji, w tym jedną dla modeli BLOOM. Używamy go, określając replace_method i relpace_with_kernel_inject. Jeśli masz niestandardowy model i potrzebujesz technologii DeepSpeed ​​do efektywnego partycjonowania, musisz zmienić relpace_with_kernel_inject do false i dodać injection_policy aby partycja uruchomieniowa działała. Aby uzyskać więcej informacji, zobacz Inicjowanie dla wnioskowania. W naszym przykładzie użyliśmy wstępnie podzielonego modelu BLOOM na DeepSpeed.

Po drugie, w model.py pliku, ładujemy również model z Amazon S3 po uruchomieniu punktu końcowego. Model jest ładowany do /tmp miejsca na kontenerze, ponieważ SageMaker mapuje /tmp do Sklep Amazon Elastic Block (Amazon EBS) wolumen, który jest montowany, gdy określamy parametr tworzenia punktu końcowego VolumeSizeInGB. W przypadku instancji takich jak p4dn, które są wstępnie zbudowane z instancją woluminu, możemy nadal korzystać z tego /tmp na pojemniku. Zobacz następujący kod:

from djl_python import Input, Output
import os
import deepspeed
import torch
import torch.distributed as dist
import sys
import subprocess
import time
from glob import glob
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer
from transformers.models.opt.modeling_opt import OPTDecoderLayer

predictor = None

def check_config():
    local_rank = os.getenv('LOCAL_RANK')
    
    if not local_rank:
        return False
    return True
    
def get_model():

    if not check_config():
        raise Exception("DJL:DeepSpeed configurations are not default. This code does not support non default configurations") 
    
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model_dir = "/tmp/model"
    bucket = os.environ.get("MODEL_S3_BUCKET")
    key_prefix = os.environ.get("MODEL_S3_PREFIX")
    print(f"rank: {local_rank}")
    if local_rank == 0:
        if f"{model_dir}/DONE" not in glob(f"{model_dir}/*"):
            print("Starting Model downloading files")
            try:
                proc_run = subprocess.run(
                    ["aws", "s3", "cp", "--recursive", f"s3://{bucket}/{key_prefix}", model_dir]
                )
                print("Model downloading finished")
                # write file when download complete. Could use dist.barrier() but this makes it easier to check if model is downloaded in case of retry
                with open(f"{model_dir}/DONE", "w") as f:
                    f.write("download_complete")
                    
                proc_run.check_returncode() # to throw the error in case there was one
                
            except subprocess.CalledProcessError as e:
                print ( "Model download failed: Error:nreturn code: ", e.returncode, "nOutput: ", e.stderr )
                raise # FAIL FAST  
                               
    dist.barrier()
                
    
    tokenizer = AutoTokenizer.from_pretrained(model_dir)
    
    # has to be FP16 as Int8 model loading not yet supported
    with deepspeed.OnDevice(dtype=torch.float16, device="meta"):
        model = AutoModelForCausalLM.from_config(
            AutoConfig.from_pretrained(model_dir), torch_dtype=torch.bfloat16
        )
    model = model.eval()
    
    model = deepspeed.init_inference(
        model,
        mp_size=tensor_parallel,
        dtype=torch.int8,
        base_dir = model_dir,
        checkpoint=os.path.join(model_dir, "ds_inference_config.json"),
        replace_method='auto',
        replace_with_kernel_inject=True
    )

    model = model.module
    dist.barrier()
    return model, tokenizer

DJLServing zarządza instalacją środowiska uruchomieniowego na dowolnych pakietach pip zdefiniowanych w requirement.txt. Ten plik będzie miał:

awscli
boto3

Stworzyliśmy katalog o nazwie code oraz model.py, serving.properties, requirements.txt pliki są już utworzone w tym katalogu. Aby wyświetlić pliki, możesz uruchomić następujący kod z terminala:

mkdir -p code
cat code/model.py 
cat code/serving.properties 
cat code/requirements.txt 

Poniższy rysunek przedstawia strukturę model.tar.gz.

Na koniec tworzymy plik modelu i przesyłamy go do Amazon S3:

tar cvfz model.tar.gz code
s3_code_artifact = sess.upload_data("model.tar.gz", bucket, s3_code_prefix)

Pobierz i zapisz model z Hugging Face (opcjonalnie)

Podaliśmy kroki w tej sekcji na wypadek, gdybyś chciał pobrać model do Amazon S3 i używać go stamtąd. Kroki są dostępne w pliku Jupyter w serwisie GitHub. Poniższy zrzut ekranu przedstawia migawkę kroków.

Stwórz model SageMakera

Teraz tworzymy Model SageMakera. Używamy Rejestr elastycznego pojemnika Amazon (Amazon ECR) obraz dostarczony przez i artefakt modelu z poprzedniego kroku tworzenia modelu SageMaker. W konfiguracji modelu konfigurujemy TENSOR_PARALLEL_DEGREE=8, co oznacza, że ​​model jest podzielony na 8 procesorów graficznych. Zobacz następujący kod:

PrimaryContainer={
        "Image": inference_image_uri,
        "ModelDataUrl": s3_code_artifact,
        "Environment": {
            "MODEL_S3_BUCKET": bucket,
            "MODEL_S3_PREFIX": s3_model_prefix,
            "TENSOR_PARALLEL_DEGREE": "8",
},

Po uruchomieniu poprzedniej komórki w pliku Jupyter zobaczysz dane wyjściowe podobne do następujących:

{
    "ModelArn": "arn:aws:sagemaker:us-east-1::model/bloom-djl-ds-"
}

Utwórz punkt końcowy SageMaker

Do testowania możesz użyć dowolnych instancji z wieloma procesorami graficznymi. W tym demo używamy instancji p4d.24xlarge. W poniższym kodzie zwróć uwagę, jak ustawiamy ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds, VolumeSizeInGB parametry, aby dostosować się do dużego rozmiaru modelu. The VolumeSizeInGB parametr dotyczy instancji GPU obsługujących przyłączenie woluminu EBS.

endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.p4d.24xlarge",
            "InitialInstanceCount": 1,
            #"VolumeSizeInGB" : 200,
            "ModelDataDownloadTimeoutInSeconds": 2400,
            "ContainerStartupHealthCheckTimeoutInSeconds": 2400,
        },
    ],
)'

Na koniec tworzymy punkt końcowy SageMaker:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=f"{endpoint_name}", EndpointConfigName=endpoint_config_name
)

Widzisz to wydrukowane w następującym kodzie:

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1::endpoint/bloom-djl-ds-"
}

Uruchomienie punktu końcowego może trochę potrwać. Możesz spróbować jeszcze kilka razy, jeśli natkniesz się na InsufficientInstanceCapacity błąd lub możesz zgłosić prośbę do AWS o zwiększenie limitu na Twoim koncie.

Podnoszenie wydajności

Jeśli zamierzasz użyć tego posta i towarzyszącego mu notebooka z innym modelem, możesz zapoznać się z niektórymi regulowanymi parametrami oferowanymi przez SageMaker, DeepSpeed ​​i DJL. Iteracyjne eksperymentowanie z tymi parametrami może mieć istotny wpływ na opóźnienie, przepustowość i koszt hostowanego dużego modelu. Aby dowiedzieć się więcej o parametrach dostrajania, takich jak liczba pracowników, stopień równoległości tensorów, rozmiar kolejki zadań i inne, zobacz Konfiguracje obsługi DJL i Wdrażaj duże modele w Amazon SageMaker za pomocą równoległego wnioskowania modeli DJLServing i DeepSpeed.

Efekt

W tym poście wykorzystaliśmy DeepSpeed ​​do hostowania BLOOM-176B i OPT-30B na instancjach SageMaker ML. Poniższa tabela podsumowuje nasze wyniki wydajności, w tym porównanie z Przyspieszeniem Hugging Face. Opóźnienie odzwierciedla liczbę milisekund potrzebnych do czterokrotnego wytworzenia ciągu 256-tokenowego (batch_size=4) z modelu. Przepustowość odzwierciedla liczbę tokenów produkowanych na sekundę dla każdego testu. W przypadku Hugging Face Accelerate użyliśmy domyślnego ładowania biblioteki z mapowaniem pamięci GPU. W przypadku DeepSpeed ​​użyliśmy jego szybszego mechanizmu ładowania punktów kontrolnych.

Z perspektywy latencji DeepSpeed ​​jest około 3.4 razy szybszy dla BLOOM-176B i 5.6 razy szybszy dla OPT-30B niż Accelerate. Zoptymalizowane jądra DeepSpeed ​​są odpowiedzialne za znaczną część tej różnicy w opóźnieniach. Biorąc pod uwagę te wyniki, zalecamy używanie funkcji DeepSpeed ​​over Accelerate, jeśli wybrany model jest obsługiwany.

Warto również zauważyć, że czasy ładowania modeli za pomocą DeepSpeed ​​były znacznie krótsze, co czyni go lepszą opcją, jeśli przewidujesz potrzebę szybkiego skalowania liczby punktów końcowych. Bardziej elastyczna technika równoległości potoków Accelerate może być lepszą opcją, jeśli masz modele lub precyzje modeli, które nie są obsługiwane przez DeepSpeed.

Wyniki te pokazują również różnicę w opóźnieniach i przepustowości różnych rozmiarów modeli. W naszych testach OPT-30B generuje 2.4 razy więcej tokenów na jednostkę czasu niż BLOOM-176B na typie instancji, który jest ponad trzy razy tańszy. Na podstawie ceny jednostkowej przepustowości, OPT-30B w wystąpieniu g5.24xl jest 8.9 razy lepszy niż BLOOM-176B w wystąpieniu p4d.24xl. Jeśli masz ścisłe ograniczenia dotyczące opóźnień, przepustowości lub kosztów, rozważ użycie najmniejszego możliwego modelu, który nadal będzie spełniał wymagania funkcjonalne.

Sprzątać

W ramach najlepszych praktyk zawsze zaleca się usuwanie nieaktywnych instancji. Poniższy kod pokazuje, jak usunąć instancje.

# - Delete the end point
sm_client.delete_endpoint(EndpointName=endpoint_name)

# - In case the end point failed we still want to delete the model
sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name)
sm_client.delete_model(ModelName=model_name)

Opcjonalnie usuń punkt kontrolny modelu z S3

!aws s3 rm --recursive s3:///{s3_model_prefix}

Wnioski

W tym poście pokazaliśmy, jak używać kontenerów wnioskowania dużych modeli SageMaker do obsługi dwóch dużych modeli językowych, BLOOM-176B i OPT-30B. Wykorzystaliśmy techniki równoległego modelu DeepSpeed ​​z wieloma procesorami graficznymi na jednej instancji SageMaker ML.

Aby uzyskać więcej informacji na temat Amazon SageMaker i jego możliwości wnioskowania na dużych modelach, zobacz Amazon SageMaker obsługuje teraz wdrażanie dużych modeli poprzez konfigurowalny rozmiar woluminu i limity czasu i Wnioskowanie w czasie rzeczywistym.

O autorach

Szymon Zamarin jest architektem rozwiązań AI / ML, którego głównym celem jest pomoc klientom w wydobyciu wartości z ich zasobów danych. W wolnym czasie Simon lubi spędzać czas z rodziną, czytając sci-fi i pracując nad różnymi projektami domowymi.

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.

Franek Liu jest inżynierem oprogramowania w AWS Deep Learning. Koncentruje się na budowaniu innowacyjnych narzędzi do głębokiego uczenia się dla inżynierów oprogramowania i naukowców. W wolnym czasie lubi piesze wędrówki z przyjaciółmi i rodziną.

Alana Tana jest starszym menedżerem produktu w firmie SageMaker, która prowadzi prace nad wnioskowaniem na dużych modelach. Pasjonuje go zastosowanie uczenia maszynowego w obszarze Analytics. Poza pracą lubi przebywać na świeżym powietrzu.

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.

QingLan jest inżynierem rozwoju oprogramowania w AWS. Pracował nad kilkoma wymagającymi produktami w Amazon, w tym wysokowydajnymi rozwiązaniami wnioskowania ML i wysokowydajnym systemem rejestrowania. Zespół Qing z powodzeniem uruchomił pierwszy model miliarda parametrów w Amazon Advertising z wymaganym bardzo niskim opóźnieniem. Qing posiada dogłębną wiedzę na temat optymalizacji infrastruktury i akceleracji Deep Learning.

Qingwei Li jest specjalistą ds. uczenia maszynowego w Amazon Web Services. Uzyskał stopień doktora. w badaniach operacyjnych po tym, jak złamał konto grantu naukowego swojego doradcy i nie przekazał obiecanej nagrody Nobla. Obecnie pomaga klientom z branży usług finansowych i ubezpieczeniowych budować rozwiązania machine learning na AWS. W wolnym czasie lubi czytać i uczyć.

Roberta Van Dusena jest starszym menedżerem produktu w Amazon SageMaker. Prowadzi optymalizację modeli uczenia głębokiego dla aplikacji takich jak wnioskowanie na dużych modelach.

Siddhartha Venkatesana jest inżynierem oprogramowania w AWS Deep Learning. Obecnie koncentruje się na budowaniu rozwiązań do wnioskowania na dużych modelach. Przed AWS pracował w Amazon Grocery org, budując nowe funkcje płatności dla klientów na całym świecie. Poza pracą lubi jeździć na nartach, spędzać czas na świeżym powietrzu i oglądać sport.