Zbuduj przepływ pracy MLOps dla wielu kont, korzystając z rejestru modelu Amazon SageMaker

Dobrze zaprojektowany potok CI/CD jest niezbędny do efektywnego skalowania dowolnego przepływu pracy związanego z tworzeniem oprogramowania. Podczas projektowania produkcyjnych potoków CI/CD AWS zaleca wykorzystanie wielu kont w celu odizolowania zasobów, powstrzymania zagrożeń bezpieczeństwa i uproszczenia rozliczeń, a potoki analizy danych nie różnią się niczym. W AWS nadal wprowadzamy innowacje, aby uprościć przepływ pracy MLOps.

W tym poście omawiamy niektóre z nowszych funkcji międzykontowych Amazon Sage Maker które pozwalają lepiej udostępniać i zarządzać grupami modeli, a także zarządzać wersjami modeli. Aby zobaczyć przykładową strukturę konta do naśladowania najlepsze praktyki jednostek organizacyjnych aby hostować modele przy użyciu punktów końcowych SageMaker na różnych kontach, patrz Orkiestrator obciążeń MLOps.

Omówienie rozwiązania

Poniższy diagram ilustruje naszą współużytkowaną architekturę rejestru modelu.

Kilka rzeczy, na które należy zwrócić uwagę w poprzedniej architekturze:

Poniższe kroki odpowiadają schematowi:

1. Analityk danych rejestruje model z konta nauki o danych w rejestrze modeli usług udostępnionych SageMaker w a PendingManualApproval państwo. Artefakt modelu jest tworzony na koncie usług udostępnionych Usługa Amazon Simple Storage Łyżka (Amazon S3).
2. Po zarejestrowaniu nowej wersji modelu osoba z uprawnieniami do zatwierdzania modelu na podstawie metryk powinna zatwierdzić lub odrzucić model.
3. Po zatwierdzeniu modelu potok CI/CD na koncie wdrożenia jest uruchomione do rozmieszczenia zaktualizowane szczegóły modelu na koncie QA i zaktualizuj etap jako QA.
4. Po pomyślnym przejściu procesu testowania możesz zdecydować się na etap ręcznego zatwierdzania w ramach procesu CI/CD lub bezpośrednio wdrożyć model do produkcji i zaktualizować etap jako Prod.
5. Środowisko produkcyjne odwołuje się do zatwierdzonego modelu i kodu, być może robiąc Test A/B w produkcji. W przypadku audytu lub jakiegokolwiek problemu z modelem możesz skorzystać Śledzenie rodowodu Amazon SageMaker ML. Tworzy i przechowuje informacje o krokach przepływu pracy uczenia maszynowego (ML) od przygotowania danych do wdrożenia modelu. Dzięki informacjom o śledzeniu można odtwarzać etapy przepływu pracy, śledzić pochodzenie modelu i zestawu danych oraz ustanawiać standardy zarządzania modelami i inspekcji.

W trakcie całego procesu udostępniony rejestr modeli zachowuje starsze wersje modeli. Pozwala to zespołowi wycofać zmiany, a nawet hostować warianty produkcyjne.

Wymagania wstępne

Upewnij się, że masz następujące wymagania wstępne:

• Udostępniona struktura wielu kont – Aby uzyskać instrukcje, patrz Najlepsze praktyki dla jednostek organizacyjnych z organizacjami AWS. Na potrzeby tego bloga korzystamy z następujących kont:
  • Konto nauki o danych – Konto, na którym analitycy danych mają dostęp do danych treningowych i tworzą modele.
  • Konto usług wspólnych – Konto centralne do przechowywania artefaktów modelu (jak pokazano na diagramie architektury), które mają być dostępne na różnych kontach obciążenia.
  • Konto wdrożenia – Konto odpowiedzialne za wdrażanie zmian na różnych kontach.
  • Konta obciążenia – Są to zazwyczaj środowiska QA i prod, w których inżynierowie oprogramowania są w stanie budować aplikacje korzystające z modelu ML.
• Konto wdrożenia z odpowiednimi uprawnieniami – Aby uzyskać więcej informacji na temat najlepszych praktyk ze strukturą jednostek organizacyjnych z wieloma kontami, zobacz Jednostka organizacyjna wdrożeń. To konto jest odpowiedzialne za kierowanie kont obciążeń do żądanego modelu w rejestrze modeli kont usług udostępnionych.

Zdefiniuj zasady dotyczące wielu kont

Zgodnie z zasadą najniższych uprawnień, najpierw musimy dodać zasady dotyczące zasobów między kontami do zasobów usług współdzielonych, aby przyznać dostęp z innych kont.

