@@ -212,34 +212,49 @@ Aquest punt és fàcil d'infravalorar: deu usuaris fent consultes curtes poden p
Per evitar que una sola sessió monopolitzi la GPU, convé combinar **límits de context per usuari al gateway**, un context màxim del servidor dimensionat al pitjor cas útil —no al màxim teòric del model—, un límit de seqüències actives simultànies al servidor i prioritats diferenciades per tipus d'usuari o de càrrega.
A més de limitar el consum, convé **recuperar capacitat** aprofitant que bona part del context sovint és compartit: el mateix prompt de sistema, el mateix preàmbul de RAG o les mateixes instruccions inicials d'un agent es repeteixen entre peticions. Reutilitzar la cache d'aquests prefixos en lloc de recalcular-los allibera KV cache i còmput, i en desplegaments compartits sovint és l'ajust que més mou la capacitat efectiva. És complementari als límits: els límits eviten que algú consumeixi massa, mentre que la reutilització fa que el consum legítim costi menys.
La regla pràctica és simple: si el sistema ha de ser compartit, ha de poder decidir **qui espera, quant pot consumir cadascú i quines peticions passen primer**.
Sense això, compartir GPU no és servir un servei multiusuari; és deixar competir peticions fins que la latència es dispara o la capacitat es col·lapsa.
### Càrregues heterogènies a la GPU
Aquest capítol se centra en eines de programació, però la mateixa GPU institucional sovint ha de servir més coses que això. La secció anterior tracta com es reparteix la GPU entre peticions d'un mateix servei; aquí el problema s'eixampla a **càrregues de naturalesa diferent** que competeixen per la mateixa targeta: el model d'instrucció compartit, models privats o a mida, models que no són LLM (models de visió purs, ASR, NLP clàssic). La pregunta no és només "qui espera", sinó "què mereix ocupar la GPU".
Aquest capítol se centra en eines de programació, però la mateixa GPU institucional sovint ha de servir més coses: el model d'instrucció compartit, models privats o a mida i models que no són LLM (visió, ASR, NLP clàssic). La secció anterior decidia **en quin ordre se serveixen les peticions d'un mateix model**; aquí la pregunta s'eixampla a **quins models mereixen ocupar la GPU** quan n'hi ha de tota mena competint per la mateixa targeta.
#### On executar un model
#### Decidir per mida, no per família
El que determina si un model necessita GPU és sobretot la combinació de **mida**, **latència objectiu** i **throughput exigit**, no la seva família. Molts models que no són LLM (un regressor, un classificador, molts pipelines de NLP clàssic) corren perfectament a la CPU; en canvi, un model de visió gran amb molta càrrega sí que la necessita.
La intuïció habitual ("els LLM van a la GPU, la resta a la CPU") és massa simple. El que determina si un model necessita GPU és sobretot la combinació de **mida del model**, **latència objectiu** i **throughput exigit**, no la seva família. Molts models que no són LLM (un regressor, un classificador tabular, molts pipelines de NLP clàssic) corren perfectament a la CPU amb latència acceptable. En canvi, un model de visió gran amb molta càrrega sí que la necessita.
La regla pràctica és **partir de la CPU i escalar a la GPU només quan cal**. Per defecte, serveix els models petits i de poca càrrega a la CPU, sovint dins de la mateixa aplicació que els consumeix. Mou un model a la GPU només quan ho justifiqui:
La regla pràctica habitual és: **per defecte, serveix els models petits i de poca càrrega a la CPU, sovint dins de la mateixa aplicació que els consumeix**, i reserva la GPU per als models que de debò la necessiten per mida o per throughput. Així la GPU no es fragmenta amb models que no n'aprofiten res, en coherència amb el corol·lari de la secció de VRAM: cada model carregat comprimeix el pressupost dels altres.
-**mida**: no cap a la VRAM o va massa lent a la CPU;
-**latència**: cal resposta ràpida sota càrrega;
-**throughput**: moltes inferències per segon que aprofiten el *batching*.
#### Dos plans d'accés diferents
Així la GPU no es fragmenta amb models que no n'aprofiten res: cada model carregat comprimeix el pressupost de tots els altres.
No tots els models es consumeixen igual:
Un factor que desplaça el llindar és la **quantització**: el mateix model pot ser viable a la CPU o requerir GPU segons la precisió amb què es desplega. Un LLM de 7B en precisió alta ocupa ~14 GB; quantitzat a 4 bits n'ocupa uns 4,5 GB i pot córrer raonablement a la CPU per a càrregues baixes. El criteri no és el nom del model ni els paràmetres nominals, sinó la **memòria que ocupa amb la precisió triada**.
-**Pla LLM**: els models que parlen el dialecte OpenAI-compatible passen pel gateway, com la resta del servei. Aquí encaixen tant el model d'instrucció compartit com els LLM a mida —inclosos els **VLM** (models de visió-llenguatge com Qwen3-VL o GLM-4.6V), que vLLM serveix pel mateix endpoint `/v1/chat/completions`.
-**Pla a mida**: els models que no parlen aquest dialecte —models de visió purs (detecció, segmentació, classificació amb entrada tensorial), ASR, predictors numèrics— acostumen a exposar el seu propi protocol i sovint es contacten directament, no a través del gateway OpenAI. Si es volen governar amb una capa comuna, normalment s'hi posa un gateway o proxy específic per a aquell tipus de servei, no pas el gateway OpenAI del pla LLM.
Com a orientació, aquests són casos habituals. La columna "On" és un punt de partida, no una regla fixa: davant del dubte, decideix amb les tres variables (mida efectiva amb la quantització triada, latència, throughput).
#### LLM a mida amb adaptadors
| Tipus de model | On | Per què |
| --- | --- | --- |
| NLP clàssic i models tabulars (regressors, classificadors) | CPU | Pocs paràmetres i latència baixa de sobres |
| Embeddings petits a poc volum | CPU | Model petit i càrrega baixa |
| LLM d'instrucció i LLM a mida | GPU | Mida gran i throughput per *batching* |
| VLM (visió-llenguatge) | GPU | Mateixes exigències que un LLM gran |
| Visió gran amb molta càrrega | GPU | Mida i throughput |
| ASR i detecció d'objectes | Depèn | Petit o fora de línia cap a CPU, gran o en temps real cap a GPU |
| Embeddings o reranking a gran volum | Depèn | Volum alt cap a GPU, esporàdic cap a CPU |
Quan calen diversos LLM personalitzats, carregar-ne molts de sencers consumeix la VRAM molt de pressa. L'opció més econòmica és **un sol model base més adaptadors lleugers** (per exemple LoRA), que comparteixen els pesos base i només afegeixen un cost petit per adaptador. Així es poden servir moltes variants sense multiplicar el cost fix.
#### Integració en el stack
#### Quan cal un servidor multi-model
L'arquitectura de tres capes (servidor d'inferència, gateway, clients) de la secció anterior s'aplica directament als LLM i VLM. Per als models heterogenis cal decidir, model a model, com s'hi integren o si en queden fora. Hi ha tres decisions que l'arquitectura general no cobreix:
Per als models a mida que sí que necessiten la GPU, un **servidor multi-model dedicat** (per exemple Triton) pot tenir sentit quan cal allotjar models heterogenis sobre una mateixa targeta amb *batching* dinàmic, versionat i càrrega i descàrrega sota demanda. No acostuma a compensar per a un model petit de CPU que ja se serveix bé dins de la pròpia aplicació: hi afegeix complexitat operativa sense cap benefici. La pauta és usar-lo **on les seves capacitats es paguen soles** (residència a GPU, compartició de targeta, *batching*), i deixar el cas simple simple.
-**Per on s'exposa cada model.** Els que parlen el mateix dialecte que els LLM (una API compatible) entren directament al stack existent (vLLM com a servidor, LiteLLM com a gateway). Els que no hi encaixen (visió pura, ASR, predictors numèrics) parlen protocols propis i necessiten el seu propi servidor i, si molts equips els comparteixen, el seu propi punt de control. Un model estrictament intern pot no necessitar cap gateway; un de compartit, sí.
-**Com conviuen molts models en una targeta.** Un servidor multi-model centralitza el *batching*, el versionat i la càrrega sota demanda. La **càrrega sota demanda** és clau quan molts models s'usen poc: en lloc de tenir-los residents ocupant VRAM, es carreguen amb la primera petició i es descarreguen quan queden inactius, a canvi d'una latència d'arrencada en fred. Per als LLM a mida, l'alternativa a carregar models sencers (que esgoten la VRAM) és servir un sol model base amb **adaptadors lleugers** (LoRA) que comparteixen els pesos i afegeixen un cost marginal per variant. Per a casos d'alt volum molt concrets, com els embeddings, sol compensar un servidor especialitzat en lloc del servidor d'LLM general.
-**Com es reparteix el maquinari.** Es pot **partir la targeta** en instàncies aïllades, amb memòria i còmput propis (MIG), o **compartir-la** sense aïllament estricte. La partició dóna latència previsible i separa bé càrregues dispars; la compartició aprofita millor una targeta infrautilitzada, a canvi d'interferència. És complementari al servidor multi-model: el servidor reparteix models dins d'un procés; la partició, el maquinari per sota.
