Sådan skalerer du maskinlæringsslutning til SaaS-brugssager med flere lejere

Dette indlæg er skrevet sammen med Sowmya Manusani, Sr. Staff Machine Learning Engineer hos Zendesk

Zendesk er en SaaS-virksomhed, der bygger support-, salgs- og kundeengagementsoftware til alle med enkelhed som grundlag. Det trives med at få over 170,000 virksomheder verden over til at betjene deres hundreder af millioner af kunder effektivt. Machine Learning-teamet hos Zendcaesk er ansvarligt for at forbedre Customer Experience-teams for at opnå deres bedste. Ved at kombinere kraften fra data og mennesker leverer Zendesk intelligente produkter, der gør deres kunder mere produktive ved at automatisere manuelt arbejde.

Zendesk har bygget ML-produkter siden 2015, bl.a Svar Bot, Forudsigelse af tilfredshed, Indhold stikord, Foreslåede makroer, og mange flere. I de sidste par år, med væksten i deep learning, især i NLP, så de mange muligheder for at automatisere arbejdsgange og hjælpe agenter med at støtte deres kunder med Zendesk-løsninger. Zendesk bruger i øjeblikket TensorFlow og PyTorch til at bygge deep learning-modeller.

Kunder som Zendesk har bygget succesrige, højskala software as a service-virksomheder (SaaS) på Amazon Web Services (AWS). En vigtig drivkraft for en succesfuld SaaS-forretningsmodel er evnen til at anvende multi-tenancy i applikationen og infrastrukturen. Dette muliggør omkostnings- og driftseffektivitet, fordi applikationen kun skal bygges én gang, men den kan bruges mange gange, og infrastrukturen kan deles. Vi ser, at mange kunder bygger sikre, omkostningseffektive, multi-tenant-systemer på AWS på alle lag af stakken, fra computer, storage, database til netværk, og nu ser vi, at kunder har brug for at anvende det til maskinlæring (ML).

At gøre den vanskelige afvejning mellem modelgenbrug og hyper-personalisering

Multi-tenancy for SaaS-virksomheder betyder typisk, at en enkelt applikation genbruges mellem mange brugere (SaaS-kunder). Dette skaber omkostningseffektivitet og sænker driftsomkostningerne. Maskinlæringsmodeller skal dog nogle gange tilpasses til en høj grad af specificitet (hyperpersonlig) for at kunne lave præcise forudsigelser. Dette betyder, at "byg én gang, brug mange gange" SaaS-paradigmet ikke altid kan anvendes på ML, hvis modellerne har specificitet. Tag for eksempel brugen af ​​kundesupportplatforme. Det sprog, som brugerne inkluderer i en supportbillet, varierer afhængigt af, om det er et spørgsmål om kørselsdeling ("turen tog for lang tid") eller et spørgsmål om køb af tøj ("misfarvning ved vask"). I dette tilfælde kan en forbedring af nøjagtigheden af ​​at forudsige den bedste afhjælpningshandling kræve træning af en NLP-model (natural language processing) på et datasæt, der er specifikt for et forretningsdomæne eller en branchevertikal. Zendesk står over for netop denne udfordring, når de forsøger at udnytte ML i deres løsninger. De havde brug for at skabe tusindvis af meget tilpassede ML-modeller, hver skræddersyet til en specifik kunde. For at løse denne udfordring med at implementere tusindvis af modeller, omkostningseffektivt, henvendte Zendesk sig til Amazon SageMaker.

I dette indlæg viser vi, hvordan du bruger nogle af de nyere funktioner i Amazon SageMaker, en fuldt administreret maskinlæringstjeneste, for at bygge en multi-tenant ML-inferens-kapacitet. Vi deler også et eksempel fra den virkelige verden på, hvordan Zendesk med succes opnåede det samme resultat ved at implementere et lykkeligt medium mellem at kunne understøtte hyper-personalisering i deres ML-modeller og den omkostningseffektive, fælles brug af infrastruktur ved hjælp af SageMaker multi-model endpoints (MME).

