Byg en MLOps-arbejdsgang på tværs af konti ved hjælp af Amazon SageMaker-modelregistret

En veldesignet CI/CD-pipeline er afgørende for at skalere enhver softwareudviklingsworkflow effektivt. Når man designer produktions-CI/CD-pipelines, anbefaler AWS at udnytte flere konti til at isolere ressourcer, indeholde sikkerhedstrusler og forenkle fakturering - og datavidenskabspipelines er ikke anderledes. Hos AWS fortsætter vi med at innovere for at forenkle MLOps-arbejdsgangen.

I dette indlæg diskuterer vi nogle af de nyere funktioner på tværs af konti Amazon SageMaker der giver dig mulighed for bedre at dele og administrere modelgrupper samt administrere modelversioner. For at følge et eksempel på en kontostruktur bedste praksis i organisationsenheden for at være vært for modeller, der bruger SageMaker-endepunkter på tværs af konti, se MLOps Workload Orchestrator.

Løsningsoversigt

Følgende diagram illustrerer vores delte modelregistreringsarkitektur.

Nogle ting at bemærke i den foregående arkitektur:

Følgende trin svarer til diagrammet:

1. En dataforsker registrerer en model fra datavidenskabskontoen til SageMaker-modelregistret for delte tjenester i en PendingManualApproval stat. Modelartefakten oprettes på kontoen for delte tjenester Amazon Simple Storage Service (Amazon S3) spand.
2. Ved registrering af en ny modelversion skal en person med bemyndigelse til at godkende modellen baseret på metrikken godkende eller afvise modellen.
3. Efter modellen er godkendt, er CI/CD-pipeline i implementeringskontoen udløst til at implementere de opdaterede modeldetaljer i QA-kontoen og opdatere stadiet som QA.
4. Når du har bestået testprocessen, kan du enten vælge at have et manuel godkendelsestrin i din CI/CD-proces eller få din CI/CD-pipeline til at implementere modellen direkte til produktion og opdatere stadiet som Prod.
5. Produktionsmiljøet refererer til den godkendte model og kode, måske gør en A/B test i produktion. I tilfælde af en revision eller ethvert problem med modellen, kan du bruge Amazon SageMaker ML Lineage Tracking. Det opretter og gemmer information om trinene i en maskinlærings-workflow (ML) fra dataforberedelse til modelimplementering. Med sporingsoplysningerne kan du reproducere workflowtrinnene, spore modellen og datasættets linje og etablere modelstyring og revisionsstandarder.

Gennem hele processen bevarer den delte modelregistrering de ældre modelversioner. Dette giver teamet mulighed for at rulle ændringer tilbage eller endda være vært produktionsvarianter.

Forudsætninger

Sørg for, at du har følgende forudsætninger:

• En klargjort multi-konto struktur – For instruktioner, se Bedste praksis for organisatoriske enheder med AWS-organisationer. Til formålet med denne blog udnytter vi følgende konti:
  • Data science konto – En konto, hvor dataforskere har adgang til træningsdataene og skaber modellerne.
  • Delte tjenester-konto – En central konto til lagring af modelartefakter (som vist i arkitekturdiagrammet), der skal tilgås på tværs af de forskellige arbejdsbelastningskonti.
  • Implementeringskonto – En konto, der er ansvarlig for at implementere ændringer på de forskellige konti.
  • Arbejdsbelastningskonti – Disse er almindeligvis QA- og prod-miljøer, hvor softwareingeniører er i stand til at bygge applikationer til at forbruge ML-modellen.
• En implementeringskonto med passende tilladelser – For mere information om bedste praksis med en flerkonto-OU-struktur, se Implementerings-OU. Denne konto er ansvarlig for at pege arbejdsbelastningskontiene til den ønskede model i delte tjenester-kontoens modelregister.

Definer politikker på tværs af konti

Ved at følge princippet om mindste privilegium skal vi først tilføje ressourcepolitikker på tværs af konti til de delte tjenesters ressourcer for at give adgang fra de andre konti.

