Créer un flux de travail MLOps entre comptes à l'aide du registre de modèles Amazon SageMaker

Un pipeline CI/CD bien conçu est essentiel pour faire évoluer efficacement tout workflow de développement logiciel. Lors de la conception des pipelines CI/CD de production, AWS recommande de tirer parti de plusieurs comptes pour isoler les ressources, contenir les menaces de sécurité et simplifier la facturation - et les pipelines de science des données ne sont pas différents. Chez AWS, nous continuons d'innover pour simplifier le workflow MLOps.

Dans cet article, nous discutons de certaines des nouvelles fonctionnalités intercomptes pour Amazon Sage Maker qui vous permettent de mieux partager et gérer les groupes de modèles ainsi que de gérer les versions de modèles. Pour un exemple de structure de compte à suivre meilleures pratiques de l'unité organisationnelle pour héberger des modèles à l'aide de points de terminaison SageMaker sur plusieurs comptes, reportez-vous à Orchestrateur de charge de travail MLOps.

Vue d'ensemble de la solution

Le schéma suivant illustre notre architecture de registre de modèle partagé.

Quelques éléments à noter dans l'architecture précédente :

Les étapes suivantes correspondent au diagramme :

1. Un scientifique des données enregistre un modèle du compte de science des données dans le registre de modèles SageMaker des services partagés dans un PendingManualApproval Etat. L'artefact de modèle est créé dans le compte de services partagés Service de stockage simple Amazon (Amazon S3) seau.
2. Lors de l'enregistrement d'une nouvelle version de modèle, une personne habilitée à approuver le modèle en fonction des métriques doit approuver ou rejeter le modèle.
3. Une fois le modèle approuvé, le pipeline CI/CD dans le compte de déploiement est déclenché pour déployer les détails du modèle mis à jour dans le compte QA et mettez à jour l'étape en tant que QA.
4. Une fois le processus de test réussi, vous pouvez soit choisir d'avoir une étape d'approbation manuelle dans votre processus CI/CD, soit demander à votre pipeline CI/CD de déployer directement le modèle en production et de mettre à jour l'étape en tant que Prod.
5. L'environnement de production fait référence au modèle et au code approuvés, peut-être en faisant une Test A/B en production. En cas d'audit ou de problème avec le modèle, vous pouvez utiliser Suivi de la lignée Amazon SageMaker ML. Il crée et stocke des informations sur les étapes d'un flux de travail d'apprentissage automatique (ML), de la préparation des données au déploiement du modèle. Grâce aux informations de suivi, vous pouvez reproduire les étapes du flux de travail, suivre la lignée du modèle et du jeu de données, et établir des normes de gouvernance et d'audit du modèle.

Tout au long du processus, le registre de modèles partagé conserve les anciennes versions de modèles. Cela permet à l'équipe d'annuler les modifications, ou même d'héberger variantes de fabrication.

Pré-requis

Assurez-vous d'avoir les prérequis suivants :

