Bouw een MLOps-workflow voor meerdere accounts met behulp van het Amazon SageMaker-modelregister

Een goed ontworpen CI/CD-pijplijn is essentieel om elke workflow voor softwareontwikkeling effectief te schalen. Bij het ontwerpen van productie-CI/CD-pijplijnen raadt AWS aan om gebruik te maken van meerdere accounts om bronnen te isoleren, beveiligingsbedreigingen in te dammen en facturering te vereenvoudigen. En datawetenschapspijplijnen zijn niet anders. Bij AWS blijven we innoveren om de MLOps-workflow te vereenvoudigen.

In dit bericht bespreken we enkele van de nieuwere functies voor meerdere accounts Amazon Sage Maker waarmee u modelgroepen beter kunt delen en beheren en modelversies kunt beheren. Voor een voorbeeld rekeningstructuur om te volgen best practices voor organisatie-eenheden voor het hosten van modellen met behulp van SageMaker-eindpunten voor verschillende accounts, raadpleeg MLOps Workload Orchestrator.

Overzicht oplossingen

Het volgende diagram illustreert onze gedeelde modelregistratiearchitectuur.

Enkele dingen om op te merken in de voorgaande architectuur:

De volgende stappen komen overeen met het diagram:

1. Een datawetenschapper registreert een model van het datawetenschapsaccount in het SageMaker-modelregister voor gedeelde services in een PendingManualApproval staat. Het modelartefact wordt gemaakt in het shared services-account Amazon eenvoudige opslagservice (Amazon S3) emmer.
2. Bij een registratie van een nieuwe modelversie moet iemand met de bevoegdheid om het model goed te keuren op basis van de statistieken het model goedkeuren of afwijzen.
3. Nadat het model is goedgekeurd, is de CI/CD-pijplijn in het implementatieaccount getriggerd om in te zetten de bijgewerkte modeldetails in het QA-account en werk de stage bij als QA.
4. Nadat u het testproces hebt doorlopen, kunt u kiezen voor een handmatige goedkeuringsstap binnen uw CI/CD-proces of uw CI/CD-pijplijn het model direct laten implementeren voor productie en het stadium bijwerken als Prod.
5. De productieomgeving verwijst naar het goedgekeurde model en de code, misschien door een A/B-test in productie. In het geval van een audit of een probleem met het model, kunt u gebruik maken van Amazon SageMaker ML Lineage-tracking. Het creëert en slaat informatie op over de stappen van een machine learning (ML)-workflow, van gegevensvoorbereiding tot modelimplementatie. Met de traceerinformatie kunt u de werkstroomstappen reproduceren, de afstamming van het model en de dataset volgen en modelbeheer- en auditnormen vaststellen.

Gedurende het hele proces behoudt het gedeelde modelregister de oudere modelversies. Hierdoor kan het team wijzigingen ongedaan maken of zelfs hosten productie varianten.

Voorwaarden

Zorg ervoor dat u aan de volgende vereisten voldoet:

• Een ingerichte structuur met meerdere accounts – Zie voor instructies Best practices voor organisatie-eenheden met AWS-organisaties. Voor de doeleinden van deze blog maken we gebruik van de volgende accounts:
  • Data science-account – Een account waar datascientists toegang hebben tot de trainingsdata en de modellen maken.
  • Gedeelde services-account – Een centraal account voor het opslaan van de modelartefacten (zoals weergegeven in het architectuurdiagram) die toegankelijk zijn voor de verschillende werklastaccounts.
  • Implementatie account – Een account dat verantwoordelijk is voor het doorvoeren van wijzigingen in de verschillende accounts.
  • Workload-accounts - Dit zijn meestal QA- en prod-omgevingen waar software-engineers applicaties kunnen bouwen om het ML-model te gebruiken.
• Een implementatieaccount met de juiste machtigingen – Voor meer informatie over best practices met een OE-structuur met meerdere accounts, zie Implementaties OU. Dit account is verantwoordelijk voor het verwijzen van de werklastaccounts naar het gewenste model in het modelregister van het shared services-account.

Beleid voor meerdere accounts definiëren

Om het principe van de minste bevoegdheden te volgen, moeten we eerst resourcebeleid voor meerdere accounts toevoegen aan de shared services-resources om toegang te verlenen vanaf de andere accounts.

