Designmönster för seriell slutledning på Amazon SageMaker

I takt med att maskininlärning (ML) blir mainstream och får bredare användning, blir ML-drivna applikationer allt vanligare för att lösa en rad komplexa affärsproblem. Lösningen på dessa komplexa affärsproblem kräver ofta att man använder flera ML-modeller. Dessa modeller kan kombineras sekventiellt för att utföra olika uppgifter, såsom förbearbetning, datatransformation, modellval, slutledningsgenerering, slutledningskonsolidering och efterbearbetning. Organisationer behöver flexibla alternativ för att orkestrera dessa komplexa ML-arbetsflöden. Seriella slutledningspipelines är ett sådant designmönster för att arrangera dessa arbetsflöden i en serie steg, där varje steg berikar eller vidarebearbetar utdata som genererats av de föregående stegen och skickar utdata till nästa steg i pipelinen.

Dessutom bör dessa seriella slutledningsledningar tillhandahålla följande:

• Flexibel och anpassad implementering (beroenden, algoritmer, affärslogik och så vidare)
• Repeterbar och konsekvent för produktionsimplementering
• Odifferentierade tunga lyft genom att minimera infrastrukturhanteringen

I det här inlägget tittar vi på några vanliga användningsfall för seriella slutledningspipelines och går igenom några implementeringsalternativ för vart och ett av dessa användningsfall med Amazon SageMaker. Vi diskuterar också överväganden för vart och ett av dessa implementeringsalternativ.

Följande tabell sammanfattar de olika användningsfallen för seriell slutledning, implementeringsöverväganden och alternativ. Dessa diskuteras i detta inlägg.

I de följande avsnitten diskuterar vi varje användningsfall mer i detalj.

Seriell slutledningspipeline med inferensbehållare

Användningsfall för seriella slutledningar har krav på att förbehandla inkommande data innan en förutbildad ML-modell för att generera slutsatser anropas. I vissa fall kan dessutom de genererade slutledningarna behöva bearbetas ytterligare så att de enkelt kan konsumeras av nedströmsapplikationer. Detta är ett vanligt scenario för användningsfall där en strömmande datakälla måste bearbetas i realtid innan en modell kan monteras på den. Men detta användningsfall kan också visa sig för batch slutledning.

SageMaker erbjuder ett alternativ för att anpassa slutledningsbehållare och använda dem för att bygga en seriell slutledningspipeline. Slutledningsbehållare använder SageMaker Inference Toolkit och är byggda på SageMaker Multi Model Server (MMS), som tillhandahåller en flexibel mekanism för att betjäna ML-modeller. Följande diagram illustrerar ett referensmönster för hur man implementerar en seriell slutledningspipeline med hjälp av slutledningsbehållare.

SageMaker MMS förväntar sig ett Python-skript som implementerar följande funktioner för att ladda modellen, förbehandla indata, hämta förutsägelser från modellen och efterbehandla utdata:

• input_fn () – Ansvarig för deserialisering och förbearbetning av indata
• model_fn () – Ansvarig för att ladda in den tränade modellen från artefakter Amazon enkel lagringstjänst (Amazon S3)
• predict_fn () – Ansvarig för att generera slutsatser från modellen
• output_fn () – Ansvarig för serialisering och efterbearbetning av utdata (slutledningar)

För detaljerade steg för att anpassa en slutledningsbehållare, se Anpassa din egen slutledningsbehållare.

Slutledningsbehållare är ett idealiskt designmönster för användning av seriella slutledningsrörledningar med följande primära överväganden:

• Hög sammanhållning – Bearbetningslogiken och motsvarande modell driver en enda affärsfunktionalitet och måste samlokaliseras
• Låg total latens – Den tid som förflutit mellan det att en begäran om slutsats görs och svaret tas emot

I en seriell slutledningspipeline är bearbetningslogiken och modellen inkapslade i samma enda behållare, så mycket av anropsanropen förblir i behållaren. Detta hjälper till att minska det totala antalet hopp, vilket resulterar i bättre total latens och känslighet för pipelinen.

