Modell-Hosting FAQs

A: Nachdem Sie Modelle erstellt und trainiert haben, bietet Amazon SageMaker AI vier Optionen für deren Bereitstellung, sodass Sie mit der Erstellung von Prognosen beginnen können. Real-Time Inference eignet sich für Workloads mit Latenzanforderungen im Millisekundenbereich, Nutzlastgrößen von bis zu 6 MB und Verarbeitungszeiten von bis zu 60 Sekunden. Batch Transform ist ideal für Offline-Vorhersagen für große Datenmengen, die im Voraus verfügbar sind. Asynchrone Inferenz wurde für Workloads entwickelt, für die keine Latenz von weniger als einer Sekunde, Nutzlastgrößen von bis zu 1 GB und Verarbeitungszeiten von bis zu 15 Minuten gelten. Mit Serverless Inference können Sie schnell Modelle für Machine Learning für Inferenz bereitstellen, ohne die zugrunde liegende Infrastruktur konfigurieren oder verwalten zu müssen, und Sie zahlen nur für die Rechenkapazität, die für die Verarbeitung von Inferenzanforderungen verwendet wird, was ideal für intermittierende Workloads ist.

A: Das folgende Diagramm kann Ihnen bei der Auswahl einer Implementierungsoption für ein SageMaker KI-Hosting-Modell helfen.

Das obige Diagramm führt Sie durch den folgenden Entscheidungsprozess. Wenn Sie Anfragen in Batches verarbeiten möchten, sollten Sie Batch Transform wählen. Andernfalls können Sie Asynchrone Inferenz, Serverlose Inferenz oder Echtzeit-Inferenz wählen, wenn Sie für jede Anforderung an Ihr Modell Inferenz erhalten möchten. Sie können Asynchrone Inferenz wählen, wenn Sie lange Verarbeitungszeiten oder große Nutzlasten haben und Anfragen in eine Warteschlange stellen möchten. Sie können Serverlose Inference wählen, wenn Ihr Workload unvorhersehbaren oder intermittierenden Datenverkehr aufweist. Sie können Echtzeit Inference wählen, wenn Sie anhaltenden Datenverkehr haben und eine geringere und konsistente Latenz für Ihre Anfragen benötigen.

F: Wie wähle ich eine Option zur Modellbereitstellung in SageMaker KI aus?

A: Das folgende Diagramm kann Ihnen bei der Auswahl einer Implementierungsoption für ein SageMaker KI-Hosting-Modell helfen.

Das obige Diagramm führt Sie durch den folgenden Entscheidungsprozess. Wenn Sie Anfragen in Batches verarbeiten möchten, sollten Sie Batch Transform wählen. Andernfalls können Sie Asynchrone Inferenz, Serverlose Inferenz oder Echtzeit-Inferenz wählen, wenn Sie für jede Anforderung an Ihr Modell Inferenz erhalten möchten. Sie können Asynchrone Inferenz wählen, wenn Sie lange Verarbeitungszeiten oder große Nutzlasten haben und Anfragen in eine Warteschlange stellen möchten. Sie können Serverlose Inference wählen, wenn Ihr Workload unvorhersehbaren oder intermittierenden Datenverkehr aufweist. Sie können Echtzeit Inference wählen, wenn Sie anhaltenden Datenverkehr haben und eine geringere und konsistente Latenz für Ihre Anfragen benötigen.

A: Um Ihre Kosten mit SageMaker AI Inference zu optimieren, sollten Sie die richtige Hosting-Option für Ihren Anwendungsfall wählen. Sie können auch Inferenzfunktionen wie Amazon SageMaker AI Savings Plans, Modelloptimierung mit SageMaker Neo, Multi-Model Endpoints und Multi-Container Endpoints oder Autoscaling verwenden. Tipps zur Optimierung Ihrer Inferenzkosten finden Sie unter Bewährte Methoden zur Optimierung von Inference-Kosten.

A: Sie sollten Amazon SageMaker Inference Recommender verwenden, wenn Sie Empfehlungen für die richtige Endpunktkonfiguration benötigen, um die Leistung zu verbessern und die Kosten zu senken. Bisher mussten Datenwissenschaftler, die ihre Modelle einsetzen wollten, manuelle Benchmarks durchführen, um die richtige Endpunktkonfiguration auszuwählen. Zuerst mussten sie den richtigen Instance-Typ für Machine Learning aus mehr als 70 verfügbaren Instance-Typen auswählen, basierend auf den Ressourcenanforderungen ihrer Modelle und Beispielnutzlasten, und dann das Modell optimieren, um unterschiedliche Hardware zu berücksichtigen. Anschließend mussten sie umfangreiche Lasttests durchführen, um zu überprüfen, ob die Latenz- und Durchsatzanforderungen erfüllt wurden und die Kosten niedrig waren. Inference Recommender beseitigt diese Komplexität, indem er Sie bei Folgendem unterstützt:

