Compartir una GPU entre varios inquilinos en un entorno cloud o privado parece sencillo sobre el papel, pero en la práctica es uno de los problemas más complejos de la infraestructura moderna. Muchas plataformas prometen aislamiento mediante características como MIG, time-slicing o vGPU, pero con frecuencia caen en lo que llamamos 'teatro de seguridad': implementan un mecanismo sin evaluar si realmente protege los activos adecuados. El resultado es una falsa sensación de protección que puede exponer modelos, datos o rendimiento crítico. En este artículo exploramos cómo construir un aislamiento real para GPU multi-inquilino, basado en una arquitectura por capas y en la comprensión de las verdaderas dimensiones de la separación.
El primer error es pensar que una sola característica resuelve todo. Un scheduler puede gestionar colas y prioridades, pero no aísla la memoria de la GPU. MIG particiona el hardware, pero no separa administradores de clúster ni protege frente a un host privilegiado. Los namespaces de Kubernetes ofrecen separación lógica, pero no crean una frontera de confianza frente a un inquilino malicioso. La confidencial computing cifra los datos en uso, pero no garantiza disponibilidad ni latencia. Por eso, antes de elegir una tecnología, hay que definir un modelo de amenazas: qué activos proteger, frente a quién y bajo qué fallos. Solo entonces se puede seleccionar la combinación correcta de controles de clúster, red, almacenamiento, identidad y cifrado.
El aislamiento real se despliega en ocho dimensiones que deben diseñarse por separado: aislamiento de memoria (que un inquilino no acceda a la memoria de otro), de cómputo (que no consuma recursos esperados por otro), de rendimiento (defender latencia bajo contención), de fallos (que un evento en un dispositivo no afecte a otros), administrativo (que un operador no altere recursos ajenos), criptográfico (que ni el administrador de infraestructura pueda leer datos en uso), económico (que no se exceda el presupuesto) y operacional (que actualizaciones o políticas no interrumpan a otros). Cada dimensión requiere un control diferente, y ninguna sustituye a las demás. Por ejemplo, asignar una GPU completa elimina la contención entre vecinos, pero no protege frente a un administrador del host. Para eso hace falta confidencial computing.
En la práctica, la elección del mecanismo de GPU (time-slicing, MIG, vGPU o GPU completa) debe alinearse con el perfil de inquilino. Para equipos internos de investigación y desarrollo, el time-slicing puede ser aceptable si se etiqueta como 'mejor esfuerzo'. Para producción regulada o clientes externos con contrato, se necesita una GPU completa o una partición MIG dedicada, con garantías de capacidad y sin sobresuscripción. Para cargas de alta confidencialidad, como modelos propietarios o datos sujetos a regulación, se requiere además confidencial computing con atestación y liberación controlada de claves. Es clave que el catálogo de servicios declare explícitamente qué riesgos residuales quedan, en lugar de vender 'GPU aislada' como una solución mágica.
La confidencial computing es una herramienta poderosa, pero tiene límites. No resuelve la denegación de servicio, los vecinos ruidosos ni los fallos de red o almacenamiento. Tampoco es compatible hoy con la compartición de una misma GPU entre múltiples inquilinos confidenciales; la arquitectura de referencia de NVIDIA para contenedores confidenciales, a fecha de 2026, solo soporta paso completo de GPU a una única máquina virtual confidencial. Por tanto, no se debe asumir que MIG más confidencial computing forma una solución multi-inquilino soportada. Hay que validar cada combinación con el fabricante y realizar pruebas de fallos reales.
Otro aspecto crítico es la telemetría por inquilino. Sin una atribución precisa del uso de GPU, no se puede facturar, demostrar cumplimiento ni investigar incidentes. El time-slicing tiene una limitación importante: el exportador DCGM no puede asociar métricas a contenedores individuales cuando se usa este método, lo que impide un showback fiable. En cambio, con MIG o GPU completa, la medición es posible. La plataforma debe registrar no solo la capacidad asignada, sino también la utilizada, los préstamos entre inquilinos, las reclamaciones y las decisiones de preferencia. Solo así se puede demostrar que la política se ha cumplido.
En Q2BSTUDIO entendemos que el aislamiento real no es un producto que se compra, sino una arquitectura que se diseña. Como empresa de desarrollo de aplicaciones a medida, ayudamos a organizaciones a construir plataformas cloud soberanas, integrando inteligencia artificial, ciberseguridad y servicios de cloud AWS/Azure. Nuestros equipos diseñan soluciones multi-inquilino que respetan las dimensiones de aislamiento, utilizando agentes IA para automatizar políticas y Power BI para monitorizar el cumplimiento. Creamos software que no solo funciona, sino que protege.
En conclusión, la GPU multi-inquilino sin teatro de seguridad no se logra con una característica estrella, sino con una pila de controles que abordan cada dimensión de aislamiento por separado. El modelo de amenazas debe guiar cada decisión, desde la asignación de GPU hasta la política de red y el cifrado. Y, sobre todo, hay que ser honestos sobre lo que cada control puede y no puede hacer. Solo así se construye una plataforma de IA o GPU como servicio que merezca la confianza de sus inquilinos.
