Uzyskaj hosting o niskich opóźnieniach dla modeli ML opartych na drzewie decyzyjnym na serwerze NVIDIA Triton Inference Server na Amazon SageMaker

Wdrożenia modelu uczenia maszynowego (ML) mogą mieć obecnie bardzo wysokie wymagania dotyczące wydajności i opóźnień dla dzisiejszych firm. Przypadki użycia, takie jak wykrywanie oszustw i umieszczanie reklam, to przykłady, w których milisekundy mają znaczenie i mają kluczowe znaczenie dla sukcesu firmy. Muszą być spełnione rygorystyczne umowy SLA, a typowe żądanie może wymagać wielu kroków, takich jak wstępne przetwarzanie, transformacja danych, logika wyboru modelu, agregacja modelu i przetwarzanie końcowe. Na dużą skalę często oznacza to utrzymywanie ogromnego natężenia ruchu przy zachowaniu niskich opóźnień. Typowe wzorce projektowe obejmują szeregowe potoki wnioskowania, zespoły (scatter-gather) i przepływy pracy logiki biznesowej, które skutkują realizacją całego przepływu pracy żądania jako ukierunkowanego wykresu acyklicznego (DAG). Jednak ponieważ przepływy pracy stają się bardziej złożone, może to prowadzić do wydłużenia ogólnego czasu odpowiedzi, co z kolei może negatywnie wpłynąć na wrażenia użytkownika końcowego i zagrozić celom biznesowym. Triton może rozwiązać te przypadki użycia, w których wiele modeli jest skomponowanych w potoku z połączonymi między sobą tensorami wejściowymi i wyjściowymi, pomagając w rozwiązaniu tych obciążeń.

Oceniając swoje cele w odniesieniu do wnioskowania o modelu ML, można rozważyć wiele opcji, ale niewiele z nich jest tak skutecznych i sprawdzonych, jak Amazon Sage Maker w Serwer wnioskowania Triton. SageMaker z Triton Inference Server jest popularnym wyborem dla wielu klientów, ponieważ został zaprojektowany w celu maksymalizacji przepustowości i wykorzystania sprzętu przy bardzo niskich (jednocyfrowych milisekundach) opóźnieniach wnioskowania. Posiada szeroką gamę obsługiwanych platform ML (w tym TensorFlow, PyTorch, ONNX, XGBoost i NVIDIA TensorRT) oraz infrastruktury zaplecza, w tym procesory graficzne NVIDIA, procesory i Inferencja AWS. Ponadto Triton Inference Server jest zintegrowany z SageMaker, w pełni zarządzaną, kompleksową usługą ML, zapewniającą opcje wnioskowania w czasie rzeczywistym na potrzeby hostingu modeli.

W tym poście omówimy wdrażanie zestawu do wykrywania oszustw w programie SageMaker z Triton Inference Server.

Omówienie rozwiązania

Niezbędne jest, aby każdy projekt miał listę wymagań i oszacowanie nakładu pracy w celu przybliżenia całkowitego kosztu projektu. Ważne jest, aby oszacować zwrot z inwestycji (ROI), który wspiera decyzję organizacji. Niektóre kwestie, które należy wziąć pod uwagę przy przenoszeniu obciążenia do Triton, obejmują:

Szacowanie nakładu pracy ma kluczowe znaczenie w tworzeniu oprogramowania, a jego pomiar często opiera się na niekompletnych, niepewnych i zaszumionych danych wejściowych. Obciążenia ML nie różnią się. Wiele czynników wpływa na architekturę wnioskowania ML, z których niektóre obejmują:

• Budżet opóźnień po stronie klienta – Określa maksymalny akceptowalny czas oczekiwania w obie strony po stronie klienta na odpowiedź wnioskowania, zwykle wyrażany w percentylach. W przypadku obciążeń, które wymagają budżetu na opóźnienia rzędu dziesiątek milisekund, transfery sieciowe mogą stać się drogie, więc lepszym rozwiązaniem byłoby użycie modeli na brzegu.
• Rozmiar dystrybucji ładunku danych – Ładowność, często określana jako treść wiadomości, to dane żądania przesyłane od klienta do modelu, a także dane odpowiedzi przesyłane z modelu do klienta. Rozmiar ładunku często ma duży wpływ na opóźnienie i należy go wziąć pod uwagę.
• Format danych – Określa, w jaki sposób ładunek jest wysyłany do modelu ML. Format może być czytelny dla człowieka, taki jak JSON i CSV, jednak istnieją również formaty binarne, które często są skompresowane i mają mniejszy rozmiar. Jest to kompromis między obciążeniem kompresji a rozmiarem transferu, co oznacza, że ​​cykle procesora i opóźnienia są dodawane do kompresji lub dekompresji, aby zaoszczędzić bajty przesyłane przez sieć. Ten post pokazuje, jak korzystać zarówno z formatu JSON, jak i binarnego.
• Wymagany stos oprogramowania i komponenty – Stos to zbiór komponentów, które współpracują ze sobą w celu obsługi aplikacji ML, w tym systemu operacyjnego, środowisk wykonawczych i warstw oprogramowania. Triton ma wbudowane popularne frameworki ML, zwane backendy, takich jak ONNX, TensorFlow, FIL, OpenVINO, natywny Python i inne. Możesz także napisać niestandardowy backend dla Twoich własnych komponentów. Ten post dotyczy modelu XGBoost i wstępnego przetwarzania danych, które migrujemy odpowiednio do backendów FIL i Python Triton dostarczonych przez firmę NVIDIA.

Wszystkie te czynniki powinny odgrywać istotną rolę w ocenie wydajności obciążeń, ale w tym przypadku koncentrujemy się na pracy potrzebnej do przeniesienia modeli ML do hostowania w programie SageMaker z serwerem Triton Inference Server. W szczególności używamy przykładu zespołu wykrywania oszustw składającego się z modelu XGBoost z logiką przetwarzania wstępnego napisaną w Pythonie.

Serwer wnioskowania NVIDIA Triton

Triton Inference Server został zaprojektowany od podstaw, aby umożliwić zespołom wdrażanie, uruchamianie i skalowanie przeszkolonych modeli sztucznej inteligencji z dowolnej struktury na infrastrukturze opartej na GPU lub CPU. Ponadto został zoptymalizowany, aby oferować wysokowydajne wnioskowanie na dużą skalę dzięki funkcjom takim jak dynamiczne grupowanie, współbieżne uruchomienia, optymalna konfiguracja modelu, zespół modelu i obsługa strumieniowych danych wejściowych.

Poniższy diagram przedstawia przykładowy potok zespołu NVIDIA Triton.

Obciążenia powinny uwzględniać możliwości oferowane przez Triton wraz z hostingiem SageMaker, aby zmaksymalizować oferowane korzyści. Na przykład Triton obsługuje zarówno HTTP, jak i Interfejs API języka C, które zapewniają elastyczność, a także optymalizację ładunku w razie potrzeby. Jak wcześniej wspomniano, Triton obsługuje kilka popularnych platform, w tym TensorFlow, PyTorch, ONNX, XGBoost i NVIDIA TensorRT. Te frameworki są obsługiwane przez backendy Triton, a w rzadkich przypadkach, gdy backend nie obsługuje twojego przypadku użycia, Triton pozwala na wdrożenie własnego i łatwą integrację.

Poniższy diagram przedstawia przykład architektury NVIDIA Triton.

NVIDIA Triton w SageMakerze

Hosting SageMaker usługi to zestaw funkcji programu SageMaker, których celem jest ułatwienie wdrażania i obsługi modeli. Zapewnia różnorodne opcje łatwego wdrażania, automatycznego skalowania, monitorowania i optymalizacji modeli ML dostosowanych do różnych przypadków użycia. Oznacza to, że można zoptymalizować wdrożenia pod kątem wszystkich typów wzorców użycia, od trwałych i zawsze dostępnych z opcjami bezserwerowymi po przejściowe, długotrwałe lub wsadowe potrzeby wnioskowania.

W ramach hostingu SageMaker znajduje się również zestaw wnioskowania SageMaker Deep Learning Containers (DLC), które są dostarczane z odpowiednim oprogramowaniem serwera modelowego dla odpowiedniej obsługiwanej struktury ML. Umożliwia to uzyskanie wysokiej wydajności wnioskowania bez konfiguracji serwera modelu, co często jest najbardziej złożonym aspektem technicznym wdrażania modelu i ogólnie nie jest częścią zestawu umiejętności analityka danych. Serwer wnioskowania Triton jest teraz dostępny w DLC SageMaker.

