Einfaches Verpacken und Bereitstellen klassischer ML und LLMs mit Amazon SageMaker, Teil 1: PySDK-Verbesserungen | Amazon Web Services

Amazon Sage Maker ist ein vollständig verwalteter Dienst, der es Entwicklern und Datenwissenschaftlern ermöglicht, schnell und mühelos Modelle für maschinelles Lernen (ML) in jeder Größenordnung zu erstellen, zu trainieren und bereitzustellen. SageMaker erleichtert die direkte Bereitstellung von Modellen in der Produktion über API-Aufrufe an den Dienst. Modelle werden für robuste und skalierbare Bereitstellungen in Container gepackt. Obwohl es verschiedene Einstiegspunkte wie das SageMaker Python SDK, AWS SDKs, die SageMaker-Konsole usw. bietet Amazon SageMaker-Studio Während Notebooks den Prozess der Schulung und Bereitstellung von ML-Modellen in großem Maßstab vereinfachen, suchen Kunden immer noch nach besseren Möglichkeiten, ihre Modelle für Spielplatztests bereitzustellen und Produktionsbereitstellungen zu optimieren.

Wir führen zwei neue Möglichkeiten ein, um den Prozess des Packens und Bereitstellens von Modellen mit SageMaker zu vereinfachen.

In diesem Beitrag stellen wir das neue SageMaker Python SDK vor ModelBuilder Erfahrung, die darauf abzielt, die Lernkurve für neue SageMaker-Benutzer wie Datenwissenschaftler zu minimieren und gleichzeitig erfahrenen MLOps-Ingenieuren dabei zu helfen, die Nutzung der SageMaker-Hosting-Dienste zu maximieren. Es reduziert die Komplexität der anfänglichen Einrichtung und Bereitstellung und bietet Anleitungen zu Best Practices für die Nutzung aller Funktionen von SageMaker. Wir stellen detaillierte Informationen und GitHub-Beispiele für diese neue SageMaker-Funktion bereit.

Die andere Neuerung besteht darin, die neue interaktive Bereitstellungserfahrung in SageMaker Studio zu nutzen. Wir besprechen dies in Teil 2.

Die Bereitstellung von Modellen auf einem SageMaker-Endpunkt erfordert eine Reihe von Schritten, um das Modell für das Hosting auf einem SageMaker-Endpunkt vorzubereiten. Dazu gehört es, die Modellartefakte in das richtige Format und die richtige Struktur zu bringen, Inferenzcode zu erstellen und wesentliche Details wie die URL des Modellbilds anzugeben. Amazon Simple Storage-Service (Amazon S3) Standort von Modellartefakten, Serialisierungs- und Deserialisierungsschritte und erforderlich AWS Identity and Access Management and (IAM)-Rollen, um entsprechende Zugriffsberechtigungen zu ermöglichen. Anschließend erfordert eine Endpunktkonfiguration die Bestimmung des Inferenztyps und die Konfiguration entsprechender Parameter wie Instanztypen, Anzahl und Verkehrsverteilung zwischen Modellvarianten.

Um unsere Kunden bei der Nutzung des SageMaker-Hostings weiter zu unterstützen, haben wir das Neue eingeführt ModelBuilder Klasse im SageMaker Python SDK, die die folgenden Hauptvorteile bei der Bereitstellung von Modellen auf SageMaker-Endpunkten bietet:

• Vereinheitlicht die Bereitstellungserfahrung über Frameworks hinweg – Die neue Erfahrung bietet einen konsistenten Workflow für die Bereitstellung von Modellen, die mit verschiedenen Frameworks wie PyTorch, TensorFlow und XGBoost erstellt wurden. Dies vereinfacht den Bereitstellungsprozess.
• Automatisiert die Modellbereitstellung – Aufgaben wie die Auswahl geeigneter Container, die Erfassung von Abhängigkeiten und die Handhabung der Serialisierung/Deserialisierung werden automatisiert, wodurch der manuelle Aufwand für die Bereitstellung reduziert wird.
• Bietet einen reibungslosen Übergang vom lokalen zum von SageMaker gehosteten Endpunkt – Mit minimalen Codeänderungen können Modelle problemlos vom lokalen Testen auf die Bereitstellung auf einem SageMaker-Endpunkt umgestellt werden. Live-Protokolle ermöglichen ein nahtloses Debuggen.

Insgesamt SageMaker ModelBuilder Vereinfacht und rationalisiert den Modellpaketierungsprozess für die SageMaker-Inferenz durch die Verarbeitung von Details auf niedriger Ebene und stellt Tools zum Testen, Validieren und Optimieren von Endpunkten bereit. Dies verbessert die Entwicklerproduktivität und reduziert Fehler.

In den folgenden Abschnitten gehen wir näher auf die Details dieser neuen Funktion ein. Wir besprechen auch, wie Sie Modelle mithilfe von SageMaker-Hosting bereitstellen ModelBuilder, was den Prozess vereinfacht. Anschließend führen wir Sie durch einige Beispiele für verschiedene Frameworks, um sowohl traditionelle ML-Modelle als auch die Basismodelle für generative KI-Anwendungsfälle bereitzustellen.

Lernen Sie SageMaker ModelBuilder kennen

The new ModelBuilder ist eine Python-Klasse, die sich darauf konzentriert, ML-Modelle, die mit Frameworks wie XGBoost oder PyTorch erstellt wurden, in Modelle umzuwandeln, die für die Bereitstellung auf SageMaker bereit sind. ModelBuilder stellt ein build() Funktion, die die Artefakte gemäß dem Modellserver generiert, und a deploy() Funktion zur lokalen Bereitstellung oder auf einem SageMaker-Endpunkt. Die Einführung dieser Funktion vereinfacht die Integration von Modellen in die SageMaker-Umgebung und optimiert sie hinsichtlich Leistung und Skalierbarkeit. Das folgende Diagramm zeigt, wie ModelBuilder funktioniert auf hohem Niveau.

ModelBuilder-Klasse

Das ModelBuilder Klasse bieten verschiedene Optionen zur Anpassung. Um das Framework-Modell bereitzustellen, erwartet der Modellersteller jedoch lediglich das Modell, die Eingabe, die Ausgabe und die Rolle:

class ModelBuilder( model, # model id or model object role_arn, # IAM role schema_builder, # defines the input and output mode, # select between local deployment and depoy to SageMaker Endpoints ...
)

SchemaBuilder

Das SchemaBuilder Mit der Klasse können Sie die Eingabe und Ausgabe für Ihren Endpunkt definieren. Es ermöglicht dem Schema-Builder, die entsprechenden Marshalling-Funktionen zum Serialisieren und Deserialisieren der Ein- und Ausgabe zu generieren. Die folgende Klassendatei bietet alle Optionen zur Anpassung:

class SchemaBuilder( sample_input: Any, sample_output: Any, input_translator: CustomPayloadTranslator = None, output_translator: CustomPayloadTranslator = None
)

In den meisten Fällen würde jedoch nur eine Beispieleingabe und -ausgabe funktionieren. Zum Beispiel:

input = "How is the demo going?"
output = "Comment la démo va-t-elle?"
schema = SchemaBuilder(input, output)

Durch die Bereitstellung von Beispieleingaben und -ausgaben SchemaBuilder kann die notwendigen Transformationen automatisch ermitteln und so den Integrationsprozess vereinfachen. Für fortgeschrittenere Anwendungsfälle besteht die Flexibilität, benutzerdefinierte Übersetzungsfunktionen sowohl für die Eingabe als auch für die Ausgabe bereitzustellen, um sicherzustellen, dass auch komplexere Datenstrukturen effizient verarbeitet werden können. Wir demonstrieren dies in den folgenden Abschnitten, indem wir verschiedene Modelle mit verschiedenen Frameworks bereitstellen ModelBuilder.

Erfahrung im lokalen Modus

In diesem Beispiel verwenden wir ModelBuilder um das XGBoost-Modell lokal bereitzustellen. Sie können den Modus verwenden, um zwischen lokalem Testen und der Bereitstellung auf einem SageMaker-Endpunkt zu wechseln. Wir trainieren zunächst das XGBoost-Modell (lokal oder in SageMaker) und speichern die Modellartefakte im Arbeitsverzeichnis:

# Train the model
model = XGBClassifier()
model.fit(X_train, y_train)
model.save_model(model_dir + "/my_model.xgb")

Dann erstellen wir ein ModelBuilder-Objekt, indem wir das eigentliche Modellobjekt übergeben SchemaBuilder Dabei werden die Eingabe- und Ausgabeobjekte des Beispieltests (die gleichen Eingabe- und Ausgabeobjekte, die wir beim Training und Testen des Modells verwendet haben) verwendet, um die erforderliche Serialisierung abzuleiten. Beachten Sie, dass wir verwenden Mode.LOCAL_CONTAINER um eine lokale Bereitstellung anzugeben. Danach rufen wir die an bauen Funktion zur automatischen Identifizierung des unterstützten Framework-Container-Images sowie zur Suche nach Abhängigkeiten. Siehe den folgenden Code:

model_builder_local = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, mode=Mode.LOCAL_CONTAINER
)
xgb_local_builder = model_builder_local.build()

Endlich können wir die anrufen deploy Funktion im Modellobjekt, die auch Live-Protokollierung für einfacheres Debuggen bereitstellt. Sie müssen weder den Instanztyp noch die Anzahl angeben, da das Modell lokal bereitgestellt wird. Wenn Sie diese Parameter angegeben haben, werden sie ignoriert. Diese Funktion gibt das Prädiktorobjekt zurück, das wir verwenden können, um eine Vorhersage mit den Testdaten zu treffen:

# note: all the serialization and deserialization is handled by the model builder.
predictor_local = xgb_local_builder.deploy(
# instance_type='ml.c5.xlarge',
# initial_instance_count=1
) # Make prediction for test data. predictor_local.predict(X_test)

Optional können Sie auch das Laden des Modells sowie die Vor- und Nachbearbeitung steuern InferenceSpec. Weitere Einzelheiten erfahren Sie später in diesem Beitrag. Benutzen LOCAL_CONTAINER ist eine großartige Möglichkeit, Ihr Skript lokal zu testen, bevor es auf einem SageMaker-Endpunkt bereitgestellt wird.

Siehe die model-builder-xgboost.ipynb Beispiel zum Testen der Bereitstellung sowohl lokal als auch auf einem SageMaker-Endpunkt mit ModelBuilder.

Stellen Sie herkömmliche Modelle auf SageMaker-Endpunkten bereit

In den folgenden Beispielen zeigen wir die Verwendung ModelBuilder um traditionelle ML-Modelle einzusetzen.

XGBoost-Modelle

Ähnlich wie im vorherigen Abschnitt können Sie ein XGBoost-Modell auf einem SageMaker-Endpunkt bereitstellen, indem Sie die ändern mode Parameter beim Erstellen der ModelBuilder Objekt:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, mode=Mode.SAGEMAKER_ENDPOINT
)
xgb_builder = model_builder.build()
predictor = xgb_builder.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1
)

Beachten Sie, dass Sie bei der Bereitstellung auf SageMaker-Endpunkten beim Aufrufen den Instanztyp und die Instanzanzahl angeben müssen deploy Funktion.

Siehe die model-builder-xgboost.ipynb Beispiel zum Bereitstellen eines XGBoost-Modells.

Triton-Modelle

Sie können verwenden ModelBuilder um PyTorch-Modelle bereitzustellen Triton Inferenzserver. Dazu müssen Sie angeben model_server Parameter als ModelServer.TRITON, übergeben Sie ein Modell und haben Sie ein SchemaBuilder Objekt, das Beispieleingaben und -ausgaben vom Modell erfordert. ModelBuilder erledigt den Rest für Sie.

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, model_server=ModelServer.TRITON, mode=Mode.SAGEMAKER_ENDPOINT
) triton_builder = model_builder.build() predictor = triton_builder.deploy( instance_type='ml.g4dn.xlarge', initial_instance_count=1
)