Fordi modelartefakterne er gemt i den delte servicekontos S3-spand, har datavidenskabskontoen brug for Amazon S3 læse-/skriveadgang for at pushe trænede modeller til Amazon S3. Følgende kode illustrerer denne politik, men føj den ikke til kontoen for delte tjenester endnu:

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

Implementeringskontoen skal kun tildeles læseadgang til S3-bøtten, så den kan bruge modelartefakter til at implementere til SageMaker-slutpunkter. Vi er også nødt til at vedhæfte følgende politik til S3-bøtten for delte tjenester:

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

Vi kombinerer begge politikker for at få følgende endelige politik. Opret denne politik på kontoen for delte tjenester efter at have erstattet de relevante konto-id'er:

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

For at kunne implementere en model, der er oprettet på en anden konto, skal brugeren have en rolle, der har adgang til SageMaker-handlinger, såsom en rolle med AmazonSageMakerFullAccess styret politik. Henvise til Implementer en modelversion fra en anden konto for yderligere detaljer.

Vi skal definere den modelgruppe, der indeholder de modelversioner, vi ønsker at implementere. Vi ønsker også at give tilladelser til datavidenskabskontoen. Dette kan opnås i de følgende trin. Vi henviser til regnskabet som følger:

• shared_services_account_id – Den konto, hvor modelregistret er, og hvor vi ønsker, at modellen skal være
• data_science_account_id – Kontoen, hvor vi skal træne og derfor skabe selve modelartefakten
• deployment_account_id – Kontoen, hvor vi ønsker at være vært for slutpunktet for denne model

Først skal vi sikre, at modelpakkegrupperne eksisterer. Du kan bruge Boto3 API'er som vist i følgende eksempel, eller du kan bruge AWS Management Console at oprette modelpakken. Henvise til Opret modelpakkegruppe for flere detaljer. Dette forudsætter, at du har Boto3 installeret.

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

For tilladelserne for denne modelpakkegruppe kan du oprette et JSON-dokument, der ligner følgende kode. Erstat de faktiske konto-id'er og modelpakkegruppenavn med dine egne værdier.

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

Anvend til sidst politikken på modelpakkegruppen. Du kan ikke knytte denne politik til pakkegruppen via konsollen. Du skal bruge SDK eller AWS kommandolinjegrænseflade (AWS CLI) adgang. For eksempel bruger følgende kode 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)

Vi har også brug for en skik AWS Key Management Service (AWS KMS) nøgle til at kryptere modellen, mens den gemmes i Amazon S3. Dette skal gøres ved hjælp af datavidenskabskontoen. På AWS KMS-konsollen skal du navigere til Definer nøglebrugstilladelser side. I den Andre AWS-konti sektion, skal du vælge Tilføj endnu en AWS-konto. Indtast AWS-kontonummeret for implementeringskontoen. Du bruger denne KMS-nøgle til SageMaker-træningsjobbet. Hvis du ikke angiver en KMS-nøgle til træningsjobbet, bruger SageMaker som standard en Amazon S3-krypteringsnøgle på serversiden. En standard Amazon S3-krypteringsnøgle på serversiden kan ikke deles med eller bruges af en anden AWS-konto.

Politikken og tilladelserne følger dette mønster:

• Amazon S3-politikken specificeret i shared_services_account giver tilladelser til data science-kontoen og implementeringskontoen
• KMS-nøglepolitikken angivet i shared_services_account giver tilladelser til data science-kontoen og implementeringskontoen

Vi skal sikre, at den delte servicekonto og implementeringskontoen har adgang til Docker-billederne, der blev brugt til træning af modellen. Disse billeder hostes generelt på AWS-konti, og din kontoadministrator kan hjælpe dig med at få adgang, hvis du ikke allerede har adgang. Til dette indlæg opretter vi ikke nogen brugerdefinerede Docker-billeder efter træning af modellen, og derfor har vi ikke brug for nogen specifikke Amazon ECR-politikker for billederne.

I arbejdsbelastningskontiene (QA eller prod) skal vi oprette to AWS identitets- og adgangsstyring (IAM) politikker svarende til følgende. Disse er inline politikker, hvilket betyder, at de er indlejret i en IAM-identitet. Dette giver disse konti adgang til modelregistret.

