Jak firma Veriff skróciła czas wdrażania o 80% przy użyciu wielomodelowych punktów końcowych Amazon SageMaker | Usługi internetowe Amazona

Weryfikacja jest partnerem platformy weryfikacji tożsamości dla innowacyjnych organizacji nastawionych na rozwój, w tym pionierów usług finansowych, FinTech, kryptowalut, gier, mobilności i rynków internetowych. Zapewniają zaawansowaną technologię, która łączy automatyzację opartą na sztucznej inteligencji z opiniami ludzi, głębokimi spostrzeżeniami i wiedzą specjalistyczną.

Veriff zapewnia sprawdzoną infrastrukturę, która umożliwia klientom zaufanie do tożsamości i cech osobistych użytkowników we wszystkich istotnych momentach podróży klienta. Veriff cieszy się zaufaniem klientów takich jak Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot i Wise.

Jako rozwiązanie oparte na sztucznej inteligencji firma Veriff musi tworzyć i uruchamiać dziesiątki modeli uczenia maszynowego (ML) w opłacalny sposób. Obejmują one zarówno lekkie modele oparte na drzewie, jak i modele wizji komputerowej głębokiego uczenia, które muszą działać na procesorach graficznych, aby osiągnąć niskie opóźnienia i poprawić komfort użytkownika. Firma Veriff dodaje obecnie więcej produktów do swojej oferty, starając się zapewnić swoim klientom hiperspersonalizowane rozwiązanie. Udostępnianie różnych modeli różnym klientom zwiększa potrzebę stosowania skalowalnego rozwiązania do obsługi modeli.

W tym poście pokażemy, jak firma Veriff ustandaryzowała przepływ pracy przy wdrażaniu modelu Amazon Sage Maker, redukując koszty i czas rozwoju.

Wyzwania infrastrukturalne i rozwojowe

Architektura backendu Veriff opiera się na wzorcu mikrousług, z usługami działającymi w różnych klastrach Kubernetes hostowanych w infrastrukturze AWS. To podejście było początkowo stosowane w przypadku wszystkich usług firmy, w tym mikrousług, które obsługują drogie modele ML z wizją komputerową.

Niektóre z tych modeli wymagały wdrożenia na instancjach GPU. Mając świadomość stosunkowo wyższego kosztu typów instancji wspieranych przez GPU, firma Veriff opracowała niestandardowe rozwiązanie na Kubernetesie, aby dzielić zasoby danego GPU pomiędzy różnymi replikami usług. Pojedynczy procesor graficzny ma zwykle wystarczającą ilość pamięci VRAM, aby pomieścić w pamięci wiele modeli widzenia komputerowego firmy Veriff.

Chociaż rozwiązanie to rzeczywiście obniżyło koszty procesora graficznego, wiązało się z ograniczeniem polegającym na tym, że badacze danych musieli wcześniej określić, ile pamięci GPU będzie wymagał ich model. Co więcej, DevOps był obciążony ręcznym przydzielaniem instancji GPU w odpowiedzi na wzorce zapotrzebowania. Powodowało to narzut operacyjny i nadmierną alokację instancji, co skutkowało nieoptymalnym profilem kosztów.

Oprócz udostępnienia procesora graficznego ta konfiguracja wymagała również od analityków danych zbudowania opakowania API REST dla każdego modelu, co było potrzebne do zapewnienia ogólnego interfejsu do wykorzystania przez inne usługi firmy oraz do hermetyzacji wstępnego i końcowego przetwarzania danych modelu. Te interfejsy API wymagały kodu klasy produkcyjnej, co utrudniało analitykom danych tworzenie modeli produkcyjnych.

Zespół platformy do nauki danych firmy Veriff szukał alternatywnych sposobów zastosowania tego podejścia. Głównym celem było wsparcie firmowych analityków danych w lepszym przejściu od badań do produkcji poprzez zapewnienie prostszych potoków wdrażania. Celem drugorzędnym było zmniejszenie kosztów operacyjnych udostępniania instancji GPU.