Ten szeroki zakres opcji, modułowość i łatwość użycia różnych frameworków obsługujących sprawia, że ​​SageMaker i Triton to potężne połączenie.

Obsługa zaplecza NVIDIA FIL

Z 22.05 wydanie wersji Triton, NVIDIA obsługuje teraz modele lasów trenowane przez kilka popularnych platform ML, w tym XGBoost, LightGBM, Scikit-learn i cuML. Korzystając z zaplecza FIL dla Triton, należy upewnić się, że dostarczane artefakty modelu są obsługiwane. Na przykład FIL obsługuje model_type xgboost, xgboost_json, lightgbmlub treelite_checkpoint, wskazując, czy dostarczony model jest odpowiednio w formacie binarnym XGBoost, formacie XGBoost JSON, formacie tekstowym LightGBM czy formacie binarnym Treelite.

Ta obsługa backendu jest dla nas niezbędna w naszym przykładzie, ponieważ FIL obsługuje modele XGBoost. Jedyną kwestią do sprawdzenia jest upewnienie się, że wdrażany przez nas model obsługuje formaty binarne lub JSON.

Oprócz upewnienia się, że masz odpowiedni format modelu, należy wziąć pod uwagę inne kwestie. Backend FIL dla Triton zapewnia konfigurowalne opcje dla programistów, aby dostroić swoje obciążenia i zoptymalizować wydajność uruchamiania modelu. Konfiguracja dynamic_batching umożliwia Tritonowi przechowywanie żądań po stronie klienta i grupowanie ich po stronie serwera, w celu efektywnego wykorzystania obliczeń równoległych FIL do wnioskowania o całej partii razem. Opcja max_queue_delay_microseconds oferuje bezawaryjną kontrolę nad tym, jak długo Triton czeka na uformowanie partii. FIL jest dostarczany z wyjaśniaczem Shapley, który można aktywować przez konfigurację treeshap_output; należy jednak pamiętać, że dane wyjściowe Shapley obniżają wydajność ze względu na ich rozmiar. Innym ważnym aspektem jest storage_type w celu kompromisu między zużyciem pamięci a środowiskiem wykonawczym. Na przykład użycie pamięci masowej jako SPARSE może zmniejszyć zużycie pamięci, podczas gdy DENSE może zmniejszyć wydajność działania modelu kosztem większego użycia pamięci. Wybór najlepszego wyboru dla każdego z nich zależy od obciążenia pracą i budżetu na opóźnienia, dlatego zalecamy dokładniejsze przyjrzenie się wszystkim opcjom w Często zadawane pytania dotyczące zaplecza FIL oraz lista konfiguracji dostępnych w FIL.

Kroki, aby hostować model na trytonie

Spójrzmy na nasz przypadek użycia wykrywania oszustw jako przykład tego, co należy wziąć pod uwagę przy przenoszeniu obciążenia do Triton.

Określ swoje obciążenie pracą

W tym przypadku użycia mamy do czynienia z modelem wykrywania oszustw używanym podczas procesu realizacji transakcji klienta detalicznego. Potok wnioskowania używa algorytmu XGBoost z logiką przetwarzania wstępnego, która obejmuje przygotowanie danych do przetwarzania wstępnego.

Zidentyfikuj aktualne i docelowe wskaźniki wydajności oraz inne cele, które mogą mieć zastosowanie

Może się okazać, że czas wnioskowania od końca do końca trwa zbyt długo, aby był akceptowalny. Twoim celem może być przejście z dziesiątek milisekund opóźnienia do jednocyfrowego opóźnienia dla tej samej liczby żądań i odpowiedniej przepustowości. Ustalasz, że większość czasu zajmuje wstępne przetwarzanie danych i model XGBoost. Inne czynniki, takie jak rozmiar sieci i ładunku, odgrywają minimalną rolę w narzutach związanych z czasem wnioskowania od końca do końca.

Pracuj wstecz, aby określić, czy Triton może obsługiwać Twoje obciążenie w oparciu o Twoje wymagania

