NVIDIA Run:ai v2.24 presenta time-based fairshare, un nuevo modo de programación que introduce un enfoque de equidad temporal para la asignación de recursos en clústeres de Kubernetes. Esta función, basada en el KAI Scheduler, aborda un desafío persistente en la infraestructura compartida de GPU.
Imagina dos equipos con igual prioridad compartiendo un clúster. El equipo A envía continuamente trabajos pequeños, mientras que el equipo B necesita ejecutar un trabajo más grande que requiere más recursos. Cada vez que se liberan recursos, los trabajos más pequeños del equipo A se programan inmediatamente, dejando al trabajo más grande del equipo B esperando indefinidamente. Esto ocurre a pesar de que ambos equipos tienen la misma prioridad y derechos de uso.
Time-based fairshare resuelve este problema al dotar al programador de memoria. En lugar de calcular la equidad en un instante, el programador rastrea el uso histórico de recursos y ajusta la parte de cada cola según el consumo pasado. Los equipos que han utilizado más recursos recientemente reciben puntuaciones más bajas para la asignación de recursos excedentes, mientras que aquellos que han estado esperando reciben un impulso.
Importancia de la equidad en recursos GPU
Las implementaciones empresariales han demostrado que al pasar de la asignación estática de GPU a la programación dinámica, el uso del clúster se vuelve mucho más dinámico. Los recursos excedentes se convierten en uno de los tipos de recursos más utilizados. Esto hace que la equidad en el uso de recursos excedentes sea crítica, ya que una parte significativa del valor del clúster proviene de esta reserva compartida.
Por lo tanto, es necesario dividir esta reserva de manera justa a lo largo del tiempo.
Funcionamiento de la programación equitativa sin estado
Los algoritmos clásicos de programación equitativa sin estado dividen los recursos del clúster en dos fases. Primero, se asigna la Cuota Merecida, que son los recursos garantizados a los que cada cola tiene derecho. Esta asignación siempre ocurre primero y no se ve afectada por el uso histórico. Time-based fairshare no cambia este comportamiento.
Después de satisfacer las cuotas merecidas, cualquier capacidad restante se convierte en el Grupo de Recursos Excedentes, un excedente compartido por el que las colas compiten según sus pesos. Aquí es donde la equidad puntual se descompone.
Al dividir los recursos excedentes, el programador agrupa las colas por nivel de prioridad y comienza con la más alta, calculando la parte equitativa según los pesos en ese nivel. Las colas que utilizan menos de su parte equitativa obtienen recursos primero, rompiendo empates con el tiempo de envío de trabajo.
Funcionamiento de time-based fairshare
La idea central de time-based fairshare es sencilla: para cada cola, se compara la proporción de recursos excedentes que realmente consumió durante el período de tiempo configurado con la proporción que debería haber recibido según su peso. Luego, se ajusta en consecuencia.
Por ejemplo, si la Cola A tiene un peso de 3 y la Cola B un peso de 1, la Cola A debería recibir el 75% de los recursos excedentes y la Cola B el 25%. Si el programador revisa el uso histórico y observa que la Cola A consumió el 90% mientras que la Cola B solo el 10%, aumentará el peso efectivo de la Cola B y reducirá el de la Cola A, equilibrando futuras asignaciones.
Cálculo de time-based fairshare
El programador utiliza tres entradas para ajustar el peso efectivo de cada cola:
- Peso: Lo que debería recibir la cola según su peso configurado en relación con otras.
- Uso: Lo que la cola realmente consumió durante un período de tiempo configurable.
- Valor K: Qué tan agresivamente corrige el programador los desequilibrios.
Cuando una cola ha consumido más de su parte equitativa, su peso efectivo se reduce. Cuando ha sido desatendida, su peso efectivo se incrementa, haciendo que las asignaciones tiendan naturalmente hacia las proporciones deseadas a lo largo del tiempo.
Time-based fairshare se puede habilitar o deshabilitar directamente desde la interfaz de usuario, mientras que parámetros como el tamaño de la ventana, tipo de ventana y tasas de decadencia se pueden ajustar a través de la API. Esto permite a los administradores experimentar en un grupo de nodos dedicado sin afectar el resto del clúster.
