Cum Veriff a redus timpul de implementare cu 80% folosind punctele finale multimodel Amazon SageMaker | Amazon Web Services

Veriff este un partener al unei platforme de verificare a identității pentru organizațiile inovatoare orientate spre creștere, inclusiv pionierii în servicii financiare, FinTech, cripto, jocuri, mobilitate și piețe online. Ele oferă tehnologie avansată care combină automatizarea bazată pe inteligență artificială cu feedback uman, cunoștințe profunde și expertiză.

Veriff oferă o infrastructură dovedită care le permite clienților să aibă încredere în identitățile și atributele personale ale utilizatorilor lor în toate momentele relevante din călătoria lor către client. Veriff este de încredere de către clienți precum Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot și Wise.

Ca soluție bazată pe inteligență artificială, Veriff trebuie să creeze și să ruleze zeci de modele de învățare automată (ML) într-un mod rentabil. Aceste modele variază de la modele ușoare bazate pe arbore până la modele de deep learning computer vision, care trebuie să ruleze pe GPU-uri pentru a obține o latență scăzută și pentru a îmbunătăți experiența utilizatorului. De asemenea, Veriff adaugă în prezent mai multe produse la oferta sa, vizând o soluție hiper-personalizată pentru clienții săi. Servirea diferitelor modele pentru diferiți clienți se adaugă la necesitatea unei soluții scalabile de servire a modelelor.

În această postare, vă arătăm cum Veriff și-a standardizat fluxul de lucru de implementare a modelului folosind Amazon SageMaker, reducând costurile și timpul de dezvoltare.

Provocări legate de infrastructură și dezvoltare

Arhitectura de backend Veriff se bazează pe un model de microservicii, cu servicii rulând pe diferite clustere Kubernetes găzduite pe infrastructura AWS. Această abordare a fost utilizată inițial pentru toate serviciile companiei, inclusiv microservicii care rulează modele costisitoare de ML cu viziune pe computer.

Unele dintre aceste modele au necesitat implementare pe instanțele GPU. Conștient de costul comparativ mai mare al tipurilor de instanțe susținute de GPU, Veriff a dezvoltat a soluție personalizată pe Kubernetes pentru a partaja resursele unui anumit GPU între diferite replici de servicii. Un singur GPU are de obicei suficientă VRAM pentru a stoca în memorie mai multe modele de computer vision Veriff.

Deși soluția a atenuat costurile GPU-ului, a venit și cu constrângerea pe care oamenii de știință de date trebuiau să indice în prealabil câtă memorie GPU ar avea nevoie de modelul lor. În plus, DevOps a fost împovărat cu furnizarea manuală a instanțelor GPU ca răspuns la modelele de cerere. Acest lucru a cauzat o suprasarcină operațională și supraprovizionare a instanțelor, ceea ce a dus la un profil de cost suboptim.

În afară de furnizarea GPU, această configurare a cerut, de asemenea, cercetătorilor de date să construiască un wrapper API REST pentru fiecare model, care era necesar pentru a oferi o interfață generică pentru consumarea altor servicii ale companiei și pentru a încapsula preprocesarea și postprocesarea datelor modelului. Aceste API-uri necesitau cod de nivel de producție, ceea ce a făcut ca oamenii de știință să producă modele să fie dificilă.

Echipa Veriff a platformei de știință a datelor a căutat modalități alternative la această abordare. Obiectivul principal a fost de a sprijini oamenii de știință de date ai companiei cu o tranziție mai bună de la cercetare la producție, prin furnizarea de conducte de implementare mai simple. Obiectivul secundar a fost reducerea costurilor operaționale ale furnizării instanțelor GPU.

Prezentare generală a soluțiilor

Veriff a necesitat o nouă soluție care a rezolvat două probleme:

• Permiteți construirea de pachete API REST în jurul modelelor ML cu ușurință
• Permiteți gestionarea capacității de instanță GPU furnizată în mod optim și, dacă este posibil, automat

În cele din urmă, echipa platformei ML a convergit asupra deciziei de a utiliza Puncte finale cu mai multe modele Sagemaker (MME-uri). Această decizie a fost condusă de sprijinul MME pentru NVIDIA Triton Inference Server (un server axat pe ML, care facilitează împachetarea modelelor ca API-uri REST; Veriff deja experimenta deja Triton), precum și capacitatea sa de a gestiona în mod nativ scalarea automată a instanțelor GPU prin politici simple de scalare automată.

Două MME-uri au fost create la Veriff, unul pentru montaj și unul pentru producție. Această abordare le permite să ruleze pași de testare într-un mediu de staging fără a afecta modelele de producție.

