Com servir un model de llenguatge gran des del teu workstation local

Darrera actualització: 17/03/2026
Autor: Isaac
  • Executar i servir LLM des d'una workstation local permet controlar costos, latència i privadesa, aprofitant CPU, GPU o iGPU segons el maquinari disponible.
  • Eines com Ollama, LM Studio i GPT4All simplifiquen la descàrrega, gestió i exposició de models quantitzats adequats a cada equip.
  • La configuració correcta de drivers, variables d'entorn i xarxa és clau per fer servir acceleració GPU i oferir una API compatible amb OpenAI a altres aplicacions.
  • La quantització i l'elecció de mides de model equilibren qualitat i consum de recursos, fent viables desplegaments locals fins i tot en equips no extrems.

IA local a workstation

Muntar un model de llenguatge gran en una workstation local ja no és un caprici de friquis de la IA: és una cosa perfectament viable si tens un bon equip, una mica de paciència i és clar què vols aconseguir. Des d'un portàtil potent fins a una torre amb una GPU seriosa o, com en el teu cas, una màquina amb AMD Ryzen AI MAX+ i una iGPU amb un bon tac de VRAM compartida, pots crear el teu propi “ChatGPT privat” accessible des d'altres dispositius de la teva xarxa.

El repte no està només a instal·lar eines com Ollama, LM Studio o GPT4All, sinó en entendre com treure partit al maquinari (CPU, GPU i iGPU), com exposar un servidor d'IA remot a què connectar-te des del mòbil o el portàtil, i com triar el model i la quantització adequats per no matar la teva màquina a la primera pregunta. Veurem tot això amb calma, però en pla pràctic i sense perdre els detalls tècnics importants.

Què implica servir un LLM des de la teva workstation local

Quan parlem de “servir un model de llenguatge gran des d'una workstation local” no és només obrir un xat i ja està, sinó aixecar un servei accessible per HTTP (normalment amb una API tipus OpenAI) que es pugui fer servir des d'altres dispositius: scripts en Python, aplicacions web, mòbils o fins i tot eines low-code. La teva màquina actua com un mini-servidor d'inferència dins de la xarxa domèstica o d'oficina.

Això té diverses implicacions: per una banda, necessites que el model s'executi amb fluïdesa al teu maquinari (ja sigui CPU, GPU dedicada o iGPU) i, de l'altra, que el servei escolti en una IP accessible per a altres equips (no només en 127.0.0.1). Eines com Ollama i LM Studio faciliten molt aquest procés, ja que exposen un servidor local compatible amb l'API d'OpenAI o amb endpoints HTTP senzills que pots consumir des de qualsevol llenguatge de programació modern.

En equips com una Framework Desktop amb Ryzen AI MAX+ i Pop!_OS (o una altra distro Linux), l'objectiu sol ser esprémer els 98 GB de VRAM compartida assignats a la iGPU per accelerar els LLM, en lloc de dependre únicament de la CPU. Aquí entren en joc els drivers, el ROCm (en el cas d'AMD) i les opcions d'acceleració GPU de cada eina.

A més de l'aspecte tècnic, hi ha una part estratègica: un LLM local us dóna més control sobre els costos, la privadesa i la latència. No pagues per token, no depens de la connexió a Internet, i les dades sensibles no surten de la teva xarxa. Això sí, tu et menges la part de manteniment, actualitzacions i control de seguretat del sistema.

Requisits de maquinari i sistema per a LLM locals

Abans d'enganxar-te amb instal·lacions, convé revisar què maquinari necessites per servir un LLM des del teu workstation local amb certa dignitat. No cal tenir un monstre de datacenter, però sí entendre on són els colls d'ampolla: RAM, VRAM, CPU i disc.

