Lambda prepara el programador de Run:ai de código abierto para Kubernetes Service

Lambda anunció el 13 de octubre de 2026 que está trabajando con NVIDIA para ofrecer el programador de GPU Run:ai, cuyo código se ha abierto, como opción administrada de primer nivel en Lambda Kubernetes Service (LKS), dentro de una biblioteca planificada de programadores que se ofrecerán como componentes administrados.

El plan se presentó en una publicación del blog de Lambda del 13 de octubre de 2026. «Celebramos la decisión de NVIDIA de publicar Run:ai como código abierto y estamos trabajando para convertirlo en una opción de primer nivel en Lambda Kubernetes Service (LKS)», declaró la empresa. Lambda dijo que ofrece compatibilidad con Run:ai en su infraestructura desde 2022 y describió su objetivo como facilitar la adopción y el funcionamiento de las capacidades de Run:ai a través de LKS, para que los equipos tengan más control sobre la asignación y el uso compartido de la capacidad de GPU.

NVIDIA publicó el programador como código abierto en 2025

NVIDIA anunció el lanzamiento de KAI Scheduler como código abierto, con licencia Apache 2.0, el 1 de abril de 2025. Se trata de una solución de programación de GPU nativa de Kubernetes, desarrollada originalmente dentro de la plataforma Run:ai, según el anuncio de NVIDIA. NVIDIA señaló que el programador sigue ofreciéndose como parte de la plataforma NVIDIA Run:ai.

Según NVIDIA, el programador recalcula continuamente los valores de reparto equitativo y ajusta las cuotas y los límites en tiempo real. Para ello, combina la programación en bloque, el uso compartido de GPU y la gestión de colas jerárquicas, mientras que un componente integrado, podgrouper, vincula automáticamente las cargas de trabajo con marcos como Kubeflow, Ray, Argo y Training Operator. NVIDIA describe un ciclo de programación que captura una instantánea del clúster de Kubernetes, calcula una cuota justa para cada cola en las fases de cuota correspondiente y recursos por encima de la cuota, y luego aplica acciones de asignación, consolidación, recuperación y desalojo para ajustar las asignaciones actuales al estado calculado.

Uso compartido de GPU y programación por cuotas en Run:ai

Lambda describió las distintas demandas que el desarrollo de IA plantea a las GPU: las sesiones de depuración pueden necesitar solo una parte de una GPU; las evaluaciones pueden distribuirse entre muchos trabajos independientes; y el entrenamiento distribuido puede requerir, al mismo tiempo, un gran número de GPU estrechamente interconectadas. Además, las necesidades cambian a medida que el trabajo pasa de las primeras ideas a los experimentos y, finalmente, a producción. Cuando los trabajos pequeños reciben GPU enteras, los investigadores tienen que esperar mientras la capacidad reservada queda sin utilizar, y los equipos pueden ver cómo sus experimentos quedan bloqueados detrás de las GPU reservadas, pero inactivas, de otro grupo.

Según la descripción de Lambda, Run:ai es un programador de GPU para Kubernetes que va más allá del programador predeterminado de Kubernetes de dos maneras: permite compartir GPU, de modo que más de una carga de trabajo pueda ejecutarse en una misma GPU, y ofrece programación basada en cuotas, que garantiza una asignación a cada equipo y, al mismo tiempo, permite que los equipos tomen prestada la capacidad inactiva de los demás.

La documentación de NVIDIA sobre las fracciones de GPU indica que las fracciones dividen la memoria de la GPU en segmentos más pequeños que pueden compartir varias cargas de trabajo. El tamaño de memoria solicitado por cada carga de trabajo se hace cumplir para que no supere lo solicitado ni invada la memoria de otra carga de trabajo. Cada pod recibe su propio espacio de direcciones de memoria virtual, una configuración que la documentación denomina «GPU lógica».