• Une structure multicompte provisionnée – Pour les instructions, voir Meilleures pratiques pour les unités organisationnelles avec AWS Organizations. Pour les besoins de ce blog, nous utilisons les comptes suivants :
  • Compte de science des données – Un compte où les data scientists ont accès aux données de formation et créent les modèles.
  • Compte de services partagés – Un compte central pour le stockage des artefacts de modèle (comme indiqué dans le diagramme d'architecture) accessibles sur les différents comptes de charge de travail.
  • Compte de déploiement – Un compte responsable du déploiement des modifications sur les différents comptes.
  • Comptes de charge de travail – Il s'agit généralement d'environnements d'assurance qualité et de production dans lesquels les ingénieurs logiciels sont capables de créer des applications pour utiliser le modèle ML.
• Un compte de déploiement avec les autorisations appropriées – Pour plus d'informations sur les meilleures pratiques avec une structure d'UO multi-comptes, reportez-vous à Unité d'organisation des déploiements. Ce compte est chargé de faire pointer les comptes de charge de travail vers le modèle souhaité dans le registre de modèles du compte de services partagés.

Définir des politiques intercomptes

En suivant le principe du moindre privilège, nous devons d'abord ajouter des stratégies de ressources intercomptes aux ressources des services partagés pour accorder l'accès à partir des autres comptes.

Étant donné que les artefacts de modèle sont stockés dans le compartiment S3 du compte de services partagés, le compte de science des données a besoin d'un accès en lecture/écriture Amazon S3 pour pousser les modèles formés vers Amazon S3. Le code suivant illustre cette règle, mais ne l'ajoutez pas encore au compte de services partagés :

#Data Science account's policy to access Shared Services' S3 bucket
 {
    'Version': '2012-10-17',
    'Statement': [{
        'Sid': 'AddPerm',
        'Effect': 'Allow',
        'Principal': {
            'AWS': 'arn:aws:iam:::root'
        }, 
        "Action": [ 
            's3:PutObject', 
            's3:PutObjectAcl',
            's3:GetObject', 
            's3:GetObjectVersion'
        ], #read/write
        'Resource': 'arn:aws:s3:::/*'
    }]
}

Le compte de déploiement doit uniquement disposer d'un accès en lecture au compartiment S3, afin qu'il puisse utiliser les artefacts de modèle pour se déployer sur les points de terminaison SageMaker. Nous devons également attacher la stratégie suivante au compartiment S3 des services partagés :

#Deployment account's policy to access Shared Services' S3 bucket
 {
    'Version': '2012-10-17',
    'Statement': [{
        'Sid': 'AddPerm',
        'Effect': 'Allow',
        'Principal': {
            'AWS': 'arn:aws:iam:::root'
        },
        'Action': [ 
            's3:GetObject', 
            's3:GetObjectVersion'
        ], #read
        'Resource': 'arn:aws:s3:::/*'
    }]
}

Nous combinons les deux politiques pour obtenir la politique finale suivante. Créez cette stratégie dans le compte de services partagés après avoir remplacé les ID de compte appropriés :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AddPerm",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam:::root"    
    },
    "Action": [
      "s3:PutObject",
      "s3:PutObjectAcl",
      "s3:GetObject",
      "s3:GetObjectVersion"    ],
    "Resource": "arn:aws:s3:::/*"  
    },
    {
      "Sid": "AddPermDeployment",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"      
      },
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"      ], 
      "Resource": "arn:aws:s3:::/*"    
    }
  ]
}

Pour pouvoir déployer un modèle créé dans un autre compte, l'utilisateur doit avoir un rôle qui a accès aux actions SageMaker, comme un rôle avec le AmazonSageMakerFullAccess politique gérée. Faire référence à Déployer une version de modèle à partir d'un autre compte pour plus de détails.

Nous devons définir le groupe de modèles qui contient les versions de modèle que nous voulons déployer. De plus, nous voulons accorder des autorisations au compte de science des données. Cela peut être accompli dans les étapes suivantes. Nous nous référons aux comptes comme suit :

• identifiant_compte_services_partagés – Le compte où se trouve le registre des modèles et où nous voulons que le modèle soit
• data_science_account_id – Le compte sur lequel nous allons nous entraîner et donc créer l'artefact du modèle réel
• déploiement_account_id – Le compte où nous voulons héberger le point de terminaison pour ce modèle

Nous devons d'abord nous assurer que les groupes de packages modèles existent. Vous pouvez utiliser les API Boto3 comme illustré dans l'exemple suivant, ou vous pouvez utiliser le Console de gestion AWS pour créer le package de modèle. Faire référence à Créer un groupe de packages de modèles pour plus de détails. Cela suppose que vous avez installé le Boto3.

model_package_group_name = "cross-account-example-model"
sm_client = boto3.Session().client("sagemaker")

create_model_package_group_response = sm_client.create_model_package_group(
    ModelPackageGroupName=model_package_group_name,
    ModelPackageGroupDescription="Cross account model package group",
    Tags=[
          {
              'Key': 'Name',
              'Value': 'cross_account_test'
          },
      ]

)