Den første inline-politik tillader en rolle at få adgang til Amazon S3-ressourcen i den delte tjenestekonto, der indeholder modelartefakten. Angiv navnet på S3-spanden og din model:

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

Den anden inline-politik tillader en rolle, som vi opretter senere, at bruge KMS-nøglen i den delte servicekonto. Angiv konto-id'et for kontoen for delte tjenester og KMS-nøgle-id'et:

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

Endelig skal vi oprette en IAM-rolle for SageMaker. Denne rolle har AmazonSageMakerFullAccess politik vedhæftet. Vi knytter derefter disse to indlejrede politikker til den rolle, vi har skabt. Hvis du bruger en eksisterende SageMaker-udførelsesrolle, skal du vedhæfte disse to politikker til den rolle. For instruktioner, se Oprettelse af roller og vedhæftning af politikker (konsol).

Nu hvor vi har defineret politikkerne for hver konto, lad os bruge et eksempel til at se det i aktion.

Byg og træne en model ved hjælp af en SageMaker-pipeline

Vi opretter først en SageMaker-pipeline i datavidenskabskontoen til at udføre databehandling, modeltræning og evaluering. Vi bruger det californiske boligdatasæt hentet fra StatLib-biblioteket. I det følgende kodestykke bruger vi et tilpasset forbehandlingsscript preprocess.py til at udføre nogle simple funktionstransformationer, såsom funktionsskalering, som kan genereres ved hjælp af følgende notesbog. Dette script opdeler også datasættet i trænings- og testdatasæt.

Vi opretter en SKLearnProcessor objekt for at køre dette forbehandlingsscript. I SageMaker-pipelinen opretter vi et behandlingstrin (ProcessingStep) for at køre behandlingskoden ved hjælp af SKLearnProcessor. Denne behandlingskode kaldes, når SageMaker-pipelinen initialiseres. Koden, der skaber SKLearnProcessor , ProcessingStep er vist i følgende kode. Bemærk, at al koden i dette afsnit køres i datavidenskabskontoen.

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

Vi har brug for en brugerdefineret KMS-nøgle til at kryptere modellen, mens vi gemmer den på Amazon S3. Se følgende kode:

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

For at træne modellen opretter vi et TensorFlow-estimatorobjekt. Vi giver det KMS-nøgle-id'et sammen med vores træningsscript train.py, træningsinstanstype og antal. Vi laver også en TrainingStep føjes til vores pipeline, og føj TensorFlow-estimatoren til den. Se følgende kode:

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

Ud over træning skal vi udføre modelevaluering, hvortil vi bruger middel kvadratisk fejl (MSE) som metrikken i dette eksempel. Det tidligere notesbog også genererer evaluate.py, som vi bruger til at evaluere vores en model ved hjælp af MSE. Vi laver også en ProcessingStep at initialisere modelevalueringsscriptet ved hjælp af en SKLearnProcessor objekt. Følgende kode opretter dette trin:

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

Efter modelevaluering skal vi også bruge et trin til at registrere vores model i modelregistret, hvis modellens ydeevne opfylder kravene. Dette er vist i den følgende kode ved hjælp af RegisterModel trin. Her skal vi specificere den modelpakke, som vi havde erklæret på kontoen for delte tjenester. Erstat region-, konto- og modelpakken med dine værdier. Modelnavnet, der bruges her, er modeltest, men du kan bruge et hvilket som helst navn efter eget valg.

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

Vi skal også oprette modelartefakter, så de kan implementeres (ved hjælp af den anden konto). For at skabe modellen opretter vi en CreateModelStep, som vist i følgende kode:

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

Tilføjelse af betingelser til rørledningen udføres med en ConditionStep. I dette tilfælde ønsker vi kun at registrere den nye modelversion i modelregistret, hvis den nye model opfylder en nøjagtighedsbetingelse. Se følgende kode:

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

Til sidst ønsker vi at orkestrere alle pipeline-trinene, så pipelinen kan initialiseres:

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

