Economia dels models fundacionals: com desplegar IA sense tenir cap laboratori frontera

La Stanford Emerging Technology Review 2026 posa números a una cosa que la majoria d'equips de producte fa dos anys que intueixen sense acabar de concretar: els models fundacionals són un objecte d'una altra mena que el programari que desplegàvem fins ara, i l'economia que tenen al darrere condiciona totes les decisions que venen després.

He llegit l'informe des del seient de qui construeix, no des del de l'analista. La pregunta que m'importa no és qui guanyarà la cursa de la frontera: és què implica aquesta economia per als equips que despleguen funcionalitats d'IA sense tenir laboratori, perquè és aquí on passo les hores de feina.

Algunes de les xifres que val la pena retenir:

• La base d'entrenament de GPT-4 era, en text, l'equivalent d'uns 100 milions de llibres — al voltant de 10 bilions de paraules.
• L'entrenament va fer servir uns 25.000 xips Nvidia A100 durant ~100 dies, a prop de 10.000 dòlars per xip només en maquinari.
• Electricitat de la fase d'entrenament d'un model de la classe de GPT-4: ~50 milions de kWh, l'energia anual d'unes 4.500 llars nord-americanes.
• Inferència per consulta a ChatGPT: ~2 Wh — per 0,3 Wh d'una cerca a Google i els 2 Wh que conté una pila AAA.
• Mercat global d'IA projectat en 244,22 mil milions de dòlars per al 2025. La inversió privada en IA va tocar els 150,79 mil milions el 2024, amb 33,94 mil milions només en IA generativa.
• Goldman Sachs estima que una IA generativa adoptada de manera àmplia podria afegir ~7 bilions de dòlars al PIB global i 1,5 punts percentuals al creixement de la productivitat en una dècada.

Si construeixes productes sobre aquests models, tres d'aquestes xifres pesen més que la resta: el cost d'inferència per consulta, la trajectòria d'aquest cost a mesura que es generalitzin els models de raonament, i la velocitat amb què les alternatives open-weight escurcen la distància de capacitats.

L'entrenament no és el teu problema. La inferència, sí.

Gairebé ningú que llegeixi aquest post no entrenarà mai un model frontera. L'economia ho fa inviable fins i tot per a un «grup d'una mida raonable de les millors universitats de recerca dels EUA» — la formulació és del mateix informe de Stanford —, no diguem ja per a una sola empresa mid-market. La pregunta interessant no és «hauríem d'entrenar un model fundacional?», sinó «com fem la inferència a un cost unitari que no ens mati el model de negoci?»

L'informe de Stanford hi apunta una cosa que aquí és clau: els models de raonament — models fundacionals que «pensen» els problemes pas a pas abans de respondre — han encarit substancialment la inferència durant l'últim any. I no és cap nota a peu de pàgina. Un producte amb un preu calculat sobre el supòsit que una consulta d'usuari equival a una crida al model ara ha d'assumir que aquella consulta pot equivaler a desenes de crides internes, més invocacions d'eines, més reintents. L'economia unitària d'«una consulta, una resposta» no serveix per a càrregues agèntiques i de raonament.

Què vol dir això, a la pràctica:

• Deixa de posar preu a les funcionalitats d'IA sobre el cost d'inferència per token com si fos estable. Les cadenes de raonament, els bucles agèntics i les entrades multimodals fan saltar aquest supòsit pels aires. Posa el preu sobre el valor per a l'usuari, amb prou marge perquè la inferència s'encareixi.
• Incorpora l'observabilitat de costos al sistema des del primer dia. Necessites telemetria del cost d'inferència per funcionalitat, per usuari i per tenant. Si no pots respondre «quant ens costa aquest usuari aquest mes?», no pots operar el negoci.
• Tracta la destil·lació i els fallbacks a models petits com a feina d'enginyeria de primer ordre. L'informe descriu explícitament la destil·lació — comprimir models grans en models més petits i ràpids — com una de les direccions clau. Els equips capaços d'encaminar les consultes fàcils a un model petit i reservar el model frontera per a les difícils operaran a la meitat del cost d'inferència dels que no ho facin.

L'open-weight és real. Tracta'l com una decisió de procurement.

L'informe cita els líders evidents — tancats (GPT, Claude, Gemini), open-source/open-weight (Llama 4, Gemma 2, Command R) — i hi afegeix una cosa menys evident: les publicacions open-source de DeepSeek estan accelerant l'adopció global i soscavant els esforços de contenció dels EUA. Pensis el que pensis de la geopolítica, la implicació d'enginyeria és neta: la distància entre els models tancats de frontera i els open-weight solvents s'escurça prou de pressa perquè triar un únic proveïdor de model tancat com a fonament arquitectònic del producte sigui un risc de procurement, no només tècnic.

L'argument contrari mereix que el prenguem seriosament: els models tancats de frontera encara van per davant en les tasques més difícils, i si fas un prototip, agafar la millor API i desplegar és la decisió correcta. El risc no és fer servir un model tancat: és construir de manera que no puguis deixar de fer-ho mai.

Dissenya amb tres coses al cap:

1. Abstracció de proveïdor. Tots els camins de prompt del sistema haurien de poder canviar de model subjacent. El lock-in via formats de tool-calling propis d'un SDK, embeddings propis d'un proveïdor o filtres de seguretat propis d'un proveïdor és deute tècnic amb el preu posat.
2. Nivells de capacitat. Classifica els prompts segons com de capaç ha de ser el model que els atén. La majoria de prompts de la majoria de productes no necessiten la frontera. Els equips que ho resolen s'estalvien milions cada any.
3. El self-hosted com a opció real. Si les dades són sensibles, el volum és alt i els requisits de latència són estrictes, un model open-weight afinat sobre la teva pròpia infraestructura és una opció creïble — no pas un projecte de recerca.

El cost ocult: les dades, no la computació

L'informe ho diu sense embuts: «Els guanys futurs de la IA dependran cada cop més no només d'una gran capacitat de càlcul i de grans volums de dades, sinó també de dades específiques de domini i d'innovacions centrades en l'eficiència.»

Torna-la a llegir, perquè per als equips de producte és la frase més important de tot el capítol. Els proveïdors de models frontera ja s'han empassat tot el que hi ha publicat a internet. La pròxima ronda d'avantatge competitiu sortirà de les dades específiques de domini que els proveïdors de frontera no tenen.

Si treballes en un sector regulat, especialitzat o carregat de dades pròpies — legal, salut, serveis financers, sistemes industrials, comerç regional —, el teu fossat són les dades, no el model. La feina d'enginyeria que se'n deriva:

• Generació de dades sintètiques. L'informe assenyala les dades sintètiques — generades artificialment per imitar les propietats estadístiques de les reals — com a resposta a l'escassetat de dades reals. Avui és una competència d'enginyeria normal, no pas recerca exòtica.
• Fine-tuning per davant del prompting. La majoria d'equips abusen dels prompts i inverteixen massa poc en fine-tuning. Per a tasques de domini repetitives, un model petit afinat guanya un model frontera amb prompts en cost, latència i consistència.
• RAG ben fet. La generació augmentada amb recuperació és l'opció per defecte, però la majoria d'implementacions són l'MVP d'algú reciclat de qualsevol manera. Un RAG de debò demana bancs d'avaluació, ajust de la recuperació i una cura contínua de les dades. Els equips que s'ho prenen seriosament treuen productes que funcionen; els que no, treuen demos.

On queden els equips d'enginyeria mid-market

Si ets CTO o fundador i desplegues funcionalitats d'IA sense pressupost de laboratori frontera, el marc de Stanford deixa el playbook més clar que fa un any. Jo faria això:

1. No entrenis. Destil·la, afina, encamina.
2. No et deixis tancar. Abstracció de proveïdor, nivells de capacitat i opcions self-hosted a punt.
3. Inverteix en dades. Dades de domini, dades sintètiques, bancs d'avaluació, infraestructura RAG.
4. Mesura el cost d'inferència per usuari, per funcionalitat i per tenant. Els equips que operin així duraran més que els que no.

On encaixa Conectia

Vam construir Conectia a partir d'una observació: els enginyers capaços d'operar dins d'aquest playbook són una població diferent dels «enginyers que saben fer anar el ChatGPT». Les habilitats se solapen amb l'enginyeria sènior clàssica — disseny de sistemes, observabilitat, disciplina de costos, seguretat — i hi afegeixen una capa de criteri específic d'IA: quan val la pena afinar un model i quan n'hi ha prou amb un bon prompt, quan basta un model petit, com escriure avaluacions que cacin regressions, com abstraure els proveïdors sense caure en la sobreenginyeria.

Els nostres enginyers nearshore passen una validació de cinc pilars que inclou la competència en IA, amb una avaluació explícita d'aquestes decisions — no un simple «has fet servir el Copilot?». Si construeixes funcionalitats d'IA i al teu equip li falta aquesta capa de criteri, aquest és exactament el buit que vam néixer per cobrir. Mira com funciona la validació.

L'economia dels models frontera no quadrarà amb el teu full de ruta fins que la teva cultura d'enginyeria tracti el cost d'inferència, la qualitat de les dades i la portabilitat de proveïdor com a qüestions de primer ordre. I això és un problema de contractació abans que un problema d'eines.