Ontwerppatronen voor seriële gevolgtrekking op Amazon SageMaker

Naarmate machine learning (ML) mainstream wordt en een bredere acceptatie krijgt, worden ML-aangedreven applicaties steeds gebruikelijker om een ​​reeks complexe zakelijke problemen op te lossen. De oplossing voor deze complexe zakelijke problemen vereist vaak het gebruik van meerdere ML-modellen. Deze modellen kunnen achtereenvolgens worden gecombineerd om verschillende taken uit te voeren, zoals voorverwerking, gegevenstransformatie, modelselectie, het genereren van gevolgtrekkingen, consolidatie van gevolgtrekkingen en nabewerking. Organisaties hebben flexibele opties nodig om deze complexe ML-workflows te orkestreren. Seriële inferentiepijplijnen zijn zo'n ontwerppatroon om deze workflows in een reeks stappen in te delen, waarbij elke stap de uitvoer die door de vorige stappen is gegenereerd, verrijkt of verder verwerkt en de uitvoer doorgeeft aan de volgende stap in de pijplijn.

Bovendien moeten deze seriële inferentiepijplijnen het volgende bieden:

• Flexibele en aangepaste implementatie (afhankelijkheden, algoritmen, bedrijfslogica, enzovoort)
• Herhaalbaar en consistent voor productie-implementatie
• Ongedifferentieerd zwaar tillen door het minimaliseren van infrastructuurbeheer

In dit bericht bekijken we enkele veelvoorkomende use-cases voor seriële inferentiepijplijnen en doorlopen we enkele implementatieopties voor elk van deze use-cases met behulp van Amazon Sage Maker. We bespreken ook de overwegingen voor elk van deze implementatieopties.

De volgende tabel geeft een overzicht van de verschillende gebruiksscenario's voor seriële gevolgtrekking, overwegingen bij de implementatie en opties. Deze worden in dit bericht besproken.

In de volgende paragrafen bespreken we elke use-case in meer detail.

Seriële inferentiepijplijn met behulp van inferentiecontainers

Gebruiksscenario's voor seriële inferentiepijplijnen hebben vereisten om binnenkomende gegevens vooraf te verwerken voordat een vooraf getraind ML-model wordt aangeroepen voor het genereren van gevolgtrekkingen. Bovendien moeten in sommige gevallen de gegenereerde gevolgtrekkingen mogelijk verder worden verwerkt, zodat ze gemakkelijk kunnen worden gebruikt door downstream-toepassingen. Dit is een veelvoorkomend scenario voor gebruikssituaties waarbij een streaminggegevensbron in realtime moet worden verwerkt voordat er een model op kan worden gemonteerd. Deze use-case kan zich echter ook manifesteren voor batch-inferentie.

SageMaker biedt een optie om inferentiecontainers aan te passen en deze te gebruiken om een ​​seriële inferentiepijplijn te bouwen. Inferentiecontainers gebruiken de SageMaker Inferentie Toolkit en zijn gebouwd op SageMaker Multi-modelserver (MMS), dat een flexibel mechanisme biedt om ML-modellen te bedienen. Het volgende diagram illustreert een referentiepatroon voor het implementeren van een seriële inferentiepijplijn met behulp van inferentiecontainers.

SageMaker MMS verwacht een Python-script dat de volgende functies implementeert om het model te laden, invoergegevens voor te verwerken, voorspellingen van het model te krijgen en de uitvoergegevens na te verwerken:

• input_fn () – Verantwoordelijk voor het deserialiseren en voorbewerken van de invoergegevens
• model_fn () – Verantwoordelijk voor het laden van het getrainde model van artefacten in Amazon eenvoudige opslagservice (Amazone S3)
• predict_fn () – Verantwoordelijk voor het genereren van gevolgtrekkingen uit het model
• output_fn () – Verantwoordelijk voor het serialiseren en nabewerken van de output data (inferenties)

Raadpleeg voor gedetailleerde stappen om een ​​inferentiecontainer aan te passen: Uw eigen inferentiecontainer aanpassen.

