Bygg en MLOps-arbeidsflyt på tvers av kontoer ved å bruke Amazon SageMaker-modellregisteret

En godt utformet CI/CD-pipeline er avgjørende for å skalere enhver arbeidsflyt for programvareutvikling effektivt. Når du designer produksjons-CI/CD-pipelines, anbefaler AWS å utnytte flere kontoer for å isolere ressurser, inneholde sikkerhetstrusler og forenkle fakturering - og datavitenskapspipelines er ikke annerledes. Hos AWS fortsetter vi å innovere for å forenkle MLOps-arbeidsflyten.

I dette innlegget diskuterer vi noen av de nyere funksjonene på tvers av kontoer Amazon SageMaker som lar deg bedre dele og administrere modellgrupper samt administrere modellversjoner. For et eksempel på kontostruktur å følge organisasjonens beste praksis for å være vert for modeller som bruker SageMaker-endepunkter på tvers av kontoer, se MLOps Workload Orchestrator.

Løsningsoversikt

Følgende diagram illustrerer vår delte modellregisterarkitektur.

Noen ting å merke seg i den foregående arkitekturen:

Følgende trinn tilsvarer diagrammet:

1. En dataforsker registrerer en modell fra datavitenskapskontoen til SageMaker-modellregisteret for delte tjenester i et PendingManualApproval stat. Modellartefakten opprettes i kontoen for delte tjenester Amazon enkel lagringstjeneste (Amazon S3) bøtte.
2. Ved registrering av ny modellversjon, bør noen med myndighet til å godkjenne modellen basert på beregningene godkjenne eller avvise modellen.
3. Etter at modellen er godkjent, er CI/CD-rørledningen i distribusjonskontoen utløst for å distribuere de oppdaterte modelldetaljene i QA-kontoen og oppdater stadiet som QA.
4. Når du har bestått testprosessen, kan du enten velge å ha et manuelt godkjenningstrinn i CI/CD-prosessen eller få CI/CD-pipeline til å distribuere modellen direkte til produksjon og oppdatere stadiet som Prod.
5. Produksjonsmiljøet refererer til den godkjente modellen og koden, kanskje gjør en A/B-test i produksjon. I tilfelle en revisjon eller ethvert problem med modellen, kan du bruke Amazon SageMaker ML Lineage Tracking. Den oppretter og lagrer informasjon om trinnene i en arbeidsflyt for maskinlæring (ML) fra dataforberedelse til modellimplementering. Med sporingsinformasjonen kan du reprodusere arbeidsflyttrinnene, spore modellen og datasettet, og etablere modellstyring og revisjonsstandarder.

Gjennom hele prosessen beholder det delte modellregisteret de eldre modellversjonene. Dette gjør at teamet kan rulle tilbake endringer, eller til og med være vert produksjonsvarianter.

Forutsetninger

Sørg for at du har følgende forutsetninger:

• En klargjort flerkontostruktur – For instruksjoner, se Beste praksis for organisasjonsenheter med AWS-organisasjoner. For formålet med denne bloggen bruker vi følgende kontoer:
  • Datavitenskap-konto – En konto der dataforskere har tilgang til treningsdataene og lager modellene.
  • Konto for delte tjenester – En sentral konto for lagring av modellartefakter (som vist i arkitekturdiagrammet) som er tilgjengelig på tvers av de forskjellige arbeidsbelastningskontoene.
  • Implementeringskonto – En konto som er ansvarlig for å implementere endringer på de ulike kontoene.
  • Arbeidsbelastningskontoer – Dette er vanligvis QA- og prod-miljøer der programvareingeniører er i stand til å bygge applikasjoner for å konsumere ML-modellen.
• En distribusjonskonto med passende tillatelser – For mer informasjon om beste fremgangsmåter med en flerkonto-OU-struktur, se Implementerings-OU. Denne kontoen er ansvarlig for å peke arbeidsbelastningskontoene til ønsket modell i delte tjenester-kontoens modellregister.

Definer retningslinjer for flere kontoer

Ved å følge prinsippet om minste privilegium må vi først legge til ressurspolicyer på tvers av kontoer til ressursene for delte tjenester for å gi tilgang fra de andre kontoene.

