Crie um fluxo de trabalho de MLOps entre contas usando o registro de modelo do Amazon SageMaker

Um pipeline de CI/CD bem projetado é essencial para dimensionar qualquer fluxo de trabalho de desenvolvimento de software com eficácia. Ao projetar pipelines de CI/CD de produção, a AWS recomenda aproveitar várias contas para isolar recursos, conter ameaças de segurança e simplificar o faturamento e os pipelines de ciência de dados não são diferentes. Na AWS, continuamos inovando para simplificar o fluxo de trabalho MLOps.

Nesta postagem, discutimos alguns dos recursos mais recentes entre contas para Amazon Sage Maker que permitem compartilhar e gerenciar melhor grupos de modelos, bem como gerenciar versões de modelos. Para obter um exemplo de estrutura de conta a seguir melhores práticas da unidade organizacional para hospedar modelos usando terminais SageMaker em contas, consulte Orquestrador de carga de trabalho MLOps.

Visão geral da solução

O diagrama a seguir ilustra nossa arquitetura de registro de modelo compartilhado.

Algumas coisas a serem observadas na arquitetura anterior:

As etapas a seguir correspondem ao diagrama:

1. Um cientista de dados registra um modelo da conta de ciência de dados no registro de modelo SageMaker de serviços compartilhados em um PendingManualApproval Estado. O artefato de modelo é criado na conta de serviços compartilhados Serviço de armazenamento simples da Amazon (Amazon S3).
2. Após o registro de uma nova versão do modelo, alguém com autoridade para aprovar o modelo com base nas métricas deve aprovar ou rejeitar o modelo.
3. Após a aprovação do modelo, o pipeline de CI/CD na conta de implantação é acionado para implantar os detalhes do modelo atualizado na conta de controle de qualidade e atualize o estágio como controle de qualidade.
4. Ao passar no processo de teste, você pode optar por ter uma etapa de aprovação manual em seu processo de CI/CD ou fazer com que seu pipeline de CI/CD implante diretamente o modelo para produção e atualize o estágio como Prod.
5. O ambiente de produção faz referência ao modelo e código aprovados, talvez fazendo uma Teste A/B em produção. Em caso de auditoria ou qualquer problema com o modelo, você pode usar Rastreamento de linhagem de ML do Amazon SageMaker. Ele cria e armazena informações sobre as etapas de um fluxo de trabalho de aprendizado de máquina (ML), desde a preparação de dados até a implantação do modelo. Com as informações de rastreamento, você pode reproduzir as etapas do fluxo de trabalho, rastrear o modelo e a linhagem do conjunto de dados e estabelecer governança do modelo e padrões de auditoria.

Ao longo de todo o processo, o registro do modelo compartilhado retém as versões do modelo mais antigo. Isso permite que a equipe reverta as alterações ou até mesmo hospede variantes de produção.

Pré-requisitos

Certifique-se de ter os seguintes pré-requisitos:

• Uma estrutura provisionada de várias contas – Para obter instruções, consulte Práticas recomendadas para unidades organizacionais com o AWS Organizations. Para os fins deste blog, estamos aproveitando as seguintes contas:
  • Conta de ciência de dados – Uma conta na qual os cientistas de dados têm acesso aos dados de treinamento e criam os modelos.
  • Conta de serviços compartilhados – Uma conta central para armazenar os artefatos de modelo (conforme mostrado no diagrama de arquitetura) a serem acessados ​​nas diferentes contas de carga de trabalho.
  • conta de implantação – Uma conta responsável por implantar alterações nas várias contas.
  • Contas de carga de trabalho – Geralmente são ambientes de controle de qualidade e produção em que os engenheiros de software podem criar aplicativos para consumir o modelo de ML.
• Uma conta de implantação com permissões apropriadas – Para obter mais informações sobre as práticas recomendadas com uma estrutura OU de várias contas, consulte UO de implantações. Essa conta é responsável por apontar as contas de carga de trabalho para o modelo desejado no registro do modelo da conta de serviços compartilhados.

Definir políticas entre contas

