L'ecosistema de LLMs evoluciona a una velocitat vertiginosa: els models concrets que avui lideren els rànquings poden estar superats d'aquí a uns mesos. Per això aquesta lliçó no pretén donar-te "el millor model" (qualsevol rànquing que memoritzessis caducaria de seguida), sinó una cosa molt més duradora: un marc de criteris per avaluar i comparar models, un mapa dels principals proveïdors i famílies, i una metodologia de decisió que podràs aplicar avui i d'aquí a dos anys. Al final l'aplicarem al cas que ens ocupa: triar l'enfocament de model per a DocuBot, l'assistent de documentació de Nubelia.

1. Els cinc criteris per comparar models
2. Panorama de proveïdors i famílies de models
3. Models propietaris via API vs. models oberts autoallotjats
4. Famílies i mides: no hi ha "un" model per proveïdor
5. Com triar: metodologia aplicada a DocuBot

Quan avaluïs qualsevol model — actual o futur — aquestes són les cinc dimensions que has de mirar. Interioritza-les: les fitxes tècniques dels proveïdors es llegeixen soles quan saps què hi has de buscar.

Com de bé resol el model les tasques que t'importen? Compte amb el matís: les tasques que t'importen, no "en general". Un model pot ser brillant raonant sobre codi i mediocre redactant en català, o a l'inrevés.

• Els proveïdors publiquen resultats en benchmarks estàndard (exàmens de coneixement, programació, raonament). Són útils com a primer filtre, però saturen (molts models freguen el màxim) i no reflecteixen el teu cas concret.
• L'única avaluació fiable és provar el model amb els teus propis casos: en el cas de Nubelia, amb preguntes reals de suport i fragments reals de la seva documentació. A la lliçó 02-04 i al mòdul 6 veurem com sistematitzar aquesta avaluació.

Quant text (en tokens, com vam veure a la lliçó 01-02) pot gestionar el model en una sola crida, sumant entrada i sortida. Determina quanta documentació, historial de conversa o instruccions hi pots incloure. Les finestres actuals van des de desenes de milers fins a milions de tokens segons el model — però compte: una finestra enorme no és gratis (més tokens = més cost i latència) ni garanteix que el model faci servir bé tot el que li passes (ho matisarem a la lliçó 01-04).

Els models via API es facturen per token, amb preus diferents per als tokens d'entrada i de sortida (la sortida sol ser diverses vegades més cara). Els preus concrets canvien sovint; el que no canvia és l'estructura:

Entre el model més capaç i el més econòmic d'un mateix proveïdor hi pot haver un o dos ordres de magnitud de diferència de preu. Per això la pregunta correcta mai no és "quin model és millor?" sinó "quin és el model més barat que resol la meva tasca amb la qualitat que necessito?". (La gestió operativa de costos — caching, optimització — es tracta en detall a la lliçó 03-04.)

Quant triga el model a respondre. Convé distingir dues mètriques:

• Temps fins al primer token: quant espera l'usuari abans de veure alguna cosa. Crític en interfícies conversacionals (per això existeix el streaming, que veurem a la lliçó 03-02).
• Velocitat de generació (tokens per segon): quant triga a completar-se la resposta.

Regla general: els models més grans i capaços són més lents i cars; els petits, més ràpids i barats. Per a un xat interactiu com DocuBot la latència importa molt; per a un procés nocturn que resumeix tiquets, gairebé gens.

Més enllà del text: accepta imatges o PDFs com a entrada (visió)? Àudio? Suporta function calling (mòdul 5) i sortides estructurades (lliçó 02-03)? Ofereix modes de raonament estès per a problemes complexos? No tots els models ho ofereixen tot, i si el teu cas necessita, per exemple, interpretar captures de pantalla adjuntes a tiquets, això es converteix en un criteri eliminatori.

Vegem els actors principals de l'ecosistema. Descripció deliberadament atemporal: retén qui és qui i què caracteritza cadascun, i consulta els seus webs per als detalls del moment.

