Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Amazon Web Services

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Amazon Web Services

Amazon Sage Maker é um serviço totalmente gerenciado que permite que desenvolvedores e cientistas de dados criem, treinem e implantem modelos de aprendizado de máquina (ML) em qualquer escala com rapidez e facilidade. O SageMaker simplifica a implantação de modelos na produção diretamente por meio de chamadas de API para o serviço. Os modelos são empacotados em contêineres para implantações robustas e escalonáveis. Embora forneça vários pontos de entrada, como o SageMaker Python SDK, AWS SDKs, o console SageMaker e Estúdio Amazon SageMaker notebooks para simplificar o processo de treinamento e implantação de modelos de ML em escala, os clientes ainda estão procurando maneiras melhores de implantar seus modelos para testes de playground e otimizar implantações de produção.

Estamos lançando duas novas maneiras de simplificar o processo de empacotamento e implantação de modelos usando o SageMaker.

Nesta postagem, apresentamos o novo SageMaker Python SDK ModelBuilder experiência, que visa minimizar a curva de aprendizado para novos usuários do SageMaker, como cientistas de dados, ao mesmo tempo que ajuda engenheiros MLOps experientes a maximizar a utilização dos serviços de hospedagem do SageMaker. Ele reduz a complexidade da configuração e implantação inicial e fornece orientação sobre as melhores práticas para aproveitar todos os recursos do SageMaker. Fornecemos informações detalhadas e exemplos do GitHub para esse novo recurso do SageMaker.

O outro lançamento é usar a nova experiência de implantação interativa no SageMaker Studio. Discutimos isso na Parte 2.

A implantação de modelos em um endpoint SageMaker envolve uma série de etapas para preparar o modelo para ser hospedado em um endpoint SageMaker. Isso envolve colocar os artefatos do modelo no formato e estrutura corretos, criar código de inferência e especificar detalhes essenciais como o URL da imagem do modelo, Serviço de armazenamento simples da Amazon (Amazon S3) localização de artefatos do modelo, etapas de serialização e desserialização e informações necessárias Gerenciamento de acesso e identidade da AWS (IAM) para facilitar permissões de acesso apropriadas. Depois disso, uma configuração de endpoint requer a determinação do tipo de inferência e a configuração dos respectivos parâmetros, como tipos de instância, contagens e distribuição de tráfego entre variantes de modelo.

Para ajudar ainda mais nossos clientes ao usar a hospedagem SageMaker, apresentamos o novo ModelBuilder classe no SageMaker Python SDK, que traz os seguintes benefícios principais ao implantar modelos em endpoints SageMaker:

  • Unifica a experiência de implantação entre estruturas – A nova experiência fornece um fluxo de trabalho consistente para implantação de modelos construídos usando diferentes estruturas como PyTorch, TensorFlow e XGBoost. Isso simplifica o processo de implantação.
  • Automatiza a implantação do modelo – Tarefas como seleção de contêineres apropriados, captura de dependências e manipulação de serialização/desserialização são automatizadas, reduzindo o esforço manual necessário para implantação.
  • Fornece uma transição suave do endpoint local para o endpoint hospedado pelo SageMaker – Com alterações mínimas no código, os modelos podem ser facilmente transferidos do teste local para a implantação em um endpoint SageMaker. Os logs dinâmicos tornam a depuração perfeita.

No geral, SageMaker ModelBuilder simplifica e agiliza o processo de empacotamento de modelo para inferência do SageMaker, manipulando detalhes de baixo nível e fornece ferramentas para teste, validação e otimização de endpoints. Isso melhora a produtividade do desenvolvedor e reduz erros.

Nas seções a seguir, nos aprofundaremos nos detalhes desse novo recurso. Também discutimos como implantar modelos na hospedagem SageMaker usando ModelBuilder, o que simplifica o processo. Em seguida, mostraremos alguns exemplos de diferentes estruturas para implantar modelos tradicionais de ML e modelos básicos que potencializam casos de uso de IA generativa.

Conhecendo o SageMaker ModelBuilder

O novo ModelBuilder é uma classe Python focada em pegar modelos de ML construídos usando estruturas, como XGBoost ou PyTorch, e convertê-los em modelos que estão prontos para implantação no SageMaker. ModelBuilder fornece uma build() função, que gera os artefatos de acordo com o servidor modelo, e um deploy() função para implantar localmente ou em um endpoint do SageMaker. A introdução deste recurso simplifica a integração dos modelos com o ambiente SageMaker, otimizando-os quanto ao desempenho e escalabilidade. O diagrama a seguir mostra como ModelBuilder funciona em alto nível.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.

