Cómo varios equipos y tenants pueden compartir clústeres de GPU con seguridad

Varios equipos o tenants pueden compartir una infraestructura de GPU costosa de forma segura si separas identidad, permisos, asignación de recursos, ubicación de cargas de trabajo, acceso a servicios, medición y auditoría. El diseño de origen aborda el multitenancy tanto como un problema de personas como un problema de cómputo: los tenants tienen miembros y permisos, pero también proyectos, cuotas, tareas, servicios de modelos, uso de tokens y límites de coste.

El objetivo es compartir esa infraestructura cara sin convertir el entorno en un único grupo de recursos sin control. Cada usuario debe recibir la capacidad que su proyecto tiene autorización para usar, ver únicamente los objetos que tiene permiso para consultar y dejar un registro auditable cada vez que envía, modifica o consume servicios.

¿Qué necesita aislar el uso compartido de GPU multitenant?

El modelo de origen aísla a los tenants en varias capas operativas. Para las personas, esto abarca miembros del tenant, miembros del proyecto, roles y permisos. En cuanto al cómputo, cubre cuotas de recursos, propiedad de tareas, grupos de recursos y planificación. Los servicios de modelos incluyen los propios modelos, bases de conocimiento, aplicaciones y claves de acceso, mientras que el consumo contempla horas de acelerador, uso de tokens y costes.

Aislar solo el cómputo no basta. Dos equipos pueden tener cuotas de GPU independientes y seguir teniendo un problema grave de gobernanza de datos si uno de ellos puede ver el modelo, la orden de trabajo o la base de conocimiento del otro. Por eso, el límite del tenant debe recorrer toda la cadena operativa.

¿Por qué deben coexistir tenants y proyectos?

Un tenant representa un límite más amplio de propiedad y aislamiento, mientras que un proyecto es una unidad de trabajo y contabilidad más específica dentro de ese tenant. El documento de origen describe el multitenancy como un esquema que involucra a personas y cómputo, incluyendo miembros, permisos, proyectos, cuotas, tareas, servicios de modelos, consumo de tokens y separación de costes.

Esto permite que una organización agrupe varios proyectos bajo un mismo tenant mientras sigue el consumo y la responsabilidad a nivel de proyecto. Por ejemplo, el tenant de un departamento de investigación puede albergar el Proyecto A para el ajuste fino de modelos fundacionales y el Proyecto B para inferencia visual. El tenant aporta la frontera organizativa y el proyecto define el límite de las cargas de trabajo y los costes.

¿Cómo deben funcionar los permisos por roles?

Aplica el principio de mínimo privilegio. El modelo de gobernanza de origen incluye jerarquía organizativa, matrices de permisos por rol, pertenencia a tenants, pertenencia a proyectos y autorizaciones separadas para operaciones sensibles. De este modo, cada usuario recibe únicamente los permisos que necesita para su función.

Por ejemplo, quien administra un tenant puede gestionar miembros y algunos parámetros de proyecto dentro de ese tenant, mientras que un usuario de proyecto puede enviar cargas de trabajo dentro de su cuota asignada. El equipo de operaciones gestiona el estado de la infraestructura y quien lleva la seguridad administra las políticas más sensibles. Las cuentas de proveedores externos solo acceden a los equipos u órdenes de trabajo autorizados durante un tiempo limitado.

El documento de origen señala explícitamente que la administración de un tenant puede gestionar miembros, proyectos y ciertos permisos dentro del margen asignado por la administración de la plataforma, pero nunca puede cruzar a otros tenants ni tocar recursos globales. Ese es el principio correcto para un entorno compartido.

¿Cómo deben las cuotas de GPU garantizar la equidad?

La cuota debe comprobarse antes de que la carga de trabajo entre en la competencia habitual de planificación. El planificador de origen trata la cuota del tenant como una restricción estricta, lo que evita que un tenant envíe suficiente trabajo para acaparar todo el clúster simplemente porque sus tareas llevan más tiempo esperando.

Según el documento de origen, la cuota puede basarse en número de GPU, memoria de aceleradores, CPU y memoria del sistema, tareas simultáneas o horas mensuales de tarjeta. Cada organización puede elegir las dimensiones que mejor encajen con su modelo operativo. Una cuota rígida de capacidad protege la infraestructura, mientras que una cuota de uso ayuda además a controlar el presupuesto.

¿Cómo deben funcionar las prioridades entre tenants?

La prioridad debe definirse mediante políticas, independientemente del orden en que los usuarios envíen sus peticiones. El planificador de origen admite prioridad de colas y desalojo (preemption), lo que permite distinguir entre producción y desarrollo, atención crítica a clientes y procesos por lotes en segundo plano, o incidentes urgentes e investigación flexible.

Aun así, la prioridad necesita gobernanza. Si cada tenant pudiera marcar cualquier tarea como "máxima prioridad", el mecanismo perdería todo su valor. La documentación de origen no impone una política rígida de administración de prioridades, pero un diseño práctico derivado de ella consiste en vincular los niveles altos de prioridad a roles concretos, tipos de proyectos o categorías de cargas de trabajo aprobadas, conservando siempre la decisión en el historial de auditoría.

