Kuidas Veriff vähendas Amazon SageMakeri mitme mudeli lõpp-punktide abil juurutusaega 80% võrra | Amazoni veebiteenused

Veriff on identiteedi kinnitamise platvormi partner uuenduslikele kasvule orienteeritud organisatsioonidele, sealhulgas finantsteenuste, FinTechi, krüpto-, mängude, mobiilsuse ja veebiturgude pioneeridele. Need pakuvad täiustatud tehnoloogiat, mis ühendab tehisintellektil põhineva automatiseerimise inimeste tagasiside, põhjaliku ülevaate ja teadmistega.

Veriff pakub tõestatud infrastruktuuri, mis võimaldab nende klientidel usaldada oma kasutajate identiteeti ja isiklikke atribuute klienditeekonna kõigil olulistel hetkedel. Veriffi usaldavad sellised kliendid nagu Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot ja Wise.

AI-toega lahendusena peab Veriff kulutõhusal viisil looma ja käivitama kümneid masinõppe (ML) mudeleid. Need mudelid ulatuvad kergetest puupõhistest mudelitest kuni süvaõppega arvutinägemise mudeliteni, mis peavad madala latentsusaja saavutamiseks ja kasutuskogemuse parandamiseks töötama GPU-del. Veriff lisab praegu oma pakkumisse ka rohkem tooteid, sihites oma klientidele ülipersonaliseeritud lahendust. Erinevate mudelite serveerimine erinevatele klientidele suurendab vajadust skaleeritava mudeliteeninduslahenduse järele.

Selles postituses näitame teile, kuidas Veriff standardiseeris oma mudeli juurutamise töövoo Amazon SageMaker, vähendades kulusid ja arendusaega.

Infrastruktuuri ja arengu väljakutsed

Veriffi taustaarhitektuur põhineb mikroteenuste mustril, kus teenused töötavad erinevates AWS-i infrastruktuuris hostitud Kubernetese klastrites. Seda lähenemisviisi kasutati algselt kõigi ettevõtte teenuste jaoks, sealhulgas mikroteenuste jaoks, mis käitavad kalleid arvutinägemise ML-mudeleid.

Mõned neist mudelitest nõudsid juurutamist GPU eksemplaridel. Olles teadlik GPU-ga toetatud eksemplaritüüpide suhteliselt kõrgematest kuludest, töötas Veriff välja a kohandatud lahendus Kubernetes, et jagada antud GPU ressursse erinevate teenusekoopiate vahel. Ühel GPU-l on tavaliselt piisavalt VRAM-i, et hoida mälus mitu Veriffi arvutinägemismudelit.

Kuigi lahendus leevendas GPU kulusid, kaasnes sellega ka piirang, et andmeteadlased pidid eelnevalt märkima, kui palju GPU mälu nende mudel vajab. Lisaks oli DevOps koormatud GPU eksemplaride käsitsi ettevalmistamisega vastavalt nõudlusmustritele. See põhjustas tegevuse üldkulusid ja eksemplaride üleprovisjoni, mille tulemuseks oli mitteoptimaalne kuluprofiil.

Lisaks GPU pakkumisele nõudis see seadistus ka andmeteadlastelt iga mudeli jaoks REST API ümbrise loomist, mida oli vaja muude ettevõtte teenuste jaoks üldise liidese pakkumiseks ning mudeliandmete eel- ja järeltöötluse kapseldamiseks. Need API-d nõudsid tootmisklassi koodi, mis muutis andmeteadlaste jaoks mudelite tootmise keeruliseks.

Veriffi andmeteaduse platvormi meeskond otsis selle lähenemisviisi alternatiivseid viise. Peamine eesmärk oli toetada ettevõtte andmeteadlasi parema üleminekuga uurimistöölt tootmisele, pakkudes lihtsamaid kasutuselevõtutorusid. Teisene eesmärk oli vähendada GPU eksemplaride varustamise tegevuskulusid.