A: SageMaker KI-Endpunkte sind HTTP-REST-Endpunkte, die einen containerisierten Webserver verwenden, zu dem auch ein Modellserver gehört. Diese Container sind dafür verantwortlich, Anfragen für ein Machine-Learning-Modell zu laden und zu bearbeiten. Container implementieren einen Webserver, der auf /invocations und /ping auf Port 8080 antwortet.

Zu den gängigen Modellservern gehören TensorFlow Serving TorchServe und Multi Model Server. SageMaker In KI-Framework-Containern sind diese Modellserver integriert.

A: Alles in SageMaker AI Inference ist containerisiert. SageMaker KI bietet verwaltete Container für beliebte Frameworks wie TensorFlow, und SKlearn. HuggingFace Eine umfassende, aktualisierte Liste dieser Bilder finden Sie unter Verfügbare Bilder.

Manchmal gibt es benutzerdefinierte Frameworks, für die Sie möglicherweise einen Container erstellen müssen. Dieser Ansatz ist als Bring Your Own Container oder BYOC bekannt. Beim BYOC-Ansatz stellen Sie das Docker-Image zur Einrichtung Ihres Frameworks oder Ihrer Bibliothek bereit. Anschließend übertragen Sie das Image an Amazon Elastic Container Registry (Amazon ECR), sodass Sie das Image mit SageMaker KI verwenden können. Ein Beispiel für einen BYOC-Ansatz finden Sie unter Überblick über Container für Amazon AI. SageMaker

Anstatt ein Image von Grund auf neu zu erstellen, können Sie alternativ einen Container erweitern. Sie können eines der von SageMaker AI bereitgestellten Basis-Images verwenden und Ihre Abhängigkeiten zusätzlich zu Ihrem Dockerfile hinzufügen.

A: SageMaker KI bietet die Möglichkeit, Ihr eigenes trainiertes Framework-Modell, das Sie außerhalb von SageMaker KI trainiert haben, mitzubringen und es auf einer der SageMaker KI-Hosting-Optionen einzusetzen.

SageMaker KI erfordert, dass Sie das Modell in einer model.tar.gz Datei verpacken und über eine bestimmte Verzeichnisstruktur verfügen. Jedes Framework hat seine eigene Modellstruktur (Beispielstrukturen finden Sie in der folgenden Frage). Weitere Informationen finden Sie in der SageMaker Python-SDK-Dokumentation für TensorFlowPyTorch, und MXNet.

Sie können zwar aus vorgefertigten Framework-Images wie TensorFlow, und wählen PyTorch, um Ihr trainiertes Modell MXNet zu hosten, aber Sie können auch Ihren eigenen Container erstellen, um Ihre trainierten Modelle auf SageMaker KI-Endpunkten zu hosten. Eine exemplarische Vorgehensweise finden Sie im Beispiel eines Jupyter Notebooks: Erstellen Sie Ihren eigenen Algorithmus-Container.

A: SageMaker KI erfordert, dass Ihre Modellartefakte in einer .tar.gz Datei oder einem Tarball komprimiert sind. SageMaker AI extrahiert diese .tar.gz Datei automatisch in das /opt/ml/model/ Verzeichnis in Ihrem Container. Der Tarball sollte keine symbolischen Links oder überflüssige Dateien enthalten. Wenn Sie einen der Framework-Container wie,, oder verwenden TensorFlow PyTorch, erwartet der Container MXNet, dass Ihre TAR-Struktur wie folgt aussieht:

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

model.tar.gz/
             |--[model_version_number]/
                                       |--variables
                                       |--saved_model.pb
            code/
                |--inference.py
                |--requirements.txt

model.tar.gz/
             |- model.pth
             |- code/
                     |- inference.py
                     |- requirements.txt  # only for versions 1.3.1 and higher

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

