Hoe machine learning-inferentie te schalen voor SaaS-gebruikscasussen met meerdere tenants

Dit bericht is geschreven in samenwerking met Sowmya Manusani, Sr. Staff Machine Learning Engineer bij Zendesk

Zendesk is een SaaS-bedrijf dat software voor ondersteuning, verkoop en klantbetrokkenheid bouwt voor iedereen, met eenvoud als basis. Het gedijt erop dat meer dan 170,000 bedrijven wereldwijd hun honderden miljoenen klanten efficiënt kunnen bedienen. Het Machine Learning-team van Zendcaesk is verantwoordelijk voor het verbeteren van Customer Experience-teams om het beste uit zichzelf te halen. Door de kracht van data en mensen te combineren, levert Zendesk intelligente producten die hun klanten productiever maken door handmatig werk te automatiseren.

Zendesk bouwt sinds 2015 ML-producten, waaronder: Antwoord Bot, Tevredenheidsvoorspelling, Inhoudscues, Voorgestelde macro's, en nog veel meer. In de afgelopen jaren, met de groei in deep learning, vooral in NLP, zagen ze veel kansen om workflows te automatiseren en agenten te helpen bij het ondersteunen van hun klanten met Zendesk-oplossingen. Zendesk gebruikt momenteel TensorFlow en PyTorch om deep learning-modellen te bouwen.

Klanten zoals Zendesk hebben succesvolle, grootschalige SaaS-bedrijven (Software as a Service) gebouwd op Amazon Web Services (AWS). Een belangrijke driver voor een succesvol SaaS-bedrijfsmodel is de mogelijkheid om multi-tenancy toe te passen in de applicatie en infrastructuur. Dit zorgt voor kosten- en operationele efficiëntie omdat de applicatie maar één keer hoeft te worden gebouwd, maar deze vele malen kan worden gebruikt en de infrastructuur kan worden gedeeld. We zien dat veel klanten veilige, kostenefficiënte multi-tenant systemen bouwen op AWS in alle lagen van de stack, van rekenkracht, opslag, database tot netwerken, en nu zien we dat klanten dit moeten toepassen op machine learning (ML ).

De moeilijke afweging maken tussen hergebruik van modellen en hyperpersonalisatie

Multi-tenancy voor SaaS-bedrijven betekent doorgaans dat een enkele applicatie wordt hergebruikt tussen veel gebruikers (SaaS-klanten). Dit zorgt voor kostenefficiëntie en verlaagt de operationele overhead. Machine learning-modellen moeten soms echter tot een hoge mate van specificiteit (hypergepersonaliseerd) worden gepersonaliseerd om nauwkeurige voorspellingen te kunnen doen. Dit betekent dat het SaaS-paradigma "één keer bouwen, vele keren gebruiken" niet altijd kan worden toegepast op ML als modellen specifiek zijn. Neem bijvoorbeeld de use case van platformen voor klantenondersteuning. De taal die gebruikers in een ondersteuningsticket opnemen, hangt af van of het een probleem is met het delen van de rit ("de rit duurde te lang") of een probleem met de aankoop van kleding ("verkleuring bij het wassen"). In dit geval kan het voor het verbeteren van de nauwkeurigheid van het voorspellen van de beste herstelactie het trainen van een natural language processing (NLP)-model vereisen op een dataset die specifiek is voor een bedrijfsdomein of een brancheverticale. Zendesk staat precies voor deze uitdaging wanneer ze ML in hun oplossingen proberen te gebruiken. Ze moesten duizenden sterk aangepaste ML-modellen maken, elk op maat gemaakt voor een specifieke klant. Om deze uitdaging van het implementeren van duizenden modellen kosteneffectief op te lossen, wendde Zendesk zich tot Amazon SageMaker.

In dit bericht laten we zien hoe u enkele van de nieuwere functies van Amazon Sage Maker, een volledig beheerde machine learning-service, om een ​​multi-tenant ML-inferentiemogelijkheid te bouwen. We delen ook een praktijkvoorbeeld van hoe Zendesk met succes hetzelfde resultaat bereikte door een gulden middenweg te implementeren tussen het ondersteunen van hyperpersonalisatie in hun ML-modellen en het kostenefficiënte, gedeelde gebruik van infrastructuur met behulp van SageMaker multi-model endpoints ( MME).

SageMaker-eindpunten voor meerdere modellen

