How To Scale Machine Learning Inference For Multi-tenant SaaS Use Cases

Republicat de Platon

Urmaritori: 0

Această postare este scrisă în colaborare cu Sowmya Manusani, inginer Sr. Staff Machine Learning la Zendesk

Zendesk este o companie SaaS care creează software de asistență, vânzări și implicarea clienților pentru toată lumea, având ca bază simplitatea. Ea se bucură de a face peste 170,000 de companii din întreaga lume să-și servească eficient sutele de milioane de clienți. Echipa de învățare automată de la Zendcaesk este responsabilă pentru îmbunătățirea experienței clienților echipelor pentru a obține cele mai bune rezultate. Combinând puterea datelor și a oamenilor, Zendesk oferă produse inteligente care își fac clienții mai productivi prin automatizarea muncii manuale.

Zendesk construiește produse ML din 2015, inclusiv Answer Bot, Predicția satisfacției, Indicații de conținut, Macro-uri sugerate, si multe altele. În ultimii câțiva ani, odată cu creșterea învățării profunde, în special în NLP, ei au văzut multe oportunități de a automatiza fluxurile de lucru și de a ajuta agenții să-și susțină clienții cu soluții Zendesk. Zendesk utilizează în prezent TensorFlow și PyTorch pentru a construi modele de învățare profundă.

Clienți precum Zendesk au construit afaceri de succes cu software ca serviciu (SaaS) pe Amazon Web Services (AWS). Un factor cheie pentru un model de afaceri SaaS de succes este capacitatea de a aplica multi-tenancy în aplicație și infrastructură. Acest lucru permite costuri și eficiență operațională, deoarece aplicația trebuie construită o singură dată, dar poate fi folosită de mai multe ori și infrastructura poate fi partajată. Vedem că mulți clienți construiesc sisteme sigure, eficiente din punct de vedere al costurilor, cu mai mulți chiriași pe AWS la toate nivelurile stivei, de la calcul, stocare, bază de date, până la rețea, iar acum vedem clienți care trebuie să le aplice în învățarea automată (ML). ).

Efectuarea unui compromis dificil între reutilizarea modelului și hiperpersonalizare

Multi-tenancy pentru afacerile SaaS înseamnă de obicei că o singură aplicație este reutilizată între mulți utilizatori (clienți SaaS). Acest lucru creează eficiență a costurilor și reduce cheltuielile operaționale. Cu toate acestea, modelele de învățare automată trebuie uneori să fie personalizate la un grad ridicat de specificitate (hiper-personalizate) pentru a face predicții precise. Aceasta înseamnă că paradigma SaaS „construiește o dată, folosește de mai multe ori” nu poate fi întotdeauna aplicată la ML dacă modelele au specificitate. Luați, de exemplu, cazul de utilizare al platformelor de asistență pentru clienți. Limba pe care utilizatorii o includ într-un bilet de asistență variază în funcție de faptul că este vorba despre o problemă de partajare („călătoria a durat prea mult”) sau de o problemă de cumpărare a îmbrăcămintei („decolorarea la spălare”). În acest caz de utilizare, îmbunătățirea acurateței predicției celei mai bune acțiuni de remediere poate necesita pregătirea unui model de procesare a limbajului natural (NLP) pe un set de date specific unui domeniu de afaceri sau unei verticale industriale. Zendesk se confruntă exact cu această provocare atunci când încearcă să folosească ML în soluțiile lor. Aveau nevoie să creeze mii de modele ML foarte personalizate, fiecare adaptat pentru un anumit client. Pentru a rezolva această provocare de implementare a mii de modele, în mod rentabil, Zendesk a apelat la Amazon SageMaker.

În această postare, arătăm cum să folosiți unele dintre funcțiile mai noi ale Amazon SageMaker, un serviciu de învățare automatizat complet gestionat, pentru a construi o capacitate de inferență ML cu mai mulți locatari. De asemenea, împărtășim un exemplu din lumea reală a modului în care Zendesk a obținut cu succes același rezultat prin implementarea unui mediu fericit între capacitatea de a susține hiperpersonalizarea în modelele lor de ML și utilizarea eficientă din punct de vedere al costurilor, partajată a infrastructurii folosind punctele finale multimodel SageMaker ( MME).

