Kako razširiti sklepanje strojnega učenja za primere uporabe SaaS z več najemniki

Ta objava je napisana skupaj s Sowmyo Manusani, višjo inženirko za strojno učenje pri Zendesku

Zendesk je podjetje SaaS, ki gradi programsko opremo za podporo, prodajo in sodelovanje s strankami za vsakogar, pri čemer je osnova preprostost. Uspeva pri tem, da več kot 170,000 podjetij po vsem svetu učinkovito služi svojim stotinam milijonov strank. Ekipa za strojno učenje pri Zendcaesku je odgovorna za izboljšanje skupin za uporabniško izkušnjo, da dosežejo najboljše. Z združevanjem moči podatkov in ljudi Zendesk zagotavlja inteligentne izdelke, ki njihove stranke z avtomatizacijo ročnega dela naredijo bolj produktivne.

Zendesk od leta 2015 gradi izdelke ML, vključno z Bot za odgovore, Napoved zadovoljstva, Vsebinske napotke, Predlagani makri, in še veliko več. V zadnjih nekaj letih so z rastjo globokega učenja, zlasti v NLP, videli veliko priložnosti za avtomatizacijo delovnih tokov in pomoč agentom pri podpori svojim strankam z rešitvami Zendesk. Zendesk trenutno uporablja TensorFlow in PyTorch za izdelavo modelov globokega učenja.

Stranke, kot je Zendesk, so zgradile uspešna, obsežna podjetja s programsko opremo kot storitvijo (SaaS) na spletnih storitvah Amazon (AWS). Ključno gonilo za uspešen poslovni model SaaS je zmožnost uporabe več najemnikov v aplikaciji in infrastrukturi. To omogoča stroškovno in operativno učinkovitost, ker je treba aplikacijo zgraditi samo enkrat, vendar jo je mogoče uporabiti večkrat in infrastrukturo je mogoče deliti. Vidimo, da številne stranke gradijo varne, stroškovno učinkovite sisteme z več najemniki na AWS na vseh ravneh sklada, od računalništva, shranjevanja, baze podatkov do mreženja, zdaj pa opažamo, da morajo stranke to uporabiti za strojno učenje (ML ).

Vzpostavitev težkega kompromisa med ponovno uporabo modela in hiperpersonalizacijo

Večnajemništvo za podjetja SaaS običajno pomeni, da se ena sama aplikacija ponovno uporabi med številnimi uporabniki (stranke SaaS). To ustvarja stroškovno učinkovitost in zmanjšuje operativne režijske stroške. Vendar je treba modele strojnega učenja včasih personalizirati do visoke stopnje specifičnosti (hiperpersonalizirane), da lahko naredijo natančne napovedi. To pomeni, da paradigme SaaS »sestavi enkrat, uporabi večkrat« ni mogoče vedno uporabiti za ML, če so modeli specifični. Vzemimo za primer primer uporabe platform za podporo strankam. Jezik, ki ga uporabniki vključijo v vozovnico za podporo, se razlikuje glede na to, ali gre za težavo z delitvijo vožnje (»vožnja je trajala predolgo«) ali težavo z nakupom oblačil (»razbarvanje pri pranju«). V tem primeru uporabe bo izboljšanje natančnosti napovedovanja najboljšega sanacijskega ukrepa morda zahtevalo usposabljanje modela obdelave naravnega jezika (NLP) na naboru podatkov, ki je specifičen za poslovno domeno ali panožno panogo. Zendesk se sooča s točno tem izzivom, ko poskuša uporabiti ML v svojih rešitvah. Ustvariti so morali na tisoče zelo prilagojenih modelov ML, od katerih je bil vsak prilagojen za določeno stranko. Za rešitev tega izziva uvajanja na tisoče modelov, stroškovno učinkovito, se je Zendesk obrnil na Amazon SageMaker.

V tej objavi prikazujemo, kako uporabljati nekatere novejše funkcije Amazon SageMaker, popolnoma upravljana storitev strojnega učenja, za izgradnjo zmožnosti sklepanja ML za več najemnikov. Delimo tudi primer iz resničnega sveta, kako je Zendesk uspešno dosegel enak rezultat z uvedbo srečnega medija med zmožnostjo podpore hiperpersonalizacije v njihovih modelih ML in stroškovno učinkovito skupno rabo infrastrukture z uporabo večmodelnih končnih točk SageMaker ( MME).

Večmodelne končne točke SageMaker

Večmodelne končne točke SageMaker vam omogočajo uvedbo več modelov za eno samo končno točko sklepanja, ki lahko vsebuje enega ali več primerkov. Vsaka instanca je zasnovana tako, da naloži in streže več modelov do svoje zmogljivosti pomnilnika in procesorja. S to arhitekturo lahko podjetje SaaS prekine linearno naraščajoče stroške gostovanja več modelov in doseže ponovno uporabo infrastrukture, ki je skladna z modelom več najemnikov, ki se uporablja drugje v skladu aplikacij.

Naslednji diagram ponazarja arhitekturo večmodelne končne točke SageMaker.

Večmodelna končna točka SageMaker dinamično nalaga modele iz Preprosta storitev shranjevanja Amazon (Amazon S3), ko je priklican, namesto da prenese vse modele, ko je končna točka prvič ustvarjena. Posledično se lahko pri začetnem priklicu modela pojavi višja zakasnitev sklepanja kot pri poznejših sklepih, ki so dokončani z nizko zakasnitvijo. Če je model ob priklicu že naložen v vsebnik, se korak prenosa preskoči in model vrne sklepe z nizko zakasnitvijo. Recimo, da imate model, ki ga uporabljate le nekajkrat na dan. Samodejno se naloži na zahtevo, medtem ko se pogosto dostopni modeli ohranijo v pomnilniku in prikličejo z dosledno nizko zakasnitvijo.

Oglejmo si podrobneje, kako je Zendesk uporabil SageMaker MME za doseganje stroškovno učinkovite uvedbe ML v hiperrazsežnosti s svojo funkcijo Suggested Macros ML.

Zakaj je Zendesk zgradil hiperpersonalizirane modele

Stranke podjetja Zendesk so razpršene po celem svetu v različnih panožnih vertikalah z različno semantiko vstopnic za podporo. Zato morajo, da bi najbolje služili svojim strankam, pogosto zgraditi prilagojene modele, ki so usposobljeni na podatkih o vozovnicah za podporo, specifičnih za stranko, da pravilno prepoznajo namere, makre in drugo.

Oktobra 2021 so izdali novo funkcijo NLP ML, Suggested Macros, ki priporoča makre (vnaprej določena dejanja) na podlagi tisočih napovedi modela za posamezne stranke. Ekipa Zendesk ML je zgradila model NLP klasifikatorja, ki temelji na TensorFlowu in je bil usposobljen iz prejšnje zgodovine vsebine vozovnic in makrov na stranko. Pri teh modelih, ki so na voljo, je priporočljivo makro predvidevanje vsakič, ko si agent ogleda vstopnico (kot je prikazano na naslednjem posnetku zaslona), kar agentu pomaga pri hitri oskrbi strank. Ker so makri specifični za stranke, Zendesk potrebuje modele, specifične za stranke, da služi natančnim napovedim.

Pod pokrovom Zendeskovih predlaganih makrov

Predlagani modeli makrov so nevronske mreže, ki temeljijo na NLP in so velike približno 7–15 MB. Glavni izziv je dati na tisoče teh modelov v proizvodnjo s stroškovno učinkovitimi, zanesljivimi in razširljivimi rešitvami.

Vsak model ima različne vzorce prometa z najmanj dvema zahtevama na sekundo in največ sto zahtevami na sekundo, ki služijo milijonom napovedi na dan z zakasnitvijo modela približno 100 milisekund, ko je model na voljo v pomnilniku. Končne točke SageMaker so nameščene v več regijah AWS in služijo na tisoče zahtev na minuto na končno točko.

S svojo sposobnostjo gostovanja več modelov na eni končni točki je SageMaker pomagal Zendesku zmanjšati stroške uvajanja in ustvariti stroškovno učinkovito rešitev v primerjavi z uvajanjem končne točke enega modela na stranko. Kompromis tukaj je manjši nadzor nad upravljanjem po modelu; vendar je to področje, kjer Zendesk sodeluje z AWS za izboljšanje končnih točk z več modeli.

Ena od večmodelnih funkcij SageMaker je leno nalaganje modelov, kar pomeni, da se modeli naložijo v pomnilnik, ko so prvič priklicani. To je za optimizacijo uporabe pomnilnika; vendar povzroča skoke odzivnega časa pri prvi obremenitvi, kar lahko vidimo kot težavo s hladnim zagonom. Za predlagane makre je bil to izziv; vendar je Zendesk to premagal z implementacijo funkcije prednalaganja na vrhu zagotavljanja končne točke SageMaker za nalaganje modelov v pomnilnik, preden služi produkcijskemu prometu. Drugič, MME razloži redko uporabljene modele iz pomnilnika, tako da Zendesk sodeluje z AWS, da bi dosegel dosledno nizko zakasnitev na vseh modelih in preprečil, da bi "hrupni sosedje" vplivali na druge manj aktivne modele, dodal nove funkcije, o katerih bomo razpravljali kasneje v objavi, da bi omogočili bolj jasno upravljanje po modelu. Poleg tega ima Zendesk kot vmesno rešitev pravilno velikost voznega parka MME, da zmanjša preveč razkladanja modelov. S tem lahko Zendesk postreže z napovedmi vsem svojim strankam z nizko zakasnitvijo, približno 100 milisekund, in še vedno doseže 90-odstotni prihranek stroškov v primerjavi z namenskimi končnimi točkami.

Pri MME prave velikosti je Zendesk med testiranjem obremenitve opazil, da je večje število manjših primerkov (pristranskost pri vodoravnem skaliranju) za MME boljša izbira kot imeti manj večjih primerkov pomnilnika (navpično skaliranje). Zendesk je opazil, da bin pakiranje preveč modelov (nad 500 modelov TensorFlow v njihovem primeru) na en sam velik primerek pomnilnika ni delovalo dobro, ker pomnilnik ni edini vir na primerku, ki je lahko ozko grlo. Natančneje, opazili so, da je TensorFlow ustvaril več niti (3 x skupni vCPE instance) na model, tako da je nalaganje več kot 500 modelov na eno instanco povzročilo prekoračitev omejitev ravni jedra pri največjem številu niti, ki jih je mogoče ustvariti na instanci. Druga težava pri uporabi manjšega števila večjih primerkov se je pojavila, ko je Zendesk izkusil dušenje (kot varnostni mehanizem) na nekaterih primerkih za MME, ker je edinstvena stopnja priklica modela na sekundo presegla tisto, kar Strežnik z več modeli (MMS) na enem primerku lahko varno obravnava, ne da bi primerek porjavel. To je bila še ena težava, ki je bila rešena z uporabo več in manjših primerkov.

Z vidika opazljivosti, ki je ključni sestavni del vsake proizvodne aplikacije, amazoncloudwatch metrike, kot so klici, CPE, izkoriščenost pomnilnika, in metrike, specifične za več modelov, kot so naloženi modeli v pomnilniku, čas nalaganja modela, čakalni čas nalaganja modela in zadetek predpomnilnika modela, so informativne narave. Natančneje, razčlenitev zakasnitve modela je Zendesku pomagala razumeti problem hladnega zagona in njegov vpliv.

Pod pokrovom samodejnega skaliranja MME

Za vsako končno točko z več modeli so primerki gostovanja modela, kot je prikazano v naslednjem diagramu. Ti primerki naložijo in odstranijo več modelov v pomnilnik in iz njega na podlagi vzorcev prometa do modelov.

SageMaker še naprej usmerja zahteve za sklepanje za model do primerka, kjer je model že naložen, tako da se zahteve strežejo iz predpomnjene kopije modela (glejte naslednji diagram, ki prikazuje pot zahteve za prvo zahtevo za predvidevanje v primerjavi s predpomnjeno zahtevo za predvidevanje pot). Če pa model prejme veliko zahtev za priklic in obstajajo dodatni primerki za končno točko več modelov, SageMaker usmeri nekatere zahteve v drug primerek, da se prilagodi povečanju. Če želite izkoristiti avtomatizirano skaliranje modela v SageMakerju, se prepričajte, da imate nastavljeno samodejno skaliranje primerka za zagotovitev dodatne zmogljivosti primerka. Nastavite svojo politiko skaliranja na ravni končne točke s parametri po meri ali klici na minuto (priporočeno), da dodate več primerkov v floto končnih točk.

Najbolj primerni primeri uporabe za MME

Večmodelne končne točke SageMaker so zelo primerne za gostovanje velikega števila podobnih modelov, ki jih lahko postrežete prek skupnega vsebnika za streženje in vam ni treba dostopati do vseh modelov hkrati. MME je najbolj primeren za modele, ki so podobni po velikosti in zakasnitvah priklica. Nekatere razlike v velikosti modela so sprejemljive; Zendeskovi modeli se na primer gibljejo med 10–50 Mb, kar deluje dobro, vendar 10-, 50- ali 100-krat večje razlike v velikosti niso primerne. Večji modeli lahko povzročijo večje število nalaganj in razkladanj manjših modelov, da se prilagodi dovolj pomnilniškega prostora, kar lahko povzroči dodatno zakasnitev na končni točki. Razlike v zmogljivostnih karakteristikah večjih modelov lahko tudi neenakomerno porabljajo vire, kot je CPE, kar lahko vpliva na druge modele v instanci.

MME je zasnovan tudi za sogostovanje modelov, ki uporabljajo isti okvir ML, ker uporabljajo skupni vsebnik za nalaganje več modelov. Če imate torej v svoji floti modelov mešanico ogrodij ML (kot sta PyTorch in TensorFlow), so namenske končne točke SageMaker ali gostovanje z več vsebniki boljša izbira. Končno je MME primeren za aplikacije, ki lahko dopuščajo občasno kazen zakasnitve hladnega zagona, ker se lahko redko uporabljeni modeli razbremenijo v korist pogosto klicanih modelov. Če imate dolg rep modelov, do katerih dostopate redko, lahko končna točka z več modeli učinkovito služi temu prometu in omogoči znatne prihranke stroškov.

Povzetek

V tej objavi ste izvedeli, kako sta SaaS in večnajemništvo povezana z ML in kako večmodelne končne točke SageMaker omogočajo večnajemništvo in stroškovno učinkovitost za sklepanje ML. Izvedeli ste o primeru Zendeskove uporabe z več najemniki modelov ML na stranko in o tem, kako so gostili na tisoče modelov ML v SageMaker MME za svojo funkcijo predlaganih makrov in dosegli 90-odstotni prihranek stroškov pri sklepanju v primerjavi z namenskimi končnimi točkami. Primeri uporabe hiperpersonalizacije lahko zahtevajo na tisoče modelov ML, MME pa je stroškovno učinkovita izbira za ta primer uporabe. Še naprej bomo izboljševali MME, da vam bomo omogočili gostovanje modelov z nizko zakasnitvijo in z bolj podrobnimi kontrolami za vsak prilagojen model. Če želite začeti z MME, glejte Gostite več modelov v enem vsebniku za eno končno točko.

---

O avtorjih

Syed Jaffry je starejši arhitekt rešitev pri AWS. Sodeluje s številnimi podjetji, od srednje velikih organizacij do velikih podjetij, finančnih storitev do ISV-jev, pri čemer jim pomaga zgraditi in upravljati varne, prožne, razširljive in visoko zmogljive aplikacije v oblaku.

Sowmya Manusani je višji kadrovski inženir strojnega učenja pri Zendesku. Dela na produkciji funkcij strojnega učenja, ki temeljijo na NLP in se osredotočajo na izboljšanje produktivnosti agentov za tisoče strank Zendesk Enterprise. Ima izkušnje z gradnjo avtomatiziranih cevovodov za usposabljanje za tisoče prilagojenih modelov in njihovo strežbo z uporabo varnih, prožnih, razširljivih in visoko zmogljivih aplikacij. V prostem času rada rešuje uganke in se preizkuša v slikanju.

Saurabh Trikande je višji produktni vodja za Amazon SageMaker Inference. Navdušuje ga delo s strankami in omogočanje dostopnejšega strojnega učenja. V prostem času Saurabh uživa v pohodništvu, spoznavanju inovativnih tehnologij, spremlja TechCrunch in preživlja čas s svojo družino.

Deepti Ragha je inženir za razvoj programske opreme v ekipi Amazon SageMaker. Njeno trenutno delo se osredotoča na gradnjo funkcij za učinkovito gostovanje modelov strojnega učenja. V prostem času rada potuje, planinari in goji rastline.

• Coinsmart. Najboljša evropska borza bitcoinov in kriptovalut.
• Platoblockchain. Web3 Metaverse Intelligence. Razširjeno znanje. PROST DOSTOP.
• CryptoHawk. Altcoin radar. Brezplačen preizkus.
• Vir: https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/