AWS Batch permite compartir capacidad entre equipos que entrenan modelos en SageMaker
Amazon Web Services ha introducido una arquitectura avanzada de gestión de cuotas en AWS Batch para trabajos de entrenamiento en Amazon SageMaker. La solución permite a múltiples equipos de ciencia de datos compartir capacidad de GPU en clústeres elásticos mediante cuotas virtuales (Quota Shares), implementando estrategias de préstamo y preempción cruzada entre proyectos para maximizar la utilización de instancias de alto costo y minimizar el tiempo ocioso sin comprometer la estabilidad del entrenamiento. Guía técnica en el blog de Machine Learning de AWS · Documentación oficial de preempción en AWS Batch.
El dilema de la capacidad ociosa en clústeres de GPU
En organizaciones que desarrollan modelos de aprendizaje automático y afinamiento (fine-tuning) de modelos de frontera, la demanda de instancias aceleradas por hardware (como las familias ml.g5, ml.p4d o ml.p5) es altamente estocástica. Mientras un equipo de visión por computadora ejecuta un pipeline de entrenamiento intensivo durante tres días, el clúster de procesamiento de lenguaje natural puede permanecer ocioso esperando la preparación de un nuevo dataset.
Asignar capacidad rígida y fija a cada unidad de negocio genera sobrecostos exorbitantes o colas de espera innecesarias. La integración de AWS Batch Quota Management con SageMaker Training Jobs soluciona este desbalance permitiendo que los clústeres actúen como un fondo común gobernado por políticas matemáticas de asignación y recuperación automática.
| Estrategia de Cuota | Comportamiento con Capacidad Ociosa | Toma de Capacidad Ajena | Resiliencia ante Preempción |
|---|---|---|---|
| RESERVE | La capacidad no usada queda bloqueada | No toma recursos prestados de otras cuotas | Máxima; no sufre preempción entre cuotas |
| LEND | Presta cómputo ocioso a otros proyectos | No toma recursos prestados de terceros | Alta; recupera su cuota mediante desalojo cuando llega demanda |
| LEND_AND_BORROW | Presta cómputo cuando está inactivo | Toma capacidad ociosa de otros proyectos | Variable; los trabajos prestados pueden ser desalojados |
| Intra-Quota Priority | Priorización interna por peso de trabajo | Aplica a la propia cuota del equipo | Trabajos de prioridad baja son desplazados por prioridad alta |
Mecanismos de Preempción y Requisitos de Checkpointing
El pilar operativo de la compartición elástica es la preempción inter-cuota. Cuando un equipo que había prestado su capacidad residual envía un nuevo trabajo de entrenamiento a su cuota, AWS Batch desaloja de forma determinista los trabajos externos que estaban ocupando esos recursos prestados, devolviéndolos al estado RUNNABLE en la cola.
Sin embargo, la preempción impone una exigencia estricta en el diseño del código de entrenamiento: la instrumentación rigurosa de puntos de control (checkpointing). Si un trabajo distribuido de PyTorch o Megatron-LM no sincroniza periódicamente los pesos del optimizador y los gradientes hacia Amazon S3, un desalojo inesperado reiniciará el entrenamiento desde cero, destruyendo horas de cómputo.
Directrices de Configuración con SageMaker Python SDK v3
Para implementar esta arquitectura en una cuenta corporativa de AWS, los ingenieros de MLOps deben configurar tres componentes sincronizados:
- Service Environment: Delimita las instancias admitidas (por ejemplo, cuotas máximas de 32 GPUs A100/H100) y las subredes VPC con conectividad EFA (Elastic Fabric Adapter).
- Training Job Queue: Cola principal vinculada al entorno de cómputo donde se enrutan las solicitudes de todos los grupos de investigación.
- Quota Share Policy: Define el peso porcentual asignado a cada cuota virtual (QS1, QS2, QS3), su estrategia (Lend/Borrow) y el parámetro
preemptionRetriesBeforeTerminationpara fijar un techo a los reintentos automáticos.
Preguntas Frecuentes
¿Compartir cuotas de GPU garantiza que nunca habrá tiempos de espera?No. Si todos los equipos demandan su capacidad máxima simultáneamente, los trabajos deberán esperar en la cola conforme a los límites físicos contratados. La ventaja radica en aprovechar los valles de demanda ociosa que normalmente se desperdician.
El trabajo vuelve al estado RUNNABLE para reanudarse cuando haya capacidad. Si el script de entrenamiento tiene habilitado checkpointing periódico hacia Amazon S3, continuará desde la última época guardada; si carece de checkpoints, comenzará desde el inicio.
Sí. Habilitando la preempción interna por prioridad, un trabajo crítico recién enviado puede desplazar a trabajos secundarios que se encuentren en ejecución dentro de la misma cuota.
AWS documenta esta funcionalidad utilizando el SageMaker Python SDK v3 y plantillas de infraestructura de AWS CloudFormation o CDK.
