Kör och optimera slutpunkter för flera modeller med Amazon SageMaker-slutpunkter för flera modeller

Amazon SageMaker multi-model endpoint (MME) gör det möjligt för dig att kostnadseffektivt distribuera och vara värd för flera modeller i en enda endpoint och sedan horisontellt skala slutpunkten för att uppnå skala. Som illustreras i följande figur är detta en effektiv teknik för att implementera multi-tenancy av modeller inom din maskininlärning (ML) infrastruktur. Vi har sett Software as a Service (SaaS)-företag använda den här funktionen för att tillämpa hyperpersonalisering i sina ML-modeller samtidigt som de uppnår lägre kostnader.

För en översikt över hur MME fungerar på hög nivå, kolla in AWS Summit-videon Skala ML till nästa nivå: Hosting för tusentals modeller på SageMaker. För att lära dig mer om de hyperanpassade användningsfallen för flera hyresgäster som MME möjliggör, se Hur man skalar inferens för maskininlärning för SaaS-användningsfall med flera hyresgäster.

I resten av det här inlägget dyker vi djupare in i SageMaker MMEs tekniska arkitektur och delar med oss ​​av bästa praxis för att optimera dina flermodellslutpunkter.

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 modeller som du kan servera genom en delad serveringsbehållare och du behöver inte komma åt alla modeller samtidigt. Beroende på storleken på slutpunktsinstansminnet kan en modell ibland laddas ur från minnet till förmån för att ladda en ny modell för att maximera effektiv användning av minnet, därför måste din applikation vara tolerant mot enstaka latensspikar på oladdade modeller.

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 modeller laddas vid första anropet och sällan använda modeller kan laddas bort från minnet till förmån för att ladda nya modeller. Därför, om du har en blandning av modeller som används ofta och sällan, kan en slutpunkt med flera modeller effektivt betjäna denna trafik med färre resurser och högre kostnadsbesparingar.

Vi har också sett några scenarier där kunder distribuerar ett MME-kluster med tillräckligt med samlad minneskapacitet för att passa alla deras modeller, och därmed undviker modellavlastningar helt och hållet men ändå uppnår kostnadsbesparingar på grund av den delade inferensinfrastrukturen.

Modell av serveringsbehållare

När du använder SageMaker Inference Toolkit eller en förbyggd SageMaker-modell serveringsbehållare som är kompatibel med MME, har din behållare Multi Model Server (JVM-process) körs. Det enklaste sättet att få Multi Model Server (MMS) inbyggd i din modellserveringsbehållare är att använda SageMaker modell serveringscontainrar kompatibel med MME (leta efter de med Job Type=inferens och CPU/GPU=CPU). MMS är ett lättanvänt verktyg med öppen källkod för att tjäna modeller för djupinlärning. Det tillhandahåller ett REST API med en webbserver för att betjäna och hantera flera modeller på en enda värd. Det är dock inte obligatoriskt att använda MMS; du kan implementera din egen modellserver så länge den implementerar API:er som krävs av MME.

När de används som en del av MME-plattformen kanaliseras alla förutsägelse, laddning och avlastning av API-anrop till MMS eller din egen modellserver via MME-dataplansstyrenheten. API-anrop från dataplanskontrollern görs endast via lokal värd för att förhindra obehörig åtkomst från utsidan av instansen. En av de viktigaste fördelarna med MMS är att det möjliggör ett standardiserat gränssnitt för att ladda, lossa och anropa modeller med kompatibilitet över ett brett utbud av ramverk för djupinlärning.

Avancerad konfiguration av MMS

Om du väljer att använda MMS för modellvisning, överväg följande avancerade konfigurationer för att optimera skalbarheten och genomströmningen av dina MME-instanser.

Öka inferensparallelliteten per modell

MMS skapar en eller flera Python-arbetsprocesser per modell baserat på värdet av default_workers_per_model konfigurationsparameter. Dessa Python-arbetare hanterar varje enskild slutledningsbegäran genom att köra alla förbearbetnings-, prediktions- och efterbearbetningsfunktioner som du tillhandahåller. För mer information, se anpassad servicehanterare GitHub -repo.

Att ha mer än en modellarbetare ökar parallelliteten i förutsägelser som kan tjänas av en given modell. Men när ett stort antal modeller finns på en instans med ett stort antal processorer bör du utföra ett belastningstest av din MME för att hitta det optimala värdet för default_workers_per_model för att förhindra att minne eller CPU-resurser töms.

Design för trafikspikar

Varje MMS-process inom en slutpunktsinstans har en förfrågningskö som kan konfigureras med job_queue_size parameter (standard är 100). Detta bestämmer antalet förfrågningar MMS kommer att köa när alla arbetsprocesser är upptagna. Använd den här parametern för att finjustera lyhördheten för dina slutpunktsinstanser efter att du har bestämt dig för det optimala antalet arbetare per modell.

I ett optimalt förhållande mellan arbetare per modell bör standardvärdet 100 vara tillräckligt i de flesta fall. Men för de fall där begäranden trafik till ändpunkten ökar ovanligt, kan du minska storleken på kön om du vill att ändpunkten ska misslyckas snabbt för att skicka kontrollen till applikationen eller öka köns storlek om du vill att ändpunkten ska absorbera spiken .

Maximera minnesresurserna per instans

När du använder flera arbetsprocesser per modell laddar varje arbetsprocess som standard sin egen kopia av modellen. Detta kan minska det tillgängliga instansminnet för andra modeller. Du kan optimera minnesutnyttjandet genom att dela en enda modell mellan arbetsprocesser genom att ställa in konfigurationsparametern preload_model=true. Här byter du ut minskad inferensparallellism (på grund av en enda modellinstans) med mer minneseffektivitet. Den här inställningen tillsammans med flera arbetsprocesser kan vara ett bra val för användningsfall där modellfördröjningen är låg men du har tyngre förbearbetning och efterbearbetning (som görs av arbetsprocesserna) per slutledningsbegäran.

Ställ in värden för avancerade MMS-konfigurationer

MMS använder en config.properties-fil för att lagra konfigurationer. MMS använder följande ordning för att hitta denna config.properties-fil:

1. Om MMS_CONFIG_FILE miljövariabeln är inställd, MMS laddar konfigurationen från miljövariabeln.
2. Om --mms-config parametern skickas till MMS, den laddar konfigurationen från parametern.
3. Om det är en config.properties i aktuell mapp där användaren startar MMS, laddar den config.properties fil från den aktuella arbetskatalogen.

Om inget av ovanstående anges laddar MMS den inbyggda konfigurationen med standardvärden.

Följande är ett kommandoradsexempel på att starta MMS med en explicit konfigurationsfil:

multi-model-server --start --mms-config /home/mms/config.properties

Nyckelmått för att övervaka din slutpunktsprestanda

Nyckelmåtten som kan hjälpa dig att optimera din MME är vanligtvis relaterade till CPU- och minnesanvändning och slutledningslatens. Mätvärdena på instansnivå sänds ut av MMS, medan latensmåtten kommer från MME. I det här avsnittet diskuterar vi typiska mått som du kan använda för att förstå och optimera din MME.

Mätvärden på slutpunktsinstansnivå (MMS-statistik)

Från lista över MMS-statistik, CPUUtilization och MemoryUtilization kan hjälpa dig att utvärdera om din instans eller MME-klustret har rätt storlek eller inte. Om båda mätvärdena har procentsatser mellan 50–80 %, är din MME rätt storlek.

Vanligtvis är låg CPUUtilization och hög MemoryUtilization en indikation på ett överprovisionerat MME-kluster eftersom det indikerar att sällan anropade modeller inte laddas ur. Detta kan bero på ett högre än optimalt antal slutpunktsinstanser som tillhandahålls för MME och därför finns ett högre än optimalt aggregerat minne tillgängligt för sällan åtkomst till modeller för att finnas kvar i minnet. Omvänt betyder nära 100 % användning av dessa mätvärden att ditt kluster är undertillgängligt, så du måste justera din policy för automatisk skalning av kluster.

Statistik på plattformsnivå (MME-statistik)

Från fullständig lista över MME-mått, ett nyckelmått som kan hjälpa dig att förstå fördröjningen av din inferensförfrågan är ModelCacheHit. Detta mått visar det genomsnittliga förhållandet av anropsbegäranden för vilka modellen redan laddades i minnet. Om detta förhållande är lågt indikerar det att ditt MME-kluster är underprovisionerat eftersom det sannolikt inte finns tillräckligt med samlad minneskapacitet i MME-klustret för antalet unika modellanrop, vilket gör att modeller ofta laddas ur minnet.

Lärdomar från fältet och strategier för att optimera MME

Vi har sett följande rekommendationer från några av de högskaliga användningarna av MME hos ett antal kunder.

Horisontell skalning med mindre instanser är bättre än vertikal skalning med större instanser

Du kan uppleva strypning på modellanrop när du kör höga förfrågningar per sekund (RPS) på färre slutpunktsinstanser. Det finns interna gränser för antalet anrop per sekund (laddningar och urladdningar som kan ske samtidigt på en instans), och därför är det alltid bättre att ha ett högre antal mindre instanser. Att köra ett högre antal mindre instanser innebär en högre total kapacitet för dessa gränser för slutpunkten.

En annan fördel med horisontell skalning med mindre instanser är att du minskar risken att tömma instansernas CPU- och minnesresurser när du kör MMS med högre nivåer av parallellitet, tillsammans med ett högre antal modeller i minnet (som beskrivits tidigare i det här inlägget).

Att undvika trassling är ett delat ansvar

Stryk i MME är när modeller ofta laddas ur minnet och laddas om på grund av otillräckligt minne, antingen i en enskild instans eller på aggregat i klustret.

Ur ett användningsperspektiv bör du göra rätt storlek på enskilda slutpunktsinstanser och rätt storlek på den totala storleken på MME-klustret för att säkerställa att det finns tillräckligt med minneskapacitet per instans och även sammantaget för klustret för ditt användningsfall. MME-plattformens routerflotta kommer också att maximera cacheträffen.

Var inte aggressiv med att packa för många modeller på färre, större minnesinstanser

Minnet är inte den enda resursen i instansen att vara medveten om. Andra resurser som CPU kan vara en begränsande faktor, vilket framgår av följande belastningstestresultat. I vissa andra fall har vi också observerat att andra kärnresurser som process-ID:n är uttömda på en instans, på grund av en kombination av för många modeller som laddas och det underliggande ML-ramverket (som TensorFlow) genererade trådar per modell som var multiplar av tillgängliga vCPU:er.

Följande prestandatest visar ett exempel på CPU-begränsningar som påverkar modellens latens. I detta test producerade en enda instansslutpunkt med en stor instans, samtidigt som den hade mer än tillräckligt med minne för att behålla alla fyra modellerna i minnet, jämförelsevis sämre modelllatenser under belastning jämfört med en slutpunkt med fyra mindre instanser.

slutpunktsmodellens fördröjning för en instans

enda instans CPU och minnesanvändning

fyra instansers slutpunktsmodell latens

fyra instansers slutpunkt CPU och minnesanvändning

För att uppnå både prestanda och kostnadseffektivitet, rätt storlek på ditt MME-kluster med ett högre antal mindre instanser som sammantaget ger dig optimalt minne och CPU-kapacitet samtidigt som det är relativt prisvärd med färre men större minnesinstanser.

Mental modell för att optimera MME

Det finns fyra nyckelmått som du alltid bör tänka på när du ska anpassa din MME till rätt storlek:

• Antalet och storleken på modellerna
• Antalet unika modeller som anropas vid en given tidpunkt
• Förekomstens typ och storlek
• Inkomsträkningen bakom slutpunkten

Börja med de två första punkterna, eftersom de informerar den tredje och fjärde. Till exempel, om det inte finns tillräckligt många instanser bakom ändpunkten för antalet eller storleken av unika modeller du har, kommer det aggregerade minnet för ändpunkten att vara lågt och du kommer att se en lägre cacheträffförhållande och trampning på ändpunktsnivån eftersom MME kommer att ladda och ladda ur modeller i och ur minnet ofta.

På liknande sätt, om anropen för unika modeller är högre än det samlade minnet för alla instanser bakom slutpunkten, kommer du att se en lägre cacheträff. Detta kan också hända om storleken på instanser (särskilt minneskapacitet) är för liten.

Vertikal skalning med riktigt stora minnesinstanser kan också leda till problem eftersom även om modellerna kan passa in i minnet kan andra resurser som CPU- och kärnprocesser och trådgränser vara uttömda. Ladda testa horisontell skalning i förproduktion för att få det optimala antalet och storleken på instanser för din MME.

Sammanfattning

I det här inlägget fick du en djupare förståelse för MME-plattformen. Du lärde dig vilka tekniska användningsfall MME lämpar sig för och granskade MME-plattformens arkitektur. Du fick en djupare förståelse för varje komponents roll inom MME-arkitekturen och vilka komponenter du direkt kan påverka prestandan för. Slutligen fick du en djupare titt på konfigurationsparametrarna som du kan justera för att optimera MME för ditt användningsfall och de mätvärden du bör övervaka för att bibehålla optimal prestanda.

För att komma igång med MME, granska Amazon SageMaker Multi-Model Endpoints med XGBoost och Värd för flera modeller i en container bakom en slutpunkt.

Om författaren

Syed Jaffry är en Principal Solutions Architect med AWS. Han arbetar med en rad företag från medelstora organisationer, stora företag, finansiella tjänster och ISV:er för att hjälpa dem att bygga och driva kostnadseffektiva och skalbara AI/ML-applikationer i molnet.

Saurabh Trikande är senior produktchef för Amazon SageMaker Inference. Han brinner för att arbeta med kunder och motiveras av målet att demokratisera maskininlärning. Han fokuserar på kärnutmaningar relaterade till att distribuera komplexa ML-applikationer, multi-tenant ML-modeller, kostnadsoptimeringar och att göra implementeringen av djupinlärningsmodeller mer tillgänglig. På sin fritid gillar Saurabh att vandra, lära sig om innovativ teknik, följa TechCrunch och umgås med sin familj.