Según la documentación, las fracciones utilizan de forma predeterminada la división temporal de NVIDIA para compartir la capacidad de cómputo de la GPU. Las fracciones multigPU asignan el mismo tamaño de fracción en varias GPU de un mismo nodo: por ejemplo, a un modelo que utiliza 8 GPU y necesita 40 GB de memoria por GPU se le pueden asignar 8×40 GB, en lugar de toda la memoria de cada GPU, con lo que quedan 40 GB disponibles en cada GPU para otras cargas de trabajo de ese nodo. La documentación señala que las fracciones de GPU y el modo Multi-Instance GPU (MIG) no pueden utilizarse en el mismo nodo.

La documentación de NVIDIA sobre los conceptos del programador indica que cada pod recién creado se asigna a un grupo de pods y que la programación en bloque significa que una carga de trabajo compuesta por varios pods se programa por completo o queda totalmente pendiente. Se crea una cola de programación para cada proyecto y departamento en cada conjunto de nodos; las cuotas que corresponden a cada uno limitan las cargas de trabajo no desalojables que pueden ejecutarse, mientras que los recursos por encima de la cuota solo están disponibles para cargas de trabajo desalojables. El programador calcula un valor de reparto equitativo para cada proyecto y departamento en cada conjunto de nodos. Cuando una cola está por debajo de su cuota justa y otra la supera, el programador desplaza recursos entre las colas para reequilibrarlas, un proceso que puede desalojar cargas de trabajo desalojables que excedan su cuota. También puede recuperar recursos entre proyectos y departamentos, y los administradores pueden establecer estrategias de colocación de empaquetado compacto o distribución para cada conjunto de nodos.

Corrección automática de nodos en LKS

Lambda señaló que tanto el uso compartido como el desalojo presuponen que la GPU subyacente funciona correctamente, algo que no está garantizado a gran escala: los aceleradores presentan errores XID, los enlaces NVLink y PCIe se degradan, las filas de memoria se reasignan y los puertos InfiniBand funcionan por debajo de la velocidad prevista. Un programador no puede distinguir una GPU en buen estado de una que está fallando, por lo que sigue enviando trabajos a un nodo que los pierde.

Lambda dijo que la corrección automática ya está disponible en LKS. La empresa señaló que supervisa todos los nodos para detectar este tipo de fallos y muestra cada uno como una condición estándar de nodo de Kubernetes. Cuando se activa una condición, se aísla el nodo para impedir que reciba nuevos trabajos, se evacúan los trabajos en ejecución y el fallo se corrige automáticamente o se deriva para su reparación de hardware. El nodo solo vuelve a estar en servicio después de superar una nueva validación.

La documentación de Kubernetes administrado de Lambda describe el servicio como un entorno de Kubernetes compatible con GPU e InfiniBand (RDMA), y con almacenamiento persistente compartido entre todos los nodos de un clúster 1-Click. NVIDIA GPU Operator y NVIDIA Network Operator vienen preinstalados, y el servicio realiza una validación continua para comprobar que las GPU, la red y el almacenamiento funcionan correctamente, además de corregir automáticamente los problemas de los nodos para detectar y resolver fallos de hardware.

La hoja de ruta de la biblioteca de planificadores administrados

Lambda describió la programación de GPU como la capa que deliberadamente deja abierta y afirmó que el siguiente paso de LKS será avanzar hacia lo que denomina una biblioteca de software de IA: planificadores que se ejecutan en Kubernetes, entre ellos Slurm y Run:ai, distribuidos como componentes administrados que Lambda valida con su propio hardware y mantiene actualizados, en lugar de que los clientes los ensamblen manualmente a partir de gráficos Helm. Run:ai es un objetivo prioritario de esa biblioteca, y Lambda afirmó que está trabajando con NVIDIA para lograrlo.

Según Lambda, el lanzamiento de código abierto es lo que hace posible este enfoque: la empresa puede integrar, probar y mantener Run:ai dentro de LKS, en vez de entregar a los clientes un conjunto de instrucciones de integración. Lambda afirmó que aspira a ofrecer una integración lista para usar, en la que se encargue de la integración, la validación y las operaciones continuas.

Lambda, que también produce investigaciones abiertas, afirmó que valora poder inspeccionar, adaptar y mejorar las herramientas de las que depende, y describió la decisión de NVIDIA como una ampliación de esa libertad al ámbito de la orquestación.