Classe ModelBuilder

A Construtor de Modelo class fornece diferentes opções de personalização. No entanto, para implantar o modelo de estrutura, o construtor do modelo espera apenas o modelo, a entrada, a saída e a função:

class ModelBuilder( model, # model id or model object role_arn, # IAM role schema_builder, # defines the input and output mode, # select between local deployment and depoy to SageMaker Endpoints ...
)

Construtor de esquema

A Construtor de esquema class permite que você defina a entrada e a saída do seu endpoint. Ele permite que o construtor de esquema gere as funções de empacotamento correspondentes para serializar e desserializar a entrada e a saída. O arquivo de classe a seguir fornece todas as opções de personalização:

class SchemaBuilder( sample_input: Any, sample_output: Any, input_translator: CustomPayloadTranslator = None, output_translator: CustomPayloadTranslator = None
)

No entanto, na maioria dos casos, apenas amostras de entrada e saída funcionariam. Por exemplo:

input = "How is the demo going?"
output = "Comment la démo va-t-elle?"
schema = SchemaBuilder(input, output)

Ao fornecer entrada e saída de amostra, SchemaBuilder pode determinar automaticamente as transformações necessárias, tornando o processo de integração mais simples. Para casos de uso mais avançados, há flexibilidade para fornecer funções de tradução personalizadas para entrada e saída, garantindo que estruturas de dados mais complexas também possam ser tratadas com eficiência. Demonstramos isso nas seções a seguir, implantando diferentes modelos com várias estruturas usando ModelBuilder.

Experiência em modo local

Neste exemplo, usamos ModelBuilder para implantar o modelo XGBoost localmente. Você pode usar o Modo para alternar entre testes locais e implantação em um endpoint SageMaker. Primeiro treinamos o modelo XGBoost (localmente ou no SageMaker) e armazenamos os artefatos do modelo no diretório de trabalho:

# Train the model
model = XGBClassifier()
model.fit(X_train, y_train)
model.save_model(model_dir + "/my_model.xgb")

Em seguida, criamos um objeto ModelBuilder passando o objeto modelo real, o SchemaBuilder que usa os objetos de entrada e saída de teste de amostra (a mesma entrada e saída que usamos ao treinar e testar o modelo) para inferir a serialização necessária. Observe que usamos Mode.LOCAL_CONTAINER para especificar uma implantação local. Depois disso, chamamos o construir função para identificar automaticamente a imagem do contêiner da estrutura suportada, bem como verificar dependências. Veja o seguinte código:

model_builder_local = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, mode=Mode.LOCAL_CONTAINER
)
xgb_local_builder = model_builder_local.build()

Finalmente, podemos chamar o deploy função no objeto de modelo, que também fornece registro em tempo real para facilitar a depuração. Você não precisa especificar o tipo ou a contagem da instância porque o modelo será implantado localmente. Se você forneceu esses parâmetros, eles serão ignorados. Esta função retornará o objeto preditor que podemos usar para fazer previsões com os dados de teste:

# note: all the serialization and deserialization is handled by the model builder.
predictor_local = xgb_local_builder.deploy(
# instance_type='ml.c5.xlarge',
# initial_instance_count=1
) # Make prediction for test data. predictor_local.predict(X_test)

Opcionalmente, você também pode controlar o carregamento do modelo e o pré-processamento e pós-processamento usando InferenceSpec. Fornecemos mais detalhes posteriormente nesta postagem. Usando LOCAL_CONTAINER é uma ótima maneira de testar seu script localmente antes de implantá-lo em um endpoint SageMaker.

Consulte o construtor de modelo-xgboost.ipynb exemplo para testar a implantação local e em um endpoint SageMaker usando ModelBuilder.

Implante modelos tradicionais em endpoints do SageMaker

Nos exemplos a seguir, mostramos como usar ModelBuilder para implantar modelos tradicionais de ML.

Modelos XGBoost

Semelhante à seção anterior, você pode implantar um modelo XGBoost em um endpoint SageMaker alterando o mode parâmetro ao criar o ModelBuilder objeto:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, mode=Mode.SAGEMAKER_ENDPOINT
)
xgb_builder = model_builder.build()
predictor = xgb_builder.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1
)

Observe que ao implantar em endpoints do SageMaker, você precisa especificar o tipo de instância e a contagem de instâncias ao chamar o método deploy função.

