Erste Schritte mit der Bereitstellung von Echtzeitmodellen auf Amazon SageMaker

Amazon Sage Maker ist ein vollständig verwalteter Dienst, der jedem Entwickler und Datenwissenschaftler die Möglichkeit bietet, Modelle für maschinelles Lernen (ML) schnell und in großem Umfang zu erstellen, zu trainieren und bereitzustellen. ML wird in Inferenz realisiert. SageMaker bietet vier Inferenzoptionen:

1. Echtzeit-Inferenz
2. Serverlose Inferenz
3. Asynchrone Inferenz
4. Batch-Transformation

Diese vier Optionen können grob in Online- und Batch-Inferenzoptionen eingeteilt werden. Bei der Online-Inferenz wird erwartet, dass Anforderungen bei ihrem Eintreffen verarbeitet werden, und die konsumierende Anwendung erwartet eine Antwort, nachdem jede Anforderung verarbeitet wurde. Dies kann entweder synchron (Echtzeit-Inferenz, serverlos) oder asynchron (asynchrone Inferenz) geschehen. In einem synchronen Muster wird die verbrauchende Anwendung blockiert und kann nicht fortfahren, bis sie eine Antwort erhält. Bei diesen Workloads handelt es sich in der Regel um Echtzeitanwendungen, wie z. B. die Erkennung von Online-Kreditkartenbetrug, bei denen Antworten in der Größenordnung von Millisekunden bis Sekunden erwartet werden und die Anfrage-Nutzdaten klein sind (einige MB). Beim asynchronen Muster wird die Anwendungserfahrung nicht blockiert (z. B. das Einreichen eines Versicherungsanspruchs über eine mobile App) und erfordert normalerweise größere Nutzlastgrößen und/oder längere Verarbeitungszeiten. Bei der Offline-Inferenz wird eine Aggregation (Batch) von Inferenzanforderungen zusammen verarbeitet, und Antworten werden erst bereitgestellt, nachdem der gesamte Batch verarbeitet wurde. Normalerweise sind diese Workloads nicht latenzempfindlich, beinhalten große Datenmengen (mehrere GB) und werden in regelmäßigen Abständen geplant (z Ende des Monats).

An den nackten Knochen, SageMaker-Echtzeit-Inferenz besteht aus einem oder mehreren Modellen, dem Framework/Container, mit dem Sie arbeiten, und der Infrastruktur/den Instanzen, die Ihren bereitgestellten Endpunkt unterstützen. In diesem Beitrag untersuchen wir, wie Sie einen Single Model Endpoint erstellen und aufrufen können.

Auswählen der Modellbereitstellungsoption

Die Auswahl des richtigen Inferenztyps kann schwierig sein, und die folgende einfache Anleitung kann Ihnen dabei helfen. Es ist kein strenges Flussdiagramm. Wenn Sie also feststellen, dass eine andere Option für Sie besser funktioniert, können Sie diese gerne verwenden. Insbesondere ist Echtzeit-Inferenz eine großartige Option zum Hosten Ihrer Modelle, wenn Sie eine niedrige und konsistente Latenz (in der Größenordnung von Millisekunden oder Sekunden) und durchsatzempfindliche Workloads haben. Sie können den Instanztyp steuern und hinter Ihrem Endpunkt zählen, während Sie auch konfigurieren Automatische Skalierung Richtlinie zur Handhabung des Datenverkehrs. Es gibt zwei weitere SageMaker-Inferenzoptionen, die Sie ebenfalls zum Erstellen eines Endpunkts verwenden können. Asynchrone Inferenz liegt vor, wenn Sie über große Nutzlastgrößen und eine Latenzbandbreite nahezu in Echtzeit verfügen. Dies ist eine gute Option, insbesondere für NLP- und Computer Vision-Modelle, die längere Vorverarbeitungszeiten haben. Serverless Inference ist eine großartige Option, wenn Sie intermittierenden Datenverkehr haben und die Infrastrukturskalierung nicht verwalten möchten. Das Rezept zum Erstellen eines Endpunkts bleibt unabhängig vom gewählten Inferenztyp gleich. In diesem Beitrag konzentrieren wir uns auf die Erstellung eines instanzbasierten Endpunkts in Echtzeit, aber Sie können ihn basierend auf Ihrem Anwendungsfall problemlos an eine der anderen Inferenzoptionen anpassen. Schließlich findet die Batch-Inferenz offline statt, sodass Sie eine Reihe von Daten bereitstellen können, von denen Sie Inferenzen erhalten möchten, und wir führen sie aus. Dies ist ebenfalls instanzbasiert, sodass Sie die optimale Instanz für Ihre Arbeitslast auswählen können. Da kein Endpunkt in Betrieb ist, zahlen Sie nur für die Dauer des Auftrags. Es eignet sich gut für die Verarbeitung von Gigabyte an Daten und die Auftragsdauer kann Tage betragen. Es gibt integrierte Funktionen, die das Arbeiten mit strukturierten Daten erleichtern, und Optimierungen, um strukturierte Daten automatisch zu verteilen. Einige beispielhafte Anwendungsfälle sind Neigungsmodellierung, vorausschauende Wartung und Abwanderungsvorhersage. All dies kann in großen Mengen offline stattfinden, da nicht auf ein bestimmtes Ereignis reagiert werden muss.

