Empaquetez et déployez facilement du ML et des LLM classiques avec Amazon SageMaker, partie 1 : améliorations de PySDK | Services Web Amazon

Amazon Sage Maker est un service entièrement géré qui permet aux développeurs et aux data scientists de créer, former et déployer rapidement et sans effort des modèles d'apprentissage automatique (ML) à n'importe quelle échelle. SageMaker facilite le déploiement de modèles en production directement via des appels API au service. Les modèles sont regroupés dans des conteneurs pour des déploiements robustes et évolutifs. Bien qu'il fournisse divers points d'entrée tels que le SDK SageMaker Python, les SDK AWS, la console SageMaker et Amazon SageMakerStudio notebooks pour simplifier le processus de formation et de déploiement de modèles ML à grande échelle, les clients recherchent toujours de meilleures façons de déployer leurs modèles pour les tests sur les terrains de jeu et d'optimiser les déploiements de production.

Nous lançons deux nouvelles façons de simplifier le processus de packaging et de déploiement de modèles à l'aide de SageMaker.

Dans cet article, nous présentons le nouveau SDK SageMaker Python ModelBuilder expérience, qui vise à minimiser la courbe d'apprentissage pour les nouveaux utilisateurs de SageMaker comme les scientifiques des données, tout en aidant également les ingénieurs MLOps expérimentés à maximiser l'utilisation des services d'hébergement SageMaker. Il réduit la complexité de la configuration et du déploiement initiaux et fournit des conseils sur les meilleures pratiques pour tirer parti de toutes les capacités de SageMaker. Nous fournissons des informations détaillées et des exemples GitHub pour cette nouvelle fonctionnalité SageMaker.

L'autre nouveau lancement consiste à utiliser la nouvelle expérience de déploiement interactif dans SageMaker Studio. Nous en discutons dans la partie 2.

Le déploiement de modèles sur un point de terminaison SageMaker implique une série d'étapes pour préparer le modèle à être hébergé sur un point de terminaison SageMaker. Cela implique d'obtenir les artefacts du modèle dans le format et la structure corrects, de créer un code d'inférence et de spécifier des détails essentiels tels que l'URL de l'image du modèle. Service de stockage simple Amazon (Amazon S3) emplacement des artefacts de modèle, étapes de sérialisation et de désérialisation et éléments nécessaires Gestion des identités et des accès AWS (IAM) pour faciliter les autorisations d'accès appropriées. Ensuite, une configuration de point de terminaison nécessite de déterminer le type d'inférence et de configurer les paramètres respectifs tels que les types d'instances, le nombre et la répartition du trafic entre les variantes de modèle.

Pour aider davantage nos clients lors de l'utilisation de l'hébergement SageMaker, nous avons introduit le nouveau ModelBuilder dans le SDK SageMaker Python, qui apporte les avantages clés suivants lors du déploiement de modèles sur les points de terminaison SageMaker :

• Unifie l’expérience de déploiement sur tous les frameworks – La nouvelle expérience fournit un flux de travail cohérent pour le déploiement de modèles construits à l'aide de différents frameworks tels que PyTorch, TensorFlow et XGBoost. Cela simplifie le processus de déploiement.
• Automatise le déploiement du modèle – Les tâches telles que la sélection des conteneurs appropriés, la capture des dépendances et la gestion de la sérialisation/désérialisation sont automatisées, réduisant ainsi les efforts manuels requis pour le déploiement.
• Fournit une transition en douceur du point de terminaison local au point de terminaison hébergé par SageMaker – Avec un minimum de modifications de code, les modèles peuvent facilement passer des tests locaux au déploiement sur un point de terminaison SageMaker. Les journaux en direct rendent le débogage transparent.

Dans l'ensemble, SageMaker ModelBuilder simplifie et rationalise le processus d'empaquetage de modèles pour l'inférence SageMaker en gérant les détails de bas niveau et fournit des outils pour tester, valider et optimiser les points de terminaison. Cela améliore la productivité des développeurs et réduit les erreurs.