Lahenduse ülevaade

Veriff vajas uut lahendust, mis lahendas kaks probleemi:

• Lubage hõlpsalt ML-mudelite ümber ehitada REST API ümbriseid
• Lubage ette nähtud GPU eksemplari võimsust optimaalselt ja võimalusel automaatselt hallata

Lõppkokkuvõttes ühines ML-i platvormi meeskond kasutamise otsusega Sagemakeri mitme mudeli lõpp-punktid (MME). Selle otsuse ajendiks oli MME toetus NVIDIA-le Tritoni järeldusserver (ML-keskne server, mis muudab mudelite REST API-deks mähkimise lihtsaks; Veriff katsetas juba ka Tritoniga), samuti selle võimet hallata GPU eksemplaride automaatset skaleerimist lihtsate automaatse skaleerimise poliitikate abil.

Veriffis loodi kaks MME-d, üks lavastuseks ja teine ​​tootmiseks. See lähenemisviis võimaldab neil testimisetappe läbi viia etapikeskkonnas, ilma et see mõjutaks tootmismudeleid.

SageMakeri MME-d

SageMaker on täielikult hallatav teenus, mis annab arendajatele ja andmeteadlastele võimaluse kiiresti ML-mudeleid luua, koolitada ja juurutada. SageMakeri MME-d pakuvad skaleeritavat ja kulutõhusat lahendust suure hulga mudelite juurutamiseks reaalajas järelduste tegemiseks. MME-d kasutavad jagatud serveerimiskonteinerit ja ressursside parki, mis saavad kasutada kiirendatud eksemplare, näiteks GPU-sid, et majutada kõiki teie mudeleid. See vähendab hostimiskulusid, maksimeerides lõpp-punkti kasutust võrreldes ühe mudeli lõpp-punktide kasutamisega. See vähendab ka juurutamise üldkulusid, kuna SageMaker haldab mudelite mällu laadimist ja mahalaadimist ning nende skaleerimist lõpp-punkti liiklusmustrite alusel. Lisaks saavad kõik SageMakeri reaalajas lõpp-punktid kasu sisseehitatud võimalustest mudelite haldamiseks ja jälgimiseks, näiteks varju variandid, automaatne skaleerimine, ja natiivset integreerimist Amazon CloudWatch (lisateabe saamiseks vaadake CloudWatchi mõõdikud mitme mudeli lõpp-punkti juurutamiseks).

Kohandatud Tritoni ansamblimudelid

Põhjuseid, miks Veriff otsustas Triton Inference Serveri kasutada, oli mitu, millest peamised olid:

• See võimaldab andmeteadlastel ehitada mudelitest REST API-sid, korraldades mudeli artefaktifailid standardses kataloogivormingus (ilma koodilahenduseta)
• See ühildub kõigi peamiste AI-raamistikega (PyTorch, Tensorflow, XGBoost ja palju muud)
• See pakub ML-spetsiifilisi madala taseme ja serveri optimeerimisi, näiteks dünaamiline komplekteerimine taotlustest

Tritoni kasutamine võimaldab andmeteadlastel mudeleid hõlpsalt juurutada, sest nad peavad REST API-de loomiseks koodi kirjutamise asemel looma vaid vormindatud mudelihoidlaid (Triton toetab ka Pythoni mudelid kui on vaja kohandatud järeldusloogikat). See vähendab mudeli juurutamise aega ja annab andmeteadlastele rohkem aega keskenduda mudelite loomisele, selle asemel et neid kasutusele võtta.

Tritoni teine ​​oluline omadus on see, et see võimaldab ehitada mudeliansamblid, mis on kokku aheldatud mudelite rühmad. Neid ansambleid saab juhtida nii, nagu oleks tegemist ühe Tritoni mudeliga. Praegu kasutab Veriff seda funktsiooni eeltöötluse ja järeltöötluse loogika juurutamiseks igas Pythoni mudeleid kasutavas ML-mudelis (nagu varem mainitud), tagades, et mudelite tootmisel kasutamisel ei esine sisendandmetes või mudeli väljundis lahknevusi.