¿Conviene compartir GPU completas o particiones de GPU?

El diseño de planificación de origen admite tanto tarjetas completas como recursos particionados, y la elección depende de la carga de trabajo y del hardware disponible. Asignar una tarjeta completa resulta adecuado cuando la tarea exige recursos de aceleración exclusivos, un rendimiento predecible o un dispositivo entero. Las particiones de GPU pueden mejorar la eficiencia en cargas de trabajo más ligeras cuando el hardware lo soporta y cuando el aislamiento resultante resulta aceptable.

El documento de origen también identifica el aislamiento de varios contenedores en una sola tarjeta y las interferencias entre tarjetas compartidas como desafíos técnicos importantes, de modo que el uso compartido de GPU no debe considerarse equivalente a una asignación dedicada de manera automática. Monitorea el comportamiento de las cargas de trabajo compartidas, mantén visible el tipo de recurso y utiliza especificaciones estándar para que los usuarios comprendan qué están solicitando.

¿Cómo se deben compartir GPU heterogéneas?

Normalízalas en especificaciones de recursos estándar, manteniendo por debajo el modelo real y su estado de salud. La plataforma de origen permite crear grupos heterogéneos entre múltiples fabricantes y modelos de aceleradores, y los usuarios pueden solicitar una clase de recurso estándar en lugar de seleccionar tarjetas físicas individuales a mano. Esto facilita el reparto porque la plataforma gestiona el tipo de tarjeta, el número de dispositivos, la CPU, la memoria y la modalidad completa o particionada.

El documento de origen también advierte que planificar recursos de múltiples fabricantes resulta complejo porque los controladores, los entornos de ejecución y los complementos de dispositivo varían. La capa de recursos estándar debe simplificar la petición manteniendo las reglas de compatibilidad, sin pretender que todas las tarjetas sean idénticas.

¿Cómo debe el estado de las tarjetas proteger a los tenants?

El estado de salud debe comprobarse antes de la asignación. El diseño de planificación de origen aísla de forma explícita las tarjetas de aceleración degradadas antes de asignar tareas, algo todavía más relevante en un entorno compartido. Ningún tenant debería recibir una tarjeta solo porque esté visible a nivel técnico y libre en ese momento.

Si la tarjeta está degradada, la plataforma debe retirarla de la planificación normal o aplicar la política de salud aprobada. Eso evita que un tenant se convierta en el desafortunado receptor de capacidad defectuosa conocida, y mejora la equidad porque la oferta útil se mide a partir de recursos sanos y no del inventario total instalado.

¿Cómo se deben rastrear las vinculaciones de cargas de trabajo?

El modelo de contenedores y GPU de origen conserva asignaciones bidireccionales entre tarjetas aceleradoras y contenedores, además de guardar una cronología de vinculación para fines de auditoría. Gracias a esto, la plataforma puede responder qué carga de trabajo está utilizando una GPU, qué GPU usa un contenedor, qué tenant posee esa carga de trabajo y cuándo comenzó y terminó dicha vinculación.

Estas relaciones son fundamentales en una infraestructura compartida porque permiten analizar el impacto de incidentes, asignar costes, realizar revisiones de seguridad, recuperar recursos y auditar el historial. Si surge un error de hardware, el equipo de operaciones puede identificar con exactitud el tenant y la tarea afectados sin exponer los datos de otros tenants no involucrados.

¿Cómo se debe aislar el acceso a los servicios de modelos?

La capa de servicios de modelos de origen separa modelos, bases de conocimiento, aplicaciones, claves, cuotas y uso por tenant y proyecto. Las claves API están vinculadas a etiquetas de proyecto para que el consumo de tokens se atribuya correctamente, lo que dota a la capa de servicios de su propio límite de acceso.

Ningún tenant debería poder invocar el servicio de modelos privado de otro tenant ni consultar su base de conocimiento simplemente porque ambos utilicen el mismo clúster de GPU subyacente. El grupo de cómputo puede ser compartido mientras la titularidad del servicio y los datos se mantiene totalmente aislada.

¿Cómo se deben aislar las bases de conocimiento?

El diseño de RAG de origen establece de forma explícita que los permisos de las bases de conocimiento se aíslan por tenant, lo cual constituye un control de seguridad esencial. Dos tenants pueden utilizar el mismo modelo aprobado mientras consultan información empresarial distinta, ya que el modelo actúa como infraestructura compartida y la base de conocimiento se mantiene específica de cada tenant.

Esta separación representa una de las ventajas de desacoplar los ciclos de vida del modelo y del conocimiento. El mismo principio debe aplicarse a documentos operativos y órdenes de trabajo, de modo que cada usuario consulte únicamente el conocimiento que su rol y su tenant le autorizan a ver.