Dans les sections suivantes, nous approfondissons les détails de cette nouvelle fonctionnalité. Nous expliquons également comment déployer des modèles sur l'hébergement SageMaker à l'aide de ModelBuilder, ce qui simplifie le processus. Nous vous présentons ensuite quelques exemples de différents frameworks permettant de déployer à la fois les modèles de ML traditionnels et les modèles de base qui alimentent les cas d'utilisation de l'IA générative.

Apprendre à connaître SageMaker ModelBuilder

Le nouveau système d’ ModelBuilder est une classe Python axée sur la prise de modèles ML construits à l'aide de frameworks, comme XGBoost ou PyTorch, et sur leur conversion en modèles prêts à être déployés sur SageMaker. ModelBuilder fournit une build() fonction, qui génère les artefacts selon le serveur de modèles, et un deploy() fonction à déployer localement ou sur un point de terminaison SageMaker. L'introduction de cette fonctionnalité simplifie l'intégration des modèles avec l'environnement SageMaker, en les optimisant en termes de performances et d'évolutivité. Le diagramme suivant montre comment ModelBuilder travaille à un niveau élevé.

Classe ModelBuilder

Le Générateur de modèles La classe offre différentes options de personnalisation. Cependant, pour déployer le modèle de framework, le générateur de modèle attend simplement le modèle, l'entrée, la sortie et le rôle :

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 ...
)

Générateur de schéma

Le Générateur de schéma La classe vous permet de définir l’entrée et la sortie de votre point de terminaison. Il permet au constructeur de schéma de générer les fonctions de marshaling correspondantes pour sérialiser et désérialiser l'entrée et la sortie. Le fichier de classe suivant fournit toutes les options de personnalisation :

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

Cependant, dans la plupart des cas, seuls des exemples d’entrées et de sorties fonctionneraient. Par exemple:

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

En fournissant des exemples d'entrée et de sortie, SchemaBuilder peut déterminer automatiquement les transformations nécessaires, rendant le processus d'intégration plus simple. Pour les cas d'utilisation plus avancés, il est possible de fournir des fonctions de traduction personnalisées pour l'entrée et la sortie, garantissant ainsi que des structures de données plus complexes peuvent également être gérées efficacement. Nous le démontrons dans les sections suivantes en déployant différents modèles avec différents frameworks utilisant ModelBuilder.

Expérience en mode local

Dans cet exemple, nous utilisons ModelBuilder pour déployer le modèle XGBoost localement. Vous pouvez utiliser Mode pour basculer entre les tests locaux et le déploiement sur un point de terminaison SageMaker. Nous entraînons d'abord le modèle XGBoost (localement ou dans SageMaker) et stockons les artefacts du modèle dans le répertoire de travail :

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

Ensuite, nous créons un objet ModelBuilder en passant l'objet modèle réel, le SchemaBuilder qui utilise l'exemple d'objets d'entrée et de sortie de test (les mêmes entrées et sorties que nous avons utilisées lors de la formation et du test du modèle) pour déduire la sérialisation nécessaire. Notez que nous utilisons Mode.LOCAL_CONTAINER pour spécifier un déploiement local. Après cela, nous appelons le construire fonction pour identifier automatiquement l’image du conteneur de framework pris en charge ainsi que rechercher les dépendances. Voir le code suivant :

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()

Enfin, on peut appeler le deploy fonction dans l'objet modèle, qui fournit également une journalisation en direct pour un débogage plus facile. Vous n'avez pas besoin de spécifier le type ou le nombre d'instances, car le modèle sera déployé localement. Si vous avez fourni ces paramètres, ils seront ignorés. Cette fonction renverra l'objet prédicteur que nous pouvons utiliser pour faire une prédiction avec les données de test :

# 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)

En option, vous pouvez également contrôler le chargement du modèle ainsi que le prétraitement et le post-traitement à l'aide de InferenceSpec. Nous fournissons plus de détails plus loin dans cet article. En utilisant LOCAL_CONTAINER est un excellent moyen de tester votre script localement avant de le déployer sur un point de terminaison SageMaker.

