Cuándo usar cuotas, reservas, prioridades y preemption de GPU

Las cuotas, reservas, prioridades y la preemption de GPU resuelven cuatro problemas diferentes de planificación. Las cuotas limitan cuánto puede consumir un tenant o proyecto. Las reservas protegen la capacidad para trabajos previstos. Las prioridades deciden qué carga de trabajo debe recibir primero la capacidad escasa. La preemption permite que una carga de trabajo de mayor prioridad reclame recursos de tareas de menor prioridad cuando la política lo autoriza.

El modelo de planificación de origen admite cuotas por tenant, colas de tareas, prioridad, preemption, protección de checkpoints, recuperación de recursos y motivos visibles en la cola. En la práctica, estos controles funcionan mejor combinados, porque ningún mecanismo por sí solo resuelve todos los problemas de capacidad.

¿Qué es una cuota de GPU?

Una cuota de GPU establece el límite de recursos para un tenant, proyecto u otro ámbito de propiedad aprobado. El diseño de planificación de origen describe las cuotas por tenant como una restricción estricta que previene la competencia desordenada por recursos costosos de aceleración.

Según las preguntas frecuentes de origen, las cuotas pueden definirse en varias dimensiones, y el modelo exacto depende de la política de gestión de la organización:

• Cantidad de GPU
• Memoria del acelerador
• CPU y memoria
• Tareas concurrentes
• Horas mensuales de tarjeta aceleradora

Una cuota resulta útil cuando varios equipos comparten un mismo grupo de infraestructura y la plataforma necesita evitar que un solo equipo consuma toda la capacidad disponible. También ayuda al control presupuestario: un proyecto puede estar técnicamente autorizado a ejecutarse en el clúster compartido pero limitado a una cantidad definida de capacidad o de consumo mensual.

¿Cuándo se deben usar las cuotas de GPU?

Utiliza cuotas cuando necesites un límite estricto entre tenants, proyectos o equipos. Las situaciones habituales incluyen múltiples departamentos que comparten un mismo clúster de GPU, tenants externos o internos que requieren límites de recursos aislados y proyectos con presupuestos de capacidad aprobados. También se aplican cuando un equipo de desarrollo no debe consumir capacidad de producción sin autorización previa, o cuando el uso mensual de aceleradores debe mantenerse dentro de un presupuesto aprobado.

Las cuotas también ayudan cuando la demanda es impredecible. Sin un límite, una avalancha de trabajos enviados por un solo proyecto puede saturar la cola y consumir todo el conjunto de recursos. Por esa razón, el modelo de origen sitúa la validación de cuotas antes de la planificación en cola: una tarea primero debe tener permiso para solicitar el recurso, y solo después la prioridad y la política de planificación deciden cuándo lo recibe.

¿Qué es una reserva de GPU?

Una reserva protege la capacidad para una carga de trabajo planificada, un proyecto, un servicio o una ventana temporal determinada. La documentación de origen distingue explícitamente la capacidad reservada de la capacidad libre y desplegable en la planificación, aunque no prescribe un producto o algoritmo de reserva universal. A nivel operativo, una reserva significa que cierta capacidad queda comprometida antes de consumirse activamente.

Supongamos que un proyecto crítico de entrenamiento necesita 32 GPU mañana por la noche, un servicio de inferencia en producción requiere margen garantizado para picos de tráfico, o un programa de validación de hardware necesita una clase específica de acelerador durante una ventana de mantenimiento. En cada caso, la capacidad reservada no debe figurar como libre para otras cargas de trabajo si su uso pusiera en peligro ese compromiso.

Eso hace que una reserva sea diferente de una cuota. Una cuota dice: «Puedes consumir hasta esta cantidad». Una reserva dice: «Esta cantidad queda apartada para este propósito aprobado».

¿Cuándo se deben usar las reservas?

Utiliza reservas cuando el coste de no disponer de capacidad en el momento requerido sea elevado. Tienen sentido para ejecuciones de entrenamiento programadas, inferencia crítica en producción, eventos comerciales previstos, ventanas de migración, evaluación de modelos grandes, validación de hardware y capacidad comprometida con un cliente o tenant.

No reserves capacidad de forma innecesaria, porque las GPU reservadas pero sin usar pueden convertirse en costosa capacidad ociosa. El panel de operaciones debe mostrar la capacidad reservada de forma independiente a la instalada, asignada, libre y desplegable. De ese modo, la protección intencionada sigue siendo visible y nadie clasifica por error cada tarjeta reservada como un desperdicio.

¿Qué es la prioridad de GPU?

La prioridad determina el orden en que las cargas de trabajo que compiten entre sí se evalúan para la asignación de recursos. El modelo de planificación de origen admite colas de tareas con prioridad y hace visibles los motivos de espera en la cola. Un trabajo con mayor prioridad puede adelantarse a otro de menor prioridad cuando ambos esperan el mismo recurso limitado.

