Hur man skalar inferens för maskininlärning för SaaS-användningsfall med flera hyresgäster

Det här inlägget är skrivet tillsammans med Sowmya Manusani, Sr. Staff Machine Learning Engineer på Zendesk

Zendesk är ett SaaS-företag som bygger programvara för support, försäljning och kundengagemang för alla, med enkelhet som grund. Det frodas på att få över 170,000 XNUMX företag världen över att betjäna sina hundratals miljoner kunder effektivt. Machine Learning-teamet på Zendcaesk är ansvarigt för att förbättra Customer Experience-teamen för att uppnå sitt bästa. Genom att kombinera kraften i data och människor levererar Zendesk intelligenta produkter som gör sina kunder mer produktiva genom att automatisera manuellt arbete.

Zendesk har byggt ML-produkter sedan 2015, bl.a Svar Bot, Förutsägelse om tillfredsställelse, Innehållssignaler, Föreslagna makron, och många fler. Under de senaste åren, med tillväxten inom djupinlärning, särskilt inom NLP, såg de många möjligheter att automatisera arbetsflöden och hjälpa agenter att stödja sina kunder med Zendesk-lösningar. Zendesk använder för närvarande TensorFlow och PyTorch för att bygga modeller för djupinlärning.

Kunder som Zendesk har byggt framgångsrika, högskaliga programvara som en tjänst (SaaS)-företag på Amazon Web Services (AWS). En viktig drivkraft för en framgångsrik SaaS-affärsmodell är förmågan att tillämpa multi-tenancy i applikationen och infrastrukturen. Detta möjliggör kostnads- och driftseffektivitet eftersom applikationen bara behöver byggas en gång, men den kan användas många gånger och infrastrukturen kan delas. Vi ser att många kunder bygger säkra, kostnadseffektiva system med flera innehavare på AWS i alla lager av stacken, från beräkning, lagring, databas till nätverk, och nu ser vi att kunder behöver tillämpa det på maskininlärning (ML) ).

Att göra den svåra avvägningen mellan modellåteranvändning och hyperpersonalisering

Multi-tenancy för SaaS-företag innebär vanligtvis att en enda applikation återanvänds mellan många användare (SaaS-kunder). Detta skapar kostnadseffektivitet och sänker driftskostnader. Emellertid behöver maskininlärningsmodeller ibland anpassas till en hög grad av specificitet (hyperpersonifierade) för att göra korrekta förutsägelser. Detta innebär att SaaS-paradigmet "bygg en gång, använd många gånger" inte alltid kan tillämpas på ML om modellerna har specificitet. Ta till exempel användningsfallet för kundsupportplattformar. Språket som användarna inkluderar i en supportbiljett varierar beroende på om det är en emission av åkande ("turen tog för lång tid") eller en klädköpsfråga ("missfärgning vid tvätt"). I det här användningsfallet kan det krävas utbildning av en NLP-modell (natural language processing) på en datauppsättning som är specifik för en företagsdomän eller en industrivertikal. Zendesk står inför exakt denna utmaning när de försöker utnyttja ML i sina lösningar. De behövde skapa tusentals mycket anpassade ML-modeller, var och en skräddarsydd för en specifik kund. För att lösa denna utmaning med att distribuera tusentals modeller, kostnadseffektivt, vände Zendesk sig till Amazon SageMaker.

I det här inlägget visar vi hur du använder några av de nyare funktionerna i Amazon SageMaker, en helt hanterad maskininlärningstjänst, för att bygga en multi-tenant ML-inferenskapacitet. Vi delar också ett verkligt exempel på hur Zendesk framgångsrikt uppnådde samma resultat genom att distribuera ett lyckligt medium mellan att kunna stödja hyperpersonalisering i sina ML-modeller och den kostnadseffektiva, delade användningen av infrastruktur med SageMaker multi-model endpoints ( MME).

SageMaker flermodellslutpunkter

SageMaker multi-model endpoints gör att du kan distribuera flera modeller bakom en enda slutpunkt som kan innehålla en eller flera instanser. Varje instans är utformad för att ladda och betjäna flera modeller upp till dess minne och CPU-kapacitet. Med den här arkitekturen kan ett SaaS-företag bryta de linjärt ökande kostnaderna för att vara värd för flera modeller och uppnå återanvändning av infrastruktur som överensstämmer med multi-tenancy-modellen som tillämpas på andra ställen i applikationsstacken.

Följande diagram illustrerar arkitekturen för en SageMaker multi-model endpoint.

SageMaker multi-model endpoint laddar dynamiskt modeller från Amazon enkel lagringstjänst (Amazon S3) när den anropas, istället för att ladda ner alla modeller när slutpunkten först skapas. Som ett resultat kan en initial anrop till en modell se högre slutledningslatens än de efterföljande slutsatserna, som avslutas med låg latens. Om modellen redan är laddad på behållaren när den anropas, hoppas nedladdningssteget över och modellen returnerar slutledningarna med låg latens. Anta till exempel att du har en modell som bara används ett fåtal gånger om dagen. Den laddas automatiskt på begäran, medan ofta åtkomliga modeller behålls i minnet och anropas med konsekvent låg latens.