Reportez-vous à modèle-builder-xgboost.ipynb exemple pour tester le déploiement à la fois localement et sur un point de terminaison SageMaker à l'aide ModelBuilder.

Déployer des modèles traditionnels sur les points de terminaison SageMaker

Dans les exemples suivants, nous montrons comment utiliser ModelBuilder pour déployer des modèles ML traditionnels.

Modèles XGBoost

Semblable à la section précédente, vous pouvez déployer un modèle XGBoost sur un point de terminaison SageMaker en modifiant le mode paramètre lors de la création du ModelBuilder objet:

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
)

Notez que lors du déploiement sur les points de terminaison SageMaker, vous devez spécifier le type d'instance et le nombre d'instances lors de l'appel du deploy la fonction.

Reportez-vous à modèle-builder-xgboost.ipynb exemple pour déployer un modèle XGBoost.

Modèles Triton

Vous pouvez utiliser ModelBuilder pour servir des modèles PyTorch sur Serveur d'inférence Triton. Pour cela, vous devez préciser le model_server paramètre comme ModelServer.TRITON, passer un modèle et avoir un SchemaBuilder objet, qui nécessite des exemples d’entrées et de sorties du modèle. ModelBuilder s'occupera du reste pour vous.

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
)

Reportez-vous à modèle-builder-triton.ipynb pour déployer un modèle avec Triton.

Modèles de visages câlins

Dans cet exemple, nous vous montrons comment déployer un modèle de transformateur pré-entraîné fourni par Hugging Face vers SageMaker. Nous voulons utiliser le Hugging Face pipeline pour charger le modèle, nous créons donc une spécification d'inférence personnalisée pour 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()

Nous définissons également l'entrée et la sortie de la charge de travail d'inférence en définissant le SchemaBuilder objet basé sur l'entrée et la sortie du modèle :

schema = SchemaBuilder(value,output)

Ensuite, nous créons le ModelBuilder objet et déployez le modèle sur un point de terminaison SageMaker en suivant la même logique que celle indiquée dans l'autre exemple :

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'
)

Reportez-vous à modèle-builder-huggingface.ipynb pour déployer un modèle de pipeline Hugging Face.

Déployer des modèles de base sur les points de terminaison SageMaker

Dans les exemples suivants, nous montrons comment utiliser ModelBuilder pour déployer des modèles de fondation. Tout comme pour les modèles mentionnés précédemment, tout ce qui est requis est l'ID du modèle.

Visage câlin

Si vous souhaitez déployer un modèle de base à partir de Visage câlin, tout ce que vous avez à faire est de transmettre l'ID de modèle pré-entraîné. Par exemple, l'extrait de code suivant déploie le méta-lama/Llama-2-7b-hf modéliser localement. Vous pouvez changer le mode en Mode.SAGEMAKER_ENDPOINT à déployer sur les points de terminaison SageMaker.

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()

Pour les modèles fermés sur Hugging Face Hub, vous devez demander l'accès via Hugging Face Hub et utiliser la clé associée en la passant comme variable d'environnement. HUGGING_FACE_HUB_TOKEN. Certains modèles Hugging Face peuvent nécessiter de faire confiance au code à distance. Il peut également être défini comme variable d'environnement en utilisant HF_TRUST_REMOTE_CODE. Par défaut, ModelBuilder utilisera une inférence de génération de texte Hugging Face (TGI) comme conteneur sous-jacent pour les modèles Hugging Face. Si vous souhaitez utiliser AWS Large Model Inference (LMI) conteneurs, vous pouvez configurer le model_server paramètre comme ModelServer.DJL_SERVING lorsque vous configurez le ModelBuilder objet.

Une caractéristique intéressante de ModelBuilder est la possibilité d'exécuter le réglage local des paramètres du conteneur lorsque vous utilisez LOCAL_CONTAINER mode. Cette fonctionnalité peut être utilisée en exécutant simplement tuned_model = model.tune().

Reportez-vous à démo-modèle-builder-huggingface-llama2.ipynb pour déployer un modèle Hugging Face Hub.

SageMaker JumpStart

