Compartir GPUs NVIDIA en entorns Kubernetes és una necessitat creixent per optimitzar costos i recursos, però triar el model adequat pot marcar la diferència entre un desplegament eficient i un caos operatiu. Hi ha dos enfocaments principals — Multi-Instance GPU (MIG) i time-slicing — i cadascun respon a problemàtiques diferents. En aquest article analitzem les seves diferències, quan aplicar cada un i com complementar-los amb quotes de recursos, des d'una perspectiva tècnica i empresarial, amb el suport de Q2BSTUDIO, empresa especialitzada en desenvolupament de programari a mida, intel·ligència artificial, ciberseguretat i cloud computing.
El principal repte és que les GPUs són recursos costosos que sovint s'infrautilitzen. Kubernetes les tracta com a recursos extensibles indivisibles: una aplicació demana una GPU, se li assigna completa, i la resta del clúster la considera ocupada encara que el workload només faci servir una fracció de la seva capacitat. La solució passa per compartir la GPU, però no totes les tècniques són equivalents. MIG divideix físicament la GPU en instàncies hardware independents, cadascuna amb memòria i còmput dedicats. Time-slicing, en canvi, anuncia múltiples rèpliques lògiques de la mateixa GPU, però totes comparteixen el mateix hardware i competeixen per temps d'execució, sense aïllament de memòria ni rendiment garantit.
Quan utilitzar MIG? És ideal per a entorns multiinquilino on cada workload necessita límits de recursos predictibles i aïllament real. Per exemple, en plataformes d'inferència amb mides de model conegudes, on una instància MIG 1g.10GB és suficient, i una altra 2g.20GB es reserva per a un model més gran. MIG ofereix un particionat hardware que evita el 'veí sorollós' i dona garanties de rendiment. No obstant, té limitacions: els perfils disponibles depenen del model de GPU (H100, A100, etc.) i no són configurables arbitràriament. Canviar la geometria de MIG requereix drenar el node, aplicar la nova configuració i esperar que el MIG Manager la validi. És una operació disruptiva que s'ha de planificar com un manteniment major.
Quan utilitzar time-slicing? És adequat per a càrregues de treball lleugeres, bursty, entorns de desenvolupament, notebooks o pipelines de CI/CD. En no crear particions hardware, es pot anunciar, per exemple, 4 o 8 rèpliques d'una mateixa GPU física. L'avantatge és la flexibilitat: es pot canviar el nombre de rèpliques sense reiniciar el node, només reiniciant el device plugin. L'inconvenient és la manca d'aïllament: un workload pot esgotar la memòria GPU de tots, i la latència és impredictible sota contenció. Per mitigar riscos, es recomana reanomenar els recursos compartits (per exemple, nvidia.com/gpu.shared) i activar failRequestsGreaterThanOne per evitar que un pod sol·liciti múltiples referències pensant que obtindrà més rendiment.
Ambdues tècniques es poden combinar: MIG com a primera capa de particionat hardware, i time-slicing sobre cada instància MIG per a oversubscription addicional. Això és útil per a workloads molt petits, però afegeix complexitat operativa i de monitorització. La nostra recomanació a Q2BSTUDIO és començar amb pools de nodes separats: un pool exclusiu per a GPUs completes (entrenament, inferència sensible a latència), un pool MIG per a producció multiinquilino, i un pool time-slicing per a desenvolupament i proves. Cada pool ha de tenir etiquetes, taints, quotes i mètriques pròpies.
Les quotes de recursos (ResourceQuota) són un complement indispensable. Permeten limitar quants recursos GPU pot consumir un namespace, ja siguin perfils MIG o recursos time-slicing. Però compte: una quota no garanteix rendiment ni percentatge de GPU; només controla l'admissió. Si un namespace té quota 4 per a nvidia.com/gpu.shared, podrà llançar fins a 4 pods, però tots competiran per la mateixa GPU física. Per a una governança real, combina quotes amb polítiques d'afinitat, nomenclatura explícita i proves de rendiment concurrent.
Des del punt de vista d'implementació, el GPU Operator de NVIDIA automatitza gran part de la feina. Per a MIG, s'utilitza MIG Manager i estratègies 'single' (tots els dispositius iguals) o 'mixed' (perfils variats). En estratègia mixed, els recursos s'anuncien amb noms com nvidia.com/mig-1g.10gb, la qual cosa dona transparència al desenvolupador. En estratègia single, s'usa nvidia.com/gpu juntament amb una etiqueta de producte. L'elecció depèn de la diversitat de workloads al clúster.
Per a time-slicing, es configura un ConfigMap amb el nombre de rèpliques i flags com renameByDefault: true. És important validar que la monitorització s'adapta: amb time-slicing, DCGM Exporter no pot associar mètriques GPU a contenidors individuals de manera fiable. Per això, les aplicacions han d'incloure telemetria pròpia (latència, throughput, taxa d'error). A Q2BSTUDIO dissenyem solucions d'observabilitat a mida, integrant mètriques de negoci amb dades d'infraestructura perquè cada equip tingui visibilitat real del seu consum.
Un cas pràctic habitual és el d'una empresa que desplega agents d'IA conversacionals. Cada agent requereix inferència en temps real, però amb pics variables. Usar una GPU completa per a cada agent seria prohibitiu. Amb MIG, es poden assignar instàncies de mida fixa als agents més crítics, i time-slicing per als de prova. A més, amb quotes per namespace, cada departament té un límit clar. Això es complementa amb serveis cloud com AWS o Azure per escalar horitzontalment quan la demanda supera la capacitat local. A Q2BSTUDIO ajudem les empreses a dissenyar aquesta arquitectura híbrida, integrant serveis cloud AWS/Azure amb clústers Kubernetes on-premise, i desenvolupant aplicacions a mida que gestionen el cicle de vida dels models d'IA.
Un altre aspecte clau és la ciberseguretat. Compartir GPUs introdueix riscos de fuita d'informació entre processos si no hi ha aïllament hardware. MIG ofereix un aïllament més fort, però no és infranquejable. Per a entorns regulats, recomanem combinar MIG amb polítiques de xarxa, namespaces dedicats i xifrat de dades en trànsit i repòs. El nostre equip de ciberseguretat realitza auditories de configuració i proves de pentesting per garantir que el model de compartició no exposa dades sensibles.
Finalment, no oblidem la intel·ligència de negoci. Quan comparteixes GPUs, entendre l'ús real és crític per a la presa de decisions. Les eines de BI com Power BI poden consumir dades de DCGM i mètriques personalitzades per generar dashboards d'utilització, cost per workload i planificació de capacitat. A Q2BSTUDIO integrem solucions de BI/Power BI amb els pipelines de dades del clúster, proporcionant informes accionables que ajuden a ajustar perfils MIG o rèpliques time-slicing segons la demanda real.
En resum, compartir GPUs no és una decisió binària. MIG, time-slicing i quotes són eines complementàries que s'han d'aplicar segons els requisits de cada workload. La clau està en dissenyar una arquitectura de pools separats, amb polítiques clares, monitorització adequada i un procés de canvi controlat. Si la teva organització busca optimitzar l'ús de GPUs sense sacrificar rendiment ni seguretat, a Q2BSTUDIO podem ajudar-te a implementar aquestes solucions, des del disseny fins a l'operació contínua.