A: ContentType ist der MIME-Typ der Eingabedaten im Anfragetext (der MIME-Typ der Daten, die Sie an Ihren Endpunkt senden). Der Modellserver verwendet den ContentType, um festzustellen, ob er den angegebenen Typ verarbeiten kann oder nicht.

Accept ist der MIME-Typ der Inferenzantwort (der MIME-Typ der Daten, die Ihr Endpunkt zurückgibt). Der Modellserver bestimmt anhand des Accept Typs, ob er die Rückgabe des angegebenen Typs verarbeiten kann oder nicht.

Zu den gängigen MIME-Typen gehören text/csv, application/json und application/jsonlines.

A: SageMaker KI leitet jede Anfrage ohne Änderung an den Modellcontainer weiter. Der Container muss die Logik zur Deserialisierung der Anfrage enthalten. Informationen zu den für integrierte Algorithmen definierten Formaten finden Sie unter Allgemeine Datenformate für Inferenz. Wenn Sie Ihren eigenen Container erstellen oder einen SageMaker AI Framework-Container verwenden, können Sie die Logik zur Annahme eines Anforderungsformats Ihrer Wahl einbeziehen.

In ähnlicher Weise gibt SageMaker KI auch die Antwort ohne Änderung zurück, und dann muss der Client die Antwort deserialisieren. Im Fall der integrierten Algorithmen geben sie Antworten in bestimmten Formaten zurück. Wenn Sie Ihren eigenen Container erstellen oder einen SageMaker AI Framework-Container verwenden, können Sie die Logik zur Rückgabe einer Antwort in dem von Ihnen gewählten Format einbeziehen.

Verwenden Sie den Invoke Endpoint-API-Aufruf, um Rückschlüsse auf Ihren Endpunkt zu ziehen.

Wenn Sie Ihre Eingabe als Nutzlast an die InvokeEndpoint-API übergeben, müssen Sie den richtigen Typ von Eingabedaten angeben, den Ihr Modell erwartet. Bei der Übergabe einer Nutzlast im InvokeEndpoint-API-Aufruf werden die Anforderungsbytes direkt an den Modellcontainer weitergeleitet. Für ein Bild können Sie beispielsweise application/jpeg für den ContentType verwenden und sicherstellen, dass Ihr Modell Rückschlüsse auf diese Art von Daten ziehen kann. Dies gilt für JSON, CSV, Video oder jede andere Art von Eingabe, mit der Sie es möglicherweise zu tun haben.

Ein weiterer zu berücksichtigender Faktor sind die Größenbeschränkungen für Nutzlasten. In Bezug auf Echtzeit- und serverlose Endpunkte liegt das Nutzlastlimit bei 6 MB. Sie können Ihr Video in mehrere Frames aufteilen und den Endpunkt mit jedem Frame einzeln aufrufen. Wenn Ihr Anwendungsfall dies zulässt, können Sie alternativ das gesamte Video in der Payload über einen asynchronen Endpunkt senden, der Payloads von bis zu 1 GB unterstützt.

In diesem Blogbeitrag finden Sie ein Beispiel, das zeigt, wie Sie Computer-Vision-Inferenz für große Videos mit asynchroner Inferenz ausführen können.

A: Sie können einen SageMaker KI-Endpunkt mithilfe AWS von Tools wie dem SageMaker Python-SDK AWS SDKs, dem AWS Management Console AWS CloudFormation, und dem erstellen. AWS Cloud Development Kit (AWS CDK)

Bei der Endpunkterstellung gibt es drei Schlüsseleinheiten: ein SageMaker KI-Modell, eine SageMaker KI-Endpunktkonfiguration und einen SageMaker KI-Endpunkt. Das SageMaker KI-Modell zeigt auf die Modelldaten und das Bild, das Sie verwenden. Die Endpunktkonfiguration definiert Ihre Produktionsvarianten, die den Instance-Typ und die Anzahl der Instances beinhalten können. Sie können dann entweder den API-Aufruf create_endpoint oder den Aufruf .deploy () für SageMaker KI verwenden, um mithilfe der Metadaten aus Ihrem Modell und Ihrer Endpunktkonfiguration einen Endpunkt zu erstellen.

A: Nein, Sie können die verschiedenen verwenden AWS SDKs (siehe Invoke/Create for available SDKs) oder sogar das entsprechende Web direkt aufrufen. APIs