print('ModelPackageGroup Arn : {}'.format(create_model_package_group_response['ModelPackageGroupArn']))

Pour les autorisations pour ce groupe de packages de modèles, vous pouvez créer un document JSON ressemblant au code suivant. Remplacez les ID de compte réels et le nom du groupe de packages modèles par vos propres valeurs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AddPermModelPackageGroupCrossAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"      
      },
      "Action": [
        "sagemaker:DescribeModelPackageGroup"      
        ],
      "Resource": "arn:aws:sagemaker:::model-package-group/"    
    },
    {
      "Sid": "AddPermModelPackageVersionCrossAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"      
      },
      "Action": [
        "sagemaker:DescribeModelPackage",
        "sagemaker:ListModelPackages",
        "sagemaker:UpdateModelPackage",
        "sagemaker:CreateModelPackage",
        "sagemaker:CreateModel"      
      ],
      "Resource": "arn:aws:sagemaker:::model-package//*"    
    }
  ]
}

Enfin, appliquez la stratégie au groupe de packages de modèles. Vous ne pouvez pas associer cette stratégie au groupe de packages via la console. Vous avez besoin du SDK ou Interface de ligne de commande AWS (AWS CLI). Par exemple, le code suivant utilise Boto3 :

# Convert the policy from JSON dict to string
model_package_group_policy = dict( )
model_package_group_policy = json.dumps(model_package_group_policy)

# Set the new policy
sm_client = boto3.Session().client("sagemaker")
response = sm_client.put_model_package_group_policy(
    ModelPackageGroupName = model_package_group_name,
    ResourcePolicy = model_package_group_policy)

Nous avons également besoin d'une coutume Service de gestion des clés AWS (AWS KMS) pour chiffrer le modèle tout en le stockant dans Amazon S3. Cela doit être fait en utilisant le compte de science des données. Sur la console AWS KMS, accédez au Définir les autorisations d'utilisation des clés page. Dans le Autres comptes AWS section, choisissez Ajouter un autre compte AWS. Entrez le numéro de compte AWS pour le compte de déploiement. Vous utilisez cette clé KMS pour la tâche de formation SageMaker. Si vous ne spécifiez pas de clé KMS pour la tâche de formation, SageMaker utilise par défaut une clé de chiffrement côté serveur Amazon S3. Une clé de chiffrement côté serveur Amazon S3 par défaut ne peut pas être partagée ou utilisée par un autre compte AWS.

La stratégie et les autorisations suivent ce modèle :

• La stratégie Amazon S3 spécifiée dans shared_services_account accorde des autorisations au compte de science des données et au compte de déploiements
• La stratégie de clé KMS spécifiée dans shared_services_account accorde des autorisations au compte de science des données et au compte de déploiements

Nous devons nous assurer que le compte de services partagés et le compte de déploiement ont accès aux images Docker qui ont été utilisées pour former le modèle. Ces images sont généralement hébergées dans des comptes AWS et votre administrateur de compte peut vous aider à y accéder, si vous n'y avez pas déjà accès. Pour cet article, nous ne créons aucune image Docker personnalisée après la formation du modèle et nous n'avons donc pas besoin de politiques Amazon ECR spécifiques pour les images.

Dans les comptes de charge de travail (QA ou prod), nous devons créer deux Gestion des identités et des accès AWS (IAM) politiques similaires aux suivantes. Ceux-ci sont politiques en ligne, ce qui signifie qu'ils sont intégrés dans une identité IAM. Cela permet à ces comptes d'accéder au registre des modèles.

La première stratégie en ligne permet à un rôle d'accéder à la ressource Amazon S3 dans le compte de services partagés qui contient l'artefact de modèle. Indiquez le nom du bucket S3 et votre modèle :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::/sagemaker//output/model.tar.gz"
        }
    ]
}

La deuxième stratégie en ligne permet à un rôle, que nous créons ultérieurement, d'utiliser la clé KMS dans le compte de services partagés. Spécifiez l'ID de compte pour le compte de services partagés et l'ID de clé KMS :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUseOfTheKey",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1::key/{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
            ]
        }
    ]
}

Enfin, nous devons créer un rôle IAM pour Sage Maker. Ce rôle a le AmazonSageMakerFullAccess police ci-jointe. Nous attachons ensuite ces deux politiques en ligne au rôle que nous avons créé. Si vous utilisez un rôle d'exécution SageMaker existant, attachez ces deux stratégies à ce rôle. Pour obtenir des instructions, reportez-vous à Créer des rôles et attacher des politiques (console).

Maintenant que nous avons défini les politiques de chaque compte, utilisons un exemple pour le voir en action.

Construire et former un modèle à l'aide d'un pipeline SageMaker

Nous créons d'abord un pipeline SageMaker dans le compte de science des données pour effectuer le traitement des données, la formation des modèles et l'évaluation. Nous utilisons l'ensemble de données sur le logement en Californie obtenu à partir de la bibliothèque StatLib. Dans l'extrait de code suivant, nous utilisons un script de prétraitement personnalisé preprocess.py pour effectuer une transformation simple des fonctionnalités, telle que la mise à l'échelle des fonctionnalités, qui peut être générée à l'aide des éléments suivants cahier. Ce script divise également le jeu de données en jeux de données d'apprentissage et de test.

Nous créons un SKLearnProcessor objet pour exécuter ce script de prétraitement. Dans le pipeline SageMaker, nous créons une étape de traitement (ProcessingStep) pour exécuter le code de traitement en utilisant SKLearnProcessor. Ce code de traitement est appelé lorsque le pipeline SageMaker est initialisé. Le code créant le SKLearnProcessor ainsi que ProcessingStep sont indiqués dans le code suivant. Notez que tout le code de cette section est exécuté dans le compte de science des données.

# Useful SageMaker variables - Create a Pipeline session which will lazy init resources
session = PipelineSession()

framework_version = "0.23-1"

# Create SKlearn processor object,
# The object contains information about what instance type to use, the IAM role to use etc.
# A managed processor comes with a preconfigured container, so only specifying version is required.
sklearn_processor = SKLearnProcessor(
    framework_version=framework_version,
    role=role,
    instance_type=processing_instance_type,
    instance_count=1,
    base_job_name="tf2-california-housing-processing-job",
    sagemaker_session=session
)

# Use the sklearn_processor in a SageMaker pipelines ProcessingStep
step_preprocess_data = ProcessingStep(
    name="Preprocess-California-Housing-Data",
    processor=sklearn_processor,
    inputs=[
        ProcessingInput(source=input_data, destination="/opt/ml/processing/input"),
    ],
    outputs=[
        ProcessingOutput(output_name="train", source="/opt/ml/processing/train"),
        ProcessingOutput(output_name="test", source="/opt/ml/processing/test"),
    ],
    code="preprocess.py",
)

Nous avons besoin d'une clé KMS personnalisée pour chiffrer le modèle tout en le stockant sur Amazon S3. Voir le code suivant :

kms_client = boto3.client('kms')
response = kms_client.describe_key(
    KeyId='alias/sagemaker/outkey',
)
key_id = response['KeyMetadata']['KeyId']

Pour entraîner le modèle, nous créons un objet estimateur TensorFlow. Nous lui transmettons l'ID de clé KMS avec notre script de formation train.py, le type d'instance d'entraînement et le nombre. Nous créons également un TrainingStep à ajouter à notre pipeline, et ajoutez-y l'estimateur TensorFlow. Voir le code suivant :

model_path = f"s3://{bucket}/{prefix}/model/"

hyperparameters = {"epochs": training_epochs}
tensorflow_version = "2.4.1"
python_version = "py37"