Beziehen auf model-builder-triton.ipynb um ein Modell mit Triton bereitzustellen.

Umarmende Gesichtsmodelle

In diesem Beispiel zeigen wir Ihnen, wie Sie ein vorab trainiertes Transformer-Modell von Hugging Face für SageMaker bereitstellen. Wir wollen das Hugging Face verwenden pipeline Um das Modell zu laden, erstellen wir eine benutzerdefinierte Inferenzspezifikation für ModelBuilder:

# custom inference spec with hugging face pipeline
class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return pipeline("translation_en_to_fr", model="t5-small") def invoke(self, input, model): return model(input) inf_spec = MyInferenceSpec()

Wir definieren auch die Eingabe und Ausgabe der Inferenzarbeitslast, indem wir die definieren SchemaBuilder Objekt basierend auf der Modelleingabe und -ausgabe:

schema = SchemaBuilder(value,output)

Dann erstellen wir die ModelBuilder Objekt und stellen Sie das Modell auf einem SageMaker-Endpunkt bereit, indem Sie der gleichen Logik folgen, wie im anderen Beispiel gezeigt:

builder = ModelBuilder( inference_spec=inf_spec, mode=Mode.SAGEMAKER_ENDPOINT, # you can change it to Mode.LOCAL_CONTAINER for local testing schema_builder=schema, image_uri=image,
)
model = builder.build( role_arn=execution_role, sagemaker_session=sagemaker_session,
)
predictor = model.deploy( initial_instance_count=1, instance_type='ml.g5.2xlarge'
)

Beziehen auf model-builder-huggingface.ipynb um ein Hugging Face-Pipelinemodell bereitzustellen.

Stellen Sie Basismodelle auf SageMaker-Endpunkten bereit

In den folgenden Beispielen zeigen wir die Verwendung ModelBuilder Grundlagenmodelle einzusetzen. Genau wie bei den zuvor genannten Modellen ist lediglich die Modell-ID erforderlich.

Face Hub umarmen

Wenn Sie ein Foundation-Modell bereitstellen möchten von Face Hub umarmen, Sie müssen lediglich die vorab trainierte Modell-ID übergeben. Das folgende Code-Snippet stellt beispielsweise Folgendes bereit: Meta-Lama/Lama-2-7b-hf Vor Ort modellieren. Sie können den Modus auf ändern Mode.SAGEMAKER_ENDPOINT zur Bereitstellung auf SageMaker-Endpunkten.

model_builder = ModelBuilder( model="meta-llama/Llama-2-7b-hf", schema_builder=SchemaBuilder(sample_input, sample_output), model_path="/home/ec2-user/SageMaker/LoadTestResources/meta-llama2-7b", #local path where artifacts will be saved mode=Mode.LOCAL_CONTAINER, env_vars={ # Llama 2 is a gated model and requires a Hugging Face Hub token. "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>" }
)
model = model_builder.build()
local_predictor = model.deploy()

Für geschlossene Modelle auf Hugging Face Hub müssen Sie den Zugriff über Hugging Face Hub anfordern und den zugehörigen Schlüssel verwenden, indem Sie ihn als Umgebungsvariable übergeben HUGGING_FACE_HUB_TOKEN. Einige Hugging Face-Modelle erfordern möglicherweise einen vertrauenswürdigen Remote-Code. Es kann auch als Umgebungsvariable festgelegt werden HF_TRUST_REMOTE_CODE. Standardmäßig, ModelBuilder wird eine Inferenz zur Generierung von Hugging Face-Text verwenden (TGI)-Container als zugrundeliegender Container für Hugging-Face-Modelle. Wenn Sie AWS Large Model Inference verwenden möchten (LMI)-Container, können Sie das einrichten model_server Parameter als ModelServer.DJL_SERVING wenn Sie das konfigurieren ModelBuilder Objekt.

Ein nettes Feature von ModelBuilder ist die Möglichkeit, bei der Verwendung eine lokale Optimierung der Containerparameter durchzuführen LOCAL_CONTAINER Modus. Diese Funktion kann durch einfaches Ausführen genutzt werden tuned_model = model.tune().