La prioridad importa porque las cargas de trabajo difieren en su relevancia para el negocio. La inferencia en producción puede situarse por encima del ajuste fino experimental, una tarea de recuperación orientada al cliente por encima de una prueba de rendimiento en desarrollo, y un trabajo de entrenamiento sujeto a plazos estrictos por encima de un trabajo por lotes en segundo plano.

La prioridad no interrumpe necesariamente el trabajo que ya está en ejecución, y ahí es donde se diferencia de la preemption.

¿Cuándo se debe usar prioridad sin preemption?

Utiliza solo la prioridad cuando el orden de espera sea importante pero la interrupción resulte demasiado arriesgada o costosa. Esto es habitual en tareas de entrenamiento de larga duración.

Supongamos que dos trabajos necesitan la misma clase de acelerador. El Trabajo A ya se está ejecutando cuando llega el Trabajo B con mayor prioridad para el negocio. Si el Trabajo A no puede guardar checkpoints con seguridad, interrumpirlo puede implicar la pérdida de muchas horas de computación. Una política exclusiva de prioridad permite que el Trabajo A termine mientras coloca al Trabajo B por delante de otras tareas en cola, de modo que la organización obtiene una cola orientada al negocio sin pérdidas innecesarias de entrenamiento.

El diseño de planificación de origen señala de forma explícita que la preemption de alta prioridad debe equilibrarse con la protección de las tareas en ejecución, razón por la cual la prioridad y la preemption deben ser controles independientes.

¿Qué es la preemption de GPU?

La preemption permite que el planificador reclame recursos de una carga de trabajo en ejecución para que otra pueda utilizarlos. El modelo de planificación de origen admite preemption de alta prioridad y la vincula con la protección de checkpoints y la recuperación ordenada de tareas. Resulta útil cuando la capacidad es escasa y algunas cargas de trabajo admiten explícitamente ser interrumpidas.

Por ejemplo, una tarea de entrenamiento por lotes de baja prioridad se está ejecutando cuando llega una carga de trabajo de alta prioridad para la recuperación de un incidente. La tarea de menor prioridad admite checkpoints, por lo que la plataforma guarda o utiliza el checkpoint más reciente, detiene la tarea, libera las GPU y las asigna al trabajo de mayor prioridad. Más adelante, la tarea interrumpida puede reanudarse. Por tanto, la preemption depende en gran medida de lo recuperable que sea la carga de trabajo.

¿Cuándo se debe usar la preemption de GPU?

Utiliza la preemption cuando se cumplan tres condiciones. Primero, que la carga de trabajo de mayor prioridad tenga una razón de peso para iniciarse antes. Segundo, que la carga de menor prioridad esté aprobada para su interrupción. Tercero, que el trabajo interrumpido pueda protegerse lo suficiente como para que el coste sea aceptable.

Buenos candidatos incluyen trabajos por lotes interrumpibles, tareas con checkpoints frecuentes, cargas de desarrollo, niveles de servicio inferiores y procesamiento flexible en segundo plano.

El diseño de origen recomienda de forma específica distinguir entre tareas apropiables (preemptibles) y no apropiables. Esa distinción debe formar parte de la política de envío de cargas de trabajo, de modo que nadie tenga que decidirla por primera vez durante un incidente.

¿Cuándo se debe evitar la preemption?

Evita o restringe con rigor la preemption en cargas de trabajo donde la interrupción genere pérdidas desproporcionadas:

• Entrenamiento de larga duración sin un checkpoint válido
• Inferencia crítica en producción sin redundancia
• Cargas de trabajo con estado que no pueden reiniciarse de forma segura
• Trabajos donde la reprogramación altere una condición experimental aprobada
• Tareas con dependencias externas que no puedan reconstruirse

Las preguntas frecuentes de origen advierten que la preemption de alta prioridad puede provocar pérdidas de entrenamiento y recomiendan mecanismos de checkpoint y terminación ordenada. Que un trabajo tenga alta prioridad no significa automáticamente que sea seguro aplicar preemption sobre otros. La prioridad expresa importancia, mientras que la capacidad de interrupción expresa recuperabilidad y política, y un planificador necesita ambas cosas.

¿Cómo funcionan juntas las cuotas y las prioridades?

La cuota decide si la carga de trabajo tiene derecho a solicitar el recurso. La prioridad decide su posición entre las cargas de trabajo que cumplen los requisitos.

Tomemos dos proyectos, cada uno con una cuota de 16 GPU. El Proyecto A ya está utilizando las 16 cuando una nueva tarea del Proyecto A solicita 8 más. El trabajo puede ser rechazado o puesto en cola porque la cuota del proyecto está agotada, y su prioridad no anula la cuota a menos que la organización defina explícitamente esa excepción.

Imaginemos ahora que ambos proyectos están dentro de su cuota y esperando la misma clase de GPU. Aquí la prioridad puede determinar qué trabajo se atiende primero. Mantener esos controles separados hace que la planificación sea comprensible y explicable.

¿Cómo funcionan juntas las reservas y las cuotas?

