IA sostenible

• El cos físic de la IA
  • La inferència ja pesa més que l’entrenament
  • Per què no hi ha una xifra única
• On s’executa la tasca
  • Quatre menes de processador, i un coll d’ampolla
  • Del centre de dades al dispositiu
  • On convé executar cada cosa
• La IA també és informàtica: mesures d’informàtica verda
  • Les mètriques clàssiques i el que amaguen
  • Pràctiques que s’apliquen igual a la IA
• Fer més amb menys, i per què no n’hi ha prou
  • La paradoxa de Jevons
• Consciència: saber què costa el que fem
  • El bucle del senyal, i el seu límit
• El cost que no és a la factura
  • Per què la transparència, sola, no ho arregla
  • Límits que no es compren
• Codi obert i maquinari obert
  • Quatre nivells que no s’han de confondre
  • La pila, capa a capa
  • Per què això és una qüestió ambiental
  • El que l’obertura no resol
• Democràcia: qui decideix sobre la computació
  • La computació com a servei públic
• Camins d’actuació
  • Preguntes obertes
• Referències

Un model d’IA sembla una cosa immaterial: entren dades, en surt una predicció. Però cada inferència passa per un processador concret, dins d’un edifici concret, alimentat per una xarxa elèctrica concreta i refrigerat amb un sistema concret. Aquest cos físic és el que fa que la sostenibilitat de la IA no es pugui reduir a una qüestió d’algoritmes.

La idea que recorre aquest document és que el cost d’un sistema d’IA no és una propietat del model sinó del sistema sencer, incloent-hi on s’executa, amb quin programari i quant de temps viu el maquinari que el fa funcionar. D’aquí en surten les dues idees centrals:

• Consciència: només es pot decidir bé sobre allò que es veu. Avui, qui fa servir un servei d’IA no sap què ha costat la seva petició, i qui la programa tampoc no acostuma a saber-ho. Fer visible el cost és la condició prèvia de qualsevol altra cosa.
• Democràcia: decidir quanta computació fem, on s’instal·la la infraestructura i qui n’assumeix els impactes són decisions col·lectives, no preferències de consum. Qui controla el model, el programari i el maquinari controla també aquestes decisions, i per això el codi obert i el maquinari obert apareixen aquí com una qüestió ambiental i no només tècnica.

El recorregut va del físic al polític. Primer mirem el cos material de la IA i les decisions tècniques que en depenen: sobre quin maquinari s’executa, com s’opera la instal·lació que l’allotja i quin model s’utilitza. Després veiem qui paga aquests costos i qui controla la infraestructura que els genera. I acabem amb el que pot fer cadascú segons el paper que hi tingui.

La dimensió tècnica d’aquests temes es desenvolupa a Arquitectura de sistemes LLM, Selecció de model per cas d’ús i Sistemes LLM en producció. Aquí ens interessa el que aquells documents donen per suposat: que la computació és barata, disponible i sense conseqüències.

El cos físic de la IA

Pensem en un servei de transcripció que processa les gravacions d’un centre. Cada fitxer que s’hi envia es converteix en segons de càlcul en una GPU, que consumeix electricitat i genera calor. Aquesta calor s’ha d’extreure, cosa que consumeix més electricitat i, sovint, aigua. La GPU, a més, ja tenia un cost ambiental abans de transcriure res: extreure els materials, fabricar el xip, provar-lo, transportar-lo i instal·lar-lo. Quan d’aquí uns anys se substitueixi, aquest cost es tornarà a pagar.

L’impacte, per tant, apareix en moments molt diferents del cicle de vida, i cadascun té una lògica pròpia.

flowchart LR
    A["extracció i fabricació"] --> B["desplegament"]
    B --> C["inferència repetida"]
    C --> D["substitució"]
    D --> E["reutilització, reciclatge o residu"]
    C -.->|electricitat, aigua, calor| C

Dins d’aquest recorregut convé separar tres dimensions que sovint es confonen sota l’etiqueta genèrica d’impacte ambiental:

• Energia: el que consumeixen el càlcul i la refrigeració. És la magnitud més fàcil de mesurar i la que menys diu per si sola.
• Emissions: depenen de com s’ha generat aquesta energia i, per tant, de la ubicació i fins i tot de l’hora del dia. La mateixa computació té impactes climàtics diferents segons la xarxa que l’alimenta.
• Aigua: intervé en la refrigeració, en la generació elèctrica i en la fabricació de semiconductors. El seu pes depèn sobretot de si la zona pateix estrès hídric.

No són dimensions acumulables ni intercanviables, i sovint entren en conflicte: un sistema de refrigeració que estalvia aigua acostuma a gastar més electricitat. Optimitzar una sola mètrica gairebé sempre en desplaça el cost cap a una altra.

Hi ha, a més, una part del cost que ja està pagada abans d’engegar la màquina. És el cost incorporat (l’anglès en diu embodied): tot el que ha calgut per fabricar el dispositiu. En equips de consum i en dispositius petits, aquest cost pot arribar a ser comparable o superior al de tota la seva vida d’ús, perquè fabricar semiconductors és extraordinàriament intensiu en energia, aigua ultrapura i materials. La conseqüència pràctica és contraintuïtiva: allargar la vida d’un equip acostuma a estalviar més que substituir-lo per un de més eficient, tret que la diferència d’eficiència sigui molt gran i l’ús molt intens.

La inferència ja pesa més que l’entrenament

