Quan es parla d'optimització d'inferència de models de llenguatge, la majoria de guies estan escrites per a equips que gestionen clústers de desenes d'H100. Però la realitat de moltes empreses — startups, departaments interns, projectes mid-market — és molt diferent: un sol servidor amb una GPU, una instància modesta a AWS o Azure, o fins i tot inferència sobre CPU per a models més petits. En aquest context, frases com 'afegeix més GPUs' no són una opció. A Q2BSTUDIO, com a empresa de desenvolupament d'aplicacions a mida, treballem cada dia amb clients que necessiten treure el màxim rendiment de recursos limitats. Aquest article desglossa les tres palanques que realment mouen l'agulla en entorns de petita i mitjana escala: gestió de la memòria cau KV, quantització i els compromisos de latència associats. Cap suposició de clúster, ni solucions miraculoses.
Abans que el cost d'inferència es converteixi en una crisi, convé entendre'l. Normalment, la despesa en latència i memòria no apareix com una partida fins que un projecte paral·lel o un MVP rep trànsit real. En aquest moment tens tres opcions: gastar més en hardware, pagar més per API externes, o comprendre què està consumint el teu pressupost de memòria i temps. La tercera és l'única que escala juntament amb el teu coneixement i la teva infraestructura. A Q2BSTUDIO hem ajudat nombrosos equips a aplicar aquest enfocament, combinant el nostre expertise en IA, ciberseguretat, cloud AWS/Azure i BI/Power BI per dissenyar solucions eficients i personalitzades.
La primera palanca és la memòria cau KV. Cada token que genera un transformer necessita atendre a tots els tokens anteriors. De manera ingènua, això obligaria a recomputar l'atenció sobre tota la seqüència a cada pas, un malbaratament enorme. La memòria cau KV emmagatzema els tensors de clau i valor dels tokens previs, de manera que cada nou token només necessita un pas cap endavant. El problema: aquesta memòria cau creix linealment amb la longitud de la seqüència, i la seva petjada de memòria sol ser el veritable coll d'ampolla — no els pesos del model — quan atens múltiples peticions concurrents amb contextos llargs. La fórmula aproximada per petició és: kv_cache_bytes = 2 * num_layers * num_heads * head_dim * seq_len * bytes_per_element. Per a un model de 7B amb 32 capes, 32 caps, head_dim 128, en fp16 (2 bytes) i un context de 4096 tokens, ja són diversos centenars de MB per petició concurrent. Multiplica-ho per la teva concurrència objectiu i entendràs per què la memòria cau KV, i no els pesos, determina quants usuaris simultanis pot atendre una sola GPU.
Per reduir la mida de la memòria cau KV, hi ha diverses estratègies pràctiques. L'atenció multi-consulta o grouped-query attention (GQA) comparteix caps K/V entre múltiples caps de consulta, retallant la mida de la memòria cau de manera significativa amb una pèrdua mínima de qualitat. La majoria de models oberts moderns ja usen GQA, però en triar un model convé verificar-ho. Una altra tècnica és la finestra lliscant (sliding window attention), que limita fins on ha d'arribar la memòria cau en tasques de context local. No serveix si necessites recuperar informació de llarga distància, però és un veritable avantatge en càrregues de treball conversacionals amb context curt. A més, pots implementar polítiques d'expulsió de memòria cau: en aplicacions de xat multitorn, eliminar o resumir torns antics en lloc de mantenir la memòria cau completa indefinidament. Això és una decisió a nivell d'aplicació, no només del motor d'inferència. Finalment, la gestió de memòria tipus PagedAttention — usada a vLLM i altres frameworks — tracta la memòria cau KV com a pàgines de memòria virtual en lloc de requerir assignació contigua, cosa que redueix dràsticament la fragmentació quan tens moltes peticions concurrents amb longituds de seqüència diferents. Si implementes la teva pròpia capa de servit en lloc d'usar vLLM o TGI, prendre prestada aquesta idea és la palanca de major impacte.
La segona palanca és la quantització. Consisteix a reduir la precisió numèrica dels pesos del model — i de vegades de les activacions —, cosa que redueix tant la petjada de memòria com, sovint, la latència. La decisió pràctica no és 'si quantitzar' (per a qualsevol pressupost fora d'un hiperescalador, gairebé sempre convé), sinó quin esquema usar i en funció del teu coll d'ampolla. Si estàs limitat per memòria (el model amb prou feines cap o vols més concurrència), la quantització int4 o GGUF et dóna el marge més gran. Si estàs limitat per latència en CPU, GGUF mitjançant llama.cpp amb un nivell com Q4_K_M és un punt de partida raonable. Si la teva tasca és sensible a la qualitat (sortida estructurada, generació de codi, instruccions precises), queda't en int8 o prova amb cura abans de baixar a int4; la degradació no és lineal i algunes tasques són molt més sensibles. Un patró que recomanem des de Q2BSTUDIO: no endevinis — prova la teva tasca real amb dos o tres nivells de quantització abans de comprometre't. Un model que quantitza bé en xat general pot degradar-se notablement en extracció estructurada o crides a eines. Aquest mateix instint s'aplica a l'enrutament de tasques: igual que un gateway multi-proveïdor tria el model segons la càrrega, pots seleccionar la variant quantitzada més barata que compleixi el llindar de qualitat per a cada petició.
La tercera palanca són els compromisos de latència. Un cop gestionades la memòria cau i la quantització, el pressupost de latència restant es divideix en parts que responen a diferents solucions. El temps fins al primer token (TTFT) està dominat pel processament del prompt inicial. Si el teu sistema utilitza prompts llargs o context extens de RAG, això infla directament el TTFT. Per a aplicacions interactives, retallar el prompt sol ser un benefici més gran que qualsevol ajust del motor d'inferència. La latència entre tokens, en canvi, està dominada per l'ample de banda de memòria durant la descodificació, que és exactament on la quantització i la mida de la memòria cau KV tenen influència directa. El batching continu — en lloc del batching estàtic — permet que noves peticions s'uneixin a un lot a mig vol, en lloc d'esperar que acabi el lot complet. Això importa molt sota patrons de trànsit reals i desiguals. És una de les raons per les quals frameworks com vLLM superen bucles de servit ingenus, fins i tot abans de tocar la quantització. Un compromís concret: el batching millora el rendiment global però pot augmentar la latència per petició sota càrrega, ja que una petició pot esperar breument per un espai al lot. Per a un assistent interactiu individual, amb prou feines es nota; per a un endpoint compartit amb concurrència real, és la diferència entre la latència p50 i p95. Val la pena decidir de bestreta quina de les dues importa més per al teu cas d'ús.
Posant-ho tot en ordre: per a un desplegament de petita a mitjana escala, la seqüència que proporciona més benefici per hora invertida és: triar un model amb arquitectura GQA si tens opció (és gratuït i estructural); quantitzar i provar contra la teva tasca real (int8 com a segur, int4/GGUF si estàs limitat per memòria); adoptar batching continu mitjançant un framework existent (vLLM, TGI) en lloc d'escriure el teu propi bucle; retallar el prompt si el TTFT importa per a la teva experiència d'usuari (és l'ajust més barat i sovint el més ignorat); i només llavors considerar canvis de hardware. En aquell punt sabràs si estàs limitat per memòria o per còmput, i quina millora mereix realment la pena. A Q2BSTUDIO apliquem aquesta metodologia en cada projecte de programari a mida, integrant a més serveis de ciberseguretat, cloud AWS/Azure, BI/Power BI i agents IA per oferir solucions completes que realment resolen problemes de negoci. Perquè l'optimització d'inferència no és només tècnica: és una decisió estratègica que, ben executada, transforma un MVP en un producte escalable sense necessitat d'un clúster d'H100.