Inferentiecontainers zijn een ideaal ontwerppatroon voor gebruiksscenario's voor seriële inferentiepijpleidingen met de volgende primaire overwegingen:

• Hoge cohesie – De verwerkingslogica en het bijbehorende model sturen enkele bedrijfsfunctionaliteit aan en moeten op dezelfde locatie worden geplaatst
• Lage algemene latentie – De verstreken tijd tussen het moment waarop een gevolgtrekkingsverzoek wordt gedaan en het antwoord wordt ontvangen

In een seriële inferentiepijplijn zijn de verwerkingslogica en het model ingekapseld in dezelfde enkele container, zodat veel van de aanroepaanroepen binnen de container blijven. Dit helpt het totale aantal hops te verminderen, wat resulteert in een betere algehele latentie en responsiviteit van de pijplijn.

Ook voor gebruikssituaties waarbij implementatiegemak een belangrijk criterium is, kunnen inferentiecontainers helpen, waarbij verschillende verwerkingsstappen van de pijplijn samen in dezelfde container worden geplaatst.

Seriële inferentiepijplijn met behulp van een SageMaker-inferentiepijplijn

Een andere variant van de use case van de seriële inferentiepijplijn vereist een duidelijkere ontkoppeling tussen de verschillende stappen in de pijplijn (zoals gegevensvoorverwerking, het genereren van inferenties, gegevensnaverwerking en opmaak en serialisatie). Dit kan verschillende redenen hebben:

• Ontkoppeling – Verschillende stappen van de pijplijn hebben een duidelijk gedefinieerd doel en moeten vanwege de onderliggende afhankelijkheden op afzonderlijke containers worden uitgevoerd. Dit helpt ook om de pijplijn goed gestructureerd te houden.
• Frameworks – Verschillende stappen van de pijplijn gebruiken specifieke geschikte kaders (zoals scikit of Spark ML) en moeten daarom op afzonderlijke containers worden uitgevoerd.
• Isolatie van hulpbronnen – Verschillende stappen van de pijplijn hebben verschillende vereisten voor het verbruik van hulpbronnen en moeten daarom op afzonderlijke containers worden uitgevoerd voor meer flexibiliteit en controle.

Bovendien kunnen voor iets complexere seriële inferentiepijplijnen meerdere stappen nodig zijn om een ​​verzoek te verwerken en een gevolgtrekking te genereren. Daarom kan het vanuit operationeel oogpunt voordelig zijn om deze stappen op afzonderlijke containers te hosten voor een betere functionele isolatie en eenvoudigere upgrades en verbeteringen mogelijk te maken (een stap wijzigen zonder andere modellen of verwerkingsstappen te beïnvloeden).

Als uw use-case overeenkomt met een aantal van deze overwegingen, a SageMaker-inferentiepijplijn biedt een gemakkelijke en flexibele optie om een ​​seriële inferentiepijplijn te bouwen. Het volgende diagram illustreert een referentiepatroon voor het implementeren van een seriële inferentiepijplijn met behulp van meerdere stappen die worden gehost op speciale containers met behulp van een SageMaker-inferentiepijplijn.

Een SageMaker-inferentiepijplijn bestaat uit een lineaire reeks van 2-15 containers die verzoeken om gevolgtrekkingen op gegevens verwerken. De inferentiepijplijn biedt de mogelijkheid om vooraf getrainde ingebouwde algoritmen van SageMaker of aangepaste algoritmen te gebruiken die zijn verpakt in Docker-containers. De containers worden gehost op dezelfde onderliggende instantie, waardoor de algehele latentie wordt verminderd en de kosten worden geminimaliseerd.

Het volgende codefragment laat zien hoe meerdere verwerkingsstappen en modellen kunnen worden gecombineerd om een ​​seriële inferentiepijplijn te maken.

We beginnen met het bouwen en specificeren van op Spark ML en XGBoost gebaseerde modellen die we willen gebruiken als onderdeel van de pijplijn:

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)

