Las listas de preferencias de instancias de Amazon SageMaker sustituyen los reintentos manuales de GPU, pero no la planificación de capacidad

Amazon ha presentado las listas de preferencias de instancias de Amazon SageMaker, que permiten que una solicitud de entrenamiento incluya hasta cinco opciones de cómputo ordenadas en lugar de un único tipo de instancia fijo. SageMaker AI revisa esas opciones por orden de prioridad e inicia la primera configuración con capacidad disponible.

El cambio aborda un persistente problema operativo. Los trabajos de entrenamiento de SageMaker respaldados por GPU pueden permanecer pendientes cuando el hardware solicitado no está disponible. Los equipos han respondido supervisando la capacidad, reenviando trabajos o manteniendo scripts que prueban configuraciones alternativas.

AWS traslada ahora esa decisión de reintento al programador administrado. Sin embargo, la función no crea capacidad de GPU ni demuestra que distintos aceleradores ejecutarán una carga de trabajo correctamente. Su valor depende de que los equipos puedan hacer que su código de entrenamiento, sus objetivos de rendimiento y sus controles de costos sean realmente flexibles respecto al hardware.

Esta distinción somete a presión una práctica habitual de la nube: tratar un tipo de instancia como una propiedad fija de cada trabajo. Google Cloud ya pone en cola solicitudes flexibles de aceleradores mediante su Dynamic Workload Scheduler. Los usuarios de Azure Machine Learning también planifican en torno a cuotas de cómputo específicas por región y familia. AWS está convirtiendo ahora la flexibilidad de hardware declarada en una parte fundamental de los trabajos individuales de SageMaker.

Qué cambió AWS con las listas de preferencias de instancias de Amazon SageMaker

Una solicitud de SageMaker ahora puede expresar varias configuraciones de cómputo aceptables sin requerir un controlador externo de reintentos.

AWS anunció la función el 15 de septiembre de 2026, tanto para trabajos de entrenamiento como de procesamiento. Está disponible a través de las API, SDK, herramientas de línea de comandos y la consola de SageMaker en todas las regiones de AWS donde SageMaker AI está disponible, según el aviso de disponibilidad regional de la empresa.

Una lista de preferencias contiene entre dos y cinco tipos de instancia por orden de prioridad. SageMaker valida la lista, realiza una comprobación en memoria y selecciona la primera configuración con capacidad disponible. Solo una configuración incluida en la lista ejecuta el trabajo.

Si ninguna está disponible de inmediato, el trabajo entra en una cola basada en eventos. SageMaker vuelve a intentarlo a medida que cambia la capacidad, en lugar de exigir a un proceso cliente que consulte el servicio y reenvíe las solicitudes. El período total de espera puede limitarse con MaxPendingTimeInSeconds.

Ese tiempo de espera se aplica a toda la lista de preferencias, no por separado a cada opción. AWS también indica que solo entra en vigor cuando al menos una configuración incluida usa cómputo acelerado de familias como ml.p, ml.g o ml.trn.

Este comportamiento importa porque una preferencia es más que un nombre de instancia alternativo. Los equipos pueden asignar un número de instancias diferente a cada opción. Un trabajo podría preferir dos nodos ml.g6.48xlarge, pero aceptar cuatro nodos ml.g5.48xlarge cuando esa segunda configuración ofrece un rendimiento agregado suficiente.

AWS permite dos modelos de recuento. Un ResourceConfig.InstanceCount compartido puede aplicarse a todas las preferencias, o cada preferencia puede definir su propio recuento. Combinar ambos enfoques no es válido, como explica la referencia de la API.

La función también se conecta con los SageMaker Flexible Training Plans, que reservan capacidad de GPU compatible durante un período definido. Un trabajo de entrenamiento puede colocar primero una configuración compatible respaldada por un plan y, después, enumerar alternativas bajo demanda. Si la opción reservada no puede aprovisionarse, SageMaker continúa con las preferencias restantes.

