Recomanacions de rendiment i gestió de memòria per a Ollama

Si estàs pensant en muntar un servei privat de LLMs amb Ollama , ja sigui al teu propi ISP rural, en un petit datacenter o en un PC potent a casa, el gran dubte sempre és el mateix: com esprémer al màxim el rendiment sense llençar els diners en maquinari que després no aprofites?

En el món dels models de llenguatge grans, VRAM, RAM, CPU, GPU, quantització i context no són simples paraules tècniques: són les peces que determinaran si el teu clúster vola o s'arrossega. A més, Ollama i llama.cpp gestionen la memòria i el repartiment CPU/GPU de manera diferent, i entendre això és clau per decidir si et compensa un node gros amb diverses GPU o diverses màquines més modestes 1:1 per client.

Agrupar GPU en un clúster o dedicar-les 1:1: què convé per a Ollama

Quan planteges un SaaS privat amb Ollama, el primer dilema és si muntar un pool centralitzat de GPU o assignar una màquina (o GPU) per client. Aquí entra en joc com Ollama i llama.cpp usen els recursos:

• Node “monstre” amb diverses GPU: ideal si vols cues de peticions compartides, aprofitar al màxim la GPU amb molts usuaris simultanis i consolidar administració i manteniment.
• Màquines 1:1 per client: més aïllament, menys embolics de multitenant, predictible en consum de recursos i molt còmode per a clients que paguen per “la seva” màquina.

Ollama actualment se centra més a aprofitar una o diverses GPU locals per instància que a orquestrar un clúster distribuït tipus Kubernetes amb repartiment fi entre màquines. Per a un ISP petit que vol donar servei a “usuaris pro”:

• Si l'objectiu és simplicitat operativa, unes quantes màquines ben dimensionades (16-24 GB VRAM cadascuna) amb Ollama per node i repartiment de clients per servidor solen ser l'opció més assenyada.
• Si vols jugar a “mini-hyperscaler”, pots plantejar un servidor gros amb diverses GPU i un proxy (o diverses instàncies d'Ollama/llama.cpp) per a cada client, però la complexitat de scheduling i aïllament puja força.

El factor determinant no és només la topologia, sinó quins models serviràs, amb quin context i quantes sessions concurrents . Això condiciona directament quanta VRAM necessites per usuari.

Com gestiona Ollama la memòria, la VRAM i el repartiment CPU/GPU

Ollama es recolza internament en llama.cpp i altres backends , però afegeix una capa d'orquestració que simplifica molt la teva vida. A nivell de memòria i rendiment, hi ha diversos punts clau:

Mapeig de models i càrrega en memòria

truca.cpp utilitza mmap per mapejar el fitxer GGUF del model a l'espai d'adreces. Això permet que el sistema operatiu decideixi quines parts estan efectivament en RAM a cada moment, reduint el temps de càrrega inicial respecte a bolcar tot el fitxer a memòria de cop.

Ollama, per la seva banda, s'encarrega de:

• Carregar i descarregar models de VRAM/RAM segons activitat, respectant el temps de OLLAMA_KEEP_ALIVE.
• Compartir models entre sessions de la mateixa instància per evitar recàrregues innecessàries.
• Mostrar-te amb ollama ps l'ús de memòria, la divisió CPU / GPU i si hi ha descàrrega de capes al processador.

A la pràctica, quan veus un model amb, per exemple, 18%/82% CPU/GPU , significa que una part de les capes no ha cabut en VRAM i s'està executant a la RAM del sistema via CPU, amb el consegüent impacte en velocitat, com mostren diverses anàlisis de latència en xarxes locals.

Què passa si el model no hi cap a VRAM?

Aquí hi ha una de les preguntes més importants: si un model entra totalment a VRAM obtens el rendiment esperat al 100% . Però quan el model excedeix la VRAM disponible, Ollama reparteix capes entre GPU i CPU. Es degrada el rendiment de forma proporcional a les capes que cauen a RAM, o t'encadena per complet a la velocitat de la RAM i el bus?

Les dades pràctiques amb una RTX 4080 de 16 GB són demolidors:

• Models 100% GPU: de l'ordre de 60 a 140 tokens/s (p. ex. gpt-oss:20b amb 14 GB usats arriba a ~140 tok/s).
• Models 70-80% GPU (resta en CPU): baixen a ~19-50 tok/s.
• Models amb ~20% GPU (majoria en CPU): es queden en ~12 tok/s (cas gpt-oss:120b, 66 GB de RAM+VRAM usats).

És a dir, no és un simple “perd un 30% de rendiment perquè el 30% és a CPU”, sinó que la latència de moure dades entre RAM i VRAM i d'executar capes a CPU multiplica el coll d'ampolla . Un 20B totalment a GPU pot ser 10-11 vegades més ràpid que un 120B majoritàriament a CPU.

Així que, per al teu clúster: l'objectiu nº1 és ​​que els models crítics d'ús interactiu càpiguen sencers a VRAM . El que no entri, millor reservar-ho per a tasques batch, nocturnes o de baixa prioritat.

Models MoE (Mixture of Experts) i descàrrega a CPU

Models tipus Mixture of Experts (com GLM 4.7 Flash o alguns Qwen i DeepSeek) tenen molts paràmetres totals, però només activen una fracció d'experts per token. Això, en teoria, pot ajudar en escenaris de VRAM limitada perquè no totes les parts del model es fan servir alhora.

A la pràctica, amb Ollama:

• Un MoE de 30B-A3B (30B totals, 3B actius) com glm-4.7-flash es mou sobre els 30-35 tok/s amb descàrrega parcial al CPU, força digne per a la seva mida.
• L'avantatge MoE no compensa si el model segueix excedint la VRAM i obliga a moure moltes capes pel bus.
• Ollama no “entén” el MoE com una cosa especial a nivell de scheduler, simplement veu capes i memòria. La màgia MoE és a l'arquitectura del model, no a Ollama.

Conclusió pràctica: MoE ajuda, però no obra miracles . Si sobrepasses molt la VRAM, continuaràs pagant la factura de la RAM i la CPU. Millor utilitzar MoE per esprémer una mica més el límit, no per justificar treballar sempre fora de VRAM.

Comparativa crida.cpp vs Ollama per esprémer el maquinari

Molts debats comencen amb la típica pregunta: “per què fer servir Ollama i no truca.cpp directament?”. A nivell de rendiment i gestió de memòria, val la pena distingir molt bé els papers de cadascun.

llama.cpp: el quiròfan dels tensors

llama.cpp és el motor C++ d'alt rendiment . El seu objectiu és esprémer fins a l'últim cicle de CPU i de GPU, amb especial cura de CPU x86 amb AVX, Apple Silicon i GPU NVIDIA/AMD. Està pensat per a qui vol:

• Ajustar quantització al detall (Q4_K_M, Q5_0, Q8_0, Q2_K…).
• controlar nombre de capes a GPU amb --n-gpu-layers.
• Fer servir context, batch, nombre de fils, gramàtiques GBNF i altres paràmetres fins.

Nivell baix, sí, però molt potent. A nivell de memòria:

• EUA mmap per carregar el model i deixa al nucli decidir què es manté en RAM.
• Permet triar amb precisió quines capes passen a GPU amb -ngl, ajustant el consum de VRAM al mil·límetre.
• Integra K-Quants per reduir mida amb el menor impacte possible en qualitat.

En resum: llama.cpp és perfecte si vols muntar el teu propi servei súper optimitzat on tu envies a cada paràmetre i no t'importa embrutar-te les mans amb opcions de línia d'ordres i configuració avançada.

Ollama: l'orquestrador de backends

Ollama està escrit a Go i es recolza en llama.cpp (i altres motors com vLLM en alguns escenaris) com a backend. La seva proposta és donar-te una experiència tipus “Docker per a models” :

• CLI simple: ollama pull, ollama run, ollama list, ollama ps.
• API de REST en 127.0.0.1:11434 per defecte, llesta per connectar GUIs com Open WebUI o aplicacions pròpies.
• Gestió de models: descàrrega des del vostre registre, actualització, emmagatzematge local, còpia i push dels vostres propis models.
• Detecció automàtica de maquinari: analitza GPU, RAM i context per ajustar capes GPU/CPU sense que toquis --n-gpu-layers.

La diferència real és de nivell d'abstracció : truca.cpp és el motor en brut, Ollama és el cotxe complet llest per conduir. A canvi d'una mica menys de control extrem, obtens:

• Arrencar models amb una sola ordre.
• Cues de peticions i descàrrega automàtica després d'inactivitat (OLLAMA_KEEP_ALIVE).
• Integració directíssima amb GUIs i frameworks.

Per a un usuari final o per donar servei generalista a clients d'un ISP, Ollama sol ser l'opció clara . Per a models XXL molt ajustats o per treure tot el suc a una GPU concreta, truca.cpp pot tenir un lleuger avantatge si ho saps tunejar bé.

Recomanacions de maquinari: VRAM, RAM, CPU i disc per a Ollama

Per dimensionar el teu clúster, no n'hi ha prou amb mirar la GPU. L'equilibri entre VRAM, RAM, CPU, disc i context mana més del que sembla.

VRAM: el recurs crític

La VRAM és el coll principal. A nivell orientatiu:

• VRAM de 8 GB: suficient per a models petits/mitjans quantitzats (7B, algun 13B en Q4_K_M amb context modest).
• VRAM de 16 GB: punt dolç actual per a ús seriós: 14B, 20B, 24B a Q4_K_M totalment a GPU amb contextos de ~16-32K.
• 24 GB o més: necessari si vols 30B-35B amb context ampli a GPU o manejar diverses sessions concurrents de models mitjans sense començar a descarregar capes.

Alguns valors pràctics en una RTX 4080 16 GB amb context ~19K i quantització Q4_K_M:

• gpt-oss:20b (20B): ~14 GB, 100% GPU, ~140 tok/s.
• qwen3:14b: ~12 GB, 100% GPU, ~62 tok/s.
• mestral-3:14b: ~13 GB, 100% GPU, ~70 tok/s.

Qualsevol model que superi aquests marges acaba barrejant CPU/GPU. En el teu projecte, si vols donar context gran tipus 80-100K a diversos usuaris, cada salt en context també augmenta el consum efectiu de VRAM perquè la KV cau cau creix.

RAM del sistema i CPUs: més importants del que sembla

Quan Ollama descarrega capes al CPU, el teu processador es torna part del motor d'inferència . A les proves amb un i7-14700 (8P+12E) i 64 GB DDR5-6000:

• Models amb un 20-30% de capes a CPU segueixen sent usables (~30-50 tok/s).
• Quan el percentatge de CPU puja del 50%, l'experiència de xat es comença a sentir pesada, sobretot si el context és gran.

Recomanacions assenyades per a un node de servei:

• RAM mínima 16 GB: només per jugar amb 7B i 13B lleugers.
• RAM recomanada 32-64 GB: per a ús seriós multiusuari amb models de 14-24B i context ampli.
• CPU amb almenys 8 nuclis (o combinació P+E moderna) per esmorteir la descàrrega de capes sense que el node es col·lapsi, i també considerar com configurar perfils de rendiment en sistemes Windows si apliqués.

Disc: l'elefant silenciós

Els fitxers de models pesen una barbaritat. La quantització ajuda, però així i tot:

• Models petits quantitzats: ~2 GB.
• Models mitjans quantitzats: 5-20 GB.
• Models grans: fàcilment 40-200 GB o més; hi ha checkpoints que sobrepassen 1 TB.

Com a regla ràpida, reserva sempre un marge d'almenys 2-3 vegades la mida de cada model entre fitxer base, variants, caixets i logs, i valora opcions d' emmagatzematge local davant del núvol híbrid . I utilitza SSD NVMe : els temps de càrrega i la paginació de mmap ho agraeixen moltíssim.

Quantització, context i elecció de models: impacte directe en rendiment

Encara que de vegades es passa per alt, la quantització que triïs i la longitud de context marquen enorme diferència en consum de memòria i velocitat.

La “pedra rosetta” de la quantització

De manera simplificada, podeu pensar en aquestes variants:

• FP16: model gairebé sense compressió, màxima qualitat, mida brutal. Requereix molta VRAM/RAM.
• Q8_0: compressió suau, qualitat gairebé idèntica a FP16, però mida encara gran.
• Q4_K_M: l'estàndard “equilibrat” per a ús local. Redueix la mida a la meitat amb només ~1-2% de pèrdua de precisió mitjana. És l'opció recomanada per a la majoria de desplegaments.
• Q2_K: compressió extrema, mida mínima, però el model es torna clarament menys fiable, amb més al·lucinacions.

A la pràctica, per a un SaaS local amb diversos clients, apostar per models Q4_K_M és la millor relació qualitat/rendiment/consum de VRAM. Q8_0 és útil si tens molta VRAM i vols esprémer una mica més de qualitat en un model petit/mitjà.

Longitud de context (num_ctx) i el seu cost ocult

El paràmetre num_ctx a Ollama/llama.cpp defineix quants tokens pot “veure” el model alhora: sistema, historial de xat, prompt actual i resposta. A nivell conceptual:

• Finestres petites (2K-4K): menys memòria, més rapidesa, però perds context en converses llargues o documents grans.
• Finestres mitjanes (8K-32K): punt mitjà raonable per a la majoria d'usos professionals.
• Finestres gegants (64K-128K+): espectaculars sobre el paper, però consumeixen molta més VRAM i empitjoren el rendiment si el maquinari va just.

A més, si forces un num_ctx superior al context amb què el model va ser entrenat , pots trobar-te amb comportaments rars i baixades de qualitat. No n'hi ha prou de pujar el valor a la configuració, hi ha un límit arquitectònic.

Per al teu escenari, el que és sensat és:

• oferir plans “normals” amb context 8K-16K, que caben bé a VRAM.
• Reservar ara contextos 64K-100K només per a màquines o GPUs premium, i assumir la caiguda de tokens/s.

Bones pràctiques de rendiment i gestió de memòria amb Ollama

Més enllà del maquinari, hi ha diverses decisions de configuració i arquitectura que poden marcar la diferència a l'hora que el clúster vagi fi.

Assegura que els models crítics estiguin 100% a GPU

Abans de donar un model a un client, convé provar-ho i comprovar amb ollama ps que el camp PROCESSOR indica 100% GPU quan està en ús. Si veus divisions tipus 60/40 CPU/GPU o pitjors, toca:

• Passar a una quantització més agressiva (per exemple de Q8_0 a Q4_K_M).
• Fer servir un model més petit (per exemple 20B en comptes de 35B).
• reduir num_ctx si el client pot viure amb un context una mica menor.

És preferible un 20B ben afinat a 140 tok/s que un 120B arrossegant-se a 12 tok/s per a xat interactiu. Els usuaris valoren molt més la fluïdesa de lexperiència que una hipotètica millora de qualitat difícil de percebre.

Ajusteu OLLAMA_KEEP_ALIVE i l'estratègia de models carregats

El paràmetre OLLAMA_KEEP_ALIVE defineix quant de temps manté Ollama un model en memòria després de l'última petició. Valors possibles:

• 0: es descarrega just en acabar la resposta. Estalvia memòria, però penalitza amb temps de càrrega constants.
• X m (p. ex. 5m, 15m): equilibra RAM/VRAM i agilitat. Ideal per a serveis amb pics puntuals.
• -1: el model es queda sempre carregat mentre el servei està actiu. Molt útil per a models “estrella” del teu SaaS.

En un escenari multiusuari sol funcionar bé mantenir un o dos models base sempre carregats (per exemple, un 14B generalista i un altre de codi) i descarregar la resta després d'uns minuts d'inactivitat.

Control de variables dentorn i rutes de models

Ollama permet ajustar el comportament amb diverses variables d'entorn que influeixen en com es gestionen recursos i accés:

• OLLAMA_MODELS: ruta on s'emmagatzemen els models. Interessant per enviar-los a un disc/SSD dedicat de més capacitat.
• OLLAMA_HOST: interfície i port de l'API (per defecte 127.0.0.1:11434). Si l'exposes a LAN, limita bé el tallafocs.
• OLLAMA_ORIGINS: CORS per a GUIs web externes (Open WebUI, panells propis, etc.).
• OLLAMA_DEBUG: mode debug per veure logs detallats de càrrega de models, detecció de GPU, errors de CUDA/ROCm, etc.

A Linux, aquests paràmetres se solen configurar mitjançant systemd (Amb systemctl edit ollama.service), mentre que a Windows i macOS s'estableixen com a variables d'entorn del sistema o de l'usuari.

Monitorització i logs

En un clúster, necessites tenir clar què passa a cada node. Per això:

• A Linux, utilitza journalctl -u ollama per seguir els logs del servei. Amb -f ho veus en temps real.
• Complementa amb nvidia-smi o equivalent en AMD per veure VRAM, càrrega de GPU i consum.
• Integra mètriques (tokens/s, cues, errors) al teu stack d'observabilitat si vas de debò amb el SaaS.

Detectar a temps que un model s'està executant majoritàriament a CPU, o que s'han quedat cues encallades, t'estalvia molts disgustos amb clients; i eines per descobrir la IP a la teva xarxa local poden ajudar a l'inventari de nodes.

Elecció de models i casos d'ús típics a Ollama

Amb tot això, l'altra pota del rendiment és triar el model adequat per a cada tasca , no només per “anar al màxim” sinó també per controlar consum i latència.

Models per a xat general i assistents

Per a converses, suport, redacció de correus, resums i tasques generals, models com:

• Qwen3 14B: excel·lent seguiment d'instruccions i bona velocitat en 100% GPU.
• Mistral 3 14B: molt equilibrat en qualitat de llenguatge i rendiment.
• Gemma i Flama 3.x en configuracions de 7-14B: bones opcions generalistes per a usuaris menys exigents o maquinari més just.

Amb aquestes famílies a Q4_K_M i context 8K-16K tens una base sòlida per a la immensa majoria d'usuaris professionals sense saturar la VRAM.

Models per a codi i desenvolupament

Per a generació de codi, revisió i tasques de desenvolupament, convé optar per models específics:

• qwen3-coder:30b: fort en programació i eines, encara que part del model acaba en CPU a 16 GB VRAM.
• DeepSeek-coder, CodeFlama i altres variants de codi per a mides menors, si vols més lleugeresa.

Si oferiràs “plans de desenvolupador”, planteja't un node amb més de 16 GB de VRAM per allotjar aquests models sense patir massa la descàrrega a CPU.

Models multimodals i visió

Per a tasques que combinen text i imatge (anàlisi de captures, documents escanejats, etc.), els models amb etiqueta Vision (clau, moondream, bakllava, qwen-vl…) són els que has de muntar. Aquí:

• El consum de VRAM augmenta i la velocitat de tokens sol ser més baixa.
• Convé limitar-los a tasques concretes i no barrejar-los amb xat intensiu de molts usuaris.

Si teniu un pool de GPU mixt (per exemple 5070 + 5060 + 4060, 48 GB VRAM total), pot ser interessant dedicar una de les targetes a models de visió i una altra a text pur, evitant saturar un únic dispositiu amb tot.

Instal·lació, desplegament i variants d'execució (natiu, Docker, contenidors)

A nivell operatiu, Ollama es pot instal·lar de diverses maneres: nadiu a Windows, macOS o Linux, oa contenidors (Podman, Docker…).

A Linux, per exemple, pots desplegar truca.cpp en un contenidor optimitzat amb GPU:

Description=llama
After=network-online.target


Image=ghcr.io/ggml-org/llama.cpp:server-cuda
ContainerName=llama
PublishPort=8000:8000
AddDevice=nvidia.com/gpu=all
Environment=NVIDIA_DRIVER_CAPABILITIES=all
Environment=NVIDIA_VISIBLE_DEVICES=all

Exec=--host 0.0.0.0 \
     --port ${PORT} \
     -m ${MODEL_PATH} \
     -ngl ${NGL} \
     -c ${CONTEXT_SIZE} \
     --flash-attn on \
     --batch-size ${BATCH}

Volume=/data/models:/models:Z
Network=llama.network


Restart=always
Environment=PORT=8000
Environment=MODEL_PATH=/models/gemma-4-E4B-it-Q8_0.gguf
Environment=NGL=99
Environment=CONTEXT_SIZE=128000
Environment=BATCH=512


WantedBy=default.target

Aquest tipus de desplegament us permet separar Ollama, llama.cpp i altres eines en contenidors, controlar versions i aïllar recursos per servei (i, si voleu, per client).

Per gestionar models de Hugging Face a GGUF o Safetensors, pots fer servir eines com rust-hf-downloader i després importar-los a Ollama mitjançant Modelfiles , on defineixes FROM, TEMPLATE, paràmetres per defecte i prompt system, a més de mantenir sincronització i backups locals dels artefactes si treballes amb diversos

Un cop tens les peces muntades, la resta són decisions de governança: quins models ofereixes a quins clients, quins límits de context i quina és la política d'actualitzacions i quantitzacions per no trencar compatibilitat ni rendiments esperats.

Si tens clar que la prioritat és que els models entrin complets en VRAM, que la quantització es mantingui en un equilibri raonable (Q4_K_M) i que el context no es dispari més enllà del que el teu maquinari pot suportar, muntar un SaaS privat d'Ollama sobre un clúster de inversió on deixa de ser ciència aporta, cuides la RAM per suportar descàrregues puntuals i uses les eines d'orquestració (Ollama, truca.cpp, contenidors, Open WebUI) per donar als teus clients l'experiència de “ChatGPT privat” però amb les teves pròpies regles i sense dependre del núvol.