Implementer en modelversion fra en anden konto

Nu hvor modellen er blevet registreret på den delte tjenester-konto, skal vi implementere i vores arbejdsbelastningskonti ved hjælp af CI/CD-pipelinen i implementeringskontoen. Vi har allerede konfigureret rollen og politikken i et tidligere trin. Vi bruger modelpakken ARN til at implementere modellen fra modelregistret. Følgende kode kører i implementeringskontoen og bruges til at implementere godkendte modeller til QA og 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')

Konklusion

I dette indlæg demonstrerede vi, hvordan man opsætter de politikker, der er nødvendige for en multi-konto opsætning til ML baseret på princippet om mindste privilegium. Derefter viste vi processen med at bygge og træne modellerne i data science-regnskabet. Til sidst brugte vi CI/CD-pipelinen i implementeringskontoen til at implementere den seneste version af godkendte modeller til QA- og produktionskonti. Derudover kan du se implementeringshistorikken for modeller , bygge udløsere in AWS CodeBuild.

Du kan skalere begreberne i dette indlæg til at være vært for modeller i Amazon Elastic Compute Cloud (Amazon EC2) eller Amazon Elastic Kubernetes Service (Amazon EKS), samt opbygge en batch-inferenspipeline.

For at lære mere om at have separate konti, der bygger ML-modeller i AWS, se Bedste praksis for organisatoriske enheder med AWS-organisationer , Sikker opdatering af modeller i produktion.

Om forfatterne

Sandeep Verma er en Sr. Prototyping Architect med AWS. Han nyder at dykke dybt ned i kundernes udfordringer og bygge prototyper til kunderne for at accelerere innovationen. Han har en baggrund i AI/ML, grundlægger af New Knowledge, og generelt passioneret omkring tech. I sin fritid elsker han at rejse og stå på ski med sin familie.

 Mani Khanuja er en Artificial Intelligence and Machine Learning Specialist SA hos Amazon Web Services (AWS). Hun hjælper kunder med maskinlæring til at løse deres forretningsudfordringer ved hjælp af AWS. Hun bruger det meste af sin tid på at dykke dybt og undervise kunder i AI/ML-projekter relateret til computersyn, naturlig sprogbehandling, prognoser, ML på kanten og meget mere. Hun brænder for ML på kanten, derfor har hun skabt sit eget laboratorium med selvkørende kit og prototypefremstillingsproduktionslinje, hvor hun bruger meget af sin fritid.

Saumitra Vikram er softwareudvikler på Amazon SageMaker-teamet og er baseret i Chennai, Indien. Uden for arbejdet elsker han at bruge tid på at løbe, vandre og køre på motorcykel gennem Himalaya.

Sreedevi Srinivasan er ingeniørleder i AWS SageMaker. Hun er passioneret og begejstret for at aktivere ML som en platform, der skal transformere hverdagen. Hun fokuserer i øjeblikket på SageMaker Feature Store. I sin fritid kan hun godt lide at bruge tid sammen med sin familie.

Rupinder Grewal er en Sr Ai/ML Specialist Solutions Architect hos AWS. Han fokuserer i øjeblikket på servering af modeller og MLOps på SageMaker. Før denne rolle har han arbejdet som Machine Learning Engineer ved at bygge og hoste modeller. Uden for arbejdet nyder han at spille tennis og cykle på bjergstier.

Farooq Sabir er senior specialist i kunstig intelligens og maskinlæringsløsninger hos AWS. Han har ph.d.- og MS-grader i elektroteknik fra University of Texas i Austin og en MS i datalogi fra Georgia Institute of Technology. Hos AWS hjælper han kunder med at formulere og løse deres forretningsproblemer inden for datavidenskab, maskinlæring, computervision, kunstig intelligens, numerisk optimering og relaterede domæner. Han har over 16 års erhvervserfaring og er også adjungeret fakultetsmedlem ved University of Texas i Dallas, hvor han underviser i et kandidatkursus i Applied Machine Learning. Baseret i Dallas, Texas, elsker han og hans familie at rejse og lave lange roadtrips.