Què és I Agent Local LLM Inference Device Deployment Guide

Si t'estàs plantejant muntar un agent d'IA al teu propi equip i no dependre del núvol, segurament t'hauràs topat amb el terme “I Agent Local LLM Inference Device Deployment Guide” o amb el web llmdev.guide. Darrere aquest nom tan llarg hi ha una cosa molt concreta: una guia pràctica, basada en dades reals, per ajudar-te a triar el maquinari adequat per executar models grans de llenguatge de forma local sense llençar els diners.

La idea que hi ha darrere aquest projecte és senzilla però potent: reunir benchmarks reals, mesurats per la comunitat, dels dispositius més usats per a inferència local de LLMs (sobretot per a agents d'IA) i presentar-los en un format clar, visual i fàcil de comparar. Amb això es pretén contrarestar el mar de xifres inflades, tàctiques de màrqueting dubtoses i especificacions confuses que inunden el mercat d'acceleradors d'IA i GPU.

Què és I Agent Local LLM Inference Device Deployment Guide

L'anomenada “AI Agent Local LLM Inference Device Deployment Guide” és una guia de desplegament enfocada a usuaris individuals que volen executar models grans de llenguatge en local, amb una atenció especial a càrregues de treball d'agents (tipus Claude Code, Cursor, OpenClaw , PicoClaw, etc.). Aquestes càrregues solen consumir una barbaritat de tokens davant d'un simple xat, així que el rendiment del maquinari es torna crític per no desesperar-se esperant respostes.

El projecte s'allotja a llmdev.guide i s'articula com una base de dades oberta i col·laborativa, on la comunitat aporta resultats de rendiment de diferents dispositius executant models concrets. La condició mínima perquè un dispositiu aparegui a la guia és que pugui moure almenys un model del voltant de (9B), és a dir, una cosa raonable per muntar un agent de IA decent.

A més de servir de catàleg, la guia està pensada com una mena d' antídot contra el màrqueting enganyós d'alguns fabricants , que prometen capacitats enormes a TOPS o TFLOPS que després, a la pràctica, no es tradueixen en més tokens per segon. A la guia s'expliquen les tàctiques més típiques d'inflació de xifres perquè no te la colin quan comparis dispositius.

Un altre punt important és que la guia se centra en equips amb un cost habitualment per sota dels 10.000$ , la qual cosa abasta des de PCs amb GPUs de consum, fins a miniPCs, SBCs vitaminades, acceleradors dedicats i algunes estacions de treball més serioses. La idea no és competir amb centres de dades, sinó mostrar què té més sentit per a algú que vulgui muntar el seu propi rig d'IA a casa o oficina i executar LLM a local.

Tàctiques de màrqueting inflades en maquinari d'IA

Un dels valors afegits de la guia és que desmunta diversos trets comercials molt habituals per inflar la “potència de càlcul” d'un dispositiu. Entendre-les ajuda força a interpretar amb cap les especificacions.

Una primera tàctica és utilitzar la “computació dispersa (sparse)” com a xifra principal de TOPS . Molts xips anuncien, per exemple, 200 TOPS, però aquesta xifra només arriba amb sparsity (part dels pesos a zero) i sota condicions molt concretes. El resultat real en models densos pot ser fàcilment la meitat, així que, com a regla general, es considera que hi ha com a mínim un factor 2x d'inflació.

Una altra forma de maquillar números és basar-se en precisions molt baixes com FP4 o INT4 en presentar la potència bruta . Aquestes xifres disparen els TOPS teòrics davant INT8 o FP16, però no sempre són aprofitables ni ofereixen prou qualitat per a tots els models. L'inflat real sol moure's entre 2 i 4 vegades respecte al que veuríem en condicions realistes.

També és força comú el “stacking” heterogeni de còmput , és a dir, sumar al brut la potència de CPU, GPU, NPU, DSP i el que s'intervé, com si tot es pogués utilitzar alhora amb eficiència perfecta. A la pràctica, co-utilitzar bé tots aquests blocs és molt difícil, i el que tens és una xifra global bonica en el paper però poc representativa del que veuràs amb un LLM concret.

Finalment, hi ha dispositius que apilen molta capacitat de còmput amb molt poc ample de banda de memòria . Sobre el paper, semblen bèsties de TOPS, però així que es posen a atendre un model gran de llenguatge acaben totalment escanyats per la memòria. A la guia s'insisteix que el veritable límit de rendiment sol venir més per l'amplada de banda que pels TOPS teòrics.

Com estructura la informació llmdev.guide

El web llmdev.guide ofereix diverses maneres de visualitzar i comparar els dispositius per a inferència local de LLM , pensades per a usuaris amb diferents nivells d'experiència tècnica. No és només una taula plana: hi ha diverses vistes interactives que faciliten molt les comparacions.

D'una banda, tenim un “Leaderboard” clàssic que permet ordenar els dispositius per un únic criteri , com ara velocitat de descodificació (tokens per segon), relació rendiment/preu o eficiència energètica. Aquesta vista és ideal si només us interessa, per exemple, veure quina opció dóna més tokens/s per euro gastat dins del vostre pressupost.

Si vols filar més fi, la guia inclou gràfiques de dispersió 2D en què pots triar quina variable col·locar a cada eix (preu, consum, ample de banda, tokens/s, etc.) i utilitzar la mida de la bombolla per representar una altra mètrica addicional. Això permet veure una ullada, per exemple, quins dispositius ofereixen un equilibri raonable entre cost, rendiment i consum.

Per a qui gaudeixi de les dades al màxim, també hi ha gràfiques 3D interactives on es creuen tres paràmetres alhora, amb bombolles en un espai tridimensional. Encara que és una vista més “friki”, va molt bé per entendre, per exemple, com s'agrupen certs tipus de maquinari en termes de tokens/s, preu i eficiència per watt.

La quarta vista és una taula de dades completa amb totes les especificacions i resultats de benchmarks . Aquí podeu filtrar, ordenar i entrar al detall de cada model de GPU, NPU o sistema. Cada dispositiu té la seva fitxa, amb especificacions tècniques, resultats de proves i notes addicionals, a més denllaços a les evidències de test que hagin aportat els usuaris.

Model unificat de referència: família Qwen 3.5

Per evitar el caos de comparar peres amb pomes, la guia utilitza la família de models Qwen 3.5 com a referència estàndard . La idea és senzilla: si tots els benchmarks es fan amb les mateixes arquitectures de model, la comparació entre dispositius és molt més neta.

Hi ha dos models de la família Qwen3.5 que es consideren obligatoris perquè un dispositiu entri al llistat . D'una banda, Qwen3.5-9B, que fa referència per a dispositius petits o d'entrada. Si el vostre maquinari no pot amb aquest model, difícilment serà recomanable per a agents d'IA exigents.

El segon model obligatori és Qwen3.5-27B, pensat com a referència per a dispositius de gamma mitjana . Si un equip mou raonablement aquest model, ja es considera una cosa sòlida per a usos més seriosos, com a aplicacions professionals de generació de codi, anàlisi de documents o assistents interns.

A més, la guia contempla diversos models Mixture of Experts (MoE) com a opcions opcionals: Qwen3.5-35B-A3B, Qwen3.5-122B-A10B i Qwen3.5-397B-A17B . Cadascú serveix com a referència per a dispositius amb més memòria o ambicions més altes: des d'equips amb força RAM fins a autèntics “flagships” pensats per a tasques molt pesades.

En tots els casos es fixa una quantització mínima de 4 bits (INT4/Q4) , de manera que els resultats siguin comparables i realistes. Si un dispositiu encara no té dades directes per a Qwen 3.5, es pot recórrer de manera excepcional a estimacions basades en models similars, i en aquests casos es marquen amb un asterisc per deixar clar que no són mesures directes.

Quines mètriques de rendiment es mesuren realment

En lloc de perdre's en mil números, la guia se centra en dues mètriques fonamentals per a l'ús interactiu d'agents d'IA : la velocitat de descodificació i la velocitat de prefill, totes dues expressades a tokens per segon.

La velocitat de descodificació (decode speed) és la més important per a l'experiència d'usuari perquè marca quants tokens per segon pot anar generant el model un cop arrenca la resposta. És el que defineix, bàsicament, si veus com el text va sortint amb fluïdesa o estrebades.

La velocitat de prefill (prefill speed) afecta el temps fins al primer token , és a dir, quant triga el sistema a digerir el prompt inicial (que pot ser llarg en agents amb context, eines, historial, etc.) abans de començar a generar la sortida. És crítica en aplicacions on es carreguen contextos enormes o molts documents de cop.

A més d'aquestes dues mètriques principals, la guia presta molta atenció a la relació entre l'amplada de banda de memòria i la velocitat real que s'aconsegueix . De fet, els valors de tokens/s reportats es contrasten amb un sostre teòric calculat a partir de l'amplada de banda disponible, i si les xifres superen el raonable es marquen amb un símbol d'advertència per indicar que alguna cosa fa olor estranya.

Tot això es complementa amb informació sobre consum energètic, preu aproximat, capacitat de memòria, amplada de banda i TOPS declarats , que després s'usen per derivar ràtios com a rendiment per euro o rendiment per watt. Aquestes ràtios són les que permeten veure ràpidament quins dispositius són “gangues” i quins estan clarament sobrevalorats.

Comparacions reals de maquinari: exemples significatius

Un dels casos més il·lustratius que es comenten usant la guia és el de comparar GPUs cares i estacions de treball premium amb opcions força més modestes . En posar totes les dades a la mateixa gràfica, es veu que el preu no sempre es tradueix en més tokens/s.

Per exemple, prenent com a referència Qwen3.5 9B , la guia mostra que equips de més de 4.000$ com un sistema NVIDIA DGX Spark o un Apple Mac Studio amb xip M3 poden acabar oferint un rendiment molt similar en tokens per segon a una màquina muntada amb una GPU molt més terrenal, com una Intel Arc B582 de 1.

A l'altre extrem, si els diners no són un problema i es persegueix la màxima velocitat possible amb models de mida contingut , el lògic és mirar a GPUs topall de gamma, com podria ser una hipotètica NVIDIA GTX 5090 de 32 GB, que ofereix una relació rendiment absolut / cost bastant raonable si només t'importa anar al límit i assumir la inversió.

Quan es puja a models realment grans, com Qwen 122B-A10B , la cosa canvia força perquè la memòria comença a ser el coll d'ampolla. En aquest context, dispositius tipus NVIDIA DGX Spark poden oferir una relació preu/rendiment sorprenentment bona davant de màquines com un Apple Mac Studio M3 Ultra amb 256 GB, principalment per com gestionen la memòria i l'amplada de banda.

Cal tenir en compte, això sí, que no totes les entrades de la guia reflecteixen el mateix nivell de detall sobre el cost : en alguns casos s'indica el preu del sistema complet, i en d'altres només el de la GPU. Tot i així, com a eina de comparació general, la guia permet detectar fàcilment quan un equip està molt sobredimensionat per al rendiment que realment aporta a LLMs.

Opcions de visualització i anàlisi a la guia

La interfície de llmdev.guide permet jugar amb múltiples paràmetres per als eixos X i Y de les gràfiques i per a la mida de les bombolles . Pots triar, per exemple, que l'eix X sigui el preu, l'eix Y els tokens/s de descodificació, i que la mida de la bombolla representi el consum energètic.

També podeu creuar característiques de maquinari (amplada de banda de memòria, capacitat, TOPS declarats) amb resultats d'inferència (velocitat de prefill, velocitat de sortida) o amb ràtios derivats (rendiment per watt, rendiment per dòlar). Això ajuda a detectar patrons, com a dispositius que rendeixen molt per sobre o per sota del que la seva fitxa tècnica faria pensar.

Quant a la part de preus, l'eina no disposa inicialment d'un filtre directe per rang de cost , però sí que ofereix la possibilitat d'usar una escala logarítmica a l'eix de preus perquè les opcions d'entrada i gamma mitjana no quedin aixafades davant de les estacions més cares. A més a més, es pot fer zoom dibuixant un requadre amb el ratolí per centrar-se en un subconjunt concret de dispositius.

Si preferiu alguna cosa més tradicional, la vista en forma de llista amb taula ordenable us permet reordenar les files per qualsevol columna , inclòs el preu. D'aquesta manera podeu veure d'una ullada quin és el dispositiu més barat que compleix certs requisits mínims o quins són els que donen més rendiment dins d'un pressupost concret.

En fer clic en un element de la llista o en una bombolla de la gràfica s'accedeix a una fitxa amb més detalls de cada dispositiu , incloent-hi especificacions tècniques completes, resultats de proves i notes sobre com es va fer el benchmark. És aquí on s'indica si les dades són mesurades o extrapolades, així com qualsevol aspecte peculiar del setup.

Dades comunitàries, estimacions i procés de contribució

Un dels pilars del projecte és que totes les dades de rendiment es nodreixen d'aportacions de la comunitat . No és una bateria de tests tancada realitzada per un únic laboratori, sinó una base de dades viva, a la qual qualsevol pot sumar-ne els resultats si segueixen el procediment establert.

Quan un dispositiu no ha estat provat directament amb Qwen 3.5, alguns resultats poden aparèixer com a estimats a partir d'altres models , com Flama 7B en el cas del Raspberry Pi 5 de 16 GB . Això es fa per oferir una referència aproximada, però es marca explícitament perquè ningú no ho confongui amb mesuraments reals.

El procés de contribució passa per fer un fork del repositori del projecte , copiar una plantilla de dispositiu (devices/_template.md) i emplenar-la amb la informació del maquinari i els resultats obtinguts. A més, es demana adjuntar evidències de les proves, com ara captures de pantalla o sortides de terminal, perquè altres puguin verificar que els números tenen sentit.

És obligatori, almenys, executar Qwen 3.5 9B amb un prompt prou llarg per obtenir dades de rendiment significatives, sobretot en escenaris dús típic dagents dIA. També es recomana fer fotos de la placa o de l'equip utilitzat, i documentar-ne la configuració (quantització, context, backend, etc.).

De moment, el sistema no automatitza la recol·lecció de dades ; cal emplenar-ho tot a mà seguint la plantilla. Alguns usuaris han assenyalat que seria ideal comptar amb scripts tipus “sbc-bench.sh” que executin els tests i enviïn els resultats, però ara com ara l'enfocament manual permet un major control de qualitat i evita que s'omplin les taules de resultats dubtosos.

Context: què són els LLM locals i per què importen

Més enllà de la pròpia guia, convé entendre el context en què sorgeix: els models de llenguatge grans que s'executen en local, sense dependre del núvol , estan vivint un boom. Cada cop més usuaris i empreses volen tenir el seu propi assistent, agent o sistema conversacional corrent a les seves màquines, sense enviar dades sensibles a tercers.

Els LLM locals suposen un canvi respecte als serveis al núvol tradicionals perquè permeten conservar la sobirania sobre les dades i treballar completament offline . En lloc de pagar trucades a una API externa, descarregues el model, l'executes al teu maquinari i controles tant la configuració com les possibles personalitzacions o afinats.

A l'ecosistema actual conviuen models com Flama 3.x, Qwen 2.5/3.5, DeepSeek R1 o Phi-4 , que han anat millorant en eficiència fins al punt que versions de 7B-9B paràmetres ofereixen resultats molt sòlids corrent en una sola GPU de consum o fins i tot només amb CPU.

Per a organitzacions amb càrregues intensives (anàlisi massiva de documents, generació de codi contínua, chatbots interns…), el pas a LLM locals pot significar un estalvi enorme enfront dels costos recurrents de les API comercials , especialment quan es manegen milions de tokens al mes. A això s'hi afegeix el control fi sobre el model i el seu comportament.

Els agents d'IA porten tot això un pas més enllà, perquè no es limiten a respondre preguntes, sinó que encadenen eines, contextos i accions en fluxos força més llargs. Això dispara el nombre de tokens i fa que el rendiment d'inferència del dispositiu sigui un factor encara més determinant, justament el tipus d'escenari per al qual resulta més útil la guia I Agent Local LLM Inference Device Deployment; per dissenyar aquests sistemes convé conèixer les arquitectures d'agents.

Requisits de maquinari per a LLM locals: GPU, CPU i memòria

Un dels grans maldecaps quan algú es planteja muntar un LLM en local és entendre quin maquinari necessita realment i quina part del pressupost té més impacte . La GPU i la memòria (VRAM i RAM) solen ser els factors decisius, però no els únics.

Al terreny de les GPUs, la clau està en la quantitat de VRAM i l'amplada de banda . Per a models d'entrada de 7-8B paràmetres (tipus Truca 3.1 8B o Qwen 2.5 7B) una GPU amb 8-12 GB de VRAM sol ser suficient, sobretot si es fan servir quantitzacions de 4 bits. Això cobreix casos d'ús generals i projectes personals sense gaires complicacions.

Si l'objectiu és pujar a models de 14-32B paràmetres (com Qwen 2.5 14B o DeepSeek R1 32B), el raonable és apuntar a GPUs amb 16-24 GB de VRAM , oa configuracions multi-GPU en certs casos. A partir de 70B paràmetres, la cosa es dispara i ja parlem de 48 GB o més, sovint en sistemes amb diverses GPU de gamma alta o acceleradors dedicats per a empreses.

Hi ha una regla aproximada per calcular quanta memòria requereix un model : M = (P × Q/8) × 1,2, on M és la memòria en GB, P el nombre de paràmetres en milers de milions i Q la precisió en bits. Així, un model de 70B a 16 bits pot rondar els 168 GB de VRAM, mentre que amb quantització a 4 bits es quedaria a prop dels 42 GB. A partir d´aquí es pot ajustar segons el backend i els buffers addicionals.

El paper de la CPU no s'ha d'infravalorar: processadors moderns amb bones extensions vectorials i bona amplada de banda de memòria poden moure models més petits amb un rendiment sorprenent. Exemples recents mostren CPUs com a certs Ryzen AI capaços de superar els 50 tokens/s amb models lleugers, cosa que obre la porta a setups sense GPU per a alguns usos.

Eines populars per desplegar LLM locals

Un cop clar el maquinari, el següent pas és triar la plataforma de programari per gestionar els models i la inferència . Aquí es combinen eines pensades per a usuaris principiants amb altres orientades a esprémer fins al darrer cicle de CPU o GPU.

Ollama s'ha consolidat com una de les opcions més amigables per començar . Funciona amb un enfocament tipus “Docker per a models”, permetent descarregar i llançar models amb ordres molt senzilles. Gestiona automàticament quantització, ús de GPU i memòria, i exposa una API compatible amb OpenAI, cosa que simplifica molt integrar un agent o un chatbot a les teves pròpies aplicacions.

Per als qui prefereixen una interfície gràfica acurada, LM Studio ofereix un entorn visual molt polit per descobrir, descarregar i provar models . S'integra directament amb Hugging Face, disposa d'interfície de xat i facilita canviar de model, quantització o backend sense tocar la línia d'ordres, a costa de perdre una mica de flexibilitat extrema.

A l'extrem més tècnic, llama.cpp segueix sent el referent quan es busca el màxim rendiment i control fi . És una implementació en C++ molt optimitzada, amb suport per a múltiples backends (CUDA, Metall, Vulkan…) i tècniques de quantització avançades. A més, ha anat millorant notablement en arquitectures ARM, cosa que beneficia tant portàtils amb Apple Silicon com equips amb Snapdragon X i similars.

Al costat d'aquestes, hi ha projectes com GPT4All o LocalAI que aposten per una experiència d'escriptori unificada o per exposar API locals molt fàcils d'integrar. A més, apareixen alternatives com Jan AI entre les opcions per als que busquen una experiència local similar a ChatGPT. L'elecció depèn de l'equilibri que cada persona cerqui entre simplicitat, rendiment i capacitat de personalització.

Estratègies de desplegament i optimització per a agents d'IA

Quan l'objectiu és executar agents d'IA més complexos (amb trucades a eines, navegació, cadenes de raonament llargues, etc.), entren en joc estratègies d'optimització addicionals per treure partit del maquinari que ja tens o que vagis a comprar seguint la guia.

La quantització és el primer gran aliat: treballar en 4 bits sol donar una relació molt bona entre qualitat i mida , permetent que models de 7-9B càpiguen còmodament en GPUs de 8-12 GB i que dissenys de 30B o més puguin moure's en GPUs de 24 GB o configuracions multi-GPU. Per a casos on es necessiti màxima qualitat, 8 bits ofereix un equilibri intermedi encara força compacte.

També és clau ajustar paràmetres com la longitud de context, la mida de lot (batch) i el nombre de capes que s'offloadegen a GPU en configuracions híbrides CPU/GPU. Augmentar el context millora la capacitat de manejar historials llargs, però dispara el consum de memòria; afinar aquests valors segons l‟ús concret de l‟agent és fonamental.

En entorns empresarials o de laboratori, té sentit plantejar-se configuracions multi-GPU i desplegaments distribuïts , usant tècniques com el paral·lelisme de tensors per dividir grans models de 70B o més entre diverses targetes. Frameworks com vLLM o certes interfícies web avançades ofereixen suport directe per a aquests modes, encara que exigeixen més coneixements de sistemes.

Finalment, des del punt de vista de costos, el desplegament local sol tornar-se molt competitiu davant del núvol quan el volum de tokens processats és alt i el maquinari s'amortitza a mitjà termini. La guia de dispositius ajuda precisament a trobar el punt dolç entre la inversió en equip, el cost energètic i el rendiment, perquè l'equació surti a favor del desplegament local d'agents.

Tenint al cap totes aquestes peces -dades de benchmarks reals, mètodes per filtrar màrqueting inflat, mètriques rellevants i eines de desplegament- la I Agent Local LLM Inference Device Deployment Guide es converteix en una referència molt útil per a qualsevol que vulgui muntar agents de IA en local amb cap: ajuda a prioritzar ample de banda Qwen 3.5 utilitzar com a prova de foc i ofereix comparacions clares de preu, rendiment i eficiència per triar maquinari sense pagar de més.