Per executar models de llenguatge grans, la memòria RAM sol ser el recurs crític. Els models es carreguen en memòria (RAM i/o VRAM), així que si et quedes curt veuràs errors de “Out of Memory” o directament penges. Amb 8 GB de RAM pots provar models molt petits (1B, 3B, 7B quantitzats), encara que notaràs manca de fluïdesa. Amb 16 GB ja pots moure't amb soltesa amb models de 7B i 13B ben quantitzats. A partir de 32 GB o més, comences a jugar seriosament amb models grans (30B, 40B, 70B) sense gaires drames.

Quant a CPU, els processadors moderns d'escriptori aguanten força bé la inferència en local, sobretot amb models quantitzats. L'ideal és comptar amb almenys 4 nuclis físics i, si pots, 8 o més cors perquè la generació de text sigui raonablement ràpida, especialment si atendràs diverses peticions concurrents des de diferents dispositius a la teva xarxa.

La GPU (o iGPU) marca la diferència en rendiment quan vols respostes fluides i tokens per segon decents. Una GPU dedicada amb almenys 8 GB de VRAM (per exemple, una RTX 3060 o similar) ja permet moure models mitjans amb soltesa. En el teu cas, amb un Ryzen AI MAX+ i una iGPU amb 98 GB de VRAM compartida, el truc és que l'stack d'IA (Ollama, truca.cpp, ROCm, etc.) aconsegueixi detectar i aprofitar aquesta iGPU. De vegades cal tocar variables dentorn com HIP_VISIBLE_DEVICES o ROCR_VISIBLE_DEVICES, revisar drivers i comprovar als logs si la GPU està sent usada o no.

El emmagatzematge també importa: els fitxers de model ocupen des d'un parell de GB fins a centenars. Un petit model quantitzat pot ser d'uns 2 GB, un mitjà d'uns 5 GB, i models grans de 40 GB o més. Hi ha fins i tot LLMs que superen el terabyte. El que és sensat és reservar entre 20 i 100 GB d'espai lliure si planeges provar diversos models sense caminar esborrant contínuament.

Finalment, el sistema operatiu. Tant Windows 10/11 com Linux i macOS poden executar LLM locals. Per a entorns com el teu, amb Pop!_OS i maquinari AMD, sol ser més pràctic quedar-se a Linux per aprofitar millor ROCm i les integracions de GPU amb Ollama o truca.cpp. Si una distro et dóna massa guerra amb drivers, de vegades val la pena canviar-ne una altra més “amigable” amb el teu maquinari (Ubuntu, Fedora, etc.).

  Curador de realitats sintètiques: el nou intermediari entre humans i màquines

Conceptes bàsics: LLMs, Transformers i quantització

Per no anar a cegues, ajuda entendre mínimament què hi ha darrere dels models de llenguatge grans. Un LLM és una xarxa neuronal entrenada de forma auto-supervisada sobre quantitats ingents de text per predir la següent paraula una seqüència, ia partir d'aquí generar respostes, traduir, resumir o programar.

La majoria de LLMs moderns usen la arquitectura Transformer, que treballa convertint paraules en vectors numèrics (embeddings). Aquests vectors es processen a través de capes datenció i feed-forward, aprenent patrons estadístics del llenguatge: bàsicament, quines paraules tendeixen a aparèixer juntes i en quins contextos. El model, a cada pas, estima la probabilitat de la següent paraula donada la seqüència anterior i altres paràmetres configurables.

El Transformer se sol dividir en dos blocs conceptuals: un codificador, que s'encarrega d'“entendre” el text d'entrada i generar una representació contextual, i un descodificador, que pren aquesta representació i va generant tokens de sortida un a un. En els grans models de xat actuals se solen fer servir arquitectures decoder-only, però la idea de fons és la mateixa: es processa la seqüència i es generen tokens fins a completar la resposta.

Durant la generació, entrar en joc paràmetres com la temperatura, el top-k, el top-p, etc., que influeixen en quant “arrisca” el model a l'hora de triar paraules menys probables. Canviar aquests ajustaments pot fer que la IA respongui de forma més creativa o més conservadora, una cosa clau si muntareu un servei remot per a altres usuaris o aplicacions.