A: Ein Multi-Modell-Endpunkt ist eine Echtzeit-Inferenzoption, die SageMaker KI bietet. Mit Multi-Model-Endpunkte können Sie Tausende von Modellen hinter einem Endpunkt hosten. Multi Model Server ist ein Open-Source-Framework für die Bereitstellung von Modellen für Machine Learning. Es stellt die HTTP-Frontend- und Modellverwaltungsfunktionen bereit, die von Multimodell-Endpunkten benötigt werden, um mehrere Modelle in einem einzigen Container zu hosten, Modelle dynamisch in den Container zu laden und Modelle daraus zu entladen und Inferenzen auf ein spezifiziertes geladenes Modell auszuführen.

A: SageMaker AI Real-Time Inference unterstützt verschiedene Implementierungsarchitekturen wie Multi-Modell-Endpunkte, Multi-Container-Endpunkte und serielle Inferenz-Pipelines.

Multi-Model-Endpunkte (MME) – MME ermöglicht es Kunden, Tausende von hyperpersonalisierten Modellen auf kostengünstige Weise bereitzustellen. Alle Modelle werden in einer Flotte mit gemeinsam genutzten Ressourcen eingesetzt. MME funktioniert am besten, wenn die Modelle eine ähnliche Größe und Latenz haben und demselben ML-Framework angehören. Diese Endpunkte sind ideal, wenn Sie nicht immer dasselbe Modell aufrufen müssen. Sie können die entsprechenden Modelle dynamisch auf den KI-Endpunkt laden, um Ihre Anfrage zu bearbeiten SageMaker .

Multi-Container-Endpoints (MCE) — MCE ermöglicht es Kunden, 15 verschiedene Container mit unterschiedlichen ML-Frameworks und -Funktionen ohne Kaltstarts bereitzustellen und dabei nur einen Endpunkt zu verwenden. SageMaker Sie können diese Container direkt aufrufen. MCE eignet sich am besten, wenn Sie alle Modelle im Speicher behalten möchten.

Serial Inferenz Pipelines (SIP) – Sie können SIP verwenden, um 2–15 Container auf einem einzigen Endpunkt miteinander zu verketten. SIP eignet sich vor allem für die Kombination von Vorverarbeitung und Modellinferenz an einem Endpunkt sowie für Operationen mit geringer Latenz.

A: Bereitstellen von Modellen mit Amazon SageMaker Serverless Inference ist eine speziell entwickelte Option zur serverlosen Bereitstellung von Modellen, mit der ML-Modelle einfach bereitgestellt und skaliert werden können. Serverlose Inferenzendpunkte starten automatisch Rechenressourcen und skalieren sie je nach Datenverkehr ein- und wieder heraus, sodass Sie sich nicht mehr für den Instance-Typ entscheiden, die bereitgestellte Kapazität ausführen oder die Skalierung verwalten müssen. Optional können Sie die Speicheranforderungen für Ihren serverlosen Endpunkt angeben. Sie zahlen nur für die Dauer der Ausführung des Inferenzcodes und die Menge der verarbeiteten Daten, nicht für Leerlaufzeiten.

A: Serverlose Inferenz vereinfacht das Entwicklererlebnis, da die Notwendigkeit entfällt, Kapazität im Voraus bereitzustellen und Skalierungsrichtlinien zu verwalten. Serverlose Inferenz kann je nach Nutzungsmuster innerhalb von Sekunden sofort von Zehntausenden auf Tausende von Inferenzen skaliert werden und eignet sich somit ideal für ML-Anwendungen mit intermittierendem oder unvorhersehbarem Datenverkehr. Beispielsweise verzeichnet ein Chatbot-Dienst, der von einem Unternehmen für die Gehaltsabrechnung genutzt wird, am Ende des Monats einen Anstieg der Anfragen, während der Verkehr für den Rest des Monats unterbrochen ist. Die Bereitstellung von Instances für den gesamten Monat ist in solchen Szenarien nicht kosteneffektiv, da Sie am Ende für Leerlaufzeiten zahlen müssen.

Serverlose Inferenz hilft bei der Bewältigung dieser Art von Anwendungsfällen, indem es Ihnen eine automatische und schnelle Skalierung ermöglicht, ohne dass Sie den Datenverkehr im Voraus prognostizieren oder Skalierungsrichtlinien verwalten müssen. Darüber hinaus zahlen Sie nur für die Rechenzeit, die für die Ausführung Ihres Inferenzcodes und für die Datenverarbeitung erforderlich ist. Somit eignet sich die Lösung ideal für Workloads mit intermittierendem Datenverkehr.