L’entrenament és un pic de computació enorme i concentrat, però es fa un cop. La inferència és petita i es repeteix milions de vegades. Durant anys el debat ambiental es va centrar en l’entrenament dels models frontera; les xifres del 2026 diuen que aquest enfocament ja no descriu la realitat.

Segons Gartner (agost del 2026), la despesa mundial en infraestructura al núvol optimitzada per a IA creixerà un 96% el 2026, fins als 42.000 milions de dòlars, i per primera vegada la inferència (23.300 milions) supera l’entrenament (19.000 milions). La previsió és que la inferència passi del 55% al 59% de la despesa el 2027. Una de les causes que s’hi apunten és l’auge dels sistemes agèntics, que multipliquen les crides al model per resoldre una sola petició d’usuari: un agent que raona en deu passos consumeix deu vegades més que una sola crida, i això no ho veu ningú des de fora.

Aquesta xifra descriu una tendència de despesa i de demanda de computació, no una auditoria directa d’emissions, aigua o energia. El pas que fem és inferir que, si la part operativa del sistema creix tant, també creix el pes ambiental de les decisions que la governen.

Això té una lectura directa per a nosaltres: la part de l’impacte que un equip de desenvolupament pot controlar és precisament la que està creixent. No entrenem models frontera, però sí que decidim quantes crides fa la nostra aplicació i amb quin model.

Per què no hi ha una xifra única

És temptador buscar el nombre que digui què costa una consulta. Aquest nombre no existeix, perquè depèn del model, de la llargada de l’entrada i de la resposta, del maquinari i de com d’ocupat està, del programari d’inferència, de la ubicació, de la refrigeració i de la modalitat. Dues xifres publicades poden diferir en un ordre de magnitud simplement perquè una inclou la fabricació del maquinari i l’altra no.

Això no vol dir que no es pugui mesurar res. Vol dir que qualsevol mesura només té sentit si diu què s’ha mesurat i respecte de què: kWh per quina tasca, litres per quin servei, grams de CO₂ en quina xarxa elèctrica. Una xifra sense aquest context és, en el millor dels casos, inútil.

Conclusió: raona en termes de recursos per tasca útil al llarg de tot el cicle de vida, no de consum instantani d’un model aïllat. I quan algú et doni una xifra, pregunta què hi ha inclòs.

On s’executa la tasca

Abans de decidir on s’executa una tasca convé saber sobre què s’executa, perquè el maquinari d’IA fa temps que va deixar de ser una sola cosa.

Quatre menes de processador, i un coll d’ampolla

La computació d’IA no depèn d’un sol tipus de processador, sinó d’una gradació que va de la flexibilitat a l’eficiència:

• GPU: processador molt paral·lel i programable. És el cavall de batalla de l’entrenament i de bona part de la inferència, i la seva virtut és que serveix per a gairebé tot.
• NPU: accelerador especialitzat en xarxes neuronals, integrat avui en telèfons i portàtils. Fa menys coses que una GPU, però les fa amb molta menys energia.
• ASIC: circuit dissenyat per a una classe concreta de tasques, com el Jalapeño d’OpenAI o les TPU de Google. És el més eficient i el menys flexible: si canvia el tipus de model, el xip es pot quedar obsolet abans d’espatllar-se.
• FPGA: maquinari reconfigurable. No arriba a l’eficiència d’un ASIC, però permet provar dissenys d’accelerador sense fabricar silici, i per això és habitual en recerca i en volums petits.

Com més especialitzat és el maquinari, més capacitat útil dona per watt i menys tolera els canvis. Aquesta tensió entre eficiència i flexibilitat és la mateixa que trobarem al programari quan haguem de triar entre un model generalista i un de petit especialitzat.

Hi ha, a més, una idea contraintuïtiva que convé tenir clara des del principi: en els models grans el coll d’ampolla no acostuma a ser el càlcul sinó la memòria. El que limita el sistema és quants paràmetres hi caben, a quina velocitat es poden llegir (l’amplada de banda) i què costa comunicar els acceleradors entre ells. Per això els sistemes moderns combinen acceleradors amb memòria d’alta amplada de banda (HBM) i xarxes internes molt ràpides, i per això les tècniques que redueixen la mida del model o el nombre de lectures de memòria tenen tant efecte sobre el consum. Un accelerador que espera dades consumeix energia sense produir res.

Del centre de dades al dispositiu

La computació d’IA s’ha estès al llarg d’un continu que es mesura per una sola cosa: la distància entre on es generen les dades i on es calcula.

Al dispositiu hi trobem NPU i acceleradors dissenyats per fer una tasca útil amb el mínim consum, no per maximitzar els FLOPS, i plataformes obertes com l’Open Edge Platform d’Intel empaqueten aquesta pila (OpenVINO i companyia) perquè no calgui reinventar-la a cada projecte. Aquí la petició no viatja: neix, es resol i mor al mateix aparell.

L’edge d’infraestructura sí que serveix peticions, i el serveix algú. Avui són sobretot les CDN, que ja tenien els edificis i la xarxa i només hi han hagut d’afegir acceleradors, i les operadores de telecomunicacions, que són les propietàries dels emplaçaments físicament més a prop de l’usuari. Convé una prevenció: bona part del que s’anuncia com a edge és el núvol un salt més a prop, amb el maquinari en una sala aliena però amb el programari, el control i l’economia en mans del mateix proveïdor de sempre.

El núvol permet executar models impossibles en un ordinador domèstic, però concentra el consum d’electricitat, aigua i materials en ubicacions concretes.

Aquest continu no s’ha de confondre amb una segona pregunta que hi va per sobre: de qui és la màquina. Quan diem que una tasca s’executa “en local” no estem dient a quina distància és, sinó que el maquinari el controlem nosaltres, i això pot passar a qualsevol nivell del continu. L’HP ZGX Nano, per exemple, és una estació d’1,25 kg amb un superxip GB10 i 128 GB de memòria unificada, capaç d’executar models de fins a 200.000 milions de paràmetres sense sortir de la taula; fa cinc anys allò era un rack. Un servidor propi a l’armari del centre és, alhora, edge per distància i local per propietat, i aquesta doble condició és la que el fa interessant: ni les dades ni la decisió surten de l’edifici.

L’eficiència real, però, no la determina només el processador. Entre l’aplicació i el silici hi ha una pila de capes (framework d’inferència, runtime, controlador) on es decideix si el maquinari s’aprofita o s’infrautilitza. Un servidor com vLLM que agrupa peticions i comparteix memòria pot atendre’n moltes més per watt que una execució ingènua sobre la mateixa GPU, i els proveïdors de núvol han arribat al mateix lloc des de l’altra banda: Google Cloud ja ofereix GPU fraccionades (mitja GPU, un quart, un vuitè) precisament perquè una GPU sencera dedicada a una tasca petita és maquinari llençat. Aquesta capa es tracta a Arquitectura de sistemes LLM, i triar-la és, de facto, una decisió ambiental.

On convé executar cada cosa

La pregunta útil no és “local o núvol” sinó on és més apropiat resoldre cada tasca. Aquests criteris cobreixen la majoria de casos:

El punt que costa més d’acceptar és l’últim. La intuïció diu que executar en local és més sostenible perquè no hi ha centre de dades pel mig, però una GPU domèstica que s’utilitza dues hores al dia arrossega el seu cost de fabricació sencer amb molt poca feina útil al damunt, mentre que la mateixa GPU en un centre de dades treballa gairebé sempre. Local vol dir més control i més privacitat; no vol dir automàticament menys impacte.

Aquesta taula serveix per decidir en temps de disseny, però la mateixa lògica es pot portar dins del sistema. En comptes de fixar un únic destí per a totes les peticions, un component barat pot classificar cada petició i encaminar-la al lloc i al model que li convenen: el que es resol amb regles o amb un classificador petit no arriba mai al model gran, el que és sensible es queda al dispositiu, i només el que ho necessita de veritat puja al núvol.

flowchart LR
    P["petició"] --> C{"classificador<br/>barat"}
    C -->|"cas senzill"| L["model petit<br/>al dispositiu"]
    C -->|"tasca especialitzada"| E["model especialitzat<br/>node proper o servidor propi"]
    C -->|"cas difícil"| N["model gran<br/>núvol"]
    L --> R["resposta"]
    E --> R
    N --> R

És el patró que a Orquestració amb workflows i agents apareix com a encaminament i cascada de models, i que allà es justifica per cost i latència. El mateix disseny que estalvia diners estalvia recursos, perquè totes dues coses mesuren el mateix: quanta computació has necessitat per resoldre el problema. La condició per aplicar-lo és tenir una avaluació que et digui quins casos resol el model petit; si no, l’encaminador acaba enviant-ho tot al model gran per prudència.

Conclusió: decideix el lloc d’execució segons el volum, la sensibilitat de les dades i la urgència, i tracta la utilització del maquinari com el factor que mana. Un accelerador ociós és car en tots els sentits.

La IA també és informàtica: mesures d’informàtica verda

Abans que existissin els LLM, la informàtica ja tenia un cos de pràctiques per reduir l’impacte dels sistemes, i la major part continua sent vàlida, perquè un centre de dades d’IA és un centre de dades. Val la pena conèixer-lo, entre altres coses perquè és el llenguatge amb què es negocia amb proveïdors i amb l’administració.

Les mètriques clàssiques i el que amaguen

• PUE (Power Usage Effectiveness): energia total de la instal·lació dividida per l’energia que arriba als equips informàtics. Un PUE d’1,5 vol dir que per cada watt de càlcul se’n gasta mig en refrigeració, alimentació i pèrdues. Les instal·lacions modernes ronden 1,1-1,2; les sales antigues estan clarament per sobre.
• WUE (Water Usage Effectiveness): litres d’aigua per kWh d’energia informàtica. És la mètrica que permet comparar refrigeracions, i la que menys empreses publiquen.
• CUE (Carbon Usage Effectiveness): emissions per unitat d’energia informàtica, que depèn sobretot de la xarxa elèctrica que alimenta la instal·lació.
• SCI (Software Carbon Intensity): un intent d’atribuir emissions a una unitat funcional de programari (per petició, per usuari), incloent-hi el cost incorporat del maquinari.

El parany d’aquestes mètriques és conegut i val la pena que el tinguis present: un centre de dades ple de GPU ocioses pot tenir un PUE excel·lent. El PUE mesura l’eficiència de l’edifici, no la utilitat del que s’hi calcula. Per això les mètriques d’instal·lació s’han de llegir sempre al costat de mesures de treball útil per unitat d’energia.

Pràctiques que s’apliquen igual a la IA