Hosten eines Modells auf SageMaker Endpoints

Im Kern besteht SageMaker Real-Time Endpoints aus einem Modell und der Infrastruktur, mit der Sie den Endpoint unterstützen. SageMaker verwendet Container zum Hosten von Modellen, was bedeutet, dass Sie einen Container benötigen, der die Umgebung für das Framework, das Sie für jedes von Ihnen bereitgestellte Modell verwenden, ordnungsgemäß einrichtet. Wenn Sie beispielsweise mit einem Sklearn-Modell arbeiten, müssen Sie Ihre Modellskripts/Daten in einem Container übergeben, der Sklearn ordnungsgemäß einrichtet. Glücklicherweise bietet SageMaker dies an verwaltete Bilder für beliebte Frameworks wie TensorFlow, PyTorch, Sklearn und HuggingFace. Sie können diese Bilder mithilfe der High-Level abrufen und verwenden SageMaker Python-SDK und fügen Sie Ihre Modellskripte und Daten in diese Container ein. Falls SageMaker keinen unterstützten Container hat, können Sie das auch Bauen Sie Ihren eigenen Container und pushen Sie Ihr eigenes benutzerdefiniertes Image, indem Sie die Abhängigkeiten installieren, die für Ihr Modell erforderlich sind.

SageMaker unterstützt sowohl trainierte als auch vortrainierte Modelle. Wenn wir im vorherigen Absatz über Modellskripte/Daten sprechen, beziehen wir uns auf diese Angelegenheit. Sie können entweder ein Skript in Ihrem Container mounten oder, wenn Sie über ein vortrainiertes Modellartefakt (z. B. `model.joblib` für SKLearn), dann können Sie diese zusammen mit Ihrem Bild an SageMaker übermitteln. Um die SageMaker-Inferenz zu verstehen, gibt es drei Hauptentitäten, die Sie im Prozess der Endpunkterstellung erstellen:

1. SageMaker-Modellentität – Hier können Sie Ihre trainierten Modelldaten/Modellskripte und Ihr Bild, mit dem Sie arbeiten, übergeben, unabhängig davon, ob es AWS gehört oder von Ihnen erstellt wurde.
2. Endpoint-Konfigurationserstellung – Hier definieren Sie Ihre Infrastruktur, d. h. Sie wählen den Instanztyp, die Anzahl usw. aus.
3. Endpunkterstellung – Dies ist der REST-Endpunkt, der Ihr Modell hostet, das Sie aufrufen, um eine Antwort zu erhalten. Sehen wir uns an, wie Sie ein verwaltetes SageMaker-Image und Ihr eigenes benutzerdefiniertes Image verwenden können, um einen Endpunkt bereitzustellen.

Anforderungen an Endpunkte in Echtzeit

1. Bevor Sie einen Endpunkt erstellen, müssen Sie verstehen, welche Art von Modell Sie hosten möchten. Wenn es sich um ein Framework-Modell wie TensorFlow, PyTorch oder MXNet handelt, können Sie eines der verwenden vorgefertigte Framework-Images.
   Wenn es sich um ein benutzerdefiniertes Modell handelt oder Sie beim Erstellen des Containers, den SageMaker für die Inferenz ausführt, volle Flexibilität wünschen, können Sie Ihren eigenen Container erstellen.

SageMaker-Endpunkte bestehen aus a SageMaker-Modell und Endpunktkonfiguration.
Wenn Sie Boto3 verwenden, würden Sie beide Objekte erstellen. Andernfalls, wenn Sie das SageMaker Python SDK verwenden, wird die Endpunktkonfiguration in Ihrem Namen erstellt, wenn Sie die verwenden .deploy(..) Funktion.

SageMaker-Entitäten:

• SageMaker-Modell:
  • Enthält die Details des Inferenzbilds und die Position der Modellartefakte darin Amazon Simple Storage Service (Amazon S3), Netzwerkkonfiguration und AWS Identitäts- und Zugriffsverwaltung (IAM) Rolle, die vom Endpunkt verwendet werden soll.
    • SageMaker erfordert, dass Ihre Modellartefakte in a komprimiert werden .tar.gz Datei. SageMaker extrahiert diese automatisch .tar.gz Datei in die /opt/ml/model/ Verzeichnis in Ihrem Container. Wenn Sie einen der Framework-Container wie TensorFlow, PyTorch oder MXNet verwenden, erwartet der Container, dass Ihre TAR-Struktur wie folgt ist:
      • 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

      • MXNet
        

        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

    • Bei der Verwendung eines Framework-Images können wir ein benutzerdefiniertes Einstiegsskript bereitstellen, in dem wir unsere eigene Vor- und Nachverarbeitung implementieren können. In unserem Fall ist das Inferenzskript in model.tar.gz im /code-Verzeichnis gepackt.

• • Endpunktkonfiguration
    • Enthält die Infrastrukturinformationen, die zum Bereitstellen des SageMaker-Modells auf dem Endpunkt erforderlich sind.
    • Beispielsweise wird hier das von uns erstellte SageMaker-Modell sowie der Instanztyp und die Anzahl der anfänglichen Instanzen angegeben.

Frameworks und BYOC

• • Abrufen von SageMaker-Bildern
    • Dieser Teil ist nicht immer notwendig und wird vom SageMaker Python SDK über Schätzfunktionen abstrahiert. Wenn Sie jedoch ein von SageMaker verwaltetes Image abrufen möchten, um es darauf zu erweitern, können Sie die Images abrufen, die über das SDK verfügbar sind. Das Folgende ist ein Beispiel für das Abrufen eines TF 2.2-Bildes für die Inferenz.

      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)

  • Frameworks
    • Wenn Sie ein Framework-Modell wie TensorFlow, PyTorch oder MXNet bereitstellen möchten, benötigen Sie lediglich die Modellartefakte.
    • Weitere Informationen zum Bereitstellen von Modellen direkt aus Modellartefakten finden Sie in der Dokumentation TensorFlow, PyTorch, oder MXNet.

• • Auswahl zwischen 1P und BYOC
    • Das SageMaker-SDK abstrahiert auch den Umgang mit dem Bild, wie Sie im vorherigen Abschnitt „Frameworks“ gesehen haben. Es verfügt über vorgefertigte Schätzfunktionen für Sklearn, TensorFlow und PyTorch, die das Bild basierend auf der von Ihnen ausgewählten Version automatisch für Sie auswählen. Dann können Sie ein Trainings-/Inferenzskript durchgeben Skriptmodus in diese Schätzer.

      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)

    • Nicht alle Pakete und Bilder werden von SageMaker unterstützt, und in diesem Fall müssen Sie dies tun bringen Sie Ihren eigenen Container mit (BYOC). Das bedeutet, ein Dockerfile zu erstellen, das die richtige Umgebung für Ihre Modellbereitstellung einrichtet. Ein Beispiel hierfür ist das Spacy NLP-Modul, und es gibt keine verwalteten SageMaker-Container für dieses Framework. Daher müssen Sie ein Dockerfile bereitstellen, das Spacy installiert. Innerhalb des Containers mounten Sie auch Ihre Modellrückschlussskripte. Lassen Sie uns schnell die Komponenten besprechen, die Sie in einem Bring-Your-Own-Container-Format bereitstellen, da diese für die meisten Beispiele konsistent bleiben.
      • „nginx.conf“ ist die Konfigurationsdatei für das Nginx-Frontend. Sie müssen diese Datei nicht bearbeiten, es sei denn, Sie möchten diese Teile stimmen.
      • „predictor.py“ ist das Programm, das den Flask-Webserver und den Modellcode für Ihre Anwendung tatsächlich implementiert. Sie können weitere Python-Dateien oder Funktionen in Ihrem Container haben, die Sie in dieser Datei aufrufen können.
      • "Dienen" ist das Programm, das gestartet wird, wenn der Container zum Hosten gestartet wird. Es startet einfach den Gunicorn-Server, der mehrere Instanzen der Flask-App ausführt, die in optimizer.py definiert sind. Wie bei nginx.conf müssen Sie diese Datei nicht bearbeiten, es sei denn, Sie möchten weitere Optimierungen vornehmen.
      • "Zug" ist das Programm, das aufgerufen wird, wenn der Container zum Training ausgeführt wird. Sie ändern dieses Programm, um Ihren Trainingsalgorithmus zu implementieren. Wenn Sie ein vortrainiertes Modell oder Framework wie Spacy verwenden, benötigen Sie diese Datei nicht.
      • „wsgi.py“ ist ein kleiner Wrapper, der zum Aufrufen der Flask-App verwendet wird. Sie sollten diese Datei unverändert übernehmen können, es sei denn, Sie haben den Namen Ihrer Datei „dictor.py“ geändert. Stellen Sie in diesem Fall sicher, dass die Karten hier richtig sind.