Omdat de modelartefacten worden opgeslagen in de S3-bucket van het shared services-account, heeft het data science-account Amazon S3 lees-/schrijftoegang nodig om getrainde modellen naar Amazon S3 te pushen. De volgende code illustreert dit beleid, maar voeg het nog niet toe aan het shared services-account:

#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:::/*'
    }]
}

Het implementatieaccount hoeft alleen leestoegang te krijgen tot de S3-bucket, zodat het de modelartefacten kan gebruiken om te implementeren op SageMaker-eindpunten. We moeten ook het volgende beleid koppelen aan de shared services S3-bucket:

#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:::/*'
    }]
}

We combineren beide beleidsregels om het volgende definitieve beleid te krijgen. Maak dit beleid in het gedeelde services-account na het vervangen van de juiste account-ID'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:::/*"    
    }
  ]
}

Om een ​​model te kunnen implementeren dat in een ander account is gemaakt, moet de gebruiker een rol hebben die toegang heeft tot SageMaker-acties, zoals een rol met de AmazonSageMakerFullAccess beheerd beleid. Verwijzen naar Implementeer een modelversie vanaf een ander account voor meer informatie.

We moeten de modelgroep definiëren die de modelversies bevat die we willen implementeren. We willen ook machtigingen verlenen aan het data science-account. Dit kan worden bereikt in de volgende stappen. We verwijzen naar de rekeningen als volgt:

• gedeelde_services_account_id – Het account waar het modelregister staat en waar we het model willen hebben
• data_science_account_id – Het account waar we gaan trainen en dus het daadwerkelijke modelartefact maken
• implementatie_account_id – Het account waar we het eindpunt voor dit model willen hosten

Eerst moeten we ervoor zorgen dat de modelpakketgroepen bestaan. U kunt Boto3 API's gebruiken zoals in het volgende voorbeeld wordt getoond, of u kunt de AWS-beheerconsole om het modelpakket te maken. Verwijzen naar Modelpakketgroep maken voor meer details. Dit veronderstelt dat u de Boto3 hebt geïnstalleerd.

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

Voor de machtigingen voor deze modelpakketgroep kunt u een JSON-document maken dat lijkt op de volgende code. Vervang de daadwerkelijke account-ID's en de naam van de modelpakketgroep door uw eigen waarden.

{
  "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//*"    
    }
  ]
}

Pas ten slotte het beleid toe op de modelpakketgroep. U kunt dit beleid niet koppelen aan de pakketgroep via de console. U hebt de SDK of AWS-opdrachtregelinterface (AWS CLI) toegang. De volgende code gebruikt bijvoorbeeld 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)

We hebben ook een gewoonte nodig AWS Sleutelbeheerservice (AWS KMS) sleutel om het model te versleutelen terwijl het wordt opgeslagen in Amazon S3. Dit moet worden gedaan met behulp van het data science-account. Navigeer op de AWS KMS-console naar de Definieer machtigingen voor sleutelgebruik bladzijde. In de Andere AWS-accounts sectie, kies Voeg nog een AWS-account toe. Voer het AWS-accountnummer in voor het implementatieaccount. U gebruikt deze KMS-sleutel voor de SageMaker-trainingstaak. Als u geen KMS-sleutel opgeeft voor de trainingstaak, gebruikt SageMaker standaard een Amazon S3-coderingssleutel aan de serverzijde. Een standaard Amazon S3-coderingssleutel aan de serverzijde kan niet worden gedeeld met of gebruikt door een ander AWS-account.

Het beleid en de machtigingen volgen dit patroon:

• Het Amazon S3-beleid gespecificeerd in shared_services_account geeft machtigingen voor het datawetenschapsaccount en het implementatieaccount
• Het KMS-sleutelbeleid dat is opgegeven in shared_services_account geeft machtigingen voor het datawetenschapsaccount en het implementatieaccount

We moeten ervoor zorgen dat het shared services-account en het implementatieaccount toegang hebben tot de Docker-images die zijn gebruikt voor het trainen van het model. Deze afbeeldingen worden over het algemeen gehost in AWS-accounts en uw accountbeheerder kan u helpen toegang te krijgen, als u nog geen toegang heeft. Voor dit bericht maken we geen aangepaste Docker-afbeeldingen na het trainen van het model en daarom hebben we geen specifiek Amazon ECR-beleid voor de afbeeldingen nodig.

In de werklastaccounts (QA of prod) moeten we er twee maken AWS Identiteits- en toegangsbeheer (IAM)-beleid vergelijkbaar met het volgende. Dit zijn inline beleid, wat betekent dat ze zijn ingebed in een IAM-identiteit. Dit geeft deze accounts toegang tot het modelregister.

