Montamos Kubernetes para compartir tus GPU entre equipos.
Producción, ciencia de datos y entrenamiento trabajan en el mismo clúster, en tus servidores, y las cargas que no pueden molestarse entre sí van separadas por hardware.
Con una GPU por equipo, unas van a tope y otras se quedan paradas.
La de producción no da abasto, la de los científicos de datos pasa la tarde con un cuaderno abierto sin calcular nada y el entrenamiento que llega el jueves no tiene dónde ir.
Comprar otra tarjeta quita la cola durante un tiempo, pero las que ya hay siguen medio paradas y la siguiente compra llega antes de lo previsto.
Formas de repartir una GPU
En un mismo clúster se suelen combinar. Cuál toca en cada caso depende de si las cargas pueden molestarse entre sí y de cuánta memoria necesita cada una.
Por turnos
Varios procesos usan la tarjeta entera y se turnan para calcular. Funciona en casi cualquier GPU de NVIDIA, pero la memoria es común y no hay aislamiento: si un proceso se queda con ella o falla la tarjeta, caen todos. Sirve para cuadernos y pruebas, que pasan mucho rato sin calcular.
En trozos, con MIG
La tarjeta se divide por hardware en GPU más pequeñas, cada una con su memoria y sus núcleos, de modo que un fallo en una no toca a las demás. Es lo indicado para servir varios modelos pequeños en producción.
Enteras, en cola
Cada trabajo recibe GPU completas y espera turno en la cola de su equipo. Así encajan los entrenamientos y los ajustes de modelos, que pueden ir de noche sin quitar sitio a producción.
- Producción
- Datos
- Pruebas y entrenamiento
Ejemplo: un servidor con cuatro GPU
Tres equipos comparten las cuatro tarjetas a lo largo de un día.
El modelo de producción, servido con vLLM, tiene la GPU 1 entera desde el arranque.
enteraTres modelos pequeños (embeddings, un clasificador y voz a texto) comparten la GPU 2, partida en trozos MIG.
MIGCinco cuadernos de ciencia de datos se turnan la GPU 3.
por turnosLlega un ajuste de modelo que pide dos GPU. Solo hay una libre, así que espera en la cola de su equipo.
en colaLos cuadernos se cierran y el ajuste toma prestada la GPU 3 junto con la 4.
prestadaEl ajuste termina y la GPU 3 vuelve a datos antes de que llegue nadie.
devuelta
Cómo lo montamos
Controladores con GPU Operator Instala y mantiene los controladores de NVIDIA en cada nodo, configura los trozos MIG y los turnos, y hace que Kubernetes vea las tarjetas. Debajo va Ubuntu o Rocky Linux, con el soporte de Canonical o de CIQ.
Pedir GPU con DRA Con DRA, que Kubernetes trae de serie desde la versión 1.34, y el controlador DRA de NVIDIA, una carga pide «una GPU con al menos 40 GB» y el clúster busca una que cumpla.
Una cola por equipo con Kueue Cada equipo tiene su cuota. Lo que uno no usa lo aprovecha otro, y producción tiene prioridad para recuperar sus tarjetas en cuanto las necesita.
Medir el uso Con el exportador DCGM de NVIDIA, Prometheus y Grafana se ve cuánto usa cada equipo, que es el dato para ajustar las cuotas o decidir si hace falta otra tarjeta.
Servidores y formación
Si todavía no tienes las tarjetas, configuramos servidores Lenovo para IA y servidores Supermicro para IA con las GPU que encajen en el reparto. Y para que tu equipo pueda llevar el clúster, están los cursos de Kubernetes con MicroK8s, de GPU compartida en Kubernetes (2 días) y de vLLM y llm-d en Kubernetes (3 días).
Preguntas frecuentes
¿Qué GPU admiten MIG?
La A100, la A30, la H100, la H200, la B200 y la B300, además de la RTX PRO 6000 Blackwell. La L4 y la L40S no lo admiten; en esas tarjetas se reparte por turnos o por GPU enteras.
¿Hace falta Kubernetes para esto?
Para un equipo y un modelo, no: basta con vLLM en un servidor. Kubernetes compensa cuando varios equipos o varios modelos comparten las mismas máquinas y hay que decidir quién usa qué y cuándo. Inferencia de IA en tus servidores
Ya tenemos las GPU. ¿Por dónde se empieza?
Con los datos de uso de las tarjetas que ya tienes proponemos el reparto, y solo si no da para todo hablamos de ampliar.
¿Cuántas GPU tienes y quién las usa?
Cuéntanos qué tarjetas tienes o vas a comprar y qué equipos las van a usar. Te proponemos cómo repartirlas y qué haría falta montar.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
