Empaquete e implemente ML y LLM clásicos fácilmente con Amazon SageMaker, parte 1: Mejoras de PySDK | Servicios web de Amazon

Amazon SageMaker es un servicio totalmente administrado que permite a los desarrolladores y científicos de datos crear, entrenar e implementar modelos de aprendizaje automático (ML) de forma rápida y sin esfuerzo a cualquier escala. SageMaker simplifica la implementación de modelos en producción directamente a través de llamadas API al servicio. Los modelos se empaquetan en contenedores para implementaciones sólidas y escalables. Aunque proporciona varios puntos de entrada como el SDK de Python de SageMaker, los SDK de AWS, la consola de SageMaker y Estudio Amazon SageMaker portátiles para simplificar el proceso de capacitación e implementación de modelos de aprendizaje automático a escala, los clientes todavía están buscando mejores formas de implementar sus modelos para pruebas en áreas de juego y optimizar las implementaciones de producción.

Estamos lanzando dos nuevas formas de simplificar el proceso de empaquetar e implementar modelos usando SageMaker.

En esta publicación, presentamos el nuevo SDK de SageMaker Python ModelBuilder experiencia, que tiene como objetivo minimizar la curva de aprendizaje para los nuevos usuarios de SageMaker, como los científicos de datos, al mismo tiempo que ayuda a los ingenieros experimentados de MLOps a maximizar la utilización de los servicios de alojamiento de SageMaker. Reduce la complejidad de la configuración e implementación iniciales y proporciona orientación sobre las mejores prácticas para aprovechar todas las capacidades de SageMaker. Proporcionamos información detallada y ejemplos de GitHub para esta nueva capacidad de SageMaker.

El otro lanzamiento nuevo es utilizar la nueva experiencia de implementación interactiva en SageMaker Studio. Hablamos de esto en la Parte 2.

La implementación de modelos en un punto final de SageMaker implica una serie de pasos para preparar el modelo para alojarlo en un punto final de SageMaker. Esto implica obtener los artefactos del modelo en el formato y estructura correctos, crear código de inferencia y especificar detalles esenciales como la URL de la imagen del modelo. Servicio de almacenamiento simple de Amazon (Amazon S3) ubicación de los artefactos del modelo, pasos de serialización y deserialización, y requisitos necesarios Gestión de identidades y accesos de AWS (IAM) roles para facilitar los permisos de acceso adecuados. Después de esto, una configuración de punto final requiere determinar el tipo de inferencia y configurar los parámetros respectivos, como tipos de instancia, recuentos y distribución de tráfico entre las variantes del modelo.

Para ayudar aún más a nuestros clientes cuando utilizan el hosting de SageMaker, presentamos el nuevo ModelBuilder clase en SageMaker Python SDK, que brinda los siguientes beneficios clave al implementar modelos en puntos finales de SageMaker:

• Unifica la experiencia de implementación en todos los marcos – La nueva experiencia proporciona un flujo de trabajo consistente para implementar modelos creados utilizando diferentes marcos como PyTorch, TensorFlow y XGBoost. Esto simplifica el proceso de implementación.
• Automatiza la implementación del modelo – Tareas como seleccionar contenedores apropiados, capturar dependencias y manejar la serialización/deserialización están automatizadas, lo que reduce el esfuerzo manual necesario para la implementación.
• Proporciona una transición fluida desde el punto final local al alojado en SageMaker – Con cambios mínimos de código, los modelos pueden pasar fácilmente de las pruebas locales a la implementación en un terminal de SageMaker. Los registros en vivo facilitan la depuración.

En general, SageMaker ModelBuilder simplifica y agiliza el proceso de empaquetado de modelos para la inferencia de SageMaker al manejar detalles de bajo nivel y proporciona herramientas para probar, validar y optimizar puntos finales. Esto mejora la productividad del desarrollador y reduce los errores.

En las siguientes secciones, profundizaremos en los detalles de esta nueva característica. También analizamos cómo implementar modelos en el alojamiento de SageMaker usando ModelBuilder, lo que simplifica el proceso. Luego, le presentamos algunos ejemplos de diferentes marcos para implementar tanto los modelos de aprendizaje automático tradicionales como los modelos básicos que impulsan los casos de uso de IA generativa.

Conociendo SageMaker ModelBuilder

