A l'ecosistema actual d'intel·ligència artificial com a servei (AIaaS), una de les preguntes més enganyosament simples i alhora més complexes de respondre és: qui va utilitzar la GPU? Quan una plataforma admet múltiples models operatius —pods de Kubernetes amb GPU completa, instàncies MIG, porcions temporals, màquines virtuals amb vGPU o pas directe del dispositiu—, la resposta deixa de ser trivial. Un mateix accelerador pot estar ocupat per diversos inquilins, mostrar alta activitat sense generar treball útil, o romandre aparentment inactiu mentre reté memòria crítica que impedeix arrencar un altre model. Aquesta ambigüitat fa que un simple gràfic d'utilització no serveixi per a la rendició de comptes per inquilí.
Per construir un sistema de showback o chargeback defensable, cal separar quatre magnituds que sovint es confonen: assignació, utilització, treball productiu i consum financer. L'assignació respon a qui va controlar o reservar capacitat durant una finestra temporal. La utilització mesura què feia el maquinari en intervals mostrejats. El treball productiu reflecteix el resultat del servei —sol·licituds exitoses, tokens generats, passos d'entrenament completats—. I el consum financer aplica una política de costos aprovada a aquestes dades. Barrejar-les condueix a informes incorrectes i disputes entre equips.
A Q2BSTUDIO, entenem que la telemetria per inquilí no és només un problema tècnic, sinó un pilar per a la governança de plataformes d'IA empresarial. La nostra experiència en desenvolupament de aplicacions a mida i en la integració de serveis cloud (AWS/Azure) ens ha ensenyat que l'evidència s'ha de construir des de la capa d'orquestració fins al ledger financer, preservant la traçabilitat fins i tot quan l'atribució és aproximada —com passa amb el time-slicing o els processos compartits de servidors de models.
El primer pilar és l'assignació: un fet del pla de control. Per a un pod exclusiu, la unitat és una GPU assignada durant tres hores. Per a MIG, s'ha de conservar el perfil (per exemple, 1g.10gb). Per a vGPU, el perfil i la màquina virtual. Per a time-slicing, es declara la política de rèpliques, no una fracció aïllada. L'equació general és: hores GPU-equivalents assignades = integral de la fracció de capacitat assignada sobre el temps transcorregut. Aquesta fracció prové d'un inventari aprovat, no d'un percentatge momentani d'utilització.
La utilització és comportament mostrejat del dispositiu. DCGM i DCGM Exporter ofereixen mètriques com SM active ratio, memòria utilitzada, potència, temperatura. Són essencials per detectar reserves ocioses, saturació, colls d'ampolla o throttling tèrmic. Però la utilització no és una unitat de facturació universal. Un inquilí pot ser financerament responsable d'una GPU reservada encara que la utilització sigui baixa, igual que una màquina virtual reservada costa encara que la seva CPU estigui en repòs. Una mesura derivada com 'hores GPU actives equivalents' pot ser útil per a analítica, però no s'ha de convertir automàticament en factura sense decisió organitzativa.
El treball productiu és específic de l'aplicació. Per a inferència, poden ser sol·licituds exitoses, tokens d'entrada i sortida, imatges generades. Per a entrenament, passos completats o mostres processades. La mateixa activitat de GPU pot produir quantitats molt diferents de treball útil segons la mida del model, la precisió, la mida del lot, la latència objectiu. Per això les mètriques del servidor de models —tokens per segon, temps fins al primer token, profunditat de cua— han d'acompanyar la telemetria de GPU.
El consum financer aplica política a l'evidència. Un model de chargeback defensable explicita: càrrec de l'inquilí = càrrec per capacitat garantida + càrrec per assignació prestada + càrrec variable per servei o energia + despeses generals compartides - crèdits i ajustos aprovats. Cada terme ha de ser explicable; un revisor de finances ha de poder reproduir el resultat mensual; el propietari de l'aplicació ha d'entendre per què una reserva ociosa segueix costant diners.
Per aconseguir-ho, cal una cadena d'atribució estable a través de capes: negoci (ID d'inquilí, departament), orquestració (clúster, namespace UID, pod UID), dispositiu (UUID de GPU, perfil MIG), servei (ID d'endpoint, model, versió) i sol·licitud (trace ID). Els identificadors immutables i la validesa temporal són claus. Quan un pod s'elimina o un namespace canvia de propietari, la relació antiga ha de seguir sent consultable per al tancament mensual. Recomanem mantenir un magatzem d'esdeveniments d'assignació independent del sistema d'orquestració en viu.
Les etiquetes de Prometheus s'han de limitar a dimensions acotades (clúster, namespace, model, classe de GPU, inquilí). Els IDs de sol·licitud o processos van a logs o traces, no a mètriques. L'arquitectura de referència separa la recol·lecció (DCGM Exporter, mètriques de Kubernetes, telemetria del servidor de models), l'enriquiment d'identitat (mitjançant regles de gravació de Prometheus), l'analítica operativa i el ledger financer. Un patró pràctic és un exportador d'identitat que emet un gauge per cada càrrega de treball activa amb etiquetes permeses, i després regles de gravació uneixen les mètriques de GPU normalitzades amb aquestes identitats.
L'atribució en MIG és més sòlida que en time-slicing perquè existeix un identificador d'instància aïllada. No obstant això, la fracció de capacitat ha de venir del perfil aprovat, no inferir-se de l'ús de memòria. En time-slicing, la mètrica del dispositiu físic es replica entre rèpliques; la divisió equitativa és una suposició modelada, no un mesurament exacte. Per això recomanem marcar aquestes dades amb un nivell de confiança explícit. Per a vGPU, cal evidència de l'amfitrió (UUID de GPU, perfil, VM) i del convidat (mètriques de DCGM dins de la VM), sense sumar tots dos.
Els servidors de models compartits —un sol procés que atén diversos inquilins— requereixen comptabilitat a nivell de sol·licitud. El cost per inquilí es basa en tokens o peticions ponderades, no en dividir la mètrica del procés. Es calcula una fracció de servei de l'inquilí: unitats productives ponderades de l'inquilí / total d'unitats productives de l'endpoint. El model de ponderació s'ha de versionar i provar.
La ciberseguretat també juga un paper: la telemetria de GPU i les assignacions s'han de protegir contra accessos no autoritzats entre inquilins. A Q2BSTUDIO integrem pràctiques de seguretat a cada capa, des de l'autenticació de mètriques fins a l'aïllament de dashboards. A més, la integració amb serveis cloud com AWS o Azure permet escalar la infraestructura de telemetria de manera segura, i l'ús d'eines de BI com Power BI facilita la creació d'informes de showback personalitzats per a cada departament.
Els agents d'IA —sistemes autònoms que executen inferències o entrenaments— afegeixen una altra capa de complexitat, ja que poden generar càrregues de treball efímeres que dificulten l'atribució. La nostra aproximació consisteix a assignar un identificador d'agent a cada sessió i correlacionar-lo amb l'assignació de GPU mitjançant etiquetes d'orquestració.
En resum, construir telemetria per inquilí per a AIaaS exigeix separar conceptes, mantenir una cadena d'evidència estable, i acceptar que algunes atribucions seran aproximades però documentades. L'objectiu no és el dashboard més vistós, sinó un registre operatiu que sobrevisqui a l'eliminació de pods, la rotació de processos, les disputes d'inquilins i el tancament mensual. A Q2BSTUDIO ajudem les organitzacions a dissenyar i implementar aquesta arquitectura, combinant desenvolupament de programari a mida, cloud, ciberseguretat, intel·ligència artificial i business intelligence perquè la pregunta 'qui va utilitzar la GPU?' tingui una resposta defensable.
