Slik skalerer du maskinlæringskonklusjon for SaaS-brukstilfeller med flere leietakere

Publisert av Platon

Følgere: 0

Dette innlegget er skrevet sammen med Sowmya Manusani, Sr. Staff Machine Learning Engineer ved Zendesk

Zendesk er et SaaS-selskap som bygger programvare for støtte, salg og kundeengasjement for alle, med enkelhet som grunnlag. Den trives med å få over 170,000 XNUMX selskaper over hele verden til å betjene sine hundrevis av millioner kunder effektivt. Maskinlæringsteamet hos Zendcaesk er ansvarlig for å forbedre kundeopplevelsesteamene for å oppnå sitt beste. Ved å kombinere kraften til data og mennesker, leverer Zendesk intelligente produkter som gjør kundene mer produktive ved å automatisere manuelt arbeid.

Zendesk har bygget ML-produkter siden 2015, bl.a Svar Bot, Forutsigelse om tilfredshet, Innholdssignaler, Foreslåtte makroer, og mange flere. I løpet av de siste årene, med veksten i dyp læring, spesielt i NLP, så de mange muligheter til å automatisere arbeidsflyter og hjelpe agenter med å støtte sine kunder med Zendesk-løsninger. Zendesk bruker for tiden TensorFlow og PyTorch for å bygge dype læringsmodeller.

Kunder som Zendesk har bygget vellykkede, høyskala programvare som en tjeneste (SaaS)-bedrifter på Amazon Web Services (AWS). En nøkkeldriver for en vellykket SaaS-forretningsmodell er muligheten til å bruke multi-tenancy i applikasjonen og infrastrukturen. Dette muliggjør kostnads- og driftseffektivitet fordi applikasjonen bare trenger å bygges én gang, men den kan brukes mange ganger og infrastrukturen kan deles. Vi ser at mange kunder bygger sikre, kostnadseffektive, multi-tenant-systemer på AWS på alle lag av stabelen, fra databehandling, lagring, database til nettverk, og nå ser vi at kunder trenger å bruke det til maskinlæring (ML). ).

Gjør den vanskelige avveiningen mellom modellgjenbruk og hyperpersonalisering

Multi-tenancy for SaaS-bedrifter betyr vanligvis at en enkelt applikasjon gjenbrukes mellom mange brukere (SaaS-kunder). Dette skaper kostnadseffektivitet og reduserer driftskostnader. Imidlertid må maskinlæringsmodeller noen ganger personaliseres til en høy grad av spesifisitet (hyperpersonlig) for å gi nøyaktige spådommer. Dette betyr at "bygg én gang, bruk mange ganger" SaaS-paradigmet ikke alltid kan brukes på ML hvis modellene har spesifisitet. Ta for eksempel bruken av kundestøtteplattformer. Språket som brukere inkluderer i en støttebillett, varierer avhengig av om det er et spørsmål om skyssandel («turen tok for lang tid») eller et problem med kjøp av klær («misfarging ved vask»). I dette tilfellet kan det kreve opplæring av en NLP-modell (natural language processing) på et datasett spesifikt for et forretningsdomene eller en industrivertikal for å forbedre nøyaktigheten av å forutsi den beste utbedringshandlingen. Zendesk står overfor akkurat denne utfordringen når de prøver å utnytte ML i sine løsninger. De trengte å lage tusenvis av svært tilpassede ML-modeller, hver skreddersydd for en spesifikk kunde. For å løse denne utfordringen med å distribuere tusenvis av modeller, kostnadseffektivt, henvendte Zendesk seg til Amazon SageMaker.

I dette innlegget viser vi hvordan du bruker noen av de nyere funksjonene til Amazon SageMaker, en fullstendig administrert maskinlæringstjeneste, for å bygge en multi-tenant ML-slutningsevne. Vi deler også et virkelighetseksempel på hvordan Zendesk oppnådde det samme resultatet ved å distribuere et lykkelig medium mellom å kunne støtte hyperpersonalisering i deres ML-modeller og kostnadseffektiv, delt bruk av infrastruktur ved å bruke SageMaker multi-modell endepunkter ( MME).