Het eerste inline beleid staat een rol toe om toegang te krijgen tot de Amazon S3-resource in het shared services-account dat het modelartefact bevat. Geef de naam van de S3-bucket en uw model op:

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

Met het tweede inline beleid kan een rol, die we later maken, de KMS-sleutel in het shared services-account gebruiken. Geef de account-ID op voor het gedeelde services-account en de KMS-sleutel-ID:

{
    "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}"
            ]
        }
    ]
}

Tot slot moeten we maak een IAM-rol aan voor SalieMaker. Deze rol heeft de AmazonSageMakerFullAccess beleid bijgevoegd. Vervolgens koppelen we deze twee inline beleidsregels aan de rol die we hebben gemaakt. Als u een bestaande SageMaker-uitvoeringsrol gebruikt, koppelt u deze twee beleidsregels aan die rol. Raadpleeg voor instructies Rollen maken en beleid koppelen (console).

Nu we het beleid van elk account hebben gedefinieerd, laten we een voorbeeld gebruiken om het in actie te zien.

Bouw en train een model met behulp van een SageMaker-pijplijn

We maken eerst een SageMaker-pijplijn in het data science-account voor het uitvoeren van gegevensverwerking, modeltraining en evaluatie. We gebruiken de gegevensset over huisvesting in Californië die is verkregen uit de StatLib-bibliotheek. In het volgende codefragment gebruiken we een aangepast preprocessing-script preprocess.py om een ​​eenvoudige functietransformatie uit te voeren, zoals het schalen van functies, die met behulp van het volgende kan worden gegenereerd notitieboekje. Dit script splitst de dataset ook op in trainings- en testdatasets.

We creëren een SKLearnProcessor object om dit preprocessing-script uit te voeren. In de SageMaker-pijplijn maken we een verwerkingsstap (ProcessingStep) om de verwerkingscode uit te voeren met behulp van SKLearnProcessor. Deze verwerkingscode wordt aangeroepen wanneer de SageMaker-pijplijn wordt geïnitialiseerd. De code die de SKLearnProcessor en ProcessingStep worden weergegeven in de volgende code. Houd er rekening mee dat alle code in deze sectie wordt uitgevoerd in het data science-account.

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

We hebben een aangepaste KMS-sleutel nodig om het model te coderen terwijl het wordt opgeslagen in Amazon S3. Zie de volgende code:

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

Om het model te trainen, maken we een TensorFlow schatterobject. We geven het de KMS-sleutel-ID door samen met ons trainingsscript train.py, type trainingsinstantie en aantal. We maken ook een TrainingStep om aan onze pijplijn te worden toegevoegd en voeg de TensorFlow-schatter eraan toe. Zie de volgende code:

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",
        ),
    },
)

Naast training moeten we modelevaluaties uitvoeren, waarvoor we in dit voorbeeld de gemiddelde kwadratische fout (MSE) gebruiken als maatstaf. De eerder notitieboekje genereert ook evaluate.py, die we gebruiken om ons model te evalueren met behulp van MSE. We maken ook een ProcessingStep om het modelevaluatiescript te initialiseren met behulp van a SKLearnProcessor object. De volgende code maakt deze stap:

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

Na modelevaluatie hebben we ook een stap nodig om ons model te registreren bij het modelregister, als de modelprestaties voldoen aan de vereisten. Dit wordt weergegeven in de volgende code met behulp van de RegisterModel stap. Hier moeten we het modelpakket specificeren dat we hadden gedeclareerd in het shared services-account. Vervang het Regio-, account- en modelpakket door uw waarden. De hier gebruikte modelnaam is modeltest, maar u kunt elke gewenste naam gebruiken.

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

We moeten ook de modelartefacten maken zodat deze kunnen worden geïmplementeerd (met behulp van het andere account). Voor het maken van het model maken we een CreateModelStep, zoals weergegeven in de volgende code:

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

Het toevoegen van voorwaarden aan de pijplijn gebeurt met a ConditionStep. In dit geval willen we de nieuwe modelversie alleen registreren bij het modelregister als het nieuwe model voldoet aan een nauwkeurigheidsvoorwaarde. Zie de volgende code:

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

Ten slotte willen we alle pijplijnstappen orkestreren zodat de pijplijn kan worden geïnitialiseerd:

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