Dessutom, för användningsfall där enkel implementering är ett viktigt kriterium, kan slutledningsbehållare hjälpa, med olika bearbetningssteg i pipelinen samlokaliseras inom samma behållare.

Seriell inferenspipeline med hjälp av en SageMaker inferenspipeline

En annan variant av användningsfallet för serieslutningspipeline kräver tydligare frikoppling mellan de olika stegen i pipelinen (såsom dataförbehandling, slutledningsgenerering, efterbearbetning av data och formatering och serialisering). Detta kan bero på flera olika orsaker:

• frikoppling – Olika steg i pipelinen har ett klart definierat syfte och måste köras på separata behållare på grund av de underliggande beroenden som är involverade. Detta hjälper också till att hålla pipelinen välstrukturerad.
• Ramar – Olika steg i pipelinen använder specifika ramverk som passar för ändamålet (som scikit eller Spark ML) och måste därför köras på separata behållare.
• Resursisolering – Olika steg i pipelinen har varierande resursförbrukningskrav och måste därför köras på separata containrar för mer flexibilitet och kontroll.

Dessutom, för lite mer komplexa seriella slutledningspipelines, kan flera steg vara involverade för att behandla en begäran och generera en slutledning. Ur operativ synvinkel kan det därför vara fördelaktigt att ha dessa steg på separata behållare för bättre funktionell isolering och underlätta enklare uppgraderingar och förbättringar (ändra ett steg utan att påverka andra modeller eller bearbetningssteg).

Om ditt användningsfall överensstämmer med några av dessa överväganden, a SageMaker inferenspipeline ger ett enkelt och flexibelt alternativ för att bygga en seriell slutledningspipeline. Följande diagram illustrerar ett referensmönster för hur man implementerar en seriell slutledningspipeline med hjälp av flera steg på dedikerade behållare med hjälp av en SageMaker inferenspipeline.

En SageMaker-inferenspipeline består av en linjär sekvens av 2–15 behållare som behandlar förfrågningar om slutsatser om data. Slutledningspipelinen ger möjlighet att använda förtränade SageMaker inbyggda algoritmer eller anpassade algoritmer förpackade i Docker-behållare. Behållarna finns på samma underliggande instans, vilket hjälper till att minska den totala latensen och minimera kostnaden.

Följande kodavsnitt visar hur flera bearbetningssteg och modeller kan kombineras för att skapa en seriell slutledningspipeline.

Vi börjar med att bygga och specificera Spark ML och XGBoost-baserade modeller som vi tänker använda som en del av pipelinen:

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

Modellerna arrangeras sedan sekventiellt inom pipelinemodellens definition:

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

Slutledningspipelinen distribueras sedan bakom en slutpunkt för realtidsinferens genom att specificera typen och antalet värd-ML-instanser:

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

Hela den sammansatta slutledningspipelinen kan betraktas som en SageMaker-modell som du kan använda för att göra antingen realtidsförutsägelser eller bearbeta batchtransformationer direkt, utan någon extern förbearbetning. Inom en inferenspipelinemodell hanterar SageMaker anrop som en sekvens av HTTP-förfrågningar som kommer från en extern applikation. Den första behållaren i pipelinen hanterar den initiala begäran, utför viss bearbetning och skickar sedan det mellanliggande svaret som en begäran till den andra behållaren i pipelinen. Detta händer för varje behållare i pipelinen och returnerar slutligen det slutliga svaret till den anropande klientapplikationen.

SageMaker inferenspipelines är helt hanterade. När pipelinen är utplacerad installerar och kör SageMaker alla definierade behållare på var och en av Amazon Elastic Compute Cloud (Amazon EC2)-instanser tillhandahållna som en del av slutpunkts- eller batchtransformeringsjobbet. Dessutom, eftersom behållarna är samlokaliserade och värdar på samma EC2-instans, reduceras den totala pipeline-latensen.

Seriemodellensemble som använder en SageMaker-inferenspipeline

En ensemblemodell är ett tillvägagångssätt i ML där flera ML-modeller kombineras och används som en del av slutledningsprocessen för att generera slutliga slutsatser. Motiven för ensemblemodeller kan bland annat inkludera att förbättra noggrannheten, minska modellens känslighet för specifika indatafunktioner och minska enstaka modellbias. I det här inlägget fokuserar vi på användningsfall relaterade till en seriemodellensemble, där flera ML-modeller kombineras sekventiellt som en del av en seriell inferenspipeline.

Låt oss överväga ett specifikt exempel relaterat till en seriemodellensemble där vi behöver gruppera en användares uppladdade bilder baserat på vissa teman eller ämnen. Denna pipeline kan bestå av tre ML-modeller:

• Modell 1 – Accepterar en bild som indata och utvärderar bildkvalitet baserat på bildupplösning, orientering och mer. Denna modell försöker sedan uppskala bildkvaliteten och skickar de bearbetade bilderna som uppfyller en viss kvalitetströskel till nästa modell (modell 2).
• Modell 2 – Accepterar bilder validerade genom Model 1 och utför bildigenkänning för att identifiera objekt, platser, personer, text och andra anpassade åtgärder och koncept i bilder. Utdata från Model 2 som innehåller identifierade objekt skickas till Model 3.
• Modell 3 – Accepterar utdata från Model 2 och utför naturliga språkbearbetningsuppgifter (NLP) såsom ämnesmodellering för att gruppera bilder baserat på teman. Till exempel kan bilder grupperas baserat på plats eller identifierade personer. Utdata (grupperingar) skickas tillbaka till klientapplikationen.

Följande diagram illustrerar ett referensmönster för hur man implementerar flera ML-modeller på en seriemodellensemble med hjälp av en SageMaker-inferenspipeline.

Som diskuterats tidigare hanteras SageMaker inferenspipeline, vilket gör att du kan fokusera på valet och utvecklingen av ML-modeller, samtidigt som du minskar de odifferentierade tunga lyften i samband med att bygga den seriella ensemblepipelinen.

Dessutom är några av de överväganden som diskuterats tidigare kring frikoppling, algoritm- och ramval för modellutveckling och implementering relevanta här också. Till exempel, eftersom varje modell är värd på en separat behållare, har du flexibilitet att välja det ML-ramverk som bäst passar varje modell och ditt övergripande användningsfall. Dessutom, ur en frikopplings- och driftssynpunkt, kan du fortsätta att uppgradera eller modifiera enskilda steg mycket lättare, utan att påverka andra modeller.

SageMaker inferenspipeline är också integrerad med SageMaker-modellregister för modellkatalogisering, versionshantering, metadatahantering och styrd distribution till produktionsmiljöer för att stödja konsekventa operativa bästa praxis. SageMaker inferenspipeline är också integrerad med amazoncloudwatch för att möjliggöra övervakning av multicontainermodellerna i inferensrörledningar. Du kan också få insyn i realtidsstatistik för att bättre förstå anrop och latens för varje behållare i pipeline, vilket hjälper till med felsökning och resursoptimering.

Seriell inferenspipeline (med riktad modellanrop från en grupp) med en SageMaker inferenspipeline

SageMaker flermodellslutpunkter (MME) tillhandahåller en kostnadseffektiv lösning för att distribuera ett stort antal ML-modeller bakom en enda slutpunkt. Motiven för att använda flermodellslutpunkter kan inkludera att anropa en specifik anpassad modell baserat på förfrågningsegenskaper (som ursprung, geografisk plats, användaranpassning och så vidare) eller helt enkelt att vara värd för flera modeller bakom samma slutpunkt för att uppnå kostnadsoptimering.

När du distribuerar flera modeller på en enda flermodellsaktiverad slutpunkt delar alla modeller beräkningsresurserna och modellbetjäningsbehållaren. SageMaker inferenspipeline kan distribueras på en MME, där en av behållarna i pipelinen dynamiskt kan betjäna förfrågningar baserat på den specifika modell som anropas. Ur ett pipelineperspektiv har modellerna identiska förbearbetningskrav och förväntar sig samma funktionsuppsättning, men är tränade för att anpassa sig till ett specifikt beteende. Följande diagram illustrerar ett referensmönster för hur denna integrerade pipeline skulle fungera.

Med MME:er bör slutledningsbegäran som härrör från klientapplikationen specificera målmodellen som måste anropas. Den första behållaren i pipelinen hanterar den initiala begäran, utför viss bearbetning och skickar sedan det mellanliggande svaret som en begäran till den andra behållaren i pipelinen, som är värd för flera modeller. Baserat på målmodellen specificerad i slutledningsbegäran, anropas modellen för att generera en slutledning. Den genererade slutledningen skickas till nästa behållare i pipeline för vidare bearbetning. Detta händer för varje efterföljande behållare i pipeline, och slutligen returnerar SageMaker det slutliga svaret till den anropande klientapplikationen.

Flera modellartefakter finns kvar i en S3-hink. När en specifik modell anropas laddar SageMaker den dynamiskt till behållaren som är värd för slutpunkten. Om modellen redan är laddad i containerns minne går anropet snabbare eftersom SageMaker inte behöver ladda ner modellen från Amazon S3. Om instansminnesanvändningen är hög och en ny modell anropas och därför måste laddas, laddas oanvända modeller bort från minnet. De urladdade modellerna finns dock kvar i instansens lagringsvolym och kan laddas in i containerns minne senare igen, utan att laddas ner från S3-hinken igen.

En av de viktigaste övervägandena när du använder MME:er är att förstå beteendet för modellanropslatens. Som diskuterats tidigare laddas modeller dynamiskt in i behållarens minne för den instans som är värd för slutpunkten när de anropas. Därför kan modellanropet ta längre tid när det anropas för första gången. När modellen redan finns i instansbehållarens minne är de efterföljande anropen snabbare. Om en instansminnesanvändning är hög och en ny modell måste laddas, laddas oanvända modeller ur. Om instansens lagringsvolym är full raderas oanvända modeller från lagringsvolymen. SageMaker sköter lastningen och lossningen av modellerna fullt ut, utan att du behöver vidta några specifika åtgärder. Det är dock viktigt att förstå detta beteende eftersom det har konsekvenser för modellens anropsfördröjning och därför övergripande fördröjning från slut till ände.

Alternativ för pipeline-värd

SageMaker tillhandahåller flera instans typ alternativ att välja mellan för att distribuera ML-modeller och bygga ut slutledningsledningar, baserat på ditt användningsfall, genomströmning och kostnadskrav. Till exempel kan du välja CPU- eller GPU-optimerade instanser för att bygga seriella slutledningspipelines, på en enda behållare eller över flera behållare. Det finns dock ibland krav där det är önskvärt att ha flexibilitet och stöd för att köra modeller på CPU- eller GPU-baserade instanser inom samma pipeline för ytterligare flexibilitet.

Du kan nu använda NVIDIA Triton Inference Server för att tjäna modeller för slutledning på SageMaker för heterogena beräkningskrav. Kolla upp Implementera snabb och skalbar AI med NVIDIA Triton Inference Server i Amazon SageMaker för ytterligare information.

Slutsats

När organisationer upptäcker och bygger nya lösningar som drivs av ML, bör verktygen som krävs för att orkestrera dessa pipelines vara tillräckligt flexibla för att stödja baserat på ett givet användningsfall, samtidigt som de förenklar och minskar de pågående driftskostnaderna. SageMaker erbjuder flera alternativ för att designa och bygga dessa seriella slutledningsarbetsflöden, baserat på dina krav.

Vi ser fram emot att höra från dig om vilka användningsfall du bygger med seriella inferenspipelines. Om du har frågor eller feedback, vänligen dela dem i kommentarerna.

Om författarna

Rahul Sharma är Senior Solutions Architect på AWS Data Lab och hjälper AWS-kunder att designa och bygga AI/ML-lösningar. Innan han började på AWS har Rahul tillbringat flera år inom finans- och försäkringssektorn och hjälpt kunder att bygga data- och analytiska plattformar.

Anand Prakash är Senior Solutions Architect på AWS Data Lab. Anand fokuserar på att hjälpa kunder att designa och bygga AI/ML, dataanalys och databaslösningar för att påskynda deras väg till produktion.

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 Computer Vision-domäner. Han hjälper kunder att uppnå högpresterande modellslutningar på SageMaker.

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.