Beziehen auf demo-model-builder-huggingface-llama2.ipynb um ein Hugging Face Hub-Modell bereitzustellen.

SageMaker-JumpStart

Amazon SageMaker-JumpStart bietet auch eine Reihe vorgefertigter Grundlagenmodelle an. Genau wie beim Bereitstellen eines Modells über Hugging Face Hub ist die Modell-ID erforderlich. Die Bereitstellung eines SageMaker JumpStart-Modells auf einem SageMaker-Endpunkt ist so einfach wie das Ausführen des folgenden Codes:

model_builder = ModelBuilder( model="huggingface-llm-falcon-7b-bf16", schema_builder=SchemaBuilder(sample_input, sample_output), role_arn=execution_role
) sm_ep_model = model_builder.build() predictor = sm_ep_model.deploy()

Alle verfügbaren SageMaker JumpStart-Modell-IDs finden Sie unter Eingebaute Algorithmen mit vortrainierter Modelltabelle. Beziehen auf model-builder-jumpstart-falcon.ipynb um ein SageMaker JumpStart-Modell bereitzustellen.

Inferenzkomponente

ModelBulder ermöglicht Ihnen die Verwendung der neuen Inferenzkomponentenfunktion in SageMaker zum Bereitstellen von Modellen. Weitere Informationen zu Inferenzkomponenten finden Sie unter Reduzieren Sie die Kosten für die Modellbereitstellung um durchschnittlich 50 % mit den neuesten Funktionen von SageMaker. Sie können Inferenzkomponenten für die Bereitstellung verwenden ModelBuilder durch Angabe endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED der deploy() Methode. Sie können auch die verwenden tune() Methode, die die optimale Anzahl an Beschleunigern abruft, und ändern Sie sie bei Bedarf.

resource_requirements = ResourceRequirements( requests={ "num_accelerators": 4, "memory": 1024, "copies": 1, }, limits={},
) goldfinch_predictor_2 = model_2.deploy( mode=Mode.SAGEMAKER_ENDPOINT, endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED, ... )

Beziehen auf model-builder-inference-component.ipynb um ein Modell als Inferenzkomponente bereitzustellen.

Passen Sie die ModelBuilder-Klasse an

Das ModelBuilder Mit der Klasse können Sie das Laden von Modellen anpassen InferenceSpec.

Darüber hinaus können Sie die Serialisierung und Deserialisierung von Nutzdaten und Antworten steuern und die Vor- und Nachverarbeitung anpassen CustomPayloadTranslator. Darüber hinaus können Sie unsere vorgefertigten Container für die Modellbereitstellung auf SageMaker erweitern ModelBuilder den Modellverpackungsprozess abzuwickeln. Im folgenden Abschnitt stellen wir weitere Einzelheiten zu diesen Funktionen bereit.

InferenceSpec

InferenceSpec bietet eine zusätzliche Ebene der Anpassung. Sie können damit definieren, wie das Modell geladen wird und wie es eingehende Inferenzanfragen verarbeitet. Durch InferenceSpeckönnen Sie benutzerdefinierte Ladeprozeduren für Ihre Modelle definieren und dabei die Standardlademechanismen umgehen. Diese Flexibilität ist besonders vorteilhaft, wenn mit nicht standardmäßigen Modellen oder benutzerdefinierten Inferenzpipelines gearbeitet wird. Die Aufrufmethode kann angepasst werden, sodass Sie anpassen können, wie das Modell eingehende Anforderungen verarbeitet (Vorverarbeitung und Nachverarbeitung). Diese Anpassung kann von wesentlicher Bedeutung sein, um sicherzustellen, dass der Inferenzprozess den spezifischen Anforderungen des Modells entspricht. Siehe den folgenden Code:

class InferenceSpec(abc.ABC): @abc.abstractmethod def load(self, model_dir: str): pass @abc.abstractmethod def invoke(self, input_object: object, model: object): pass

Der folgende Code zeigt ein Beispiel für die Verwendung dieser Klasse:

