En nuestro banco de preguntas de MLA-C01, unas 30 preguntas tratan sobre cómo escalar endpoints e inferencia basada en contenedores, uno de los grupos más grandes de un solo tema. La guía del examen también lo dice claramente: la tarea 3.2 menciona "políticas de escalado automático de endpoints de SageMaker según la demanda y el tiempo" y "elegir métricas concretas para el escalado automático (latencia del modelo, uso de CPU, invocaciones por instancia)", y la tarea 3.1 menciona "elegir el destino de despliegue entre endpoints de SageMaker, Kubernetes, ECS, EKS y Lambda". Saber los nombres de las políticas no basta; hay que combinar la política y la métrica adecuadas para cada situación.
Este artículo empieza por cómo funciona el escalado automático y luego cubre los tres tipos de política y cómo combinarlos, la elección de la métrica, los periodos de espera y los límites de capacidad, los endpoints que pueden bajar a cero, la elección del tipo de instancia y los destinos de despliegue fuera de SageMaker (EKS, ECS, Lambda). Las diferencias básicas entre las cuatro opciones de inferencia (en tiempo real, sin servidor, asíncrona y por lotes) se trataron antes en Infraestructura de despliegue y estrategias de escalado.
---
Cómo Funciona el Escalado Automático
El encargado de un restaurante llama a más personal cuando llegan muchos clientes y deja salir antes a la gente cuando hay poco movimiento. Pero llamar y despedir gente con demasiada frecuencia solo crea confusión, así que después de cada ajuste espera y observa un rato. El escalado automático de los endpoints de SageMaker tiene la misma estructura.
| Componente | Función | |------|------| | Métrica de CloudWatch | Muestra la carga del endpoint como un número (por ejemplo, invocaciones por instancia) | | Alarma de CloudWatch | Decide si la métrica superó el umbral | | Application Auto Scaling | Calcula y ajusta el número de instancias según la política | | Destino escalable | El número de instancias de una variante de producción, ajustado entre la capacidad mínima y la máxima |
El orden de configuración es: registrar el destino escalable (con capacidad mínima y máxima), definir la política y aplicarla. Hay que indicar tanto el nombre del endpoint como el de la variante, y los permisos necesarios los gestiona el rol vinculado al servicio de Application Auto Scaling.
!Ciclo en el que las métricas y alarmas de CloudWatch activan una política de Application Auto Scaling que ajusta el número de instancias del endpoint entre su mínimo y su máximo
---
Los Tres Tipos de Política y Cómo Combinarlos
| Política | Cómo funciona | Cuándo encaja | |------|------|------| | Seguimiento de destino (recomendada) | Mantiene la métrica cerca de un valor objetivo; las alarmas se crean solas | La mayoría de los casos, la más sencilla de configurar | | Por pasos | Añade un número distinto de instancias según cuánto se supere la alarma | Control fino; obligatoria para escalar desde cero | | Programada | Cambia la capacidad mínima y máxima a horas fijas, una vez o de forma recurrente | Picos previsibles, como las 9 de la mañana cada día |
AWS recomienda el seguimiento de destino en la mayoría de los casos. Por ejemplo, con un objetivo de 70 invocaciones por instancia, añade instancias cuando el valor supera 70 y las quita cuando baja. El escalado programado no se puede configurar en la consola; solo se crea con la AWS CLI o la API de Application Auto Scaling.
Una respuesta correcta frecuente en el examen es una combinación de políticas. Usa el escalado programado para añadir instancias antes de los picos previsibles, como la hora de entrada al trabajo, y deja que el seguimiento de destino siga las variaciones inesperadas. El seguimiento de destino sigue funcionando después de que se ejecuta una acción programada. Si varias políticas sobre el mismo destino entran en conflicto, gana la que aporta más capacidad.
Consejo: "Prepararse de antemano para el pico de tráfico de cada lunes por la mañana y responder automáticamente a los demás cambios" es escalado programado más seguimiento de destino. "Escalado automático con el menor esfuerzo operativo" es una sola política de seguimiento de destino.
---
¿Qué Métrica Debe Guiar el Escalado?
Una métrica para el seguimiento de destino debe bajar de forma proporcional al añadir instancias. Solo así se cumple la lógica de que "añadir instancias devuelve la métrica al objetivo".
| Métrica | Tipo | Cuándo usarla | |------|------|------| | InvocationsPerInstance | Métrica predefinida, resolución de 1 minuto | La opción por defecto para endpoints en tiempo real típicos | | ConcurrentRequestsPerModel y ConcurrentRequestsPerCopy | Métricas predefinidas de alta resolución, cada 10 segundos | Ráfagas repentinas de tráfico, LLM que envían la respuesta como flujo de tokens | | CPUUtilization, GPUUtilization, MemoryUtilization | Métricas personalizadas | Modelos de cálculo intensivo en los que la CPU o la GPU llega primero al límite | | ModelLatency | Métrica personalizada | Cuando gestionas directamente un objetivo de tiempo de respuesta (SLA) | | ApproximateBacklogSizePerInstance | Métrica personalizada | Longitud de la cola de un endpoint asíncrono |
Las métricas de alta resolución se emiten cada 10 segundos, así que escalan hacia afuera mucho más rápido cuando crece el tráfico. Sin embargo, la reducción ocurre a la misma velocidad que con las métricas estándar. CPUUtilization puede superar el 100 % hasta el número de vCPU de la instancia (hasta 400 % con 4 vCPU), así que hay que tener cuidado al fijar el objetivo.
Consejo: "El escalado es demasiado lento ante un salto repentino de solicitudes simultáneas y aparece latencia" es la métrica de alta resolución de solicitudes simultáneas. "El modelo agota la GPU y se vuelve lento" es una métrica personalizada basada en GPUUtilization.
---
Periodos de Espera, Límites de Capacidad y Pruebas de Carga
Periodo de Espera: Evitar que la Capacidad Oscile Demasiado
El periodo de espera (cooldown) es un tiempo que retrasa el siguiente ajuste después de haber hecho uno. Si no se indica, se aplica el valor predeterminado de 300 segundos tanto para escalar hacia afuera como hacia adentro.
Se añaden y quitan instancias con demasiada frecuencia: aumenta el periodo de espera Las instancias llegan demasiado tarde para el tráfico que crece: reduce el periodo de espera de escalado hacia afuera Reducir despacio y ampliar rápido: haz que el periodo de reducción sea más largo que el de ampliación (por ejemplo, 600 y 300 segundos)
Capacidad Mínima y Máxima
La capacidad mínima de un endpoint en tiempo real normal debe ser al menos 1, y cuando el tráfico baja a cero el endpoint se reduce hasta ese mínimo. SageMaker no impone un límite propio al máximo, pero no puede superar la cuota de instancias de la cuenta. Para ampliar a mano con urgencia, sube el mínimo; para reducir, baja el máximo.
Fija el Objetivo con una Prueba de Carga
El método que recomienda AWS es encontrar con una prueba de carga el número máximo de solicitudes por segundo (MAX_RPS) que una instancia puede atender dentro de tu objetivo de latencia, y multiplicarlo por un factor de seguridad para fijar el objetivo.
Objetivo de InvocationsPerInstance = MAX_RPS × factor de seguridad × 60 Empieza con un factor de seguridad de 0,5 y ajústalo mientras pruebas
Consejo: "El escalado ocurre tan a menudo que las instancias se añaden y se quitan sin parar" se resuelve aumentando el periodo de espera.
---
Endpoints que Pueden Bajar a Cero
Mantener instancias encendidas toda la noche para un modelo que no recibe solicitudes es tirar el dinero. Que un endpoint pueda bajar a cero depende de su tipo.
| Tipo | Bajar a cero | Cómo y qué vigilar | |------|------|------| | Endpoint en tiempo real (normal) | No | Capacidad mínima de al menos 1 | | Tiempo real con componentes de inferencia | Sí | Fija en 0 el número mínimo de instancias; volver a crecer desde cero requiere una política por pasos y una alarma, y las solicitudes fallan durante los minutos de aprovisionamiento | | Endpoint asíncrono | Sí | Capacidad mínima 0, las solicitudes esperan en la cola; añadir una política por pasos HasBacklogWithoutCapacity escala con la primera solicitud | | Endpoint sin servidor | Automático | Baja a cero solo cuando está inactivo; la primera solicitud provoca un arranque en frío |
Los arranques en frío de la inferencia sin servidor se reducen con la simultaneidad aprovisionada. La simultaneidad que indiques se mantiene preparada, y ese valor se puede ajustar con Application Auto Scaling según una métrica objetivo o un horario. Los endpoints sin servidor admiten de 1 a 6 GB de memoria y una simultaneidad máxima de 200 por endpoint, y no admiten GPU, configuración de VPC, endpoints multimodelo, captura de datos ni Model Monitor.
Consejo: "Solicitudes poco frecuentes, se puede esperar unos minutos y las cargas útiles son grandes" es un endpoint asíncrono que baja a cero. "Solicitudes cortas e intermitentes, pero hay que reducir la latencia de la primera respuesta" es sin servidor con simultaneidad aprovisionada.
---
Elegir el Tipo de Instancia: Inference Recommender
El escalado automático decide "cuántas", pero antes hay que decidir "cuál". SageMaker Inference Recommender despliega el modelo en varios tipos de instancia, ejecuta pruebas de carga y da recomendaciones que comparan rendimiento y costo.
| Tipo de trabajo | Qué hace | Duración | |------|------|------| | Predeterminado (Inference recommendations) | Pruebas de carga automáticas en las instancias candidatas recomendadas | Normalmente menos de 45 minutos | | Avanzado (Endpoint recommendations) | Pruebas de carga personalizadas en las que eliges instancias, patrón de tráfico y objetivo de latencia | Unas 2 horas de media |
Funciona con endpoints en tiempo real y sin servidor, y solo pagas las instancias usadas mientras corre el trabajo. Para los recursos d