Amazon MLS-C01: Despliegue, Inferencia y Servicio (Implementación y Operaciones de ML) — Guía de estudio

By Laurynas Brazys · 25 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Forma parte de la AWS Machine Learning Specialty MLS-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Patrones de despliegue y opciones de servicio

Las opciones para servir modelos equilibran la latencia, el costo, el rendimiento (throughput) y la complejidad operativa. Los endpoints de SageMaker en tiempo real (aprovisionados o sin servidor) proporcionan latencias de menos de 100 ms a segundos, adecuadas para API interactivas; elija familias de instancias como ml.c5/m5 para modelos de CPU, ml.g4dn o ml.p3 para modelos de GPU, o ml.inf1 para inferencia de bajo costo y alto rendimiento con Inferentia. La inferencia asíncrona y Batch Transform son adecuados para casos de uso con lotes grandes o latencia variable: Batch Transform es ideal para trabajos offline de gran tamaño (divida objetos grandes de S3 en fragmentos y utilice instancias ml.m5/c5 o de GPU según sea necesario), mientras que SageMaker Asynchronous Inference admite cargas útiles (payloads) más grandes con un sistema de colas para lotes casi en tiempo real. Los endpoints multimodelo alojan muchos modelos detrás de un único contenedor, reduciendo la sobrecarga de almacenamiento al cargar los modelos bajo demanda; funcionan mejor cuando los modelos son pequeños, tienen costos de arranque en frío (cold-start) modestos y los patrones de acceso son dispersos. Elija SageMaker Serverless Inference para cargas de trabajo impredecibles y de bajo rendimiento (throughput) para evitar la gestión de instancias; tenga cuidado con los arranques en frío (cold starts) y el tiempo de ejecución limitado. Los criterios de decisión clave incluyen los SLO de latencia, el costo por invocación, el patrón de concurrencia, el tamaño del modelo y la tolerancia al arranque en frío (cold-start). Una trampa común es usar endpoints en tiempo real para cargas de trabajo por lotes de volumen extremadamente alto; esto es costoso. En su lugar, utilice Batch Transform, Async Inference, o invoque los endpoints mediante procesamiento por lotes y workers concurrentes.

Escalado, modelado de tráfico y optimización de costos

El autoescalado, el desvío de tráfico y el control de costos deben diseñarse conjuntamente con la topología de despliegue. Utilice Application Auto Scaling para escalar las variantes de los endpoints de SageMaker con políticas de seguimiento de objetivos (target-tracking) basadas en métricas de invocación o métricas personalizadas de CloudWatch; defina capacidades mínimas/máximas y periodos de enfriamiento (cooldowns) sensatos para evitar la sobrecarga por escalado (thrashing). Para despliegues blue/green y lanzamientos canary, utilice endpoints multivariante o actualizaciones de EndpointConfig con porcentajes de división de tráfico e incrementos graduales; intégrelo con AWS CodeDeploy para automatizar el desvío de tráfico. Las optimizaciones de costos incluyen la poda de modelos (pruning), la cuantificación (quantization) (FP16 o int8), la compilación con SageMaker Neo o AWS Neuron para Inf1, y el traslado de cargas de trabajo no sensibles a la latencia a Batch Transform o a la inferencia sin servidor. Las instancias Spot reducen los costos de entrenamiento, pero no son aplicables a los endpoints en tiempo real; en su lugar, dimensione correctamente los tipos de instancia (cpu vs gpu vs inferentia) y consolide modelos con endpoints multimodelo cuando sea apropiado. Esté atento a trampas como el sobreaprovisionamiento al usar el seguimiento de objetivos (target-tracking) sin comprender el rendimiento (throughput) por instancia, o asumir que los endpoints multimodelo eliminan los límites de memoria; la carga del modelo todavía requiere memoria y puede aumentar la latencia. Además, comprima los artefactos del modelo (ONNX, TF SavedModel con gz) y utilice estrategias de carga diferida (lazy-loading) para reducir los tiempos de almacenamiento y de arranque en frío (cold-start).

Inferencia en el borde (edge), de baja latencia y ubicación del pre/post-procesamiento