SageMaker multi-modell endepunkter

SageMaker multi-modell endepunkter lar deg distribuere flere modeller bak et enkelt slutningsendepunkt som kan inneholde en eller flere forekomster. Hver forekomst er designet for å laste og betjene flere modeller opp til minne og CPU-kapasitet. Med denne arkitekturen kan en SaaS-bedrift bryte de lineært økende kostnadene ved å være vert for flere modeller og oppnå gjenbruk av infrastruktur i samsvar med multi-tenancy-modellen som brukes andre steder i applikasjonsstakken.

Følgende diagram illustrerer arkitekturen til et SageMaker flermodellendepunkt.

SageMaker multi-modell endepunkt laster dynamisk modeller fra Amazon enkel lagringstjeneste (Amazon S3) når den påkalles, i stedet for å laste ned alle modellene når endepunktet først opprettes. Som et resultat kan en innledende påkalling til en modell se høyere slutningsforsinkelse enn de påfølgende slutningene, som fullføres med lav forsinkelse. Hvis modellen allerede er lastet inn på beholderen når den startes, hoppes nedlastingstrinnet over og modellen returnerer slutningene med lav ventetid. Anta for eksempel at du har en modell som bare brukes noen få ganger om dagen. Den lastes automatisk på forespørsel, mens ofte brukte modeller beholdes i minnet og påkalles med konsekvent lav ventetid.

La oss se nærmere på hvordan Zendesk brukte SageMaker MME for å oppnå kostnadseffektiv, hyperskalert ML-distribusjon med deres Suggested Macros ML-funksjon.

Hvorfor Zendesk bygde hyper-personlige modeller

Zendesks kunder er spredt globalt i forskjellige bransjevertikaler med ulik semantikk for støttebilletter. Derfor, for å betjene kundene sine best mulig, må de ofte bygge personlige modeller som er trent på kundespesifikke støttebillettdata for å identifisere intensjoner, makroer og mer på riktig måte.

I oktober 2021 ga de ut en ny NLP ML-funksjon, Suggested Macros, som anbefaler makroer (forhåndsdefinerte handlinger) basert på tusenvis av kundespesifikke modellspådommer. Zendesks ML-team bygde en TensorFlow-basert NLP-klassifiseringsmodell trent fra tidligere historie med billettinnhold og makroer per kunde. Med disse modellene tilgjengelig, anbefales en makroprediksjon hver gang en agent ser på billetten (som vist i følgende skjermbilde), som hjelper agenten med å betjene kunder raskt. Fordi makroer er spesifikke for kunder, trenger Zendesk kundespesifikke modeller for å tjene nøyaktige spådommer.

Under panseret på Zendesks Suggested Macros

Foreslåtte makromodeller er NLP-baserte nevrale nett som er rundt 7–15 MB store. Hovedutfordringen er å sette tusenvis av disse modellene i produksjon med kostnadseffektive, pålitelige og skalerbare løsninger.

Hver modell har forskjellige trafikkmønstre, med minimum to forespørsler per sekund og en topp på hundrevis av forespørsler per sekund, og serverer millioner av spådommer per dag med en modellforsinkelse på omtrent 100 millisekunder når modellen er tilgjengelig i minnet. SageMaker-endepunkter er distribuert i flere AWS-regioner, og betjener tusenvis av forespørsler per minutt per endepunkt.

Med sin evne til å være vert for flere modeller på ett enkelt endepunkt, hjalp SageMaker Zendesk med å redusere distribusjonskostnader og skape en kostnadseffektiv løsning sammenlignet med å distribuere et enkelt-modell-endepunkt per kunde. Avveiningen her er mindre kontroll på administrasjon per modell; Dette er imidlertid et område der Zendesk samarbeider med AWS for å forbedre multi-modell endepunkter.