• • Benutzerdefiniertes Inferenzskript
    • SageMaker Framework-Container geben Ihnen die Flexibilität, die Vor-/Nachverarbeitung der Anfrage und das Laden des Modells mit einem benutzerdefinierten Einstiegspunkt script/inference.py zu handhaben.
    • Siehe die Dokumentation zum Erstellen eines benutzerdefinierten inference.py-Skripts für TensorFlow, PyTorch und MXNet.
  • Benutzerdefinierter Behälter

Verschiedene Möglichkeiten, wie Sie mit SageMaker Endpoints interagieren können

Es gibt viele Optionen für die programmgesteuerte Verwendung von SageMaker, sodass Sie Ihre bereitgestellten Modelle aufrufen können, um Rückschlüsse zu erhalten. Das AWS-Befehlszeilenschnittstelle (AWS CLI), REST-APIs, AWS CloudFormation, AWS Cloud Development Kit (AWS CDK) und AWS SDKs sind gängige Tools, die von AWS angeboten und von anderen AWS-Services umfassend unterstützt werden. Für SageMaker haben wir auch ein SageMaker Python SDK. Lassen Sie uns nun die verschiedenen Optionen zum Erstellen, Aufrufen und Verwalten von SageMaker-Endpunkten vergleichen.

Zusätzlich zu den Modi SageMaker-CLI, gibt es zwei programmgesteuerte Möglichkeiten, wie Sie mit Endpoints in SageMaker über die SDKs interagieren können. Schauen wir uns einige Unterschiede zwischen an SageMaker Python-SDK und Boto3-Python-SDK:

1. High-Level-SageMaker-„Python“-SDK – Dieses SDK ist eine Open-Source-Bibliothek, die eine Abstraktion auf höherer Ebene bietet, die speziell für den programmgesteuerten Aufruf von SageMaker-APIs mit Python gedacht ist. Das Gute an diesem SDK ist, dass es sehr einfach ist, Sagemaker-APIs aufzurufen, viel schweres Heben wird bereits erledigt, wie das Aufrufen der APIs im synchronen/asynchronen Modus (hilft, Polling zu vermeiden), ein einfacheres Anforderungs-/Antwortschema, viel weniger Code und vieles mehr einfacherer Code. Das SageMaker Python SDK bietet mehrere High-Level-Abstraktionen für die Arbeit mit SageMaker. Das Paket soll verschiedene ML-Prozesse auf SageMaker vereinfachen.
2. Low-Level-AWS-SDK (Boto3 SDK) – Dieses SDK arbeitet auf der unteren Ebene, indem es dem Benutzer ermöglicht, aus den unterstützten Programmiersprachen auszuwählen und alle AWS-Services programmgesteuert aufzurufen. Dies ist nicht nur spezifisch für SageMaker, sondern kann allgemein für alle AWS-Dienste verwendet werden. Die Low-Level-AWS-SDKs sind in verschiedenen Programmiersprachen verfügbar, z. B. .NET, Python, Java, Node.js usw. Eines der beliebtesten verwendeten SDKs ist boto3 python SDK, das in der Data Scientist-Community für ML beliebt ist. Das Gute an diesem SDK ist, dass es sehr leicht ist und standardmäßig installiert ist AWS Lambda Laufzeit. Darüber hinaus können Sie dieses SDK verwenden, um mit jedem AWS-Service außerhalb von SageMaker zu interagieren.