SageMaker multi-model slutpunkter

SageMaker multi-model endpoints gør det muligt for dig at implementere flere modeller bag et enkelt slutningsendepunkt, der kan indeholde en eller flere forekomster. Hver instans er designet til at indlæse og betjene flere modeller op til dens hukommelse og CPU-kapacitet. Med denne arkitektur kan en SaaS-virksomhed bryde de lineært stigende omkostninger ved hosting af flere modeller og opnå genbrug af infrastruktur i overensstemmelse med multi-tenancy-modellen, der anvendes andre steder i applikationsstakken.

Følgende diagram illustrerer arkitekturen af ​​et SageMaker multi-model slutpunkt.

SageMaker multi-model slutpunktet indlæser dynamisk modeller fra Amazon Simple Storage Service (Amazon S3), når den aktiveres, i stedet for at downloade alle modellerne, når slutpunktet først oprettes. Som et resultat heraf kan en indledende invokation til en model se højere slutningsforsinkelse end de efterfølgende slutninger, som afsluttes med lav latens. Hvis modellen allerede er indlæst på containeren, når den startes, springes downloadtrinnet over, og modellen returnerer inferenserne med lav latenstid. Antag for eksempel, at du har en model, der kun bliver brugt få gange om dagen. Den indlæses automatisk efter behov, mens hyppigt tilgåede modeller bevares i hukommelsen og påkaldes med konsekvent lav latenstid.

Lad os se nærmere på, hvordan Zendesk brugte SageMaker MME til at opnå omkostningseffektiv, hyperskaleret ML-implementering med deres Suggested Macros ML-funktion.

Hvorfor Zendesk byggede hyper-personaliserede modeller

Zendesks kunder er spredt globalt i forskellige branchevertikaler med forskellig supportbillet-semantik. For at kunne betjene deres kunder bedst, skal de ofte bygge personlige modeller, der er trænet i kundespecifikke supportbilletdata for korrekt at identificere hensigter, makroer og mere.

I oktober 2021 udgav de en ny NLP ML-funktion, Suggested Macros, som anbefaler makroer (foruddefinerede handlinger) baseret på tusindvis af kundespecifikke modelforudsigelser. Zendesks ML-team byggede en TensorFlow-baseret NLP-klassificeringsmodel, trænet fra den tidligere historie med billetindhold og makroer pr. kunde. Med disse modeller tilgængelige, anbefales en makroforudsigelse, hver gang en agent ser billetten (som vist på følgende skærmbillede), hvilket hjælper agenten med at betjene kunderne hurtigt. Fordi makroer er specifikke for kunder, har Zendesk brug for kundespecifikke modeller til at tjene præcise forudsigelser.

Under motorhjelmen på Zendesks Suggested Macros

Foreslåede makromodeller er NLP-baserede neurale net, der er omkring 7-15 MB store. Hovedudfordringen er at sætte tusindvis af disse modeller i produktion med omkostningseffektive, pålidelige og skalerbare løsninger.

Hver model har forskellige trafikmønstre, med et minimum på to anmodninger i sekundet og et toppunkt på hundredvis af anmodninger i sekundet, der serverer millioner af forudsigelser om dagen med en modelforsinkelse på cirka 100 millisekunder, når modellen er tilgængelig i hukommelsen. SageMaker-slutpunkter er implementeret i flere AWS-regioner, der betjener tusindvis af anmodninger pr. minut pr. slutpunkt.

Med sin evne til at hoste flere modeller på et enkelt slutpunkt, hjalp SageMaker Zendesk med at reducere implementeringsomkostninger og skabe en omkostningseffektiv løsning sammenlignet med implementering af et enkelt-model slutpunkt pr. kunde. Afvejningen her er mindre kontrol med styring pr. model; dette er dog et område, hvor Zendesk samarbejder med AWS for at forbedre multi-model endpoints.