Låt oss ta en närmare titt på hur Zendesk använde SageMaker MME för att uppnå kostnadseffektiv, hyperskalig ML-distribution med deras funktionen Suggested Macros ML.

Varför Zendesk byggde hyperpersonaliserade modeller

Zendesks kunder är spridda globalt i olika branschvertikaler med olika semantik för supportbiljetter. Därför, för att betjäna sina kunder bäst, måste de ofta bygga personliga modeller som är utbildade på kundspecifika supportärenden för att korrekt identifiera avsikter, makron och mer.

I oktober 2021 släppte de en ny NLP ML-funktion, Suggested Macros, som rekommenderar makron (fördefinierade åtgärder) baserat på tusentals kundspecifika modellförutsägelser. Zendesks ML-team byggde en TensorFlow-baserad NLP-klassificeringsmodell utbildad från den tidigare historien om biljettinnehåll och makron per kund. Med dessa modeller tillgängliga rekommenderas en makroförutsägelse närhelst en agent ser biljetten (som visas i följande skärmdump), vilket hjälper agenten att betjäna kunder snabbt. Eftersom makron är specifika för kunder behöver Zendesk kundspecifika modeller för att ge korrekta förutsägelser.

Under huven på Zendesks förslag på makron

Föreslagna makromodeller är NLP-baserade neurala nät som är cirka 7–15 MB stora. Den största utmaningen är att sätta tusentals av dessa modeller i produktion med kostnadseffektiva, pålitliga och skalbara lösningar.

Varje modell har olika trafikmönster, med minst två förfrågningar per sekund och en topp på hundratals förfrågningar per sekund, vilket ger miljontals förutsägelser per dag med en modelllatens på cirka 100 millisekunder när modellen är tillgänglig i minnet. SageMaker-slutpunkter distribueras i flera AWS-regioner och betjänar tusentals förfrågningar per minut och slutpunkt.

Med sin förmåga att vara värd för flera modeller på en enda slutpunkt, hjälpte SageMaker Zendesk att minska distributionskostnaderna och skapa en kostnadseffektiv lösning jämfört med att implementera en enda modell av en enda modell per kund. Avvägningen här är mindre kontroll på hantering per modell; Detta är dock ett område där Zendesk samarbetar med AWS för att förbättra flermodellslutpunkter.

En av SageMakers multimodellfunktioner är lat laddning av modeller, det vill säga modeller laddas in i minnet när de anropas för första gången. Detta för att optimera minnesutnyttjandet; det orsakar dock svarstidstoppar vid första laddning, vilket kan ses som ett kallstartsproblem. För förslag på makron var detta en utmaning; Men Zendesk övervann detta genom att implementera en förladdningsfunktion ovanpå SageMaker-slutpunktsprovisioneringen för att ladda modellerna i minnet innan de betjänar produktionstrafik. För det andra laddar MME sällan använda modeller från minnet, så för att uppnå konsekvent låg latens på alla modeller och undvika att "bullriga grannar" påverkar andra mindre aktiva modeller, samarbetar Zendesk med AWS för att lägga till nya funktioner, som diskuteras senare i inlägget, för att möjliggöra mer explicit hantering per modell. Dessutom, som en interimslösning, har Zendesk anpassat MME-flottan i rätt storlek för att minimera lossning av för många modeller. Med detta kan Zendesk leverera förutsägelser till alla sina kunder med låg latens, runt 100 millisekunder, och ändå uppnå 90 % kostnadsbesparingar jämfört med dedikerade slutpunkter.

När det gäller MME med rätt storlek, observerade Zendesk under belastningstestning att att ha ett högre antal mindre instanser (bias på horisontell skalning) bakom MME var ett bättre val än att ha färre större minnesinstanser (vertikal skalning). Zendesk observerade att packning av för många modeller (utöver 500 TensorFlow-modeller i deras fall) på en enda stor minnesinstans inte fungerade bra eftersom minnet inte är den enda resursen på en instans som kan vara en flaskhals. Mer specifikt observerade de att TensorFlow skapade flera trådar (3 x totala instans-vCPU:er) per modell, så att ladda över 500 modeller på en enda instans orsakade att kärnnivågränser bröts för det maximala antalet trådar som kunde skapas på en instans. Ett annat problem med att använda färre, större instanser uppstod när Zendesk upplevde strypning (som en säkerhetsmekanism) på vissa instanser bakom MME eftersom den unika modellanropsfrekvensen per sekund översteg vad Multi Model Server (MMS) på en enskild instans skulle kunna hantera utan att bryna ut instansen. Detta var ytterligare ett problem som löstes med hjälp av fler och mindre instanser.

Ur observerbarhetsperspektivet, som är en avgörande komponent i alla produktionsapplikationer, amazoncloudwatch mått som anrop, CPU, minnesanvändning och multimodellspecifika mått som laddade modeller i minnet, modellladdningstid, modellladdningsväntetid och modellcacheträff är informativa. Specifikt hjälpte uppdelningen av modelllatens Zendesk att förstå kallstartsproblemet och dess inverkan.