Fordi modellartefaktene er lagret i S3-bøtten til kontoen for delte tjenester, trenger datavitenskapskontoen Amazon S3 lese-/skrivetilgang for å sende trente modeller til Amazon S3. Følgende kode illustrerer denne policyen, men ikke legg den til kontoen for delte tjenester ennå:

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

Distribusjonskontoen trenger bare å gis lesetilgang til S3-bøtten, slik at den kan bruke modellartefakter til å distribuere til SageMaker-endepunkter. Vi må også knytte følgende retningslinjer 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 retningslinjene for å få følgende endelige policy. Opprett denne policyen i kontoen for delte tjenester etter å ha erstattet de aktuelle konto-ID-ene:

{
  "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 å kunne distribuere en modell opprettet i en annen konto, må brukeren ha en rolle som har tilgang til SageMaker-handlinger, for eksempel en rolle med AmazonSageMakerFullAccess administrert politikk. Referere til Distribuer en modellversjon fra en annen konto for ytterligere detaljer.

Vi må definere modellgruppen som inneholder modellversjonene vi ønsker å distribuere. Vi ønsker også å gi tillatelser til datavitenskapskontoen. Dette kan oppnås i følgende trinn. Vi viser til regnskapet som følger:

• shared_services_account_id – Kontoen hvor modellregisteret er og hvor vi ønsker at modellen skal være
• data_science_account_id – Kontoen der vi skal trene og derfor lage selve modellartefakten
• deployment_account_id – Kontoen der vi ønsker å være vert for endepunktet for denne modellen

Først må vi sikre at modellpakkegruppene eksisterer. Du kan bruke Boto3 APIer som vist i følgende eksempel, eller du kan bruke AWS-administrasjonskonsoll for å lage modellpakken. Referere til Opprett modellpakkegruppe for flere detaljer. Dette forutsetter at du har Boto3 installert.

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 tillatelsene for denne modellpakkegruppen kan du opprette et JSON-dokument som ligner på følgende kode. Erstatt de faktiske konto-ID-ene og modellpakkegruppenavnet med dine egne verdier.

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

Til slutt, bruk policyen på modellpakkegruppen. Du kan ikke knytte denne policyen til pakkegruppen via konsollen. Du trenger SDK eller AWS kommandolinjegrensesnitt (AWS CLI) tilgang. For eksempel bruker 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 trenger også en skikk AWS nøkkelstyringstjeneste (AWS KMS) nøkkel for å kryptere modellen mens du lagrer den i Amazon S3. Dette må gjøres ved hjelp av datavitenskapskontoen. På AWS KMS-konsollen, naviger til Definer nøkkelbrukstillatelser side. I Andre AWS-kontoer delen velger Legg til en annen AWS-konto. Skriv inn AWS-kontonummeret for distribusjonskontoen. Du bruker denne KMS-nøkkelen til SageMaker-treningsjobben. Hvis du ikke spesifiserer en KMS-nøkkel for opplæringsjobben, bruker SageMaker som standard en Amazon S3-krypteringsnøkkel på serversiden. En standard Amazon S3-krypteringsnøkkel på serversiden kan ikke deles med eller brukes av en annen AWS-konto.

Retningslinjene og tillatelsene følger dette mønsteret:

• Amazon S3-policyen spesifisert i shared_services_account gir tillatelser til datavitenskapskontoen og distribusjonskontoen
• KMS-nøkkelpolicyen spesifisert i shared_services_account gir tillatelser til datavitenskapskontoen og distribusjonskontoen

Vi må sørge for at kontoen for delte tjenester og distribusjonskontoen har tilgang til Docker-bildene som ble brukt til å trene modellen. Disse bildene er vanligvis lagret i AWS-kontoer, og kontoadministratoren din kan hjelpe deg med å få tilgang, hvis du ikke allerede har tilgang. For dette innlegget lager vi ingen tilpassede Docker-bilder etter opplæring av modellen, og derfor trenger vi ingen spesifikke Amazon ECR-policyer for bildene.

I arbeidsbelastningskontoene (QA eller prod) må vi opprette to AWS identitets- og tilgangsadministrasjon (IAM) retningslinjer som ligner på følgende. Disse er innebygde retningslinjer, som betyr at de er innebygd i en IAM-identitet. Dette gir disse kontoene tilgang til modellregisteret.

Den første integrerte policyen tillater en rolle å få tilgang til Amazon S3-ressursen i kontoen for delte tjenester som inneholder modellartefakten. Oppgi navnet på S3-bøtten og modellen din:

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

Den andre innebygde policyen tillater en rolle, som vi oppretter senere, å bruke KMS-nøkkelen i kontoen for delte tjenester. Angi konto-ID-en for kontoen for delte tjenester og KMS-nøkkel-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}"
            ]
        }
    ]
}