Aby określić, czy Triton może spełnić Twoje wymagania, należy zwrócić uwagę na dwa główne obszary zainteresowania. Pierwszym z nich jest upewnienie się, że Triton może służyć z akceptowalną opcją interfejsu, taką jak HTTP lub C API.

Jak wspomniano wcześniej, bardzo ważne jest również ustalenie, czy Triton obsługuje backend, który może obsługiwać Twoje artefakty. Triton obsługuje wiele backendy które są dostosowane do obsługi różnych platform, takich jak PyTorch i TensorFlow. Sprawdź, czy Twoje modele są obsługiwane i czy masz odpowiedni format modelu, którego oczekuje Triton. Aby to zrobić, najpierw sprawdź, jakie formaty modeli obsługuje backend Triton. W wielu przypadkach nie wymaga to żadnych zmian w modelu. W innych przypadkach model może wymagać przekształcenia do innego formatu. W zależności od formatu źródłowego i docelowego istnieją różne opcje, takie jak przekształcenie Plik pickle Pythona do korzystania z binarnego formatu punktów kontrolnych Treelite.

W tym przypadku użycia określamy Zaplecze FIL może obsługiwać model XGBoost bez konieczności wprowadzania zmian i że możemy korzystać z Zaplecze Pythona do wstępnego przetwarzania. Dzięki funkcji zespołu Triton możesz jeszcze bardziej zoptymalizować obciążenie pracą, unikając kosztownych połączeń sieciowych między instancjami hostingowymi.

Utwórz plan i oszacuj nakład pracy wymagany do korzystania z Triton do hostingu

Porozmawiajmy o planie przeniesienia Twoich modeli do Tritona. Każde wdrożenie Triton wymaga:

• Modelowe artefakty wymagane przez backendy Triton
• Pliki konfiguracyjne Triton
• Folder repozytorium modelu o odpowiedniej strukturze

W dalszej części tego wpisu pokazujemy przykład tworzenia tych zależności wdrażania.

Uruchom plan i zweryfikuj wyniki

Po utworzeniu wymaganych plików i artefaktów w repozytorium modeli o odpowiedniej strukturze należy dostroić wdrożenie i przetestować je, aby sprawdzić, czy osiągnięto już docelowe metryki.

W tym momencie możesz użyć Polecający wnioskowanie SageMaker aby określić, jaki typ wystąpienia punktu końcowego jest dla Ciebie najlepszy w oparciu o Twoje wymagania. Ponadto Triton zapewnia narzędzia do optymalizacji kompilacji w celu uzyskania lepszej wydajności.

Realizacja

Przyjrzyjmy się teraz szczegółom implementacji. W tym celu przygotowaliśmy dwa zeszyty, które stanowią przykład tego, czego można się spodziewać. The pierwszy notatnik przedstawia uczenie danego modelu XGBoost oraz logikę przetwarzania wstępnego, która jest używana zarówno do uczenia, jak i czasu wnioskowania. The drugi notatnik pokazuje, jak przygotowujemy artefakty potrzebne do wdrożenia na Tritonie.

Pierwszy notatnik pokazuje istniejący notatnik, który posiada Twoja organizacja, który używa KATARAKTY NA RZECE zestaw bibliotek i jądro RAPIDS Conda. To wystąpienie działa na typie wystąpienia G4DN dostarczonym przez AWS, który jest akcelerowany przez GPU przy użyciu procesorów NVIDIA T4.

Zadania przetwarzania wstępnego w tym przykładzie korzystają z akceleracji GPU i intensywnie korzystają z bibliotek cuML i cuDF. Przykładem tego jest poniższy kod, w którym pokazujemy kodowanie etykiet kategorycznych za pomocą cuML. Generujemy również label_encoders.pkl plik, którego możemy użyć do serializacji koderów i użyć ich do przetwarzania wstępnego w czasie wnioskowania.

Pierwszy notatnik kończy się szkoleniem naszego modelu XGBoost i odpowiednim zapisaniem artefaktów.

W tym scenariuszu kod szkolenia już istniał i nie są potrzebne żadne zmiany modelu w czasie szkolenia. Dodatkowo, chociaż używaliśmy akceleracji GPU do wstępnego przetwarzania podczas uczenia, planujemy użyć procesorów do wstępnego przetwarzania w czasie wnioskowania. Więcej wyjaśnimy w dalszej części postu.

Przejdźmy teraz do drugiego notatnika i przypomnijmy, czego potrzebujemy do pomyślnego wdrożenia Triton.

Najpierw potrzebujemy artefaktów modelu wymaganych przez backendy. Pliki, które musimy stworzyć dla tego zespołu to:

• Artefakty przetwarzania wstępnego (model.py, label_encoders.pkl)
• Artefakty modelu XGBoost (xgboost.json)

Backend Pythona w Triton wymaga od nas użycia środowiska Conda jako zależności. W tym przypadku używamy backendu Pythona do wstępnego przetwarzania nieprzetworzonych danych przed wprowadzeniem ich do modelu XGBoost uruchamianego w backendzie FIL. Mimo że pierwotnie używaliśmy bibliotek RAPIDS cuDF i cuML do wstępnego przetwarzania danych (jak wspomniano wcześniej przy użyciu naszego GPU), tutaj używamy Pandas i Scikit-learn jako zależności wstępnego przetwarzania dla czasu wnioskowania (przy użyciu naszego procesora). Robimy to z trzech powodów:

• Aby pokazać, jak stworzyć środowisko Conda dla swoich zależności i jak je spakować w oczekiwany format przez backend Tritona w Pythonie.
• Pokazując model przetwarzania wstępnego działający w zapleczu Pythona na procesorze, podczas gdy model XGBoost działa na GPU w zapleczu FIL, zilustrujemy, w jaki sposób każdy model potoku ensemble Triton może działać na innym zapleczu frameworka i na innym sprzęcie z różnymi konfiguracje.
• Podkreśla, w jaki sposób biblioteki RAPIDS (cuDF, cuML) są kompatybilne z ich odpowiednikami CPU (Pandas, Scikit-learn). W ten sposób możemy pokazać jak LabelEncoders utworzone w cuML mogą być używane w Scikit-learn i vice-versa. Zwróć uwagę, że jeśli spodziewasz się wstępnie przetworzyć duże ilości danych tabelarycznych w czasie wnioskowania, nadal możesz użyć RAPID-ów do akceleracji GPU.

Przypomnijmy, że stworzyliśmy label_encoders.pkl plik w pierwszym zeszycie. Nie ma nic więcej do zrobienia w przypadku kodowania kategorii poza włączeniem go do naszego model.py plik do wstępnego przetworzenia.

Aby utworzyć plik model.py wymagany przez backend Triton Python, przestrzegamy formatowanie wymagane przez backend i dołącz naszą logikę Pythona do przetwarzania przychodzącego tensora i użyj kodera etykiet, o którym mowa wcześniej. Możesz przejrzeć filet używane do wstępnego przetwarzania.

W przypadku modelu XGBoost nie trzeba nic więcej robić. Trenowaliśmy model w pierwszym notebooku, a backend Tritona FIL nie wymaga dodatkowego wysiłku w przypadku modeli XGBoost.

Następnie potrzebujemy plików konfiguracyjnych Triton. Każdy model w zespole Triton wymaga config.pbtxt plik. Ponadto tworzymy również config.pbtxt plik dla zespołu jako całości. Pliki te pozwalają Tritonowi poznać metadane dotyczące zespołu z informacjami, takimi jak oczekiwane wejścia i wyjścia, a także pomagają zdefiniować DAG związany z zespołem.

Na koniec, aby wdrożyć model na Triton, potrzebujemy naszego folderu repozytorium modeli, aby miał odpowiednią strukturę folderów. Triton ma specyficzne wymagania dotyczące układu repozytorium modeli. W katalogu repozytorium modeli najwyższego poziomu każdy model ma swój własny podkatalog zawierający informacje dla odpowiedniego modelu. Każdy katalog modelu w Triton musi mieć co najmniej jeden numeryczny podkatalog reprezentujący wersję modelu. W naszym przypadku użycia wynikowa struktura powinna wyglądać następująco.

Po spełnieniu tych trzech wymagań wstępnych tworzymy skompresowany plik jako pakiet do wdrożenia i przesyłamy go do Usługa Amazon Simple Storage (Amazonka S3).

Możemy teraz utworzyć model SageMaker z repozytorium modeli, które przesłaliśmy do Amazon S3 w poprzednim kroku.

W tym kroku podajemy również dodatkową zmienną środowiskową SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, który określa nazwę modelu do załadowania przez Triton. Wartość tego klucza powinna być zgodna z nazwą folderu w pakiecie modelu przesłanym do Amazon S3. Ta zmienna jest opcjonalna w przypadku pojedynczego modelu. W przypadku modeli zespołowych ten klucz musi zostać określony, aby Triton mógł się uruchomić w SageMaker.

Dodatkowo możesz ustawić SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT i SAGEMAKER_TRITON_THREAD_COUNT do optymalizacji liczby wątków. Obie wartości konfiguracyjne pomagają dostroić liczbę wątków działających na procesorach, dzięki czemu można uzyskać lepsze wykorzystanie, zwiększając te wartości dla procesorów z większą liczbą rdzeni. W większości przypadków wartości domyślne często działają dobrze, ale warto poeksperymentować i sprawdzić, czy można zwiększyć wydajność w przypadku obciążeń.

W poprzednim modelu tworzymy konfigurację punktu końcowego, w której możemy określić typ i liczbę wystąpień, które chcemy w punkcie końcowym.

Na koniec używamy poprzedniej konfiguracji punktu końcowego, aby utworzyć nowy punkt końcowy SageMaker i czekać na zakończenie wdrożenia. Status zmieni się na InService po pomyślnym wdrożeniu.

Otóż ​​to! Twój punkt końcowy jest teraz gotowy do testowania i walidacji. W tym momencie możesz skorzystać z różnych narzędzi, które pomogą zoptymalizować typy i konfigurację instancji, aby uzyskać najlepszą możliwą wydajność. Poniższy rysunek przedstawia przykład korzyści, które można osiągnąć przy użyciu zaplecza FIL dla modelu XGBoost na Tritonie.

Podsumowanie

W tym poście przeprowadziliśmy Cię przez proces wdrażania obciążenia zestawu XGBoost w programie SageMaker za pomocą serwera Triton Inference Server. Przeniesienie obciążeń do Triton w programie SageMaker może być korzystnym zwrotem z inwestycji. Podobnie jak w przypadku każdego przyjęcia technologii, proces i plan weryfikacji są kluczowe. Szczegółowo opisaliśmy pięcioetapowy proces, który poprowadzi Cię przez kwestie, które należy wziąć pod uwagę podczas przenoszenia obciążeń. Ponadto zagłębiliśmy się w kroki potrzebne do wdrożenia zespołu, który wykorzystuje preprocessing Pythona i model XGBoost na Triton w SageMaker.

SageMaker zapewnia narzędzia do usuwania niezróżnicowanego podnoszenia ciężarów na każdym etapie cyklu życia ML, ułatwiając w ten sposób szybkie eksperymentowanie i eksplorację potrzebne do pełnej optymalizacji wdrożeń modeli. Obsługa hostingu SageMaker dla Triton Inference Server umożliwia niskie opóźnienia i wysokie obciążenia transakcji na sekundę (TPS).

Notatniki użyte w tym przykładzie można znaleźć na GitHub.

---

O autorze

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 poszukiwać nowych kultur, nowych doświadczeń i być na bieżąco z najnowszymi trendami technologicznymi.

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

Kszitiz Gupta jest architektem rozwiązań w firmie NVIDIA. Lubi edukować klientów korzystających z chmury na temat technologii GPU AI, które firma NVIDIA ma do zaoferowania, i pomagać im w przyspieszaniu ich aplikacji do uczenia maszynowego i uczenia głębokiego. Poza pracą lubi biegać, wędrować i obserwować dziką przyrodę.

Bruno Aguiara de Melo jest inżynierem ds. rozwoju oprogramowania w Amazon.com, gdzie pomaga zespołom naukowym w tworzeniu, wdrażaniu i zwalnianiu obciążeń ML. Interesuje się oprzyrządowaniem i kontrolowalnymi aspektami w fazie modelowania/projektowania ML, które należy wziąć pod uwagę i zmierzyć, mając na uwadze, że wydajność wykonania modelu jest tak samo ważna jak wydajność jakości modelu, szczególnie w przypadkach użycia z ograniczonymi opóźnieniami. W wolnym czasie lubi wino, gry planszowe i gotowanie.

Eliut Triana jest kierownikiem ds. relacji z programistami w firmie NVIDIA. Łą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ą.