¿Cómo se debe medir el consumo?

El modelo de medición de origen atribuye el consumo por tenant, proyecto, modelo y tipo de acelerador, registrando tanto las horas de tarjeta como el uso de tokens. Esto proporciona a la organización una respuesta clara a la pregunta fundamental de cualquier infraestructura compartida: quién utilizó qué.

Sin medición, las GPU compartidas pueden convertirse en una fuente de fricciones internas porque cada equipo suele asumir que otro está consumiendo la capacidad más cara. La medición convierte esa discusión en datos objetivos.

Si quieres profundizar en el modelo de asignación detallado, cómo las empresas pueden medir el coste de la infraestructura de IA por hora de GPU, token, proyecto, tenant o modelo explica cómo se conectan las dimensiones de propiedad y consumo.

¿Cómo debe funcionar la visibilidad de costes?

Cada tenant o proyecto debe tener visibilidad sobre su propio consumo dentro del ámbito autorizado, y el modelo de operaciones de origen genera informes de costes por proyecto y por tenant. Las organizaciones no necesitan facturar internamente a sus equipos de forma obligatoria: algunas empresas utilizan estas cifras únicamente para showback, mientras que otras las aplican para chargeback.

El requisito principal de seguridad es que los datos detallados de costes y cargas de trabajo de un tenant no queden expuestos a otro sin la debida autorización. A nivel de plataforma, la administración puede disponer de informes globales agregados para la toma de decisiones.

¿Cómo debe funcionar la auditoría entre tenants?

El modelo de gobernanza de origen exige trazabilidad por persona, fecha y hora, objeto de destino y acción. En las operaciones con GPU compartidas, las acciones auditadas incluyen solicitudes de recursos, cambios de cuota, ajustes de prioridad, envío de cargas de trabajo, desalojos, liberación manual de recursos, publicación de servicios de modelos, gestión de claves API, modificaciones de permisos y cualquier otra operación sensible.

El registro de auditoría debe conservar la identidad del usuario o del servicio que ejecutó la acción. Esto resulta especialmente crítico para los administradores de un tenant, que pueden contar con un control amplio dentro de su entorno pero no tienen autorización para modificar la política global de recursos. El historial de auditoría confirma si ese límite se respetó.

En cuanto a las políticas de planificación para capacidad compartida, qué significan las cuotas, reservas, prioridades y el desalojo en GPU y cuándo conviene usar cada mecanismo detalla por qué el derecho a los recursos y la urgencia deben mantenerse como controles separados.

¿Cómo gestionar el acceso de soporte y proveedores externos?

El documento de origen recomienda cuentas de proveedor restringidas con un alcance limitado a la orden de trabajo y permisos acotados en el tiempo, un patrón que funciona igual de bien en infraestructuras compartidas. Un proveedor de hardware puede necesitar acceso a un nodo de GPU averiado, pero ese permiso no debe extenderse de forma automática a las cargas de trabajo de otros tenants, los servicios de modelos, las bases de conocimiento, el consumo de proyectos ni la administración global.

El acceso temporal y delimitado reduce la exposición innecesaria, y cada inicio de sesión y operación debe quedar registrado para auditoría.

¿Cómo evitar que el fallo de un tenant afecte a los demás?

Utiliza límites de recursos claros, aislamiento por estado de salud, conocimiento de la topología y una planificación controlada. Si una tarjeta se degrada, aísla el dispositivo antes de realizar nuevas asignaciones. Si una tarea genera una contención anómala en una tarjeta compartida, la plataforma debe detectar la interferencia y aplicar la política de recursos correspondiente. Si un nodo falla, identifica las cargas de trabajo afectadas y vuelve a planificarlas únicamente donde lo permita la política de recuperación aprobada.

El diseño de origen también rastrea las dependencias desde la GPU hasta el contenedor y la aplicación, lo que ayuda a contener cualquier incidente dentro del tenant o servicio afectado.

¿Qué debe mostrar la interfaz para el tenant?

La vista destinada a un tenant o proyecto puede mostrar la cuota de recursos autorizada, la asignación actual, la cuota disponible, las tareas en ejecución y en cola con sus motivos de espera, los servicios de modelos, el consumo de tokens, las horas de tarjeta, el coste estimado y las alarmas activas que afecten a sus recursos. Nunca debe mostrar infraestructura ni datos de otros tenants fuera del límite autorizado.

Un ejemplo de plataforma que reúne cuotas de tenant, aislamiento de proyectos, planificación de recursos, atribución de tokens y acceso con mínimo privilegio es Sensaka.

Si tuviera que diseñar un esquema seguro para compartir GPU, situaría un principio en el centro: el grupo de aceleradores físicos puede compartirse, pero la propiedad, los permisos, la identidad de las cargas de trabajo, el acceso a los servicios, los datos de uso y la auditoría deben mantenerse explícitos en cada capa. Con esa base, un clúster compartido opera como una verdadera plataforma multitenant en lugar de una sala de servidores desordenada.