Met SageMaker-eindpunten met meerdere modellen kunt u meerdere modellen implementeren achter een enkel inferentie-eindpunt dat een of meer instanties kan bevatten. Elke instantie is ontworpen om meerdere modellen te laden en te bedienen, tot aan de geheugen- en CPU-capaciteit. Met deze architectuur kan een SaaS-bedrijf de lineair stijgende kosten van het hosten van meerdere modellen doorbreken en hergebruik van infrastructuur realiseren in overeenstemming met het multi-tenancy-model dat elders in de applicatie-stack wordt toegepast.

Het volgende diagram illustreert de architectuur van een SageMaker-eindpunt met meerdere modellen.

Het SageMaker-eindpunt voor meerdere modellen laadt dynamisch modellen van Amazon eenvoudige opslagservice (Amazon S3) wanneer aangeroepen, in plaats van alle modellen te downloaden wanneer het eindpunt voor het eerst wordt gemaakt. Als gevolg hiervan kan een eerste aanroep van een model een hogere inferentielatentie zien dan de daaropvolgende inferenties, die worden voltooid met een lage latentie. Als het model al in de container is geladen wanneer het wordt aangeroepen, wordt de downloadstap overgeslagen en retourneert het model de gevolgtrekkingen met een lage latentie. Stel je hebt bijvoorbeeld een model dat maar een paar keer per dag wordt gebruikt. Het wordt automatisch op aanvraag geladen, terwijl veelgebruikte modellen in het geheugen worden bewaard en worden aangeroepen met een consistent lage latentie.

Laten we eens nader bekijken hoe Zendesk SageMaker MME heeft gebruikt om een ​​kosteneffectieve, hyperschaalbare ML-implementatie te realiseren met hun Suggested Macros ML-functie.

Waarom Zendesk hypergepersonaliseerde modellen heeft gebouwd

De klanten van Zendesk zijn wereldwijd verspreid in verschillende branches met verschillende semantiek voor supporttickets. Om hun klanten zo goed mogelijk van dienst te zijn, moeten ze daarom vaak gepersonaliseerde modellen bouwen die zijn getraind op klantspecifieke supportticketgegevens om de intentie, macro's en meer correct te identificeren.

In oktober 2021 brachten ze een nieuwe NLP ML-functie uit, Suggested Macros, die macro's (vooraf gedefinieerde acties) aanbeveelt op basis van duizenden klantspecifieke modelvoorspellingen. Het ML-team van Zendesk heeft een op TensorFlow gebaseerd NLP-classificatiemodel gebouwd dat is getraind op basis van de eerdere geschiedenis van ticketinhoud en macro's per klant. Met deze modellen beschikbaar, wordt een macrovoorspelling aanbevolen wanneer een agent het ticket bekijkt (zoals weergegeven in de volgende schermafbeelding), wat de agent helpt om klanten snel van dienst te zijn. Omdat macro's specifiek zijn voor klanten, heeft Zendesk klantspecifieke modellen nodig om nauwkeurige voorspellingen te kunnen doen.

Onder de motorkap van de voorgestelde macro's van Zendesk

Voorgestelde macro-modellen zijn op NLP gebaseerde neurale netwerken die ongeveer 7-15 MB groot zijn. De grootste uitdaging is om duizenden van deze modellen in productie te nemen met kostenefficiënte, betrouwbare en schaalbare oplossingen.

Elk model heeft verschillende verkeerspatronen, met een minimum van twee verzoeken per seconde en een piek van honderden verzoeken per seconde, waarmee miljoenen voorspellingen per dag worden uitgevoerd met een modellatentie van ongeveer 100 milliseconden wanneer het model beschikbaar is in het geheugen. SageMaker-eindpunten worden ingezet in meerdere AWS-regio's en bedienen duizenden verzoeken per minuut per eindpunt.

Met de mogelijkheid om meerdere modellen op een enkel eindpunt te hosten, hielp SageMaker Zendesk om de implementatieoverhead te verminderen en een kosteneffectieve oplossing te creëren in vergelijking met de implementatie van een enkelvoudig eindpunt per klant. De afweging hier is minder controle over het beheer per model; dit is echter een gebied waarop Zendesk samenwerkt met AWS om eindpunten met meerdere modellen te verbeteren.