Under huven på MME automatisk skalning

Bakom varje slutpunkt för flera modeller finns modellvärdinstanser, som visas i följande diagram. Dessa instanser laddar och kastar ut flera modeller till och från minnet baserat på trafikmönstren till modellerna.

SageMaker fortsätter att dirigera inferensförfrågningar för en modell till den instans där modellen redan är laddad så att förfrågningarna betjänas från cachad modellkopia (se följande diagram, som visar sökvägen för den första förutsägelseförfrågan kontra den cachade förutsägelseförfrågan väg). Men om modellen tar emot många anropsförfrågningar, och det finns ytterligare instanser för flermodellslutpunkten, dirigerar SageMaker några förfrågningar till en annan instans för att tillgodose ökningen. För att dra fördel av automatiserad modellskalning i SageMaker, se till att du har ställ in automatisk skalning för instans för att tillhandahålla ytterligare instanskapacitet. Ställ in din skalningspolicy på slutpunktsnivå med antingen anpassade parametrar eller anrop per minut (rekommenderas) för att lägga till fler instanser till slutpunktsflottan.

Användningsfall som är bäst lämpade för MME

SageMaker multi-model endpoints är väl lämpade för att vara värd för ett stort antal liknande modeller som du kan servera genom en delad serveringsbehållare och inte behöver komma åt alla modeller samtidigt. MME lämpar sig bäst för modeller som är liknande i storlek och anropslatenser. Viss variation i modellstorlek är acceptabel; till exempel sträcker sig Zendesks modeller från 10–50 Mb, vilket fungerar bra, men variationer i storlek som är en faktor 10, 50 eller 100 gånger större är inte lämpliga. Större modeller kan orsaka ett högre antal laddningar och urladdningar av mindre modeller för att rymma tillräckligt med minnesutrymme, vilket kan resultera i ökad latens på slutpunkten. Skillnader i prestandaegenskaper hos större modeller kan också förbruka resurser som CPU ojämnt, vilket kan påverka andra modeller i instansen.

MME är också designat för att vara värd för modeller som använder samma ML-ramverk eftersom de använder den delade behållaren för att ladda flera modeller. Därför, om du har en blandning av ML-ramverk i din modellflotta (som PyTorch och TensorFlow), är SageMaker dedikerade slutpunkter eller värd för flera behållare ett bättre val. Slutligen är MME lämpad för applikationer som kan tolerera en tillfällig kallstartsfördröjning eftersom sällan använda modeller kan laddas ur till förmån för ofta anropade modeller. Om du har en lång svans av sällan åtkomst till modeller kan en multi-modell slutpunkt effektivt betjäna denna trafik och möjliggöra betydande kostnadsbesparingar.

Sammanfattning

I det här inlägget lärde du dig hur SaaS och multi-tenancy relaterar till ML och hur SageMaker multi-model endpoints möjliggör multi-tenancy och kostnadseffektivitet för ML-inferens. Du lärde dig om Zendesks användningsfall med flera hyresgäster av ML-modeller per kund och hur de var värd för tusentals ML-modeller i SageMaker MME för deras föreslagna makron och uppnådde 90 % kostnadsbesparingar på slutsatser jämfört med dedikerade slutpunkter. Användningsfall för hyperpersonalisering kan kräva tusentals ML-modeller, och MME är ett kostnadseffektivt val för detta användningsfall. Vi kommer att fortsätta att göra förbättringar i MME så att du kan vara värd för modeller med låg latens och med mer detaljerade kontroller för varje personlig modell. För att komma igång med MME, se Värd för flera modeller i en container bakom en slutpunkt.

---

Om författarna

Syed Jaffry är Sr. Solutions Architect med AWS. Han arbetar med en rad företag från medelstora organisationer till stora företag, finansiella tjänster till ISV:er, för att hjälpa dem bygga och driva säkra, motståndskraftiga, skalbara och högpresterande applikationer i molnet.

Sowmya Manusani är Senior Staff Machine Learning Engineer på Zendesk. Hon arbetar med att produktionsalisera NLP-baserade maskininlärningsfunktioner som fokuserar på att förbättra agentproduktiviteten för tusentals Zendesk Enterprise-kunder. Hon har erfarenhet av att bygga automatiserade träningspipelines för tusentals personliga modeller och serva dem med säkra, motståndskraftiga, skalbara och högpresterande applikationer. På fritiden gillar hon att lösa pussel och prova på att måla.

Saurabh Trikande är senior produktchef för Amazon SageMaker Inference. Han brinner för att arbeta med kunder och göra maskininlärning mer tillgänglig. På sin fritid tycker Saurabh om att vandra, lära sig om innovativ teknik, följa TechCrunch och umgås med sin familj.

Deepti Ragha är en mjukvaruutvecklingsingenjör i Amazon SageMaker-teamet. Hennes nuvarande arbete fokuserar på att bygga funktioner för att effektivt vara värd för maskininlärningsmodeller. På fritiden tycker hon om att resa, vandra och odla växter.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/