En av SageMaker-multimodellfunksjonene er lat lasting av modeller, det vil si at modeller lastes inn i minnet når de startes for første gang. Dette for å optimalisere minneutnyttelsen; det forårsaker imidlertid responstidstopper ved første lasting, noe som kan sees på som et kaldstartproblem. For foreslåtte makroer var dette en utfordring; Imidlertid overvant Zendesk dette ved å implementere en forhåndsinnlastingsfunksjonalitet på toppen av SageMaker-endepunktsforsyningen for å laste modellene inn i minnet før de betjener produksjonstrafikk. For det andre laster MME ut sjelden brukte modeller fra minnet, så for å oppnå konsekvent lav latenstid på alle modellene og unngå at "støyende naboer" påvirker andre mindre aktive modeller, samarbeider Zendesk med AWS for å legge til nye funksjoner, diskutert senere i innlegget, for å aktivere mer eksplisitt styring per modell. I tillegg, som en midlertidig løsning, har Zendesk dimensjonert MME-flåten i riktig størrelse for å minimere lossing av for mange modeller. Med dette er Zendesk i stand til å levere spådommer til alle sine kunder med lav ventetid, rundt 100 millisekunder, og fortsatt oppnå 90 % kostnadsbesparelser sammenlignet med dedikerte endepunkter.

På MME med riktig størrelse, observerte Zendesk under lasttesting at å ha et høyere antall mindre forekomster (bias på horisontal skalering) bak MME var et bedre valg enn å ha færre større minneforekomster (vertikal skalering). Zendesk observerte at pakking av for mange modeller (utover 500 TensorFlow-modeller i deres tilfelle) på en enkelt stor minneforekomst ikke fungerte bra fordi minne ikke er den eneste ressursen på en forekomst som kan være en flaskehals. Mer spesifikt observerte de at TensorFlow skapte flere tråder (3 x totalt vCPU-er for forekomster) per modell, så lasting av over 500 modeller på en enkelt forekomst førte til at grensene for kjernenivå ble brutt for det maksimale antallet tråder som kunne avles på en forekomst. Et annet problem med å bruke færre, større forekomster oppsto da Zendesk opplevde struping (som en sikkerhetsmekanisme) på noen forekomster bak MME fordi den unike modellanropshastigheten per sekund oversteg det som Multi -modellserver (MMS) på en enkelt forekomst kunne trygt håndtere uten å brune ut forekomsten. Dette var et annet problem som ble løst ved bruk av flere og mindre instanser.

Fra observerbarhetsperspektivet, som er en avgjørende komponent i enhver produksjonsapplikasjon, Amazon CloudWatch Beregninger som påkallinger, CPU, minneutnyttelse og multimodellspesifikke beregninger som innlastede modeller i minnet, modelllastetid, modellinnlastingsventetid og modellbuffertreff er informative. Nærmere bestemt hjalp sammenbruddet av modellforsinkelse Zendesk å forstå kaldstartproblemet og dets innvirkning.

Under panseret til MME automatisk skalering

Bak hvert multi-modellendepunkt er det modellvertsinstanser, som vist i følgende diagram. Disse forekomstene laster og kaster ut flere modeller til og fra minnet basert på trafikkmønstrene til modellene.

SageMaker fortsetter å rute slutningsforespørsler for en modell til forekomsten der modellen allerede er lastet, slik at forespørslene blir servert fra bufret modellkopi (se følgende diagram, som viser forespørselsbanen for den første prediksjonsforespørselen kontra den hurtigbufrede prediksjonsforespørselen sti). Imidlertid, hvis modellen mottar mange invokasjonsforespørsler, og det er flere forekomster for flermodellendepunktet, ruter SageMaker noen forespørsler til en annen forekomst for å imøtekomme økningen. For å dra nytte av automatisert modellskalering i SageMaker, sørg for at du har forekomst automatisk skalering satt opp å sørge for ekstra instanskapasitet. Konfigurer skaleringspolicyen på endepunktnivå med enten egendefinerte parametere eller påkallinger per minutt (anbefalt) for å legge til flere forekomster til endepunktflåten.

Bruk tilfeller som passer best for MME