Selle töökoormuse jaoks näeb tüüpiline Tritoni mudelihoidla välja järgmine:

. model.py fail sisaldab eel- ja järeltöötluskoodi. Treenitud mudeli raskused on screen_detection_inferencer kataloog, mudeliversiooni all 1 (mudel on selles näites ONNX-vormingus, kuid võib olla ka TensorFlow-, PyTorchi-vormingus või muus). Ansambli mudeli määratlus on esitatud screen_detection_pipeline kataloog, kus sammudevahelised sisendid ja väljundid kaardistatakse konfiguratsioonifailis.

Pythoni mudelite käitamiseks vajalikud täiendavad sõltuvused on üksikasjalikult kirjeldatud jaotises a requirements.txt faili ja Conda keskkonna loomiseks peavad need olema conda-pakitud (python_env.tar.gz). Lisateabe saamiseks vaadake Pythoni käitusaja ja teekide haldamine. Samuti peavad Pythoni sammude konfiguratsioonifailid osutama python_env.tar.gz kasutades EXECUTION_ENV_PATH Direktiivi.

Seejärel tuleb mudelikaust TAR-i tihendada ja kasutades ümber nimetada model_version.txt. Lõpuks tulemus <model_name>_<model_version>.tar.gz fail kopeeritakse Amazoni lihtne salvestusteenus (Amazon S3) kopp, mis on ühendatud MME-ga, võimaldades SageMakeril mudelit tuvastada ja teenindada.

Mudeli versioonide loomine ja pidev juurutamine

Nagu eelmisest jaotisest selgus, on Tritoni mudelihoidla ehitamine lihtne. Kuid kõigi selle juurutamiseks vajalike toimingute käivitamine on käsitsi käivitamisel tüütu ja veatundlik. Selle ületamiseks ehitas Veriff monorepo, mis sisaldas kõiki mudeleid, mida saab kasutada MME-des, kus andmeteadlased teevad koostööd Gitflow-laadse lähenemisviisi raames. Sellel monorepol on järgmised omadused:

• Seda juhitakse kasutades Püksid.
• Pantsiga kasutatakse koodikvaliteedi tööriistu, nagu Black ja MyPy.
• Iga mudeli jaoks on määratletud ühiktestid, mis kontrollivad, kas mudeli väljund on antud mudelisisendi eeldatav väljund.
• Mudeli kaalud salvestatakse koos mudelihoidlatega. Need kaalud võivad olla suured binaarfailid, nii et CVD kasutatakse nende sünkroonimiseks Gitiga versioonipõhiselt.

See monorepo on integreeritud pideva integreerimise (CI) tööriistaga. Iga uue repo või uue mudeli tõuke korral käivitatakse järgmised toimingud.

1. Läbige koodi kvaliteedi kontroll.
2. Laadige alla mudeli kaalud.
3. Ehitage Conda keskkond.
4. Pöörake Conda keskkonna abil üles Tritoni server ja kasutage seda üksusetestides määratletud päringute töötlemiseks.
5. Ehitage lõplik mudeli TAR-fail (<model_name>_<model_version>.tar.gz).

Need sammud tagavad, et mudelitel on juurutamiseks vajalik kvaliteet, nii et iga repoharusse tõuke korral kopeeritakse saadud TAR-fail (teise CI-etapi käigus) S3 ämbrisse. Kui põhiharus tõukeid tehakse, kopeeritakse mudelifail S3 tootmise ämbrisse. Järgmine diagramm kujutab seda CI/CD süsteemi.

Kasu kuludest ja kasutuselevõtu kiirusest

MME-de kasutamine võimaldab Veriffil mudelite tootmisse juurutamiseks kasutada monorepo-lähenemist. Kokkuvõttes koosneb Veriffi uue mudeli juurutamise töövoog järgmistest sammudest.