• Anthropic — família Claude. Models propietaris accessibles via API, amb un fort focus en fiabilitat, seguretat i capacitats d'assistent per treballar amb codi i documents llargs. La família s'organitza en esglaons de capacitat/cost (tradicionalment amb noms com Opus, Sonnet i Haiku, de més gran a més petit).
• OpenAI — família GPT (i derivats). El proveïdor que va popularitzar els LLMs conversacionals. Models propietaris via API, gamma àmplia que cobreix des de models lleugers fins a models de raonament avançat, i un ecosistema d'eines molt extens.
• Google (DeepMind) — família Gemini. Models propietaris integrats a l'ecosistema de Google Cloud, històricament forts en multimodalitat (text, imatge, àudio, vídeo) i en finestres de context molt grans.
• Meta — família Llama. El gran impulsor dels models de pesos oberts: models que pots descarregar i executar a la teva pròpia infraestructura. Han creat un ecosistema enorme de variants i afinats per part de la comunitat.
• Mistral AI. Companyia europea (francesa) que combina models oberts i models comercials via API. Rellevant a més per consideracions de sobirania de dades europees.
• Altres actors que convé conèixer: DeepSeek i Qwen (Alibaba) com a famílies obertes molt competitives d'origen xinès; Cohere, orientat a empresa; i els proveïdors de plataforma — AWS Bedrock, Google Vertex AI, Azure AI Foundry — que no creen els models principals però els ofereixen dins del seu núvol, amb la facturació, la seguretat i el compliment normatiu integrats a la teva infraestructura existent.

Tres observacions transversals més útils que qualsevol rànquing:

1. Tots els grans proveïdors ofereixen una gamma, no un model. Cada família té esglaons (gran/mitjà/petit) amb el mateix estil d'API.
2. La frontera de qualitat es mou constantment i convergeix. El líder d'avui és atrapat en qüestió de mesos. Dissenya la teva aplicació per poder canviar de model amb facilitat (bona abstracció de la capa LLM, avaluacions pròpies que es puguin re-executar contra un model nou).
3. Les APIs són conceptualment molt similars (missatges amb rols, paràmetres com temperature, streaming, eines), de manera que el que aprenguis en aquest curs amb un proveïdor es transfereix gairebé directament als altres. Els detalls pràctics d'integració els veurem al mòdul 3.

La decisió més estructural no és "quin proveïdor" sinó quin model de desplegament: consumeixo un model propietari com a servei, o descarrego un model obert i l'executo a la meva infraestructura?

Matisos importants que la taula no captura:

• "Obert" gairebé sempre vol dir "de pesos oberts" (pots descarregar i executar el model), no que les dades d'entrenament o el procés siguin públics. Revisa sempre la llicència: algunes permeten ús comercial sense restriccions i d'altres imposen condicions.
• Hi ha una via intermèdia molt popular: consumir models oberts a través d'un proveïdor d'inferència que els serveix via API. Obtens preus sovint baixos i zero infraestructura, a canvi que les dades sí que surten del teu perímetre. I la via de plataforma (Bedrock, Vertex, Azure) ofereix models propietaris dins del teu marc de núvol i compliment.
• El cost de l'autoallotjament es subestima sistemàticament. No és només la GPU: és la disponibilitat, les actualitzacions, l'optimització d'inferència, l'observabilitat i el personal que ho manté.

Regla pràctica honesta: per a la gran majoria d'equips que comencen, l'API propietària (o de plataforma) és el punt de partida correcte — iteres ràpid, sense inversió, amb la millor qualitat. L'autoallotjament es justifica amb requisits estrictes de residència de dades, volums molt alts i sostinguts, o necessitats de personalització profunda.

Mereix secció pròpia perquè és una decisió que prendràs constantment: dins del proveïdor triat, quin esglaó de la gamma fas servir?

• Model gran (frontera): màxima capacitat de raonament i fiabilitat; més car i lent. Per a tasques complexes, ambigües o on l'error és car.
• Model mitjà: el cavall de batalla. Equilibri qualitat/cost/latència adequat per a la majoria d'aplicacions — chatbots, RAG, processament de documents.
• Model petit: molt ràpid i barat. Per a tasques simples i de gran volum: classificar, extreure camps, enrutar peticions.

I una idea d'arquitectura que veuràs en sistemes madurs: no has de triar-ne només un. Un mateix producte pot combinar esglaons segons la subtasca:

Aquest patró d'enrutament per complexitat redueix cost i latència sense sacrificar qualitat allà on importa. El reprendrem en parlar de costos (lliçó 03-04).

