La gestión de cuotas de AWS Batch permite a los equipos compartir GPU y recuperar sus asignaciones
La gestión de cuotas de AWS Batch permite a los equipos ceder capacidad de entrenamiento inactiva sin perder la posibilidad de recuperarla de las cargas de trabajo que la han tomado prestada. Esta capacidad conecta las asignaciones de recursos con las decisiones de programación de Amazon SageMaker Training, el servicio gestionado de AWS para entrenar modelos de aprendizaje automático. La contrapartida central es sencilla: los equipos pueden utilizar la capacidad sobrante de otros, pero sus trabajos deben poder tolerar la pérdida de acceso cuando el propietario la necesite de nuevo.
La guía publicada por AWS el 29 de octubre explica esta contrapartida mediante distintas políticas de carga de trabajo. La capacidad en sí se lanzó el 25 de marzo de 2026, según el anuncio de gestión de cuotas de la empresa. La diferencia es importante: el desarrollo de esta semana es un ejemplo operativo detallado de una función ya existente, no su lanzamiento inicial.
Los enfoques enfrentados son conocidos para los equipos de infraestructura: proteger las asignaciones mediante una separación rígida o agrupar los recursos y negociar el acceso cuando la demanda entra en conflicto. AWS incorpora esas negociaciones a la política de programación. Eso desplaza la presión hacia los administradores de plataforma y los responsables del entrenamiento, que deben decidir qué experimentos merecen un acceso predecible y cuáles pueden aceptar interrupciones.
La gestión de cuotas de AWS Batch convierte las asignaciones en reglas de programación
El cambio consiste en vincular la asignación de un equipo con su derecho a recuperar la capacidad que otros equipos hayan tomado prestada.
Una cuota compartida, una cola virtual con límites de capacidad y reglas de compartición, representa a un equipo, proyecto o agrupación de cargas de trabajo. Los administradores vinculan esas cuotas a una cola de trabajos, el contenedor que alberga el trabajo enviado. AWS documenta un máximo de 20 cuotas por cola, con hasta cinco límites de capacidad por cuota.
Esos límites utilizan tipos de instancia de entrenamiento compatibles, es decir, configuraciones específicas de máquinas, en lugar de un grupo indiferenciado de GPU intercambiables. Las políticas de cuotas compartidas de AWS ofrecen tres opciones. RESERVE mantiene la capacidad inactiva para su propia cuota. LEND permite que otros utilicen capacidad inactiva. LEND_AND_BORROW permite prestar y tomar prestado, sujeto a un límite de préstamo configurado.
Se trata de un sistema de asignación con reglas explícitas sobre el acceso temporal. El derecho de un equipo y su consumo actual ya no tienen por qué coincidir en todo momento. La capacidad sobrante puede atender otros trabajos sin cambiar permanentemente la asignación subyacente.
Esta distinción facilita el razonamiento sobre la infraestructura compartida. Una asignación responde quién tiene derecho a reclamar recursos cuando vuelve la demanda. El consumo responde quién utiliza los recursos ahora. Tratar ambas cuestiones por separado ofrece a los administradores una forma de permitir flexibilidad sin renunciar a la propiedad.
Pensemos en un equipo de plataforma hipotético que divide el acceso al entrenamiento entre grupos de investigación. Una partición fija protege a cada grupo de la competencia, pero puede dejar recursos sin utilizar. Un grupo sin restricciones mejora el acceso durante los periodos tranquilos, pero deja al equipo de plataforma explicando por qué un recurso asignado no está disponible.
Las políticas de cuotas crean una posición intermedia. El préstamo se convierte en acceso condicionado con un mecanismo de recuperación establecido. El acuerdo sigue requiriendo consenso sobre las asignaciones, pero los administradores pueden codificarlo antes de que surja una disputa de programación.
AWS documenta esta capacidad para las colas de SageMaker Training conectadas a un entorno de servicio SAGEMAKER_TRAINING, la configuración de Batch asociada a la ejecución de entrenamiento gestionado. Los lectores no deberían interpretarla como una función general de compartición de recursos para todas las cargas de trabajo de AWS Batch.
El alcance importa al evaluar una migración. Un equipo que ya envía trabajos de SageMaker se enfrenta a una decisión operativa distinta de la de otro que gestiona el entrenamiento mediante otro sistema de ejecución. La política de programación forma parte de ese flujo de trabajo más amplio.
Por tanto, la cuestión práctica es más específica que determinar si la compartición está disponible. Se trata de saber si la organización puede expresar sus compromisos actuales mediante estas cuotas sin crear expectativas engañosas sobre un acceso garantizado.
Los equipos de plataforma deben definir qué promete realmente una asignación
El préstamo automático reduce la coordinación de programación solo después de que los equipos acuerden las condiciones asociadas a la capacidad prestada.
La presión inmediata recae sobre los equipos de plataforma responsables de la infraestructura de entrenamiento compartida. Su trabajo va más allá de asignar acceso. Deben distinguir entre una asignación duradera y un permiso temporal para consumir recursos no utilizados.
Esta distinción parece administrativa hasta que llega una fecha límite. Un equipo prestatario puede considerar que una ejecución de entrenamiento exitosa demuestra que la capacidad está disponible. El equipo prestamista puede considerar esos mismos recursos como parte de una asignación que espera recuperar.
Ambas interpretaciones son comprensibles. Sin una política explícita, el desacuerdo se vuelve personal: alguien debe decidir qué experimento se detiene. Con una política explícita, el desacuerdo se traslada antes, al acuerdo de asignación.
Aquí es donde el uso compartido de capacidad de GPU se convierte en una cuestión organizativa. El programador puede aplicar reglas de forma coherente, pero la coherencia no determina si las reglas se ajustan a las prioridades empresariales. Los administradores siguen necesitando una explicación defendible para el tratamiento de cada cuota.
El trabajo de investigación ofrece un contraste hipotético útil. Los experimentos exploratorios suelen tener ventanas de finalización flexibles, mientras que una ejecución de entrenamiento vinculada a una fecha límite de evaluación tiene menos margen de espera. Esas diferencias pueden justificar distintas políticas de compartición sin implicar que el trabajo de un equipo tenga menos valor.
Los casos difíciles surgen dentro de un mismo equipo. Un solo grupo puede encargarse de experimentos exploratorios, preparación de lanzamientos e investigaciones urgentes. Asignar una única política a todo el grupo corre el riesgo de tratar cargas de trabajo distintas como si sus costes de interrupción fueran idénticos.
Organizar las cuotas por proyecto o carga de trabajo puede ayudar a expresar esas diferencias. También crea más límites de política que mantener. La agrupación adecuada depende de la fiabilidad con la que los usuarios puedan clasificar el trabajo antes de enviarlo.
La prioridad introduce otro problema de gobernanza. Si los usuarios pueden elevar la urgencia de un trabajo cada vez que se acerca una fecha límite, los valores de prioridad pueden perder significado. Todos los equipos tienen incentivos para proteger su propio tiempo de finalización.
La respuesta debe ser operativamente concreta. Los equipos necesitan definiciones compartidas de urgencia, una persona responsable de las excepciones y una forma de revisar los cambios. De lo contrario, la programación automatizada puede reproducir la misma negociación mediante cambios de configuración.
Por ejemplo, una organización podría distinguir entre no alcanzar el objetivo de un experimento y bloquear una decisión de lanzamiento. Se trata de una elección de política ilustrativa, no de una clasificación integrada de AWS. Su valor reside en hacer comprensibles las consecuencias antes de que la capacidad entre en disputa.
La documentación respalda este acuerdo. Los equipos de ingeniería pueden conservar las decisiones de asignación, las hipótesis de recuperación y las excepciones en una base de conocimiento con capacidad de búsqueda. El registro útil explica por qué existe una política y quién puede modificarla.
Este trabajo no desaparece cuando un programador asume la aplicación de las reglas. Se vuelve más visible. Un acuerdo de préstamo que antes vivía en mensajes o reuniones ahora debe resistir el contacto con el comportamiento real de las cargas de trabajo.
Por eso una implementación debería comenzar con las características de las cargas de trabajo, en lugar de hacerlo solo con los nombres de los equipos. La tolerancia a las interrupciones, el comportamiento de recuperación y la sensibilidad a los plazos ofrecen una base más sólida para la política que los organigramas.
La capacidad prestada conlleva un contrato de interrupción
El ejemplo de AWS considera la tolerancia a las interrupciones como un motivo para elegir una política de compartición, no como una consideración secundaria.
La guía de octubre configura tres cuotas, a cada una de las cuales se le asigna una instancia ml.g5.xlarge. Su cuota de trabajo en segundo plano puede prestar y tomar prestado, con interrupciones basadas en prioridad habilitadas. AWS describe explícitamente esos trabajos como usuarios de puntos de control, estados de entrenamiento guardados que permiten la recuperación tras una interrupción.
La cuota de prioridad media presta capacidad inactiva, pero no toma prestado. Sus trabajos esperan cuando su asignación está ocupada. La cuota protegida no presta ni toma prestado, y desactiva las interrupciones entre sus propios trabajos.
En el ejemplo de cuotas de SageMaker, un nuevo trabajo en la cuota prestamista hace que Batch recupere capacidad de la cuota prestataria. Por separado, aumentar la prioridad de un trabajo en espera hace que otro trabajo dentro de su cuota ceda el paso.
Son mecanismos distintos. La preempción entre cuotas, que detiene trabajo para restaurar capacidad a la cuota que la asignó, aplica el acuerdo de préstamo. La preempción dentro de una cuota, que detiene trabajo de menor prioridad dentro de una misma cuota, aplica las reglas internas de urgencia de esa cuota.
El ejemplo establece que distintas políticas pueden coexistir dentro de un mismo acuerdo general. No establece que todas las cargas de trabajo se beneficien de la configuración de préstamo más permisiva.
Para un experimento en segundo plano, la capacidad prestada ofrece una oportunidad de avanzar antes. Su responsable acepta incertidumbre sobre la finalización. Para una tarea vinculada a una fecha límite, evitar esa incertidumbre puede ser más valioso que obtener capacidad adicional durante periodos tranquilos.
Esta distinción cambia la forma en que los equipos deberían describir el préstamo. Es acceso temporal con una posible interrupción, no una extensión de la asignación fiable del equipo.
Un contrato de interrupción debería responder varias preguntas prácticas. ¿Puede recuperarse la carga de trabajo? ¿Quién asume los fallos de recuperación? ¿El tiempo de finalización previsto supone acceso continuo? ¿Qué sucede cuando el mismo trabajo cede repetidamente?
Estas preguntas siguen siendo relevantes incluso cuando el sistema se encarga de detener y reenviar el trabajo. La automatización controla las transiciones de ejecución. Los propietarios de la aplicación siguen siendo responsables de decidir si el comportamiento resultante es aceptable.
También existe un problema de comunicación. Un trabajo que empieza a ejecutarse genera una expectativa de avance. Los usuarios deben entender que ejecutarse con capacidad prestada no implica la misma expectativa de continuidad que ejecutarse dentro de su asignación.
De lo contrario, el préstamo exitoso puede crear su propio problema de adopción. Los equipos se acostumbran a la capacidad sobrante, la incorporan a sus previsiones de entrega y después interpretan la recuperación legítima como un fallo del servicio.
Por ello, la política debe aparecer en el lenguaje de planificación, no solo en la configuración. Las previsiones deberían distinguir entre el trabajo respaldado por capacidad asignada y el trabajo acelerado mediante acceso oportunista.
Eso no hace que la ejecución con capacidad prestada sea menos útil. Hace que su valor sea más fácil de evaluar. El progreso logrado durante periodos que de otro modo estarían inactivos tiene valor incluso cuando su calendario es incierto, siempre que los equipos eviten prometer la finalización sobre esa base.
La lección más amplia de la guía de AWS es que la utilización y la previsibilidad pueden recibir un tratamiento distinto según la carga de trabajo. Los administradores no tienen que imponer el mismo compromiso en todas partes.
La calidad de la recuperación determina si la compartición genera avances útiles
Un planificador puede devolver un trabajo interrumpido a una cola sin garantizar que la aplicación conserve su trabajo previo.
El comportamiento de preempción de trabajos de AWS hace explícita la semántica de ejecución. La preempción detiene el trabajo en estados programado, iniciando o en ejecución para dar cabida a un trabajo que puede ejecutarse. De forma predeterminada, los trabajos preemptados vuelven al estado ejecutable sin un límite de preempciones.
Los administradores pueden establecer preemptionRetriesBeforeTermination para limitar ese comportamiento. Un valor de cero provoca un fallo en la primera preempción. AWS también indica que su heurística de selección considera los recursos de instancias prestados, las prioridades relativas y la duración del trabajo.
Estos detalles explican por qué «la prioridad más alta se ejecuta primero» necesita matices. Los requisitos de recursos y el acuerdo de compartición participan en las decisiones de programación. La prioridad es una entrada, no una promesa universal de que cualquier trabajo urgente comience de inmediato.
La preocupación a nivel de aplicación es la recuperación. Un trabajo puede ser elegible para ejecutarse de nuevo y aun así carecer del estado necesario para continuar de forma eficiente. La puesta en cola y la recuperación resuelven problemas relacionados, pero distintos.
La compatibilidad con puntos de control de entrenamiento de AWS guarda el estado del modelo y sincroniza los archivos de puntos de control configurados con Amazon S3, su servicio de almacenamiento de objetos. El código de entrenamiento personalizado debe guardar y cargar correctamente el estado pertinente. AWS también deja la frecuencia de los puntos de control bajo el control del script de entrenamiento.
Eso significa que una política de préstamo debe depender de una ruta de recuperación demostrada. Simplemente habilitar un destino de almacenamiento no demuestra que una aplicación de entrenamiento concreta pueda reconstruir todo lo que necesita.
En un experimento hipotético, los parámetros del modelo podrían ser solo una parte del estado necesario. Los propietarios de las aplicaciones deben examinar el comportamiento completo de continuación que espera su framework. La prueba adecuada es si la ejecución interrumpida produce un progreso aceptable y resultados válidos.
La frecuencia de los puntos de control añade otra disyuntiva. Guardar con más frecuencia puede conservar avances más recientes, mientras que el propio guardado consume recursos. El intervalo útil depende de la carga de trabajo, no de una preferencia de programación universal.
Estas son consideraciones de ingeniería, no pruebas de que la funcionalidad de AWS falle. Explican por qué las afirmaciones sobre utilización requieren mediciones de las cargas de trabajo. Una instancia ocupada no demuestra automáticamente que se haya completado más entrenamiento.
Una evaluación útil debe incluir cómputo repetido, preparación para el reinicio, tiempo de espera tras la interrupción y finalización correcta. Observar únicamente los recursos ocupados puede pasar por alto el coste de lograr esa utilización.
El riesgo es mayor cuando un equipo trata cada carga de trabajo ejecutable como un prestatario igual de adecuado. Algunos experimentos toleran bien el acceso fragmentado. Otros generan suficiente sobrecarga de recuperación como para que esperar un acceso estable sea la opción más práctica.
La interrupción repetida también merece atención por separado. Un trabajo que se reanuda repetidamente puede consumir recursos y aun así no cumplir su ventana de finalización. Un límite de reintentos proporciona un control, pero elegir ese límite exige una respuesta operativa cuando se alcanza.
Alguien debe ser responsable de esa respuesta. El fallo debe conducir a una decisión clara sobre reclasificación, reenvío o un acuerdo de capacidad diferente. De lo contrario, una política de reintentos limitada simplemente traslada la carga de coordinación a la gestión de incidentes.
Las políticas protegidas también tienen matices. AWS documenta que reducir los límites de capacidad de una participación puede hacer que su trabajo existente sea elegible para preempción. Por lo tanto, los administradores deben tratar los cambios de asignación como cambios que afectan a la ejecución.
La expectativa de continuidad de un equipo depende tanto de su política de compartición como de la estabilidad de su asignación. La revisión de la configuración es importante porque una modificación de la política puede alterar las condiciones bajo las que el trabajo en ejecución permanece protegido.
El ejemplo publicado por AWS es una demostración operativa, no una evaluación independiente de los ahorros de los clientes. Proporciona un mecanismo para evaluar. No ofrece una respuesta universal sobre rendimiento o tiempo de finalización.
El argumento más sólido para la adopción vendrá de cargas de trabajo cuyo comportamiento de recuperación se haya medido bajo una contención realista. Esa evidencia conecta la flexibilidad de programación con resultados útiles, en lugar de asumir que avanzan conjuntamente.
Kueue ofrece una comparación para la infraestructura de entrenamiento compartida
AWS integra un problema conocido de compartición de recursos en el entrenamiento gestionado, mientras que los usuarios de Kubernetes tienen otra vía mediante Kueue.
Kueue, un sistema de puesta en cola de cargas de trabajo nativo de Kubernetes, documenta el préstamo y la preempción entre colas relacionadas. Sus políticas de preempción distinguen la interrupción dentro de una cola de la recuperación que involucra otras colas. También ofrece distintos enfoques para compartir el acceso a recursos prestables.
Esta comparación sitúa la funcionalidad de AWS en contexto. El acceso condicional a asignaciones no utilizadas es un enfoque de programación establecido. El desarrollo de AWS incorpora ese enfoque al flujo de trabajo de los equipos que utilizan SageMaker Training.
Por tanto, la comparación relevante es operativa. Un equipo ya comprometido con el entrenamiento gestionado evalúa qué tan bien Batch expresa sus acuerdos de asignación. Un equipo que ejecuta Kubernetes evalúa esos acuerdos junto con sus controladores de cargas de trabajo existentes y sus responsabilidades de plataforma.
La documentación de ninguno de los productos establece un ganador universal. La evidencia disponible respalda comparar la adecuación de las políticas y las responsabilidades operativas, en lugar de afirmar que un sistema siempre logra una mejor utilización.
Esto importa porque las organizaciones pueden plantear las decisiones de programación de forma demasiado limitada. El préstamo resulta atractivo, pero el planificador es solo una parte de un entorno de entrenamiento. Las herramientas de ejecución, las prácticas de recuperación, los controles de acceso y la responsabilidad del soporte también influyen en el resultado.
Para los usuarios de SageMaker, integrar la asignación de recursos en la ruta de entrenamiento existente puede reducir el número de sistemas separados que los administradores deben coordinar. Que ese beneficio justifique la adopción depende del flujo de trabajo actual de la organización.
Para los usuarios de Kubernetes, introducir una ruta de entrenamiento gestionada independiente únicamente para compartir cuotas requiere una evaluación más amplia. Una comparación de funcionalidades por sí sola no puede captar las consecuencias de cambiar los entornos de ejecución.
La cuestión común sigue siendo la misma: la capacidad asignada debe seguir siendo útil cuando su propietario está inactivo, mientras que el propietario conserva una ruta de recuperación creíble. Ambos enfoques exigen que los equipos decidan qué permite el acceso temporal.
Esto también explica por qué una separación rígida sigue siendo una comparación legítima. Una organización puede aceptar racionalmente recursos inactivos cuando el riesgo de interrupción conlleva consecuencias mayores. La utilización es un objetivo entre varios.
Por el contrario, una organización con experimentos flexibles puede priorizar racionalmente el progreso oportunista. Sus cargas de trabajo y compromisos de entrega respaldan un equilibrio diferente. La política de programación debe expresar ese equilibrio en lugar de imponer un objetivo abstracto de utilización.
La compartición de capacidad de GPU resulta más convincente cuando sustituye una carga de coordinación existente por una política que la gente entiende. Es menos convincente cuando la organización no puede explicar qué trabajo debe ceder o recuperarse.
Por lo tanto, la presión competitiva recae en parte sobre las prácticas internas de plataforma. Los equipos que mantienen procesos manuales de asignación ahora tienen una opción gestionada que evaluar. Necesitan evidencia de que su enfoque actual proporciona beneficios que justifican su coste de coordinación.
La funcionalidad de AWS no elimina la necesidad de esas comparaciones. Ofrece a los usuarios de SageMaker otra forma de implementar el acuerdo entre derecho de uso y acceso temporal.
Vigile el tiempo de finalización, el comportamiento de recuperación y la estabilidad de las políticas
La evidencia más útil conectará la compartición de recursos con el trabajo completado y un acceso predecible para los equipos que asignan capacidad.
La primera señal que debe vigilarse es el tiempo de finalización bajo una contención realista. Una evaluación significativa debe comparar cuándo termina el trabajo, incluido lo que ocurre cuando regresan los equipos que prestan capacidad. Una mayor ocupación por sí sola proporcionaría evidencia incompleta.
Si el préstamo acelera el trabajo flexible y preserva un acceso aceptable para los equipos que asignan capacidad, el argumento para la adopción se fortalece. Si los retrasos por interrupción compensan las ganancias, los administradores tienen motivos para restringir qué cargas de trabajo pueden tomar prestado.
La segunda señal es el comportamiento de recuperación en aplicaciones representativas. Una continuación correcta tras una interrupción respaldaría un uso más amplio del préstamo. Reinicios repetidos, continuación no válida o cómputo repetido extenso debilitarían ese argumento.
Esta evidencia necesita contexto de aplicación. Una demostración satisfactoria con un script de entrenamiento no puede establecer que todos los flujos de trabajo de modelos se comporten igual. Los equipos deben registrar los supuestos de recuperación asociados a cada clasificación de carga de trabajo.
La tercera señal es la estabilidad de las políticas después de que los usuarios comiencen a depender del acceso compartido. Los administradores deben observar si las reglas de asignación siguen siendo comprensibles o generan excepciones frecuentes, cambios de prioridad y disputas.
Las políticas estables sugerirían que la organización ha traducido sus prioridades en reglas de programación utilizables. Las anulaciones persistentes sugerirían un desajuste entre las participaciones configuradas y los compromisos reales.
Durante los próximos meses, esas señales importan más que el número de equipos que habilitan la funcionalidad. La adopción demuestra interés. El comportamiento de finalización, la calidad de la recuperación y una gobernanza manejable demuestran si el acuerdo funciona.
La guía de octubre ofrece a los equipos de plataforma un punto de partida concreto para esa evaluación. Separa las cargas de trabajo según su tolerancia a la interrupción y muestra cómo la recuperación cambia la ejecución. El siguiente paso corresponde a la evidencia de las propias cargas de trabajo de la organización.
Para los líderes de ingeniería, la decisión debe conectar el comportamiento de la infraestructura con las promesas de entrega. Un entorno de entrenamiento puede admitir más trabajo oportunista sin hacer que todos los plazos de finalización sean igual de predecibles.
Para los investigadores, la implicación inmediata es que el acceso anticipado puede venir con continuidad condicional. Los planes de experimentación deben reflejar la diferencia entre recursos asignados y recursos prestados.
Comience con una carga de trabajo representativa cuyo comportamiento ante interrupciones entienda su equipo. Registre su tiempo de finalización, los resultados de recuperación y el efecto de que un equipo asignador recupere capacidad. Compare esos resultados con su acuerdo actual antes de ampliar el acceso. Mantenga el acuerdo de asignación junto a los resultados para que los revisores puedan evaluar si la política cumplió su propósito previsto. La gestión de cuotas de AWS Batch ofrece una forma concreta de automatizar el préstamo y la recuperación, pero la evidencia de sus cargas de trabajo debe determinar dónde encaja. ¿Qué experimentos pueden aceptar acceso temporal y cuáles necesitan una ventana de ejecución más predecible?
