Compartir una GPU entre diversos inquilins en un entorn cloud o privat sembla senzill sobre el paper, però a la pràctica és un dels problemes més complexos de la infraestructura moderna. Moltes plataformes prometen aïllament mitjançant característiques com MIG, time-slicing o vGPU, però sovint cauen en el que anomenem 'teatre de seguretat': implementen un mecanisme sense avaluar si realment protegeix els actius adequats. El resultat és una falsa sensació de protecció que pot exposar models, dades o rendiment crític. En aquest article explorem com construir un aïllament real per a GPU multi-inquilí, basat en una arquitectura per capes i en la comprensió de les veritables dimensions de la separació.
El primer error és pensar que una sola característica ho resol tot. Un scheduler pot gestionar cues i prioritats, però no aïlla la memòria de la GPU. MIG particiona el maquinari, però no separa administradors de clúster ni protegeix davant d'un host privilegiat. Els namespaces de Kubernetes ofereixen separació lògica, però no creen una frontera de confiança davant d'un inquilí maliciós. La confidencial computing xifra les dades en ús, però no garanteix disponibilitat ni latència. Per tant, abans d'escollir una tecnologia, cal definir un model d'amenaces: quins actius protegir, davant de qui i sota quines fallades. Només llavors es pot seleccionar la combinació correcta de controls de clúster, xarxa, emmagatzematge, identitat i xifrat.
L'aïllament real es desplega en vuit dimensions que s'han de dissenyar per separat: aïllament de memòria (un inquilí no pot accedir a la memòria d'un altre), de còmput (no consumeix recursos esperats per un altre), de rendiment (defensar latència sota contenció), de fallades (un esdeveniment en un dispositiu no afecta altres), administratiu (un operador no pot alterar recursos aliens), criptogràfic (ni l'administrador d'infraestructura pot llegir dades en ús), econòmic (no s'excedeix el pressupost) i operacional (actualitzacions o polítiques no interrompen altres). Cada dimensió requereix un control diferent, i cap substitueix les altres. Per exemple, assignar una GPU completa elimina la contenció entre veïns, però no protegeix davant d'un administrador del host. Per això cal confidencial computing.
A la pràctica, l'elecció del mecanisme de GPU (time-slicing, MIG, vGPU o GPU completa) ha d'alinear-se amb el perfil d'inquilí. Per a equips interns de recerca i desenvolupament, el time-slicing pot ser acceptable si s'etiqueta com a 'millor esforç'. Per a producció regulada o clients externs amb contracte, cal una GPU completa o una partició MIG dedicada, amb garanties de capacitat i sense sobresubscripció. Per a càrregues d'alta confidencialitat, com models propietaris o dades subjectes a regulació, cal a més confidencial computing amb atestació i alliberament controlat de claus. És clau que el catàleg de serveis declari explícitament els riscos residuals, en lloc de vendre 'GPU aïllada' com una solució màgica.
La confidencial computing és una eina poderosa, però té límits. No resol la denegació de servei, els veïns sorollosos ni les fallades de xarxa o emmagatzematge. Tampoc és compatible avui amb la compartició d'una mateixa GPU entre múltiples inquilins confidencials; l'arquitectura de referència de NVIDIA per a contenidors confidencials, a data de 2026, només suporta pas complet de GPU a una única màquina virtual confidencial. Per tant, no s'ha d'assumir que MIG més confidencial computing forma una solució multi-inquilí suportada. Cal validar cada combinació amb el fabricant i fer proves de fallades reals.
Un altre aspecte crític és la telemetria per inquilí. Sense una atribució precisa de l'ús de GPU, no es pot facturar, demostrar compliment ni investigar incidents. El time-slicing té una limitació important: l'exportador DCGM no pot associar mètriques a contenidors individuals quan s'usa aquest mètode, cosa que impedeix un showback fiable. En canvi, amb MIG o GPU completa, la mesura és possible. La plataforma ha de registrar no només la capacitat assignada, sinó també la utilitzada, els préstecs entre inquilins, les reclamacions i les decisions de preferència. Només així es pot demostrar que la política s'ha complert.
A Q2BSTUDIO entenem que l'aïllament real no és un producte que es compri, sinó una arquitectura que es dissenya. Com a empresa de desenvolupament d'aplicacions a mida, ajudem organitzacions a construir plataformes cloud sobiranes, integrant intel·ligència artificial, ciberseguretat i serveis cloud AWS/Azure. Els nostres equips dissenyen solucions multi-inquilí que respecten les dimensions d'aïllament, utilitzant agents IA per automatitzar polítiques i Power BI per monitoritzar el compliment. Creem programari que no només funciona, sinó que protegeix.
En conclusió, la GPU multi-inquilí sense teatre de seguretat no s'aconsegueix amb una característica estrella, sinó amb una pila de controls que aborden cada dimensió d'aïllament per separat. El model d'amenaces ha de guiar cada decisió, des de l'assignació de GPU fins a la política de xarxa i el xifrat. I, sobretot, cal ser honestos sobre què pot i què no pot fer cada control. Només així es construeix una plataforma d'IA o GPU com a servei que mereixi la confiança dels seus inquilins.