Ponieważ artefakty modelu są przechowywane w zasobniku S3 konta usług współdzielonych, konto nauki o danych wymaga dostępu do odczytu/zapisu usługi Amazon S3 w celu wypychania przeszkolonych modeli do usługi Amazon S3. Poniższy kod ilustruje tę zasadę, ale nie dodawaj jej jeszcze do konta usług wspólnych:

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

Konto wdrażania musi mieć tylko dostęp do odczytu do zasobnika S3, aby mogło używać artefaktów modelu do wdrażania w punktach końcowych SageMaker. Musimy również dołączyć następującą politykę do zasobnika usług wspólnych S3:

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

Łączymy obie polisy, aby uzyskać następującą ostateczną polisę. Utwórz tę politykę na koncie usług wspólnych po zastąpieniu odpowiednich identyfikatorów kont:

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

Aby móc wdrożyć model utworzony na innym koncie, użytkownik musi mieć rolę z dostępem do działań SageMaker, taką jak rola z AmazonSageMakerFullAccess zarządzana polityka. Odnosić się do Wdróż wersję modelu z innego konta aby uzyskać dodatkowe informacje.

Musimy zdefiniować grupę modeli zawierającą wersje modeli, które chcemy wdrożyć. Ponadto chcemy przyznać uprawnienia do konta nauki o danych. Można to osiągnąć w następujących krokach. Odnosimy się do rachunków w następujący sposób:

• identyfikator_konta_wspólnych usług_usług – Konto, na którym znajduje się rejestr modeli i gdzie chcemy, aby znajdował się model
• data_science_account_id – Konto, na którym będziemy trenować, a tym samym tworzyć rzeczywisty model artefaktu
• identyfikator_konta_wdrożenia – Konto, na którym chcemy hostować punkt końcowy dla tego modelu

Najpierw musimy upewnić się, że istnieją grupy pakietów modeli. Możesz użyć interfejsów API Boto3, jak pokazano w poniższym przykładzie, lub możesz użyć Konsola zarządzania AWS aby utworzyć pakiet modelu. Odnosić się do Utwórz grupę pakietów modelu po więcej szczegółów. Zakłada się, że masz zainstalowany Boto3.

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

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

)

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

Aby uzyskać uprawnienia dla tej grupy pakietów modelowych, możesz utworzyć dokument JSON podobny do następującego kodu. Zastąp rzeczywiste identyfikatory kont i nazwę grupy pakietów modelu własnymi wartościami.

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

Na koniec zastosuj zasady do grupy pakietów modelowych. Tej zasady nie można powiązać z grupą pakietów za pośrednictwem konsoli. Potrzebujesz zestawu SDK lub Interfejs wiersza poleceń AWS (AWS CLI). Na przykład poniższy kod używa 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)

Potrzebujemy również zwyczaju Usługa zarządzania kluczami AWS (AWS KMS) klucz do zaszyfrowania modelu podczas przechowywania go w Amazon S3. Należy to zrobić przy użyciu konta nauki o danych. W konsoli AWS KMS przejdź do pliku Zdefiniuj uprawnienia do korzystania z klucza strona. w Inne konta AWS Sekcja, wybierz Dodaj kolejne konto AWS. Wprowadź numer konta AWS dla konta wdrożenia. Używasz tego klucza KMS do zadania szkoleniowego SageMaker. Jeśli nie określisz klucza KMS dla zadania szkoleniowego, SageMaker domyślnie użyje klucza szyfrowania po stronie serwera Amazon S3. Domyślny klucz szyfrowania po stronie serwera Amazon S3 nie może być udostępniany ani używany przez inne konto AWS.

Zasady i uprawnienia są zgodne z tym wzorem:

• Polityka Amazon S3 określona w shared_services_account nadaje uprawnienia do konta nauki o danych i konta wdrożeń
• Zasady kluczy KMS określone w shared_services_account nadaje uprawnienia do konta nauki o danych i konta wdrożeń

Musimy upewnić się, że konto usług wspólnych i konto wdrożenia mają dostęp do obrazów platformy Docker, które zostały użyte do szkolenia modelu. Te obrazy są zazwyczaj hostowane na kontach AWS, a administrator konta może pomóc Ci uzyskać dostęp, jeśli jeszcze go nie masz. W tym poście nie tworzymy żadnych niestandardowych obrazów platformy Docker po wytrenowaniu modelu i dlatego nie potrzebujemy żadnych konkretnych zasad Amazon ECR dla obrazów.