El nuevo ModelBuilder es una clase de Python centrada en tomar modelos de aprendizaje automático creados utilizando marcos, como XGBoost o PyTorch, y convertirlos en modelos que estén listos para su implementación en SageMaker. ModelBuilder proporciona una build() función, que genera los artefactos según el modelo de servidor, y una deploy() función para implementar localmente o en un punto final de SageMaker. La introducción de esta característica simplifica la integración de modelos con el entorno de SageMaker, optimizándolos en términos de rendimiento y escalabilidad. El siguiente diagrama muestra cómo ModelBuilder trabaja a un alto nivel.

Clase ModelBuilder

La Constructor de modelos La clase proporciona diferentes opciones de personalización. Sin embargo, para implementar el modelo marco, el creador del modelo solo espera el modelo, la entrada, la salida y la función:

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

Generador de esquemas

La Generador de esquemas La clase le permite definir la entrada y salida para su punto final. Permite al generador de esquemas generar las funciones de clasificación correspondientes para serializar y deserializar la entrada y la salida. El siguiente archivo de clase proporciona todas las opciones de personalización:

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

Sin embargo, en la mayoría de los casos, solo funcionarán las entradas y salidas de muestra. Por ejemplo:

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

Al proporcionar entradas y salidas de muestra, SchemaBuilder puede determinar automáticamente las transformaciones necesarias, haciendo que el proceso de integración sea más sencillo. Para casos de uso más avanzados, existe flexibilidad para proporcionar funciones de traducción personalizadas tanto para entrada como para salida, lo que garantiza que las estructuras de datos más complejas también se puedan manejar de manera eficiente. Demostramos esto en las siguientes secciones implementando diferentes modelos con varios marcos utilizando ModelBuilder.

Experiencia en modo local

En este ejemplo, usamos ModelBuilder para implementar el modelo XGBoost localmente. Puede usar Modo para cambiar entre pruebas locales e implementación en un punto final de SageMaker. Primero entrenamos el modelo XGBoost (localmente o en SageMaker) y almacenamos los artefactos del modelo en el directorio de trabajo:

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

Luego creamos un objeto ModelBuilder pasando el objeto modelo real, el SchemaBuilder que utiliza los objetos de entrada y salida de prueba de muestra (la misma entrada y salida que usamos al entrenar y probar el modelo) para inferir la serialización necesaria. Tenga en cuenta que utilizamos Mode.LOCAL_CONTAINER para especificar una implementación local. Después de eso, llamamos al build función para identificar automáticamente la imagen del contenedor del marco compatible, así como escanear en busca de dependencias. Vea el siguiente 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 llamar a la deploy función en el objeto modelo, que también proporciona registro en vivo para facilitar la depuración. No es necesario especificar el tipo de instancia ni el recuento porque el modelo se implementará localmente. Si proporcionó estos parámetros, se ignorarán. Esta función devolverá el objeto predictor que podemos usar para hacer predicciones con los datos de prueba:

# 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, también puede controlar la carga del modelo y el preprocesamiento y posprocesamiento usando InferenceSpec. Proporcionamos más detalles más adelante en esta publicación. Usando LOCAL_CONTAINER es una excelente manera de probar su script localmente antes de implementarlo en un punto final de SageMaker.

Para obtener más detalles sobre cómo diseñar y realizar los esfuerzos de seguimiento y evaluación, refierase a constructor-de-modelos-xgboost.ipynb ejemplo para probar la implementación tanto localmente como en un punto final de SageMaker usando ModelBuilder.

Implemente modelos tradicionales en los puntos finales de SageMaker

En los siguientes ejemplos, mostramos cómo utilizar ModelBuilder para implementar modelos de ML tradicionales.

Modelos XGBoost

De manera similar a la sección anterior, puede implementar un modelo XGBoost en un punto final de SageMaker cambiando el mode parámetro al crear el ModelBuilder :

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
)

Tenga en cuenta que al implementar en puntos finales de SageMaker, debe especificar el tipo de instancia y el recuento de instancias al llamar al deploy función.

Para obtener más detalles sobre cómo diseñar y realizar los esfuerzos de seguimiento y evaluación, refierase a constructor-de-modelos-xgboost.ipynb ejemplo para implementar un modelo XGBoost.

Modelos tritón

Puedes usar ModelBuilder para servir modelos PyTorch en Servidor de inferencia Triton. Para ello es necesario especificar el model_server parámetro como ModelServer.TRITON, pasar un modelo y tener un SchemaBuilder objeto, que requiere entradas y salidas de muestra del modelo. ModelBuilder se encargará del resto por usted.

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 constructor-de-modelos-triton.ipynb para implementar un modelo con Triton.

Modelos de cara abrazada

En este ejemplo, le mostramos cómo implementar un modelo de transformador previamente entrenado proporcionado por Hugging Face en SageMaker. Queremos usar la cara de abrazo pipeline para cargar el modelo, por lo que creamos una especificación de inferencia 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()