• Consolidació i dimensionament ajustat: agrupar càrregues en menys màquines i ajustar-ne la mida. Un servidor ociós no consumeix zero, sinó una fracció important del seu màxim, de manera que tenir maquinari de reserva és car en energia encara que no faci res.
• Planificació sensible al carboni: moure les càrregues ajornables a hores o regions on la xarxa és més neta. És aplicable a reindexacions, generació d’embeddings i processos per lots, i no requereix canviar ni una línia del model.
• Reaprofitament de la calor: connectar la calor residual a xarxes de calor urbanes o a processos industrials propers. Existeix i funciona, però condiciona molt on s’ubica la instal·lació.
• Refrigeració líquida i temperatures d’operació més altes: refrigerar menys, i millor, en comptes de refrigerar més. Amb els acceleradors actuals ha deixat de ser una opció exòtica.
• Eficiència del programari: llenguatges, estructures de dades i consultes tenen consum. Una consulta mal indexada o un bucle que copia dades sense necessitat gasta energia igual que una inferència, i sol ser molt més fàcil d’arreglar.
• Localitat de les dades: processar a prop d’on són les dades i evitar moure-les. Val per a la inferència al dispositiu i val per a un pipeline de dades mal dissenyat.
• Allargament de la vida útil: reparació, actualització i reutilització. És la mesura amb més impacte i la que menys s’aplica, perquè xoca amb el cicle comercial de renovació.
• Gestió del final de vida: reciclatge real i traçable dels residus electrònics, que a Europa regula la directiva RAEE.

També hi ha marc normatiu: la directiva europea d’eficiència energètica obliga els centres de dades a partir d’una certa mida a reportar periòdicament indicadors de consum d’energia i d’aigua, i el codi de conducta europeu per a centres de dades fixa bones pràctiques d’adhesió voluntària. La tendència reguladora és clara: passar de la publicitat ambiental a la declaració obligatòria.

Conclusió: abans d’optimitzar el model, mira si el problema és la instal·lació, la utilització o el codi que l’envolta. Molt del que cal fer per a una IA sostenible no té res d’específic de la IA.

Fer més amb menys, i per què no n’hi ha prou

Els models grans resolen coses que els petits no resolen, però la mida es paga en memòria, càlcul, energia i infraestructura. I moltes tasques reals (classificar, detectar, transcriure, resumir, transformar text) no necessiten un model frontera. Un model especialitzat, o directament un model clàssic, pot donar la mateixa qualitat amb dos ordres de magnitud menys de computació: aquesta decisió es tracta a LLM vs. ML tradicional.

Quan cal un model generatiu, hi ha un repertori de tècniques per abaratir la inferència. Totes comparteixen la mateixa idea i el mateix preu:

• Quantització: representar els pesos amb menys bits. Redueix memòria i transferència de dades, i sovint energia, a canvi d’una pèrdua de qualitat que cal comprovar. Ja no és només cosa de models locals: el maquinari de servidor recent treballa nativament en formats de 4 bits.
• Distil·lació: entrenar un model petit perquè imiti un de gran. Molt efectiva quan el domini és estret, poc útil quan es demana generalitat.
• Mescla d’experts: activar només una part dels paràmetres per cada token. Redueix el càlcul, però no la memòria necessària per allotjar el model.
• Decodificació especulativa: fer que un model petit proposi i un de gran validi. Accelera la resposta sense degradar-ne la qualitat, però requereix mantenir dos models.
• Memòria cau de context i de resultats: no tornar a calcular el que ja s’ha calculat. És l’optimització més avorrida i sovint la que més estalvia en aplicacions reals.

Els mecanismes es descriuen a Transformers i Models de Llenguatge. El que cal retenir aquí és que la capacitat no depèn linealment de la computació, i que gairebé sempre hi ha marge per baixar-la.

La mateixa lògica està arribant al silici, i és la que justifica els ASIC que hem esmentat abans. Quan OpenAI i Broadcom van presentar Jalapeño el 2026, l’argument no va ser que fes més multiplicacions per segon, sinó que redueix el moviment de dades i acosta la utilització real al màxim teòric, amb la promesa d’un rendiment per watt substancialment millor que el del maquinari de propòsit general. Aquest detall no és menor: en els acceleradors moderns, moure un byte de la memòria al processador pot costar més energia que operar-hi, i per això bona part de l’enginyeria d’eficiència consisteix a evitar viatges de dades i no a fer multiplicacions més ràpides.

D’aquí surt la regla de disseny més útil de tot el document: fes servir el model més petit que resolgui adequadament la tasca, i puja de model només quan una mesura et digui que el petit no arriba. Això obliga a tenir un llindar de qualitat definit abans de triar el model, que és exactament el que proposa Avaluació de sistemes LLM. Sense aquest llindar, la tendència natural és agafar el model més gran disponible per si de cas, que és la manera més cara de no haver de pensar.

La paradoxa de Jevons

Ara bé, l’eficiència no resol el problema per si sola. Quan una operació es fa més barata, se’n fan moltes més, i el consum agregat pot acabar creixent tot i que cada operació consumeixi menys.

flowchart LR
    A["eficiència ↑"] --> B["cost per operació ↓"]
    B --> C["ús ↑↑"]
    C --> D["consum total ↑?"]
    D -.-> A

No cal anar-ho a buscar gaire lluny. El mateix any que s’anuncien xips molt més eficients per watt, l’acord entre OpenAI i Broadcom parla de desplegar 10 GW d’acceleradors fins al 2029: una potència de l’ordre de la d’una desena de reactors nuclears grans. L’eficiència per operació i el consum total poden créixer alhora, i de fet és el que està passant.

Conclusió: l’eficiència tècnica només compta com a sostenibilitat si va acompanyada d’una decisió sobre el volum. Mesura el consum total, no només el consum per petició.

Consciència: saber què costa el que fem