De modellen worden vervolgens sequentieel gerangschikt binnen de pijplijnmodeldefinitie:

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])

De inferentiepijplijn wordt vervolgens achter een eindpunt geïmplementeerd voor realtime gevolgtrekking door het type en aantal host-ML-instanties op te geven:

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

De gehele geassembleerde inferentiepijplijn kan worden beschouwd als een SageMaker-model dat u kunt gebruiken om realtime voorspellingen te doen of batchtransformaties direct te verwerken, zonder externe voorbewerking. Binnen een inferentiepijplijnmodel verwerkt SageMaker aanroepen als een reeks HTTP-verzoeken die afkomstig zijn van een externe toepassing. De eerste container in de pijplijn verwerkt het eerste verzoek, voert enige verwerking uit en verzendt vervolgens het tussenantwoord als een verzoek naar de tweede container in de pijplijn. Dit gebeurt voor elke container in de pijplijn en retourneert uiteindelijk het definitieve antwoord op de aanroepende clienttoepassing.

SageMaker-inferentiepijplijnen worden volledig beheerd. Wanneer de pijplijn is geïmplementeerd, installeert en draait SageMaker alle gedefinieerde containers op elk van de Amazon Elastic Compute-cloud (Amazon EC2) instanties ingericht als onderdeel van de eindpunt- of batchtransformatietaak. Bovendien wordt de algehele latentie van de pijplijn verminderd, omdat de containers zich op dezelfde locatie bevinden en worden gehost op dezelfde EC2-instantie.

Serieel modelensemble met behulp van een SageMaker-inferentiepijplijn

Een ensemblemodel is een benadering in ML waarbij meerdere ML-modellen worden gecombineerd en gebruikt als onderdeel van het gevolgtrekkingsproces om definitieve gevolgtrekkingen te genereren. De motivaties voor ensemble-modellen kunnen onder meer zijn: het verbeteren van de nauwkeurigheid, het verminderen van de modelgevoeligheid voor specifieke invoerfuncties en het verminderen van vooringenomenheid voor één model. In dit bericht richten we ons op de gebruiksscenario's die verband houden met een serieel modelensemble, waarbij meerdere ML-modellen opeenvolgend worden gecombineerd als onderdeel van een seriële inferentiepijplijn.

Laten we een specifiek voorbeeld bekijken met betrekking tot een serieel modelensemble waarbij we de geüploade afbeeldingen van een gebruiker moeten groeperen op basis van bepaalde thema's of onderwerpen. Deze pijplijn zou kunnen bestaan ​​uit drie ML-modellen:

• model 1 – Accepteert een afbeelding als invoer en evalueert de beeldkwaliteit op basis van beeldresolutie, oriëntatie en meer. Dit model probeert vervolgens de beeldkwaliteit op te schalen en stuurt de bewerkte beelden die aan een bepaalde kwaliteitsdrempel voldoen door naar het volgende model (model 2).
• model 2 – Accepteert afbeeldingen die zijn gevalideerd via Model 1 en presteert beeldherkenning om objecten, plaatsen, mensen, tekst en andere aangepaste acties en concepten in afbeeldingen te identificeren. De uitvoer van Model 2 die geïdentificeerde objecten bevat, wordt naar Model 3 gestuurd.
• model 3 – Accepteert de uitvoer van Model 2 en voert natuurlijke taalverwerkingstaken (NLP) uit, zoals onderwerpmodellering voor het groeperen van afbeeldingen op basis van thema's. Afbeeldingen kunnen bijvoorbeeld worden gegroepeerd op basis van locatie of geïdentificeerde personen. De uitvoer (groeperingen) wordt teruggestuurd naar de clienttoepassing.

Het volgende diagram illustreert een referentiepatroon voor het implementeren van meerdere ML-modellen die worden gehost op een serieel modelensemble met behulp van een SageMaker-inferentiepijplijn.