Un concepte vital per poder servir LLMs en una workstation és la quantització. En comptes d'emmagatzemar els pesos de la xarxa en coma flotant de 16 o 32 bits, es converteixen a enters de 8, 4 o fins i tot 2 bits. Això redueix moltíssim la mida del fitxer del model i la memòria necessària per executar-lo, a costa d'una lleugera pèrdua de precisió a les respostes.

A la pràctica, passar un model de 32 bits a un format com Q4_K_M o similars pot fer que un model de 40 GB baixi a la meitat o menys de mida. Les mètriques com la perplexitat ajuden a mesurar l'impacte: un valor més baix implica millor qualitat, i s'observa com puja una mica en aplicar quantització, però moltes vegades l'usuari gairebé no nota la diferència en l'ús real mentre que el rendiment millora brutalment.

Avantatges de servir un LLM des de la teva pròpia màquina

Aixecar un servidor d'IA al teu propi PC o workstation té diversos avantatges clars davant de dependre tota l'estona d'APIs al núvol. La primera és la privadesa i el control total de les dades. Tot el que envies al model (prompts, documents, historials de conversa) es queda al teu equip, sense passar per servidors externs, cosa que és crucial si treballes amb informació mèdica, legal o financera sensible.

També hi ha un tema de costos i rendiment. Cada trucada a una API com GPT-4, Claude o altres models comercials té un preu per milió de tokens. Si la vostra aplicació fa moltes peticions, la factura es pot disparar. Amb un model local, més enllà de la despesa en maquinari i electricitat, no pagues per consulta. I en no dependre de la xarxa, sols guanyar en latència: el temps fins al primer token i la velocitat de generació solen ser millors, especialment en xarxes lentes o inestables.

Un altre avantatge potent és el personalització. Moltes eines dexecució local permeten ajustar paràmetres dels models, carregar plantilles de prompts específiques, o fins i tot reutilitzar pesos daltres models per afinar-los (fine-tuning lleuger). S'ha creat una comunitat enorme de models derivats per a diferents casos d'ús, des d'assistents de programació fins a chatbots creatius o models especialitzats en documents legals.

A nivell d'estratègia tecnològica, executar LLMs a la teva pròpia infraestructura redueix la dependència de proveïdors concrets. No estàs exposat a canvis de preus, límits dús, restriccions de contingut o tancaments de servei. I, si més endavant decideixes combinar-ho amb serveis de núvol (per exemple, per a pics de càrrega), pots dissenyar arquitectures híbrides que reparteixin la càrrega entre el maquinari local i la cloud.

Això sí, no tot són roses: en guanyar control, també assumeixes responsabilitats a governança de models, actualitzacions, seguretat i monitorització. Si utilitzaràs aquest servidor per a alguna cosa més seriosa que trastejar a casa, convé planificar des del principi com registraràs logs, gestionar versions de models i auditar-ne el comportament.

Eines clau per servir LLM en local

Per muntar un servei d'IA accessible des d'altres dispositius, teniu diverses eines al vostre abast. Algunes estan orientades a usuaris que no volen saber res de terminals, i d'altres són més tècniques, però ofereixen més control. Les més rellevants pel teu cas són Ollama, LM Studio, GPT4All i entorns basats en truca.cpp/ROCm, a més de plataformes com Comfy per a la part de generació d'imatges.

Ollama és una capa amigable sobre flama.cpp que permet descarregar, executar i gestionar models directament des de la línia d'ordres, oferint a més una API HTTP al port 11434 per defecte. Suporta Windows, macOS i Linux, i és especialment potent en màquines amb GPU NVIDIA o AMD ben configurades. Pots enganxar-te amb ell a Pop!_OS sense problema sempre que tinguis els drivers correctes.

Estudi LM és més visual, amb interfície gràfica per buscar models a Hugging Face, descarregar-los i xatejar amb ells. A més, ofereix un mode servidor local compatible amb l'API d'OpenAI, perfecte per integrar-lo a les teves aplicacions com si estiguessis trucant a GPT-4, però sense pagar i sense treure dades de la teva xarxa. Suporta Windows, macOS i Linux, i es porta força bé amb GPUs modernes.

  Com llistar dependències d'un paquet a Linux i no trencar el sistema

D'altra banda, GPT4All combina una interfície gràfica senzilla amb eines de línia d'ordres. Està pensat per a usuaris que volen alguna cosa intermedi: poder fer servir un xat en local, però també fer coses més avançades via terminal o integracions amb altres projectes. Funciona bé sense GPU, tirant només de CPU, cosa que el fa útil per a equips sense acceleració gràfica potent.

Al terreny gràfic, Còmode és una plataforma open source molt popular per generació i edició d'imatges amb IA. Encara que no està centrada en LLMs, encaixa bé en un setup d'IA local més complet: uses Ollama o LM Studio per a text, i Comfy per a imatges, tot servint-se des de la teva workstation.

Si vols anar a l'extrem, plataformes basades en AMD Ryzen AI Max+ amb ROCm i llama.cpp permeten fins i tot executar models de fins a un trilió de paràmetres de forma distribuïda en clústers locals, quantitzats i hiperoptimitzats. És un escenari més propi de startups tech amb ambicions serioses que no pas d'un usuari domèstic, però demostra que la inferència local a gran escala és perfectament real.

Ollama a Linux: instal·lació, configuració i ús com a servidor

Tornant a un cas pràctic i alineat amb el teu entorn, Ollama a Linux és una opció molt sòlida per servir un LLM des de la teva workstation. La instal·lació oficial, en distros de l'estil de Pop!_OS o Ubuntu, es fa normalment amb una única ordre:

curl -fsSL https://ollama.com/install.sh | sh descarrega i instal·la el servei, que s'executa en segon pla mitjançant systemd. Un cop instal·lat, Ollama descarrega els models en una carpeta interna (a Linux sol ser /usr/share/ollama/.ollama/models llevat que canviïs la ruta) i aixeca una API a 127.0.0.1:11434.

Per adaptar-lo a les teves necessitats, en pots configurar diverses variables d'entorn editant la unitat de systemd: amb sudo systemctl edit ollama.service afegeixes un bloc [Service] on defineixes opcions com OLLAMA_MODELS (ruta personalitzada de models), OLLAMA_HOST (per exemple, 0.0.0.0:11434 perquè altres dispositius de la xarxa puguin connectar), OLLAMA_ORIGINS per controlar CORS, o OLLAMA_KEEP_ALIVE per decidir quant de temps roman un model en memòria després de la darrera petició.

Després de guardar, fas un sudo systemctl dimoni-recarrega i després sudo systemctl restart ollama per aplicar els canvis. És important revisar els logs d'Ollama, que a Linux es consulten amb suo journalctl -o ollama (pots afegir -f per seguir en temps real o -n 100 per veure només les últimes 100 línies), perquè aquí sabràs si està detectant la GPU, si hi ha errors CUDA/ROCm o si s'està quedant sol a CPU.

Dins d'aquests logs veureu una línia amb el missatge “looking for compatible GPUs” i, si tot va bé, una altra indicant que s'ha trobat una GPU usable. Si en canvi apareix “no compatible GPUs were discovered”, significa que Ollama està tirant únicament de CPU, i aquí toca revisar drivers i variables d'entorn d'AMD (HIP_VISIBLE_DEVICES, ROCR_VISIBLE_DEVICES, etc.).

Amb Ollama operatiu, pots gestionar models amb ordres com ollama pull truca3.2:1b (descàrrega), Ollama Run Llama 3.2:1b (execució interactiva), ollama list (llista de models), ollama xou (detalls), ollama rm (esborrat) o Ollama PS (models carregats en memòria i si usen CPU o GPU). L'ordre ollama stop et permet descarregar un model de memòria si ja no ho necessites.

Triar i etiquetar models: mida, quantització i variants

Un cop tens el servidor a punt, toca decidir què model serviràs a les teves aplicacions i dispositius. A la web d'Ollama o als catàlegs de LM Studio veuràs una enorme llista de models amb etiquetes que poden embolicar una mica al principi, però que en realitat són força informatives.

D'una banda hi ha el mida, normalment expressat en “B” de billions de paràmetres: 1B, 3B, 7B, 13B, 32B, 70B, etc. Més paràmetres solen implicar més coneixement i millor rendiment, però també més consum de RAM i VRAM. Si la teva workstation va justa de recursos o vols baixa latència amb molts usuaris alhora, pot ser més assenyat servir un model de 7B o 13B ben afinat que un gegant que s'arrossega.

Després hi ha la quantització, amb etiquetes tipus Q2_K, Q3_K_M, Q4_K_S, q8_0, fp16, fp32, etc. Com més baix és el nombre (Q2 davant Q8), més comprimit està el model i menys memòria fa servir, però també hi ha una pèrdua de precisió. Les variants amb sufix K (K_S, K_M, K_L) solen considerar-se equilibrades entre mida i qualitat, mentre que fp16 o fp32 significa pràcticament sense quantitzar, cosa que dóna màxima qualitat a costa de devorar recursos.

A més, veuràs variants per tipus d'ús: models etiquetats com a instruct (pensats per seguir instruccions), xat (conversa general), code (programació), vision (multimodals amb imatges), etc. Per servir un assistent general a altres dispositius, normalment t'interessa alguna cosa tipus xat o instruct, mentre que per a un backend de generació de codi serà millor un model code com CodeFlama o DeepSeek Coder.

Finalment, moltes vegades apareix una etiqueta últim. Això no vol dir que sigui l'últim model creat, sinó una mena de “versió recomanable per defecte”: sol ser un punt mitjà entre mida, qualitat i requisits de maquinari. Si no tens clar per on començar, latest és un bon primer candidat per a proves.

LM Studio i el mode servidor compatible amb OpenAI

Si prefereixes alguna cosa més visual i t'interessa especialment exposar un API tipus OpenAI des de la teva workstation, Estudi LM és un aliat molt còmode. Després de descarregar la versió per a Windows, macOS o Linux des de la seva web, la instal·les com qualsevol altra aplicació i, en obrir-la, t'ofereix un cercador integrat de models allotjats a plataformes com Hugging Face.

  Com optimitzar el consum de RAM de Microsoft Edge amb pestanyes en espera

A LM Studio pots filtrar per mida, tipus de tasca i compatibilitat amb el maquinari. Per a equips amb només CPU i 8 GB de RAM, hauràs d'anar a models petits i molt quantitzats. Si tens més de 16 GB de RAM, ja pots pujar a 7B o 13B amb més soltesa. Amb GPU i 16 GB de RAM (o un Mac amb M1/M2) pots provar models mitjans, i amb GPU i 32 GB de RAM ja entres al territori de 40B sense que sigui un drama, sempre ajustant la quantització.

Un cop descarregat un model, LM Studio et permet xatejar directament des de la pròpia interfície, amb estadístiques de tokens i velocitat. Pots obrir diversos xats, canviar paràmetres de generació al panell lateral i veure com es comporta cada model amb prompts reals. Això és útil abans de decidir quina exposaràs com servei remot per a les teves apps.

La part més interessant arriba amb l'opció de “Local Server”. En activar-la amb el botó de “Start Server”, LM Studio aixeca un servidor a la teva màquina que emula l'API d'OpenAI. Això significa que des del teu codi Python, JavaScript o el que facis servir, pots seguir utilitzant el client d'OpenAI, però apuntant a http://localhost:1234/v1 (o un altre port que configures) en lloc dels servidors reals d'OpenAI.