class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return // model object def invoke(self, input, model): return model(input)

CustomPayloadTranslator

Beim Aufruf von SageMaker-Endpunkten werden die Daten über HTTP-Nutzlasten mit unterschiedlichen MIME-Typen gesendet. Beispielsweise muss ein Bild, das zur Inferenz an den Endpunkt gesendet wird, auf der Clientseite in Bytes konvertiert und über die HTTP-Nutzlast an den Endpunkt gesendet werden. Wenn der Endpunkt die Nutzlast empfängt, muss er die Bytezeichenfolge wieder in den Datentyp deserialisieren, der vom Modell erwartet wird (auch bekannt als serverseitige Deserialisierung). Nachdem das Modell die Vorhersage abgeschlossen hat, müssen die Ergebnisse in Bytes serialisiert werden, die über die HTTP-Nutzlast an den Benutzer oder Client zurückgesendet werden können. Wenn der Client die Antwortbyte-Daten empfängt, muss er eine clientseitige Deserialisierung durchführen, um die Bytedaten zurück in das erwartete Datenformat, z. B. JSON, zu konvertieren. Zumindest Sie müssen die Daten für Folgendes konvertieren (wie im folgenden Diagramm nummeriert):

1. Serialisierung der Inferenzanforderung (wird vom Client durchgeführt)
2. Deserialisierung der Inferenzanforderung (vom Server oder Algorithmus verarbeitet)
3. Aufrufen des Modells gegen die Nutzlast
4. Antwortnutzlast zurücksenden
5. Serialisierung der Inferenzantwort (wird vom Server oder Algorithmus verwaltet)
6. Deserialisierung der Inferenzantwort (wird vom Client durchgeführt)

Das folgende Diagramm zeigt den Prozess der Serialisierung und Deserialisierung während des Aufrufprozesses.

Im folgenden Codeausschnitt zeigen wir ein Beispiel dafür CustomPayloadTranslator wenn zusätzliche Anpassungen erforderlich sind, um sowohl die Serialisierung als auch die Deserialisierung auf der Client- bzw. Serverseite zu handhaben:

from sagemaker.serve import CustomPayloadTranslator # request translator
class MyRequestTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on client side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the input payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on server side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object # response translator class MyResponseTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on server side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the response payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on client side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object

Im demo-model-builder-pytorch.ipynb Notebook zeigen wir, wie Sie mit einfach ein PyTorch-Modell auf einem SageMaker-Endpunkt bereitstellen können ModelBuilder an. Nach der Installation können Sie HEIC-Dateien mit der CustomPayloadTranslator und für InferenceSpec Klasse.

Stufenmodell für die Bereitstellung

Wenn Sie das Modell zur Inferenz oder in der Modellregistrierung bereitstellen möchten, können Sie Folgendes verwenden model.create() or model.register(). Das aktivierte Modell wird im Dienst erstellt und kann später bereitgestellt werden. Siehe den folgenden Code:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, )
deployable_model = model_builder.build() deployable_model.create() # deployable_model.register() for model registry

Verwenden Sie benutzerdefinierte Container

SageMaker bietet vorgefertigte Docker-Images für seine integrierten Algorithmen und die unterstützten Deep-Learning-Frameworks, die für Training und Inferenz verwendet werden. Wenn ein vorgefertigter SageMaker-Container nicht alle Ihre Anforderungen erfüllt, können Sie das vorhandene Image entsprechend Ihren Anforderungen erweitern. Durch die Erweiterung eines vorgefertigten Images können Sie die enthaltenen Deep-Learning-Bibliotheken und -Einstellungen nutzen, ohne ein Image von Grund auf erstellen zu müssen. Weitere Informationen zum Erweitern der vorgefertigten Container finden Sie im SageMaker-Dokument. ModelBuilder unterstützt Anwendungsfälle beim Mitbringen eigener Container, die aus unseren vorgefertigten Docker-Containern erweitert werden.

Um in diesem Fall Ihr eigenes Container-Image zu verwenden, müssen Sie die Felder festlegen image_uri und model_server beim Definieren ModelBuilder:

model_builder = ModelBuilder( model=model, # Pass in the actual model object. its "predict" method will be invoked in the endpoint. schema_builder=SchemaBuilder(X_test, y_pred), # Pass in a "SchemaBuilder" which will use the sample test input and output objects to infer the serialization needed. role_arn=execution_role, image_uri=image_uri, # REQUIRED FOR BYOC: Passing in image hosted in personal ECR Repo model_server=ModelServer.TORCHSERVE, # REQUIRED FOR BYOC: Passing in model server of choice mode=Mode.SAGEMAKER_ENDPOINT, dependencies={"auto": True, "custom": ["protobuf==3.20.2"]}
)

Hier, die image_uri ist der Container-Image-ARN, der in Ihrem Konto gespeichert ist Amazon Elastic Container-Registrierung (Amazon ECR)-Repository. Ein Beispiel wird wie folgt dargestellt:

# Pulled the xgboost:1.7-1 DLC and pushed to personal ECR repo
image_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

Wenn das image_uri eingestellt ist, während der ModelBuilder Beim Erstellungsprozess wird die automatische Erkennung des Bildes übersprungen, da der Bild-URI bereitgestellt wird. Wenn model_server nicht in ModelBuilder festgelegt ist, erhalten Sie eine Validierungsfehlermeldung, zum Beispiel:

ValueError: Model_server must be set when image_uri is set. Supported model servers: {<ModelServer.TRITON: 5>, <ModelServer.DJL_SERVING: 4>, <ModelServer.TORCHSERVE: 1>}

Zum Zeitpunkt der Veröffentlichung dieses Beitrags ModelBuilder unterstützt das Mitbringen eigener Container, die von unserem erweitert werden vorgefertigte DLC-Container-Images oder Container, die mit den Modellservern wie erstellt wurden Deep Java-Bibliothek (DJL), Textgenerierungsinferenz (TGI), FackelServe und Triton-Inferenzserver.

Benutzerdefinierte Abhängigkeiten

Beim Laufen ModelBuilder.build(), standardmäßig erfasst es automatisch Ihre Python-Umgebung in einem requirements.txt Datei und installiert die gleiche Abhängigkeit im Container. Manchmal kommt es jedoch zu Konflikten zwischen Ihrer lokalen Python-Umgebung und der Umgebung im Container. ModelBuilder bietet Ihnen eine einfache Möglichkeit, die erfassten Abhängigkeiten zu ändern, um solche Abhängigkeitskonflikte zu beheben, indem Sie Ihre benutzerdefinierten Konfigurationen bereitstellen können ModelBuilder. Beachten Sie, dass dies nur für TorchServe und Triton mit gilt InferenceSpec. Beispielsweise können Sie die Abhängigkeiten der Eingabeparameter, bei denen es sich um ein Python-Wörterbuch handelt, in ModelBuilder wie folgt angeben:

dependency_config = { "auto" = True, "requirements" = "/path/to/your/requirements.txt" "custom" = ["module>=1.2.3,<1.5", "boto3==1.16.*", "some_module@http://some/url"]
} ModelBuilder( # Other params dependencies=dependency_config,
).build()

Wir definieren die folgenden Felder:

• Auto – Ob versucht werden soll, die Abhängigkeiten in Ihrer Umgebung automatisch zu erfassen.
• Anforderungen – Eine Spur des Weges zu Deinem eigenen requirements.txt Datei. (Dies ist optional.)
• Original – Eine Liste aller anderen benutzerdefinierten Abhängigkeiten, die Sie hinzufügen oder ändern möchten. (Dies ist optional.)

Wenn dasselbe Modul an mehreren Stellen angegeben ist, custom wird dann höchste Priorität haben requirements und auto wird die niedrigste Priorität haben. Nehmen wir zum Beispiel an, dass während der automatischen Erkennung ModelBuilder erkennt numpy==1.25Und eine requirements.txt Es wird eine Datei bereitgestellt, die Folgendes angibt numpy>=1.24,<1.26. Darüber hinaus gibt es eine benutzerdefinierte Abhängigkeit: custom = ["numpy==1.26.1"]. In diesem Fall, numpy==1.26.1 wird ausgewählt, wenn wir Abhängigkeiten im Container installieren.