Tanquem amb una metodologia de cinc passos, aplicant-la a la decisió que Nubelia ha de prendre per a DocuBot.

Pas 1 — Defineix els requisits del cas d'ús. Per a DocuBot:

• Usuaris: ~200 empleats interns (desenvolupadors i suport). Volum moderat: potser uns quants centenars de preguntes al dia.
• Tasca: respondre preguntes en català (i potser altres idiomes) basant-se en documentació tècnica que se li passarà com a context.
• UX: xat interactiu → la latència percebuda importa.
• Dades: la documentació interna és confidencial, però no conté dades personals de clients → una API amb garanties contractuals adequades (no entrenar amb les dades, retenció limitada) és acceptable per a Nubelia; no hi ha requisit dur d'autoallotjament.
• L'error és tolerable però molest: una resposta incorrecta fa perdre temps, no diners directament.

Pas 2 — Filtra per criteris eliminatoris. Necessita: bon maneig del català, finestra de context suficient per a diversos fragments de documentació més l'historial, i (de cara als mòduls 4 i 5) bon suport de sortides estructurades i function calling. No necessita: visió, àudio, finestra gegant.

Pas 3 — Decideix el model de desplegament. Equip petit, sense experiència a servir models, volum moderat, sense requisit de residència estricta → API gestionada. Revisar els termes de tractament de dades del proveïdor és part de la decisió, no un tràmit posterior (hi aprofundirem a la lliçó 06-02).

Pas 4 — Tria l'esglaó, no només el proveïdor. Hipòtesi inicial raonable: model mitjà d'un proveïdor principal per a la generació de respostes. És una hipòtesi, no un compromís: l'arquitectura ha de permetre canviar-lo.

Pas 5 — Valida amb una avaluació pròpia i deixa la porta oberta. Abans de comprometre's, l'equip de Nubelia hauria de preparar 30–50 preguntes reals amb les seves respostes correctes conegudes i provar-hi 2–3 models candidats. Aquest conjunt d'avaluació, a més, es converteix en un actiu permanent: cada vegada que surti un model nou, es re-executa i la decisió de migrar es pren amb dades. (Com construir aquestes avaluacions es veu a les lliçons 02-04 i 06-03.)

