@@ -64,7 +64,6 @@ Això no invalida l'autoallotjament, però sí que exigeix preguntar: **per a qu
La conclusió pràctica és que l'autoallotjament no és "la mateixa cosa però gratis i amb control". És un conjunt diferent de *trade-offs*: menys qualitat màxima a canvi de més control, privacitat i independència. Decidir-lo bé requereix saber quins *trade-offs* són acceptables per als patrons d'ús concrets de l'organització.
## Requisits dels models
### Capacitats mínimes
@@ -75,8 +74,8 @@ La capacitat d'**instruction-following** és el mínim per a qualsevol ús de xa
@@ -125,7 +124,7 @@ La forma més estable de desplegar aquest stack és separar tres peces:
És la capa que carrega pesos, tokenitza, genera i retorna respostes.
Les seves responsabilitats centrals són servir un o més models, gestionar VRAM i concurrència, fer streaming, exposar tool calling i maximitzar el throughput sota càrrega. **Ollama** és l'opció senzilla d'operar, adequada per a entorns petits o prototips; **vLLM** és més adequat quan hi ha concurrència real i models grans.
Les seves responsabilitats centrals són servir un o més models, gestionar VRAM i concurrència, fer streaming, exposar tool calling i maximitzar el throughput sota càrrega. **vLLM** és l'opció per defecte per adesplegaments institucionals: està dissenyat per a concurrència real, context llarg i throughput sota càrrega. **Ollama** només té sentit en entorns molt petits, prototips, o com a sidecar per a models auxiliars (embeddings, models petits).
#### Gateway
@@ -149,41 +148,21 @@ Afegir API nativa d'Ollama, endpoints propis i altres dialectes al mateix temps
### Tria del servidor d'inferència
La decisió acostuma a ser menys "quin producte és millor?" i més "quina càrrega hem de suportar?".
**Ollama** encaixa bé amb equips petits, baixa concurrència i situacions on la simplicitat operativa és prioritària: és la millor opció per posar models en marxa ràpid sense gaire manteniment. **vLLM** és la millor tria quan hi ha molts usuaris simultanis, ús intensiu d'agents o models grans, i quan cal throughput alt i un millor control sobre el runtime. La migració entre tots dos és més fàcil si el gateway i els clients ja parlen només OpenAI-compatible.
## Operació del servei
### Autenticació i identificació d'usuaris
Per a un desplegament institucional, **vLLM** és el punt de partida raonable: està pensat per a concurrència alta, serveix context llarg eficientment i té un scheduler dimensionat per a múltiples peticions simultànies. Acostuma a ser la tria correcta sempre que hi hagi més d'un grapat d'usuaris actius o ús real d'agents.
En un desplegament compartit, algun mecanisme d'autenticació és imprescindible. La solució més simple i més compatible és treballar amb **API keys**.
**Ollama** encaixa en escenaris molt concrets: equips molt petits on la simplicitat operativa pesa més que el throughput, prototips ràpids, o com a sidecar per a models auxiliars. No és una tria simètrica amb vLLM en càrregues reals: és l'excepció, no la norma.
Les claus no serveixen només per "protegir" l'endpoint: serveixen sobretot per **atribuir cada petició a un usuari o servei concret**, aplicar quotes i límits, revocar accessos de manera individual i tenir observabilitat real sobre qui consumeix què. Sense identificació per usuari, el sistema només veu trànsit agregat, cosa que dificulta saber qui satura el servei, separar usos legítims d'abús o auditar incidents.
La migració entre tots dos és més fàcil si el gateway i els clients ja parlen només OpenAI-compatible.
La pràctica recomanable és **una clau per usuari o per client de servei**, gestionada al gateway —no als servidors d'inferència—, vinculada a un rol o equip i amb logs amb atribució per clau.
En entorns petits, això es pot gestionar manualment. En entorns institucionals, és millor automatitzar la provisió i revocació de claus des d'una capa central.
### Gateway com a punt de control
El gateway és on convé centralitzar les polítiques del servei.
Com a mínim hauria de permetre saber **qui ha fet cada petició**, limitar volum per usuari o grup, decidir quin model usa cada client, desactivar ràpidament un model problemàtic i registrar errors, latència i volum de tokens. Sense això, un desplegament multiusuari és opac i difícil de governar.
### Dimensionament
### Dimensionament i pressupost de VRAM
El dimensionament depèn sobretot de la **mida dels models**, la **quantitat de VRAM** disponible, la **concurrència esperada** i el **tipus de càrrega**: xat curt, compleció o agents llargs.
Una institució amb pocs usuaris però molts agents simultanis pot necessitar més capacitat que una amb molts usuaris fent només xat puntual.
El throughput sota càrrega importa més que la velocitat percebuda en una demo amb un únic usuari.
### Pressupost de VRAM
Una institució amb pocs usuaris però molts agents simultanis pot necessitar més capacitat que una amb molts usuaris fent només xat puntual. El throughput sota càrrega importa més que la velocitat percebuda en una demo amb un únic usuari.
La VRAM d'una GPU es reparteix entre dues coses que competeixen: els **pesos del model** i el **KV cache** de les peticions actives.
Els pesos ocupen un volum fix determinat per la mida del model i la quantitat. El KV cache creix amb cada petició activa: a més context i més concurrència, més memòria consumeix.
Els pesos ocupen un volum fix determinat per la mida del model i la quantització. El KV cache creix amb cada petició activa: a més context i més concurrència, més memòria consumeix.
Aquesta tensió porta a una decisió de repartiment que val la pena fer explícita:
@@ -217,7 +196,7 @@ Un cop la petició ha passat el gateway, el servidor d'inferència encara ha de
Aquí apareixen tres problemes reals: quantes seqüències poden estar actives alhora, quina prioritat tenen les peticions i quanta memòria reserva cadascuna per context i KV cache.
Aquest és el motiu pel qual la qualitat del *scheduler* importa tant en desplegaments multiusuari. `vLLM` està pensat per a aquest escenari; `Ollama` és molt més simple i funciona millor quan la concurrència és baixa.
Aquest és el motiu pel qual la qualitat del *scheduler* importa tant en desplegaments multiusuari, i per què **vLLM** és l'opció per defecte en aquest escenari: el seu scheduler està pensat per a concurrència alta i context llarg. Ollama és molt més simple i només funciona bé quan la concurrència és realment baixa.
#### El context llarg pressiona la cua
@@ -237,6 +216,18 @@ La regla pràctica és simple: si el sistema ha de ser compartit, ha de poder de
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.
## Operació del servei
### Autenticació i gateway
En un desplegament compartit, algun mecanisme d'autenticació és imprescindible. La solució més simple i més compatible és treballar amb **API keys**.
Les claus no serveixen només per "protegir" l'endpoint: serveixen sobretot per **atribuir cada petició a un usuari o servei concret**, aplicar quotes i límits, revocar accessos de manera individual i tenir observabilitat real sobre qui consumeix què. Sense identificació per usuari, el sistema només veu trànsit agregat, cosa que dificulta saber qui satura el servei, separar usos legítims d'abús o auditar incidents.
El gateway és el lloc natural per centralitzar aquestes polítiques: una clau per usuari o client de servei, vinculada a un rol o equip, amb logs amb atribució per clau. Des del gateway també convé poder limitar volum per usuari o grup, decidir quin model usa cada client, desactivar ràpidament un model problemàtic i registrar errors, latència i volum de tokens. Sense aquest punt de control, un desplegament multiusuari és opac i difícil de governar.
En entorns petits, això es pot gestionar manualment. En entorns institucionals, és millor automatitzar la provisió i revocació de claus des d'una capa central.
### Seguretat
En aquest tipus de sistemes hi ha dos plans de seguretat diferents:
@@ -264,29 +255,18 @@ Per comparar autoallotjat amb comercial, cal mirar com a mínim el **hardware**,
La decisió rarament és purament econòmica. Sovint barreja cost, control i risc.
### Estratègia de desplegament
Una seqüència prudent acostuma a ser:
1. desplegar un únic servidor d'inferència;
2. posar-hi un gateway davant;
3. validar un petit grup de clients reals;
4. mesurar càrrega, latència i errors;
5. afegir un segon model només si apareix un cas d'ús clar;
6. optimitzar concurrència només quan hi ha dades de càrrega.
Això evita sobredissenyar.
### Recomanació de mínims
Per a un primer desplegament institucional raonable:
-**API**: OpenAI-compatible
-**Inferència**: Ollama si la càrrega és baixa; vLLM si hi ha concurrència real
-**Inferència**: vLLM per defecte; Ollama només en entorns realment petits o per a models auxiliars
-**Gateway**: LiteLLM Proxy
-**Clients**: només els necessaris per als patrons escollits
-**Governança**: autenticació, logging i quotes des del primer dia
Convé desplegar-ho incrementalment: primer un únic servidor amb gateway davant, validar amb un grup petit d'usuaris reals, mesurar càrrega i errors, i només després afegir més models o optimitzar concurrència. Sobredissenyar abans de tenir dades reals de càrrega acostuma a costar més que el que estalvia.
@@ -261,7 +261,7 @@ Abans d'entrar en com Docker cobreix cada factor, val la pena fer explícit un p
L'efecte és doble. D'una banda, reforça els factors II (*Dependencies*) i X (*Dev/prod parity*): qualsevol persona pot reconstruir l'entorn des de zero, i aquest entorn és el mateix a tot arreu. De l'altra, **limita el dany quan les coses van malament**: si una instal·lació corromp l'entorn, `docker compose down` i `git reset` ho desfan tot; si en canvi toques l'entorn global del host, recuperar-lo pot ser llarg i manual.
Aquest principi es coneix com *sandboxing* i és una bona pràctica en qualsevol projecte. Quan es treballa amb agents d'IA que executen comandes autònomament, passa de bona pràctica a requisit — vegeu [Execució aïllada](./ia_desenvolupament.md#execució-aïllada-sandboxing) per al tractament detallat.
Aquest principi es coneix com *sandboxing* i és una bona pràctica en qualsevol projecte. Quan es treballa amb agents d'IA que executen comandes autònomament, passa de bona pràctica a requisit — vegeu [Execució aïllada](../aitools/07_practiques_i_tancament.md#execució-aïllada-sandboxing) per al tractament detallat.