Een van de functies van SageMaker voor meerdere modellen is het lui laden van modellen, dat wil zeggen dat modellen in het geheugen worden geladen wanneer ze voor de eerste keer worden aangeroepen. Dit is om het geheugengebruik te optimaliseren; het veroorzaakt echter pieken in de responstijd bij de eerste lading, wat kan worden gezien als een probleem met een koude start. Voor Suggested Macros was dit een uitdaging; Zendesk heeft dit echter overwonnen door een preload-functionaliteit te implementeren bovenop de SageMaker-eindpuntvoorziening om de modellen in het geheugen te laden voordat het productieverkeer wordt bediend. Ten tweede haalt MME niet vaak gebruikte modellen uit het geheugen, dus om een ​​consistente lage latentie op alle modellen te bereiken en te voorkomen dat "lawaaierige buren" andere, minder actieve modellen beïnvloeden, werkt Zendesk samen met AWS om nieuwe functies toe te voegen, die later in de post worden besproken, om explicieter beheer per model. Bovendien heeft Zendesk, als tussenoplossing, de MME-vloot op de juiste maat gemaakt om het uitladen van te veel modellen tot een minimum te beperken. Hiermee kan Zendesk al zijn klanten voorspellingen doen met een lage latentie, ongeveer 100 milliseconden, en toch 90% kostenbesparingen realiseren in vergelijking met speciale eindpunten.