• Triar model per titulars o rànquings genèrics. Els benchmarks públics no mesuren la teva tasca. Un model mitjà pot superar-ne un de capdavanter en el teu cas concret (per idioma, domini o format). L'avaluació pròpia és insubstituïble.
• Començar pel model més gran "per anar sobre segur". Comença provant l'esglaó mitjà; puja només si la teva avaluació demostra que ho necessites. La diferència de cost i latència és gran, i moltes tasques no la justifiquen.
• Acoblar-se a un proveïdor sense capa d'abstracció. Si les crides a l'LLM estan escampades per tot el codi amb detalls específics del proveïdor, canviar de model serà un projecte en lloc d'un canvi de configuració. Centralitza l'accés a l'LLM des del primer dia (ho farem així al mòdul 3).
• Confondre "model obert" amb "gratis". Els pesos són gratuïts; les GPUs, l'operació i el personal, no. Calcula el cost total abans de decidir autoallotjar.
• Ignorar la llicència i els termes de dades. Tant en models oberts (restriccions d'ús comercial) com en APIs (entrenen amb les teves dades?, quant de temps les retenen?, on es processen?). Per a una empresa com Nubelia, això és un criteri de selecció de primer ordre.
• Consell: mantén una petita fitxa comparativa pròpia (els 5 criteris × els teus 2–3 candidats) i actualitza-la quan avaluïs models nous. És barat i converteix cada re-avaluació en rutina en lloc de debat.

Per a cada escenari, indica quin dels cinc criteris (capacitat, context, cost, latència, modalitats) seria el més determinant i per què:

1. Un procés nocturn que classifica 500.000 correus al mes en 10 categories.
2. Un assistent que analitza contractes extensos (centenars de pàgines) i respon preguntes sobre ells.
3. Autocompleció de text en temps real mentre l'usuari escriu.
4. Una eina interna que rep captures de pantalla d'errors i descriu el problema.

Una empresa financera vol un assistent intern que treballi amb documents que, per política interna estricta, no poden sortir del seu centre de dades sota cap circumstància. Té un equip de plataforma amb experiència en Kubernetes i GPUs, i un volum previst alt i sostingut. Justifica quin model de desplegament recomanaries i esmenta dos costos ocults que haurien de pressupostar.

A la reunió de decisió de DocuBot, un directiu de Nubelia proposa: "Fem servir el model més potent del mercat per a tot; així segur que funciona". Escriu una resposta argumentada (5–8 línies) fent servir la metodologia de la lliçó: què està malament en el plantejament i què proposaries en el seu lloc.

Solució 1:

1. Cost. Volum enorme i tasca simple: la diferència de preu per token multiplicada per 500.000 crides domina la decisió. Un model petit probablement classifica igual de bé; la capacitat extra seria diners llençats.
2. Context. Centenars de pàgines són molts tokens: necessites una finestra gran (o tècniques de trossejament, com veurem al mòdul 4). Si el document no hi cap, la resta de criteris ni tan sols s'aplica.
3. Latència. L'autocompleció ha d'aparèixer en fraccions de segon o fa nosa en lloc d'ajudar. Apunta a models petits i ràpids.
4. Modalitats. Necessites entrada d'imatge (visió); qualsevol model que no la suporti queda eliminat, per barat o capaç que sigui.

Solució 2:

Recomanació: model obert autoallotjat. El requisit que les dades no surtin del centre de dades és eliminatori per a les APIs externes (fins i tot amb garanties contractuals, les dades sortirien del perímetre), i l'empresa té just el perfil que fa viable l'autoallotjament: equip de plataforma experimentat i volum alt i sostingut que amortitza la infraestructura. Dos costos ocults a pressupostar (en valen d'altres de raonables): (a) l'operació contínua — actualitzacions de models, optimització d'inferència, alta disponibilitat, observabilitat — que requereix dedicació permanent de personal, no només el desplegament inicial; (b) el cost d'oportunitat de la qualitat: els models oberts poden anar per darrere de la frontera, així que necessitaran avaluació pròpia contínua i potser fine-tuning per assolir la qualitat objectiu.

Solució 3 (exemple de resposta):

"Fer servir el model més potent per a tot optimitza un sol criteri (capacitat) i ignora els altres quatre. Pagaríem el preu per token més alt i la latència més gran del mercat per a tasques on un model mitjà dona la mateixa qualitat: la majoria de preguntes a DocuBot són consultes directes sobre documentació que li passarem com a context, no problemes de raonament profund. Proposo el contrari: definir 30–50 preguntes reals dels nostres equips amb les seves respostes correctes, avaluar-hi un model mitjà i un de gran de 2–3 proveïdors, i triar el model més econòmic que assoleixi la qualitat objectiu, deixant l'arquitectura preparada per canviar de model si l'avaluació futura ho justifica. Així la decisió es basa en dades nostres, no en rànquings genèrics, i el conjunt d'avaluació ens serveix per sempre."

En aquesta lliçó has adquirit el que de debò perdura en un ecosistema que canvia cada pocs mesos: els cinc criteris de comparació (capacitat, context, cost, latència, modalitats), el mapa de proveïdors i famílies (Anthropic/Claude, OpenAI/GPT, Google/Gemini, Meta/Llama i l'ecosistema obert, Mistral i d'altres, més les plataformes de núvol), la disjuntiva API propietària vs. autoallotjament amb els seus matisos, i una metodologia de cinc passos que hem aplicat a DocuBot: Nubelia opta com a hipòtesi inicial per un model mitjà via API gestionada, validat amb una avaluació pròpia i amb l'arquitectura preparada per canviar. La lliçó de fons: aprèn a avaluar, no memoritzis rànquings.

Però abans de construir res, falta l'altra cara de la moneda. Hem parlat del que els models ofereixen; a la pròxima lliçó, "Limitacions i riscos: al·lucinacions, context i costos", veurem el que pot sortir malament: per què DocuBot es podria inventar amb total seguretat una funcionalitat de Nubelia que no existeix, què implica realment la finestra de context, i quins altres riscos — tall de coneixement, no determinisme, biaixos, costos — has de tenir al radar des del disseny. És la lliçó que separa qui integra LLMs amb criteri de qui s'endú sorpreses en producció.