Kostenefficiënte ML-inferentie met multi-framework-modellen op Amazon SageMaker 

Machine learning (ML) is een van de meest succesvolle en wijdverbreide toepassingen van technologie gebleken, die een breed scala aan industrieën treft en elke dag miljarden gebruikers treft. Met deze snelle acceptatie van ML in elke branche, worden bedrijven geconfronteerd met uitdagingen bij het ondersteunen van voorspellingen met lage latentie en met hoge beschikbaarheid, terwijl het gebruik van hulpbronnen wordt gemaximaliseerd en de bijbehorende kosten worden verlaagd. Omdat elk ML-framework zijn eigen afhankelijkheden heeft en de implementatiestappen voor elk framework anders zijn, wordt het implementeren van modellen die in verschillende frameworks zijn gebouwd in productie en het beheren van elk van de eindpunten steeds complexer.

Amazon Sage Maker multi-container endpoints (MCE's) stellen ons in staat om modellen op verschillende frameworks te groeperen en ze op dezelfde host te implementeren, waardoor een enkel eindpunt ontstaat. U kunt containers leveren voor de verschillende frameworks die u gebruikt om de modellen te bouwen, en SageMaker neemt al deze containers en plaatst ze achter één eindpunt. U kunt bijvoorbeeld een PyTorch- en een TensorFlow-model laden op twee speciale eindpunten die dezelfde of geheel verschillende gebruiksscenario's bedienen, en beide modellen hebben intermitterend inkomend verkeer dat de bronnen niet tot het uiterste gebruikt. In een dergelijk scenario kunt u ze samenvoegen door containers te gebruiken in één eindpunt met behulp van een MCE, waardoor het gebruik van hulpbronnen wordt verbeterd en de kosten worden verlaagd die worden gemaakt om beide modellen vanaf verschillende eindpunten te laten bedienen.

Eindpunten met meerdere containers bieden een schaalbare en kosteneffectieve oplossing voor het implementeren van maximaal 15 modellen die zijn gebouwd op verschillende ML-frameworks, modelservers en algoritmen voor dezelfde of verschillende use-cases, wat betekent dat u modellen kunt laten bouwen op verschillende ML-frameworks of tussenliggende stappen over al deze containers en modellen. Al deze modellen zijn afzonderlijk toegankelijk via directe aanroep of worden samengevoegd tot een pijplijn met behulp van seriële aanroep, waarbij de uitvoer van het ene model de invoer is voor het volgende.

In dit bericht bespreken we hoe u kostenefficiënte ML-inferentie kunt uitvoeren met multi-framework-modellen op SageMaker.

MCE-aanroeppatronen

Directe aanroep van SageMaker MCE is handig in gevallen waarin u niet-gerelateerde modellen in een MCE-eindpunt hebt geclubd of u een A/B-test uitvoert tussen de modellen achter een MCE-eindpunt om hun prestaties te meten. U kunt de specifieke container rechtstreeks in de API-aanroep aanroepen en de voorspelling van dat model ophalen.

Met seriële aanroep kunt u 2-15 containers aan elkaar naaien, en de uitvoer van één wordt de invoer van de volgende container in volgorde. Dit is een ideale use-case als u bijvoorbeeld een voorspellingspijplijn met meerdere stappen hebt waarbij een Scikit-leermodel wordt gebruikt voor een tussentijdse voorspelling en het resultaat wordt ingevoerd in een TensorFlow-model voor definitieve inferentie. In plaats van ze te implementeren als verschillende eindpunten en een andere applicatie of taak die ze orkestreert en meerdere API-aanroepen doet, kunt u ze implementeren als een SageMaker MCE, de logica abstraheren en ze instellen voor seriële aanroep, waarbij SageMaker de gegevensoverdracht tussen één container beheert automatisch naar een andere en verzendt de uitvoer van de laatste container naar de client die het API-verzoek doet.

SageMaker MCE seriële aanroep is fundamenteel anders dan een SageMaker seriële inferentiepijplijn (meer details in de onderstaande secties). Een seriële inferentiepijplijn is meer gericht op het orkestreren van complexe ML-workflows zoals gegevensvoorverwerking, het bouwen van een modelensemble, het implementeren van voorwaardelijke controles om te bepalen welk model moet worden aangeroepen, of het nabewerken van de voorspelling, waarbij bedrijfslogica betrokken is voordat de voorspelling naar de downstream-applicaties wordt verzonden . MCE seriële aanroep daarentegen is ontworpen om 2-14 modellen in een pijplijn voor gevolgtrekking te naaien, waarbij elk model de voorspelling van het vorige model als invoer neemt.

Alle containers in een MCE zijn altijd in service en in het geheugen, dus er is geen koude start bij het aanroepen van het eindpunt. MCE's verbeteren ook het gebruik van eindpunten en verbeteren de kosten, omdat modellen achter één eindpunt worden geïmplementeerd en de onderliggende rekeninstantie delen, in plaats van dat elk model afzonderlijke rekenbronnen in beslag neemt.

Laten we een paar use-cases bekijken en zien hoe u SageMaker MCE's kunt gebruiken om ML-inferentie te optimaliseren.

Gebruiksscenario's voor SageMaker MCE's

Stel dat u twee modellen heeft voor sentimentclassificatie, een voor de Engelse taal en een andere voor de Duitse taal, en deze modellen bedienen verschillende regio's met verkeer dat op verschillende tijdstippen op een dag binnenkomt. In plaats van twee 24 uur per dag, 7 dagen per week twee eindpunten te hebben, kunt u ze beide in één eindpunt implementeren met behulp van een MCE en ze openen via directe aanroep, waardoor uw resourcegebruik en -kosten worden geoptimaliseerd. Zie de volgende code:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

In dit voorbeeld hebben we twee modellen (englishModel en germanModel), en we definiëren de containers in de SageMaker create_model construeren en definiëren van de InferenceExecutionConfig als 'Direct'. Nu kunnen we het eindpunt voor inferentie oproepen en de . definiëren TargetContainerHostname als ofwel englishModel or germanModel afhankelijk van de client die de API-aanroep doet:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

U kunt ook directe aanroep binnen de MCE gebruiken om A/B-tests uit te voeren om de prestaties tussen de modellen te vergelijken.

Het volgende diagram illustreert onze architectuur.

Evenzo, in andere ML-gebruiksgevallen, wanneer het getrainde model wordt gebruikt voor het verwerken van een verzoek, ontvangt het model gegevens in een indeling die moet worden voorbewerkt (bijvoorbeeld gefeaturiseerd) voordat het kan worden doorgegeven aan het algoritme voor gevolgtrekking. Wanneer ML-algoritmen aan elkaar worden gekoppeld, dient de uitvoer van het ene model als invoer voor het volgende voordat het uiteindelijke resultaat wordt bereikt. In dit geval kunt u een seriële SageMaker MCE-pijplijn bouwen, waarbij de containers met elkaar praten in de volgorde die is gedefinieerd in de create_model construeren in plaats van dat u elk van de modellen in verschillende eindpunten implementeert en een onafhankelijke logica schrijft om de gegevensstroom tussen al deze modellen en API-aanroepen te vergemakkelijken. Het volgende diagram illustreert deze architectuur.

Voor deze use case gebruiken we de volgende code:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

In dit voorbeeld hebben we twee verwerkingscontainers (Processing-1 en Processing-2) voor functieverwerking en gegevenstransformaties, en twee inferentiecontainers (Inference-1 en Inference-2) om ML-modelvoorspellingen uit te voeren op de voorverwerkte gegevens. De PipelineModel instantie kunt u de inferentiepijplijn definiëren die bestaat uit een lineaire reeks van vier containers die verzoeken om inferentie op gegevens verwerken. De containers bevinden zich op dezelfde instantie, zodat u inferentie kunt uitvoeren met een lage latentie.

Schaal multi-model eindpunten voor grote aantallen modellen

De voordelen van SageMaker multi-model endpoints nemen toe op basis van de schaal van modelconsolidatie. U kunt kostenbesparingen zien bij het hosten van twee modellen met één eindpunt, en voor use cases met honderden of duizenden modellen zijn de besparingen veel groter.

Het schalen van de MCE-eindpunten is ook eenvoudig met behulp van de SageMakerVariantInvocationsPerInstance vooraf gedefinieerde metriek, die het gemiddelde aantal keren per minuut geeft dat elke instantie voor een modeleindpunt wordt aangeroepen om een TargetScaling beleid. SageMaker past dynamisch het aantal instanties aan dat voor een model is ingericht als reactie op wijzigingen in uw werklast. Wanneer de werklast toeneemt, brengt automatisch schalen meer instanties online en worden de doelmodellen en containers geladen om de verzoeken te kunnen blijven verwerken. Wanneer de werklast afneemt, verwijdert automatisch schalen onnodige instanties en worden de modelcontainers ontlast, zodat de containers de resources niet opslokken en u niet betaalt voor instanties die u niet gebruikt. De tijd om het eerste verzoek voor een bepaald model te voltooien, ervaart extra latentie (een koude start genoemd) om het model te downloaden van Amazon eenvoudige opslagservice (Amazon S3) en laad het in het geheugen. Daaropvolgende oproepen eindigen zonder extra overhead omdat het model al is geladen. Zie de volgende code:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

In navolging van de voorgaande voorbeeldbeleidsconfiguratie gebruiken we de SageMakerVariantInvocationsPerInstance vooraf gedefinieerde statistiek om het aantal variantinstanties aan te passen, zodat elke instantie een InvocationsPerInstance metriek van 70.

We kunnen SageMaker MCE's ook schalen op basis van onze eigen aangepaste metriek, zoals: CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationof DiskUtilization, om het aantal instanties omhoog of omlaag te schalen op basis van het gebruik van een specifieke resource. Voor meer informatie, zie: Schaal Amazon SageMaker-modellen automatisch.

Het wordt aanbevolen dat het model in elke container vergelijkbare reken- en latentievereisten heeft voor elk inferentieverzoek, omdat als het verkeer naar de MCE verschuift van een model met een hoog CPU-gebruik naar een model met een laag CPU-gebruik, maar het totale oproepvolume hetzelfde blijft, het eindpunt schaalt niet uit en er zijn mogelijk niet genoeg instanties om alle aanvragen voor het hoge CPU-gebruiksmodel te verwerken.

Veilige MCE's

Voor MCE's met directe aanroep worden meerdere containers in één instantie gehost door geheugen en een opslagvolume te delen. Het is belangrijk om de containers te beveiligen, de juiste toewijzing van aanvragen aan doelcontainers te behouden en gebruikers de juiste toegang tot doelcontainers te bieden. U kunt beperken invoke_endpoint toegang tot een beperkte set containers in een MCE met behulp van de sagemaker:TargetContainerHostname AWS Identiteits- en toegangsbeheer (IAM) voorwaardesleutel. SageMaker gebruikt IAM-rollen om IAM-beleid op basis van identiteit te bieden dat u gebruikt om toegestane of geweigerde acties en bronnen te specificeren en de voorwaarden waaronder acties zijn toegestaan ​​of geweigerd. Het volgende beleid laat zien hoe u aanroepen kunt beperken tot specifieke containers binnen een eindpunt:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Monitor eindpunten met meerdere modellen met behulp van Amazon CloudWatch-statistieken

Om prijs- en prestatieafwegingen te maken, wilt u eindpunten met meerdere modellen testen met modellen en representatief verkeer van uw eigen applicatie. SageMaker biedt aanvullende statistieken in: Amazon Cloud Watch voor eindpunten met meerdere modellen, zodat u het eindpuntgebruik en de cachehitrate kunt bepalen en uw eindpunt kunt optimaliseren. De statistieken zijn als volgt:

• ModelBezig met ladenWachttijd – Het tijdsinterval dat een aanroepverzoek wacht totdat het doelmodel is gedownload of geladen om de inferentie uit te voeren.
• ModelOntlaadtijd – Het tijdsinterval dat nodig is om het model door de container te lossen UnloadModel API-oproep.
• ModelDownloadenTijd – Het tijdsinterval dat nodig is om het model van Amazon S3 te downloaden.
• ModelLaadtijd – Het tijdsinterval dat nodig is om het model door de container te laden LoadModel API-oproep.
• ModelCacheHit - Het aantal InvokeEndpoint verzoeken verzonden naar het eindpunt waar het model al was geladen. De nemen Average statistiek toont de verhouding van verzoeken waarin het model al is geladen.
• GeladenModelCount – Het aantal modellen dat in de containers in het eindpunt is geladen. Deze statistiek wordt per instantie verzonden. De Average statistiek met een periode van 1 minuut vertelt u het gemiddelde aantal modellen dat per instantie is geladen, en de Sum statistiek vertelt u het totale aantal modellen dat is geladen over alle instanties in het eindpunt. De modellen die met deze metrische gegevens worden bijgehouden, zijn niet per se uniek omdat u een model in meerdere containers in het eindpunt kunt laden.

Er zijn ook verschillende andere metrische gegevens die worden gebruikt door elke container die op een instantie wordt uitgevoerd, zoals: Invocations met vermelding van het aantal InvokeEndpoint verzoeken verzonden naar een container binnen een eindpunt, ContainerLatency het geven van de tijd die een eindpunt nodig had voor de doelcontainer of alle containers in een seriële aanroep om te reageren zoals gezien vanuit SageMaker, en CPUUtilization en MemoryUtilizaton met vermelding van de CPU-eenheden en het percentage geheugen.

Conclusie

In de post hebben we besproken hoe SageMaker-eindpunten met meerdere containers nuttig kunnen zijn bij het optimaliseren van de kosten en het gebruik van hulpbronnen. Voorbeelden van wanneer MCE's moeten worden gebruikt, zijn onder meer, maar zijn niet beperkt tot:

• Hostingmodellen in verschillende frameworks (zoals TensorFlow, PyTorch en Scikit-learn) die niet voldoende verkeer hebben om de volledige capaciteit van een instantie te verzadigen
• Modellen hosten uit hetzelfde framework met verschillende ML-algoritmen (zoals aanbevelingen, prognoses of classificatie) en handlerfuncties
• Vergelijkingen van vergelijkbare architecturen die draaien op verschillende framework-versies (zoals TensorFlow 1.x vs. TensorFlow 2.x) voor scenario's zoals A/B-testen

SageMaker MCE's ondersteunen de implementatie van maximaal 15 containers op realtime eindpunten en deze onafhankelijk aan te roepen voor inferentie met lage latentie en kostenbesparingen. De modellen kunnen volledig heterogeen zijn, met hun eigen onafhankelijke serveerstapel. U kunt deze containers opeenvolgend of onafhankelijk voor elke aanvraag aanroepen. Het veilig hosten van meerdere modellen, vanuit verschillende frameworks, op één instance kan u tot 90% kosten besparen in vergelijking met hostingmodellen in dedicated single-instance endpoints.

Over de auteurs

Dhawal Patel is Principal Machine Learning Architect bij AWS. Hij heeft met organisaties, variërend van grote ondernemingen tot middelgrote startups, gewerkt 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 om hoogwaardige modelinferentie te bereiken op Amazon SageMaker.

Vikram Elango is een Senior AI/ML Specialist Solutions Architect bij Amazon Web Services, gevestigd in Virginia, VS. Vikram helpt wereldwijde klanten in de financiële en verzekeringssector met design en thought leadership om machine learning-applicaties op grote schaal te bouwen en te implementeren. Hij is momenteel gefocust op natuurlijke taalverwerking, verantwoorde AI, inferentie-optimalisatie en het schalen van ML in de hele onderneming. In zijn vrije tijd houdt hij van reizen, wandelen, koken en kamperen met zijn gezin.

Saurabh Trikande is Senior Product Manager voor Amazon SageMaker Inference. Hij heeft een passie voor het werken met klanten en wordt gemotiveerd door het doel om machine learning te democratiseren. Hij richt zich op kernuitdagingen met betrekking tot het inzetten van complexe ML-applicaties, multi-tenant ML-modellen, kostenoptimalisaties en het toegankelijker maken van de inzet van deep learning-modellen. In zijn vrije tijd houdt Saurabh van wandelen, leren over innovatieve technologieën, TechCrunch volgen en tijd doorbrengen met zijn gezin.