Seguindo o princípio do privilégio mínimo, primeiro precisamos adicionar políticas de recursos entre contas aos recursos de serviços compartilhados para conceder acesso de outras contas.

Como os artefatos de modelo são armazenados no bucket S3 da conta de serviços compartilhados, a conta de ciência de dados precisa de acesso de leitura/gravação do Amazon S3 para enviar modelos treinados ao Amazon S3. O código a seguir ilustra essa política, mas não a adicione à conta de serviços compartilhados ainda:

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

A conta de implantação precisa apenas receber acesso de leitura ao bucket do S3, para que possa usar os artefatos de modelo para implantar nos endpoints do SageMaker. Também precisamos anexar a seguinte política ao bucket S3 de serviços compartilhados:

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

Combinamos ambas as políticas para obter a seguinte política final. Crie esta política na conta de serviços compartilhados após substituir os IDs de conta apropriados:

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

Para poder implantar um modelo criado em uma conta diferente, o usuário deve ter uma função que tenha acesso às ações do SageMaker, como uma função com o AmazonSageMakerFullAccess política gerenciada. Referir-se Implantar uma versão de modelo de uma conta diferente para obter detalhes adicionais.

Precisamos definir o grupo de modelos que contém as versões de modelo que queremos implantar. Além disso, queremos conceder permissões à conta de ciência de dados. Isso pode ser feito nas etapas a seguir. Referimo-nos às contas da seguinte forma:

• shared_services_account_id – A conta onde está o registro do modelo e onde queremos que o modelo esteja
• data_science_account_id – A conta onde estaremos treinando e, portanto, criando o artefato do modelo real
• implantação_account_id – A conta onde queremos hospedar o endpoint para este modelo

Primeiro, precisamos garantir que os grupos de pacotes do modelo existam. Você pode usar as APIs do Boto3 conforme mostrado no exemplo a seguir ou pode usar o Console de gerenciamento da AWS para criar o pacote de modelo. Referir-se Criar Grupo de Pacotes de Modelo para mais detalhes. Isso pressupõe que você tenha o Boto3 instalado.

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

Para as permissões para este grupo de pacotes modelo, você pode criar um documento JSON semelhante ao seguinte código. Substitua os IDs de conta reais e o nome do grupo de pacotes de modelos por seus próprios valores.

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

Por fim, aplique a política ao grupo de pacotes modelo. Você não pode associar esta política ao grupo de pacotes por meio do console. Você precisa do SDK ou Interface de linha de comando da AWS (AWS CLI) acesso. Por exemplo, o código a seguir usa 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)

Também precisamos de um costume Serviço de gerenciamento de chaves AWS (AWS KMS) para criptografar o modelo enquanto o armazena no Amazon S3. Isso precisa ser feito usando a conta de ciência de dados. No console do AWS KMS, navegue até o Definir permissões de uso de chave página. No Outras contas da AWS seção, escolha Adicionar outra conta da AWS. Insira o número da conta da AWS para a conta de implantação. Você usa essa chave KMS para o trabalho de treinamento do SageMaker. Se você não especificar uma chave KMS para o trabalho de treinamento, o SageMaker usará como padrão uma chave de criptografia do lado do servidor Amazon S3. Uma chave de criptografia do lado do servidor Amazon S3 padrão não pode ser compartilhada ou usada por outra conta da AWS.

A política e as permissões seguem este padrão:

• A política do Amazon S3 especificada em shared_services_account concede permissões à conta de ciência de dados e à conta de implantações
• A política de chave KMS especificada em shared_services_account concede permissões à conta de ciência de dados e à conta de implantações

Precisamos garantir que a conta de serviços compartilhados e a conta de implantação tenham acesso às imagens do Docker usadas para treinar o modelo. Essas imagens geralmente são hospedadas em contas da AWS e o administrador da sua conta pode ajudá-lo a obter acesso, caso ainda não o tenha. Para esta postagem, não criamos nenhuma imagem personalizada do Docker após treinar o modelo e, portanto, não precisamos de nenhuma política específica do Amazon ECR para as imagens.