Puncte finale cu mai multe modele SageMaker

Punctele finale cu mai multe modele SageMaker vă permit să implementați mai multe modele în spatele unui singur punct final de inferență care poate conține una sau mai multe instanțe. Fiecare instanță este proiectată să încarce și să servească mai multe modele până la capacitatea sa de memorie și CPU. Cu această arhitectură, o afacere SaaS poate reduce costul în creștere liniar al găzduirii mai multor modele și poate realiza reutilizarea infrastructurii în concordanță cu modelul multi-tenancy aplicat în altă parte a stivei de aplicații.

Următoarea diagramă ilustrează arhitectura unui punct final cu mai multe modele SageMaker.

Punctul final multimodel SageMaker încarcă dinamic modelele de la Serviciul Amazon de stocare simplă (Amazon S3) când este invocat, în loc să descărcați toate modelele atunci când punctul final este creat pentru prima dată. Ca rezultat, o invocare inițială la un model ar putea vedea o latență de inferență mai mare decât inferențe ulterioare, care sunt finalizate cu o latență scăzută. Dacă modelul este deja încărcat pe container atunci când este invocat, atunci pasul de descărcare este omis și modelul returnează inferențe cu latență scăzută. De exemplu, să presupunem că aveți un model care este folosit doar de câteva ori pe zi. Este încărcat automat la cerere, în timp ce modelele accesate frecvent sunt păstrate în memorie și invocate cu o latență constant scăzută.

Să aruncăm o privire mai atentă asupra modului în care Zendesk a folosit SageMaker MME pentru a realiza o implementare ML rentabilă, la scară superioară, cu funcția ML Suggested Macros.

De ce Zendesk a construit modele hiperpersonalizate

Clienții Zendesk sunt răspândiți la nivel global în diferite verticale ale industriei, cu semantică diferită a biletelor de asistență. Prin urmare, pentru a-și servi cel mai bine clienții, aceștia trebuie adesea să construiască modele personalizate care sunt instruite pe date despre biletele de asistență specifice clientului pentru a identifica corect intenția, macrocomenzile și multe altele.

În octombrie 2021, au lansat o nouă funcție NLP ML, Suggested Macros, care recomandă macrocomenzi (acțiuni predefinite) bazate pe mii de predicții de model specifice clientului. Echipa ML Zendesk a construit un model de clasificator NLP bazat pe TensorFlow, instruit din istoricul anterior al conținutului biletelor și al macrocomenzilor per client. Cu aceste modele disponibile, este recomandată o predicție macro ori de câte ori un agent vede biletul (așa cum se arată în următoarea captură de ecran), care îl ajută pe agent să servească rapid clienții. Deoarece macrocomenzile sunt specifice clienților, Zendesk are nevoie de modele specifice clientului pentru a furniza predicții precise.

Sub capota Macro-urilor sugerate de Zendesk

Modelele de macro-uri sugerate sunt rețele neuronale bazate pe NLP, care au o dimensiune de aproximativ 7–15 MB. Principala provocare este de a pune în producție mii de aceste modele cu soluții rentabile, fiabile și scalabile.

Fiecare model are modele de trafic diferite, cu un minim de două solicitări pe secundă și un vârf de sute de solicitări pe secundă, servind milioane de predicții pe zi cu o latență a modelului de aproximativ 100 de milisecunde atunci când modelul este disponibil în memorie. Punctele finale SageMaker sunt implementate în mai multe regiuni AWS, deservând mii de solicitări pe minut per punct final.

Cu capacitatea sa de a găzdui mai multe modele pe un singur punct final, SageMaker a ajutat Zendesk să reducă cheltuielile generale de implementare și să creeze o soluție rentabilă în comparație cu implementarea unui punct final cu un singur model per client. Compromisul aici este un control mai mic asupra managementului per model; totuși, acesta este un domeniu în care Zendesk colaborează cu AWS pentru a îmbunătăți punctele finale cu mai multe modele.