1. Looge monorepos haru uue mudeli või mudeliversiooniga.
2. Defineerige ja käivitage arendusmasinas ühikutestid.
3. Lükake haru, kui mudel on lavastuskeskkonnas testimiseks valmis.
4. Ühendage haru põhiliseks, kui mudel on tootmises kasutamiseks valmis.

Kui see uus lahendus on paigas, on mudeli juurutamine Veriffis arendusprotsessi otsene osa. Uue mudeli väljatöötamise aeg on vähenenud 10 päevalt keskmiselt 2 päevale.

SageMakeri hallatud infrastruktuuri varustamise ja automaatse skaleerimise funktsioonid tõid Veriffile lisaeeliseid. Nad kasutasid InvocationsPerInstance CloudWatchi mõõdikuid saab liiklusmustrite järgi skaleerida, säästes kulusid ilma usaldusväärsust ohverdamata. Mõõdiku läviväärtuse määratlemiseks viisid nad läbi etapi lõpp-punkti koormustesti, et leida parim kompromiss latentsusaja ja kulu vahel.

Pärast seitsme tootmismudeli juurutamist MME-dele ja kulutuste analüüsimist teatas Veriff, et GPU-mudeli kulud vähenesid 75% võrra võrreldes algse Kubernetese-põhise lahendusega. Vähenesid ka tegevuskulud, sest ettevõtte DevOpsi inseneridelt võeti ära eksemplaride käsitsi varustamise koorem.

Järeldus

Selles postituses vaatasime üle, miks Veriff valis Sagemakeri MME-d isehallatava mudeli juurutamise asemel Kubernetes. SageMaker võtab enda peale eristamata raskete tõstetööde, võimaldades Veriffil lühendada mudeli arendusaega, suurendada inseneri efektiivsust ja oluliselt vähendada reaalajas järelduste tegemise kulusid, säilitades samal ajal oma ärikriitiliste toimingute jaoks vajaliku jõudluse. Lõpuks tutvustasime Veriffi lihtsat, kuid tõhusat mudeli juurutamise CI/CD konveieri ja mudeli versioonide loomise mehhanismi, mida saab kasutada tarkvaraarenduse parimate tavade ja SageMakeri MME-de ühendamisel. Koodinäidised leiate mitme mudeli hostimise kohta, kasutades SageMaker MME-sid GitHub.

---

Autoritest

Ricard Borràs on Veriffi masinõppe vanem, kus ta juhib ettevõttes MLOpsi jõupingutusi. Ta aitab andmeteadlastel luua kiiremaid ja paremaid AI / ML tooteid, luues ettevõttes Data Science Platformi ja kombineerides mitmeid avatud lähtekoodiga lahendusi AWS-i teenustega.

João Moura on Hispaanias asuva AWS-i AI/ML-i spetsialistilahenduste arhitekt. Ta aitab kliente süvaõppemudeli suuremahulise koolituse ja järelduste optimeerimisega ning laiemalt AWS-i suuremahuliste ML-platvormide ehitamisel.

Miguel Ferreira töötab Soomes Helsingis asuvas AWSis Sr. Solutions Arhitektina. AI/ML on olnud eluaegne huvi ja ta on aidanud mitmel kliendil integreerida Amazon SageMakeri oma ML-i töövoogudesse.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• PlatoData.Network Vertikaalne generatiivne Ai. Jõustage ennast. Juurdepääs siia.
• PlatoAiStream. Web3 luure. Täiustatud teadmised. Juurdepääs siia.
• PlatoESG. Süsinik, CleanTech, Energia, Keskkond päikeseenergia, Jäätmekäitluse. Juurdepääs siia.
• PlatoTervis. Biotehnoloogia ja kliiniliste uuringute luureandmed. Juurdepääs siia.
• Allikas: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/