Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Modell-Hosting FAQs
In den folgenden FAQ Abschnitten finden Sie Antworten auf häufig gestellte Fragen zu SageMaker Inference Hosting.
Allgemeines Hosting
Die folgenden FAQ Punkte beantworten häufig gestellte allgemeine Fragen zu SageMaker Inference.
A: Nachdem Sie Modelle erstellt und trainiert haben, SageMaker bietet Amazon 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 Bereitstellungsoption für ein SageMaker 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 Inference zu optimieren, sollten Sie die richtige Hosting-Option für Ihren Anwendungsfall wählen. Sie können auch Inferenzfunktionen wie Amazon SageMaker Savings Plans
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:
-
Mit einer Instance-Empfehlung können Sie in wenigen Minuten loslegen.
-
Führen Sie Lasttests für alle Instance-Typen durch, um innerhalb weniger Stunden Empfehlungen für Ihre Endpunktkonfiguration zu erhalten.
-
Passen Sie Container- und Model-Serverparameter automatisch an und führen Sie Modelloptimierungen für einen bestimmten Instance-Typ durch.
A: SageMaker Endpunkte sind HTTP REST Endgeräte, 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 Framework-Containern sind diese Modellserver integriert.
A: Alles in SageMaker Inference ist containerisiert. SageMaker bietet verwaltete Container für beliebte Frameworks wie TensorFlow, undSKlearn. 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 bekannt als Bring Your Own Container oder BYOC. Bei diesem 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 (AmazonECR), sodass Sie das Image mit verwenden können SageMaker. Ein Beispiel für einen BYOC Ansatz finden Sie unter Überblick über Container für Amazon
Anstatt ein Image von Grund auf neu zu erstellen, können Sie alternativ einen Container erweitern. Sie können eines der bereitgestellten Basis-Images verwenden SageMaker und Ihre Abhängigkeiten zusätzlich zu Ihrem Dockerfile hinzufügen.
A: SageMaker bietet die Möglichkeit, Ihr eigenes trainiertes Framework-Modell, das Sie außerhalb trainiert haben, mitzubringen SageMaker und es auf einer der SageMaker Hosting-Optionen einzusetzen.
SageMaker erfordert, dass Sie das Modell in einer model.tar.gz Datei packen 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 SDK Python-Dokumentation für TensorFlowPyTorch
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 Endpunkten zu hosten. Eine exemplarische Vorgehensweise finden Sie im Beispiel eines Jupyter Notebooks: Erstellen Sie Ihren eigenen Algorithmus-Container
A: SageMaker erfordert, dass Ihre Modellartefakte in einer .tar.gz Datei oder einem Tarball komprimiert sind. SageMaker 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 ContainerMXNet, 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
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.
Acceptist 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/csvapplication/json, undapplication/jsonlines.
A: SageMaker Übergibt jede Anfrage ohne Änderung an den Modellcontainer. 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 Framework-Container verwenden, können Sie die Logik zur Annahme eines Anforderungsformats Ihrer Wahl einbeziehen.
In ähnlicher Weise wird SageMaker auch die Antwort ohne Änderung zurückgegeben, 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 Framework-Container verwenden, können Sie die Logik zur Rückgabe einer Antwort in dem von Ihnen ausgewählten Format einbeziehen.
Verwenden Sie den Aufruf Invoke EndpointAPI, um Rückschlüsse auf Ihren Endpunkt zu ziehen.
Wenn Sie Ihre Eingabe als Nutzlast an die übergeben InvokeEndpointAPI, 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ürJSON,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
Echtzeit-Inferenz
Die folgenden FAQ Punkte beantworten häufig gestellte Fragen zu SageMaker Real-Time Inference.
A: Sie können einen SageMaker Endpunkt mit AWS unterstützten Tools wie SageMaker Python AWS SDKs,, SDK AWS Management Console AWS CloudFormation, und dem erstellen. AWS Cloud Development Kit (AWS CDK)
Bei der Endpunkterstellung gibt es drei wichtige Entitäten: ein SageMaker Modell, eine SageMaker Endpunktkonfiguration und einen SageMaker Endpunkt. Das SageMaker 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 Aufruf create_endpoint
A: Nein, Sie können die verschiedenen verwenden AWS SDKs (siehe Invoke/Create for availableSDKs) oder sogar das entsprechende Web direkt aufrufen. APIs
A: Bei einem Multi-Modell-Endpunkt handelt es sich um eine Echtzeit-Inferenzoption, die Folgendes bietet: SageMaker Mit Multi-Model-Endpunkte können Sie Tausende von Modellen hinter einem Endpunkt hosten. Multi Model Server
A: SageMaker Real-Time Inference unterstützt verschiedene Implementierungsarchitekturen wie Multi-Model-Endpoints, Multi-Container-Endpoints und serielle Inferenz-Pipelines.
Multi-Model Endpoints (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. MMEfunktioniert am besten, wenn die Modelle eine ähnliche Größe und Latenz haben und zum selben ML-Framework gehören. Diese Endpunkte sind ideal, wenn Sie nicht immer dasselbe Modell aufrufen müssen. Sie können die jeweiligen Modelle dynamisch auf den SageMaker Endpunkt laden, um Ihre Anfrage zu bearbeiten.
Multi-Container-Endpunkte (MCE) — MCE ermöglicht es Kunden, 15 verschiedene Container mit unterschiedlichen ML-Frameworks und -Funktionen ohne Kaltstarts bereitzustellen und dabei nur einen SageMaker Endpunkt zu verwenden. Sie können diese Container direkt aufrufen. MCEeignet sich am besten, wenn Sie alle Modelle im Speicher behalten möchten.
Serielle Inferenz-Pipelines (SIP) — Sie können sie verwendenSIP, um 2—15 Container auf einem einzigen Endpunkt miteinander zu verketten. SIPeignet sich vor allem für die Kombination von Vorverarbeitung und Modellinferenz an einem Endpunkt sowie für Operationen mit geringer Latenz.
Serverlose Inferenz
Die folgenden FAQ Artikel beantworten häufig gestellte Fragen zu Amazon SageMaker Serverless Inference.
A: Modelle mit Amazon SageMaker Serverless Inference bereitstellen 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 RAM Mindestgröße von 1024 MB (1 GB), und die maximale RAM Größe, die Sie wählen können, ist 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. vCPUs
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ählenSLAs. Die Speichergrößenstufen haben unterschiedliche Preise. Weitere Informationen finden Sie auf der SageMaker Amazon-Preisseite
Batch-Transformation
Die folgenden FAQ Artikel beantworten häufig gestellte Fragen zu SageMaker Batch Transform.
A: Für bestimmte Dateiformate wie CSV RecordIO und TFRecord SageMaker kann Ihre Daten in Mini-Batches mit einem Datensatz oder mehreren Datensätzen aufteilen und diese als Payload an Ihren Modellcontainer senden. Wenn der Wert von BatchStrategy istMultiRecord, wird die maximale Anzahl von Datensätzen in jeder Anfrage SageMaker gesendet, bis der Grenzwert erreicht ist. MaxPayloadInMB Wenn der Wert von BatchStrategy istSingleRecord, werden in jeder Anfrage einzelne Datensätze SageMaker gesendet.
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.
A: Wenn Sie den verwenden CreateTransformJobAPI, können Sie die Zeit reduzieren, die zum Abschließen von Batch-Transformationsaufträgen benötigt wird, indem Sie optimale Werte für Parameter wie MaxPayloadInMBMaxConcurrentTransforms, oder verwendenBatchStrategy. Der ideale Wert für MaxConcurrentTransforms entspricht der Anzahl der Compute Worker im Stapeltransformationsauftrag. Wenn Sie die SageMaker Konsole verwenden, können Sie diese optimalen Parameterwerte im Abschnitt Zusätzliche Konfiguration auf der Konfigurationsseite für Batch-Transformationsaufträge angeben. SageMaker 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 Transform unterstützt CSV undJSON.
Asynchrone Inferenz
In den folgenden FAQ Abschnitten werden häufig gestellte allgemeine Fragen zur SageMaker asynchronen Inferenz beantwortet.
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 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 SageMaker unterstützten gehosteten Modellen 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 es die Skalierung Ihrer serverlosen Endgeräte verwaltet. Wenn Sie jedoch keinen Datenverkehr haben, gilt dieselbe Infrastruktur.