Omówienie rozwiązania

Firma Veriff potrzebowała nowego rozwiązania, które rozwiązałoby dwa problemy:

• Pozwól z łatwością tworzyć opakowania API REST wokół modeli ML
• Pozwól optymalnie i, jeśli to możliwe, automatycznie zarządzać udostępnioną wydajnością instancji GPU

Ostatecznie zespół platformy ML podjął decyzję o jej zastosowaniu Wielomodelowe punkty końcowe Sagemaker (MME). Decyzja ta była podyktowana wsparciem MME dla NVIDIA Serwer wnioskowania Triton (serwer zorientowany na ML, który ułatwia opakowywanie modeli jako interfejsy API REST; Veriff eksperymentował już także z Tritonem), a także jego zdolność do natywnego zarządzania automatycznym skalowaniem instancji GPU za pomocą prostych zasad automatycznego skalowania.

W Veriff utworzono dwa MME, jedno do inscenizacji i jedno do produkcji. Takie podejście umożliwia przeprowadzanie etapów testowania w środowisku przejściowym bez wpływu na modele produkcyjne.

MME SageMakera

SageMaker to w pełni zarządzana usługa, która zapewnia programistom i analitykom danych możliwość szybkiego budowania, trenowania i wdrażania modeli ML. SageMaker MME zapewnia skalowalne i ekonomiczne rozwiązanie do wdrażania dużej liczby modeli do wnioskowania w czasie rzeczywistym. MME używają współdzielonego kontenera do obsługi i floty zasobów, które mogą wykorzystywać przyspieszone instancje, takie jak procesory graficzne, do hostowania wszystkich modeli. Zmniejsza to koszty hostingu poprzez maksymalizację wykorzystania punktów końcowych w porównaniu z punktami końcowymi z jednym modelem. Zmniejsza to również koszty wdrożenia, ponieważ SageMaker zarządza ładowaniem i rozładowywaniem modeli w pamięci oraz skalowaniem ich w oparciu o wzorce ruchu w punkcie końcowym. Ponadto wszystkie punkty końcowe SageMaker działające w czasie rzeczywistym korzystają z wbudowanych funkcji zarządzania i monitorowania modeli, takich jak warianty cieni, automatyczne skalowaniei natywna integracja z Amazon Cloud Watch (aby uzyskać więcej informacji, patrz Metryki CloudWatch dla wielomodelowych wdrożeń punktów końcowych).

Niestandardowe modele zespołów Triton

Było kilka powodów, dla których Veriff zdecydował się na użycie Triton Inference Server, a najważniejsze z nich to:

• Umożliwia badaczom danych budowanie interfejsów API REST na podstawie modeli poprzez organizowanie plików artefaktów modelu w standardowym formacie katalogu (bez rozwiązania kodowego)
• Jest kompatybilny ze wszystkimi głównymi frameworkami AI (PyTorch, Tensorflow, XGBoost i innymi)
• Zapewnia specyficzne dla ML optymalizacje niskiego poziomu i serwera, takie jak dynamiczne grupowanie żądań

Korzystanie z Triton pozwala analitykom danych na łatwe wdrażanie modeli, ponieważ wystarczy im jedynie zbudowanie sformatowanych repozytoriów modeli zamiast pisania kodu w celu zbudowania interfejsów API REST (Triton obsługuje również Modele Pythona jeśli wymagana jest niestandardowa logika wnioskowania). Skraca to czas wdrażania modelu i daje badaczom danych więcej czasu na skupienie się na budowaniu modeli zamiast na ich wdrażaniu.