Til slutt må vi opprette en IAM-rolle for SageMaker. Denne rollen har AmazonSageMakerFullAccess politikk vedlagt. Deretter knytter vi disse to integrerte retningslinjene til rollen vi opprettet. Hvis du bruker en eksisterende SageMaker-utførelsesrolle, knytter du disse to policyene til den rollen. For instruksjoner, se Opprette roller og legge ved retningslinjer (konsoll).

Nå som vi har definert retningslinjene for hver konto, la oss bruke et eksempel for å se det i aksjon.

Bygg og tren en modell ved å bruke en SageMaker-rørledning

Vi oppretter først en SageMaker-pipeline i datavitenskapskontoen for å utføre databehandling, modelltrening og evaluering. Vi bruker California boligdatasettet hentet fra StatLib-biblioteket. I den følgende kodebiten bruker vi et tilpasset forhåndsbehandlingsskript preprocess.py å utføre noen enkle funksjonstransformasjoner som funksjonsskalering, som kan genereres ved å bruke følgende bærbare. Dette skriptet deler også datasettet i trenings- og testdatasett.

Vi lager en SKLearnProcessor objekt for å kjøre dette forhåndsbehandlingsskriptet. I SageMaker-pipelinen lager vi et behandlingstrinn (ProcessingStep) for å kjøre behandlingskoden ved hjelp av SKLearnProcessor. Denne behandlingskoden kalles når SageMaker-rørledningen initialiseres. Koden som lager SKLearnProcessor og ProcessingStep vises i følgende kode. Merk at all koden i denne delen kjøres i datavitenskapskontoen.

# 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 trenger en tilpasset KMS-nøkkel for å kryptere modellen mens vi lagrer 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 å trene modellen lager vi et TensorFlow-estimatorobjekt. Vi gir den KMS-nøkkel-ID-en sammen med treningsskriptet vårt train.py, type treningsforekomst og antall. Vi lager også en TrainingStep legges til rørledningen vår, og legg 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",
        ),
    },
)

I tillegg til opplæring, må vi gjennomføre modellevaluering, hvor vi bruker gjennomsnittlig kvadratfeil (MSE) som metrikk i dette eksemplet. De tidligere notatbok også genererer evaluate.py, som vi bruker til å evaluere vår modell ved bruk av MSE. Vi lager også en ProcessingStep for å initialisere modellevalueringsskriptet ved å bruke en SKLearnProcessor gjenstand. Følgende kode oppretter dette trinnet:

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

Etter modellevaluering trenger vi også et trinn for å registrere modellen vår i modellregisteret, dersom modellytelsen oppfyller kravene. Dette vises i følgende kode ved hjelp av RegisterModel steg. Her må vi spesifisere modellpakken som vi hadde deklarert i kontoen for delte tjenester. Bytt ut region-, konto- og modellpakken med verdiene dine. Modellnavnet som brukes her er modeltest, men du kan bruke hvilket som helst navn du ønsker.

# 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 må også lage modellartefakter slik at de kan distribueres (ved hjelp av den andre kontoen). For å lage modellen lager 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"),
 )

Legge til forhold til rørledningen gjøres med en ConditionStep. I dette tilfellet ønsker vi kun å registrere den nye modellversjonen i modellregisteret hvis den nye modellen oppfyller en nøyaktighetsbetingelse. 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 slutt ønsker vi å orkestrere alle pipeline-trinnene slik at 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],
)