Implementeer een modelversie vanaf een ander account

Nu het model is geregistreerd in het account voor gedeelde services, moeten we het implementeren in onze werklastaccounts met behulp van de CI/CD-pijplijn in het implementatieaccount. We hebben de rol en het beleid al in een eerdere stap geconfigureerd. We gebruiken het modelpakket ARN om het model uit het modelregister te implementeren. De volgende code wordt uitgevoerd in het implementatieaccount en wordt gebruikt om goedgekeurde modellen te implementeren voor QA en prod:

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

Conclusie

In dit bericht hebben we laten zien hoe u het beleid kunt instellen dat nodig is voor een configuratie met meerdere accounts voor ML op basis van het principe van de minste privileges. Vervolgens lieten we het proces zien van het bouwen en trainen van de modellen in het data science-account. Ten slotte hebben we de CI/CD-pijplijn in het implementatieaccount gebruikt om de nieuwste versie van goedgekeurde modellen te implementeren in QA- en productieaccounts. Bovendien kan dat bekijk de implementatiegeschiedenis van modellen en triggers bouwen in AWS CodeBuild.

Je kunt de concepten in dit bericht schalen om modellen in te hosten Amazon Elastic Compute-cloud (Amazon EC2) of Amazon Elastic Kubernetes-service (Amazon EKS), evenals het uitbouwen van een batch-inferentiepijplijn.

Zie voor meer informatie over het hebben van afzonderlijke accounts die ML-modellen bouwen in AWS Best practices voor organisatie-eenheden met AWS-organisaties en Werk modellen in productie veilig bij.

Over de auteurs

Sandeep Verma is een Sr. Prototyping Architect bij AWS. Hij duikt graag diep in de uitdagingen van klanten en bouwt prototypes voor klanten om innovatie te versnellen. Hij heeft een achtergrond in AI/ML, oprichter van New Knowledge en over het algemeen een passie voor technologie. In zijn vrije tijd houdt hij van reizen en skiën met zijn gezin.

 Mani Khanuja is een Artificial Intelligence en Machine Learning Specialist SA bij Amazon Web Services (AWS). Ze helpt klanten die machine learning gebruiken om hun zakelijke uitdagingen op te lossen met behulp van de AWS. Ze besteedt het grootste deel van haar tijd aan het duiken en lesgeven aan klanten over AI/ML-projecten met betrekking tot computervisie, natuurlijke taalverwerking, prognoses, ML aan de rand en meer. Ze is gepassioneerd door ML at edge, daarom heeft ze haar eigen lab gecreëerd met een zelfrijdende kit en een productielijn voor het maken van prototypes, waar ze veel van haar vrije tijd doorbrengt.

Saumitra Vikram is een softwareontwikkelaar in het Amazon SageMaker-team en is gevestigd in Chennai, India. Buiten zijn werk brengt hij graag tijd door met hardlopen, wandelen en motorrijden door de Himalaya.

Sreedevi Srinivasan is een technisch leider in AWS SageMaker. Ze is gepassioneerd en enthousiast over het mogelijk maken van ML als een platform dat klaar is om het dagelijks leven te transformeren. Ze richt zich momenteel op SageMaker Feature Store. In haar vrije tijd brengt ze graag tijd door met haar gezin.

Rupinder Grewal is een Sr Ai/ML Specialist Solutions Architect bij AWS. Hij richt zich momenteel op het bedienen van modellen en MLOps op SageMaker. Voorafgaand aan deze functie heeft hij gewerkt als Machine Learning Engineer voor het bouwen en hosten van modellen. Naast zijn werk speelt hij graag tennis en fietst hij graag op bergpaden.

Farooq Sabir is een Senior Artificial Intelligence en Machine Learning Specialist Solutions Architect bij AWS. Hij heeft een doctoraat en MS-graad in Electrical Engineering van de Universiteit van Texas in Austin en een MS in Computer Science van het Georgia Institute of Technology. Bij AWS helpt hij klanten bij het formuleren en oplossen van hun zakelijke problemen op het gebied van data science, machine learning, computer vision, kunstmatige intelligentie, numerieke optimalisatie en aanverwante domeinen. Hij heeft meer dan 16 jaar werkervaring en is ook adjunct-faculteitslid aan de Universiteit van Texas in Dallas, waar hij een afstudeercursus over Applied Machine Learning geeft. Gevestigd in Dallas, Texas, houden hij en zijn gezin van reizen en lange roadtrips maken.