Transcripció de l'episodi 001
Generat automàticament amb OpenAI Whisper
Data: 2026-03-31 23:35:11
==================================================

 D'acord, anem a desgranar això des del principi. Imaginem per un moment tenir, no sé, un cervell amb tot el coneixement col·lectiu d'internet, però que viu completament desconnectat, vull dir, a dins d'una caixa de metall sobre el nostre escriptori. Sí, sí, sense connexió a fora. Exacte. Sense subscripcions mensuals al núvol, sense que ningú recopili dades de forma massiva, o sigui, intel·ligència crua i totalment privada. Clar. Llavors, avui estem aquí per fer una anàlisi a fons de com donar-li una mena de sistema nerviós a aquest cervell allat. I, doncs, aquest sistema nerviós és precisament l'àpid o a llama, perquè, clar, estem passant d'una època on l'estàndard era bàsicament agafar la teva informació confidencial i enviar-la a servidors de tercers, oi? Totalment. A una realitat on els grans models de llenguatge, els LLM, s'executen de manera local. I el gran repte, avui dia, no és només aconseguir que el model... ...de l'arrenqui i ja està. Xolard, no és només que funcioni. Exacte. Sinó com aconseguim que es reoni de manera autònoma, que interactui amb el món digital o físic que l'envolta, però sense que col·lapsi tota la nostra infraestructura de pas. I per desmitificar tot això, hem estat remenant piles de documentació tècnica de la mateixa àpid o llama i també hem revisat guies pràctiques molt bones de l'equip de One of Time i del Cactus Group. Déu-n'hi-do la quantitat d'informació que hi ha. Sí, sí, és massiu. Però la nostra missió avui és extreure la mecànica real d'això. Així que, a veure, comencem per la real del tema. Quan iniciem un llama a l'ordinador, s'estableix com un servei en segon pla, no? Que es queda escoltant el port, crec que és el 11.434, de la xarxa local. Aquest mateix. Però, com s'ho fa realment per gestionar les demandes de càlcul tan bèsties que exigeixen aquests models? Bueno, el que és fascinant de la mecànica interna d'Ullama és, o sigui, com amaga tota la complexitat del maquinari. Diguem que quan una aplicació li demana carregar una arquitectura enorme, com un llama o un mistral o fins i tot un dípsic, l'API no agafa el model i l'aboca allà a la memòria de qualsevol manera i a veure què passa. Fa una avaluació gairebé instantània del sistema. O sigui, analitza què tens a l'ordinador en aquell moment. Exacte. Analitza quanta memòria B-RAM tens lliure a la targeta gràfica, quina és la capacitat de la RAM tradicional de la teva placa base, i a partir d'allà, pren una decisió arquitectònica per fragmentar el model si cal. Clar. Aquesta fragmentació ha de ser la clau, no? Jo, vull dir, confesso que pensava que això del núvol era com anar de restaurant. Ja m'entens. Demanes a l'OpenAI i et porten el plat fet. Sí, és una bona analogia. Però tenir Ullama és com tenir una cuina professional a casa, oi? On tu controles els ingredients. I si entenc bé com funciona aquesta cuina, els models tenen capes. Matrius de pesos matemàtics. Sí, capes sobre capes. Llavors, si tens una targeta gràfica molt potent, l'API hi posa el 100% de les capes i tens una velocitat brutal. Però si el model és massa gros per la GPU, què fa? Ho divideix. Ho divideix, exacte. Reparteix la feina. L'API podria dir, a veure, enviarem un 52% de la càrrega, la part més pesada matemàticament, a la targeta gràfica. D'acord. I el 48% restant cap al processador central, la CPU. I l'API d'Ullama fa de director d'orquestra, passant dades amunt i avall, entre la memòria de vídeo i la del sistema durant la inferència. Això evita colls d'ampolla increïbles. I a l'usuari ni se n'adona. Ni se n'adona. I, de fet, una cosa molt xula és que proporcionen un endpoint específic, que és barra API barra SAPS. O sigui, API, SAPS. Ah, sí, ho he vist a la documentació. Doncs això permet a qui desenvolupa supervisar en temps real com s'estan repartint els recursos. És com tenir visió de reigecs del que passa sota el capó. Ostres, això és molt potent. Però, clar, tenir aquest cervell massiu allà optimitzat a la RAM, doncs està molt bé, però és totalment inútil si està sortimut, oi? Clar, necessita instruccions. Necessita parlar. Llavors anem a com l'API estructura el diàleg. Perquè tenim dues rutes principals. Barra API, barra Generate. I barra API, barra xat. Mhm. Si mirem l'endpoint de generació, el Generate, a mi em va semblar pràcticament quirúrgic. Fa la impressió que és per a una operació d'un sol tret, sense memòria del passat. Mhm, estic totalment d'acord. És una descripció molt acurada. La ruta Generate rep una única cadena de text, un simple prompt, i et torna una continuació directa d'aquí el text. I ja està. Molt directa? Sí, és l'eina ideal per automatitzar tasques que no necessiten context. Per exemple, li passes un text i li dius «Extreu-me els noms propis d'aquí», o per autocompletar una línia de codi. Ah, clar. I, curiosament, també suporta un camp que es diu «súfix», que et permet posar text al davant i al darrere d'un buit i forces el model a omplir exactament aquell forat. Això per programar va de conya. Però, bueno, això resol les tasques, diguem-ne, mecàniques. Ara, si volem construir assistents intel·ligents, necessitem que recordin de què estàvem parlant fa 10 minuts. L'historial. L'historial de la conversa, sí. I aquí és on entra l'empoïnxat. Que, clar, això introdueix tota l'estructura de rols, allò de sistema, usuari, assistent. El que em va volar al cap de les guies és la quantitat de feina bruta que ens estalvia l'API aquí. Moltíssima. Perquè si un programador hagués de parlar amb cada model en el seu, no sé, idioma natiu, seria un caos de formats, no? Un caos absolut. Jo n'estic segura, vull dir, cada família de models té la seva pròpia paranoia sintàctica amb els tòquens de control. Sí. Clar, per exemple, alguns models fan servir etiquetes com imstart entre claudados angulars seguit del rol per dir qui està parlant. Altres fan servir claudados quadrats o etiquetes raríssimes. Quina bogeria per programar això. T'hi podries passar hores. Però el disseny de l'API de Chat do Llama actua com un traductor universal. Agafa la llista de missatges neta, identifica quin model s'està ejecutant sota el capó, aplica la plantilla exacta que necessita aquella arquitectura de forma dinàmica i llavors ja construeix la cadena de text final per al processador. És a dir, tu només li passes un format net i o Llama s'encarrega de disfressar-lo perquè el model ho entengui. Exacte. Et treu un pes de sobre enorme. D'acord. Llavors ja tenim la comunicació resolta. Però més enllà d'això, tenim els paràmetres de control. Jo els veig com els condiments per a la IA, no? No. No. No. No. No. No. La comunicació insisteix molt en el paràmetre temperatura. La temperatura. Ui, sí, aquesta és fonamental. A veure, si jo poso la temperatura a zero, la IA es converteix en una calculadora avorrida i superprecisa. Bàsicament, sí. Si poses la temperatura a zero, elimines tota l'aliatorietat matemàtica. L'obligues a triar sempre la següent paraula, el següent tòquen amb la probabilitat més alta. D'acord. Així es converteix en un sistema determinista, que és justa. El que vols per extreure dades, on la creativitat seria, bueno, un desastre. Clar, no vols que s'inventi números. Però també hi ha altres controls, el top K i el top P. Aquests semblen una mica més subtils. Sí. Operen manipulant la llista de possibles respostes abans que el model decideixi. El top K funciona com unes tisores, per entendre'ns. Si el poses a 40, el model només mirarà les 40 paraules més probables. Talla la resta. Talla darrere la cua d'opcions rares. Que és el que sol provocar les al·lucinacions. I el top P és encara més sofisticat. Ordena els tòquens per probabilitat i els va sumant fins a arribar a un percentatge. Posem un 90%. Llavors, si la primera opció ja és un 90%? Només es queda amb aquella. Permet tenir moltes opcions quan el model dubta o molt poques quan la resposta és evident. I no ens podem deixar el numset ex. Què és això? La finestra ve context. Si redueixes aquest límit de memòria a curt termini, alliberes una barba. Així pots accelerar moltíssim el rendiment quan fas tasques curtes. D'acord, entès. Això està molt bé per afinar el motor. Però, clar, si ajustem tot això, no solucionem el problema de la paciència humana, no? Ah, la latència. Clar. Tu pots tenir el model més precís del món, però si necessita dos minuts pensant abans d'escopir-te un bloc de text enorme de cop... Sembla que s'hagi penjat. Exacte. L'il·lusió d'interactivitat es trenca totalment. Però aquí és on es posa realment interessant, perquè les fonts detallen que l'API fa servir el flux de dades en temps real, el famós streaming, i està activat per defecte. I tant. I el mecanisme tècnic darrere d'aquesta il·lusió d'immediatesa és el format NDXN, que vol dir JSON delimitat per salts de línia. Com funciona això, exactament? Doncs, mira, en una petició tradicional, l'aplicació demana la informació i el servidor et fa esperar fins que té tot el text generat. Llavors t'ho envia tot de cop. El bloc sencer. Clar. Però amb NDTSS la connexió es manté oberta com si fos una canonada contínua d'aigua. Tampoc un punt el model dedueix el primer token, la primera paraula, l'API envia un petit paquet de dades, i fraccions de segons després envia la següent. Així el codi que rep això ho pot anar pintant a la pantalla paraula a paraula. Aquest efecte de màquina d'escriure, tan típic que veiem a tot arreu ara. Exacte, és això. Però el que jo trobo fascinant, o sigui, de veritat, és com han hagut d'adaptar aquest streaming per a la nova generació de models de raonament, els que pensen com el Dipsic R1. Ah, sí, això és molt nou. Clar, perquè aquests models, abans de donar-te la resposta, elaboren una cadena de pensament intern, miren diferents camins, s'equivoquen, rectifiquen... Com envies aquest pensant-veu-adre? Doncs la solució que han trobat és introduir un camp separat. Un camp que es diu, literalment, Thinking, dins d'aquests paquets JSON que t'arriben en temps real. Llavors, mentre el model està rumiant el problema, només emet dades per aquest canal de Thinking. Això permet capturar tota aquella lògica pura i l'exploració d'errors que fa el model. Però, a nivell de disseny d'interfaces, això és un repte enorme per al programador. I tant, has de fer un seguiment de l'estat. O sigui, identificar quan estàs en un estat que en podríem dir Inthinking. Clar, mentre això està actiu, què fas amb el text? Doncs l'agrupes, l'amagues darrere d'aquelles pestanyes desplegables que veus a la pantalla que diuen, el model està pensando. I quan l'api para d'enviar coses pel camp Thinking i passa a la resposta normal, tanca el bloc i comença a mostrar la resposta definitiva. I això és vital, perquè dona una transparència increïble. Pots auditar pas per pas com ha arribat a la conclusió. Auditar el raonament és clau, sobretot quan t'adones d'un petit detall. I és que, per molt llest que sigui, aquest model continua atrapat en el temps. Només sap el que va aprendre durant el seu entrenament. Una entitat aïllada. Completament aïllada. I la necessitat de connectar aquest raonament amb informació d'avui mateix o amb altres programes, això obre la porta al que anomenen la crida de funcions. El famós Tool Calling. Sí, sí, i això canvia tot. I es posa i es té clics per internet ella sola. No, no, per res. Jo ho veig més aviat com tenir, no sé, una estratègia brillant tancat en un búnquer sense finestres. M'agrada molt aquesta imatge. Clar, aquesta estratègia no sap si fora plou o fa sol, però pot passar un paper per sota la porta demanant llegeix el termòmetre de fora i torna amb la xifra. I l'aplicació que estem fent nosaltres és la persona de fora que llegeix el termòmetre i li torna el paper amb els graus. Exacte. És un repartiment de responsabilitats pur. Tècnicament, això comença fins i tot abans de la conversa. El teu programa li diu al model Mira, tens aquestes eines disponibles i ho fa amb un esquema JSON super estricte, definint el nom de la funció i quins paràmetres necessita. I si el model, mentre raona, decideix que necessita el clima? Doncs atura en sec la generació de text, deixa de parlar en llenguatge natural i en comptes de text, l'API es retorna un objecte que es diu toolscalls. És la comanda que deies, el paper per sota la porta. Ah, i què hi diu allà? Et diu quina funció has d'executar i amb quines variables. Llavors la teva aplicació local executa el codi de veritat, obté els graus que fa fora i fa una nova petició a l'API afegint la dada a l'historial amb el rol de tool. I llavors el model ja pot respondre amb base a la realitat. Però, a veure, un moment, un moment. Digues. Si jo estic dissenyant un sistema on dono llibertat al model de demanar dades, avaluar resultat i si no li agrada demanar una altra eina de forma autònoma, no estic creant una bomba de rellotgeria? O sigui, un bucle infinit? El model es podria confondre, començar a demanar coses sense sentit, repetidament, i penjar l'ordinador esgotant tots els recursos. Totalment. El que descriu s'anomena bucle de gens, els agent loops, i és un maldecap constant en la indústria ara mateix. I la solució recau 100% en qui programa l'aplicació. Ollama no et protegeix d'això? No. L'API només posa la via de comunicació. Tu has d'imposar la disciplina en el codi extern. Has de definir les esquemes de les funcions amb descripcions claríssimes perquè la IA no es confongui. I, sobretot, i això és imperatiu, has de posar un límit màxim d'iteracions al teu codi. Un tall per si es torna boic. Clar. Si el model demana eines, no sé, cinc vegades seguides sense generar una resposta final per a l'usuari, el teu sistema ha de tallar el procés allà mateix, i llançar un error humà. D'acord. Però encara hi ha un altre repte. Si el meu sistema informàtic espera arregrar el famós tool calls amb un format JSON perfecte d'aparells de dades, però el model, per algun motiu, es posa a xerrar i em respon m'agradaria fer servir l'eina del clima per midar el temps a Barcelona. El teu programa peta. Immediatament. Peta. Clar, perquè no entén el text humà. Espera codi. Com ho evitem, això? Aquí és un entrant a les sortides estructurades, o Structured Outputs. Pots configurar l'API exigint un esquema JSON concret. I el que fa l'API per sota és brutal, perquè restringeix físicament l'espai de tòquens que el model pot generar. O sigui, no el deixa xerrar? L'impedeix generar xerrameca innecessària. L'obliga a encaixar la seva resposta explosivament dins del format que tu li has demanat. Les guies també parlen molt d'eines de validació, com Paidantic o Zot. Sí, sí, absolutament vitals. Per a qui no ho conegueix, jo me les imagino com... porters de discoteca molt, molt estrictes. Bona comparació. Quan el model genera el format JSON, aquests porters l'inspeccionen. Si esperaven un número, però arriba un text o falta una variable, retgeixen l'entrada de cop. No deixen passar dades mal formades a la resta de l'aplicació. Mai. I si combines això amb la temperatura zero que dèiem abans? Tens un sistema hiperdeterminista, robusta i funcionant 100% a la teva màquina. Això és impressionant. Converter Sollama en una eina increïble per crear aplicacions des de zero. Però aquí hi ha un elefant a l'habitació. A la indústria hi ha milions i milions de línies de codi que ja estan escrites específicament per a l'API d'OpenAI. Uf, sí. De tot. Automatitzacions, atenció al client... Clar, anar ara als programadors i dir-los Ei, reescriviu-ho tot per al format d'Ullama. Doncs no ho farà ningú. És una fricció massa gran. I per això mateix la gent d'Ullama va tenir una visió estratègica genial. Han creat un autèntic cavall de troia corporatiu amb el seu endpoint d'UVU. A la documentació diu que és una capa d'emulació directa d'OpenAI. Com s'ho fa per enganyar el codi vell? Actua com un traductor simultani, rapidíssim. Quan un programa fa servir la llibreria oficial d'OpenAI, envia un paquet de dades preparat pels servidors d'ells. Però com a desenvolupador l'única cosa que has de fer és canviar la URL base i posar-la al localhost amb el port 11434. I ja està. I posar una clau d'API inventada, falsa. Que bo. Llavors, quan Ullama rep això al B1, agafa l'estructura d'OpenAI, extreu els paràmetres, els tradueix el seu idioma, executa el model que tinguis en local i empaquetar la resposta recreant l'involcatge exacte que donaria OpenAI. De manera que el teu programa creu que està parlant amb un servidor caríssim de Califòrnia, però està xerrant amb la targeta gràfica que tens sota la taula. Exacte. No hi ha cap diferència per al programa. I atenció, perquè això no només serveix per generar text. He vist a les guies que amulen fins i tot la generació de vectors incrustats, allò dels embeddings. Oh, això és molt important per al RAC. Sí, la generació augmentada per recuperació. Simplificant molt, per si algú s'ha perdut amb les sigles, és allò de convertir milars de documents teus, personals, en coordenades matemàtiques. I quan fas una pregunta, busca el fragment més rellevant i l'afegeix al context. Que això es pugui fer completament en local, emulant el núvol, és tancar el cercle de la privacitat, oi? Totalment. I no es queda només amb opanellar, eh? També s'estan començant a emular els formats d'antròpic. Vull dir, pots agafar eines d'assistència a la programació avançadíssimes, com CloudCode, i enganyar-les perquè funcionin completament amb el teu disco dur i el teu model local. Vist amb tota aquesta perspectiva que hem analitzat, ja no estem parlant d'un simple simulador de xat, d'un xatbot divertit per passar l'estona. L'Apidoyama és una infraestructura per orquestrar sistemes autònoms. Pots gestionar la memòria, exigir sortides en JSON rigoroses, emular servidors comercials. És espectacular com no depèn de cap xarxa. Hem esborrat la barrera d'entrada. El poder computacional que fa dos anys demanava un equip sencer d'enginyers de núvol ara està empaquetat en un servei que corre al teu ordinador amb dues comandes. I, precisament, aquesta autonomia em porta a una última reflexió que em va venir al cap llegint els arxius de configuració en Model File. Aquests arxius et permeten incrustar un historial de missatges previ dins del propi model de manera permanent. Llavors, pensem a llarg termi. Què passaria si algú dissenya un sistema que actualitze contínuament aquest Model File, que cada dia hi afegeixi un resum de les teves interaccions, les teves decisions vitals o reflexions? És un sistema que és molt important. I, per tant, és un sistema que és molt important. I, per tant, és un sistema que és molt important. I, per tant, és un sistema que és molt important. I, per tant, és un sistema que és molt important. És un sistema que és molt important. Any rere any. Tot això sense dependre d'empreses que llegeixin les teves dades, perquè només viu al teu port 11.434. És una perspectiva superprofunda. Estaries construint pràcticament un repositori d'aprenentatge acumulat que creix amb tu. O sigui, encapsular el teu context vital dins del model. Clar. Ja no descarregues un programa. Estàs plantant la llavor d'una extensió cognitiva pròpia, un segon cervell privat que aprèn, iteració en reiteració, per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. Per fer-ho. I la tecnologia base ja la tenim a l'escriptori. Absolutament. Doncs amb aquesta idea us deixem avui. Moltes gràcies per acompanyar-nos en aquesta desconstrucció de l'àpido llama. Ens retrobem a la pròxima anàlisi a fons.