Bij de juiste grootte van MME constateerde Zendesk tijdens belastingtests dat een groter aantal kleinere instances (bias bij horizontale schaling) achter MME een betere keuze was dan minder grotere geheugeninstances (verticale schaling). Zendesk merkte op dat te veel modellen (meer dan 500 TensorFlow-modellen in hun geval) op een enkele grote geheugeninstantie niet goed werkte omdat geheugen niet de enige bron op een instantie is die een knelpunt kan zijn. Meer specifiek merkten ze op dat TensorFlow meerdere threads voortbracht (3 x totale instantie-vCPU's) per model, dus het laden van meer dan 500 modellen op een enkele instantie zorgde ervoor dat de limieten op het kernelniveau werden overschreden op het maximale aantal threads dat op een instantie kon worden voortgebracht. Een ander probleem met het gebruik van minder, grotere instances deed zich voor toen Zendesk in sommige instances achter MME throttling (als veiligheidsmechanisme) ondervond, omdat de unieke aanroep per seconde van het model groter was dan wat de Server voor meerdere modellen (MMS) op een enkele instantie veilig kunnen verwerken zonder de instantie bruin te maken. Dit was een ander probleem dat werd opgelost door meer en kleinere exemplaren te gebruiken.

Vanuit het waarnemingsperspectief, dat een cruciaal onderdeel is van elke productietoepassing, Amazon Cloud Watch metrische gegevens zoals aanroepen, CPU, geheugengebruik en multi-modelspecifieke metrische gegevens zoals geladen modellen in het geheugen, modellaadtijd, wachttijd voor modellading en modelcachehit zijn informatief. Met name de uitsplitsing van de modellatentie hielp Zendesk het koudestartprobleem en de impact ervan te begrijpen.

Onder de motorkap van MME automatisch schalen

Achter elk eindpunt met meerdere modellen bevinden zich modelhostinginstanties, zoals weergegeven in het volgende diagram. Deze instanties laden en verwijderen meerdere modellen van en naar het geheugen op basis van de verkeerspatronen naar de modellen.

SageMaker gaat door met het routeren van inferentieverzoeken voor een model naar de instantie waar het model al is geladen, zodat de verzoeken worden geleverd vanuit de in de cache opgeslagen modelkopie (zie het volgende diagram dat het verzoekpad toont voor het eerste voorspellingsverzoek versus het in de cache opgeslagen voorspellingsverzoek pad). Als het model echter veel aanroepverzoeken ontvangt en er extra exemplaren zijn voor het eindpunt met meerdere modellen, stuurt SageMaker sommige verzoeken door naar een ander exemplaar om de toename op te vangen. Om te profiteren van geautomatiseerde modelschaling in SageMaker, moet u ervoor zorgen dat: instantie automatisch schalen instellen om extra instantiecapaciteit te leveren. Stel uw schaalbeleid op eindpuntniveau in met aangepaste parameters of aanroepen per minuut (aanbevolen) om meer instanties toe te voegen aan de eindpuntvloot.

Gebruiksscenario's die het meest geschikt zijn voor MME

SageMaker-eindpunten met meerdere modellen zijn zeer geschikt voor het hosten van een groot aantal vergelijkbare modellen die u kunt bedienen via een gedeelde servercontainer en die niet alle modellen tegelijkertijd hoeft te openen. MME is het meest geschikt voor modellen die qua grootte en aanroeplatentie vergelijkbaar zijn. Enige variatie in modelgrootte is acceptabel; de modellen van Zendesk variëren bijvoorbeeld van 10–50 Mb, wat prima werkt, maar variaties in grootte die een factor 10, 50 of 100 keer groter zijn, zijn niet geschikt. Grotere modellen kunnen leiden tot een groter aantal laad- en losbewerkingen van kleinere modellen om voldoende geheugenruimte te kunnen bieden, wat kan resulteren in extra latentie op het eindpunt. Verschillen in prestatiekenmerken van grotere modellen kunnen ook ongelijkmatige bronnen zoals CPU verbruiken, wat van invloed kan zijn op andere modellen op de instantie.

MME is ook ontworpen voor co-hosting van modellen die hetzelfde ML-framework gebruiken, omdat ze de gedeelde container gebruiken om meerdere modellen te laden. Daarom, als u een mix van ML-frameworks in uw modelvloot heeft (zoals PyTorch en TensorFlow), is SageMaker dedicated endpoints of multi-container hosting een betere keuze. Ten slotte is MME geschikt voor toepassingen die af en toe een vertraging van een koude start kunnen verdragen, omdat niet vaak gebruikte modellen kunnen worden uitgeschakeld ten gunste van vaak aangeroepen modellen. Als u een lange staart hebt van modellen die niet vaak worden gebruikt, kan een eindpunt met meerdere modellen dit verkeer efficiënt bedienen en aanzienlijke kostenbesparingen opleveren.

Samengevat

In dit bericht heb je geleerd hoe SaaS en multi-tenancy zich verhouden tot ML en hoe SageMaker multi-model endpoints multi-tenancy en kostenefficiëntie voor ML-inferentie mogelijk maken. U leerde over Zendesk's multi-tenant use case van ML-modellen per klant en hoe ze duizenden ML-modellen hosten in SageMaker MME voor hun functie Suggested Macros en 90% kostenbesparingen behaalden op gevolgtrekking in vergelijking met speciale eindpunten. Hyperpersonalisatie use cases kunnen duizenden ML-modellen vereisen, en MME is een kosteneffectieve keuze voor deze use case. We zullen doorgaan met het maken van verbeteringen in MME zodat u modellen kunt hosten met een lage latentie en met meer gedetailleerde controles voor elk gepersonaliseerd model. Om aan de slag te gaan met MME, zie Host meerdere modellen in één container achter één eindpunt.

---

Over de auteurs

Syed Jaffry is Sr. Solutions Architect bij AWS. Hij werkt met een scala aan bedrijven, van middelgrote tot grote ondernemingen, van financiële diensten tot ISV's, om hen te helpen veilige, veerkrachtige, schaalbare en hoogwaardige applicaties in de cloud te bouwen en te exploiteren.

Sowmya Manusani is Senior Staff Machine Learning Engineer bij Zendesk. Ze werkt aan het productionaliseren van op NLP gebaseerde Machine Learning-functies die gericht zijn op het verbeteren van de productiviteit van agenten voor duizenden Zendesk Enterprise-klanten. Ze heeft ervaring met het bouwen van geautomatiseerde trainingspijplijnen voor duizenden gepersonaliseerde modellen en deze te bedienen met behulp van veilige, veerkrachtige, schaalbare en krachtige applicaties. In haar vrije tijd lost ze graag puzzels op en probeert ze te schilderen.

Saurabh Trikande is een Senior Product Manager voor Amazon SageMaker Inference. Hij heeft een passie voor het werken met klanten en het toegankelijker maken van machine learning. In zijn vrije tijd houdt Saurabh van wandelen, leren over innovatieve technologieën, TechCrunch volgen en tijd doorbrengen met zijn gezin.

Diepte Ragha is een Software Development Engineer in het Amazon SageMaker-team. Haar huidige werk is gericht op het bouwen van functies om machine learning-modellen efficiënt te hosten. In haar vrije tijd houdt ze van reizen, wandelen en planten kweken.

• Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. GRATIS TOEGANG.
• CryptoHawk. Altcoin-radar. Gratis proefversie.
• Bron: https://aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/