Quan paguem una subscripció a un servei d’IA veiem un preu, i aquest preu tendeix a suggerir que aquí s’acaba el cost. Però hi ha una asimetria clara entre executar en local i executar al núvol. En local, l’electricitat apareix a la nostra factura, i aquesta factura és un senyal: si el consum puja, ho notem, i canviem de comportament. Al núvol, la petició desapareix dins d’una infraestructura on el consum d’electricitat, aigua i maquinari queda agregat amb el de milions d’usuaris. El servei ens diu que l’hem utilitzat; no ens diu quants recursos ha requerit.

Aquesta invisibilitat té un nom, externalització, i és la clau del problema ecològic: el que paguem no és el que costa. Hi entrem a fons a la secció següent, perquè és una qüestió d’una altra naturalesa que no es resol amb bon disseny.

La conseqüència de disseny és concreta i està a l’abast de qualsevol aplicació: el que es mesura i es mostra, es pot decidir. Una interfície que digui quin model ha respost, quants tokens ha consumit i quin cost aproximat té converteix una persona usuària passiva en algú que tria. Sense aquesta informació, demanar-li responsabilitat és retòrica. I el mateix val cap endins d’un equip: un tauler amb el cost per funcionalitat canvia les prioritats de desenvolupament molt més ràpid que una recomanació genèrica d’estalviar.

Per a un proveïdor, la mateixa exigència es tradueix en publicar energia, carboni, aigua, ubicació i metodologia de càlcul, perquè sense metodologia les xifres no són comparables entre empreses. Aquest punt és previ a tots els altres: sense dades comparables, ni els clients poden escollir ni la recerca pot avaluar res. I convé mirar amb atenció l’argument de les energies renovables: que una empresa compri electricitat renovable no vol dir que la seva demanda hagi generat nova capacitat neta, sinó que potser adquireix certificats mentre la xarxa que la subministra continua depenent d’altres fonts. La pregunta rellevant és l’addicionalitat: aquesta demanda ha fet créixer la generació renovable real, sí o no?

El bucle del senyal, i el seu límit

El mecanisme que hi ha al darrere és un bucle de retroalimentació ben conegut en economia de recursos: l’ús genera consum, el consum es tradueix en un preu que algú percep, i aquest preu modifica el comportament, que torna a afectar l’ús.

flowchart LR
    U["ús"] --> C["consum de recursos"]
    C --> P["preu percebut"]
    P --> B["comportament"]
    B --> U
    C -.->|"el senyal es perd"| X["cost agregat i invisible"]

La fletxa de punts és la part important: quan el cost s’agrega i s’externalitza, el bucle es trenca. No és que la persona usuària decideixi malament, és que no rep cap senyal a partir del qual decidir.

Ara bé, convé dir-ho amb totes les lletres: això és una hipòtesi de disseny, no una conclusió demostrada. Que fer visible el cost redueixi el consum és plausible i té precedents en altres àmbits (comptadors elèctrics amb informació immediata, indicadors de consum als vehicles), però no està establert per a la IA, i hi ha almenys dues raons per a la prudència:

• Apunta en direcció contrària a la paradoxa de Jevons. Si mostrar el cost fa que la gent trii models més petits i barats, l’operació es fa més barata i es pot acabar fent-ne moltes més. El senyal educa el comportament individual, però no fixa cap límit agregat.
• La magnitud del senyal és petita. El cost energètic d’una consulta és, per a qui la fa, gairebé imperceptible; és difícil que una xifra minúscula modifiqui un hàbit, tret que s’agregui i es presenti de manera comprensible.

La conclusió honesta és que la visibilitat del cost és una condició necessària però probablement insuficient: fa possible decidir, no garanteix que es decideixi bé. Per això aquest document no s’acaba en la consciència individual.

Aquesta prudència val també per a les xifres que fem servir per argumentar. Davant de qualsevol dada sobre l’impacte de la IA convé distingir què sabem, què estimem i què desconeixem: la recerca actual arrossega dades incompletes, metodologies incompatibles, poca transparència dels proveïdors i sistemes que canvien més de pressa del que triga a publicar-se un estudi. Dir “no ho sabem amb prou precisió” és una resposta científicament correcta, i molt més útil que repetir una xifra rodona d’origen desconegut.

Conclusió: com més visible és el cost per a qui pren la decisió, més probable és que la decisió sigui raonable. Mostrar el consum a la interfície i exigir metodologia als proveïdors són les dues cares de la mateixa idea, però cap de les dues no canvia el preu de res.

El cost que no és a la factura

Aquí hi ha el nucli ecològic del problema, i val la pena dir-lo sense embuts: una part important del cost ambiental de la IA no apareix en cap factura, ni en la de qui fa servir el servei ni en el compte de resultats de qui el ven.

Concretem-ho. Una consulta a un model gran costa unes dècimes de cèntim. Dins d’aquesta xifra hi ha l’electricitat que ha consumit el servidor, l’amortització del maquinari i el marge del proveïdor. No hi ha l’aigua evaporada en una conca amb estrès hídric, ni el reforç de xarxa elèctrica que ha calgut per alimentar la instal·lació, ni el cost climàtic de les emissions d’aquella electricitat, ni el residu electrònic que l’accelerador serà d’aquí a quatre anys. Aquests costos existeixen i els paga algú, però no els paga qui pren la decisió.

Per això convé distingir dues coses que la paraula “cost” confon:

• El cost privat és el que apareix a la factura: el que et cobren, o el que et costa fer-ho tu.
• El cost social és el cost privat més tot el que assumeixen tercers: la comunitat que acull la instal·lació, la conca que hi perd aigua, la xarxa elèctrica que s’ha de reforçar, el sistema de residus i, en el cas del clima, tothom.

Un servei pot ser molt barat per a l’usuari i molt car per a la societat. En economia ambiental això s’anomena una externalitat negativa, i té una conseqüència que no és una opinió: quan el preu no incorpora el cost, el mercat no hi pot arribar sol. No perquè les empreses siguin malèvoles, sinó perquè cap actor individual no té l’incentiu d’assumir voluntàriament un cost que els seus competidors no assumeixen; qui ho fes competiria en desavantatge.

Per què la transparència, sola, no ho arregla

Convé aturar-s’hi, perquè és fàcil confondre-ho amb la secció anterior. Mostrar els tokens i els cèntims d’una petició fa visible el cost privat, que és precisament el que ja pagues. Per construcció, no pot fer visible allò que no és a la factura. La consciència millora les decisions dins de les opcions existents, però no altera el preu de cap opció.

Perquè el cost social entri al preu cal una decisió col·lectiva. El principi de referència és antic i senzill:

qui genera un impacte n’ha d’assumir el cost.

I els instruments per aplicar-lo són coneguts, encara que la seva aplicació a la computació sigui recent:

• Posar preu al que ara és gratuït: les emissions i, en zones d’estrès, l’aigua. És el mecanisme que trasllada el cost al balanç de qui el genera, i el que fa que estalviar recursos i estalviar diners tornin a ser la mateixa cosa.
• Límits quantitatius: sostres d’aigua o de potència per emplaçament. Calen quan el recurs és físicament escàs i el senyal de preu arriba massa tard.
• Responsabilitat ampliada del productor i dret a reparació: que el cost del final de vida recaigui sobre qui fabrica i ven el maquinari, que és qui decideix si serà reparable.
• Repercussió del cost d’infraestructura: que la subestació, la línia o la conducció que necessita una instal·lació les pagui l’empresa que les necessita, i no la comunitat que l’acull.
• Declaració obligatòria amb metodologia comparable: no internalitza cap cost per si mateixa, però sense ella no es pot aplicar cap dels instruments anteriors.

Límits que no es compren

I encara hi ha un pas més enllà del preu. Alguns límits no són econòmics sinó físics: en una conca en sequera no hi ha cap preu que faci aparèixer l’aigua, i una xarxa elèctrica té una capacitat que no es negocia. Quan es toca un d’aquests límits, la pregunta deixa de ser quant costa i passa a ser qui té prioritat, cosa que ja no decideix cap mercat.

D’aquí surt la premissa ecològica d’aquest document: no tota demanda tecnològica ha de ser satisfeta. La disponibilitat de recursos físics és finita, i això val també per a la computació, per molt immaterial que sembli.

Conclusió: la consciència fa visible el cost privat; només una decisió col·lectiva posa el cost social dins del preu. Sense aquest pas, tota la resta (models més petits, millor utilització, maquinari més durador) fa més eficient un sistema que continua sense pagar el que consumeix.

Codi obert i maquinari obert

Aquesta secció és el nucli de la part democràtica del document. L’obertura no és aquí una preferència ideològica sinó una propietat que determina qui pot decidir, qui pot comprovar i durant quant de temps un aparell continua sent útil.

Quatre nivells que no s’han de confondre

El terme “obert” s’aplica avui a coses molt diferents, i barrejar-les porta a conclusions equivocades:

1. Pesos disponibles (open weights): pots descarregar i executar el model. És el nivell més estès i el que més canvia la pràctica quotidiana.
2. Codi obert de veritat: a més dels pesos, el codi d’entrenament i inferència amb una llicència lliure. La definició d’IA de codi obert de l’OSI hi afegeix informació suficient sobre les dades perquè algú altre pugui reproduir el procés.
3. Dades i procés reproduïbles: saber amb què s’ha entrenat i poder repetir-ho. Gairebé ningú no hi arriba, i és el que separa auditar de confiar.
4. Maquinari obert: especificacions, dissenys i controladors accessibles. És el nivell menys madur i el que més condiciona la vida útil dels equips.

L’agost del 2026 tenim exemples vius del primer nivell: Meta ha alliberat Muse Glimmer, un model de 30.000 milions de paràmetres pensat per executar tasques agèntiques en un Mac o un PC amb una sola targeta gràfica, versió oberta del seu model tancat més potent; i bona part de l’empenta en models oberts ve de la Xina (Kimi, Qwen, DeepSeek). Que un model capaç càpiga en una màquina de sobretaula canvia radicalment qui pot fer-lo servir, estudiar-lo i auditar-lo.

La pila, capa a capa

Val la pena mirar on hi ha alternativa oberta i on no, perquè cada capa tancada és un punt on algú altre decideix per tu:

Per què això és una qüestió ambiental

L’argument no és abstracte i té tres potes molt concretes:

• Vida útil. El motiu més habitual pel qual un equip perfectament funcional acaba com a residu no és que s’espatlli, sinó que el fabricant deixa de publicar controladors per als sistemes operatius nous. Amb controladors lliures, la comunitat pot mantenir viu aquell maquinari anys més. Cada any addicional de vida amortitza el cost incorporat de fabricació entre més feina útil.
• Reparació i reutilització. Dissenys documentats i components estandarditzats (la idea que hi ha darrere de l’Open Compute Project) permeten substituir una peça en comptes de tot el conjunt, i donen sentit a un mercat de segona mà que d’altra manera no existeix.
• Portabilitat. Si el teu sistema només funciona sobre una pila propietària, la teva única opció quan aquell proveïdor puja preus, canvia condicions o discontinua un model és migrar-ho tot. Amb formats i runtimes oberts pots moure la mateixa càrrega al maquinari que en aquell moment sigui més eficient, o al lloc on l’electricitat sigui més neta.