Consulte o construtor de modelo-xgboost.ipynb exemplo para implantar um modelo XGBoost.

Modelos Tritão

Você pode usar ModelBuilder para servir modelos PyTorch em Servidor de Inferência Triton. Para isso, você precisa especificar o model_server parâmetro como ModelServer.TRITON, passe um modelo e tenha um SchemaBuilder objeto, que requer entradas e saídas de amostra do modelo. ModelBuilder cuidará do resto para você.

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, model_server=ModelServer.TRITON, mode=Mode.SAGEMAKER_ENDPOINT
) triton_builder = model_builder.build() predictor = triton_builder.deploy( instance_type='ml.g4dn.xlarge', initial_instance_count=1
)

Consulte construtor de modelo-triton.ipynb para implantar um modelo com Triton.

Abraçando modelos de rosto

Neste exemplo, mostramos como implantar um modelo de transformador pré-treinado fornecido pelo Hugging Face para o SageMaker. Queremos usar o rosto do abraço pipeline para carregar o modelo, então criamos uma especificação de inferência personalizada para ModelBuilder:

# custom inference spec with hugging face pipeline
class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return pipeline("translation_en_to_fr", model="t5-small") def invoke(self, input, model): return model(input) inf_spec = MyInferenceSpec()

Também definimos a entrada e a saída da carga de trabalho de inferência definindo o SchemaBuilder objeto com base na entrada e saída do modelo:

schema = SchemaBuilder(value,output)

Então criamos o ModelBuilder objeto e implantar o modelo em um endpoint SageMaker seguindo a mesma lógica mostrada no outro exemplo:

builder = ModelBuilder( inference_spec=inf_spec, mode=Mode.SAGEMAKER_ENDPOINT, # you can change it to Mode.LOCAL_CONTAINER for local testing schema_builder=schema, image_uri=image,
)
model = builder.build( role_arn=execution_role, sagemaker_session=sagemaker_session,
)
predictor = model.deploy( initial_instance_count=1, instance_type='ml.g5.2xlarge'
)

Consulte model-builder-huggingface.ipynb para implantar um modelo de pipeline Hugging Face.

Implante modelos básicos em endpoints do SageMaker

Nos exemplos a seguir, mostramos como usar ModelBuilder para implantar modelos básicos. Assim como os modelos mencionados anteriormente, basta o ID do modelo.

Abraçando o Face Hub

Se você quiser implantar um modelo básico de Abraçando o Face Hub, tudo que você precisa fazer é passar o ID do modelo pré-treinado. Por exemplo, o trecho de código a seguir implanta o metal-lhama/Llama-2-7b-hf modelo localmente. Você pode alterar o modo para Mode.SAGEMAKER_ENDPOINT para implantar em endpoints do SageMaker.

model_builder = ModelBuilder( model="meta-llama/Llama-2-7b-hf", schema_builder=SchemaBuilder(sample_input, sample_output), model_path="/home/ec2-user/SageMaker/LoadTestResources/meta-llama2-7b", #local path where artifacts will be saved mode=Mode.LOCAL_CONTAINER, env_vars={ # Llama 2 is a gated model and requires a Hugging Face Hub token. "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>" }
)
model = model_builder.build()
local_predictor = model.deploy()

Para modelos fechados no Hugging Face Hub, você precisa solicitar acesso via Hugging Face Hub e usar a chave associada, passando-a como a variável de ambiente HUGGING_FACE_HUB_TOKEN. Alguns modelos Hugging Face podem exigir código remoto confiável. Também pode ser definido como uma variável de ambiente usando HF_TRUST_REMOTE_CODE. Por padrão, ModelBuilder usará uma inferência de geração de texto de rosto de abraço (TGI) como o contêiner subjacente para modelos Hugging Face. Se você quiser usar o AWS Large Model Inference (LMI) contêineres, você pode configurar o model_server parâmetro como ModelServer.DJL_SERVING quando você configura o ModelBuilder objeto.

Uma característica interessante de ModelBuilder é a capacidade de executar o ajuste local dos parâmetros do contêiner quando você usa LOCAL_CONTAINER modo. Este recurso pode ser usado simplesmente executando tuned_model = model.tune().

Consulte demo-model-builder-huggingface-llama2.ipynb para implantar um modelo Hugging Face Hub.

SageMaker JumpStart

JumpStart do Amazon SageMaker também oferece vários modelos de base pré-treinados. Assim como no processo de implantação de um modelo do Hugging Face Hub, o ID do modelo é necessário. Implantar um modelo SageMaker JumpStart em um endpoint SageMaker é tão simples quanto executar o seguinte código:

model_builder = ModelBuilder( model="huggingface-llm-falcon-7b-bf16", schema_builder=SchemaBuilder(sample_input, sample_output), role_arn=execution_role
) sm_ep_model = model_builder.build() predictor = sm_ep_model.deploy()

Para todos os IDs de modelo SageMaker JumpStart disponíveis, consulte Algoritmos integrados com tabela de modelo pré-treinada. Referir-se model-builder-jumpstart-falcon.ipynb para implantar um modelo SageMaker JumpStart.

Componente de inferência

ModelBulder permite que você use o novo recurso de componente de inferência no SageMaker para implantar modelos. Para obter mais informações sobre componentes de inferência, consulte Reduza os custos de implantação de modelo em 50%, em média, usando os recursos mais recentes do SageMaker. Você pode usar componentes de inferência para implantação com ModelBuilder especificando endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED no deploy() método. Você também pode usar o tune() método, que busca o número ideal de aceleradores e o modifica se necessário.

resource_requirements = ResourceRequirements( requests={ "num_accelerators": 4, "memory": 1024, "copies": 1, }, limits={},
) goldfinch_predictor_2 = model_2.deploy( mode=Mode.SAGEMAKER_ENDPOINT, endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED, ... )

Consulte model-builder-inference-component.ipynb para implantar um modelo como um componente de inferência.

Personalize a classe ModelBuilder

A ModelBuilder class permite que você personalize o carregamento do modelo usando InferenceSpec.

Além disso, você pode controlar a serialização e desserialização de carga e resposta e personalizar o pré-processamento e o pós-processamento usando CustomPayloadTranslator. Além disso, quando precisar estender nossos contêineres pré-construídos para implantação de modelo no SageMaker, você pode usar ModelBuilder para lidar com o processo de embalagem do modelo. Na seção a seguir, fornecemos mais detalhes sobre esses recursos.

Especificação de inferência

Especificação de inferência oferece uma camada adicional de personalização. Ele permite definir como o modelo é carregado e como ele tratará as solicitações de inferência recebidas. Através InferenceSpec, você pode definir procedimentos de carregamento personalizados para seus modelos, ignorando os mecanismos de carregamento padrão. Essa flexibilidade é particularmente benéfica ao trabalhar com modelos não padronizados ou pipelines de inferência personalizados. O método invocar pode ser customizado, proporcionando a capacidade de personalizar como o modelo processa as solicitações recebidas (pré-processamento e pós-processamento). Essa customização pode ser essencial para garantir que o processo de inferência esteja alinhado às necessidades específicas do modelo. Veja o seguinte código:

class InferenceSpec(abc.ABC): @abc.abstractmethod def load(self, model_dir: str): pass @abc.abstractmethod def invoke(self, input_object: object, model: object): pass

O código a seguir mostra um exemplo de uso desta classe:

class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return // model object def invoke(self, input, model): return model(input)

Tradutor de Payload personalizado

Ao invocar endpoints SageMaker, os dados são enviados por meio de cargas HTTP com diferentes tipos MIME. Por exemplo, uma imagem enviada ao endpoint para inferência precisa ser convertida em bytes no lado do cliente e enviada por meio da carga HTTP para o endpoint. Quando o endpoint recebe a carga útil, ele precisa desserializar a string de bytes de volta para o tipo de dados esperado pelo modelo (também conhecido como desserialização do lado do servidor). Depois que o modelo termina a previsão, os resultados precisam ser serializados em bytes que podem ser enviados de volta por meio da carga HTTP para o usuário ou cliente. Quando o cliente recebe os dados de bytes de resposta, ele precisa realizar a desserialização do lado do cliente para converter os dados de bytes de volta para o formato de dados esperado, como JSON. No mínimo, você precisa converter os dados para o seguinte (conforme numerado no diagrama a seguir):

  1. Serialização de solicitação de inferência (tratada pelo cliente)
  2. Desserialização de solicitação de inferência (tratada pelo servidor ou algoritmo)
  3. Invocando o modelo contra a carga útil
  4. Enviando carga útil de resposta de volta
  5. Serialização de resposta de inferência (tratada pelo servidor ou algoritmo)
  6. Desserialização da resposta de inferência (tratada pelo cliente)

O diagrama a seguir mostra o processo de serialização e desserialização durante o processo de invocação.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.

No trecho de código a seguir, mostramos um exemplo de CustomPayloadTranslator quando é necessária personalização adicional para lidar com a serialização e a desserialização no lado do cliente e do servidor, respectivamente:

from sagemaker.serve import CustomPayloadTranslator # request translator
class MyRequestTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on client side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the input payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on server side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object # response translator class MyResponseTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on server side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the response payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on client side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object

No demo-model-builder-pytorch.ipynb notebook, demonstramos como implantar facilmente um modelo PyTorch em um endpoint SageMaker usando ModelBuilder com o CustomPayloadTranslator e os votos de InferenceSpec classe.

Modelo de estágio para implantação

Se quiser preparar o modelo para inferência ou no registro do modelo, você pode usar model.create() or model.register(). O modelo habilitado é criado no serviço e você pode implantá-lo posteriormente. Veja o seguinte código:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, )
deployable_model = model_builder.build() deployable_model.create() # deployable_model.register() for model registry

Use contêineres personalizados

SageMaker fornece imagens Docker pré-construídas por seus algoritmos integrados e pelas estruturas de aprendizagem profunda suportadas usadas para treinamento e inferência. Se um contêiner SageMaker pré-construído não atender a todos os seus requisitos, você poderá estender a imagem existente para acomodar suas necessidades. Ao estender uma imagem pré-construída, você pode usar as bibliotecas e configurações de aprendizado profundo incluídas sem precisar criar uma imagem do zero. Para obter mais detalhes sobre como estender os contêineres pré-construídos, consulte o documento do SageMaker. ModelBuilder oferece suporte a casos de uso ao trazer seus próprios contêineres estendidos de nossos contêineres Docker pré-construídos.

Para usar sua própria imagem de contêiner neste caso, você precisa definir os campos image_uri e model_server ao definir ModelBuilder:

model_builder = ModelBuilder( model=model, # Pass in the actual model object. its "predict" method will be invoked in the endpoint. schema_builder=SchemaBuilder(X_test, y_pred), # Pass in a "SchemaBuilder" which will use the sample test input and output objects to infer the serialization needed. role_arn=execution_role, image_uri=image_uri, # REQUIRED FOR BYOC: Passing in image hosted in personal ECR Repo model_server=ModelServer.TORCHSERVE, # REQUIRED FOR BYOC: Passing in model server of choice mode=Mode.SAGEMAKER_ENDPOINT, dependencies={"auto": True, "custom": ["protobuf==3.20.2"]}
)

Aqui o image_uri será o ARN da imagem do contêiner que está armazenado na sua conta Registro do Amazon Elastic Container (Amazon ECR). Um exemplo é mostrado a seguir:

# Pulled the xgboost:1.7-1 DLC and pushed to personal ECR repo
image_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

Quando o image_uri é definido, durante o ModelBuilder processo de construção, ele ignorará a detecção automática da imagem conforme o URI da imagem for fornecido. Se model_server não estiver definido no ModelBuilder, você receberá uma mensagem de erro de validação, por exemplo:

ValueError: Model_server must be set when image_uri is set. Supported model servers: {<ModelServer.TRITON: 5>, <ModelServer.DJL_SERVING: 4>, <ModelServer.TORCHSERVE: 1>}

A partir da publicação desta postagem, ModelBuilder apoia trazer seus próprios contêineres que são estendidos de nosso imagens de contêiner DLC pré-construídas ou contêineres construídos com os servidores modelo, como Biblioteca Java Profunda (DJL), Inferência de geração de texto (TGI), TorchServe e Servidor de inferência Triton.

Dependências personalizadas

Quando correr ModelBuilder.build(), por padrão ele captura automaticamente seu ambiente Python em um requirements.txt arquivo e instala a mesma dependência no contêiner. No entanto, às vezes o seu ambiente Python local entrará em conflito com o ambiente no contêiner. ModelBuilder fornece uma maneira simples de modificar as dependências capturadas para corrigir esses conflitos de dependência, permitindo que você forneça suas configurações personalizadas em ModelBuilder. Observe que isso é apenas para TorchServe e Triton com InferenceSpec. Por exemplo, você pode especificar as dependências do parâmetro de entrada, que é um dicionário Python, no ModelBuilder da seguinte forma:

dependency_config = { "auto" = True, "requirements" = "/path/to/your/requirements.txt" "custom" = ["module>=1.2.3,<1.5", "boto3==1.16.*", "some_module@http://some/url"]
} ModelBuilder( # Other params dependencies=dependency_config,
).build()

