Amazon MLA-C01: Despliegue e inferencia de modelos — Guía de estudio
Forma parte de la AWS Machine Learning Engineer Associate MLA-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Endpoints en tiempo real, sin servidor, asíncronos y por lotes: concepto central
La inferencia en tiempo real en Amazon SageMaker es un modelo de servicio con estado y de baja latencia en el que se crea un Model, un EndpointConfig y un Endpoint que asigna cómputo aprovisionado (tipos de instancia ml.*) y permanece disponible para atender solicitudes a través de la API InvokeEndpoint. CreateEndpointConfig acepta ProductionVariants, y cada ProductionVariant define ModelName, InitialInstanceCount, InstanceType y InitialVariantWeight; puedes cambiar el tráfico y la capacidad con UpdateEndpointWeightsAndCapacities o UpdateEndpoint. Para necesidades predecibles de baja latencia, los endpoints en tiempo real aprovisionados son la opción principal y admiten canalizaciones de inferencia de múltiples contenedores para encadenar contenedores de preprocesamiento, modelo y posprocesamiento.
Serverless Inference elimina la gestión de instancias y se configura a nivel de endpoint con un ServerlessConfig que especifica MemorySizeInMB y MaxConcurrency para cada ProductionVariant; SageMaker gestiona el aprovisionamiento de contenedores y escala a cero cuando está inactivo, lo que lo hace ideal para cargas de trabajo con picos de tráfico y de bajo rendimiento (low-throughput). Asynchronous Inference está optimizado para solicitudes que tardan mucho tiempo en ejecutarse o donde el cliente no requiere una respuesta síncrona. Un endpoint asíncrono se crea con AsyncInferenceConfig en CreateEndpointConfig (OutputConfig con S3OutputPath, ClientConfig opcional y MaxConcurrentInvocationsPerInstance) y los clientes llaman a InvokeEndpointAsync, proporcionando un URI de S3 de entrada; los resultados se escriben en la ubicación de salida de S3 configurada. Batch Transform es un tipo de trabajo separado (CreateTransformJob) para grandes cargas de trabajo de inferencia sin conexión (offline); la API requiere TransformInput (S3DataSource con S3Uri y S3DataType), TransformOutput (S3OutputPath, Accept, AssembleWith) y TransformResources (InstanceType, InstanceCount). Batch Transform es ideal cuando importa el rendimiento (throughput) pero no la latencia, y admite un gran paralelismo entre conjuntos de datos.
Endpoints multimodelo, canalizaciones de inferencia, pruebas en sombra y A/B: servicios y configuración clave
Cuando se alojan muchos modelos con un bajo QPS por modelo, los endpoints multimodelo de SageMaker (MME) permiten que un único contenedor aloje de docenas a miles de artefactos de modelo almacenados en S3 y los cargue bajo demanda. Se construye un contenedor de servidor de modelos que implementa el patrón de servidor multimodelo de SageMaker o se utiliza una imagen de framework compatible, se suben los archivos tar del modelo a S3 y se crea un recurso Model que hace referencia al contenedor. En el momento de la invocación, se pasa el nombre del modelo de destino a través del parámetro TargetModel de la API InvokeEndpoint (o la cabecera X-Amzn-SageMaker-Target-Model) para que el servidor cargue ese modelo desde S3 en la memoria. Los MME ahorran memoria y costos operativos para grandes flotas de modelos, pero añaden latencia de carga en frío (cold-load) para los modelos que aún no residen en el runtime.
Las canalizaciones de inferencia se implementan como modelos de múltiples contenedores donde el recurso Model enumera los Containers en orden; el endpoint enruta las cargas útiles (payloads) a través del primer contenedor (preprocesamiento), luego el contenedor del modelo y finalmente el contenedor de posprocesamiento. Define cada contenedor con su propio ModelDataUrl y variables de entorno en CreateModel. Para pruebas de estilo canario (canary) o azul/verde (blue/green), utiliza múltiples ProductionVariants en un EndpointConfig y controla la división del tráfico con InitialVariantWeight y posteriormente a través de UpdateEndpointWeightsAndCapacities. Un despliegue en sombra (shadow deployment) se puede lograr ya sea enviando una copia de cada solicitud en la capa de aplicación a un endpoint en sombra (sin peso de tráfico en el endpoint de producción) o creando una ProductionVariant de bajo peso para que la infraestructura del endpoint reciba algo de tráfico reflejado; la duplicación de solicitudes a nivel de aplicación te brinda un aislamiento completo del experimento y una observabilidad independiente.
Para el monitoreo continuo y bajo demanda, configura DataCaptureConfig al crear un endpoint para persistir las cargas útiles (payloads) de solicitud y respuesta en S3. Los campos de interés de DataCaptureConfig incluyen EnableCapture (true), InitialSamplingPercentage, DestinationS3Uri y CaptureOptions (REQUEST, RESPONSE). Los datos capturados se convierten en la base para las comprobaciones posteriores al despliegue de SageMaker Model Monitor y SageMaker Clarify; puedes crear líneas base (baselines) con CreateMonitoringSchedule de Model Monitor y ejecutar trabajos de procesamiento (Processing jobs) ad-hoc que utilizan el contenedor de monitoreo de modelos incorporado para calcular restricciones y métricas de deriva (drift).
Patrones de diseño y contrapartidas
Elija endpoints aprovisionados en tiempo real cuando necesite una latencia de milisegundos de un solo dígito a dos dígitos bajos y pueda permitirse la capacidad siempre activa. Si el costo por minuto en estado inactivo es la restricción dominante y el tráfico es intermitente, los endpoints sin servidor (serverless) reducen las operaciones: configure ServerlessConfig.MemorySizeInMB y ServerlessConfig.MaxConcurrency para cada variante y deje que SageMaker autoescale. Para cargas de trabajo con inferencias de larga duración o patrones de intercambio de cargas útiles (payloads) pesadas, los endpoints asíncronos desacoplan el ciclo de vida del cliente del cómputo; requieren S3 para las entradas/salidas y son más apropiados cuando los clientes pueden consultar (hacer polling) o recibir notificaciones de S3 para la finalización.
Los endpoints multimodelo reducen la duplicación de memoria y la complejidad de la gestión de objetos de S3, pero añaden una latencia de arranque en frío por modelo y requieren un servidor de modelos capaz de cargar bajo demanda desde S3 y gestionar adecuadamente el ciclo de vida (expulsión/LRU). Si la latencia por modelo es crítica, aloje los modelos de alto tráfico (“hot models”) en ProductionVariants dedicados y descargue los modelos de bajo tráfico a un MME. Las canalizaciones de inferencia (Inference pipelines) centralizan la lógica de preprocesamiento y posprocesamiento más cerca del modelo, lo que reduce el código del lado del cliente y garantiza una transformación consistente entre el entrenamiento y la inferencia, pero aumentan la complejidad de arranque del endpoint y exigen un diseño robusto del contrato del contenedor (códecs de entrada/salida y tipos de contenido).
Las pruebas A/B que utilizan los pesos de ProductionVariant son sencillas para la división del tráfico y la recopilación de métricas offline, pero cuando se desea replicar el tráfico en modo “sombra” (shadow) sin afectar a las métricas de producción, es preferible la duplicación a nivel de aplicación. Para despliegues progresivos y la automatización de la reversión (rollback), integre UpdateEndpointWeightsAndCapacities en un flujo de trabajo de CodePipeline o Step Functions que incluya la evaluación automática de métricas mediante las métricas de CloudWatch, las alertas de Model Monitor y una acción de aprobación manual que controle la promoción final.
Errores comunes y criterios de decisión
Un error operativo común es asumir que Model Monitor detectará problemas de disponibilidad de etiquetas; Model Monitor puede detectar la deriva en la distribución de características y violaciones de la calidad de los datos a partir de las solicitudes capturadas, pero para medir la degradación de métricas basadas en etiquetas (F1, recall) debe entregar las etiquetas de verdad fundamental (ground-truth) de vuelta a S3 en un formato que los trabajos de monitorización puedan consumir y programar un trabajo de monitorización que calcule la predicción vs. la verdad. Otro error es no dimensionar ServerlessConfig.MemorySizeInMB adecuadamente; la memoria subaprovisionada causa estrangulamiento (throttling) o caídas del contenedor, mientras que el sobreaprovisionamiento aumenta el costo. Para los endpoints multimodelo, no establecer un diseño de objetos y ciclo de vida de S3 apropiados (prefijos, manifiestos de modelo) hace que las cargas en frío sean más lentas y complica las políticas de desalojo (eviction).
Al tratar con el desequilibrio de clases para la detección de fraudes, prefiera la ponderación nativa del algoritmo a los pipelines de muestreo pesado para una mínima carga operativa; por ejemplo, XGBoost (el contenedor SageMaker XGBoost) soporta el hiperparámetro ‘scale_pos_weight’, que se calcula como ejemplos_negativos/ejemplos_positivos y se pasa a través del mapa de hiperparámetros en la llamada a CreateTrainingJob. Para el control manual de despliegues, utilice el SageMaker Model Registry: cree un ModelPackageGroup, llame a CreateModelPackage para registrar un paquete de modelo y establezca el estado del paquete de modelo en PendingManualApproval; una acción de aprobación manual externa de CodePipeline o una confirmación manual con Step Functions + SNS pueden luego llamar a UpdateModelPackage para establecer ApprovalStatus = "Approved" antes de que se ejecuten CreateModel o CreateEndpoint.
Problema práctico: Escenario de caso de uso
FraudDetectCo está construyendo un sistema de detección de fraudes en línea que debe consolidar los registros de transacciones en S3 y las tablas de perfiles de clientes en un MySQL on-premise, entrenar un modelo XGBoost, desplegarlo con latencia casi en tiempo real, aplicar una puerta de aprobación manual para los lanzamientos a producción y detectar tanto anomalías en el conjunto de datos como deriva del modelo bajo demanda.
Agregación y preprocesamiento de datos: utilice AWS Database Migration Service (DMS) o el conector JDBC de AWS Glue para replicar continuamente las tablas de MySQL on-premise en S3 (parquet) o en un lago de datos habilitado para Amazon RDS/Athena; catalogue con AWS Glue y registre las características en el almacén offline de Amazon SageMaker Feature Store para proporcionar una búsqueda de características consistente para el entrenamiento y el servicio en línea. Esto centraliza el linaje de características y aplica las políticas de seguridad de S3 y la gobernanza de Lake Formation para el aislamiento.
Entrenamiento y manejo del desequilibrio de clases: ejecute trabajos de entrenamiento de SageMaker (Training jobs) utilizando el contenedor incorporado de SageMaker XGBoost. Calcule la proporción de etiquetas en el entrenamiento y establezca el hiperparámetro de XGBoost “scale_pos_weight” en el mapa
HyperParametersdeCreateTrainingJobpara abordar el desequilibrio de clases con un preprocesamiento mínimo. Utilice el modo Pipe para el canal de entrenamiento (DataSourceconS3DataSourceyS3DataTypeestablecidos enS3Prefix, y habilite"RecordWrapperType":"None"si usa el modo Pipe) para reducir el tiempo de inicio y la latencia de descarga de datos en trabajos consecutivos.Registro de modelos y aprobación manual: registre los modelos entrenados en el SageMaker Model Registry llamando a
CreateModelPackagedentro de unModelPackageGroup. Establezca elApprovalStatusinicial enPendingManualApproval, integre un AWS CodePipeline que incluya una acción de Aprobación Manual de AWS (AWS Manual Approval) y, tras la confirmación manual, llame aUpdateModelPackageconApprovalStatus="Approved"antes de promover elModelPackagea producción a través deCreateModelyCreateEndpointConfig.Topología de despliegue e inferencia: despliegue el modelo en un endpoint en tiempo real aprovisionado para una puntuación de baja latencia. Si más tarde se deben alojar cientos de modelos, evalúe un Multi-Model Endpoint y utilice el parámetro
TargetModeldeInvokeEndpointpara dirigir a modelos específicos almacenados en S3. ConfigureDataCaptureConfig(EnableCapture=true,InitialSamplingPercentage=100,DestinationS3Uri=s3:///captures,CaptureOptions=['REQUEST','RESPONSE']) para recolectar las cargas útiles de solicitud/respuesta para análisis bajo demanda.Monitorización y detección de anomalías: programe líneas base (baselines) de SageMaker Model Monitor con
CreateMonitoringSchedulepara la calidad de los datos y la deriva de características. Para la detección de anomalías y visualización a nivel de conjunto de datos, alimente los datos capturados en S3 a Amazon Lookout for Metrics para detectar anomalías automáticamente y a Amazon QuickSight para crear paneles de control. Para la evaluación de sesgo y deriva bajo demanda, ejecute trabajos de procesamiento de SageMaker Clarify contra los datos capturados o lance un trabajo de procesamiento de Model Monitor ad-hoc (a través deCreateProcessingJob) que aplique las restricciones de la línea base almacenada y produzca el informe de comparación.
Justificación: este enfoque centraliza las características para un entrenamiento reproducible y un servicio de baja latencia, utiliza el scale_pos_weight de XGBoost para el desequilibrio de clases con una complejidad mínima del pipeline, impone una aprobación manual en el Model Registry integrado con CodePipeline, reduce la latencia de inicio del entrenamiento mediante el uso del modo Pipe para la transmisión de datos de entrenamiento, y proporciona tanto detección automatizada de anomalías (Lookout for Metrics) como verificaciones de equidad/deriva bajo demanda (Clarify + Model Monitor) utilizando los datos de inferencia capturados.
← Evaluación y selección de modelos · Todos los dominios · MLOps y gestión del ciclo de vida del modelo →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →