Aplica límites de memoria GPU en Kubernetes con CUDA 13.4 y KAI Scheduler

NVIDIA ha lanzado CUDA 13.4, que introduce la aplicación transparente de límites de memoria para cargas de trabajo de GPU. Para operacionalizar esto en Kubernetes, el GPU Fractioning Operator de código abierto ahora funciona con KAI Scheduler v0.18.0 para gestionar recursos de GPU fraccionados. Esta combinación permite a los equipos de plataforma compartir GPUs de manera más eficiente manteniendo un aislamiento estricto de la memoria.

Qué ha ocurrido

Muchas cargas de trabajo de inferencia y desarrollo de IA no requieren una GPU completa. Asignar dispositivos completos a trabajos pequeños conduce a una capacidad ociosa significativa. Aunque las GPUs de NVIDIA han admitido durante mucho tiempo el uso compartido mediante Multi-instance GPU (MIG), time-slicing o Multi-Process Service (MPS), los métodos anteriores carecían de una aplicación robusta de límites de memoria en modos compartidos. El time-slicing permitía a los procesos turnarse, pero no impedía que uno consumiera toda la memoria disponible. MPS permitía la ejecución concurrente, pero dependía de la disciplina a nivel de aplicación para el uso de memoria.

CUDA 13.4 aborda esta brecha aplicando límites de memoria de forma transparente a nivel de driver. Las aplicaciones solo ven su fracción asignada de memoria, y las asignaciones que superan este límite fallan inmediatamente. Para cerrar la brecha entre esta capacidad de bajo nivel y la orquestación de Kubernetes, NVIDIA introdujo el GPU Fractioning Operator. Alojado bajo la organización KAI Scheduler en GitHub, este operador se ejecuta junto al NVIDIA GPU Operator. Gestiona la configuración de MPS en cada nodo, aplica límites de memoria por carga de trabajo e informa del uso por fracción en lugar de por GPU completa.

KAI Scheduler v0.18.0 se integra directamente con este operador a través de un nuevo modo de uso compartido de GPU llamado NvFractions. El planificador selecciona las GPUs adecuadas basándose en la memoria disponible y escribe anotaciones específicas en las especificaciones de Pod. El GPU Fractioning Operator lee estas anotaciones y configura el nodo para aplicar los límites de memoria y los modos de cálculo solicitados antes de que inicie el contenedor. Esta separación de responsabilidades garantiza que las decisiones de planificación permanezcan distintas de la aplicación a nivel de nodo.

Cómo funciona

El sistema depende de dos modos de cálculo para compartir recursos de GPU: time-slicing y sm-sharing. En time-slicing, las cargas de trabajo se turnan para usar la GPU completa. Si una carga de trabajo está inactiva, su franja temporal se redistribuye a otras. Este modo proporciona un aislamiento completo de errores, lo que significa que una caída en una carga de trabajo no afecta a las demás. En sm-sharing, los multiprocesadores de streaming (SM) de la GPU se dividen entre cargas de trabajo concurrentes. Todas las cargas de trabajo activas se ejecutan simultáneamente y los SM no utilizados se reasignan dinámicamente. Sin embargo, sm-sharing coloca las cargas de trabajo en un único dominio de error, por lo que una falla en una puede afectar a las demás.

CUDA 13.4 aplica límites de memoria independientemente del modo de cálculo. Una carga de trabajo puede solicitar una cantidad exacta de memoria o un rango compuesto por un mínimo garantizado y un máximo explosivo (burstable). Si una carga de trabajo intenta asignar memoria más allá de su límite, la asignación falla tal como lo haría en una GPU física más pequeña. Esta aplicación es transparente para la aplicación y no requiere cambios en el código. El GPU Fractioning Operator garantiza que estos límites se apliquen configurando los demonios MPS subyacentes y monitorizando el uso por fracción.

Los planificadores comunican los requisitos al operador utilizando anotaciones estándar de Pod de Kubernetes. Estas anotaciones especifican la solicitud de memoria garantizada, el límite opcional de ráfaga, el modo de cálculo deseado y los dispositivos GPU específicos asignados. El operador analiza estos campos y los traduce en configuraciones a nivel de nodo. Este mecanismo permite que cualquier planificador de Kubernetes capaz de escribir estas anotaciones aproveche la aplicación de memoria de CUDA, aunque KAI Scheduler es el primero en ofrecer integración nativa.

Detalles clave

• CUDA 13.4 introduce la aplicación transparente de límites de memoria, permitiendo cantidades exactas de memoria o rangos explosivos para cargas de trabajo de GPU compartidas.
• El GPU Fractioning Operator es una herramienta de código abierto que configura MPS, aplica límites de memoria y mide el uso por fracción de GPU.
• KAI Scheduler v0.18.0 incluye un modo NvFractions que escribe las anotaciones de Pod necesarias para que el operador las aplique.
• Las cargas de trabajo pueden elegir entre time-slicing (ejecución serial con aislamiento de errores) y sm-sharing (ejecución paralela con asignación dinámica de SM).
• Las solicitudes de memoria pueden definirse como tamaños absolutos (p. ej., "40Gi") o como porciones de una GPU (p. ej., "0.5").
• Los administradores habilitan la integración durante la instalación de KAI Scheduler utilizando una bandera de Helm, que instala el GPU Fractioning Operator como dependencia.

Por qué importa

Para los equipos de ingeniería que construyen infraestructura de ML, esta actualización mejora significativamente la utilización de recursos sin sacrificar la estabilidad. Anteriormente, compartir GPUs solía implicar elegir entre un aislamiento deficiente (MPS) o una partición rígida (MIG). Con CUDA 13.4 y el GPU Fractioning Operator, los equipos pueden agrupar más cargas de trabajo en hardware existente garantizando que ningún trabajo individual pueda privar a otros de memoria. Esto es particularmente valioso para servicios de inferencia y entornos de desarrollo donde las cargas de trabajo varían en tamaño e intensidad.

La capacidad de definir límites de memoria explosivos añade flexibilidad para trabajos por lotes o tareas de entrenamiento que ocasionalmente pueden necesitar más recursos. Si hay memoria libre, una carga de trabajo puede expandirse hacia ella; si no, permanece dentro de su mínimo garantizado. Esta asignación dinámica reduce la necesidad de sobreaprovisionamiento. Además, la clara distinción entre time-slicing y sm-sharing permite a los arquitectos ajustar el modo de uso compartido a los requisitos de tolerancia a fallos de la carga de trabajo. Los servicios críticos de producción pueden usar time-slicing para aislamiento, mientras que los trabajos por lotes resilientes pueden usar sm-sharing para mayor rendimiento.

Qué puedes hacer

• Instala KAI Scheduler v0.18.0 o posterior con la bandera de Helm global.nvFractions.set=true para habilitar el soporte de fraccionamiento de GPU.
• Revisa el repositorio del GPU Fractioning Operator en GitHub para guías de instalación y detalles de configuración.
• Actualiza las especificaciones de Pod para incluir anotaciones para solicitudes de memoria, límites y modos de cálculo al desplegar cargas de trabajo fraccionadas.
• Elige time-slicing para cargas de trabajo que requieran aislamiento de errores y sm-sharing para aquellas que necesiten ejecución paralela y uso dinámico de SM.
• Monitoriza el uso de GPU por fracción utilizando las métricas proporcionadas por el GPU Fractioning Operator para optimizar la asignación de recursos.
• Únete al canal de Slack de KAI Scheduler o a las reuniones comunitarias quincenales para hacer preguntas y contribuir al proyecto.