Esa integración se limita al entrenamiento. Los trabajos de procesamiento reciben el mismo mecanismo ordenado de respaldo, pero no pueden asociar preferencias con Flexible Training Plans.

El caso de uso de procesamiento sigue siendo significativo. SageMaker Processing ejecuta infraestructura administrada para preparación de datos, ingeniería de características, evaluación y trabajo relacionado. Estos trabajos suelen tolerar una gama de hardware más amplia que los trabajos de entrenamiento distribuido estrechamente optimizados.

AWS presenta el cambio como una alternativa a los bucles manuales de reintentos y scripts de supervisión de capacidad en su publicación de lanzamiento. Ese es el beneficio inmediato más claro. Una canalización envía un trabajo, mientras SageMaker asume la búsqueda de capacidad dentro de los límites declarados.

El programador no elige una máquina arbitraria que considere equivalente. Sigue el orden del cliente. Esto preserva una división útil de responsabilidades: los operadores deciden qué configuraciones son válidas y SageMaker decide qué opción válida puede iniciarse primero.

Se trata de un pequeño cambio de API con una implicación operativa mayor. La flexibilidad de infraestructura ahora puede acompañar a la definición del trabajo en lugar de residir en el código de orquestación circundante.

Por qué la capacidad de GPU de SageMaker se convirtió en un problema de programación

El recurso escaso ya no es solo una GPU; es la configuración de clúster adecuada en la región adecuada y en el momento adecuado.

Los equipos de entrenamiento de IA suelen hablar de los aceleradores como unidades intercambiables, pero la capacidad en la nube se divide entre familias de instancias, tamaños, regiones, grupos de disponibilidad, cuotas y modelos de reserva. Un cliente puede tener permiso para solicitar una máquina sin que esa máquina esté lista para asignación inmediata.

Esa fragmentación genera una gestión de fallos incómoda. Una canalización puede ser técnicamente correcta y aun así perder horas porque la configuración seleccionada no puede iniciarse. Entonces, un ingeniero debe decidir si espera, cambia el hardware, modifica el número de nodos o traslada la carga de trabajo.

Antes de las listas de preferencias, los trabajos de entrenamiento de SageMaker especificaban un tipo de instancia durante el envío. Los equipos que aceptaban alternativas debían codificar esa flexibilidad en otra parte. Algunos crearon funciones de reintento en torno a fallos de API. Otros enviaban varias variantes y cancelaban las restantes cuando una se iniciaba.

Ambos patrones introducen trabajo de coordinación. Varias solicitudes activas pueden complicar la observabilidad y la cancelación. Los scripts de reintento secuencial necesitan gestión de estado, reglas de espera progresiva, manejo de tiempos de espera, permisos y protección contra ejecuciones duplicadas.

La supervisión de capacidad también se convierte en otro sistema de producción. El equipo debe mantenerlo cuando cambia el comportamiento de los SDK, hacer visibles sus fallos y garantizar que un controlador reiniciado no inicie dos veces el mismo trabajo costoso.

Las listas de preferencias de instancias de Amazon SageMaker absorben parte de ese plano de control. La solicitud de trabajo lleva un conjunto acotado de resultados aceptables, y el servicio administrado realiza la selección una vez que encuentra capacidad.

Ese modelo refleja el comportamiento de muchas cargas de trabajo reales. El ajuste fino, la evaluación, el preprocesamiento y la experimentación con modelos suelen tener una configuración preferida en lugar de una única configuración matemáticamente obligatoria. Un equipo podría favorecer GPU más recientes por velocidad, pero aceptar GPU más antiguas cuando el tiempo de inicio importa más.

El mismo principio se aplica al número de nodos. Dos nodos más rápidos y cuatro más lentos pueden, en ocasiones, cumplir un objetivo de finalización similar. No son intrínsecamente equivalentes, pero los desarrolladores pueden probarlos y declarar ambos aceptables.