Beide SDKs können für dieselben Aufgaben verwendet werden, aber in einigen Fällen ist es intuitiver, eines mehr als das andere zu verwenden. SageMaker Python SDK wird für einfaches Testen empfohlen, während AWS SDK/Boto3 für Anwendungsfälle in der Produktion empfohlen wird, um die Leistung besser kontrollieren zu können. SageMaker as a Service bietet beispielsweise vorgefertigte und gepflegte Images für beliebte Frameworks wie Sklearn, PyTorch und TensorFlow. Es kann besonders nützlich sein, SageMaker SDK zu verwenden, um Deep-Learning-Bilder abzurufen und Modelle zu trainieren Schätzer, und stellen Sie das Modell einfach mit einem einfachen API-Aufruf bereit. Ein Beispiel, um dies in Aktion zu zeigen, kann gefunden werden hier.

Andererseits haben Sie manchmal vortrainierte Modelle oder verschiedene Frameworks, die Sie möglicherweise verwenden. Dies erfordert ein größeres Maß an Anpassung und das SageMaker SDK bietet dies nicht immer. Wir haben drei wichtige Schritte und entsprechende boto3-API-Aufrufe, die wir ausführen müssen, um einen Endpunkt bereitzustellen: Modellerstellung, Erstellung der Endpunktkonfiguration und Endpunkterstellung. Die ersten beiden Entitäten wurden mit dem SageMaker SDK mit unseren unterstützten Frameworks abstrahiert, aber wir sehen diese Details mit dem Boto3 SDK. Ein ausführliches Beispiel zur Veranschaulichung der Schritte zur Verwendung eines Boto3-SDK zum Erstellen und Verwalten eines Endpunkts finden Sie hier hier.

Überlegungen zum SageMaker-Hosting

SageMaker Real-Time Inference hat zwei Hauptoptimierungen, die Sie berücksichtigen können: 1/ Leistungsoptimierung und 2/ Kostenoptimierung. Schauen wir uns zuerst an Leistungsoptimierung, denn wenn wir es mit latenzempfindlichen Workloads zu tun haben, ist jede Millisekunde entscheidend. Es gibt verschiedene Regler, die Sie einstellen können, um Ihre Latenz und Ihren Durchsatz zu optimieren. Auf Instanzebene können Sie verwenden Inferenz-Recommender, unser integriertes Auslastungstest-Tool, um Ihnen bei der Auswahl des richtigen Instance-Typs und der richtigen Anzahl für Ihre Workload zu helfen. Die Verwendung der richtigen Compute-Kombination hilft Ihnen sowohl bei der Leistung als auch bei den Kosten. Sie können auch auf Container- und Frameworkebene optimieren.
Zu den Fragen, die Sie sich stellen sollten, gehören:

1. Welchen Rahmen verwendest du?
2. Gibt es Umgebungsvariablen, die Sie in Ihrem Container optimieren können?

Ein Beispiel hierfür ist die Maximierung TensorFlow-Leistung mit SageMaker-Containern. Ein weiteres Beispiel für Optimierungen auf Containerebene ist Verwendung von gRPC anstatt REST hinter Ihrem Endpunkt. Schließlich können Sie auch auf Skriptebene optimieren. Benötigt Ihr Inferenzcode bei bestimmten Blöcken zusätzliche Zeit? Das Timing jeder einzelnen Zeile Ihres Skripts hilft Ihnen, alle Engpässe in Ihrem Code zu erkennen.

Es gibt drei Betrachtungsweisen Verbesserung der Auslastung Ihres Echtzeit-Endpunkts:

1. Multi-Modell-Endpunkte (MME)
   • Sie können Tausende von Modellen hinter einem einzigen Endpunkt hosten. Dies ist perfekt für Anwendungsfälle, in denen Sie keinen dedizierten Endpunkt für jedes Ihrer Modelle benötigen. MME funktioniert am besten, wenn die Modelle eine ähnliche Größe und Latenz haben und zum selben ML-Framework gehören. Diese können normalerweise verwendet werden, wenn Sie nicht immer dasselbe Modell anrufen müssen. Sie können das jeweilige Modell dynamisch auf den SageMaker Endpoint laden, um Ihre Anfrage zu bedienen. Ein Beispiel, das MME in Aktion zeigt, finden Sie hier hier. Wenn Sie mehr über die verschiedenen Vorbehalte und Best Practices für das Hosten von Modellen auf MME erfahren möchten, lesen Sie den Beitrag hier.
