Kosteneffiziente ML-Inferenz mit Multi-Framework-Modellen auf Amazon SageMaker 

Maschinelles Lernen (ML) hat sich als eine der erfolgreichsten und am weitesten verbreiteten Anwendungen von Technologie erwiesen, die eine Vielzahl von Branchen betrifft und täglich Milliarden von Benutzern betrifft. Mit dieser schnellen Einführung von ML in jeder Branche stehen Unternehmen vor der Herausforderung, Vorhersagen mit geringer Latenz und hoher Verfügbarkeit zu unterstützen und gleichzeitig die Ressourcennutzung zu maximieren und die damit verbundenen Kosten zu senken. Da jedes ML-Framework seine eigenen Abhängigkeiten hat und die Bereitstellungsschritte für jedes Framework unterschiedlich sind, wird das Bereitstellen von Modellen, die in verschiedenen Frameworks in der Produktion erstellt wurden, und das Verwalten der einzelnen Endpunkte immer komplexer.

Amazon Sage Maker Multi-Container-Endpunkte (MCEs) ermöglichen es uns, Modelle auf verschiedenen Frameworks zu gruppieren und sie auf demselben Host bereitzustellen, wodurch ein einziger Endpunkt entsteht. Sie können Container für die verschiedenen Frameworks bereitstellen, die Sie zum Erstellen der Modelle verwenden, und SageMaker nimmt alle diese Container und stellt sie hinter einen Endpunkt. Sie könnten beispielsweise ein PyTorch- und ein TensorFlow-Modell auf zwei dedizierten Endpunkten laden, die dieselben oder völlig unterschiedliche Anwendungsfälle bedienen, und beide Modelle haben zeitweise eingehenden Datenverkehr, der die Ressourcen nicht bis an seine Grenzen nutzt. In einem solchen Szenario könnten Sie sie mithilfe von Containern mit einem MCE zu einem Endpunkt zusammenführen, wodurch die Ressourcennutzung verbessert und gleichzeitig die Kosten gesenkt werden, die dadurch entstehen, dass beide Modelle von unterschiedlichen Endpunkten bereitgestellt werden.

Multi-Container-Endpunkte bieten eine skalierbare und kostengünstige Lösung zum Bereitstellen von bis zu 15 Modellen, die auf verschiedenen ML-Frameworks, Modellservern und Algorithmen basieren, die denselben oder einen anderen Anwendungsfall bedienen, was bedeutet, dass Sie Modelle haben können, die auf verschiedenen ML-Frameworks oder Vermittlern basieren Schritte über all diese Container und Modelle. Auf alle diese Modelle kann einzeln per direktem Aufruf zugegriffen oder per seriellem Aufruf in eine Pipeline eingebunden werden, wobei die Ausgabe eines Modells die Eingabe für das nächste ist.

In diesem Beitrag diskutieren wir, wie Sie eine kosteneffiziente ML-Inferenz mit Multi-Framework-Modellen auf SageMaker durchführen können.

MCE-Aufrufmuster

Der direkte Aufruf von SageMaker MCE ist in Fällen nützlich, in denen Sie nicht verwandte Modelle in einen MCE-Endpunkt eingebunden haben oder einen A/B-Test zwischen den Modellen hinter einem MCE-Endpunkt ausführen, um deren Leistung zu messen. Sie können den spezifischen Container direkt im API-Aufruf aufrufen und die Vorhersage von diesem Modell abrufen.

Mit seriellem Aufruf können Sie 2–15 Container zusammenfügen, und die Ausgabe eines Containers wird zur Eingabe des nächsten Containers in Folge. Dies ist ein idealer Anwendungsfall, wenn Sie beispielsweise eine mehrstufige Vorhersagepipeline haben, bei der ein Scikit-Learn-Modell für eine Zwischenvorhersage verwendet wird und das Ergebnis zur endgültigen Inferenz in ein TensorFlow-Modell eingespeist wird. Anstatt sie als verschiedene Endpunkte bereitzustellen und von einer anderen Anwendung oder einem anderen Job zu orchestrieren und mehrere API-Aufrufe durchzuführen, können Sie sie als SageMaker-MCE bereitstellen, die Logik abstrahieren und sie für den seriellen Aufruf einrichten, wobei SageMaker die Datenübertragung zwischen einem Container verwaltet automatisch an einen anderen und sendet die Ausgabe des endgültigen Containers an den Client, der die API-Anfrage stellt.