Na kontach obciążenia (QA lub prod) musimy utworzyć dwa AWS Zarządzanie tożsamością i dostępem (IAM) zasady podobne do poniższych. To są zasady inline, co oznacza, że ​​są one osadzone w tożsamości IAM. Daje to tym kontom dostęp do rejestru modeli.

Pierwsza zasada wbudowana umożliwia roli dostęp do zasobu Amazon S3 na koncie usług udostępnionych, które zawiera artefakt modelu. Podaj nazwę łyżki S3 i swój model:

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

Druga polityka wbudowana umożliwia roli, którą utworzymy później, używanie klucza KMS na koncie usług wspólnych. Określ identyfikator konta dla konta usług wspólnych i identyfikator klucza 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}"
            ]
        }
    ]
}

Wreszcie musimy utwórz rolę IAM dla SageMakera. Ta rola ma AmazonSageMakerFullAccess dołączona polisa. Następnie dołączamy te dwie wbudowane zasady do utworzonej przez nas roli. Jeśli używasz istniejącej roli wykonawczej SageMaker, dołącz te dwie zasady do tej roli. Aby uzyskać instrukcje, patrz Tworzenie ról i dołączanie polityk (konsola).

Teraz, gdy zdefiniowaliśmy zasady dla każdego konta, użyjmy przykładu, aby zobaczyć to w działaniu.

Zbuduj i wytrenuj model przy użyciu potoku SageMaker

Najpierw tworzymy potok SageMaker na koncie nauki o danych do przeprowadzania przetwarzania danych, trenowania modeli i oceny. Korzystamy z zestawu danych mieszkaniowych w Kalifornii uzyskanych z biblioteki StatLib. W poniższym fragmencie kodu używamy niestandardowego skryptu przetwarzania wstępnego preprocess.py wykonać pewne proste przekształcenia funkcji, takie jak skalowanie funkcji, które można wygenerować za pomocą następujących elementów notatnik. Ten skrypt również dzieli zestaw danych na treningowe i testowe zestawy danych.

Tworzymy SKLearnProcessor obiekt, aby uruchomić ten skrypt przetwarzania wstępnego. W potoku SageMaker tworzymy krok przetwarzania (ProcessingStep), aby uruchomić kod przetwarzania przy użyciu SKLearnProcessor. Ten kod przetwarzania jest wywoływany podczas inicjowania potoku SageMaker. Kod tworzący SKLearnProcessor i ProcessingStep są pokazane w poniższym kodzie. Należy zauważyć, że cały kod w tej sekcji jest uruchamiany na koncie nauki o danych.

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

Potrzebujemy niestandardowego klucza KMS do zaszyfrowania modelu podczas przechowywania go w Amazon S3. Zobacz następujący kod:

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

Aby wytrenować model, tworzymy obiekt estymatora TensorFlow. Przekazujemy mu identyfikator klucza KMS wraz z naszym skryptem szkoleniowym train.py, typ instancji szkoleniowej i liczba. Tworzymy również TrainingStep do dodania do naszego potoku i dodaj do niego estymator TensorFlow. Zobacz następujący kod:

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

Oprócz szkolenia musimy przeprowadzić ocenę modelu, dla której w tym przykładzie jako metrykę używamy błędu średniokwadratowego (MSE). The wcześniejszy notatnik generuje również evaluate.py, którego używamy do oceny naszego modelu za pomocą MSE. Tworzymy również ProcessingStep zainicjować skrypt oceny modelu przy użyciu pliku SKLearnProcessor obiekt. Poniższy kod tworzy ten krok:

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

Po ewaluacji modelu potrzebujemy również kroku, aby zarejestrować nasz model w rejestrze modeli, jeśli wydajność modelu spełnia wymagania. Jest to pokazane w poniższym kodzie przy użyciu RegisterModel krok. Tutaj musimy określić pakiet modelowy, który zadeklarowaliśmy na koncie usług wspólnych. Zastąp region, konto i pakiet modelu swoimi wartościami. Zastosowana tutaj nazwa modelu to modeltest, ale możesz użyć dowolnej nazwy.

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

Musimy również utworzyć artefakty modelu, aby można je było wdrożyć (przy użyciu drugiego konta). Do stworzenia modelu tworzymy a CreateModelStep, jak pokazano w następującym kodzie:

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

Dodawanie warunków do potoku odbywa się za pomocą a ConditionStep. W takim przypadku chcemy zarejestrować nową wersję modelu w rejestrze modeli tylko wtedy, gdy nowy model spełnia warunek dokładności. Zobacz następujący kod:

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

Na koniec chcemy zorganizować wszystkie kroki potoku, aby można było zainicjować potok:

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

Wdróż wersję modelu z innego konta

Teraz, gdy model został zarejestrowany na koncie usług udostępnionych, musimy przeprowadzić wdrożenie na naszych kontach obciążeń przy użyciu potoku CI/CD na koncie wdrożenia. Skonfigurowaliśmy już rolę i politykę we wcześniejszym kroku. Używamy pakietu modelu ARN do wdrażania modelu z rejestru modeli. Poniższy kod jest uruchamiany na koncie wdrożenia i służy do wdrażania zatwierdzonych modeli do kontroli jakości i produkcji:

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

Wnioski

W tym poście pokazaliśmy, jak skonfigurować zasady potrzebne do konfiguracji wielu kont dla ML w oparciu o zasadę najmniejszych uprawnień. Następnie pokazaliśmy proces budowania i uczenia modeli na koncie Data Science. Na koniec użyliśmy potoku CI/CD na koncie wdrożenia, aby wdrożyć najnowszą wersję zatwierdzonych modeli na kontach kontroli jakości i produkcji. Dodatkowo możesz przeglądać historię wdrażania modeli i budować wyzwalacze in Tworzenie kodu AWS.

Możesz skalować koncepcje w tym poście, aby hostować modele Elastyczna chmura obliczeniowa Amazon (Amazon EC2) lub Elastyczna usługa Amazon Kubernetes (Amazon EKS), a także zbudować potok wnioskowania wsadowego.

Aby dowiedzieć się więcej o posiadaniu osobnych kont budujących modele ML w AWS, zobacz Najlepsze praktyki dla jednostek organizacyjnych z organizacjami AWS i Bezpiecznie aktualizuj modele w produkcji.

O autorach

Sandeep Verma jest starszym architektem prototypowania w AWS. Lubi zagłębiać się w wyzwania klientów i budować prototypy dla klientów w celu przyspieszenia innowacji. Ma doświadczenie w AI/ML, jest założycielem New Knowledge i ogólnie pasjonuje się technologią. W wolnym czasie uwielbia podróżować i jeździć na nartach z rodziną.

 Mani Chanuja jest specjalistą ds. sztucznej inteligencji i uczenia maszynowego SA w Amazon Web Services (AWS). Pomaga klientom korzystającym z uczenia maszynowego w rozwiązywaniu wyzwań biznesowych za pomocą AWS. Spędza większość czasu nurkując głęboko i ucząc klientów w projektach AI/ML związanych z wizją komputerową, przetwarzaniem języka naturalnego, prognozowaniem, ML na krawędzi i nie tylko. Pasjonuje się ML na krawędzi, dlatego stworzyła własne laboratorium z zestawem do samodzielnego prowadzenia i linią produkcyjną prototypów, w którym spędza dużo wolnego czasu.

Saumitry Vikrama jest programistą w zespole Amazon SageMaker i ma siedzibę w Chennai w Indiach. Poza pracą uwielbia biegać, trekkingować i jeździć na motorze po Himalajach.

Sreedevi Srinivasan jest liderem inżynierii w AWS SageMaker. Jest pełna pasji i podekscytowana udostępnieniem ML jako platformy, która ma zmienić codzienne życie. Obecnie koncentruje się na SageMaker Feature Store. W wolnym czasie lubi spędzać czas z rodziną.

Rozbijacz Grewal jest Sr Ai/ML Specialist Solutions Architect z AWS. Obecnie skupia się na serwowaniu modeli i MLOpów na SageMakerze. Wcześniej pracował jako inżynier ds. uczenia maszynowego budując i hostując modele. Poza pracą lubi grać w tenisa i jeździć na rowerze po górskich szlakach.

Farooq Sabir jest starszym architektem rozwiązań w zakresie sztucznej inteligencji i uczenia maszynowego w AWS. Posiada stopień doktora i magistra inżynierii elektrycznej uzyskany na Uniwersytecie Teksańskim w Austin oraz tytuł magistra informatyki uzyskany na Georgia Institute of Technology. W AWS pomaga klientom formułować i rozwiązywać ich problemy biznesowe w zakresie nauki o danych, uczenia maszynowego, wizji komputerowej, sztucznej inteligencji, optymalizacji numerycznej i pokrewnych dziedzin. Ma ponad 16-letnie doświadczenie zawodowe i jest także adiunktem na Uniwersytecie Teksańskim w Dallas, gdzie prowadzi kurs podyplomowy w zakresie stosowanego uczenia maszynowego. Mieszka w Dallas w Teksasie, on i jego rodzina uwielbiają podróżować i robić długie wycieczki samochodowe.