Para entornos de latencia ultrabaja o desconectados, despliegue modelos en AWS IoT Greengrass (v2) o utilice SageMaker Edge Manager para empaquetar y monitorear modelos en dispositivos de borde (edge devices); compile con componentes de SageMaker Neo o AWS IoT Greengrass y utilice la cuantificación (quantization) para cumplir con las restricciones de memoria/CPU. Ubique el preprocesamiento y la extracción de características donde se minimice la latencia de extremo a extremo y el costo: los filtros simples pueden ejecutarse en el firmware del dispositivo o en una Lambda de Greengrass, mientras que el procesamiento por lotes y las transformaciones pesadas deben realizarse en un gateway de borde (edge gateway) o en la nube. Para ventanas de eventos en streaming (p. ej., ventanas deslizantes de 10 minutos), ingiera los datos con Amazon Kinesis Data Streams o Amazon MSK, utilice Kinesis Data Analytics o Flink/Apache Spark para la gestión de ventanas y la agregación, y reenvíe las características resumidas a un endpoint de SageMaker o a un modelo ligero en el borde (on-edge); esto reduce el egreso de red y la frecuencia de invocación del modelo. Tenga cuidado con trampas como ignorar el versionado de modelos en los dispositivos de borde, o no aprovisionar suficiente almacenamiento en el dispositivo para los artefactos del modelo. Para microservicios del lado del servidor, coloque el preprocesamiento en la misma ubicación (API Gateway + Lambda o ALB + Fargate) para evitar la sobrecarga de la llamada en frío (cold-call) y reducir el tamaño de las cargas útiles (payloads) enviadas al modelo.

Monitoreo, auditoría, gobernanza y manejo de datos

El ML operativo requiere una salud continua del modelo y gobernanza de datos. Usa SageMaker Model Monitor para establecer una línea base de los datos de entrenamiento con un DataQualityJob y configura el monitoreo continuo para detectar deriva de datos (data drift), regresiones en la calidad del modelo, valores faltantes y restricciones personalizadas; habilita DataCaptureConfig en los endpoints para capturar entradas/salidas en S3 y activar trabajos de Model Monitor. Para el linaje y la auditoría a nivel de características (features), utiliza Amazon SageMaker Feature Store (almacenes online y offline) combinado con AWS Glue Data Catalog y CloudTrail para rastrear el acceso y las transformaciones de los conjuntos de datos; Amazon Macie y los trabajos de procesamiento de Glue/SageMaker pueden descubrir y redactar PII (información de identificación personal) antes del entrenamiento. Las trampas de la encriptación incluyen SSE-KMS: cuando los objetos de S3 están encriptados con una CMK administrada por el cliente, asegúrate de que el rol de ejecución de SageMaker tenga los permisos kms:Decrypt y kms:GenerateDataKey y que la política de la CMK otorgue acceso; también asegúrate de que las políticas del bucket de S3 y los endpoints de VPC no bloqueen el acceso. Para objetos grandes diarios en S3 (p. ej., 100 GB), evita la ingesta en un solo archivo: particiónalo en muchos objetos más pequeños, almacénalos en formato Parquet y comprímelos, y usa Athena/Glue para la detección de esquemas. Las trampas comunes incluyen cronogramas de monitoreo insuficientes, no generar una línea base adecuada para Model Monitor y olvidar otorgar acceso a KMS a todos los principales de servicio (service principals) (SageMaker, Glue, Lambda) que necesitan desencriptar.

Problema práctico: Escenario de caso de uso

Escenario: Streamlytic Media opera una plataforma de análisis de podcasts en AWS. Usan Kinesis Data Streams para ingerir eventos de usuario, almacenan características agregadas en S3 y alojan modelos en SageMaker para la predicción de la interacción (engagement) en tiempo real. Los datos contienen PII ocasionalmente y están encriptados con una clave administrada por el cliente SSE-KMS.

Desafío: Proporcionar predicciones de baja latencia sobre una ventana móvil de eventos de 10 minutos, redactar la PII antes del entrenamiento del modelo, asegurar que SageMaker pueda leer los datos encriptados de S3 e implementar un monitoreo continuo para la deriva de características (feature drift).

Enfoque recomendado:

Crear un Kinesis Data Stream para ingerir eventos, ejecutar Kinesis Data Analytics (Flink) para mantener ventanas móviles de 10 minutos y emitir características agregadas a S3 en formato Parquet con particiones por hora.
Detectar y redactar PII usando Amazon Macie para el descubrimiento y un trabajo de SageMaker Processing (o un trabajo de AWS Glue) para aplicar redacción/tokenización determinista; almacenar los resultados en un almacén offline de Feature Store para el entrenamiento.
Otorgar al rol de ejecución de SageMaker los permisos kms:Decrypt y kms:GenerateDataKey sobre la CMK, agregar el rol a la política de clave de la CMK y asegurar que la política del bucket de S3 o el endpoint de VPC permitan el acceso para SageMaker.
Desplegar el modelo como un endpoint en tiempo real de SageMaker en instancias ml.inf1, habilitar DataCaptureConfig, crear una línea base de Model Monitor a partir de los datos de entrenamiento y configurar el monitoreo continuo con alertas a CloudWatch.

Justificación: La agregación en streaming con Kinesis + Flink minimiza el volumen de eventos y la latencia; la redacción en el momento del procesamiento preserva la privacidad y el cumplimiento; los permisos explícitos de KMS evitan fallos de acceso; los endpoints respaldados por Inferentia y Model Monitor equilibran un bajo costo de inferencia con la observabilidad operativa.

← Entrenamiento · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →