Una «fábrica de inteligencia artificial» no consiste en un único modelo ni en un clúster de Kubernetes independiente, sino en una flota compartida de unidades de procesamiento gráfico GPU utilizada simultáneamente por equipos para distintos fines: ajuste fino, ejecución de inferencias y evaluación. Un artículo publicado en el blog de la CNCF sostiene que el verdadero desafío empresarial ya no es solo entrenar el modelo, sino conceder a cada equipo un acceso seguro y aislado al mismo hardware, manteniendo al mismo tiempo un uso elevado de las unidades GPU y unos costes medibles.
El material fue escrito por Hrittik Roy, en su calidad de CNCF Ambassador y Platform Advocate en vCluster, y ofrece una lectura práctica de cómo construir este entorno sobre Kubernetes. La idea central del artículo es que Kubernetes proporciona una base madura para contenedores, RBAC, escalado automático y políticas, pero necesita un ecosistema adicional para gestionar aceleradores y el aislamiento entre inquilinos en los mismos nodos.
El cuello de botella es la utilización, no solo la velocidad de inferencia
Las unidades GPU representan el mayor gasto de capital en una infraestructura de inteligencia artificial, por lo que el porcentaje de utilización se convierte en un indicador económico más importante que registrar una velocidad máxima en una única ejecución. El artículo presenta dos problemas principales: el modelo de asignación de recursos y el modelo de aislamiento.
En el modelo tradicional de device plugin, la carga solicita, por ejemplo, nvidia.com/gpu: 1 y reserva una unidad completa aunque solo utilice el diez por ciento de ella. En cambio, Dynamic Resource Allocation o DRA, disponible de forma general en Kubernetes 1.34, permite que el planificador trate los aceleradores como dispositivos con propiedades, memoria y topología. Sin embargo, no divide una unidad GPU en cuotas automáticamente; la densidad procede de la capa del dispositivo, como HAMi, un proyecto en fase Incubating dentro de la CNCF que impone límites de memoria y cómputo a nivel del contenedor y admite varios proveedores de aceleradores.
Por otro lado, asignar hardware separado a cada equipo puede proporcionar un aislamiento sólido, pero deja sin utilizar una gran parte de la capacidad. Por eso, el artículo distingue entre asignar una unidad completa cuando los límites de confianza son estrictos y dividir la unidad dentro de un mismo dominio de confianza para aumentar la densidad. NVIDIA MIG ofrece aislamiento de memoria y de fallos a nivel de hardware, pero el artículo señala que su uso como separación entre inquilinos hostiles sigue siendo objeto de debate; por ello, asignar una GPU completa continúa siendo la opción conservadora en situaciones de baja confianza.
Las capas de la fábrica, desde el metal hasta la carga
El sistema comienza con el aprovisionamiento del hardware en bruto. Se descubren los nodos y se inspeccionan las unidades GPU, el estado de la memoria ECC y las identidades de las tarjetas de red; después se instala la imagen del sistema operativo, que incluye el controlador de GPU y las bibliotecas CUDA y NCCL. A continuación se aplican los ajustes adecuados de BIOS y los nodos se someten a pruebas de estrés y pruebas de NCCL para comprobar que las unidades GPU se comunican con el ancho de banda completo, antes de registrar el resultado en una fuente de verdad como NetBox. Este ciclo puede construirse mediante un gestor de hardware específico del proveedor o utilizando herramientas abiertas como Metal3 con Ironic o vMetal.
Tras la asignación, herramientas como KAI Scheduler y Volcano se encargan de la planificación por lotes y consciente de la topología, mientras que Kueue gestiona la espera, la admisión y las cuotas. En la capa de cargas, vLLM puede utilizarse para motores de inferencia y KServe para proporcionar puntos finales estándar y escalado automático, además de NVIDIA Dynamo y llm-d para inferencia desacoplada en entornos más grandes. Gateway API proporciona el enrutamiento, mientras que LiteLLM añade una puerta de enlace compatible con la API de OpenAI.
La plataforma no se limita a los contenedores. El artículo explica que los entornos de entrenamiento pueden utilizar Slurm mediante Slinky de SchedMD, que representa los servicios de Slurm como recursos personalizados y los integra con GPU Operator y DRA. KubeVirt también puede ejecutar máquinas virtuales como cargas de Kubernetes, de modo que las máquinas virtuales y los contenedores se gestionen desde la misma flota y con permisos y cuotas unificados.
El aislamiento no consiste únicamente en espacios de nombres
El artículo divide el problema del aislamiento en dos niveles. En el nivel de control, el patrón tenant cluster proporciona a cada equipo una interfaz virtual de Kubernetes que incluye un servidor de API, recursos dedicados y reglas de admisión y RBAC independientes, ejecutándose como una carga sobre un único clúster base. vCluster ofrece un ejemplo de ello, con la posibilidad de utilizar herramientas conocidas como kubectl, Helm y Argo CD sin extensiones propietarias.
El nivel de datos requiere aislar las redes, el almacenamiento, las cuotas y el entorno de ejecución. Cilium puede utilizarse para la CNI y las políticas, y Multus y SR-IOV para la ruta rápida, junto con InfiniBand o RoCEv2 para transportar el tráfico de GPU entre los nodos. También se utilizan VPC separadas mediante VXLAN y EVPN, o particiones en InfiniBand, mientras que unidades DPU como NVIDIA BlueField o AMD Pensando trasladan algunas funciones de aislamiento y cifrado fuera del procesador anfitrión. El artículo destaca que el verdadero criterio de una nube es el aislamiento impuesto por hardware cuando sea necesario, no la dependencia exclusiva de los namespaces.
¿Qué convierte la flota en un servicio en la nube?
Lectura editorial: el valor práctico de este planteamiento es que traslada el debate de «¿qué modelo es más rápido?» a la cuestión de operar la propia infraestructura. La plataforma no se convierte en un servicio en la nube por el mero hecho de reunir unidades GPU; lo hace cuando el inquilino puede crear y eliminar clústeres mediante una API, Terraform o GitOps, y cuando los recursos se definen de forma declarativa y son gestionados por Flux o Argo CD, con identidad OIDC y permisos RBAC.
El servicio también necesita medición y facturación comprensibles. El artículo propone utilizar datos de DCGM para calcular segundos de GPU y distribuirlos entre los inquilinos mediante OpenCost. La supervisión y la fiabilidad también forman parte del producto, no son un complemento operativo: DCGM supervisa la degradación y Node Problem Detector convierte las señales de fallo en estados de los nodos, mientras que el ciclo de procesamiento aísla el nodo sospechoso y lo drena antes de programar nuevas cargas. La capa de seguridad incluye herramientas como Keycloak mediante OIDC, OpenBao con External Secrets Operator, Kyverno u OPA para los controles, y Falco y Trivy para la seguridad de ejecución y de la cadena de suministro.
La prueba más difícil sigue siendo pasar de una demostración a una producción a gran escala. El ejemplo que ejecuta dos equipos y dos modelos en una única GPU dividida no demuestra por sí solo la validez del diseño con cientos de nodos y varios centros de datos. El artículo señala el papel de herramientas de validación como NVIDIA AI Cluster Runtime y el programa Kubernetes AI Conformance, presentado con la versión 1.35, pero deja abiertas cuestiones operativas sobre el radio de explosión, los límites del aislamiento entre inquilinos y la elección entre el paquete NVIDIA DSX OS y la combinación de capas de código abierto.
La conclusión es que el éxito de una «fábrica de inteligencia artificial» depende de combinar densidad, aislamiento y facturación teniendo en cuenta la topología del hardware: la ubicación de las unidades GPU respecto de NVLink o NVSwitch, su conexión a una red InfiniBand o RoCE, y las posiciones de GPU, NIC y CPU en los nodos NUMA. Programar la carga sin estos datos puede ralentizar las operaciones de comunicación colectiva en el enlace más lento, aunque la plataforma parezca estar en buen estado desde el punto de vista del software.