MME-uri SageMaker

SageMaker este un serviciu complet gestionat care oferă dezvoltatorilor și cercetătorilor de date capacitatea de a construi, antrena și implementa rapid modele ML. SageMaker MME oferă o soluție scalabilă și rentabilă pentru implementarea unui număr mare de modele pentru inferență în timp real. MME-urile folosesc un container de servire partajat și o flotă de resurse care pot folosi instanțe accelerate, cum ar fi GPU-urile, pentru a găzdui toate modelele dvs. Acest lucru reduce costurile de găzduire prin maximizarea utilizării punctelor finale în comparație cu utilizarea punctelor finale cu un singur model. De asemenea, reduce costul general de implementare, deoarece SageMaker gestionează încărcarea și descărcarea modelelor în memorie și scalarea acestora în funcție de tiparele de trafic ale punctului final. În plus, toate punctele finale în timp real SageMaker beneficiază de capabilități încorporate de gestionare și monitorizare a modelelor, cum ar fi inclusiv variante de umbră, scalare automată, și integrarea nativă cu Amazon CloudWatch (pentru mai multe informații, consultați Valori CloudWatch pentru implementări de puncte finale cu mai multe modele).

Modele personalizate de ansamblu Triton

Au existat mai multe motive pentru care Veriff a decis să folosească Triton Inference Server, principalele fiind:

• Le permite oamenilor de știință de date să construiască API-uri REST din modele prin aranjarea fișierelor artefacte model într-un format de director standard (fără soluție de cod)
• Este compatibil cu toate cadrele AI majore (PyTorch, Tensorflow, XGBoost și multe altele)
• Oferă optimizări de nivel scăzut și server specifice ML, cum ar fi loturi dinamice a cererilor

Utilizarea Triton permite oamenilor de știință să implementeze modele cu ușurință, deoarece trebuie doar să construiască depozite de modele formatate în loc să scrie cod pentru a construi API-uri REST (Triton acceptă, de asemenea, Modele Python dacă este necesară logica de inferență personalizată). Acest lucru scade timpul de implementare a modelelor și le oferă cercetătorilor de date mai mult timp pentru a se concentra pe construirea modelelor în loc să le implementeze.

O altă caracteristică importantă a lui Triton este că vă permite să construiți ansambluri model, care sunt grupuri de modele care sunt legate între ele. Aceste ansambluri pot fi conduse ca și cum ar fi un singur model Triton. În prezent, Veriff folosește această caracteristică pentru a implementa logica de preprocesare și postprocesare cu fiecare model ML folosind modele Python (după cum am menționat mai devreme), asigurându-se că nu există nepotriviri în datele de intrare sau în ieșirea modelului atunci când modelele sunt utilizate în producție.

Iată cum arată un depozit tipic de modele Triton pentru această sarcină de lucru:

model.py fișierul conține cod de preprocesare și postprocesare. Greutățile modelului antrenat sunt în screen_detection_inferencer director, sub versiunea modelului 1 (modelul este în format ONNX în acest exemplu, dar poate fi și TensorFlow, PyTorch sau altele). Definiția modelului de ansamblu este în screen_detection_pipeline director, unde intrările și ieșirile dintre pași sunt mapate într-un fișier de configurare.

Dependențe suplimentare necesare pentru a rula modelele Python sunt detaliate în a requirements.txt fișier și trebuie să fie împachetat în conda pentru a construi un mediu Conda (python_env.tar.gz). Pentru mai multe informații, consultați Gestionarea runtime și biblioteci Python. De asemenea, trebuie să indice fișierele de configurare pentru pașii Python python_env.tar.gz folosind EXECUTION_ENV_PATH directivă.

Folderul model trebuie apoi să fie comprimat TAR și redenumit folosind model_version.txt. În sfârșit, rezultatul <model_name>_<model_version>.tar.gz fișierul este copiat în Serviciul Amazon de stocare simplă Bucket (Amazon S3) conectat la MME, permițând SageMaker să detecteze și să servească modelul.

Versiune model și implementare continuă

După cum a arătat secțiunea anterioară, construirea unui depozit de modele Triton este simplă. Cu toate acestea, rularea tuturor pașilor necesari pentru a-l implementa este plictisitoare și predispusă la erori, dacă este executată manual. Pentru a depăși acest lucru, Veriff a construit un monorepo care conține toate modelele care urmează să fie implementate în MME, în care oamenii de știință de date colaborează într-o abordare asemănătoare Gitflow. Acest monorepo are următoarele caracteristici:

• Este gestionat folosind Pantaloni.
• Instrumentele de calitate a codului, cum ar fi Black și MyPy, sunt aplicate folosind Pants.
• Testele unitare sunt definite pentru fiecare model, care verifică dacă rezultatul modelului este rezultatul așteptat pentru o anumită intrare a modelului.
• Greutățile modelului sunt stocate alături de depozitele de modele. Aceste greutăți pot fi fișiere binare mari, deci DVC este folosit pentru a le sincroniza cu Git într-o manieră versionată.

Acest monorepo este integrat cu un instrument de integrare continuă (CI). Pentru fiecare împingere nouă către repo sau model nou, se parcurg următorii pași:

1. Treci verificarea calității codului.
2. Descărcați greutățile modelului.
3. Construiește mediul Conda.
4. Porniți un server Triton folosind mediul Conda și utilizați-l pentru a procesa cererile definite în testele unitare.
5. Construiți fișierul TAR model final (<model_name>_<model_version>.tar.gz).

Acești pași se asigură că modelele au calitatea necesară pentru implementare, astfel încât pentru fiecare împingere către o ramură repo, fișierul TAR rezultat este copiat (într-un alt pas CI) în compartimentul S3 de staging. Când se fac împingeri în ramura principală, fișierul model este copiat în găleata S3 de producție. Următoarea diagramă ilustrează acest sistem CI/CD.

Beneficii de cost și viteza de implementare

Utilizarea MME-urilor permite Veriff să utilizeze o abordare monorepo pentru a implementa modele în producție. În rezumat, noul flux de lucru de implementare a modelului Veriff constă din următorii pași:

1. Creați o ramură în monorepo cu noul model sau versiunea modelului.
2. Definiți și rulați teste unitare într-o mașină de dezvoltare.
3. Împingeți ramura când modelul este gata să fie testat în mediul de pregătire.
4. Îmbinați ramura în principal atunci când modelul este gata pentru a fi utilizat în producție.

Cu această nouă soluție în vigoare, implementarea unui model la Veriff este o parte simplă a procesului de dezvoltare. Timpul de dezvoltare a noului model a scăzut de la 10 zile la o medie de 2 zile.

Funcțiile de furnizare a infrastructurii gestionate și scalare automată ale SageMaker au adus beneficii suplimentare Veriff. Au folosit InvocationsPerInstance Valoarea CloudWatch pentru scalare în funcție de tiparele de trafic, economisind costuri fără a sacrifica fiabilitatea. Pentru a defini valoarea pragului pentru măsurare, au efectuat teste de încărcare pe punctul final de staging pentru a găsi cel mai bun compromis între latență și cost.

După implementarea a șapte modele de producție în MME-uri și analizarea cheltuielilor, Veriff a raportat o reducere cu 75% a costurilor de funcționare a modelului GPU în comparație cu soluția originală bazată pe Kubernetes. Costurile operaționale au fost, de asemenea, reduse, deoarece sarcina de a furniza manual instanțe a fost ridicată de la inginerii DevOps ai companiei.

Concluzie

În această postare, am analizat de ce Veriff a ales MME-urile Sagemaker în locul implementării modelelor autogestionate pe Kubernetes. SageMaker preia sarcinile grele nediferențiate, permițând Veriff să scadă timpul de dezvoltare a modelului, să mărească eficiența ingineriei și să scadă dramatic costul pentru inferența în timp real, menținând în același timp performanța necesară pentru operațiunile lor critice pentru afaceri. În cele din urmă, am prezentat pipeline CI/CD de implementare a modelului Veriff, simplă, dar eficientă, și mecanismul de versiune a modelului, care poate fi folosit ca implementare de referință pentru combinarea celor mai bune practici de dezvoltare de software și MME-uri SageMaker. Puteți găsi exemple de cod pentru găzduirea mai multor modele folosind MME-uri SageMaker GitHub.

---

Despre Autori

Ricard Borràs este Senior Machine Learning la Veriff, unde conduce eforturile MLOps în companie. El îi ajută pe oamenii de știință de date să construiască produse AI/ML mai rapide și mai bune prin construirea unei platforme Data Science la companie și combinând mai multe soluții open source cu serviciile AWS.

João Moura este arhitect specializat în soluții AI/ML la AWS, cu sediul în Spania. El ajută clienții cu formarea la scară largă a modelului de învățare profundă și optimizarea inferenței și, mai larg, construind platforme ML la scară largă pe AWS.

Miguel Ferreira lucrează ca arhitect senior de soluții la AWS cu sediul în Helsinki, Finlanda. AI/ML a fost un interes de-a lungul vieții și a ajutat mai mulți clienți să integreze Amazon SageMaker în fluxurile lor de lucru ML.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
• Sursa: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/