Distribuer en modellversjon fra en annen konto

Nå som modellen er registrert i kontoen for delte tjenester, må vi distribuere til arbeidsbelastningskontoene våre ved å bruke CI/CD-pipelinen i distribusjonskontoen. Vi har allerede konfigurert rollen og policyen i et tidligere trinn. Vi bruker modellpakken ARN for å distribuere modellen fra modellregisteret. Følgende kode kjører i distribusjonskontoen og brukes til å distribuere godkjente 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')

konklusjonen

I dette innlegget demonstrerte vi hvordan du setter opp retningslinjene som trengs for et multikontooppsett for ML basert på prinsippet om minste privilegium. Deretter viste vi prosessen med å bygge og trene modellene i datavitenskapsregnskapet. Til slutt brukte vi CI/CD-pipelinen i distribusjonskontoen for å distribuere den nyeste versjonen av godkjente modeller til QA- og produksjonskontoer. I tillegg kan du se distribusjonshistorikken til modellene og bygge utløsere in AWS CodeBuild.

Du kan skalere konseptene i dette innlegget for å være vert for modeller Amazon Elastic Compute Cloud (Amazon EC2) eller Amazon Elastic Kubernetes-tjeneste (Amazon EKS), samt bygge ut en batch-inferensrørledning.

For å lære mer om å ha separate kontoer som bygger ML-modeller i AWS, se Beste praksis for organisasjonsenheter med AWS-organisasjoner og Trygg oppdatering av modeller i produksjon.

Om forfatterne

Sandeep Verma er en Sr. Prototyping Architect med AWS. Han liker å dykke dypt inn i kundenes utfordringer og bygge prototyper for kunder for å akselerere innovasjon. Han har bakgrunn fra AI/ML, grunnlegger av New Knowledge, og generelt lidenskapelig opptatt av teknologi. På fritiden elsker han å reise og gå på ski med familien.

 Mani Khanuja er en kunstig intelligens og maskinlæringsspesialist SA hos Amazon Web Services (AWS). Hun hjelper kunder som bruker maskinlæring for å løse sine forretningsutfordringer ved hjelp av AWS. Hun bruker mesteparten av tiden på å dykke dypt og undervise kunder på AI / ML-prosjekter relatert til datasyn, naturlig språkbehandling, prognoser, ML i utkanten og mer. Hun er lidenskapelig opptatt av ML på kanten, derfor har hun opprettet et eget laboratorium med selvkjøringssett og produksjonslinje for prototypeproduksjon, hvor hun bruker mye av fritiden.

Saumitra Vikram er en programvareutvikler på Amazon SageMaker-teamet og er basert i Chennai, India. Utenom jobben elsker han å tilbringe tid på løping, fotturer og motorsykkelkjøring gjennom Himalaya.

Sreedevi Srinivasan er ingeniørleder i AWS SageMaker. Hun er lidenskapelig og begeistret for å muliggjøre ML som en plattform som skal transformere hverdagen. Hun fokuserer for tiden på SageMaker Feature Store. På fritiden liker hun å tilbringe tid med familien.

Rupinder Grewal er en Sr Ai/ML spesialistløsningsarkitekt med AWS. Han fokuserer for tiden på servering av modeller og MLOps på SageMaker. Før denne rollen har han jobbet som maskinlæringsingeniør med å bygge og hoste modeller. Utenom jobben liker han å spille tennis og sykle på fjellstier.

Farooq Sabir er senior spesialistløsningsarkitekt for kunstig intelligens og maskinlæring ved AWS. Han har PhD- og MS-grader i elektroteknikk fra University of Texas i Austin og en MS i informatikk fra Georgia Institute of Technology. Hos AWS hjelper han kunder med å formulere og løse forretningsproblemer innen datavitenskap, maskinlæring, datasyn, kunstig intelligens, numerisk optimalisering og relaterte domener. Han har over 16 års arbeidserfaring og er også et fakultetsmedlem ved University of Texas i Dallas, hvor han underviser i et hovedfagskurs i Applied Machine Learning. Basert i Dallas, Texas, elsker han og familien å reise og foreta lange bilturer.