SageMaker multi-modell endepunkter er godt egnet for å være vert for et stort antall lignende modeller som du kan betjene gjennom en delt serveringsbeholder og ikke trenger å få tilgang til alle modellene samtidig. MME er best egnet for modeller som er like i størrelse og påkallingsforsinkelser. Noen variasjoner i modellstørrelse er akseptabelt; for eksempel varierer Zendesks modeller fra 10–50 Mb, noe som fungerer fint, men variasjoner i størrelse som er en faktor på 10, 50 eller 100 ganger større er ikke egnet. Større modeller kan føre til et høyere antall inn- og utlastinger av mindre modeller for å få plass til tilstrekkelig minneplass, noe som kan resultere i ekstra ventetid på endepunktet. Forskjeller i ytelsesegenskaper til større modeller kan også forbruke ressurser som CPU ujevnt, noe som kan påvirke andre modeller på forekomsten.

MME er også designet for co-hosting-modeller som bruker samme ML-rammeverk fordi de bruker den delte beholderen til å laste flere modeller. Derfor, hvis du har en blanding av ML-rammeverk i modellflåten din (som PyTorch og TensorFlow), er SageMaker dedikerte endepunkter eller multi-container-hosting et bedre valg. Til slutt er MME egnet for applikasjoner som kan tolerere en sporadisk kaldstartsforsinkelse fordi sjelden brukte modeller kan lastes av til fordel for modeller som ofte brukes. Hvis du har en lang hale med sjelden tilgang til modeller, kan et endepunkt med flere modeller effektivt betjene denne trafikken og gi betydelige kostnadsbesparelser.

Oppsummering

I dette innlegget lærte du hvordan SaaS og multi-tenancy forholder seg til ML og hvordan SageMaker multi-modell endepunkter muliggjør multi-tenancy og kostnadseffektivitet for ML-slutning. Du lærte om Zendesks brukstilfelle for flere leietakere av ML-modeller per kunde og hvordan de var vert for tusenvis av ML-modeller i SageMaker MME for deres foreslåtte makroer og oppnådde 90 % kostnadsbesparelser på slutninger sammenlignet med dedikerte endepunkter. Brukstilfeller med hyperpersonalisering kan kreve tusenvis av ML-modeller, og MME er et kostnadseffektivt valg for denne brukstilfellet. Vi vil fortsette å gjøre forbedringer i MME slik at du kan være vert for modeller med lav ventetid og med mer detaljerte kontroller for hver personlig tilpassede modell. For å komme i gang med MME, se Vert for flere modeller i én beholder bak ett endepunkt.

Om forfatterne

Syed Jaffry er senior løsningsarkitekt med AWS. Han jobber med en rekke selskaper fra mellomstore organisasjoner til store bedrifter, finansielle tjenester til ISV-er, for å hjelpe dem med å bygge og drifte sikre, spenstige, skalerbare og høyytelsesapplikasjoner i skyen.

Sowmya Manusani er en Senior Staff Machine Learning Engineer i Zendesk. Hun jobber med produksjonalisering av NLP-baserte maskinlæringsfunksjoner som fokuserer på å forbedre agentproduktiviteten for tusenvis av Zendesk Enterprise-kunder. Hun har erfaring med å bygge automatiserte treningspipelines for tusenvis av personaliserte modeller og betjene dem ved å bruke sikre, spenstige, skalerbare og høyytelsesapplikasjoner. På fritiden liker hun å løse gåter og prøve å male.

Saurabh Trikande er senior produktsjef for Amazon SageMaker Inference. Han brenner for å jobbe med kunder og gjøre maskinlæring mer tilgjengelig. På fritiden liker Saurabh å gå tur, lære om innovative teknologier, følge TechCrunch og tilbringe tid med familien.

Deepti Ragha er en programvareutviklingsingeniør i Amazon SageMaker-teamet. Hennes nåværende arbeid fokuserer på å bygge funksjoner for å være vert for maskinlæringsmodeller effektivt. På fritiden liker hun å reise, gå tur og dyrke planter.