Amazon SageMaker JumpStart propose également un certain nombre de modèles de base pré-entraînés. Tout comme pour le processus de déploiement d'un modèle depuis Hugging Face Hub, l'ID du modèle est requis. Déployer un modèle SageMaker JumpStart sur un point de terminaison SageMaker est aussi simple que d'exécuter le code suivant :

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()

Pour tous les ID de modèle SageMaker JumpStart disponibles, reportez-vous à Algorithmes intégrés avec table modèle pré-formée. Faire référence à modèle-builder-jumpstart-falcon.ipynb pour déployer un modèle SageMaker JumpStart.

Composant d'inférence

ModelBulder vous permet d'utiliser la nouvelle fonctionnalité de composant d'inférence dans SageMaker pour déployer des modèles. Pour plus d'informations sur les composants d'inférence, voir Réduisez les coûts de déploiement de modèles de 50 % en moyenne grâce aux dernières fonctionnalités de SageMaker. Vous pouvez utiliser des composants d'inférence pour le déploiement avec ModelBuilder en précisant endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED dans le deploy() méthode. Vous pouvez également utiliser le tune() méthode, qui récupère le nombre optimal d’accélérateurs et le modifie si nécessaire.

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, ... )

Reportez-vous à composant-d'inférence-model-builder.ipynb pour déployer un modèle en tant que composant d'inférence.

Personnaliser la classe ModelBuilder

Le ModelBuilder la classe vous permet de personnaliser le chargement du modèle à l'aide de InferenceSpec.

De plus, vous pouvez contrôler la sérialisation et la désérialisation de la charge utile et des réponses et personnaliser le prétraitement et le post-traitement à l'aide de CustomPayloadTranslator. De plus, lorsque vous devez étendre nos conteneurs prédéfinis pour le déploiement de modèles sur SageMaker, vous pouvez utiliser ModelBuilder pour gérer le processus d’empaquetage du modèle. Dans la section suivante, nous fournissons plus de détails sur ces capacités.

InférenceSpécification

InférenceSpécification offre une couche supplémentaire de personnalisation. Il vous permet de définir comment le modèle est chargé et comment il gérera les demandes d'inférence entrantes. À travers InferenceSpec, vous pouvez définir des procédures de chargement personnalisées pour vos modèles, en contournant les mécanismes de chargement par défaut. Cette flexibilité est particulièrement bénéfique lorsque vous travaillez avec des modèles non standard ou des pipelines d'inférence personnalisés. La méthode d'invocation peut être personnalisée, vous offrant ainsi la possibilité d'adapter la manière dont le modèle traite les demandes entrantes (prétraitement et post-traitement). Cette personnalisation peut être essentielle pour garantir que le processus d'inférence s'aligne sur les besoins spécifiques du modèle. Voir le code suivant :

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

Le code suivant montre un exemple d'utilisation de cette classe :

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

Traducteur CustomPayload

Lors de l'appel de points de terminaison SageMaker, les données sont envoyées via des charges utiles HTTP avec différents types MIME. Par exemple, une image envoyée au point de terminaison pour inférence doit être convertie en octets côté client et envoyée via la charge utile HTTP au point de terminaison. Lorsque le point de terminaison reçoit la charge utile, il doit désérialiser la chaîne d'octets vers le type de données attendu par le modèle (également appelé désérialisation côté serveur). Une fois la prédiction du modèle terminée, les résultats doivent être sérialisés en octets qui peuvent être renvoyés via la charge utile HTTP à l'utilisateur ou au client. Lorsque le client reçoit les données d'octet de réponse, il doit effectuer une désérialisation côté client pour reconvertir les données d'octets au format de données attendu, tel que JSON. Au minimum, vous devez convertir les données pour ce qui suit (tel que numéroté dans le schéma suivant) :

1. Sérialisation des demandes d'inférence (gérées par le client)
2. Désérialisation de la demande d'inférence (gérée par le serveur ou l'algorithme)
3. Invoquer le modèle par rapport à la charge utile
4. Renvoyer la charge utile de la réponse
5. Sérialisation des réponses d'inférence (gérée par le serveur ou l'algorithme)
6. Désérialisation de la réponse d'inférence (gérée par le client)

Le diagramme suivant montre le processus de sérialisation et de désérialisation pendant le processus d'appel.

Dans l'extrait de code suivant, nous montrons un exemple de CustomPayloadTranslator lorsqu'une personnalisation supplémentaire est nécessaire pour gérer à la fois la sérialisation et la désérialisation côté client et côté serveur, respectivement :

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

Dans le démo-modèle-builder-pytorch.ipynb notebook, nous montrons comment déployer facilement un modèle PyTorch sur un point de terminaison SageMaker à l'aide de ModelBuilder des CustomPayloadTranslator et les terres parsemées de InferenceSpec classe.

Modèle d'étape pour le déploiement

Si vous souhaitez préparer le modèle pour l'inférence ou dans le registre des modèles, vous pouvez utiliser model.create() or model.register(). Le modèle activé est créé sur le service, puis vous pouvez le déployer ultérieurement. Voir le code suivant :

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

Utiliser des conteneurs personnalisés

SageMaker fournit images Docker prédéfinies pour ses algorithmes intégrés et les cadres d'apprentissage profond pris en charge utilisés pour la formation et l'inférence. Si un conteneur SageMaker prédéfini ne répond pas à toutes vos exigences, vous pouvez étendre l'image existante pour répondre à vos besoins. En étendant une image prédéfinie, vous pouvez utiliser les bibliothèques et paramètres d'apprentissage en profondeur inclus sans avoir à créer une image à partir de zéro. Pour plus de détails sur la façon d'étendre les conteneurs prédéfinis, reportez-vous au document SageMaker. ModelBuilder prend en charge les cas d'utilisation lorsque vous apportez vos propres conteneurs étendus à partir de nos conteneurs Docker prédéfinis.

Pour utiliser votre propre image de conteneur dans ce cas, vous devez définir les champs image_uri et les model_server lors de la définition 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"]}
)

Ici le image_uri sera l'ARN de l'image du conteneur qui est stocké dans le fichier de votre compte. Registre des conteneurs élastiques Amazon (Amazon ECR). Un exemple est présenté comme suit :

# 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"

When the image_uri est réglé, pendant le ModelBuilder processus de construction, il ignorera la détection automatique de l’image lorsque l’URI de l’image est fourni. Si model_server n'est pas défini dans ModelBuilder, vous recevrez un message d'erreur de validation, par exemple :

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

Dès la publication de cet article, ModelBuilder prend en charge l'apport de vos propres conteneurs étendus à partir de notre images de conteneurs DLC prédéfinies ou des conteneurs construits avec les serveurs modèles comme Bibliothèque Java profonde (DJL), Inférence de génération de texte (TGI), TorcheServeet une Serveur d'inférence Triton.

Dépendances personnalisées

En cours d'exécution ModelBuilder.build(), par défaut, il capture automatiquement votre environnement Python dans un requirements.txt et installe la même dépendance dans le conteneur. Cependant, il arrive parfois que votre environnement Python local entre en conflit avec l'environnement du conteneur. ModelBuilder fournit un moyen simple de modifier les dépendances capturées pour résoudre ces conflits de dépendances en vous permettant de fournir vos configurations personnalisées dans ModelBuilder. Notez que ceci concerne uniquement TorchServe et Triton avec InferenceSpec. Par exemple, vous pouvez spécifier les dépendances des paramètres d'entrée, qui sont un dictionnaire Python, dans ModelBuilder comme suit :

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()

Nous définissons les champs suivants :

• auto – S'il faut essayer de capturer automatiquement les dépendances dans votre environnement.
• exigences – Une chaîne de chemin vers le vôtre requirements.txt déposer. (Ceci est facultatif.)
• Customiser – Une liste de toutes les autres dépendances personnalisées que vous souhaitez ajouter ou modifier. (Ceci est facultatif.)

Si le même module est spécifié à plusieurs endroits, custom aura la plus haute priorité, alors requirementset une auto aura la priorité la plus basse. Par exemple, disons que lors de la détection automatique, ModelBuilder détecte numpy==1.25Et un requirements.txt un fichier est fourni qui spécifie numpy>=1.24,<1.26. De plus, il existe une dépendance personnalisée : custom = ["numpy==1.26.1"]. Dans ce cas, numpy==1.26.1 sera sélectionné lorsque nous installerons les dépendances dans le conteneur.

Nettoyer

Lorsque vous avez terminé de tester les modèles, il est recommandé de supprimer le point de terminaison pour réduire les coûts s'il n'est plus nécessaire. Vous pouvez suivre le Nettoyer dans chacun des blocs-notes de démonstration ou utilisez le code suivant pour supprimer le modèle et le point de terminaison créés par la démo :

predictor.delete_model()
predictor.delete_endpoint()

Conclusion

La nouvelle fonctionnalité SageMaker ModelBuilder simplifie le processus de déploiement de modèles ML en production sur SageMaker. En gérant de nombreux détails complexes en coulisses, ModelBuilder réduit la courbe d'apprentissage pour les nouveaux utilisateurs et maximise l'utilisation pour les utilisateurs expérimentés. Avec seulement quelques lignes de code, vous pouvez déployer des modèles avec des frameworks intégrés tels que XGBoost, PyTorch, Triton et Hugging Face, ainsi que des modèles fournis par SageMaker JumpStart dans des points de terminaison robustes et évolutifs sur SageMaker.

Nous encourageons tous les utilisateurs de SageMaker à essayer cette nouvelle fonctionnalité en vous référant au Générateur de modèles page de documentation. ModelBuilder est désormais disponible pour tous les utilisateurs de SageMaker sans frais supplémentaires. Profitez de ce flux de travail simplifié pour déployer vos modèles plus rapidement. Nous sommes impatients de savoir comment ModelBuilder accélère le cycle de vie de votre développement de modèles !

Un merci spécial à Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg et Ram Vegiraju.

À propos des auteurs

Mélanie Li, PhD, est un TAM spécialiste principal en IA/ML chez AWS basé à Sydney, en Australie. Elle aide les entreprises clientes à créer des solutions à l'aide d'outils IA/ML de pointe sur AWS et fournit des conseils sur l'architecture et la mise en œuvre de solutions ML avec les meilleures pratiques. Dans ses temps libres, elle aime explorer la nature et passer du temps avec sa famille et ses amis.

Marc Karpe est un architecte ML au sein de l'équipe Amazon SageMaker Service. Il se concentre sur l'aide aux clients pour la conception, le déploiement et la gestion des charges de travail ML à grande échelle. Dans ses temps libres, il aime voyager et explorer de nouveaux endroits.

Sam Edwards, est Cloud Engineer (AI/ML) chez AWS Sydney spécialisé dans l'apprentissage automatique et Amazon SageMaker. Il a pour passion d'aider les clients à résoudre les problèmes liés aux flux de travail d'apprentissage automatique et de créer de nouvelles solutions pour eux. En dehors du travail, il aime pratiquer des sports de raquette et voyager.

Raghu Ramesha est un architecte senior de solutions ML au sein de l'équipe Amazon SageMaker Service. Il s'efforce d'aider les clients à créer, déployer et migrer des charges de travail de production ML vers SageMaker à grande échelle. Il se spécialise dans les domaines de l'apprentissage automatique, de l'IA et de la vision par ordinateur, et est titulaire d'une maîtrise en informatique de l'UT Dallas. Dans ses temps libres, il aime voyager et photographier.

Shiva Raaj Kotini travaille en tant que chef de produit principal dans le portefeuille de produits d'inférence Amazon SageMaker. Il se concentre sur le déploiement de modèles, le réglage des performances et l'optimisation dans SageMaker pour l'inférence.

Mohan Ghandi est ingénieur logiciel senior chez AWS. Il travaille chez AWS depuis 10 ans et a travaillé sur divers services AWS tels que EMR, EFA et RDS. Actuellement, il se concentre sur l'amélioration de l'expérience d'inférence SageMaker. Dans ses temps libres, il aime faire de la randonnée et des marathons.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/