Komma igång med att distribuera realtidsmodeller på Amazon SageMaker

Amazon SageMaker är en helt hanterad tjänst som ger varje utvecklare och datavetare möjligheten att snabbt bygga, träna och distribuera maskininlärningsmodeller (ML) i stor skala. ML realiseras i slutledning. SageMaker erbjuder fyra inferensalternativ:

1. Realtidsinferens
2. Serverlös slutledning
3. Asynkron slutledning
4. Batchtransform

Dessa fyra alternativ kan i stort sett klassificeras i online- och batch-inferensalternativ. I Online Inference förväntas förfrågningar behandlas när de anländer, och den konsumerande applikationen förväntar sig ett svar efter att varje begäran har behandlats. Detta kan antingen ske synkront (realtidsinferens, serverlös) eller asynkront (asynkron slutledning). I ett synkront mönster blockeras den konsumerande applikationen och kan inte fortsätta förrän den får ett svar. Dessa arbetsbelastningar tenderar att vara realtidsapplikationer, såsom upptäckt av kreditkortsbedrägerier online, där svar förväntas i storleksordningen millisekunder till sekunder och förfrågningsnyttolasten är liten (några MB). I det asynkrona mönstret är applikationsupplevelsen inte blockerad (till exempel genom att lämna in ett försäkringskrav via en mobilapp) och kräver vanligtvis större nyttolaststorlekar och/eller längre handläggningstider. I Offline-inferens bearbetas en aggregering (batch) av slutledningsbegäranden tillsammans, och svar ges först efter att hela batchen har bearbetats. Vanligtvis är dessa arbetsbelastningar inte latenskänsliga, involverar stora volymer (flera GB) data och är schemalagda med en vanlig takt (till exempel kör objektdetektering på övervakningskameror i slutet av dagen eller bearbeta lönedata vid slutet av månaden).

Vid de bara benen, SageMaker Real-Time Inference består av en modell(er), ramverket/behållaren som du arbetar med och infrastrukturen/instanserna som backar upp din distribuerade slutpunkt. I det här inlägget kommer vi att utforska hur du kan skapa och anropa en Endpoint för en enda modell.

Välja modelldistributionsalternativ

Att välja rätt slutledningstyp kan vara svårt, och följande enkla guide kan hjälpa dig. Det är inte ett strikt flödesschema, så om du upptäcker att ett annat alternativ fungerar bättre för dig, använd gärna dem. I synnerhet är Real-Time Inference ett utmärkt alternativ för att vara värd för dina modeller när du har låg och konsekvent latens (i storleksordningen millisekunder eller sekunder) och genomströmningskänsliga arbetsbelastningar. Du kan styra instanstypen och räkna efter din slutpunkt samtidigt som du konfigurerar AutoScaling policy för att hantera trafik. Det finns två andra SageMaker Inference-alternativ som du också kan använda för att skapa en slutpunkt. Asynkron inferens är när du har stora nyttolaststorlekar och nästan realtids latensbandbredd. Detta är ett bra alternativ, särskilt för NLP- och Computer Vision-modeller som har längre förbearbetningstider. Serverless Inference är ett utmärkt alternativ när du har intermittent trafik och inte vill hantera infrastrukturskalning. Receptet för att skapa en slutpunkt förblir detsamma oavsett vilken slutledningstyp du väljer. I det här inlägget kommer vi att fokusera på att skapa en instansbaserad slutpunkt i realtid, men du kan enkelt anpassa den till något av de andra slutledningsalternativen baserat på ditt användningsfall. Slutligen sker Batch-inferens offline, så du kan tillhandahålla en uppsättning data som du vill få slutledning från och vi kör den. Detta är på liknande sätt instansbaserat, så du kan välja den optimala instansen för din arbetsbelastning. Eftersom det inte finns någon slutpunkt igång, betalar du bara för jobbets varaktighet. Det är bra för att bearbeta gigabyte med data och jobbet kan vara dagar. Det finns inbyggda funktioner för att göra arbetet med strukturerad data enklare och optimeringar för att automatiskt distribuera strukturerad data. Några exempel på användningsfall är benägenhetsmodellering, prediktivt underhåll och churn-prediktion. Alla dessa kan ske offline i bulk eftersom det inte behöver reagera på en specifik händelse.

Värd för en modell på SageMaker Endpoints

Vid kruxet består SageMaker Real-Time Endpoints av en modell och den infrastruktur som du väljer att backa upp Endpoint med. SageMaker använder behållare för att vara värd för modeller, vilket innebär att du behöver en behållare som korrekt ställer in miljön för det ramverk som du använder för varje modell du tillhandahåller. Om du till exempel arbetar med en Sklearn-modell måste du skicka in dina modellskript/data i en behållare som korrekt konfigurerar Sklearn. Lyckligtvis ger SageMaker hanterade bilder för populära ramverk, som TensorFlow, PyTorch, Sklearn och HuggingFace. Du kan hämta och använda dessa bilder med hjälp av högnivån SageMaker Python SDK och injicera dina modellskript och data i dessa behållare. Om SageMaker inte har en behållare som stöds kan du också Bygg din egen container och tryck på din egen anpassade bild, installera de beroenden som är nödvändiga för din modell.

SageMaker stöder både tränade och förtränade modeller. I föregående stycke när vi pratar om modellskript/data, hänvisar vi till denna fråga. Du kan antingen montera ett skript på din behållare eller om du har en förtränad modellartefakt (till exempel `model.joblib` för SKLearn), då kan du tillhandahålla detta tillsammans med din bild till SageMaker. För att förstå SageMaker Inference finns det tre huvudenheter som du kommer att skapa i processen för att skapa slutpunkter:

1. SageMaker Model Entity – Här kan du skicka in din tränade modelldata/modellskript och din bild som du arbetar med, oavsett om den ägs av AWS eller byggd av dig.
2. Skapa slutpunktskonfiguration – Här definierar du din infrastruktur, vilket innebär att du väljer instanstyp, antal osv.
3. Skapande av slutpunkter – Detta är REST-slutpunkten som är värd för din modell som du anropar för att få ett svar. Låt oss titta på hur du kan använda en hanterad SageMaker-bild och din egen specialbyggda bild för att distribuera en slutpunkt.

Krav på slutpunkter i realtid

1. Innan du skapar en slutpunkt måste du förstå vilken typ av modell du vill vara värd för. Om det är en rammodell, som TensorFlow, PyTorch eller MXNet, kan du använda en av förbyggda rambilder.
   Om det är en anpassad modell, eller om du vill ha full flexibilitet när det gäller att skapa behållaren som SageMaker kommer att köra för slutledning, kan du bygga din egen behållare.

SageMaker slutpunkter består av en SageMaker modell och Slutpunktskonfiguration.
Om du använder Boto3 skulle du skapa båda objekten. Annars, om du använder SageMaker Python SDK, skapas Endpoint Configuration på dina vägnar när du använder .deploy(..) funktion.

SageMaker-enheter:

• SageMaker modell:
  • Innehåller detaljerna i slutledningsbilden, placeringen av modellartefakterna i Amazon Simple Storage Service (Amazon S3), nätverkskonfiguration och AWS Identity and Access Management (IAM) roll som ska användas av Endpoint.
    • SageMaker kräver att dina modellartefakter komprimeras i en .tar.gz fil. SageMaker extraherar detta automatiskt .tar.gz filen i /opt/ml/model/ katalogen i din behållare. Om du använder en av rambehållarna, som TensorFlow, PyTorch eller MXNet, förväntar sig behållaren att din TAR-struktur är följande:
      • TensorFlow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MX Net
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • Sklearn
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • När vi använder en rambild kan vi tillhandahålla ett anpassat ingångsskript, där vi kan implementera vår egen för- och efterbehandling. I vårt fall är inferensskriptet paketerat i model.tar.gz under /code-katalogen.

• • Slutpunktskonfiguration
    • Innehåller den infrastrukturinformation som krävs för att distribuera SageMaker-modellen till Endpoint.
    • Till exempel specificeras SageMaker-modellen som vi skapade här, liksom instanstypen och antalet initiala instanser.

Frameworks och BYOC

• • Hämtar SageMaker-bilder
    • Denna del är inte alltid nödvändig och abstraheras ut av SageMaker Python SDK via estimatorer. Men om du skulle vilja kunna hämta en SageMaker-hanterad bild för att utöka den, så kan du få de bilder som är tillgängliga via SDK:n. Följande är ett exempel på att hämta en TF 2.2-bild för slutledning.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • Ramar
    • Om du vill distribuera en rammodell, som TensorFlow, PyTorch eller MXNet, behöver du bara modellartefakterna.
    • Se dokumentationen för att distribuera modeller direkt från modellartefakter för TensorFlow, PyTorch, eller MX Net.

• • Välj mellan 1P och BYOC
    • SageMaker SDK abstraherar också hanteringen av bilden, som du såg i föregående Frameworks-sektion. Den har färdiga estimatorer för Sklearn, TensorFlow och PyTorch som automatiskt väljer bilden åt dig baserat på den version du har valt. Sedan kan du skicka in ett tränings-/inferensmanus Skriptläge i dessa skattare.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • Inte alla paket och bilder stöds av SageMaker, och i det här fallet måste du ta med din egen behållare (BYOC). Detta innebär att bygga en Dockerfile som kommer att ställa in rätt miljö för din modelltjänst. Ett exempel på detta är Spacy NLP-modulen, och det finns inga hanterade SageMaker-behållare för detta ramverk. Därför måste du tillhandahålla en Dockerfile som installerar Spacy. Inuti behållaren monterar du även dina modellinferensskript. Låt oss snabbt diskutera komponenterna som du tillhandahåller i ett Bring Your Own Container-format, eftersom dessa förblir konsekventa för de flesta exempel.
      • "nginx.conf" är konfigurationsfilen för nginx-gränssnittet. Du behöver inte redigera den här filen, såvida du inte vill ställa in dessa delar.
      • "predictor.py" är programmet som faktiskt implementerar Flask-webbservern och modellkoden för din applikation. Du kan ha ytterligare Python-filer eller funktioner i din behållare som du kan anropa i den här filen.
      • "tjäna" är programmet startat när behållaren startas för hosting. Den startar helt enkelt gunicorn-servern, som kör flera instanser av Flask-appen som definieras i predictor.py. Precis som nginx.conf behöver du inte redigera den här filen om det inte finns ytterligare justeringar som du vill utföra.
      • "tåg" är programmet som anropas när containern körs för träning. Du kommer att modifiera detta program för att implementera din träningsalgoritm. Om du tar med en förutbildad modell eller ramverk som Spacy behöver du inte den här filen.
      • "wsgi.py" är ett litet omslag som används för att anropa Flask-appen. Du bör kunna ta den här filen som den är, om du inte har ändrat namnet på filen predictor.py. Se i så fall till att kartor korrekt här.

• • Anpassat slutledningsskript
    • SageMaker Framework-behållare ger dig flexibiliteten att hantera för-/efterbehandling av begäran och modellladdning med hjälp av ett anpassat ingångsskript/inference.py.
    • Se dokumentationen för att skapa ett anpassat inference.py-skript för TensorFlow, PyTorch och MX Net.
  • Anpassad behållare

Olika sätt att interagera med SageMaker Endpoints

Det finns många alternativ för att använda SageMaker programmatiskt så att du kan ringa dina distribuerade modeller för att få slutsatser. De AWS Command Line Interface (AWS CLI), REST API:er, AWS molnformation, AWS Cloud Development Kit (AWS CDK), och AWS SDK: er är vanliga verktyg som erbjuds av AWS och som stöds av andra AWS-tjänster. För SageMaker har vi även en SageMaker Python SDK. Låt oss nu jämföra de olika alternativen för att skapa, anropa och hantera SageMaker Endpoints.

Utöver SageMaker CLI, det finns två sätt programmässigt som du kan interagera med Endpoints i SageMaker genom SDK:erna. Låt oss titta på några skillnader mellan SageMaker Python SDK och Boto3 Python SDK:

1. SageMaker "Python" SDK på hög nivå – Denna SDK är ett bibliotek med öppen källkod som tillhandahåller abstraktion på högre nivå, speciellt avsedd för att anropa SageMaker API:er programmatiskt med Python. Den bra delen av denna SDK är att det är väldigt enkelt att anropa Sagemaker API:er, många tunga lyft görs redan som att anropa API:erna synkront/asynkront läge (hjälper till att undvika polling), enklare begäran/svarsschema, mycket mindre kod och mycket enklare kod. SageMaker Python SDK tillhandahåller flera abstraktioner på hög nivå för att arbeta med SageMaker. Paketet är tänkt att förenkla olika ML-processer på SageMaker.
2. Lågnivå AWS SDK (Boto3 SDK) – Denna SDK fungerar på lägre nivå genom att låta användaren välja bland de programmeringsspråk som stöds och anropa alla AWS-tjänster programmatiskt. Detta är inte bara specifikt för SageMaker utan kan användas i allmänhet för alla AWS-tjänster. AWS SDK:erna på låg nivå är tillgängliga i olika programmeringsspråk, såsom .NET, Python, Java, Node.js, etc. En av de populära SDK:erna som används är boto3 python SDK, som är populär inom dataforskargemenskapen för ML. Den goda delen av denna SDK är att den är väldigt lätt och tillgänglig som standard installerad på AWS Lambda Körning. Dessutom kan du använda denna SDK för att interagera med alla AWS-tjänster utanför SageMaker.

Båda dessa SDK:er kan användas för samma uppgifter, men i vissa fall är det mer intuitivt att använda den ena mer än den andra. SageMaker Python SDK rekommenderas för enkel testning medan AWS SDK/Boto3 rekommenderas för produktionsanvändningsfall för bättre kontroll över prestanda. Till exempel tillhandahåller SageMaker som en tjänst förbyggda och underhållna bilder för populära ramverk, som Sklearn, PyTorch och TensorFlow. Det kan vara särskilt användbart att använda SageMaker SDK för att hämta djupinlärningsbilder, träna modeller med hjälp av skattningar, och enkelt distribuera modellen med ett enkelt API-anrop. Ett exempel för att visa upp detta i aktion finns här..

Å andra sidan, ibland har du förutbildade modeller eller olika ramverk som du kanske använder. Detta kräver en större del av anpassning och SageMaker SDK erbjuder inte alltid det. Vi har tre viktiga steg och motsvarande boto3 API-anrop som vi måste köra för att distribuera en slutpunkt: Modellskapande, Skapa slutpunktskonfigurationoch Skapande av slutpunkter. De två första enheterna abstraherades ut med SageMaker SDK med våra ramar som stöds, men vi ser dessa detaljer med Boto3 SDK. Ett omfattande exempel för att visa stegen som är involverade i att använda en Boto3 SDK för att skapa och hantera en slutpunkt kan hittas här..

Överväganden om SageMaker-värd

SageMaker Real-Time Inference har två huvudsakliga optimeringar som du kan överväga: 1/ Prestandaoptimering och 2/ Kostnadsoptimering. Låt oss först titta på prestandaoptimering, som när vi har att göra med latenskänsliga arbetsbelastningar, är varje millisekund avgörande. Det finns olika rattar som du kan ställa in för att optimera din latens och genomströmning. På instansnivå kan du använda Slutledningsrekommendator, vårt inbyggda belastningstestverktyg, för att hjälpa dig välja rätt instanstyp och räkna för din arbetsbelastning. Att använda rätt kombination av beräkning kommer att hjälpa dig med både prestanda och kostnad. Du kan också ställa in på container- och ramnivå.
Frågor att ställa dig själv inkluderar:

1. Vilket ramverk använder du?
2. Finns det några miljövariabler som du kan ställa in i din behållare?