En af SageMaker multi-model funktioner er doven indlæsning af modeller, det vil sige, modeller indlæses i hukommelsen, når de aktiveres for første gang. Dette er for at optimere hukommelsesudnyttelsen; det forårsager dog reaktionstidsspidser ved første belastning, hvilket kan ses som et koldstartsproblem. For foreslåede makroer var dette en udfordring; Imidlertid overvandt Zendesk dette ved at implementere en forudindlæsningsfunktionalitet oven på SageMaker-slutpunktsforsyningen for at indlæse modellerne i hukommelsen, før de betjener produktionstrafik. For det andet aflæser MME sjældent brugte modeller fra hukommelsen, så for at opnå konsistent lav latency på alle modellerne og undgå at "støjende naboer" påvirker andre mindre aktive modeller, samarbejder Zendesk med AWS for at tilføje nye funktioner, diskuteret senere i indlægget, for at muliggøre mere eksplicit styring pr. model. Derudover har Zendesk, som en midlertidig løsning, tilpasset MME-flåden i den rigtige størrelse for at minimere aflæsning af for mange modeller. Med dette er Zendesk i stand til at levere forudsigelser til alle deres kunder med lav latenstid, omkring 100 millisekunder, og stadig opnå 90 % omkostningsbesparelser sammenlignet med dedikerede slutpunkter.