AWS no está sola al convertir la escasez en una interfaz de programación. El modo Flex-start de Google Cloud pone en cola las solicitudes de aceleradores hasta que todos los recursos necesarios estén disponibles. Google lo posiciona para trabajos de entrenamiento que pueden tolerar una hora de inicio flexible.

Los mecanismos difieren. El modelo de Google enfatiza el cumplimiento de una asignación y duración de aceleradores solicitadas. AWS permite que un trabajo de SageMaker avance por un conjunto ordenado de tipos y recuentos. Ambos enfoques piden a los clientes que expresen flexibilidad en lugar de sondear repetidamente la capacidad.

Azure Machine Learning expone otra parte de la restricción. Sus cuotas de cómputo se administran por región y familia de VM, con límites separados para el uso del espacio de trabajo y de la suscripción. Las familias de GPU pueden comenzar sin cuota predeterminada de núcleos dedicados, según la suscripción.

Estos sistemas muestran por qué la disponibilidad de aceleradores no puede reducirse a una página de catálogo. Una instancia incluida en la lista puede ser compatible y, aun así, no estar disponible para una cuenta, ubicación, tamaño de trabajo o ventana temporal concretos.

Para los clientes de AWS, la presión inmediata recae sobre los equipos que mantienen lógica de aprovisionamiento personalizada. Si un servicio de reintentos solo recorre tipos de instancia de SageMaker, su función central ahora se solapa con la plataforma.

La función también presiona los estándares internos rígidos que aprueban exactamente un tipo de instancia por modelo. Esos estándares simplificaban la evaluación comparativa y la gobernanza, pero convierten cada escasez de capacidad en un bloqueo. Los equipos ahora tienen un motivo para certificar varias configuraciones para cada carga de trabajo.

Esto no elimina la orquestación. Las canalizaciones aún necesitan dependencias, seguimiento de artefactos, políticas de fallo y validación posterior a la ejecución. El cambio acota la tarea de la orquestación al trasladar una decisión recurrente —qué configuración aceptable puede iniciarse— a SageMaker.

La flexibilidad sustituye la lógica de reintentos, no las restricciones de capacidad

El mecanismo mejora la búsqueda de infraestructura disponible, pero no puede proporcionar infraestructura que no existe.

Cuando llega un trabajo, SageMaker valida su configuración y lista de preferencias frente a los recursos y límites compatibles. El programador comprueba entonces las opciones una vez en el orden declarado. La primera opción disponible gana e inicia el aprovisionamiento.

Si todas las opciones no están disponibles, la cola basada en eventos espera un cambio de capacidad relevante. Esto es más eficiente que la consulta continua por parte del cliente, pero sigue siendo una cola. Un trabajo puede permanecer pendiente hasta que expire su tiempo de espera.

Ese límite importa al evaluar la afirmación de AWS de que la función ayuda a que los trabajos se inicien antes. La comparación es con un trabajo fijado a una configuración no disponible o con un sistema de reintentos administrado por el cliente más lento. AWS no ha publicado evaluaciones comparativas independientes que muestren mejoras en el tiempo de inicio mediano entre regiones, familias de instancias o tamaños de clúster.

Una lista tampoco combina capacidad parcial de varias entradas. Si una preferencia solicita ocho nodos, SageMaker necesita que esa configuración seleccionada pueda aprovisionarse. El sistema elige una preferencia completa en lugar de ensamblar un clúster heterogéneo a partir de fragmentos disponibles.

Esto separa las preferencias de instancias de los clústeres heterogéneos de SageMaker. Un clúster heterogéneo ejecuta deliberadamente varios grupos de instancias dentro de un trabajo de entrenamiento. Una lista de preferencias representa alternativas mutuamente excluyentes, de las cuales solo una se convierte en el entorno de cómputo del trabajo.