Las reservas protegen una cantidad conocida de capacidad futura o garantizada, mientras que las cuotas limitan el consumo global, y un proyecto puede tener ambas. Si el Proyecto A tiene una cuota de 64 GPU y una reserva de 32 GPU para esta noche, puede consumir hasta 64 según la política, pero 32 están específicamente protegidas para la ejecución planificada.

Los materiales de origen no definen una regla de interacción universal entre reserva y cuota, por lo que esa relación debe especificarse en la política de planificación corporativa. Sea cual sea la regla, las reservas deben permanecer visibles para que la capacidad supuestamente libre no se comprometa dos veces.

¿Cómo funcionan juntas las reservas y las prioridades?

Una reserva normalmente debe proteger el recurso comprometido con independencia de la prioridad ordinaria de la cola. De lo contrario, no sería una garantía real.

Las empresas pueden definir aun así políticas de anulación por emergencia. Los materiales de origen no prescriben un modelo de anulación cerrado, por lo que el diseño más seguro consiste en hacer que la política sea explícita y auditable. Si se anula un grupo reservado, la plataforma debe registrar quién lo autorizó, qué carga de trabajo utilizó la capacidad, qué reserva se vio afectada y qué riesgo de servicio se asumió. Esto cobra especial importancia cuando la reserva pertenece a otro tenant o al compromiso con un cliente.

¿Cómo cambian los checkpoints la política de preemption?

Los checkpoints reducen el coste de las interrupciones. El planificador de origen incluye protección de checkpoints, aislamiento de fallos y reanudación a partir del punto de control.

Una carga de trabajo con un checkpoint reciente puede liberar sus recursos con menor pérdida de trabajo, lo que la convierte en mejor candidata para la preemption. Una carga de trabajo cuyo último checkpoint tiene seis horas de antigüedad resulta mucho más costosa de interrumpir. Por consiguiente, la política de planificación puede evaluar el estado del checkpoint además de la prioridad estática. El origen no define un algoritmo de puntuación específico; lo que sostiene es el principio de que la protección de las tareas en ejecución y la capacidad de guardar checkpoints deben influir en las decisiones de preemption.

En cuanto a la recuperación ante fallos, cómo la infraestructura de IA puede recuperar automáticamente tareas de entrenamiento tras el fallo de una GPU o de un servidor explica este mismo mecanismo de checkpoints desde el punto de vista de la resiliencia.

¿Cómo deben mostrarse los motivos de espera en cola?

El diseño de origen indica que los motivos de espera en cola deben ser visibles elemento por elemento. Esto es fundamental cuando coinciden al mismo tiempo cuotas, reservas, prioridades y fragmentación. Un trabajo puede estar esperando por cualquiera de estas razones:

• Cuota agotada
• Tipo de GPU coincidente no disponible
• Capacidad reservada no disponible para este proyecto
• Trabajo de mayor prioridad por delante
• Topología requerida no disponible
• Capacidad operativa insuficiente
• La fragmentación de recursos impide la asignación

El usuario debe ver el motivo real. De lo contrario, la misma cola puede parecer un problema de capacidad cuando en realidad es un problema de políticas.

¿Cómo influyen las comprobaciones de estado en estas políticas?

La arquitectura de planificación de origen incluye el estado de salud a nivel de tarjeta como entrada para la asignación de recursos. Por tanto, las cifras de cuotas y reservas deben referirse a recursos utilizables y en buen estado, no únicamente a tarjetas instaladas.

Si un tenant tiene una reserva de ocho GPU y una tarjeta reservada pasa a estar degradada, la plataforma debe identificar el déficit y encontrar capacidad de sustitución adecuada cuando la política lo permita. Una tarjeta degradada no debe seguir siendo planificable solo porque una reserva cuente con ella. Una planificación que tiene en cuenta el estado de salud hace que las garantías sean mucho más realistas.

Para profundizar en el modelo a nivel de tarjeta, cómo las empresas pueden monitorizar el estado de las GPU, los errores ECC, la temperatura, el consumo de energía y las tarjetas aceleradoras degradadas detalla cómo debe afectar el estado de salud a la planificación.

¿Cómo deben elegir las empresas entre los cuatro controles?

Utiliza el control que se ajuste a cada problema: cuota para los derechos de uso y los límites de consumo, reserva para la capacidad garantizada o planificada, prioridad para el orden de espera, y preemption para la interrupción controlada cuando el trabajo urgente deba reclamar capacidad.

No utilices la prioridad como sustituto de la cuota, ni recurras a las reservas para cualquier carga de trabajo. No habilites la preemption sin un plan de recuperación, ni asumas que una cuota amplia garantiza capacidad inmediata.

Un ejemplo de plataforma que combina cuotas por tenant, prioridad, preemption, planificación basada en el estado de salud y recuperación de recursos es Sensaka.

Si tuviera que definir la política de planificación, exigiría que cada carga de trabajo enviada declarase cuatro aspectos: a quién pertenece, qué cuota se le aplica, qué prioridad tiene y si admite preemption con seguridad. Las reservas pueden añadirse después para cargas de trabajo que requieran capacidad garantizada en un momento concreto. Esto crea un modelo de planificación que los usuarios pueden comprender y que operaciones puede auditar.