El que l’obertura no resol

Convé ser honestos, perquè aquí és fàcil caure en l’entusiasme:

• Obert no vol dir descentralitzat. La mateixa setmana d’agost del 2026, IBM i Together AI van signar un acord de 240 milions de dòlars per construir un clúster d’unes 2.000 GPU Blackwell dedicat, precisament, a servir models de codi obert. Els pesos són lliures; la infraestructura que els fa útils a escala continua sent enorme, cara i propietat d’algú.
• Obert no vol dir eficient. Duplicar models, reentrenaments i infraestructures per tot el món pot augmentar el consum global respecte d’un servei compartit ben aprofitat.
• Obert no vol dir auditable. Sense dades ni procés, uns pesos publicats es poden inspeccionar però no reproduir.
• El maquinari obert encara és minoritari. RISC-V avança de pressa en microcontroladors i acceleradors petits, però els acceleradors d’IA d’alt rendiment continuen sent, a la pràctica, un mercat tancat i molt concentrat.

Conclusió: l’obertura no garanteix sostenibilitat, però és la condició que fa possible triar, i sense alternativa real no hi ha ni consciència útil ni decisió democràtica. En termes ambientals, la capa que més impacte té no és el model sinó els controladors i els dissenys, perquè són els que decideixen quan un aparell es converteix en residu.

Democràcia: qui decideix sobre la computació

Fins aquí hem vist com es fa la computació i on es fa, i com una elecció de model o de runtime es transforma en consum de maquinari, energia i aigua. La pregunta següent és diferent, i ja no és tècnica: qui controla la infraestructura que fa possible tota aquesta feina? Una persona pot triar el model i la freqüència d’ús, però no pot decidir quanta aigua consumeix un centre de dades, on s’instal·la, ni si la xarxa elèctrica es reforça per a ell o per a altres usos. Un centre de dades pot requerir una potència comparable a la d’una ciutat, i en zones amb estrès hídric la seva refrigeració competeix amb usos bàsics.

D’aquí surt una asimetria que convé no oblidar: posar tot el pes de la sostenibilitat sobre qui consumeix és, a la pràctica, no fer res. Les palanques que de veritat mouen l’agulla ja han anat sortint al llarg del document (la utilització dels acceleradors, la refrigeració i el reaprofitament de la calor, la planificació de càrregues segons l’energia disponible, la vida útil del maquinari), i totes tenen una cosa en comú: qui les pot accionar és qui opera la infraestructura, no qui la fa servir. Una persona usuària conscient pot triar entre les opcions que li ofereixen; no pot crear-ne de noves.

Els instruments de la secció anterior tenen tots la mateixa característica: són decisions col·lectives, i cap consumidor no les pot prendre per informat que estigui. Algú ha de decidir si aquella instal·lació es construeix, on, amb quina aigua, amb quina prioritat sobre la xarxa i qui en paga l’accés. La pregunta ecològica desemboca, inevitablement, en una pregunta sobre qui té la potestat de decidir.

La computació com a servei públic

Fins aquí l’administració apareix només com a àrbitre: posa límits, exigeix dades, avalua impactes. Però hi ha una altra manera d’intervenir-hi, que és oferir la computació directament.

Ja existeix, i a prop. El Barcelona Supercomputing Center allotja una de les primeres set AI Factories europees, construïda sobre el MareNostrum 5 amb un pressupost de 129 milions d’euros finançat a mitges entre EuroHPC i el consorci format pel govern espanyol, la Generalitat, Portugal i Turquia. L’objectiu declarat és exactament l’argument democràtic: donar accés a capacitat de càlcul a pimes, empreses emergents, grups de recerca i administracions que mai no la podrien comprar. L’accés és per trams, des d’un nivell de proves fins a assignacions de més de 50.000 hores de GPU, i gratuït per a pimes en modalitat d’innovació.

El model no és nou: és el de la biblioteca i el de la xarxa científica. Un recurs car que ningú no pot pagar individualment es comparteix, i s’assigna segons criteris públics en comptes de segons qui pugui pagar més. A Catalunya fa anys que funciona així amb el CSUC i l’Anella Científica per a les universitats.

Convé, però, no confondre dues coses:

• Compartit no vol dir distribuït. Una AI Factory és computació pública, però centralitzada: continua sent un centre de dades gran. L’edge públic de proximitat, node a node en cada municipi, pràcticament no existeix, i el motiu no és ideològic sinó el de sempre: un node municipal utilitzat el 5% del temps repeteix l’error de la GPU domèstica, però amb diners públics. El que fa eficient la computació pública és compartir-la, no multiplicar-la.
• Públic no vol dir sobirà. Cal mirar de qui és el maquinari i qui controla la pila de programari. La mateixa ampliació del MareNostrum 5 la construeix un consorci industrial privat, cosa que no té res d’escandalós, però recorda que l’etiqueta de públic s’ha de comprovar capa a capa amb els criteris de la secció anterior.

I hi ha una virtut que sol passar desapercebuda. Quan la computació es compra, el preu decideix qui l’obté i ningú no ha de justificar res. Quan és pública, algú ha d’escriure els criteris d’assignació, i això obliga a fer explícita una decisió que altrament queda amagada dins d’un mercat.

Conclusió: la responsabilitat s’ha de repartir en proporció a la capacitat d’actuar. La consciència individual és necessària però insuficient; el que la fa efectiva és tenir alternatives reals (obertura) i regles comunes (regulació).

Camins d’actuació

Les dues idees del document es tradueixen en coses que es poden fer, segons el paper que hi tinguis.

Si desenvolupes sistemes:

• Comprova si cal un LLM. És la decisió amb més impacte de totes i es pren al principi.
• Defineix un llindar de qualitat mesurable abans de triar el model, i queda’t amb el més petit que l’assoleixi.
• Instrumenta tokens, latència i cost per petició des del primer dia, com es descriu a Sistemes LLM en producció: el que no es mesura no es pot reduir.
• Posa memòria cau a tot el que es repeteixi, que en aplicacions reals sol ser molt més del que sembla.
• Prefereix una GPU compartida i ben aprofitada a diverses GPU mig ocioses, encara que sembli menys còmode.
• Posa a la cua i agrupa les càrregues que no siguin interactives, i executa-les quan la xarxa elèctrica sigui més neta si el proveïdor t’ho permet triar.
• Tria formats i runtimes portables (ONNX, GGUF, vLLM) per no quedar lligat a un sol fabricant ni a una sola generació de maquinari.
• Mostra el cost de la petició a la interfície quan tingui sentit: és la manera més directa de convertir una persona usuària en algú que decideix.

Si decideixes per una organització:

• Demana dades d’energia, aigua, ubicació i metodologia als proveïdors, i fes que pesin en la comparació d’ofertes; si no les donen, això també és informació.
• Comptabilitza el cost incorporat del maquinari que compres i allarga’n la vida en comptes de renovar per defecte: reparació, ampliació de memòria, segona vida en tasques menys exigents.
• Valora el suport de controladors lliures en la compra, perquè determina quants anys serà utilitzable l’equip.
• Revisa periòdicament si els models que fas servir continuen sent els més petits que resolen el problema, perquè els models petits milloren molt de pressa i el que fa un any exigia un model gran potser ja no.
• Valora la dependència, no només el preu: un model obert executat en una infraestructura que pots canviar et deixa marge de decisió que un servei tancat no et deixa.

Com a societat, queden les peces que cap decisió de compra no resol, i que són les que de veritat posen el cost ambiental dins del preu: posar preu a les emissions i, on calgui, a l’aigua; l’obligació de transparència amb metodologia comparable; l’avaluació d’impacte de les infraestructures noves; els límits en zones amb estrès hídric; la responsabilitat del fabricant sobre el final de vida del maquinari; el suport a estàndards i maquinari oberts com a política industrial; i el repartiment del cost de la infraestructura entre l’empresa que la necessita i la comunitat que l’acull.

Preguntes obertes

Algunes qüestions no tenen encara una resposta consolidada i val la pena discutir-les:

1. Si l’eficiència per operació millora però es despleguen 10 GW d’acceleradors nous, què vol dir exactament “IA més eficient”?
2. Hauria de mostrar tot servei d’IA una estimació del consum de cada petició, i hauria de pagar més qui consumeix més recursos?
3. Democratitza res un model obert si per servir-lo a escala calen clústers de milers de GPU que només unes poques empreses poden pagar?
4. Hauria de ser el suport de controladors lliures un requisit en la compra pública de maquinari, com a mesura contra l’obsolescència programada?
5. Qui hauria d’assumir el cost de la infraestructura elèctrica i hídrica que necessiten els centres de dades nous?
6. Qui decideix què és un ús necessari de la IA, i té sentit posar un límit al creixement d’aquesta infraestructura?

Una IA sostenible no és només una IA que consumeix menys energia. És una IA en què l’eficiència, la transparència, la responsabilitat, la sobirania tecnològica i el cost ambiental formen part del disseny del sistema.

Referències

Les dades concretes d’aquest document corresponen a l’estiu del 2026 i caduquen de pressa; el que no caduca és la manera de llegir-les.

• Gartner: la despesa en IaaS optimitzada per a IA creixerà un 96% el 2026, amb la inferència superant l’entrenament per primera vegada.
• OpenAI i Broadcom presenten Jalapeño, un ASIC específic per a inferència, i el pla de desplegar 10 GW d’acceleradors.
• Meta llança Muse Glimmer, un model obert de 30B pensat per executar-se en una màquina personal.
• IBM i Together AI construeixen un clúster d’inferència de 240 milions de dòlars per servir models oberts.
• Google Cloud: infraestructura d’IA i GPU fraccionades, un exemple de com s’ataca la infrautilització del maquinari.
• Intel Open Edge Platform, pila oberta per a inferència a l’edge.
• HP ZGX Nano AI Station, exemple de fins on arriba avui l’execució local.
• AMD: infraestructura i programari d’IA, sobre la convergència entre entorns locals i de núvol.
• El BSC allotja una de les set primeres AI Factories europees i les modalitats d’accés d’EuroHPC, un exemple de computació pública compartida.
• Cloudflare Workers AI, inferència servida des dels punts de presència de la xarxa, com a exemple d’edge d’infraestructura.
• Open Compute Project, dissenys oberts de servidors, racks i refrigeració per a centres de dades.
• Definició d’IA de codi obert de l’OSI, sobre què cal per poder dir que un model és realment obert.
• Green Software Foundation: Software Carbon Intensity, especificació per atribuir emissions a una unitat funcional de programari.