Zoals eerder besproken, wordt de SageMaker-inferentiepijplijn beheerd, waardoor u zich kunt concentreren op de selectie en ontwikkeling van het ML-model, terwijl u het ongedifferentieerde zware werk vermindert dat gepaard gaat met het bouwen van de seriële ensemble-pijplijn.

Bovendien zijn enkele van de eerder besproken overwegingen rond ontkoppeling, algoritme- en raamwerkkeuze voor modelontwikkeling en -implementatie ook hier relevant. Omdat elk model bijvoorbeeld op een afzonderlijke container wordt gehost, hebt u flexibiliteit bij het selecteren van het ML-framework dat het beste past bij elk model en uw algemene gebruiksscenario. Bovendien kunt u vanuit een ontkoppelings- en operationeel standpunt veel gemakkelijker afzonderlijke stappen blijven upgraden of wijzigen, zonder andere modellen te beïnvloeden.

De SageMaker-inferentiepijplijn is ook geïntegreerd met de SageMaker-modelregister voor modelcatalogus, versiebeheer, metadatabeheer en beheerde implementatie in productieomgevingen om consistente operationele best practices te ondersteunen. De SageMaker-inferentiepijplijn is ook geïntegreerd met: Amazon Cloud Watch om het monitoren van de multi-containermodellen in inferentiepijplijnen mogelijk te maken. U kunt ook inzicht krijgen in realtime statistieken om aanroepen en latentie voor elke container in de pijplijn beter te begrijpen, wat helpt bij het oplossen van problemen en het optimaliseren van bronnen.

Seriële inferentiepijplijn (met gerichte modelaanroep van een groep) met behulp van een SageMaker-inferentiepijplijn