tf2_estimator = TensorFlow(
    source_dir="code",
    entry_point="train.py",
    instance_type=training_instance_type,
    instance_count=1,
    framework_version=tensorflow_version,
    role=role,
    base_job_name="tf2-california-housing-train",
    output_path=model_path,
    output_kms_key=key_id,
    hyperparameters=hyperparameters,
    py_version=python_version,
    sagemaker_session=session
)

# Use the tf2_estimator in a SageMaker pipelines ProcessingStep.
# NOTE how the input to the training job directly references the output of the previous step.
step_train_model = TrainingStep(
    name="Train-California-Housing-Model",
    estimator=tf2_estimator,
    inputs={
        "train": TrainingInput(
            s3_data=step_preprocess_data.properties.ProcessingOutputConfig.Outputs[
                "train"
            ].S3Output.S3Uri,
            content_type="text/csv",
        ),
        "test": TrainingInput(
            s3_data=step_preprocess_data.properties.ProcessingOutputConfig.Outputs[
                "test"
            ].S3Output.S3Uri,
            content_type="text/csv",
        ),
    },
)

En plus de la formation, nous devons effectuer une évaluation du modèle, pour laquelle nous utilisons l'erreur quadratique moyenne (MSE) comme métrique dans cet exemple. La cahier précédent génère également evaluate.py, que nous utilisons pour évaluer notre modèle à l'aide de MSE. Nous créons également un ProcessingStep pour initialiser le script d'évaluation du modèle à l'aide d'un SKLearnProcessor objet. Le code suivant crée cette étape :

from sagemaker.workflow.properties import PropertyFile

# Create SKLearnProcessor object.
# The object contains information about what container to use, what instance type etc.
evaluate_model_processor = SKLearnProcessor(
    framework_version=framework_version,
    instance_type=processing_instance_type,
    instance_count=1,
    base_job_name="tf2-california-housing-evaluate",
    role=role,
    sagemaker_session=session
)

# Create a PropertyFile
# A PropertyFile is used to be able to reference outputs from a processing step, for instance to use in a condition step.
# For more information, visit https://docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-propertyfile.html
evaluation_report = PropertyFile(
    name="EvaluationReport", output_name="evaluation", path="evaluation.json"
)

# Use the evaluate_model_processor in a SageMaker pipelines ProcessingStep.
step_evaluate_model = ProcessingStep(
    name="Evaluate-California-Housing-Model",
    processor=evaluate_model_processor,
    inputs=[
        ProcessingInput(
            source=step_train_model.properties.ModelArtifacts.S3ModelArtifacts,
            destination="/opt/ml/processing/model",
        ),
        ProcessingInput(
            source=step_preprocess_data.properties.ProcessingOutputConfig.Outputs[
                "test"
            ].S3Output.S3Uri,
            destination="/opt/ml/processing/test",
        ),
    ],
    outputs=[
        ProcessingOutput(output_name="evaluation", source="/opt/ml/processing/evaluation"),
    ],
    code="evaluate.py",
    property_files=[evaluation_report],
)

Après l'évaluation du modèle, nous avons également besoin d'une étape pour enregistrer notre modèle auprès du registre des modèles, si les performances du modèle répondent aux exigences. Ceci est illustré dans le code suivant en utilisant le RegisterModel marcher. Ici, nous devons spécifier le modèle de package que nous avions déclaré dans le compte de services partagés. Remplacez le package Région, compte et modèle par vos valeurs. Le nom du modèle utilisé ici est modeltest, mais vous pouvez utiliser le nom de votre choix.

# Create ModelMetrics object using the evaluation report from the evaluation step
# A ModelMetrics object contains metrics captured from a model.
model_metrics = ModelMetrics(
    model_statistics=MetricsSource(
        s3_uri=evaluation_s3_uri,
        content_type="application/json",
    )
)

# Create a RegisterModel step, which registers the model with SageMaker Model Registry.
model = Model(
    image_uri=tf2_estimator.training_image_uri(),
    model_data=training_step.properties.ModelArtifacts.S3ModelArtifacts,
    source_dir=tf2_estimator.source_dir,
    entry_point=tf2_estimator.entry_point,
    role=role_arn,
    sagemaker_session=session
)