Kolejną ważną cechą Tritona jest to, że pozwala na budowanie zespoły modelowe, które są grupami modeli połączonymi ze sobą łańcuchem. Zespoły te można uruchomić tak, jakby były pojedynczym modelem Triton. Firma Veriff obecnie wykorzystuje tę funkcję do wdrażania logiki przetwarzania wstępnego i końcowego w każdym modelu ML przy użyciu modeli Pythona (jak wspomniano wcześniej), zapewniając, że nie będzie żadnych rozbieżności w danych wejściowych ani wynikach modelu, gdy modele są używane w środowisku produkcyjnym.

Poniżej przedstawiono typowe repozytorium modeli Triton dla tego obciążenia:

Połączenia model.py plik zawiera kod przetwarzania wstępnego i końcowego. Wyszkolone wagi modelu znajdują się w pliku screen_detection_inferencer katalogu, w wersji modelu 1 (w tym przykładzie model jest w formacie ONNX, ale może być również w formacie TensorFlow, PyTorch lub innym). Definicja modelu zespołowego znajduje się w pliku screen_detection_pipeline katalog, w którym wejścia i wyjścia pomiędzy krokami są mapowane w pliku konfiguracyjnym.

Dodatkowe zależności potrzebne do uruchomienia modeli Pythona są szczegółowo opisane w a requirements.txt i muszą być spakowane w Conda, aby zbudować środowisko Conda (python_env.tar.gz). Aby uzyskać więcej informacji, zobacz Zarządzanie środowiskiem wykonawczym i bibliotekami Pythona. Należy także wskazać pliki konfiguracyjne dla kroków Pythona python_env.tar.gz używając WYKONANIE_ENV_PATH Dyrektywa.

Folder modelu należy następnie skompresować w formacie TAR i zmienić jego nazwę za pomocą model_version.txt. Wreszcie wynik <model_name>_<model_version>.tar.gz plik jest kopiowany do Usługa Amazon Simple Storage Łyżka (Amazon S3) podłączona do MME, umożliwiając SageMakerowi wykrycie i obsługę modelu.

Wersjonowanie modelu i ciągłe wdrażanie

Jak wynika z poprzedniej sekcji, budowanie repozytorium modeli Triton jest proste. Jednak wykonanie wszystkich niezbędnych kroków w celu wdrożenia jest żmudne i podatne na błędy, jeśli zostanie uruchomione ręcznie. Aby temu zaradzić, firma Veriff zbudowała monorepo zawierające wszystkie modele do wdrożenia w MME, gdzie badacze danych współpracują w oparciu o podejście podobne do Gitflow. To monorepo ma następujące funkcje:

• Zarządza się nim za pomocą Spodnie.
• Narzędzia jakości kodu, takie jak Black i MyPy, są stosowane przy użyciu Pants.
• Dla każdego modelu zdefiniowane są testy jednostkowe, które sprawdzają, czy wynik modelu jest oczekiwanym wyjściem dla danych wejściowych modelu.
• Wagi modeli są przechowywane obok repozytoriów modeli. Wagi te mogą być dużymi plikami binarnymi, tzw rozszerzenie DVC służy do synchronizowania ich z Git w sposób wersjonowany.

To monorepo jest zintegrowane z narzędziem ciągłej integracji (CI). Dla każdego nowego wypchnięcia do repo lub nowego modelu wykonywane są następujące kroki:

1. Przejdź kontrolę jakości kodu.
2. Pobierz ciężary modeli.
3. Zbuduj środowisko Conda.
4. Uruchom serwer Triton przy użyciu środowiska Conda i wykorzystaj go do przetwarzania żądań zdefiniowanych w testach jednostkowych.
5. Zbuduj ostateczny plik modelu TAR (<model_name>_<model_version>.tar.gz).

Dzięki tym krokom modele mają jakość wymaganą do wdrożenia, więc przy każdym wypchnięciu do gałęzi repo wynikowy plik TAR jest kopiowany (w kolejnym kroku CI) do zasobnika tymczasowego S3. Po wykonaniu operacji wypychania w głównej gałęzi plik modelu jest kopiowany do produkcyjnego segmentu S3. Poniższy diagram przedstawia ten system CI/CD.