Una dintre caracteristicile multi-modelului SageMaker este încărcarea lenenă a modelelor, adică modelele sunt încărcate în memorie atunci când sunt invocate pentru prima dată. Aceasta este pentru a optimiza utilizarea memoriei; cu toate acestea, provoacă creșteri ale timpului de răspuns la prima încărcare, ceea ce poate fi văzut ca o problemă de pornire la rece. Pentru Macro-urile sugerate, aceasta a fost o provocare; cu toate acestea, Zendesk a depășit acest lucru prin implementarea unei funcționalități de preîncărcare pe lângă furnizarea de puncte finale SageMaker pentru a încărca modelele în memorie înainte de a servi traficul de producție. În al doilea rând, MME descarcă din memorie modele utilizate rar, astfel încât pentru a obține o latență scăzută constantă pentru toate modelele și pentru a evita ca „vecinii zgomotoși” să afecteze alte modele mai puțin active, Zendesk colaborează cu AWS pentru a adăuga funcții noi, discutate mai târziu în postare, pentru a permite management mai explicit pe model. În plus, ca soluție intermediară, Zendesk a dimensionat flota MME pentru a minimiza descărcarea prea multor modele. Prin aceasta, Zendesk este capabil să ofere predicții tuturor clienților lor cu o latență scăzută, în jur de 100 de milisecunde, și să obțină în continuare economii de 90% a costurilor în comparație cu punctele finale dedicate.

În ceea ce privește MME dimensionat corect, Zendesk a observat în timpul testării de încărcare că a avea un număr mai mare de instanțe mai mici (disturbire la scalarea orizontală) în spatele MME a fost o alegere mai bună decât a avea mai puține instanțe de memorie mai mari (scalare verticală). Zendesk a observat că împachetarea prea multor modele (dincolo de 500 de modele TensorFlow în cazul lor) pe o singură instanță de memorie mare nu a funcționat bine, deoarece memoria nu este singura resursă a unei instanțe care poate fi un blocaj. Mai precis, ei au observat că TensorFlow a generat mai multe fire de execuție (3 x totalul vCPU-uri de instanță) per model, astfel încât încărcarea a peste 500 de modele pe o singură instanță a cauzat încălcarea limitelor la nivel de kernel pentru numărul maxim de fire care ar putea fi generate pe o instanță. O altă problemă legată de utilizarea mai puține, mai mari, a apărut atunci când Zendesk a experimentat throttling (ca mecanism de siguranță) în unele cazuri din spatele MME, deoarece rata de invocare a modelului unic pe secundă a depășit valoarea Server multimodel (MMS) pe o singură instanță ar putea gestiona în siguranță, fără a decolora instanța. Aceasta a fost o altă problemă care a fost rezolvată prin utilizarea a mai multe instanțe și mai mici.

Din perspectiva observabilității, care este o componentă crucială a oricărei aplicații de producție, Amazon CloudWatch metrici precum invocări, procesor, utilizarea memoriei și metrici specifice mai multor modele, cum ar fi modelele încărcate în memorie, timpul de încărcare a modelului, timpul de așteptare a încărcării modelului și accesarea cache a modelului sunt informative. Mai exact, defalcarea latenței modelului a ajutat Zendesk să înțeleagă problema pornirii la rece și impactul acesteia.

Sub capota scalarii automate MME

În spatele fiecărui punct final cu mai multe modele, există instanțe de găzduire model, așa cum este prezentat în diagrama următoare. Aceste instanțe încarcă și evacuează mai multe modele în și din memorie pe baza modelelor de trafic către modele.

SageMaker continuă să direcționeze cererile de inferență pentru un model către instanța în care modelul este deja încărcat, astfel încât cererile să fie servite din copia modelului stocată în cache (consultați următoarea diagramă, care arată calea cererii pentru prima solicitare de predicție față de cererea de predicție stocată în cache). cale). Cu toate acestea, dacă modelul primește multe solicitări de invocare și există instanțe suplimentare pentru punctul final cu mai multe modele, SageMaker direcționează unele solicitări către o altă instanță pentru a se adapta la creștere. Pentru a profita de scalarea automată a modelului în SageMaker, asigurați-vă că aveți Configurarea scalării automate a instanței pentru a furniza capacitate suplimentară de instanță. Configurați-vă politica de scalare la nivel de punct final fie cu parametri personalizați, fie cu invocări pe minut (recomandat) pentru a adăuga mai multe instanțe la flota de puncte finale.

Cazuri de utilizare cele mai potrivite pentru MME