model_registry_args = model.register(
    content_types=['text/csv'],
    response_types=['application/json'],
    inference_instances=['ml.t2.medium', 'ml.m5.xlarge'],
    transform_instances=['ml.m5.xlarge'],
    model_package_group_name=model_package_group_name,
    approval_status='PendingManualApproval',
    model_metrics=model_metrics
)

 step_register_model= ModelStep(
    name='RegisterModel',
    step_args=model_registry_args
)

Nous devons également créer les artefacts du modèle afin qu'il puisse être déployé (en utilisant l'autre compte). Pour créer le modèle, nous créons un CreateModelStep, comme indiqué dans le code suivant :

from sagemaker.inputs import CreateModelInput 
from sagemaker.workflow.model_step import ModelStep 
step_create_model = ModelStep( 
    name="Create-California-Housing-Model", 
    step_args=model.create(instance_type="ml.m5.large",accelerator_type="ml.eia1.medium"),
 )

L'ajout de conditions au pipeline se fait avec un ConditionStep. Dans ce cas, nous ne voulons enregistrer la nouvelle version du modèle auprès du registre des modèles que si le nouveau modèle répond à une condition de précision. Voir le code suivant :

from sagemaker.workflow.conditions import ConditionLessThanOrEqualTo
from sagemaker.workflow.condition_step import (
    ConditionStep,
    JsonGet,
)

# Create accuracy condition to ensure the model meets performance requirements.
# Models with a test accuracy lower than the condition will not be registered with the model registry.
cond_lte = ConditionLessThanOrEqualTo(
    left=JsonGet(
        step=step_evaluate_model,
        property_file=evaluation_report,
        json_path="regression_metrics.mse.value",
    ),
    right=accuracy_mse_threshold,
)

# Create a SageMaker Pipelines ConditionStep, using the preceding condition.
# Enter the steps to perform if the condition returns True / False.
step_cond = ConditionStep(
    name="MSE-Lower-Than-Threshold-Condition",
    conditions=[cond_lte],
    if_steps=[step_register_model, step_create_model],
    else_steps=[step_higher_mse_send_email_lambda],
)

Enfin, nous souhaitons orchestrer toutes les étapes du pipeline afin que le pipeline puisse être initialisé :

from sagemaker.workflow.pipeline import Pipeline

# Create a SageMaker Pipeline.
# Each parameter for the pipeline must be set as a parameter explicitly when the pipeline is created.
# Also pass in each of the preceding steps.
# Note that the order of execution is determined from each step's dependencies on other steps,
# not on the order they are passed in.
pipeline = Pipeline(
    name=pipeline_name,
    parameters=[
        processing_instance_type,
        training_instance_type,
        input_data,
        training_epochs,
        accuracy_mse_threshold,
        endpoint_instance_type,
    ],
    steps=[step_preprocess_data, step_train_model, step_evaluate_model, step_cond],
)

Déployer une version de modèle à partir d'un autre compte

Maintenant que le modèle a été enregistré dans le compte de services partagés, nous devons le déployer dans nos comptes de charge de travail à l'aide du pipeline CI/CD dans le compte de déploiement. Nous avons déjà configuré le rôle et la politique dans une étape précédente. Nous utilisons l'ARN du package de modèle pour déployer le modèle à partir du registre de modèles. Le code suivant s'exécute dans le compte de déploiement et est utilisé pour déployer les modèles approuvés pour le contrôle qualité et la production :

from sagemaker import ModelPackage
from time import gmtime, strftime

sagemaker_session = sagemaker.Session(boto_session=sess)

model_package_arn = 'arn:aws:sagemaker:::/modeltest/version_number'
model = ModelPackage(role=role, 
                     model_package_arn=model_package_arn, 
                     sagemaker_session=sagemaker_session)
model.deploy(initial_instance_count=1, instance_type='ml.m5.xlarge')

Conclusion