También definimos la entrada y salida de la carga de trabajo de inferencia definiendo el SchemaBuilder objeto basado en la entrada y salida del modelo:

schema = SchemaBuilder(value,output)

Luego creamos el ModelBuilder objeto e implemente el modelo en un punto final de SageMaker siguiendo la misma lógica que se muestra en el otro ejemplo:

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 implementar un modelo de canalización de Hugging Face.

Implementar modelos básicos en los puntos finales de SageMaker

En los siguientes ejemplos, mostramos cómo utilizar ModelBuilder para implementar modelos de base. Al igual que los modelos mencionados anteriormente, todo lo que se requiere es la identificación del modelo.

abrazando la cara hub

Si desea implementar un modelo básico desde abrazando la cara hub, todo lo que necesita hacer es pasar la ID del modelo previamente entrenado. Por ejemplo, el siguiente fragmento de código implementa el meta-llama/Llama-2-7b-hf modelo localmente. Puede cambiar el modo a Mode.SAGEMAKER_ENDPOINT para implementar en los puntos finales de 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 cerrados en Hugging Face Hub, debe solicitar acceso a través de Hugging Face Hub y usar la clave asociada pasándola como variable de entorno. HUGGING_FACE_HUB_TOKEN. Algunos modelos de Hugging Face pueden requerir un código remoto confiable. También se puede configurar como una variable de entorno usando HF_TRUST_REMOTE_CODE. Por defecto, ModelBuilder utilizará una inferencia de generación de texto de cara abrazada (TGI) contenedor como contenedor subyacente para los modelos Hugging Face. Si desea utilizar AWS Large Model Inference (LMI) contenedores, puedes configurar el model_server parámetro como ModelServer.DJL_SERVING cuando configuras el ModelBuilder objeto.

Una característica interesante de ModelBuilder es la capacidad de ejecutar el ajuste local de los parámetros del contenedor cuando se utiliza LOCAL_CONTAINER modo. Esta característica se puede utilizar simplemente ejecutando tuned_model = model.tune().

Consulte demo-modelo-constructor-huggingface-llama2.ipynb para implementar un modelo de Hugging Face Hub.

Inicio rápido de SageMaker

JumpStart de Amazon SageMaker También ofrece una serie de modelos de cimentación previamente entrenados. Al igual que el proceso de implementación de un modelo desde Hugging Face Hub, se requiere la identificación del modelo. Implementar un modelo JumpStart de SageMaker en un punto final de SageMaker es tan sencillo como ejecutar el siguiente 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 conocer todos los ID de modelo de SageMaker JumpStart disponibles, consulte Algoritmos integrados con tabla de modelo preentrenada. Referirse a constructor-de-modelos-jumpstart-falcon.ipynb para implementar un modelo SageMaker JumpStart.

Componente de inferencia

ModelBulder le permite utilizar la nueva capacidad del componente de inferencia en SageMaker para implementar modelos. Para obtener más información sobre los componentes de inferencia, consulte Reduzca los costos de implementación de modelos en un 50% en promedio utilizando las últimas funciones de SageMaker. Puede utilizar componentes de inferencia para la implementación con ModelBuilder especificando endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED existentes deploy() método. También puedes utilizar el tune() método, que recupera el número óptimo de aceleradores y lo modifica si es necesario.

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 componente-inferencia-constructor-de-modelos.ipynb implementar un modelo como componente de inferencia.

Personaliza la clase ModelBuilder

La ModelBuilder La clase le permite personalizar la carga del modelo usando InferenceSpec.

Además, puede controlar la serialización y deserialización de la carga útil y la respuesta y personalizar el preprocesamiento y el posprocesamiento utilizando CustomPayloadTranslator. Además, cuando necesite ampliar nuestros contenedores prediseñados para la implementación de modelos en SageMaker, puede usar ModelBuilder para manejar el proceso de empaquetado del modelo. En la siguiente sección, proporcionamos más detalles de estas capacidades.

Especificación de inferencia

Especificación de inferencia ofrece una capa adicional de personalización. Le permite definir cómo se carga el modelo y cómo manejará las solicitudes de inferencia entrantes. A través de InferenceSpec, puede definir procedimientos de carga personalizados para sus modelos, sin pasar por los mecanismos de carga predeterminados. Esta flexibilidad es particularmente beneficiosa cuando se trabaja con modelos no estándar o canales de inferencia personalizados. El método de invocación se puede personalizar, lo que le brinda la capacidad de personalizar cómo el modelo procesa las solicitudes entrantes (preprocesamiento y posprocesamiento). Esta personalización puede ser esencial para garantizar que el proceso de inferencia se alinee con las necesidades específicas del modelo. Vea el siguiente 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