Aufräumen

Wenn Sie mit dem Testen der Modelle fertig sind, löschen Sie als Best Practice den Endpunkt, um Kosten zu sparen, wenn der Endpunkt nicht mehr benötigt wird. Sie können dem folgen Aufräumen Abschnitt in jedem der Demo-Notebooks oder verwenden Sie den folgenden Code, um das von der Demo erstellte Modell und den Endpunkt zu löschen:

predictor.delete_model()
predictor.delete_endpoint()

Zusammenfassung

Die neue SageMaker ModelBuilder-Funktion vereinfacht den Prozess der Bereitstellung von ML-Modellen in der Produktion auf SageMaker. Durch die Handhabung vieler komplexer Details im Hintergrund reduziert ModelBuilder die Lernkurve für neue Benutzer und maximiert die Nutzung für erfahrene Benutzer. Mit nur wenigen Codezeilen können Sie Modelle mit integrierten Frameworks wie XGBoost, PyTorch, Triton und Hugging Face sowie von SageMaker JumpStart bereitgestellte Modelle in robusten, skalierbaren Endpunkten auf SageMaker bereitstellen.

Wir empfehlen allen SageMaker-Benutzern, diese neue Funktion auszuprobieren ModelBuilder Dokumentationsseite. ModelBuilder steht jetzt allen SageMaker-Benutzern ohne zusätzliche Kosten zur Verfügung. Nutzen Sie diesen vereinfachten Workflow, um Ihre Modelle schneller bereitzustellen. Wir freuen uns darauf zu hören, wie ModelBuilder Ihren Modellentwicklungslebenszyklus beschleunigt!

Besonderer Dank geht an Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg und Ram Vegiraju.

Über die Autoren

Melanie Li, PhD, ist Senior AI/ML Specialist TAM bei AWS mit Sitz in Sydney, Australien. Sie unterstützt Unternehmenskunden beim Aufbau von Lösungen mit modernsten KI/ML-Tools auf AWS und bietet Anleitungen zur Architektur und Implementierung von ML-Lösungen mit Best Practices. In ihrer Freizeit erkundet sie gerne die Natur und verbringt Zeit mit Familie und Freunden.

Markus Karp ist ein ML-Architekt im Amazon SageMaker Service-Team. 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.

Sam Edwards, ist Cloud Engineer (AI/ML) bei AWS Sydney, spezialisiert auf maschinelles Lernen und Amazon SageMaker. Es ist ihm eine Leidenschaft, Kunden bei der Lösung von Problemen im Zusammenhang mit maschinellen Lernabläufen zu unterstützen und neue Lösungen für sie zu entwickeln. Außerhalb der Arbeit treibt er gerne Schlägersport und reist gerne.

Raghu Ramesha ist Senior ML Solutions Architect im Amazon SageMaker Service-Team. Er konzentriert sich darauf, Kunden bei der Erstellung, Bereitstellung und Migration von ML-Produktions-Workloads in großem Maßstab zu SageMaker zu unterstützen. Er ist auf die Bereiche maschinelles Lernen, KI und Computer Vision spezialisiert und verfügt über einen Master-Abschluss in Informatik von der UT Dallas. In seiner Freizeit reist und fotografiert er gerne.

Shiva Raaj Kotini arbeitet als Hauptproduktmanager im Amazon SageMaker-Inferenzproduktportfolio. Sein Schwerpunkt liegt auf der Modellbereitstellung, Leistungsoptimierung und Optimierung in SageMaker für Inferenzzwecke.

Mohan Gandhi ist Senior Software Engineer bei AWS. Er ist seit 10 Jahren bei AWS und hat an verschiedenen AWS-Services wie EMR, EFA und RDS gearbeitet. Derzeit konzentriert er sich auf die Verbesserung der SageMaker Inference Experience. In seiner Freizeit geht er gerne wandern und Marathons.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/