La distinción protege la consistencia de ejecución. Los marcos de entrenamiento distribuido suelen esperar una topología conocida una vez que comienza el trabajo. Seleccionar una configuración predefinida es más sencillo que mezclar dinámicamente arquitecturas de hardware, características de red y perfiles de memoria.

La integración con Training Plan añade otra capa de decisión. Una preferencia puede apuntar a un plan reservado compatible, mientras que las entradas posteriores usan capacidad bajo demanda. AWS evalúa primero la opción reservada cuando los operadores la colocan en primer lugar.

Esa secuencia ofrece a las organizaciones una forma directa de priorizar capacidad prepagada sin convertirla en la única vía del trabajo. Sin embargo, la alternativa de respaldo puede cambiar el resultado económico. Una opción bajo demanda puede tener un coste efectivo diferente, y un mayor número de nodos puede amplificar esa diferencia.

La función tampoco parece sustituir a Managed Spot Training. Managed Spot Training aborda una disyuntiva distinta al usar capacidad EC2 Spot interrumpible. AWS afirma que este enfoque puede reducir el coste de computación, aunque las interrupciones pueden prolongar el tiempo de finalización y exigir puntos de control.

Las preferencias de instancia abordan principalmente la selección inicial de capacidad entre configuraciones aceptables. El entrenamiento Spot aborda el modelo de compra y el riesgo de interrupciones después de que una carga de trabajo obtiene recursos de computación. Los equipos deben evaluar estas dimensiones por separado.

Por tanto, el mejor caso de uso es un trabajo sensible a los reinicios, pero flexible en cuanto a hardware. Pensemos en una canalización de evaluación nocturna que puede ejecutarse en varias generaciones de GPU. No llegar a la ventana de informes de la mañana importa, pero utilizar el acelerador absolutamente más rápido no.

El equipo puede certificar varias configuraciones, ordenarlas según su equilibrio preferido entre tiempo de finalización y gasto esperado, y luego establecer un período máximo de espera. SageMaker selecciona dentro de ese conjunto probado.

Las grandes ejecuciones de preentrenamiento presentan un caso más difícil. Sus patrones de comunicación, demandas de memoria, comportamiento de los puntos de control y topología pueden estar ajustados a un acelerador y una interconexión concretos. Una alternativa nominalmente compatible podría hacer que el trabajo sea más lento, más caro o inestable.

El nuevo planificador no puede decidir si esa alternativa sigue siendo científicamente o económicamente válida. Ese juicio sigue correspondiendo al propietario de la carga de trabajo.

Por lo tanto, las listas de preferencias de instancia de Amazon SageMaker son declarativas, no adaptativas en sentido amplio. SageMaker responde a señales de capacidad, pero no evalúa el modelo, reescribe configuraciones distribuidas ni optimiza la lista frente a un plazo.

Esto sigue siendo relevante. Los servicios gestionados crean valor cuando asumen una responsabilidad repetitiva y bien delimitada de cada cliente y la implementan una sola vez. La alternativa de capacidad encaja en ese patrón, siempre que el cliente proporcione límites de compatibilidad honestos.

La compatibilidad y el coste siguen siendo responsabilidad del operador

El riesgo más importante no es que SageMaker elija la preferencia equivocada; es que un equipo declare aceptable una preferencia insegura.

AWS advierte explícitamente que SageMaker no valida la compatibilidad entre tipos. El servicio no determina si un contenedor admite todas las arquitecturas de GPU, si sus controladores son compatibles o si su configuración distribuida requiere redes Elastic Fabric Adapter.

Por tanto, un trabajo puede superar la validación de la solicitud y aun así fallar después del aprovisionamiento. Ese resultado consume tiempo de arranque y puede debilitar el beneficio esperado de la alternativa automática.