Per exemple, a Python faries servir una cosa així: definir un OpenAI(base_url="http://localhost:1234/v1", api_key="not-needed") i després crear completions amb el model «local-model» o el nom que heu configurat. Des de fora sembla que estàs trucant a GPT-4, però en realitat estàs parlant amb el teu LLM local, executant-se a la workstation i aplicant les teves regles de privadesa i cost.

Aquesta compatibilitat amb el format OpenAI permet muntar de manera senzilla arquitectures híbrides: pots fer que el teu codi faci servir primer el model local i, en cas d'error, latència inacceptable o la necessitat d'un model molt gran, delegar puntualment en una API externa de pagament. D'aquesta manera, mantens flexibilitat sense renunciar a l'estalvi i al control que dóna la inferència local.

Rendiment, problemes típics i com afinar-los

Quan tens el model en marxa i el servidor exposat, arriba el moment de barallar-te amb el rendiment real i els errors comuns. El primer que sol aparèixer són missatges de “Memòria insuficient” o “Out of Memory” en intentar carregar models massa grans per al teu RAM/VRAM. La solució sol passar per tancar aplicacions pesades, triar una quantització més agressiva (per exemple, Q4 en lloc de Q8) o directament baixar de mida de model.

Si has apostat per utilitzar la GPU o la iGPU del Ryzen AI MAX+ i notes que el sistema torna una vegada i una altra a la CPU, segurament hi ha un problema de drivers o detecció de GPU. A Windows, assegura't que els drivers NVIDIA/AMD són els més recents i que l'eina (LM Studio, Ollama, etc.) té habilitada l'opció d'acceleració per GPU a la configuració. A Linux, revisa ROCm, les variables d'entorn i els logs per comprovar si realment la GPU és visible.

Una altra font de maldecaps són les descàrregues corruptes o incompletes de models. Si un model no carrega o es bloqueja només arrencar, de vegades només cal esborrar-lo des de l'eina (ollama rm, esborrar carpeta a LM Studio) i tornar-lo a descarregar. Tingues present que un model de 30 o 40 GB descarregat a mitges no arrencarà per art de màgia.

En entorns basats només en CPU, la queixa habitual és la lentitud de generació. Això és normal: els LLM són pesats. Per millorar-lo, centra't en models més petits i ben quantitzats, puja el nombre de fils que l'eina pot fer servir i vigila que la CPU no estigui fent thermal throttling per temperatura. De vegades un canvi de pasta tèrmica o una millora en la ventilació de la caixa es nota més del que sembla.

Si el que busques és servir un LLM a altres dispositius de casa teva o oficina, no oblidis revisar també la configuració de xarxa i seguretat. Exposar l'API a 0.0.0.0 fa que qualsevol dispositiu de la xarxa pugui arribar al teu servidor, cosa que és útil però implica riscos. Podeu limitar l'accés amb tallafocs, xarxes separades o autenticació a nivell d'aplicació, especialment si utilitzeu dades sensibles o si la vostra workstation està exposada a Internet.

Més enllà d'aquests problemes bàsics, en desplegaments més seriosos per a startups o empreses cal pensar en monitorització, logging estructurat, backups de models i estratègies d'actualització. No és el mateix jugar a casa que muntar un producte comercial on els models es converteixen en un component crític del negoci.

En definitiva, servir un model de llenguatge gran des d'una workstation local implica combinar bon maquinari, eines adequades i una mica de mim en la configuració. Amb CPU moderna, suficient RAM, una GPU o iGPU ben suportada i plataformes com Ollama o LM Studio, pots muntar la teva pròpia infraestructura d'IA privada, accessible des de tots els teus dispositius, amb un control fi de costos, privadesa i latència que les solucions 100% cloud no sempre poden igualar.