Dans cet article, nous avons montré comment configurer les politiques nécessaires pour une configuration multi-comptes pour ML basée sur le principe du moindre privilège. Ensuite, nous avons montré le processus de construction et de formation des modèles dans le compte de science des données. Enfin, nous avons utilisé le pipeline CI/CD dans le compte de déploiement pour déployer la dernière version des modèles approuvés sur les comptes d'assurance qualité et de production. De plus, vous pouvez afficher l'historique de déploiement des modèles ainsi que créer des déclencheurs in Création de code AWS.

Vous pouvez mettre à l'échelle les concepts de cet article pour héberger des modèles dans Cloud de calcul élastique Amazon (Amazon EC2) ou Service Amazon Elastic Kubernetes (Amazon EKS), ainsi que la création d'un pipeline d'inférence par lots.

Pour en savoir plus sur le fait d'avoir des comptes distincts qui créent des modèles ML dans AWS, consultez Meilleures pratiques pour les unités organisationnelles avec AWS Organizations ainsi que Mettre à jour en toute sécurité les modèles en production.

À propos des auteurs

Verma des sables est un architecte de prototypage senior chez AWS. Il aime plonger profondément dans les défis des clients et construire des prototypes pour les clients afin d'accélérer l'innovation. Il a une formation en IA/ML, fondateur de New Knowledge, et généralement passionné par la technologie. Pendant son temps libre, il aime voyager et skier avec sa famille.

 Mani Khanouja est un spécialiste de l'intelligence artificielle et de l'apprentissage automatique SA chez Amazon Web Services (AWS). Elle aide les clients utilisant l'apprentissage automatique à résoudre leurs problèmes commerciaux à l'aide d'AWS. Elle passe la plupart de son temps à approfondir et à enseigner aux clients des projets d'IA/ML liés à la vision par ordinateur, au traitement du langage naturel, à la prévision, au ML à la périphérie, et plus encore. Elle est passionnée par le ML at edge, c'est pourquoi elle a créé son propre laboratoire avec un kit de conduite autonome et une ligne de production de prototypes, où elle passe une grande partie de son temps libre.

Saumitra Vikram est un développeur de logiciels au sein de l'équipe Amazon SageMaker et est basé à Chennai, en Inde. En dehors du travail, il aime passer du temps à courir, à faire du trekking et à faire du vélo à travers l'Himalaya.

Sreedevi Srinivasan est un leader de l'ingénierie dans AWS SageMaker. Elle est passionnée et enthousiaste à l'idée d'activer le ML en tant que plate-forme destinée à transformer la vie de tous les jours. Elle se concentre actuellement sur SageMaker Feature Store. Dans ses temps libres, elle aime passer du temps avec sa famille.

Rupinder Grewal est un architecte de solutions spécialisé Sr Ai/ML avec AWS. Il se concentre actuellement sur le service des modèles et des MLOps sur SageMaker. Avant d'occuper ce poste, il a travaillé en tant qu'ingénieur en apprentissage automatique pour créer et héberger des modèles. En dehors du travail, il aime jouer au tennis et faire du vélo sur les sentiers de montagne.

Farouq Sabir est architecte principal de solutions spécialisées en intelligence artificielle et en apprentissage automatique chez AWS. Il est titulaire d'un doctorat et d'une maîtrise en génie électrique de l'Université du Texas à Austin et d'une maîtrise en informatique du Georgia Institute of Technology. Chez AWS, il aide les clients à formuler et à résoudre leurs problèmes commerciaux dans les domaines de la science des données, de l'apprentissage automatique, de la vision par ordinateur, de l'intelligence artificielle, de l'optimisation numérique et des domaines connexes. Il a plus de 16 ans d'expérience professionnelle et est également membre auxiliaire du corps professoral de l'Université du Texas à Dallas, où il enseigne un cours de deuxième cycle sur l'apprentissage automatique appliqué. Basé à Dallas, au Texas, lui et sa famille adorent voyager et faire de longs trajets en voiture.