Der serielle Aufruf von SageMaker MCE unterscheidet sich grundlegend von einer seriellen Inferenzpipeline von SageMaker (weitere Einzelheiten in den folgenden Abschnitten). Eine serielle Inferenzpipeline ist eher darauf ausgerichtet, komplexe ML-Workflows wie Datenvorverarbeitung, Aufbau eines Modellensembles, Implementierung bedingter Prüfungen zur Bestimmung des aufzurufenden Modells oder Nachbearbeitung der Vorhersage unter Einbeziehung der Geschäftslogik zu orchestrieren, bevor die Vorhersage an die nachgelagerten Anwendungen gesendet wird . Im Gegensatz dazu ist der serielle MCE-Aufruf so konzipiert, dass er 2–14 Modelle in eine Pipeline für Schlussfolgerungen einfügt, wobei jedes Modell die Vorhersage des vorherigen Modells als Eingabe verwendet.

Alle Container in einem MCE sind immer in Betrieb und im Arbeitsspeicher, sodass beim Aufrufen des Endpunkts kein Kaltstart erfolgt. MCEs verbessern auch die Endpunktauslastung und senken die Kosten, da Modelle hinter einem Endpunkt bereitgestellt werden und die zugrunde liegende Recheninstanz gemeinsam nutzen, anstatt dass jedes Modell einzelne Rechenressourcen belegt.

Sehen wir uns einige Anwendungsfälle an und sehen wir uns an, wie Sie SageMaker MCEs verwenden können, um ML-Inferenz zu optimieren.

Anwendungsfälle für SageMaker-MCEs

Angenommen, Sie haben zwei Modelle für die Stimmungsklassifizierung, eines für die englische Sprache und das andere für die deutsche Sprache, und diese Modelle bedienen unterschiedliche Regionen mit Traffic, der zu unterschiedlichen Tageszeiten eingeht. Anstatt zwei Endpunkte rund um die Uhr laufen zu lassen, können Sie beide mit einem MCE an einem Endpunkt bereitstellen und über einen direkten Aufruf darauf zugreifen, wodurch Ihre Ressourcennutzung und Kosten optimiert werden. Siehe folgenden 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 diesem Beispiel haben wir zwei Modelle (englishModel machen germanModel) und wir definieren die Container im SageMaker create_model konstruieren und definieren InferenceExecutionConfig als „Direkt“. Jetzt können wir den Endpunkt für die Inferenz aufrufen und die definieren TargetContainerHostname entweder englishModel or germanModel abhängig vom Client, der den API-Aufruf durchführt:

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

Sie können auch den direkten Aufruf innerhalb des MCE verwenden, um A/B-Tests auszuführen, um die Leistung zwischen den Modellen zu vergleichen.

Das folgende Diagramm zeigt unsere Architektur.

In ähnlicher Weise empfängt das Modell in anderen ML-Anwendungsfällen, wenn das trainierte Modell zur Verarbeitung einer Anfrage verwendet wird, Daten in einem Format, das vorverarbeitet (z. B. mit Features versehen) werden muss, bevor es zur Inferenz an den Algorithmus übergeben werden kann. Wenn ML-Algorithmen miteinander verkettet werden, dient die Ausgabe eines Modells als Eingabe für das nächste, bevor das Endergebnis erreicht wird. In diesem Fall können Sie eine serielle SageMaker MCE-Pipeline erstellen, in der die Container in der in der definierten Reihenfolge miteinander kommunizieren create_model zu konstruieren, anstatt jedes der Modelle in verschiedenen Endpunkten bereitzustellen und eine unabhängige Logik zu schreiben, um den Datenfluss zwischen all diesen Modellen und API-Aufrufen zu erleichtern. Das folgende Diagramm veranschaulicht diese Architektur.

Für diesen Anwendungsfall verwenden wir den folgenden 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 diesem Beispiel haben wir zwei Verarbeitungscontainer (Processing-1 machen Processing-2) für Feature-Verarbeitung und Datentransformationen sowie zwei Inferenzcontainer (Inference-1 machen Inference-2), um ML-Modellvorhersagen für die vorverarbeiteten Daten auszuführen. Das PipelineModel -Instanz können Sie die Inferenzpipeline definieren, die aus einer linearen Folge von vier Containern besteht, die Anfragen für Inferenz auf Daten verarbeiten. Die Container befinden sich auf derselben Instanz, sodass Sie Inferenzen mit geringer Latenz ausführen können.

Skalieren Sie Endpunkte mit mehreren Modellen für eine große Anzahl von Modellen

Die Vorteile von SageMaker-Multimodell-Endpunkten steigen je nach Umfang der Modellkonsolidierung. Sie können Kosteneinsparungen feststellen, wenn Sie zwei Modelle mit einem Endpunkt hosten, und bei Anwendungsfällen mit Hunderten oder Tausenden von Modellen sind die Einsparungen viel größer.

