Compartir GPUs NVIDIA en entornos Kubernetes es una necesidad creciente para optimizar costes y recursos, pero elegir el modelo adecuado puede marcar la diferencia entre un despliegue eficiente y un caos operativo. Existen dos enfoques principales — Multi-Instance GPU (MIG) y time-slicing — y cada uno responde a problemáticas distintas. En este artículo analizamos sus diferencias, cuándo aplicar cada uno y cómo complementarlos con cuotas de recursos, desde una perspectiva técnica y empresarial, con el apoyo de Q2BSTUDIO, empresa especializada en desarrollo de software a medida, inteligencia artificial, ciberseguridad y cloud computing.
El principal reto es que las GPUs son recursos costosos que a menudo se infrautilizan. Kubernetes las trata como recursos extensibles indivisibles: una aplicación pide una GPU, se le asigna completa, y el resto del clúster la considera ocupada aunque el workload solo use una fracción de su capacidad. La solución pasa por compartir la GPU, pero no todas las técnicas son equivalentes. MIG divide físicamente la GPU en instancias hardware independientes, cada una con memoria y cómputo dedicados. Time-slicing, en cambio, anuncia múltiples réplicas lógicas de la misma GPU, pero todas comparten el mismo hardware y compiten por tiempo de ejecución, sin aislamiento de memoria ni rendimiento garantizado.
¿Cuándo usar MIG? Es ideal para entornos multiinquilino donde cada workload necesita límites de recursos predecibles y aislamiento real. Por ejemplo, en plataformas de inferencia con modelos de tamaño conocido, donde una instancia MIG 1g.10GB basta, y otra 2g.20GB se reserva para un modelo mayor. MIG ofrece un particionado hardware que evita el 'vecino ruidoso' y da garantías de rendimiento. Sin embargo, tiene limitaciones: los perfiles disponibles dependen del modelo de GPU (H100, A100, etc.) y no son configurables arbitrariamente. Cambiar la geometría de MIG requiere drenar el nodo, aplicar la nueva configuración y esperar que el MIG Manager la valide. Es una operación disruptiva que debe planificarse como un mantenimiento mayor.
¿Cuándo usar time-slicing? Es adecuado para cargas de trabajo ligeras, bursty, entornos de desarrollo, notebooks o pipelines de CI/CD. Al no crear particiones hardware, se puede anunciar, por ejemplo, 4 o 8 réplicas de una misma GPU física. La ventaja es la flexibilidad: se puede cambiar el número de réplicas sin reiniciar el nodo, solo reiniciando el device plugin. El inconveniente es la falta de aislamiento: un workload puede agotar la memoria GPU de todos, y la latencia es impredecible bajo contención. Para mitigar riesgos, se recomienda renombrar los recursos compartidos (por ejemplo, nvidia.com/gpu.shared) y activar failRequestsGreaterThanOne para evitar que un pod solicite múltiples referencias pensando que obtendrá más rendimiento.
Ambas técnicas pueden combinarse: MIG como primera capa de particionado hardware, y time-slicing sobre cada instancia MIG para oversubscription adicional. Esto es útil para workloads muy pequeños, pero añade complejidad operativa y de monitorización. Nuestra recomendación en Q2BSTUDIO es empezar con pools de nodos separados: un pool exclusivo para GPUs completas (entrenamiento, inferencia sensible a latencia), un pool MIG para producción multiinquilino, y un pool time-slicing para desarrollo y pruebas. Cada pool debe tener etiquetas, taints, cuotas y métricas propias.
Las cuotas de recursos (ResourceQuota) son un complemento indispensable. Permiten limitar cuántos recursos GPU puede consumir un namespace, ya sean perfiles MIG o recursos time-slicing. Pero ojo: una cuota no garantiza rendimiento ni porcentaje de GPU; solo controla la admisión. Si un namespace tiene cuota 4 para nvidia.com/gpu.shared, podrá lanzar hasta 4 pods, pero todos competirán por la misma GPU física. Para una gobernanza real, combina cuotas con políticas de afinidad, naming explícito y pruebas de rendimiento concurrente.
Desde el punto de vista de implementación, el GPU Operator de NVIDIA automatiza gran parte del trabajo. Para MIG, se usa MIG Manager y estrategias 'single' (todos los dispositivos iguales) o 'mixed' (perfiles variados). En estrategia mixed, los recursos se anuncian con nombres como nvidia.com/mig-1g.10gb, lo que da transparencia al desarrollador. En estrategia single, se usa nvidia.com/gpu junto con una etiqueta de producto. La elección depende de la diversidad de workloads en el clúster.
Para time-slicing, se configura un ConfigMap con el número de réplicas y flags como renameByDefault: true. Es importante validar que la monitorización se adapta: con time-slicing, DCGM Exporter no puede asociar métricas GPU a contenedores individuales de forma fiable. Por eso, las aplicaciones deben incluir telemetría propia (latencia, throughput, tasa de error). En Q2BSTUDIO diseñamos soluciones de observabilidad a medida, integrando métricas de negocio con datos de infraestructura para que cada equipo tenga visibilidad real de su consumo.
Un caso práctico habitual es el de una empresa que despliega agentes de IA conversacionales. Cada agente requiere inferencia en tiempo real, pero con picos variables. Usar una GPU completa para cada agente sería prohibitivo. Con MIG, se pueden asignar instancias de tamaño fijo a los agentes más críticos, y time-slicing para los de prueba. Además, con cuotas por namespace, cada departamento tiene un límite claro. Esto se complementa con servicios cloud como AWS o Azure para escalar horizontalmente cuando la demanda supera la capacidad local. En Q2BSTUDIO ayudamos a las empresas a diseñar esta arquitectura híbrida, integrando servicios cloud AWS/Azure con clústeres Kubernetes on-premise, y desarrollando aplicaciones a medida que gestionan el ciclo de vida de los modelos de IA.
Otro aspecto clave es la ciberseguridad. Compartir GPUs introduce riesgos de fuga de información entre procesos si no hay aislamiento hardware. MIG ofrece un aislamiento más fuerte, pero no es infranqueable. Para entornos regulados, recomendamos combinar MIG con políticas de red, namespaces dedicados y cifrado de datos en tránsito y reposo. Nuestro equipo de ciberseguridad realiza auditorías de configuración y pruebas de pentesting para garantizar que el modelo de compartición no expone datos sensibles.
Finalmente, no olvidemos la inteligencia de negocio. Cuando compartes GPUs, entender el uso real es crítico para la toma de decisiones. Las herramientas de BI como Power BI pueden consumir datos de DCGM y métricas personalizadas para generar dashboards de utilización, coste por workload y planificación de capacidad. En Q2BSTUDIO integramos soluciones de BI/Power BI con los pipelines de datos del clúster, proporcionando informes accionables que ayudan a ajustar perfiles MIG o réplicas time-slicing según la demanda real.
En resumen, compartir GPUs no es una decisión binaria. MIG, time-slicing y cuotas son herramientas complementarias que deben aplicarse según los requisitos de cada workload. La clave está en diseñar una arquitectura de pools separados, con políticas claras, monitorización adecuada y un proceso de cambio controlado. Si tu organización busca optimizar el uso de GPUs sin sacrificar rendimiento ni seguridad, en Q2BSTUDIO podemos ayudarte a implementar estas soluciones, desde el diseño hasta la operación continua.