Korzyści w zakresie kosztów i szybkości wdrażania

Korzystanie z MME umożliwia firmie Veriff zastosowanie podejścia monorepo do wdrażania modeli w środowisku produkcyjnym. Podsumowując, proces wdrażania nowego modelu Veriff składa się z następujących kroków:

1. Utwórz oddział w monorepo z nowym modelem lub wersją modelu.
2. Zdefiniuj i uruchom testy jednostkowe na maszynie deweloperskiej.
3. Naciśnij gałąź, gdy model będzie gotowy do przetestowania w środowisku przejściowym.
4. Połącz gałąź z główną, gdy model będzie gotowy do użycia w produkcji.

Dzięki temu nowemu rozwiązaniu wdrożenie modelu w Veriff jest prostą częścią procesu rozwoju. Czas opracowywania nowego modelu skrócił się z 10 dni do średnio 2 dni.

Funkcje udostępniania zarządzanej infrastruktury i automatycznego skalowania w SageMaker przyniosły firmie Veriff dodatkowe korzyści. Korzystali z Wywołania na instancję Metryka CloudWatch skalowana zgodnie ze wzorcami ruchu, co pozwala zaoszczędzić na kosztach bez utraty niezawodności. Aby zdefiniować wartość progową metryki, przeprowadzili testy obciążenia w tymczasowym punkcie końcowym, aby znaleźć najlepszy kompromis między opóźnieniem a kosztem.

Po wdrożeniu siedmiu modeli produkcyjnych w MME i przeanalizowaniu wydatków firma Veriff odnotowała 75% redukcję kosztów obsługi modelu GPU w porównaniu z oryginalnym rozwiązaniem opartym na Kubernetes. Koszty operacyjne również zostały obniżone, ponieważ odciążono inżynierów DevOps firmy od ręcznego udostępniania instancji.

Wnioski

W tym poście sprawdziliśmy, dlaczego firma Veriff wybrała MME firmy Sagemaker zamiast samodzielnie zarządzanego wdrażania modeli w Kubernetes. SageMaker przejmuje niezróżnicowane ciężkie zadania, umożliwiając firmie Veriff skrócenie czasu opracowywania modelu, zwiększenie wydajności inżynieryjnej i radykalne obniżenie kosztów wnioskowania w czasie rzeczywistym, przy jednoczesnym zachowaniu wydajności niezbędnej do operacji o znaczeniu krytycznym. Na koniec zaprezentowaliśmy prosty, ale skuteczny potok CI/CD wdrażania modelu firmy Veriff oraz mechanizm wersjonowania modelu, który może służyć jako referencyjna implementacja łącząca najlepsze praktyki tworzenia oprogramowania i MME SageMaker. Przykłady kodu można znaleźć na hostingu wielu modeli przy użyciu MME SageMaker GitHub.

---

O autorach

Ricarda Borrasa jest starszym specjalistą ds. uczenia maszynowego w Veriff, gdzie kieruje działaniami MLOps w firmie. Pomaga analitykom danych budować szybsze i lepsze produkty AI/ML budując w firmie platformę Data Science Platform oraz łącząc kilka rozwiązań open source z usługami AWS.

Joao Moura jest architektem rozwiązań specjalistycznych AI/ML w AWS z siedzibą w Hiszpanii. Pomaga klientom w modelowaniu głębokiego uczenia się na dużą skalę, optymalizacji wnioskowania i szerzej w budowaniu wielkoskalowych platform ML na AWS.

Miguel Ferreira pracuje jako starszy architekt rozwiązań w AWS z siedzibą w Helsinkach w Finlandii. AI/ML interesował się przez całe życie i pomógł wielu klientom zintegrować Amazon SageMaker z ich przepływami pracy ML.

• 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/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/