Nas contas de carga de trabalho (QA ou prod), precisamos criar dois Gerenciamento de acesso e identidade da AWS (IAM) semelhantes ao seguinte. Estes são políticas em linha, o que significa que eles estão incorporados em uma identidade IAM. Isso dá a essas contas acesso ao registro do modelo.

A primeira política em linha permite que uma função acesse o recurso do Amazon S3 na conta de serviços compartilhados que contém o artefato de modelo. Forneça o nome do bucket S3 e seu modelo:

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

A segunda política em linha permite que uma função, que criamos posteriormente, use a chave KMS na conta de serviços compartilhados. Especifique o ID da conta para a conta de serviços compartilhados e o ID da chave 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}"
            ]
        }
    ]
}

Finalmente, precisamos criar uma função IAM para SageMaker. Este papel tem o AmazonSageMakerFullAccess política em anexo. Em seguida, anexamos essas duas políticas em linha à função que criamos. Se você estiver usando uma função de execução existente do SageMaker, anexe essas duas políticas a essa função. Para obter instruções, consulte Criação de funções e anexação de políticas (console).

Agora que definimos as políticas de cada conta, vamos usar um exemplo para vê-la em ação.

Crie e treine um modelo usando um pipeline do SageMaker

Primeiro criamos um pipeline do SageMaker na conta de ciência de dados para realizar processamento de dados, treinamento de modelo e avaliação. Usamos o conjunto de dados habitacionais da Califórnia obtido da biblioteca StatLib. No trecho de código a seguir, usamos um script de pré-processamento personalizado preprocess.py para executar alguma transformação de recurso simples, como dimensionamento de recurso, que pode ser gerado usando o seguinte caderno. Esse script também divide o conjunto de dados em conjuntos de dados de treinamento e teste.

Nós criamos um SKLearnProcessor objeto para executar este script de pré-processamento. No pipeline do SageMaker, criamos uma etapa de processamento (ProcessingStep) para executar o código de processamento usando SKLearnProcessor. Esse código de processamento é chamado quando o pipeline do SageMaker é inicializado. O código que cria o SKLearnProcessor e ProcessingStep são mostrados no código a seguir. Observe que todo o código nesta seção é executado na conta de ciência de dados.

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

Precisamos de uma chave KMS personalizada para criptografar o modelo enquanto o armazenamos no Amazon S3. Veja o seguinte código:

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

Para treinar o modelo, criamos um objeto estimador do TensorFlow. Passamos o ID da chave KMS junto com nosso script de treinamento train.py, tipo de instância de treinamento e contagem. Também criamos um TrainingStep a ser adicionado ao nosso pipeline e adicione o estimador TensorFlow a ele. Veja o seguinte código:

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

Além do treinamento, precisamos realizar a avaliação do modelo, para a qual usamos o erro quadrático médio (MSE) como métrica neste exemplo. o caderno anterior também gera evaluate.py, que usamos para avaliar nosso modelo usando MSE. Também criamos um ProcessingStep para inicializar o script de avaliação do modelo usando um SKLearnProcessor objeto. O código a seguir cria esta etapa:

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

Após a avaliação do modelo, também precisamos de uma etapa para registrar nosso modelo no registro de modelos, se o desempenho do modelo atender aos requisitos. Isso é mostrado no código a seguir usando o RegisterModel degrau. Aqui precisamos especificar o pacote modelo que declaramos na conta de serviços compartilhados. Substitua o pacote Região, conta e modelo pelos seus valores. O nome do modelo usado aqui é modeltest, mas você pode usar qualquer nome de sua escolha.

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

Também precisamos criar os artefatos do modelo para que ele possa ser implantado (usando a outra conta). Para criar o modelo, criamos um CreateModelStep, conforme mostrado no código a seguir:

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

Adicionar condições ao pipeline é feito com um ConditionStep. Neste caso, queremos apenas registrar a nova versão do modelo com o registro do modelo se o novo modelo atender a uma condição de precisão. Veja o seguinte código:

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

Por fim, queremos orquestrar todas as etapas do pipeline para que o pipeline possa ser inicializado:

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

Implantar uma versão de modelo de uma conta diferente

Agora que o modelo foi registrado na conta de serviços compartilhados, precisamos implantar em nossas contas de carga de trabalho usando o pipeline CI/CD na conta de implantação. Já configuramos a função e a política em uma etapa anterior. Usamos o ARN do pacote de modelo para implantar o modelo do registro de modelo. O código a seguir é executado na conta de implantação e é usado para implantar modelos aprovados para controle de qualidade e produção:

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

Conclusão

Nesta postagem, demonstramos como definir as políticas necessárias para uma configuração de várias contas para ML com base no princípio do menor privilégio. Em seguida, mostramos o processo de construção e treinamento dos modelos na conta de ciência de dados. Por fim, usamos o pipeline de CI/CD na conta de implantação para implantar a versão mais recente dos modelos aprovados para controle de qualidade e contas de produção. Além disso, você pode visualizar o histórico de implantação de modelos e construir gatilhos in AWS CodeBuild.

Você pode dimensionar os conceitos neste post para hospedar modelos em Amazon Elastic Compute Nuvem (Amazon EC2) ou Serviço Amazon Elastic Kubernetes (Amazon EKS), bem como criar um pipeline de inferência em lote.

Para saber mais sobre como ter contas separadas que criam modelos de ML na AWS, consulte Práticas recomendadas para unidades organizacionais com o AWS Organizations e Atualize modelos com segurança na produção.

Sobre os autores

Sandeep Verma é arquiteto sênior de prototipagem da AWS. Ele gosta de mergulhar profundamente nos desafios dos clientes e construir protótipos para os clientes para acelerar a inovação. Ele tem experiência em AI/ML, fundador da New Knowledge e geralmente apaixonado por tecnologia. Nas horas vagas, adora viajar e esquiar com a família.

 Mani Khanuja é especialista em inteligência artificial e aprendizado de máquina SA na Amazon Web Services (AWS). Ela ajuda os clientes a usar o aprendizado de máquina para resolver seus desafios de negócios usando o AWS. Ela passa a maior parte do tempo mergulhando fundo e ensinando clientes em projetos de IA / ML relacionados à visão computacional, processamento de linguagem natural, previsão, ML no limite e muito mais. Ela é apaixonada por ML no limite, portanto, ela criou seu próprio laboratório com kit autodirigível e linha de produção de fabricação de protótipos, onde passa grande parte de seu tempo livre.

Saumitra Vikram é um desenvolvedor de software da equipe do Amazon SageMaker e mora em Chennai, na Índia. Fora do trabalho, ele adora correr, fazer caminhadas e andar de moto pelo Himalaia.

Sreedevi Srinivasan é um líder de engenharia no AWS SageMaker. Ela é apaixonada e entusiasmada por habilitar o ML como uma plataforma que deve transformar a vida cotidiana. Atualmente, ela se concentra na SageMaker Feature Store. Em seu tempo livre, ela gosta de passar tempo com sua família.

Rupinder Grewal é um arquiteto de soluções especialista sênior em Ai/ML da AWS. Ele atualmente se concentra em servir de modelos e MLOps no SageMaker. Antes dessa função, ele trabalhou como engenheiro de aprendizado de máquina construindo e hospedando modelos. Fora do trabalho, ele gosta de jogar tênis e andar de bicicleta em trilhas nas montanhas.

Farooq Sabir é arquiteto sênior de soluções de inteligência artificial e aprendizado de máquina na AWS. Ele possui doutorado e mestrado em Engenharia Elétrica pela Universidade do Texas em Austin e mestrado em Ciência da Computação pelo Georgia Institute of Technology. Na AWS, ele ajuda os clientes a formular e resolver seus problemas de negócios em ciência de dados, aprendizado de máquina, visão computacional, inteligência artificial, otimização numérica e domínios relacionados. Ele tem mais de 16 anos de experiência profissional e também é membro adjunto do corpo docente da Universidade do Texas em Dallas, onde ministra um curso de pós-graduação em Aprendizado de Máquina Aplicado. Com sede em Dallas, Texas, ele e sua família adoram viajar e fazer longas viagens.