Punctele finale cu mai multe modele SageMaker sunt potrivite pentru găzduirea unui număr mare de modele similare pe care le puteți servi printr-un container de servire partajat și nu este nevoie să accesați toate modelele în același timp. MME este cel mai potrivit pentru modele care sunt similare ca dimensiune și latențe de invocare. Unele variații în dimensiunea modelului sunt acceptabile; de exemplu, modelele Zendesk variază de la 10 la 50 Mb, ceea ce funcționează bine, dar variațiile de dimensiune care sunt un factor de 10, 50 sau 100 de ori mai mari nu sunt potrivite. Modelele mai mari pot determina un număr mai mare de încărcări și descarcări ale modelelor mai mici pentru a găzdui spațiu suficient de memorie, ceea ce poate duce la o latență suplimentară la punctul final. Diferențele în caracteristicile de performanță ale modelelor mai mari ar putea consuma, de asemenea, resurse precum procesorul în mod neuniform, ceea ce ar putea afecta alte modele asupra instanței.

MME este, de asemenea, conceput pentru modele de co-găzduire care utilizează același cadru ML, deoarece folosesc containerul partajat pentru a încărca mai multe modele. Prin urmare, dacă aveți o combinație de cadre ML în flota dvs. de modele (cum ar fi PyTorch și TensorFlow), punctele finale dedicate SageMaker sau găzduirea cu mai multe containere sunt o alegere mai bună. În cele din urmă, MME este potrivit pentru aplicațiile care pot tolera o penalizare ocazională de latență la pornire la rece, deoarece modelele utilizate rar pot fi descărcate în favoarea modelelor invocate frecvent. Dacă aveți o serie lungă de modele accesate rar, un terminal cu mai multe modele poate servi eficient acest trafic și poate permite economii semnificative de costuri.

Rezumat

În această postare, ați învățat cum se leagă SaaS și multi-tenancy cu ML și cum punctele finale cu mai multe modele SageMaker permit multi-tenancy și eficiența costurilor pentru inferența ML. Ați aflat despre cazul de utilizare Zendesk cu locatari multiple al modelelor ML pentru fiecare client și cum au găzduit mii de modele ML în SageMaker MME pentru caracteristica Macro-urilor sugerate și ați realizat economii de 90% la costuri la inferență în comparație cu punctele finale dedicate. Cazurile de utilizare de hiperpersonalizare pot necesita mii de modele ML, iar MME este o alegere rentabilă pentru acest caz de utilizare. Vom continua să aducem îmbunătățiri în MME pentru a vă permite să găzduiți modele cu latență scăzută și cu controale mai granulare pentru fiecare model personalizat. Pentru a începe cu MME, vezi Găzduiește mai multe modele într-un singur container în spatele unui punct final.

Despre Autori

Syed Jaffry este un arhitect senior de soluții cu AWS. Lucrează cu o gamă largă de companii, de la organizații mijlocii până la întreprinderi mari, de la servicii financiare până la ISV, ajutându-le să creeze și să opereze aplicații sigure, rezistente, scalabile și de înaltă performanță în cloud.

Sowmya Manusani este inginer senior de învățare automată a personalului la Zendesk. Lucrează la producția de funcții de învățare automată bazate pe NLP, care se concentrează pe îmbunătățirea productivității agenților pentru mii de clienți Zendesk Enterprise. Are experiență în construirea conductelor de instruire automatizate pentru mii de modele personalizate și în servirea acestora folosind aplicații sigure, rezistente, scalabile și de înaltă performanță. În timpul liber, îi place să rezolve puzzle-uri și să încerce să picteze.

Saurabh Trikande este Senior Product Manager pentru Amazon SageMaker Inference. Este pasionat de lucrul cu clienții și de a face învățarea automată mai accesibilă. În timpul liber, lui Saurabh îi place să facă drumeții, să învețe despre tehnologii inovatoare, să urmărească TechCrunch și să petreacă timpul cu familia sa.

Deepti Ragha este inginer de dezvoltare software în echipa Amazon SageMaker. Activitatea ei actuală se concentrează pe construirea de funcții pentru a găzdui eficient modele de învățare automată. În timpul liber, îi place să călătorească, să facă drumeții și să cultive plante.