Hur Veriff minskade distributionstiden med 80 % med Amazon SageMaker multi-model endpoints | Amazon webbtjänster

Verifikation är en plattformspartner för identitetsverifiering för innovativa tillväxtdrivna organisationer, inklusive pionjärer inom finansiella tjänster, FinTech, krypto, spel, mobilitet och onlinemarknadsplatser. De tillhandahåller avancerad teknik som kombinerar AI-driven automation med mänsklig feedback, djupa insikter och expertis.

Veriff levererar en beprövad infrastruktur som gör det möjligt för deras kunder att lita på sina användares identiteter och personliga egenskaper under alla relevanta ögonblick i deras kundresa. Veriff litar på av kunder som Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot och Wise.

Som en AI-driven lösning behöver Veriff skapa och köra dussintals maskininlärningsmodeller (ML) på ett kostnadseffektivt sätt. Dessa modeller sträcker sig från lätta trädbaserade modeller till modeller för djupinlärning av datorseende, som måste köras på GPU:er för att uppnå låg latens och förbättra användarupplevelsen. Veriff lägger för närvarande också till fler produkter till sitt erbjudande, med inriktning på en hyperpersonlig lösning för sina kunder. Att servera olika modeller för olika kunder ökar behovet av en skalbar modellserveringslösning.

I det här inlägget visar vi dig hur Veriff standardiserade sitt arbetsflöde för modelldistribution med hjälp av Amazon SageMaker, vilket minskar kostnader och utvecklingstid.

Infrastruktur och utvecklingsutmaningar

Veriffs backend-arkitektur är baserad på ett mikrotjänstmönster, med tjänster som körs på olika Kubernetes-kluster på AWS-infrastruktur. Detta tillvägagångssätt användes initialt för alla företagstjänster, inklusive mikrotjänster som kör dyra datorseende ML-modeller.

Vissa av dessa modeller krävde distribution på GPU-instanser. Medveten om den jämförelsevis högre kostnaden för GPU-stödda instanstyper utvecklade Veriff en anpassad lösning på Kubernetes för att dela en given GPU:s resurser mellan olika tjänstekopior. En enda GPU har vanligtvis tillräckligt med VRAM för att hålla flera av Veriffs datorvisionsmodeller i minnet.

Även om lösningen minskade GPU-kostnaderna, kom den också med begränsningen att datavetare behövde i förväg ange hur mycket GPU-minne deras modell skulle kräva. Dessutom belastades DevOps med manuell provisionering av GPU-instanser som svar på efterfrågemönster. Detta orsakade en operativ overhead och överprovisionering av instanser, vilket resulterade i en suboptimal kostnadsprofil.

Förutom GPU-provisionering krävde den här installationen också att datavetare byggde ett REST API-omslag för varje modell, vilket behövdes för att tillhandahålla ett generiskt gränssnitt för andra företagstjänster att konsumera, och för att kapsla in förbearbetning och efterbearbetning av modelldata. Dessa API:er krävde produktionskod, vilket gjorde det utmanande för datavetare att producera modeller.

Veriffs datavetenskapliga plattformsteam letade efter alternativa sätt till detta tillvägagångssätt. Huvudsyftet var att stödja företagets dataforskare med en bättre övergång från forskning till produktion genom att tillhandahålla enklare distributionspipelines. Det sekundära målet var att minska driftskostnaderna för att tillhandahålla GPU-instanser.

Lösningsöversikt

Veriff krävde en ny lösning som löste två problem:

• Tillåt att enkelt bygga REST API-omslag runt ML-modeller
• Tillåt hantering av provisionerad GPU-instanskapacitet optimalt och, om möjligt, automatiskt

I slutändan konvergerade ML-plattformsteamet om beslutet att använda Sagemaker multi-modell slutpunkter (MME). Detta beslut drevs av MME:s stöd för NVIDIA:s Triton Inference Server (en ML-fokuserad server som gör det enkelt att slå in modeller som REST API:er; Veriff experimenterade också redan med Triton), såväl som dess förmåga att inbyggt hantera den automatiska skalningen av GPU-instanser via enkla automatiska skalningspolicyer.

Två MME skapades på Veriff, en för iscensättning och en för produktion. Detta tillvägagångssätt tillåter dem att köra teststeg i en iscensättningsmiljö utan att påverka produktionsmodellerna.

SageMaker MME

SageMaker är en helt hanterad tjänst som ger utvecklare och datavetare möjligheten att snabbt bygga, träna och distribuera ML-modeller. SageMaker MMEs tillhandahåller en skalbar och kostnadseffektiv lösning för att distribuera ett stort antal modeller för realtidsinferens. MME:er använder en delad serveringsbehållare och en flotta av resurser som kan använda accelererade instanser som GPU:er för att vara värd för alla dina modeller. Detta minskar värdkostnaderna genom att maximera slutpunktsutnyttjandet jämfört med att använda slutpunkter med en enda modell. Det minskar också distributionskostnader eftersom SageMaker hanterar in- och urladdning av modeller i minnet och skalar dem baserat på slutpunktens trafikmönster. Dessutom drar alla SageMaker realtidsslutpunkter nytta av inbyggda möjligheter för att hantera och övervaka modeller, som t.ex. skuggvarianter, automatisk skalning, och inbyggd integration med amazoncloudwatch (för mer information, se CloudWatch Metrics for Multi-Model Endpoint Deployment).

Anpassade Triton-ensemblemodeller

Det fanns flera anledningar till att Veriff bestämde sig för att använda Triton Inference Server, de främsta var:

• Det tillåter datavetare att bygga REST API:er från modeller genom att ordna modellartefaktfiler i ett standardkatalogformat (ingen kodlösning)
• Den är kompatibel med alla större AI-ramverk (PyTorch, Tensorflow, XGBoost och mer)
• Det ger ML-specifika lågnivå- och serveroptimeringar som t.ex dynamisk batchning av förfrågningar

Att använda Triton tillåter datavetare att distribuera modeller med lätthet eftersom de bara behöver bygga formaterade modelllager istället för att skriva kod för att bygga REST API:er (Triton stöder också Python-modeller om anpassad slutledningslogik krävs). Detta minskar modellimplementeringstiden och ger datavetare mer tid att fokusera på att bygga modeller istället för att distribuera dem.

En annan viktig egenskap hos Triton är att den låter dig bygga modellensembler, som är grupper av modeller som är sammankopplade. Dessa ensembler kan köras som om de vore en enda Triton-modell. Veriff använder för närvarande den här funktionen för att distribuera förbearbetnings- och efterbearbetningslogik med varje ML-modell med Python-modeller (som nämnts tidigare), vilket säkerställer att det inte finns några felmatchningar i indata eller modellutdata när modeller används i produktionen.

Följande är hur ett typiskt Triton-modellförråd ser ut för denna arbetsbelastning:

Smakämnen model.py filen innehåller förbearbetnings- och efterbearbetningskod. De tränade modellvikterna finns i screen_detection_inferencer katalog, under modellversion 1 (modellen är i ONNX-format i det här exemplet, men kan också vara TensorFlow, PyTorch-format eller andra). Ensemblemodellens definition finns i screen_detection_pipeline katalog, där ingångar och utgångar mellan steg mappas i en konfigurationsfil.

Ytterligare beroenden som behövs för att köra Python-modellerna beskrivs i detalj i en requirements.txt fil, och måste vara conda-packad för att bygga en Conda-miljö (python_env.tar.gz). För mer information, se Hantera Python Runtime och bibliotek. Konfigurationsfiler för Python-steg måste också peka på python_env.tar.gz med EXECUTION_ENV_PATH Direktiv.

Modellmappen måste sedan TAR-komprimeras och döpas om med hjälp av model_version.txt. Slutligen resultatet <model_name>_<model_version>.tar.gz filen kopieras till Amazon enkel lagringstjänst (Amazon S3) hink ansluten till MME, vilket gör att SageMaker kan upptäcka och betjäna modellen.

Modellversionering och kontinuerlig driftsättning

Som föregående avsnitt framgick är det enkelt att bygga ett Triton-modellförråd. Men att köra alla nödvändiga steg för att distribuera det är tråkigt och felbenäget om det körs manuellt. För att övervinna detta byggde Veriff en monorepo som innehåller alla modeller som ska distribueras till MME, där dataforskare samarbetar i ett Gitflow-liknande tillvägagångssätt. Denna monorepo har följande egenskaper:

• Det hanteras med hjälp av Byxor.
• Kodkvalitetsverktyg som Black och MyPy används med Pants.
• Enhetstester definieras för varje modell, som kontrollerar att modellutgången är den förväntade utgången för en given modellingång.
• Modellvikter lagras vid sidan av modellförråd. Dessa vikter kan vara stora binära filer, så DVC används för att synkronisera dem med Git på ett versionerat sätt.

Denna monorepo är integrerad med ett verktyg för kontinuerlig integration (CI). För varje ny push till repo eller ny modell körs följande steg:

1. Klara kvalitetskontrollen av koden.
2. Ladda ner modellvikterna.
3. Bygg Conda-miljön.
4. Snurra upp en Triton-server med Conda-miljön och använd den för att behandla förfrågningar som definieras i enhetstester.
5. Bygg den slutliga modellen TAR-fil (<model_name>_<model_version>.tar.gz).

Dessa steg säkerställer att modellerna har den kvalitet som krävs för utplacering, så för varje push till en repo-gren kopieras den resulterande TAR-filen (i ett annat CI-steg) till staging S3-bucket. När push görs i huvudgrenen kopieras modellfilen till produktions S3-skopan. Följande diagram visar detta CI/CD-system.

Kostnader och fördelar med distributionshastighet

Genom att använda MME:er kan Veriff använda en monorepo-metod för att distribuera modeller till produktion. Sammanfattningsvis består Veriffs nya arbetsflöde för modelldistribution av följande steg:

1. Skapa en gren i monorepo med den nya modellen eller modellversionen.
2. Definiera och kör enhetstester i en utvecklingsmaskin.
3. Tryck på grenen när modellen är redo att testas i uppställningsmiljön.
4. Slå ihop grenen till huvud när modellen är redo att användas i produktionen.

Med denna nya lösning på plats är implementeringen av en modell hos Veriff en enkel del av utvecklingsprocessen. Utvecklingstiden för nya modeller har minskat från 10 dagar till i genomsnitt 2 dagar.

SageMakers hanterade infrastrukturförsörjning och automatisk skalningsfunktioner gav Veriff ytterligare fördelar. De använde InvocationsPerInstance CloudWatch-mått för att skala enligt trafikmönster, vilket sparar på kostnader utan att offra tillförlitligheten. För att definiera tröskelvärdet för måttet, utförde de belastningstestning på iscensättningsändpunkten för att hitta den bästa kompromissen mellan latens och kostnad.

Efter att ha distribuerat sju produktionsmodeller till MME och analyserat utgifter rapporterade Veriff en kostnadsminskning på 75 % i GPU-modelltjänsten jämfört med den ursprungliga Kubernetes-baserade lösningen. Driftkostnaderna minskade också, eftersom bördan med att tillhandahålla instanser manuellt lyftes från företagets DevOps-ingenjörer.

Slutsats

I det här inlägget gick vi igenom varför Veriff valde Sagemaker MME framför självhanterad modelldistribution på Kubernetes. SageMaker tar sig an de odifferentierade tunga lyften, vilket gör att Veriff kan minska modellutvecklingstiden, öka den tekniska effektiviteten och dramatiskt sänka kostnaden för realtidsinferens samtidigt som de bibehåller den prestanda som krävs för deras affärskritiska verksamhet. Slutligen visade vi upp Veriffs enkla men effektiva modelldistribution CI/CD-pipeline och modellversionsmekanism, som kan användas som en referensimplementering för att kombinera bästa praxis för mjukvaruutveckling och SageMaker MME. Du kan hitta kodexempel på att vara värd för flera modeller med SageMaker MME på GitHub.

---

Om författarna

Ricard Borràs är Senior Machine Learning på Veriff, där han leder MLOps insatser i företaget. Han hjälper datavetare att bygga snabbare och bättre AI/ML-produkter genom att bygga en Data Science Platform på företaget och kombinera flera lösningar med öppen källkod med AWS-tjänster.

João Moura är en AI/ML Specialist Solutions Architect på AWS, baserad i Spanien. Han hjälper kunder med djupinlärningsmodeller för storskalig utbildning och slutledningsoptimering, och mer brett att bygga storskaliga ML-plattformar på AWS.

Miguel Ferreira arbetar som Sr. Solutions Architect på AWS baserad i Helsingfors, Finland. AI/ML har varit ett livslångt intresse och han har hjälpt flera kunder att integrera Amazon SageMaker i deras ML-arbetsflöden.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/