Auch das Skalieren der MCE-Endpunkte ist mit dem einfach SageMakerVariantInvocationsPerInstance vordefinierte Metrik, die angibt, wie oft pro Minute durchschnittlich jede Instanz für einen Modellendpunkt aufgerufen wird, um a zu definieren TargetScaling Politik. SageMaker passt die Anzahl der für ein Modell bereitgestellten Instanzen als Reaktion auf Änderungen Ihrer Arbeitslast dynamisch an. Wenn die Arbeitslast zunimmt, bringt die automatische Skalierung mehr Instanzen online und lädt mit den Zielmodellen und Containern, um die Anforderungen weiterhin zu erfüllen. Wenn die Arbeitslast abnimmt, entfernt die automatische Skalierung unnötige Instanzen und lagert die Modellcontainer aus, sodass die Container die Ressourcen nicht verbrauchen und Sie nicht für Instanzen bezahlen, die Sie nicht verwenden. Die Zeit zum Abschließen der ersten Anforderung für ein bestimmtes Modell erfährt eine zusätzliche Latenz (als Kaltstart bezeichnet) zum Herunterladen des Modells Amazon Simple Storage-Service (Amazon S3) und in den Arbeitsspeicher laden. Nachfolgende Aufrufe werden ohne zusätzlichen Aufwand beendet, da das Modell bereits geladen ist. Siehe folgenden 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
    }
)

Nach der vorangehenden Beispielrichtlinienkonfiguration verwenden wir die SageMakerVariantInvocationsPerInstance vordefinierte Metrik, um die Anzahl der Varianteninstanzen so anzupassen, dass jede Instanz eine hat InvocationsPerInstance Metrik von 70.

Wir können SageMaker MCEs auch basierend auf unseren eigenen benutzerdefinierten Metriken skalieren, wie z CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization, oder DiskUtilization, um die Anzahl der Instanzen basierend auf der Nutzung einer bestimmten Ressource hoch- oder herunterzuskalieren. Weitere Informationen finden Sie unter Amazon SageMaker-Modelle automatisch skalieren.

Es wird empfohlen, dass das Modell in jedem Container bei jeder Inferenzanforderung ähnliche Rechen- und Latenzanforderungen aufweist, denn wenn sich der Datenverkehr zum MCE von einem Modell mit hoher CPU-Auslastung zu einem Modell mit niedriger CPU-Auslastung verschiebt, das Gesamtaufrufvolumen jedoch gleich bleibt, der Endpunkt wird nicht hochskaliert und es sind möglicherweise nicht genügend Instanzen vorhanden, um alle Anforderungen an das Modell mit hoher CPU-Auslastung zu verarbeiten.

Sichere MCEs

Bei MCEs mit direktem Aufruf werden mehrere Container in einer einzigen Instanz gehostet, indem Arbeitsspeicher und ein Speichervolume gemeinsam genutzt werden. Es ist wichtig, die Container zu sichern, die korrekte Zuordnung von Anforderungen zu Zielcontainern beizubehalten und Benutzern den richtigen Zugriff auf Zielcontainer zu gewähren. Sie können einschränken invoke_endpoint Zugriff auf eine begrenzte Anzahl von Containern in einem MCE mithilfe von sagemaker:TargetContainerHostname AWS Identity and Access Management and (IAM) Bedingungsschlüssel. SageMaker verwendet IAM-Rollen um identitätsbasierte IAM-Richtlinien bereitzustellen, mit denen Sie zulässige oder verweigerte Aktionen und Ressourcen sowie die Bedingungen angeben, unter denen Aktionen zulässig oder verweigert werden. Die folgenden Richtlinien zeigen, wie Aufrufe auf bestimmte Container innerhalb eines Endpunkts beschränkt werden:

{
    "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*"]
                }
            }
        }
    ]
}

Überwachen Sie Endpunkte mit mehreren Modellen mithilfe von Amazon CloudWatch-Metriken

Um Kompromisse bei Preis und Leistung einzugehen, sollten Sie Endpunkte mit mehreren Modellen mit Modellen und repräsentativem Datenverkehr aus Ihrer eigenen Anwendung testen. SageMaker bietet zusätzliche Metriken in Amazon CloudWatch für Endpunkte mit mehreren Modellen, damit Sie die Endpunktnutzung und die Cache-Trefferrate bestimmen und Ihren Endpunkt optimieren können. Die Metriken sind wie folgt:

• ModelLoadingWaitTime – Das Zeitintervall, das eine Aufrufanforderung darauf wartet, dass das Zielmodell heruntergeladen oder geladen wird, um die Inferenz durchzuführen.
• ModelUnloadingTime – Das Zeitintervall, das zum Entladen des Modells durch den Container benötigt wird UnloadModel API-Aufruf.
• ModelDownloadingTime – Das Zeitintervall, das zum Herunterladen des Modells von Amazon S3 benötigt wird.
• ModelLoadingTime – Das Zeitintervall, das benötigt wird, um das Modell durch die Container zu laden LoadModel API-Aufruf.
• ModelCacheHit - Die Anzahl der InvokeEndpoint Anforderungen, die an den Endpunkt gesendet werden, auf dem das Modell bereits geladen wurde. Unter der Average Statistik zeigt den Anteil der Anfragen, bei denen das Modell bereits geladen war.
• LoadedModelCount – Die Anzahl der in die Container im Endpunkt geladenen Modelle. Diese Metrik wird pro Instanz ausgegeben. Das Average Statistik mit einem Zeitraum von 1 Minute zeigt Ihnen die durchschnittliche Anzahl der geladenen Modelle pro Instanz und die Sum Die Statistik zeigt Ihnen die Gesamtzahl der Modelle, die über alle Instanzen im Endpunkt geladen wurden. Die Modelle, die diese Metrik verfolgt, sind nicht unbedingt eindeutig, da Sie ein Modell in mehrere Container im Endpunkt laden können.

Es gibt auch mehrere andere Metriken, die von jedem Container verwendet werden, der auf einer Instanz ausgeführt wird, z Invocations Angabe der Anzahl von InvokeEndpoint Anfragen, die an einen Container innerhalb eines Endpunkts gesendet werden, ContainerLatency Angeben der Zeit, die ein Endpunkt benötigte, damit der Zielcontainer oder alle Container in einem seriellen Aufruf aus der Sicht von SageMaker antwortet, und CPUUtilization machen MemoryUtilizaton Zeigt die CPU-Einheiten und den Prozentsatz des Speichers an.

Zusammenfassung

In dem Beitrag haben wir diskutiert, wie SageMaker Multi-Container-Endpunkte bei der Optimierung von Kosten und Ressourcennutzung hilfreich sein können. Beispiele für den Einsatz von MCEs sind unter anderem:

• Hosten von Modellen über verschiedene Frameworks (z. B. TensorFlow, PyTorch und Scikit-learn), die nicht über ausreichend Datenverkehr verfügen, um die volle Kapazität einer Instanz auszuschöpfen
• Hosten von Modellen aus demselben Framework mit unterschiedlichen ML-Algorithmen (z. B. Empfehlungen, Prognosen oder Klassifizierung) und Handler-Funktionen
• Vergleiche ähnlicher Architekturen, die auf verschiedenen Framework-Versionen ausgeführt werden (z. B. TensorFlow 1.x vs. TensorFlow 2.x) für Szenarien wie A/B-Tests

SageMaker MCEs unterstützen die Bereitstellung von bis zu 15 Containern auf Echtzeit-Endpunkten und deren unabhängiges Aufrufen für Inferenz mit geringer Latenz und Kosteneinsparungen. Die Modelle können völlig heterogen sein, mit ihrem eigenen unabhängigen Servierstapel. Sie können diese Container entweder nacheinander oder unabhängig für jede Anforderung aufrufen. Durch das sichere Hosten mehrerer Modelle aus verschiedenen Frameworks auf einer einzigen Instanz können Sie im Vergleich zum Hosten von Modellen in dedizierten Einzelinstanz-Endpunkten bis zu 90 % der Kosten einsparen.

Über die Autoren

Dhawal Patel ist Principal Machine Learning Architect bei AWS. Er hat mit Organisationen von großen Unternehmen bis hin zu mittelständischen Startups an Problemen im Zusammenhang mit verteiltem Computing und künstlicher Intelligenz gearbeitet. Er konzentriert sich auf Deep Learning, einschließlich NLP und Computer Vision-Domänen. Er hilft Kunden dabei, eine leistungsstarke Modellinferenz auf Amazon SageMaker zu erreichen.

Vikram Elango ist Senior AI/ML Specialist Solutions Architect bei Amazon Web Services mit Sitz in Virginia, USA. Vikram unterstützt globale Kunden aus der Finanz- und Versicherungsbranche mit Design und Vordenkerrolle bei der Erstellung und Bereitstellung von Anwendungen für maschinelles Lernen in großem Maßstab. Derzeit konzentriert er sich auf die Verarbeitung natürlicher Sprache, verantwortungsbewusste KI, Inferenzoptimierung und die Skalierung von ML im gesamten Unternehmen. In seiner Freizeit reist er gerne, wandert, kocht und campt mit seiner Familie.

Saurabh Trikande ist Senior Product Manager für Amazon SageMaker Inference. Er arbeitet leidenschaftlich gerne mit Kunden zusammen und ist motiviert von dem Ziel, maschinelles Lernen zu demokratisieren. Er konzentriert sich auf die Kernherausforderungen im Zusammenhang mit der Bereitstellung komplexer ML-Anwendungen, mandantenfähigen ML-Modellen, Kostenoptimierungen und der leichteren Bereitstellung von Deep-Learning-Modellen. In seiner Freizeit wandert Saurabh gerne, lernt etwas über innovative Technologien, folgt TechCrunch und verbringt Zeit mit seiner Familie.