A: Ihr serverloser Endpunkt hat eine minimale RAM-Größe von 1024 MB (1 GB), und die maximale RAM-Größe, die Sie wählen können, beträgt 6144 MB (6 GB). Die Speichergrößen, die Sie wählen können, sind 1024 MB, 2048 MB, 3096 MB, 5120 MB oder 6144 MB. Serverlose Inferenz weist Rechenressourcen automatisch proportional zum ausgewählten Speicher zu. Wenn Sie eine größere Speichergröße wählen, hat Ihr Container Zugriff auf mehr V. CPUs

Wählen Sie die Speichergröße Ihres Endpunkts entsprechend Ihrer Modellgröße. Im Allgemeinen sollte die Speichergröße mindestens so groß sein wie Ihre Modellgröße. Möglicherweise müssen Sie einen Benchmark durchführen, um anhand Ihrer Latenz die richtige Speicherauswahl für Ihr Modell auszuwählen SLAs. Die Speichergrößenstufen haben unterschiedliche Preise. Weitere Informationen finden Sie auf der SageMaker Amazon-Preisseite.

A: Für bestimmte Dateiformate wie CSV, RecordIO und TFRecord SageMaker AI kann KI Ihre Daten in Mini-Batches mit einem Datensatz oder mehreren Datensätzen aufteilen und diese als Nutzlast an Ihren Modellcontainer senden. Wenn der Wert von BatchStrategy istMultiRecord, sendet SageMaker KI die maximale Anzahl von Datensätzen in jeder Anfrage bis zum Limit. MaxPayloadInMB Wenn der Wert von BatchStrategy gleich istSingleRecord, sendet SageMaker KI in jeder Anfrage einzelne Datensätze.

A: Das maximale Timeout für Batch-Transformation beträgt 3600 Sekunden. Die maximale Payload-Größe für einen Datensatz (pro Mini-Batch) beträgt 100 MB.

Wenn Sie die CreateTransformJob-API verwenden, können Sie die Batch-Transformationsaufträge schneller abschließen, indem Sie optimale Werte für Parameter wie MaxPayloadInMB, MaxConcurrentTransforms, oder BatchStrategy verwenden. Der ideale Wert für MaxConcurrentTransforms entspricht der Anzahl der Rechenarbeiter im Batch-Transformationsauftrag. Wenn Sie die SageMaker AI-Konsole verwenden, können Sie diese optimalen Parameterwerte im Abschnitt Zusätzliche Konfiguration auf der Konfigurationsseite für Batch-Transformationsaufträge angeben. SageMaker KI findet automatisch die optimalen Parametereinstellungen für integrierte Algorithmen. Für benutzerdefinierte Algorithmen müssen Sie diese Werte über einen execution-parameters-Endpunkt angeben.

A: Batch-Transformation unterstützt CSV und JSON.

A: Asynchrone Inferenz stellt eingehende Anfragen in eine Warteschlange und verarbeitet sie asynchron. Diese Option ist ideal für Anfragen mit großen Nutzlasten oder langen Verarbeitungszeiten, die bei ihrem Eingang verarbeitet werden müssen. Optional können Sie Einstellungen für die automatische Skalierung konfigurieren, um die Anzahl der Instances auf Null zu reduzieren, wenn Anfragen nicht aktiv verarbeitet werden.

A: Amazon SageMaker AI unterstützt die automatische Skalierung (Autoscaling) Ihres asynchronen Endpunkts. Autoscaling passt die Anzahl der Instances, die für ein Modell als Reaktion auf Änderungen Ihres Workloads bereitgestellt wurden, dynamisch an. Im Gegensatz zu anderen gehosteten Modellen, die SageMaker KI unterstützt, können Sie mit Asynchronous Inference auch Ihre asynchronen Endpunkt-Instances auf Null herunterskalieren. Anfragen, die eingehen, wenn keine Instances vorhanden sind, werden zur Verarbeitung in die Warteschlange gestellt, sobald der Endpunkt hochskaliert wird. Weitere Informationen finden Sie unter Automatisches Skalieren eines asynchronen Endpunkts.

Amazon SageMaker Serverless Inference wird außerdem automatisch auf Null herunterskaliert. Sie werden das nicht sehen, weil SageMaker KI die Skalierung Ihrer serverlosen Endpunkte verwaltet. Wenn Sie jedoch keinen Datenverkehr haben, gilt dieselbe Infrastruktur.