El siguiente código muestra un ejemplo del uso de esta clase:

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

Traductor de carga útil personalizado

Al invocar puntos finales de SageMaker, los datos se envían a través de cargas útiles HTTP con diferentes tipos MIME. Por ejemplo, una imagen enviada al punto final para inferencia debe convertirse a bytes en el lado del cliente y enviarse a través de la carga útil HTTP al punto final. Cuando el punto final recibe la carga útil, necesita deserializar la cadena de bytes al tipo de datos esperado por el modelo (también conocido como deserialización del lado del servidor). Una vez que el modelo finaliza la predicción, los resultados deben serializarse en bytes que puedan enviarse de vuelta a través de la carga útil HTTP al usuario o cliente. Cuando el cliente recibe los datos de los bytes de respuesta, necesita realizar una deserialización del lado del cliente para convertir los datos de los bytes al formato de datos esperado, como JSON. A lo mínimo, necesitas convertir los datos para lo siguiente (como se numera en el siguiente diagrama):

1. Serialización de solicitud de inferencia (manejada por el cliente)
2. Deserialización de solicitud de inferencia (manejada por el servidor o algoritmo)
3. Invocar el modelo contra la carga útil
4. Devolviendo la carga útil de respuesta
5. Serialización de respuesta de inferencia (manejada por el servidor o algoritmo)
6. Deserialización de respuesta de inferencia (manejada por el cliente)

El siguiente diagrama muestra el proceso de serialización y deserialización durante el proceso de invocación.

En el siguiente fragmento de código, mostramos un ejemplo de CustomPayloadTranslator cuando se necesita personalización adicional para manejar tanto la serialización como la deserialización en el lado del cliente y del 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

En demo-model-builder-pytorch.ipynb cuaderno, demostramos cómo implementar fácilmente un modelo de PyTorch en un punto final de SageMaker usando ModelBuilder con el CustomPayloadTranslator y del InferenceSpec clase.

Modelo de etapa para el despliegue

Si desea preparar el modelo para inferencia o en el registro de modelos, puede utilizar model.create() or model.register(). El modelo habilitado se crea en el servicio y luego se puede implementar más adelante. Vea el siguiente 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

Utilice contenedores personalizados

SageMaker proporciona imágenes de Docker prediseñadas por sus algoritmos integrados y los marcos de aprendizaje profundo compatibles utilizados para el entrenamiento y la inferencia. Si un contenedor de SageMaker prediseñado no cumple con todos sus requisitos, puede ampliar la imagen existente para adaptarla a sus necesidades. Al ampliar una imagen prediseñadas, puede utilizar las bibliotecas y configuraciones de aprendizaje profundo incluidas sin tener que crear una imagen desde cero. Para obtener más detalles sobre cómo ampliar los contenedores prediseñados, consulte el documento de SageMaker. ModelBuilder admite casos de uso al traer sus propios contenedores que se extienden desde nuestros contenedores Docker prediseñados.

Para utilizar su propia imagen de contenedor en este caso, debe configurar los campos image_uri y model_server al 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"]}
)

Aquí el image_uri será el ARN de la imagen del contenedor que se almacena en el archivo de su cuenta. Registro de contenedores elásticos de Amazon (Amazon ECR) repositorio. Un ejemplo se muestra a continuación:

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

Cuando el image_uri se establece, durante el ModelBuilder proceso de compilación, omitirá la detección automática de la imagen a medida que se proporcione el URI de la imagen. Si model_server no está configurado en ModelBuilder, recibirá un mensaje de error de validación, por ejemplo:

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 de la publicación de esta publicación, ModelBuilder admite traer sus propios contenedores que se extienden desde nuestro Imágenes de contenedores DLC prediseñadas o contenedores construidos con los servidores modelo como Biblioteca Deep Java (DJL), Inferencia de generación de texto (TGI), AntorchaServiry Servidor de inferencia Triton.

Dependencias personalizadas

Cuando se ejecuta ModelBuilder.build(), de forma predeterminada captura automáticamente su entorno Python en un requirements.txt archivo e instala la misma dependencia en el contenedor. Sin embargo, a veces su entorno local de Python entrará en conflicto con el entorno del contenedor. ModelBuilder proporciona una forma sencilla de modificar las dependencias capturadas para solucionar dichos conflictos de dependencia permitiéndole proporcionar sus configuraciones personalizadas en ModelBuilder. Tenga en cuenta que esto es sólo para TorchServe y Triton con InferenceSpec. Por ejemplo, puede especificar las dependencias de los parámetros de entrada, que es un diccionario de Python, en ModelBuilder de la siguiente manera:

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 los siguientes campos:

• auto – Si intentar capturar automáticamente las dependencias en su entorno.
• requisitos – Una cadena del camino hacia el tuyo. requirements.txt archivo. (Esto es opcional).
• personalizado – Una lista de cualquier otra dependencia personalizada que desee agregar o modificar. (Esto es opcional).

Si el mismo módulo se especifica en varios lugares, custom tendrá la máxima prioridad, entonces requirementsy auto tendrá la menor prioridad. Por ejemplo, digamos que durante la detección automática, ModelBuilder detecta numpy==1.25, Y un requirements.txt Se proporciona un archivo que especifica numpy>=1.24,<1.26. Además, existe una dependencia personalizada: custom = ["numpy==1.26.1"]. En este caso, numpy==1.26.1 Se seleccionará cuando instalemos dependencias en el contenedor.

Limpiar

Cuando haya terminado de probar los modelos, como práctica recomendada, elimine el punto final para ahorrar costos si ya no es necesario. Puedes seguir el Limpiar sección en cada uno de los cuadernos de demostración o utilice el siguiente código para eliminar el modelo y el punto final creados por la demostración:

predictor.delete_model()
predictor.delete_endpoint()

Conclusión

La nueva capacidad de SageMaker ModelBuilder simplifica el proceso de implementación de modelos de ML en producción en SageMaker. Al manejar muchos de los detalles complejos detrás de escena, ModelBuilder reduce la curva de aprendizaje para los nuevos usuarios y maximiza la utilización para los usuarios experimentados. Con solo unas pocas líneas de código, puede implementar modelos con marcos integrados como XGBoost, PyTorch, Triton y Hugging Face, así como modelos proporcionados por SageMaker JumpStart en puntos finales robustos y escalables en SageMaker.

Animamos a todos los usuarios de SageMaker a probar esta nueva capacidad consultando el Constructor de modelos página de documentación. ModelBuilder ya está disponible para todos los usuarios de SageMaker sin coste adicional. Aproveche este flujo de trabajo simplificado para implementar sus modelos más rápidamente. ¡Esperamos escuchar cómo ModelBuilder acelera el ciclo de vida de desarrollo de su modelo!

Un agradecimiento especial a Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg y Ram Vegiraju.

Sobre los autores

melanie li, PhD, es especialista sénior en AI/ML TAM en AWS con sede en Sídney, Australia. Ayuda a los clientes empresariales a crear soluciones utilizando herramientas de IA/ML de última generación en AWS y brinda orientación sobre la arquitectura y la implementación de soluciones de ML con las mejores prácticas. En su tiempo libre, le encanta explorar la naturaleza y pasar tiempo con su familia y amigos.

marc karp es un Arquitecto de ML con el equipo de Servicio de Amazon SageMaker. Se enfoca en ayudar a los clientes a diseñar, implementar y administrar cargas de trabajo de ML a escala. En su tiempo libre le gusta viajar y explorar nuevos lugares.

Sam Edwards, es ingeniero de nube (AI/ML) en AWS Sydney especializado en aprendizaje automático y Amazon SageMaker. Le apasiona ayudar a los clientes a resolver problemas relacionados con los flujos de trabajo de aprendizaje automático y crear nuevas soluciones para ellos. Fuera del trabajo, le gusta practicar deportes de raqueta y viajar.

Raghu Ramesha es arquitecto sénior de soluciones de aprendizaje automático en el equipo de servicios de Amazon SageMaker. Se centra en ayudar a los clientes a crear, implementar y migrar cargas de trabajo de producción de aprendizaje automático a SageMaker a escala. Se especializa en los dominios de aprendizaje automático, inteligencia artificial y visión por computadora, y tiene una maestría en Ciencias de la Computación de UT Dallas. En su tiempo libre le gusta viajar y la fotografía.

Shiva Raaj Kotini Trabaja como gerente principal de productos en la cartera de productos de inferencia de Amazon SageMaker. Se centra en la implementación de modelos, el ajuste del rendimiento y la optimización en SageMaker para realizar inferencias.

Mohán Gandhi es ingeniero de software sénior en AWS. Ha estado en AWS durante los últimos 10 años y ha trabajado en varios servicios de AWS como EMR, EFA y RDS. Actualmente, se centra en mejorar la experiencia de inferencia de SageMaker. En su tiempo libre, disfruta de caminatas y maratones.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/