El comportamiento de los frameworks merece especial atención. Las capacidades de CUDA, las bibliotecas de comunicación colectiva, los formatos de precisión mixta, las salidas de compiladores y los kernels específicos de cada dispositivo pueden variar entre generaciones de aceleradores. No debe suponerse que un contenedor probado en hardware H100 se comportará de forma idéntica en hardware A100 o L40S.

La memoria es otro límite. Una carga de trabajo que cabe en un acelerador puede superar la memoria del dispositivo en otro, incluso cuando el rendimiento teórico agregado parece similar. Aumentar el número de nodos no resuelve automáticamente las restricciones de memoria por dispositivo.

La topología distribuida también afecta al rendimiento. Sustituir dos nodos de gran ancho de banda por cuatro nodos más lentos modifica el volumen de comunicación, la sobrecarga de sincronización y la exposición a fallos. Un número equivalente de GPU o una estimación aproximada de cómputo no garantizan el mismo tiempo de finalización.

Los ejemplos de AWS ilustran la intención, no una fórmula universal de equivalencia. Un ejemplo enumera dos instancias ml.g6.48xlarge antes que cuatro instancias ml.g5.48xlarge. El cliente debe decidir si esa relación se mantiene para su modelo, tamaño de lote, patrón de red y pila de software.

Los equipos deben evaluar cada configuración incluida en la lista con la misma imagen de contenedor, ruta de datos y lanzador distribuido que se utilizan en producción. El registro de aprobación resultante debe incluir tiempo de ejecución, comprobaciones de convergencia, utilización, tasa de fallos y validación de resultados.

La política de costes exige la misma disciplina. El orden de preferencia expresa prioridad, no un límite presupuestario. Una alternativa con más instancias puede iniciarse antes y, sin embargo, generar una factura total mayor que la opción preferida.

A la inversa, el hardware más antiguo puede tardar más y eliminar un aparente ahorro por instancia. La medida relevante es el resultado completo del trabajo, incluidos el retraso de inicio, el tiempo de ejecución, los reintentos, el almacenamiento y cualquier impacto posterior en los plazos.

El lanzamiento también crea un requisito de observabilidad. Los equipos deben registrar qué preferencia resultó seleccionada, cuánto tiempo esperó el trabajo, por qué se ordenaron las alternativas y si el rendimiento real coincidió con la evaluación comparativa.

Sin esos registros, la selección automática se vuelve opaca. Los ingenieros pueden observar una mayor variación en el tiempo de ejecución o el coste sin saber que la familia de instancias subyacente cambió entre ejecuciones.

También puede ser necesario actualizar las normas de gobernanza. AWS admite políticas de identidad que restringen los tipos de instancia de SageMaker. La lista de preferencias aprobada de una organización debe mantenerse dentro de esos controles, las cuotas de cuenta y la disponibilidad regional.

La capacidad reservada introduce otro posible malentendido. Una preferencia de Flexible Training Plan puede proporcionar un compromiso de capacidad más sólido, pero una alternativa no convierte una reserva no disponible en más suministro reservado. Traslada el trabajo a una vía bajo demanda aceptable por separado.

Los trabajos de procesamiento necesitan su propia revisión. Una alternativa de CPU puede tener sentido para algunas transformaciones, pero también puede alterar drásticamente el tiempo de finalización. Los equipos deben evitar incluir una opción de CPU simplemente porque la API lo permita.

La ausencia de datos de campo publicados es la mayor incertidumbre actual. AWS ha descrito el flujo de programación y las reglas de configuración, pero los clientes aún no cuentan con evidencia amplia sobre las mejoras en tiempos de inicio bajo distintas condiciones de escasez.

Las mediciones útiles deben comparar la función con la referencia existente de cada equipo. Esto incluye el tiempo desde el envío hasta la ejecución, el porcentaje de trabajos que utilizan una alternativa, las tasas de tiempo de espera agotado, el consumo total de computación y los incidentes operativos provocados por cambios de configuración.

Estas mediciones revelarán si la flexibilidad de capacidad de GPU de SageMaker elimina trabajo operativo real o simplemente traslada la variabilidad a una capa menos visible.

Tres señales mostrarán si la función funciona en la práctica

La adopción debe evaluarse por los resultados de los trabajos, no por cuántos equipos añaden un segundo tipo de instancia a su configuración.

La primera señal es la frecuencia de uso de alternativas junto con el tiempo de inicio. Los equipos deben medir con qué frecuencia SageMaker selecciona una opción por debajo de la primera preferencia y cómo eso modifica la latencia desde el envío hasta el inicio.

Una alta tasa de alternativas con esperas más cortas respaldaría la afirmación central de AWS. Demostraría que existe capacidad en el conjunto más amplio incluso cuando el tipo preferido está restringido.

Una alta tasa de alternativas sin esperas más cortas debilitaría ese argumento. Podría indicar que las alternativas incluidas comparten el mismo cuello de botella regional, que los clústeres solicitados son demasiado grandes o que la cola basada en eventos no mejora de forma material la asignación para esa carga de trabajo.

La segunda señal es la variación de rendimiento y coste entre las configuraciones seleccionadas. Cada alternativa debe vincularse al tiempo de ejecución, la utilización, el estado de finalización y el consumo total de recursos.

Resultados estables reforzarían el argumento de tratar la infraestructura como un conjunto de preferencias. Grandes desviaciones demostrarían que las alternativas no eran realmente equivalentes, aunque cada configuración pudiera ejecutar técnicamente el contenedor.

Esto es especialmente importante para las canalizaciones recurrentes. Un equipo puede aceptar una ejecución más lenta durante un experimento urgente, pero rechazar una imprevisibilidad persistente en un calendario diario de producción.

La tercera señal es cómo AWS amplía la función y su telemetría asociada. Los clientes deben observar si aparecen eventos de selección más detallados, explicaciones más claras de los estados pendientes, herramientas de ordenación sensibles al coste y una integración más amplia con los controles de canalización.

También sería importante admitir políticas más matizadas. Con el tiempo, los operadores podrían querer restricciones como un plazo, un límite de gasto o el requisito de que el rendimiento de la alternativa se mantenga dentro de un rango probado. La lista ordenada actual codifica esos juicios manualmente.

Las respuestas de los competidores ofrecen contexto de apoyo, pero la evidencia decisiva procederá de las operaciones de los clientes. Google ya trata la escasez de aceleradores como un problema de programación mediante Dynamic Workload Scheduler. Azure expone los límites de cuota que determinan si los trabajos gestionados pueden ejecutarse.

El movimiento distintivo de AWS consiste en colocar varias configuraciones aceptables directamente dentro de una solicitud de entrenamiento o procesamiento de SageMaker. Si los clientes logran inicios más rápidos sin una variación inaceptable, ese modelo será difícil de ignorar para las plataformas gestionadas de ML.

La prueba a corto plazo es sencilla. Seleccione una carga de trabajo flexible en hardware, evalúe cada configuración candidata y defina un tiempo máximo de espera antes de activar la alternativa automática. Después, compare al menos varias ejecuciones con el proceso anterior de reintentos.

Registre el tipo de instancia elegido, la duración de la cola, el tiempo de ejecución, el estado de finalización y el uso total de recursos. No considere un lanzamiento exitoso como el resultado completo.

Las listas de preferencias de instancia de Amazon SageMaker hacen que la gestión de capacidad sea menos manual, pero recompensan la preparación. Los equipos que validen sus alternativas pueden eliminar código de infraestructura frágil. Los equipos que introduzcan alternativas especulativas quizá solo automaticen el descubrimiento de incompatibilidades.

La pregunta útil no es si cinco opciones son mejores que una. Es si su organización puede definir cinco resultados realmente aceptables, ordenarlos deliberadamente y medir qué ocurre cuando SageMaker elige entre ellos.