SageMaker-eindpunten voor meerdere modellen (MME's) bieden een kosteneffectieve oplossing om een ​​groot aantal ML-modellen achter één enkel eindpunt te implementeren. De motivaties voor het gebruik van eindpunten met meerdere modellen kunnen zijn: het aanroepen van een specifiek aangepast model op basis van verzoekkenmerken (zoals oorsprong, geografische locatie, gebruikerspersonalisatie, enzovoort) of het eenvoudig hosten van meerdere modellen achter hetzelfde eindpunt om kostenoptimalisatie te bereiken.

Wanneer u meerdere modellen implementeert op een enkel multi-model ingeschakeld eindpunt, delen alle modellen de rekenbronnen en de modelservercontainer. De SageMaker-inferentiepijplijn kan worden geïmplementeerd op een MME, waar een van de containers in de pijplijn dynamisch verzoeken kan bedienen op basis van het specifieke model dat wordt aangeroepen. Vanuit een pijplijnperspectief hebben de modellen identieke voorverwerkingsvereisten en verwachten ze dezelfde functieset, maar zijn ze getraind om af te stemmen op een specifiek gedrag. Het volgende diagram illustreert een referentiepatroon van hoe deze geïntegreerde pijplijn zou werken.

Bij MME's moet het inferentieverzoek dat afkomstig is van de clienttoepassing het doelmodel specificeren dat moet worden aangeroepen. De eerste container in de pijplijn verwerkt het eerste verzoek, voert enige verwerking uit en verzendt vervolgens het tussenantwoord als een verzoek naar de tweede container in de pijplijn, die meerdere modellen host. Op basis van het doelmodel dat is opgegeven in de inferentieaanvraag, wordt het model aangeroepen om een ​​gevolgtrekking te genereren. De gegenereerde inferentie wordt naar de volgende container in de pijplijn gestuurd voor verdere verwerking. Dit gebeurt voor elke volgende container in de pijplijn en tenslotte stuurt SageMaker het laatste antwoord terug naar de aanroepende clienttoepassing.

Meerdere modelartefacten worden bewaard in een S3-bucket. Wanneer een specifiek model wordt aangeroepen, laadt SageMaker het dynamisch in de container die het eindpunt host. Als het model al in het geheugen van de container is geladen, gaat het aanroepen sneller omdat SageMaker het model niet hoeft te downloaden van Amazon S3. Als het geheugengebruik van de instantie hoog is en een nieuw model wordt aangeroepen en daarom moet worden geladen, worden ongebruikte modellen uit het geheugen verwijderd. De niet-geladen modellen blijven echter in het opslagvolume van de instantie en kunnen later weer in het geheugen van de container worden geladen, zonder opnieuw uit de S3-bucket te worden gedownload.

Een van de belangrijkste overwegingen bij het gebruik van MME's is het begrijpen van het latentiegedrag van modelaanroepen. Zoals eerder besproken, worden modellen dynamisch geladen in het geheugen van de container van de instantie die het eindpunt host wanneer ze worden aangeroepen. Daarom kan het aanroepen van het model langer duren wanneer het voor de eerste keer wordt aangeroepen. Wanneer het model zich al in het geheugen van de instantiecontainer bevindt, zijn de daaropvolgende aanroepen sneller. Als het geheugengebruik van een instantie hoog is en een nieuw model moet worden geladen, worden ongebruikte modellen verwijderd. Als het opslagvolume van de instantie vol is, worden ongebruikte modellen van het opslagvolume verwijderd. SageMaker regelt het laden en lossen van de modellen volledig, zonder dat u specifieke handelingen hoeft te verrichten. Het is echter belangrijk om dit gedrag te begrijpen, omdat het gevolgen heeft voor de latentie van het aanroepen van het model en dus voor de algehele latentie van begin tot eind.

Opties voor pijplijnhosting

SageMaker biedt meerdere instantietype opties om uit te kiezen voor het implementeren van ML-modellen en het bouwen van inferentiepijplijnen, op basis van uw gebruiksscenario, doorvoer en kostenvereisten. U kunt bijvoorbeeld voor CPU of GPU geoptimaliseerde instanties kiezen om seriële inferentiepijplijnen te bouwen, op een enkele container of over meerdere containers. Er zijn echter soms vereisten waarbij flexibiliteit en ondersteuning gewenst is om modellen op CPU- of GPU-gebaseerde instanties binnen dezelfde pijplijn uit te voeren voor extra flexibiliteit.

U kunt nu NVIDIA Triton Inference Server gebruiken om modellen voor inferentie op SageMaker te gebruiken voor heterogene computervereisten. Uitchecken Implementeer snelle en schaalbare AI met NVIDIA Triton Inference Server in Amazon SageMaker voor meer informatie.

Conclusie

Naarmate organisaties nieuwe oplossingen ontdekken en bouwen die worden aangedreven door ML, moeten de tools die nodig zijn voor het orkestreren van deze pijplijnen flexibel genoeg zijn om te ondersteunen op basis van een bepaalde use case, terwijl de lopende operationele overheadkosten worden vereenvoudigd en verminderd. SageMaker biedt meerdere opties om deze workflows voor seriële inferentie te ontwerpen en te bouwen, op basis van uw vereisten.

We horen graag van u welke gebruiksscenario's u bouwt met behulp van seriële inferentiepijplijnen. Als je vragen of feedback hebt, deel ze dan in de comments.

Over de auteurs

Rahul Sharma is Senior Solutions Architect bij AWS Data Lab en helpt AWS-klanten bij het ontwerpen en bouwen van AI/ML-oplossingen. Voordat hij bij AWS kwam, heeft Rahul een aantal jaren in de financiële en verzekeringssector gewerkt en klanten geholpen bij het bouwen van data- en analytische platforms.

Anand Prakash is Senior Solutions Architect bij AWS Data Lab. Anand richt zich op het helpen van klanten bij het ontwerpen en bouwen van AI/ML, data-analyse en database-oplossingen om hun weg naar productie te versnellen.

Dhawal Patel is een Principal Machine Learning Architect bij AWS. Hij heeft gewerkt met organisaties variërend van grote ondernemingen tot middelgrote startups aan problemen met betrekking tot gedistribueerde computing en kunstmatige intelligentie. Hij richt zich op Deep learning inclusief NLP en Computer Vision domeinen. Hij helpt klanten bij het bereiken van high-performance modelinferentie op SageMaker.

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.