Definimos os seguintes campos:

  • auto – Se deve tentar capturar automaticamente as dependências em seu ambiente.
  • requisitos – Uma sequência do caminho para o seu próprio requirements.txt arquivo. (Isso é opcional.)
  • personalizadas – Uma lista de quaisquer outras dependências customizadas que você deseja adicionar ou modificar. (Isso é opcional.)

Se o mesmo módulo for especificado em vários locais, custom terá a maior prioridade, então requirements e auto terá a prioridade mais baixa. Por exemplo, digamos que durante a detecção automática, ModelBuilder detecta numpy==1.25e um requirements.txt é fornecido um arquivo que especifica numpy>=1.24,<1.26. Além disso, há uma dependência personalizada: custom = ["numpy==1.26.1"]. Nesse caso, numpy==1.26.1 será escolhido quando instalarmos dependências no contêiner.

limpar

Quando terminar de testar os modelos, como prática recomendada, exclua o endpoint para economizar custos se o endpoint não for mais necessário. Você pode seguir o limpar em cada um dos notebooks de demonstração ou use o código a seguir para excluir o modelo e o endpoint criados pela demonstração:

predictor.delete_model()
predictor.delete_endpoint()

Conclusão

O novo recurso SageMaker ModelBuilder simplifica o processo de implantação de modelos de ML em produção no SageMaker. Ao lidar com muitos detalhes complexos nos bastidores, o ModelBuilder reduz a curva de aprendizado para novos usuários e maximiza a utilização para usuários experientes. Com apenas algumas linhas de código, você pode implantar modelos com estruturas integradas como XGBoost, PyTorch, Triton e Hugging Face, bem como modelos fornecidos pelo SageMaker JumpStart em endpoints robustos e escalonáveis ​​no SageMaker.

Encorajamos todos os usuários do SageMaker a experimentar esse novo recurso consultando o Construtor de Modelo página de documentação. ModelBuilder já está disponível para todos os usuários do SageMaker sem custo adicional. Aproveite esse fluxo de trabalho simplificado para implantar seus modelos com mais rapidez. Estamos ansiosos para saber como o ModelBuilder acelera o ciclo de vida de desenvolvimento do seu modelo!

Agradecimentos especiais a Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg e Ram Vegiraju.


Sobre os autores

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Melanie Li, PhD, é especialista sênior em AI/ML TAM na AWS com sede em Sydney, Austrália. Ela ajuda clientes corporativos a criar soluções usando ferramentas de IA/ML de última geração na AWS e fornece orientação sobre como arquitetar e implementar soluções de ML com as melhores práticas. Em seu tempo livre, ela adora explorar a natureza e passar tempo com a família e amigos.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Marc Karp é arquiteto de ML da equipe do Amazon SageMaker Service. Ele se concentra em ajudar os clientes a projetar, implantar e gerenciar cargas de trabalho de ML em escala. Nas horas vagas gosta de viajar e explorar novos lugares.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Sam Edwards, é engenheiro de nuvem (AI/ML) na AWS Sydney, especializado em aprendizado de máquina e Amazon SageMaker. Ele é apaixonado por ajudar os clientes a resolver problemas relacionados a fluxos de trabalho de aprendizado de máquina e a criar novas soluções para eles. Fora do trabalho, ele gosta de praticar esportes com raquete e viajar.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Raghu Ramesha é arquiteto sênior de soluções de ML da equipe do Amazon SageMaker Service. Ele se concentra em ajudar os clientes a criar, implantar e migrar cargas de trabalho de produção de ML para o SageMaker em escala. Ele é especialista em domínios de aprendizado de máquina, IA e visão computacional, e possui mestrado em Ciência da Computação pela UT Dallas. Nas horas vagas gosta de viajar e fotografar.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Shiva Raj Kotini trabalha como gerente de produto principal no portfólio de produtos de inferência do Amazon SageMaker. Ele se concentra na implantação de modelos, ajuste de desempenho e otimização no SageMaker para inferência.

Empacote e implante ML e LLMs clássicos facilmente com o Amazon SageMaker, parte 1: Melhorias no PySDK | Inteligência de dados PlatoBlockchain da Amazon Web Services. Pesquisa vertical. Ai.Mohan Gandhi é engenheiro de software sênior da AWS. Ele está na AWS há 10 anos e trabalhou em vários serviços da AWS, como EMR, EFA e RDS. Atualmente, ele está focado em melhorar a experiência de inferência do SageMaker. Nas horas vagas, gosta de caminhadas e maratonas.

Carimbo de hora:

Mais de Aprendizado de máquina da AWS