2. Multi-Container-Endpunkte (MCE)
   • Anstatt mehrere Endpunkte zum Hosten mehrerer Container zu verwenden, können Sie bis zu 15 Container auf einem einzigen Endpunkt hosten. Jeder dieser Container kann direkt aufgerufen werden. Daher können Sie unterschiedliche Modelle verschiedener Frameworks auf einem einzigen Endpunkt hosten. Diese Option ist am besten geeignet, wenn Container ähnliche Verwendungs- und Leistungsmerkmale aufweisen. Ein Beispiel, das MCE präsentiert, ist zu finden hier. Wenn Sie mehr über die verschiedenen Vorbehalte und Best Practices für das Hosten von Modellen auf MCE erfahren möchten, lesen Sie den Beitrag hier.
3. Serielle Inferenzpipeline (SIP)
   • Wenn Sie eine Pipeline von Schritten in Ihrer Inferenzlogik haben, können Sie die Serial Inference Pipeline (SIP) verwenden. Mit SIP können Sie 2-15 Container hinter einem einzigen Endpunkt verketten. SIP funktioniert gut, wenn Sie Vorverarbeitungs- und Nachverarbeitungsschritte haben. Wenn Sie mehr über die Entwurfsmuster für serielle Inferenzpipelines erfahren möchten, lesen Sie den Beitrag hier.

Die zweite wichtige Optimierung, die Sie im Hinterkopf behalten sollten, ist kosten. Echtzeit-Inferenz ist eine von drei Optionen beim Erstellen von SageMaker-Endpunkten. SageMaker Endpoints werden immer ausgeführt, sofern sie nicht gelöscht werden. Daher müssen Sie die Nutzung des Endpunkts verbessern, was wiederum einen Kostenvorteil bietet.

SageMaker bietet auch Sparpläne. Sparpläne können Ihre Kosten um bis zu 64 % senken. Hierbei handelt es sich um eine 1- oder 3-jährige Verpflichtung zu einer gleichbleibenden Nutzungsmenge ($/Stunde). Sieh dir das an Link für mehr Informationen. Und siehe das Link um die Kosten für die Inferenz auf Amazon SageMaker am besten zu optimieren.

Zusammenfassung

In diesem Beitrag haben wir Ihnen einige der Best Practices gezeigt, um zwischen verschiedenen Modell-Hosting-Optionen auf SageMaker zu wählen. Wir haben die SageMaker Endpoint-Anforderungen besprochen und auch Framework- und BYOC-Anforderungen und -Funktionen gegenübergestellt. Darüber hinaus haben wir über die verschiedenen Möglichkeiten gesprochen, wie Sie Echtzeit-Endpunkte nutzen können, um Ihre ML-Modelle in der Produktion zu hosten. auf kostengünstige Weise und haben eine hohe Leistung.

Siehe die entsprechenden GitHub-Repository und probiere die Beispiele aus.

---

Über die Autoren

Raghu Ramesha ist ML Solutions Architect im Amazon SageMaker Service-Team. Er konzentriert sich darauf, Kunden dabei zu helfen, ML-Produktions-Workloads in großem Maßstab zu erstellen, bereitzustellen und zu SageMaker zu migrieren. Er ist auf maschinelles Lernen, KI und Computer Vision spezialisiert und hat einen Master-Abschluss in Informatik von der UT Dallas. In seiner Freizeit reist und fotografiert er gerne.

Widder Vegiraju ist ML-Architekt im SageMaker-Serviceteam. Er konzentriert sich darauf, Kunden bei der Erstellung und Optimierung ihrer KI/ML-Lösungen auf Amazon SageMaker zu unterstützen. In seiner Freizeit liebt er es zu reisen und zu schreiben.

Markus Karp ist ML-Architekt im SageMaker-Serviceteam. Er konzentriert sich darauf, Kunden dabei zu helfen, ML-Workloads in großem Umfang zu entwerfen, bereitzustellen und zu verwalten. In seiner Freizeit reist er gerne und entdeckt neue Orte.

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.

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.