På MME i højre størrelse observerede Zendesk under belastningstestning, at det at have et højere antal mindre forekomster (bias på vandret skalering) bag MME var et bedre valg end at have færre større hukommelsesforekomster (vertikal skalering). Zendesk observerede, at bin-pakning for mange modeller (ud over 500 TensorFlow-modeller i deres tilfælde) på en enkelt stor hukommelsesforekomst ikke fungerede godt, fordi hukommelsen ikke er den eneste ressource på en forekomst, der kan være en flaskehals. Mere specifikt observerede de, at TensorFlow skabte flere tråde (3 x samlede instans vCPU'er) pr. model, så indlæsning af over 500 modeller på en enkelt instans forårsagede, at kerneniveaugrænser blev overtrådt på det maksimale antal tråde, der kunne dannes på en instans. Et andet problem med at bruge færre, større tilfælde opstod, da Zendesk oplevede drosling (som en sikkerhedsmekanisme) på nogle tilfælde bag MME, fordi den unikke modelankaldelse pr. sekund-hastighed oversteg, hvad Multi Model Server (MMS) på en enkelt forekomst kunne håndtere sikkert uden at brune forekomsten ud. Dette var endnu et problem, der blev løst ved brug af flere og mindre instanser.

Fra observerbarhedsperspektivet, som er en afgørende komponent i enhver produktionsapplikation, amazoncloudwatch målinger som påkald, CPU, hukommelsesudnyttelse og multimodelspecifikke målinger som indlæste modeller i hukommelsen, modelindlæsningstid, modelindlæsningsventetid og modelcachehit er informative. Specifikt hjalp nedbrydningen af ​​modellatens Zendesk med at forstå koldstartsproblemet og dets indvirkning.

Under motorhjelmen af ​​MME auto scaling

Bag hvert multi-model slutpunkt er der modelhostingforekomster, som vist i det følgende diagram. Disse tilfælde indlæser og fjerner flere modeller til og fra hukommelsen baseret på trafikmønstrene til modellerne.

SageMaker fortsætter med at dirigere slutningsanmodninger for en model til den instans, hvor modellen allerede er indlæst, således at anmodningerne serveres fra cachelagret modelkopi (se følgende diagram, som viser anmodningsstien for den første forudsigelsesanmodning vs. den cachelagrede forudsigelsesanmodningssti). Men hvis modellen modtager mange invokationsanmodninger, og der er yderligere forekomster for multi-model-slutpunktet, dirigerer SageMaker nogle anmodninger til en anden forekomst for at imødekomme stigningen. For at drage fordel af automatiseret modelskalering i SageMaker skal du sørge for at have opsætning af automatisk skalering at tilvejebringe yderligere instanskapacitet. Konfigurer din skaleringspolitik på endepunktsniveau med enten brugerdefinerede parametre eller opkald pr. minut (anbefales) for at tilføje flere forekomster til endepunktsflåden.

Brug cases, der passer bedst til MME

SageMaker multi-model endpoints er velegnede til at være vært for et stort antal lignende modeller, som du kan betjene gennem en delt serveringsbeholder og ikke behøver at få adgang til alle modellerne på samme tid. MME er bedst egnet til modeller, der er ens i størrelse og invokationsforsinkelser. Nogle variationer i modelstørrelse er acceptabel; for eksempel spænder Zendesks modeller fra 10-50 Mb, hvilket fungerer fint, men variationer i størrelse, der er en faktor 10, 50 eller 100 gange større, er ikke egnede. Større modeller kan forårsage et højere antal ind- og udlæsninger af mindre modeller for at rumme tilstrækkelig hukommelsesplads, hvilket kan resultere i øget latenstid på slutpunktet. Forskelle i ydeevnekarakteristika for større modeller kan også forbruge ressourcer som CPU ujævnt, hvilket kan påvirke andre modeller på instansen.

MME er også designet til co-hosting af modeller, der bruger den samme ML-ramme, fordi de bruger den delte container til at indlæse flere modeller. Derfor, hvis du har en blanding af ML-frameworks i din modelflåde (såsom PyTorch og TensorFlow), er SageMaker dedikerede slutpunkter eller multi-container-hosting et bedre valg. Endelig er MME velegnet til applikationer, der kan tolerere en lejlighedsvis koldstartsforsinkelse, fordi sjældent brugte modeller kan aflastes til fordel for ofte påkaldte modeller. Hvis du har en lang hale af sjældent tilgåede modeller, kan et multi-model slutpunkt effektivt betjene denne trafik og muliggøre betydelige omkostningsbesparelser.

Resumé

I dette indlæg lærte du, hvordan SaaS og multi-tenancy relaterer sig til ML, og hvordan SageMaker multi-model endpoints muliggør multi-tenancy og omkostningseffektivitet for ML-inferens. Du lærte om Zendesks multi-tenanted use case af per-kunde ML-modeller, og hvordan de hostede tusindvis af ML-modeller i SageMaker MME for deres Suggested Macros-funktion og opnåede 90 % omkostningsbesparelser på inferens sammenlignet med dedikerede slutpunkter. Hyper-personalisering use cases kan kræve tusindvis af ML-modeller, og MME er et omkostningseffektivt valg til denne use case. Vi vil fortsætte med at lave forbedringer i MME for at gøre det muligt for dig at være vært for modeller med lav latenstid og med mere detaljerede kontroller for hver personlig model. For at komme i gang med MME, se Vær vært for flere modeller i én container bag ét slutpunkt.

---

Om forfatterne

Syed Jaffry er Sr. Solutions Architect hos AWS. Han arbejder med en række virksomheder fra mellemstore organisationer til store virksomheder, finansielle tjenester til ISV'er, for at hjælpe dem med at bygge og drive sikre, robuste, skalerbare og højtydende applikationer i skyen.

Sowmya Manusani er Senior Staff Machine Learning Engineer hos Zendesk. Hun arbejder på at produktionsalisere NLP-baserede Machine Learning-funktioner, der fokuserer på at forbedre Agent-produktiviteten for tusindvis af Zendesk Enterprise-kunder. Hun har erfaring med at bygge automatiserede træningspipelines til tusindvis af personaliserede modeller og betjene dem ved hjælp af sikre, robuste, skalerbare og højtydende applikationer. I sin fritid kan hun lide at løse gåder og prøve at male.

Saurabh Trikande er Senior Product Manager for Amazon SageMaker Inference. Han brænder for at arbejde med kunder og gøre machine learning mere tilgængelig. I sin fritid nyder Saurabh at vandre, lære om innovative teknologier, følge TechCrunch og tilbringe tid med sin familie.

Deepti Ragha er softwareudviklingsingeniør i Amazon SageMaker-teamet. Hendes nuværende arbejde fokuserer på at bygge funktioner til effektivt at være vært for maskinlæringsmodeller. I sin fritid nyder hun at rejse, vandre og dyrke planter.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/