Ett exempel på detta är maximering TensorFlow-prestanda med SageMaker-behållare. Ett annat exempel på optimering av behållarnivå är använder gRPC snarare än REST bakom din slutpunkt. Slutligen kan du också optimera på skriptnivå. Tar din slutledningskod extra tid vid vissa block? Att tajma varje rad i ditt skript hjälper dig att fånga eventuella flaskhalsar i din kod.

Det finns tre sätt att se på förbättra utnyttjandet av din realtidsslutpunkt:

1. Multi-model Endpoints (MME)
   • Du kan vara värd för tusentals modeller bakom en enda slutpunkt. Detta är perfekt för användningsfall där du inte behöver en dedikerad slutpunkt för var och en av dina modeller. MME fungerar bäst när modellerna har samma storlek och fördröjning och tillhör samma ML-ramverk. Dessa kan vanligtvis användas när du inte behöver ringa samma modell hela tiden. Du kan dynamiskt ladda respektive modell till SageMaker Endpoint för att betjäna din begäran. Ett exempel som visar MME i aktion finns här.. Om du vill lära dig mer om de olika varningarna och bästa praxis för värdmodeller på MME, se inlägget här..
2. Multi-Container Endpoints (MCE)
   • Istället för att använda flera slutpunkter för att vara värd för flera behållare, kan du titta på att vara värd för upp till 15 behållare på en enda slutpunkt. Var och en av dessa behållare kan anropas direkt. Därför kan du titta på att vara värd för olika modeller av olika ramverk på en enda slutpunkt. Det här alternativet är bäst när behållare uppvisar liknande användnings- och prestandaegenskaper. Ett exempel som visar upp MCE finns här.. Om du vill lära dig mer om de olika varningarna och bästa praxis för värdmodeller på MCE, se inlägget här..
3. Serial Inference Pipeline (SIP)
   • Om du har en pipeline med steg i din slutledningslogik, kan du använda Serial Inference Pipeline (SIP). SIP låter dig koppla samman 2-15 behållare bakom en enda ändpunkt. SIP fungerar bra när du har förbearbetnings- och efterbearbetningssteg. Om du vill lära dig mer om designmönstren för seriella slutledningsrörledningar, se inlägget här..

Den andra huvudsakliga optimeringen att tänka på är kosta. Realtidsinferens är ett av tre alternativ för att skapa SageMaker Endpoints. SageMaker Endpoints körs hela tiden om de inte raderas. Därför måste du titta på att förbättra utnyttjandet av endpointen vilket i sin tur ger en kostnadsfördel.

SageMaker erbjuder också Sparplaner. Sparplaner kan minska dina kostnader med upp till 64 %. Detta är ett åtagande på 1 eller 3 år för en konsekvent mängd användning ($/timme). Se detta länk för mer information. Och se detta länk för att på bästa sätt optimera kostnaderna för Inference på Amazon SageMaker.

Slutsats

I det här inlägget visade vi dig några av de bästa metoderna för att välja mellan olika modellvärdalternativ på SageMaker. Vi diskuterade SageMaker Endpoint-kraven och kontrasterade också kraven och funktionaliteten för ramverk och BYOC. Dessutom pratade vi om de olika sätten som du kan utnyttja Real-Time Endpoints för att vara värd för dina ML-modeller i produktion. på ett kostnadseffektivt sätt och har hög prestanda.

Se motsvarande GitHub repository och prova exemplen.

---

Om författarna

Raghu Ramesha är en ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att bygga, distribuera och migrera ML-produktionsarbetsbelastningar till SageMaker i stor skala. Han är specialiserad på domäner för maskininlärning, AI och datorseende och har en magisterexamen i datavetenskap från UT Dallas. På fritiden tycker han om att resa och fotografera.

Ram Vegiraju är en ML-arkitekt med SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att bygga och optimera sina AI/ML-lösningar på Amazon SageMaker. På fritiden älskar han att resa och skriva.

Marc Karp är en ML-arkitekt med SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att designa, distribuera och hantera ML-arbetsbelastningar i stor skala. På fritiden tycker han om att resa och utforska nya platser.

Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning, inklusive NLP och datorseende domäner. Han hjälper kunder att uppnå högpresterande modellslutledning på Amazon SageMaker.

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.