Fundamentos on lo0 — Blog Técnico

Disaggregated serving: prefill y decode en pods especializados

Fri, 22 May 2026 01:00:00 +0200

TL;DR

La inferencia LLM tiene dos fases con perfiles opuestos: prefill (procesar el prompt entero de golpe) es compute-bound, decode (generar token a token) es memory-bandwidth-bound. Ejecutarlas en la misma GPU obliga a elegir entre dos hardware óptimos incompatibles, y deja entre el 60 % y el 80 % de la capacidad de pico sin usar. La industria ha consolidado el patrón en 2026: disaggregated serving — pods separados para cada fase, conectados por un canal de transferencia de KV cache (NIXL sobre UCX, RDMA, o NCCL en su defecto). DistServe demostró 7,4× más request rate a igual SLO; NVIDIA Dynamo 1.0 (GA en GTC 2026) lleva el patrón a producción a escala datacenter. Mezclar hardware heterogéneo —H100 para prefill, GPUs commodity para decode— recorta hasta el 48 % del coste por token. Este artículo explica el porqué, el cómo, y los números que importan para una infraestructura on-premise típica.

La analogía: la cocina con dos brigadas

Una cocina industrial seria —cualquiera que sirva más de 50 cubiertos por noche— funciona con dos brigadas distintas y dos espacios físicos separados.

La brigada de prep empieza al alba. Su trabajo es la mise en place: cortar, marinar, blanquear, hervir fondos, preparar componentes complejos. Equipamiento: cuchillos buenos, fogones grandes, hornos de convección, ollas de 40 litros. Es trabajo intensivo en capacidad y se hace de golpe. Cuando termina, queda todo en bandejas etiquetadas listas para usar.

La brigada de pase entra a media tarde. Su trabajo es el servicio: tomar las bandejas de la prep, calentar porciones, emplatar, montar el pase. Equipamiento: salamandras, planchas pequeñas, espátulas finas, mucha vajilla. Es trabajo de muñeca, de ritmo, de no fallar al cliente que tiene el plato delante. La capacidad por hora importa menos que la latencia por plato.

Si haces que la misma persona haga prep y pase, las dos cosas sufren. El cocinero está parado mientras hace mise en place a media tarde. Tiene que parar a emplatar cuando entran cinco pedidos a la vez. Su equipo de trabajo está diseñado para uno o para el otro, no para ambos.

Las cocinas serias resolvieron esto hace décadas: brigadas separadas, espacios separados, equipo separado. Lo único que cruza entre ambas son las bandejas de mise en place.

Las bandejas son el KV cache. La separación es disaggregated serving. El pase de la prep al servicio es la transferencia de KV cache, hoy resuelta con NIXL sobre RDMA. Y los pods especializados son las dos brigadas con sus equipos óptimos.

Recap rápido: prefill y decode

Una petición a un LLM atraviesa siempre dos fases:

Prefill. Coger el prompt completo (por ejemplo, 4.000 tokens) y procesarlo de una sola pasada por todas las capas del modelo. El resultado es el KV cache de esos 4.000 tokens (ver el artículo previo sobre KV cache si quieres recordar qué guarda exactamente). Este paso es masivamente paralelo: todos los tokens van a la vez por las matrices de atención, lo que se traduce en multiplicaciones de matrices enormes y densas. La GPU está al 90-95 % de uso de compute. TTFT (time to first token) lo determina esta fase.

Decode. Una vez está el KV cache listo, el modelo genera tokens uno por uno. Cada token nuevo es una pasada por todas las capas con un solo vector de query, leyendo todo el KV cache acumulado para calcular la atención. No hay paralelismo entre tokens (cada uno depende del anterior). Lo que limita aquí no es el compute sino el ancho de banda: cada paso hay que leer los pesos completos del modelo desde HBM. La GPU está al 20-40 % de uso de compute, pero al 90 % de uso del HBM. TBT (time between tokens) lo determina esta fase.

Fase	Característica	Cuello de botella	Métrica clave
Prefill	Cómputo masivo paralelo sobre N tokens de golpe	TFLOPS (compute)	TTFT
Decode	Streaming de pesos desde HBM, 1 token cada vez	Bandwidth HBM	TBT (inter-token latency)

La asimetría es estructural: prefill quema el compute y deja la memoria a media, decode hace lo contrario. Una GPU diseñada para ser excelente en ambos a la vez es una GPU diseñada para estar mal aprovechada todo el tiempo.

Por qué juntarlas en la misma GPU es un mal negocio

Hasta 2023, la asunción universal era ejecutar prefill y decode en el mismo proceso de inferencia, sobre la misma GPU. El motor scheduler (vLLM, TGI, Triton) decidía en cada ciclo si hacer prefill de una petición nueva o decode de las que ya estaban en marcha. La intuición era que compartir hardware ahorra coste.

La intuición es incorrecta. El problema tiene tres caras:

Interferencia en latencia. Cuando el motor decide hacer prefill de una petición nueva, interrumpe todos los decodes en curso. Eso sube el TBT de las otras peticiones. El usuario que estaba viendo tokens caer fluidos en su pantalla nota un parón de varios cientos de milisegundos. Esto se conoce como prefill-decode interference y degrada la experiencia de forma visible a medida que sube la concurrencia.

Hardware sub-óptimo para cada fase. Una H100 SXM tiene 989 TFLOPS BF16 de compute y 3,35 TB/s de HBM3. Es excelente para prefill, donde el compute es el límite. Para decode, donde lo único que importa es el bandwidth, esos 989 TFLOPS están desaprovechados al 60-70 %. Inversamente, una GPU con menos compute pero similar bandwidth relativo (RTX 4090, L40S) resolvería el decode igual de bien por una fracción del precio.

Utilización agregada baja. En workloads reales con Llama 3 70B y outputs de 512 tokens, alrededor del 80 % del wall-clock se gasta en decode. Eso quiere decir que el 80 % del presupuesto de tu cluster H100 está haciendo lecturas de memoria, no cálculos. Es como pagar un Ferrari para usarlo en cola de aparcamiento.

La idea: pods especializados, KV cache como entregable

Disaggregated serving rompe el ciclo de inferencia en dos servicios distintos:

Pod de prefill. Recibe el prompt, ejecuta el prefill, produce el KV cache. Hardware: GPUs con alto compute (H100, H200, B200). Optimizado para batching agresivo y throughput, no para latencia individual: si llegan 32 prompts en 100 ms, los procesa juntos.

Pod de decode. Recibe el KV cache ya construido, ejecuta la generación token a token, streamea al cliente. Hardware: GPUs con buen bandwidth pero idealmente más baratas por TFLOPS (RTX 4090, L40S, A100, incluso A30 según el caso). Optimizado para latencia por token (TBT bajo).

Entre ambos: una transferencia de KV cache sobre la red, que puede ser nodo-local (shared memory, NVLink), intra-rack (RDMA con InfiniBand o RoCE) o cross-rack (NIXL sobre UCX). El coste de esta transferencia escala linealmente con la longitud del contexto, y es la clave económica del esquema.

El protocolo de transferencia: la economía del movimiento

El KV cache transferido en un Llama 3 70B con 4K de contexto pesa aproximadamente 2,6 GB (80 layers × 8 KV heads × 128 dim × 4 096 tokens × 2 (K y V) × 2 bytes en BF16). Mover 2,6 GB entre dos GPUs no es trivial:

Canal	Bandwidth efectivo	Tiempo para 2,6 GB
NVLink intra-nodo (NVSwitch)	~450 GB/s	~6 ms
Shared memory (mismo nodo, PCIe 5)	~60 GB/s	~45 ms
RDMA InfiniBand 400 Gbps	~50 GB/s	~55 ms
RDMA RoCE 200 Gbps	~25 GB/s	~105 ms
TCP/IP 10 GbE	~1 GB/s	~2,6 s

Lectura inmediata: por encima de InfiniBand-grade, la transferencia es cómoda. Por debajo, lleva al traste el TTFT que estamos intentando mejorar. Disaggregated serving es viable sólo con interconexión decente — no es un patrón para clusters montados con switches Ethernet de consumo.

NVIDIA respondió a esto con NIXL (NVIDIA Inference Transfer Library), publicada a mediados de 2025: una librería que abstrae el transporte (UCX, NCCL, RDMA verbs directos, shared memory) y elige el mejor camino disponible automáticamente. vLLM la integra desde finales de 2025 mediante el NixlConnector. Es ahora el default de facto para nuevos despliegues.

Implementaciones reales en mayo 2026

El recorrido del patrón en dos años:

2024 ene · DistServe (HKU + UCSD): 7,4× requests al mismo SLO
2024 may · SplitWise (Microsoft): variante con hardware heterogéneo
2024 dic · vLLM disagg experimental (SharedStorage + PyNcclConnector)
2025 mar · NIXL release (NVIDIA): librería de transferencia unificada
2025 jul · vLLM NixlConnector estable
2025 nov · SGLang, llm-d, MoonCake adoptan el patrón
2026 mar · NVIDIA Dynamo 1.0 GA (GTC 2026): production-ready a escala datacenter

A día de hoy, el patrón es el default en cualquier framework de serving serio. Los que siguen monolíticos son los pequeños o los educativos.

Tres opciones realistas para una infraestructura on-premise:

vLLM disagg con NixlConnector. El camino más abierto, requiere desplegar dos sets de pods de vLLM (uno con --kv-transfer-config '{"kv_role":"producer"}', otro con "kv_role":"consumer") y un proxy router. Suficiente para clusters de 4-16 GPUs.
SGLang con disagg. Equivalente conceptual, mejor performance en algunos workloads MoE.
NVIDIA Dynamo 1.0. El que se está imponiendo a escala datacenter. Cubre routing, KV cache management, monitorización y scheduling en un solo plano de control. Más pesado, pero la solución de referencia si tu cluster crece por encima de 32 GPUs.

Los números que importan

Lo que la disaggregation desbloquea, en términos directos:

Métrica	Aggregated (monolítico)	Disaggregated	Mejora
Goodput (req/s al SLO)	baseline	1,4 – 2×	hasta 2×
TTFT bajo carga alta	sube agresivo desde QPS 4	estable hasta QPS 7+	~2×
Request rate al mismo SLO (DistServe paper)	baseline	7,4×	7,4×
Throughput MoE en Blackwell (Dynamo, GB300 NVL72)	baseline (Hopper)	hasta 50×	depende del modelo
Coste por token (heterogéneo H100 + commodity)	baseline (todo H100)	-48 %	casi mitad

Hay que leer estos números con cuidado: los más espectaculares (7× y 50×) requieren hardware específico (Blackwell GB200/GB300 NVL72) y modelos específicos (MoE grandes). El rango realista para un on-premise típico es 1,4-2× en goodput y -30 a -50 % en coste por token, dependiendo de cuán heterogénea sea la mezcla de GPUs y de cuán optimizada esté la transferencia de KV cache.

Heterogeneidad: la versión radical

El paso lógico siguiente, propuesto por SplitWise en 2024 y madurado en 2025-2026 (Cronus, Tessera y otros), es mezclar tipos de GPU: GPUs caras de cómputo alto para prefill, GPUs commodity con buen bandwidth para decode.

Coste indicativo (precios de mercado típicos a mediados de 2026):

H100 SXM: ~30-40 k$ capex, ~3-4 $/h amortizado. Perfil compute-pesado.
L40S: ~8-10 k$ capex, ~1,5 $/h. Perfil intermedio, 864 GB/s de bandwidth.
RTX 4090: ~1,5 k$ capex, ~0,30 $/h. Perfil compute-modesto pero 1 TB/s de bandwidth GDDR6X — suficiente para decode de modelos hasta ~30B parámetros.

Un cluster mixto realista para servir un modelo 8B:

2× RTX 4090 (prefill batch) → ~3.000 $ capex, ~0,60 $/h
4× RTX 4090 (decode pool) → ~6.000 $ capex, ~1,20 $/h
TOTAL → ~9.000 $ capex, ~1,80 $/h

Frente a la alternativa monolítica equivalente en throughput:

2× H100 SXM (todo en uno) → ~70.000 $ capex, ~7 $/h

El mismo throughput a una fracción del capex y a la cuarta parte del coste por hora, a costa de complejidad operativa: ahora tienes dos pools que coordinar, una red de transferencia que cuidar, y un scheduler que no es trivial.

Para modelos más grandes (Llama 3 70B), el decode pool ya no cabe en una 4090 individual (el modelo no entra en 24 GB ni siquiera cuantizado a INT4 con margen). Ahí la mezcla razonable es H100 para prefill + L40S o A100 80GB para decode, con ahorro típico del 30-40 % sobre la opción todo-H100.

Aplicado a hardware on-premise típico

Caso 1 — Una o dos RTX 4090: monolítico sigue ganando

Con una sola GPU no hay disaggregation que valga: el patrón requiere mínimo dos GPUs en pods separados. Con dos 4090, técnicamente puedes intentarlo (una para prefill, otra para decode con KV cache transferido por PCIe 5 o RDMA básico), pero el overhead de transferencia se come la ganancia para modelos pequeños donde el prefill ya es rápido.

Recomendación: mantener monolítico (vLLM tradicional, bien configurado con KV cache cuantizado). El siguiente nivel justificable de complejidad es un cluster con interconexión rápida.

Caso 2 — Cluster 4×H100 SXM (320 GB, NVLink): el sweet spot

Configuración mínima realista para disaggregation seria, sirviendo un modelo 70B en producción:

2× H100 (TP=2) → 2 pods de prefill
2× H100 (TP=2) → pods de decode con varias instancias compartiendo TP
NIXL sobre NVLink → transferencia KV cache <6 ms
Router (vLLM o Dynamo) → distribución de prompts y stream

Resultado realista esperado: goodput 1,6-1,9× respecto al mismo cluster en monolítico, con TTFT estable hasta cargas de QPS 7-8 (frente al QPS 4 al que empieza a degradar el monolítico).

Si la mezcla heterogénea es posible (añadir 4-8 L40S al cluster para hacer el decode pool), el coste por token cae adicionalmente entre un 25 % y un 35 %, manteniendo el modelo 70B servido íntegro.

Posición dentro de la arquitectura

Disaggregated serving es una capa transversal a casi todo lo discutido en artículos previos. Toca:

El KV cache porque es el artefacto que se transfiere entre pods. Sin entender bien cuánto pesa el cache y cómo crece con el contexto, no se puede dimensionar la transferencia.
El fine-tuning continuo porque el multi-LoRA hot-swap conserva su semántica: cada pod (prefill o decode) carga los adapters por separado, y el router decide qué adapter aplicar en cada fase.
La topología del cluster: cambia la HW recomendada, el networking exigido y el modelo de costes.

Si estás diseñando una infraestructura de inferencia para 2026 desde cero, disaggregation deja de ser opcional para cualquier cluster que exceda 4 GPUs de capacidad. Si estás modernizando una existente, es la actualización con mejor retorno por euro invertido — siempre que el networking entre pods sea decente (NVLink intra-nodo o RDMA intra-rack como mínimo).

Lo que no hemos cubierto (próximos artículos)

NIXL en detalle: cómo elige el transporte óptimo, cómo se configura UCX, qué pasa cuando RDMA falla y hay que degradar a TCP.
Scheduler de routing: cómo decide el orquestador qué pod recibe qué petición, batching dinámico, manejo de prioridades.
Multi-tenant disagg: aislamiento de KV cache entre tenants, ACLs por adapter, multi-LoRA sobre pods especializados.
Disagg + prefix caching: cómo se combina con el patrón de reutilización de KV cache cuando varios prompts comparten prefijo (system prompt común).
Disagg en edge / inferencia local: viabilidad sobre hardware doméstico (4090 + Mac Studio, por ejemplo), donde la transferencia depende de Thunderbolt o Ethernet residencial.

Ver también

KV cache: la memoria de trabajo que sostiene la inferencia LLM — el artefacto exacto que se transfiere entre pods, con la fórmula completa de su tamaño.
Fine-tuning continuo en producción — cómo el multi-LoRA hot-swap convive con la disaggregation: cada pod carga adapters por separado, el router elige.

Referencias

Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving (OSDI 2024).
Patel et al., SplitWise: Efficient Generative LLM Inference Using Phase Splitting (ISCA 2024).
NVIDIA, NVIDIA Dynamo 1.0: Production-Ready Disaggregated Inference (GTC 2026, marzo): https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/.
NVIDIA, NIXL: NVIDIA Inference Transfer Library — documentación oficial.
vLLM, Disaggregated Prefilling: https://docs.vllm.ai/en/stable/features/disagg_prefill/.
vLLM, NixlConnector Usage Guide: https://docs.vllm.ai/en/stable/features/nixl_connector_usage/.
Hao AI Lab, Disaggregated Inference: 18 Months Later (UCSD, 2025) — retrospectiva técnica del paper DistServe.

Fine-tuning continuo en producción: del tráfico real al adapter desplegado

Thu, 21 May 2026 10:00:00 +0200

TL;DR

Fine-tuning continuo no es “entrenar el modelo cada cierto tiempo”. Es un ciclo cerrado donde el tráfico real de producción genera los datasets, un pipeline corto entrena un adapter LoRA, una batería de evaluaciones decide si promociona, y vLLM lo carga sin reiniciar. El estado del arte en mayo de 2026 ha fragmentado el stack: ya no es DPO contra todo, sino una elección entre SFT, DPO, KTO, ORPO y SimPO según el tipo de señal que captura tu producto. Lo que ha consolidado el patrón es la combinación PostgreSQL 18 + pgvector 0.8 como sistema nervioso del pipeline —captura de tráfico, dataset versioning, eval results, registry de adapters—, junto a vLLM multi-LoRA hot-swap que convierte el despliegue en una llamada HTTP. Este artículo desmonta el ciclo con esquemas concretos, queries reales, y los números que cuestan en una RTX 4090 frente a un cluster 4×H100.

La analogía: el restaurante que afina su carta

Imagina un restaurante de barrio con un plato estrella que funciona, pero el chef sabe que se puede afinar. Cada noche pasan cosas:

Algunos comensales dejan parte del plato: señal débil de que algo no acabó de encajar.
Otros piden otra versión ("¿podrías ponerle menos sal?"): señal explícita y direccional.
Otros terminan el plato y vuelven la semana siguiente: la única señal que de verdad importa, pero llega tarde.
Y un grupo selecto opina sin que se les pregunte, normalmente para mal.

El chef no rehace su carta cada noche. Hace algo más interesante: anota en una libreta los platos servidos, las devoluciones, los cambios pedidos, las propinas. Cada cierto tiempo, lee la libreta entera, decide ajustes mínimos en una receta, prueba la nueva versión en mesa privada con su personal, y solo si la prueban favorablemente la incorpora a la carta del día siguiente. A veces incluso sirve dos versiones distintas del plato a distintas mesas durante una semana, mide qué pasa, y elige.

Eso es fine-tuning continuo. La libreta es Postgres. El plato es el modelo base. Las anotaciones son señales de feedback —explícitas y implícitas—. El “ajuste mínimo” es un LoRA adapter de 30 MB. La mesa privada es la batería de evaluaciones automatizadas. La carta del día siguiente es vLLM con multi-LoRA hot-swap, que carga el nuevo adapter sin reiniciar el servicio. El servir dos versiones a distintas mesas es A/B testing con tráfico real.

La analogía es exacta en un punto crítico: el chef no tira la receta original. Mantiene la receta base y guarda una libreta separada con las “modificaciones que dan buen resultado para los habituales del barrio”. Esa libreta es el adapter LoRA: encima del modelo base, no en su lugar.

El ciclo, desmontado

Antes de entrar en componentes, conviene fijar el flujo completo. Estos siete pasos son lo que cualquier equipo serio replica con variaciones:

El ciclo dura entre 1 y 4 semanas en producción real. Lo que cambia entre equipos es el ritmo (más rápido en chat asistente, más lento en banca regulada) y los detalles de cada paso. La estructura es la misma.

Por qué fine-tuning continuo (y por qué no es RAG)

Antes de profundizar, una distinción que se sigue confundiendo. Fine-tuning sirve para forma, no para hechos. Si tu problema es que el modelo no conoce las tarifas del cliente o el catálogo actualizado, no fine-tunees: usa RAG. Si tu problema es que el modelo responde con un tono que no encaja, no respeta tu formato JSON, rechaza casos legítimos o se inventa estructura, ahí sí es fine-tuning.

En 2026 el límite ya está bien establecido por la práctica de la comunidad:

Problema observado	Solución
El modelo no sabe X (X cambia semanalmente)	RAG
El modelo conoce X pero responde mal de tono o formato	Fine-tuning SFT
Hay dos formas de responder y prefiero una sobre otra	Fine-tuning con preferencias (DPO/KTO/ORPO/SimPO)
El modelo razona mal en un dominio verificable (código, mates)	RL con recompensa verificable (GRPO/DAPO)
El modelo es competente, solo necesita memoria de hechos	RAG, no fine-tuning

Fine-tuning continuo es la versión disciplinada del segundo y tercer caso. La palabra clave es continuo: no es un evento puntual de “alineamos el modelo”, es un proceso que toca cada vez que la distribución del tráfico se desvía lo suficiente, o que aparecen nuevos casos de uso.

Las cuatro técnicas según la señal que captures

El cambio más importante de los últimos 12 meses ha sido el fin del monopolio de DPO. En 2024 todo equipo que hacía alineamiento usaba DPO con pares (chosen, rejected). En 2026 la elección es más fina y depende de cómo es la señal que recoges en tu producto:

Señal real en producto	Técnica recomendada	Por qué
Ejemplos correctos etiquetados (input → output esperado)	SFT + LoRA	Sigue siendo la base. 500-5.000 ejemplos bastan para estilo.
Pares explícitos `(chosen, rejected)`	DPO o SimPO	SimPO elimina el modelo de referencia → 50 % menos VRAM en entrenamiento.
👍 / 👎 sueltos sobre respuestas	KTO	El método que más naturalmente encaja con la telemetría real.
SFT y preferencias en una sola pasada	ORPO	Un solo modelo en memoria, evita el drift entre fases.
Recompensa verificable (tests, soluciones)	GRPO / DAPO	Razonamiento, no chat. Otro mundo.

La regla práctica: diseña la captura de feedback en producto pensando en qué método podrás usar después. Si tu UI sólo tiene 👍/👎, fuerzas el camino a KTO. Si añades un botón “regenerar respuesta”, desbloqueas DPO desde el regenerate-as-rejected (lo veremos abajo). Si añades un botón “editar respuesta”, la respuesta editada se convierte en SFT directo de alta calidad.

Hay un detalle de coste que se publicita poco. DPO necesita mantener en memoria dos modelos: el que entrenas y el de referencia. SimPO elimina ese segundo modelo. ORPO también. Para un Llama 3 8B en BF16 esto es la diferencia entre necesitar ~32 GB de VRAM activos durante entrenamiento (DPO) o ~16 GB (SimPO/ORPO). Es la diferencia entre que el entrenamiento quepa en una RTX 4090 con QLoRA agresivo, o no quepa sin offload.

Postgres como sistema nervioso del pipeline

Aquí está la opinión técnica fuerte de este artículo, y es la que conviene defender con datos: Postgres 18 + pgvector 0.8 + un bucket S3/MinIO para los pesos es suficiente para todo el pipeline. No hace falta MLflow, no hace falta lakeFS, no hace falta DVC.

No se trata de minimalismo ideológico. Se trata de tres ventajas concretas que ningún stack alternativo iguala en el escenario on-premise con compliance:

Una sola fuente de verdad, un solo modelo de autorización. Las ACL que ya tienes para Postgres cubren los datos de entrenamiento, los resultados de eval, el registry de adapters y el log de auditoría. No multiplicas planos de control.
SQL como lenguaje universal del pipeline. El query que genera el dataset, el predicado del eval gate, la asignación de tráfico A/B, la decisión de promoción: todo es SQL. Tu equipo ya sabe SQL.
Audit y reproducibilidad criptográfica gratis. Las extensiones pg_audit y pgcrypto, combinadas con set_hash sobre el dataset, te dan trazabilidad criptográfica sin código adicional. Es un terreno que da para artículo propio.

Esquema concreto

Empezamos por la tabla de tráfico, particionada por semanas para que el DROP PARTITION sea barato:

CREATE TABLE obs.inference_log (
 id BIGSERIAL,
 request_id UUID NOT NULL,
 tenant_id INT NOT NULL,
 user_hash BYTEA, -- pseudonimización GDPR
 adapter_id TEXT NOT NULL, -- ej. "support-es-v4.1"
 experiment TEXT, -- ej. "rerank-v2-canary"
 variant CHAR(1), -- 'A' | 'B' | NULL
 messages JSONB NOT NULL,
 completion TEXT,
 ttft_ms INT,
 tokens_in INT,
 tokens_out INT,
 -- señales de feedback
 fb_explicit SMALLINT, -- -1/0/+1 (KTO-ready)
 fb_regen BOOLEAN DEFAULT false, -- usuario regeneró → DPO-rejected
 fb_edited BOOLEAN DEFAULT false, -- usuario editó → SFT golden
 parent_id BIGINT, -- autoreferencia regenerate
 -- vector y meta
 embedding HALFVEC(1024), -- pgvector 0.8, mitad de RAM
 pii_flags SMALLINT DEFAULT 0, -- bitmask
 created_at TIMESTAMPTZ DEFAULT now()
) PARTITION BY RANGE (created_at);

CREATE TABLE obs.inference_log_2026w21 PARTITION OF obs.inference_log
 FOR VALUES FROM ('2026-05-18') TO ('2026-05-25');

CREATE INDEX ON obs.inference_log_2026w21
 USING hnsw (embedding halfvec_cosine_ops);
CREATE INDEX ON obs.inference_log_2026w21
 (tenant_id, adapter_id, created_at);

Tres decisiones merecen una nota:

HALFVEC(1024). Vectores en FP16 nativos de pgvector 0.8. La mitad de RAM y disco con pérdida de precisión irrelevante para deduplicación semántica. Esto solo, a escala de millones de filas, ahorra entre 4 y 8 GB.

Particionado semanal por rango temporal. A los 90 días, DROP TABLE obs.inference_log_2026wXX libera espacio en milisegundos sin bloqueo prolongado. Autovacuum nunca vuelve a tocar particiones congeladas.

parent_id autoreferenciado. El usuario regenera la respuesta → se inserta una nueva fila con parent_id apuntando a la anterior. Eso nos dará un dataset DPO sin tocar la UX.

El registry de adapters

CREATE TABLE serve.adapter (
 id TEXT PRIMARY KEY,
 base_model TEXT NOT NULL,
 rank INT, alpha INT,
 target_modules JSONB,
 method TEXT, -- 'sft'|'dpo'|'kto'|'orpo'|'simpo'
 training_run_id UUID,
 dataset_snapshot_id UUID,
 weights_uri TEXT, -- s3://.../v4.2.safetensors
 eval_summary JSONB,
 status TEXT NOT NULL, -- 'training'|'canary'|'prod'|'retired'
 traffic_pct NUMERIC(5,2) DEFAULT 0,
 promoted_at TIMESTAMPTZ
);

El router de vLLM lee esta tabla con TTL de pocos segundos. Un UPDATE serve.adapter SET status='prod', traffic_pct=100 WHERE id='v4.2' es una promoción. Un UPDATE ... SET status='retired' es un rollback. La auditoría de quién hizo qué y cuándo la da pg_audit sin escribir una línea de código adicional.

Generar datasets DPO y KTO desde tráfico real

Aquí es donde la elegancia del esquema paga. El dataset no es un fichero estático: es una vista materializada que se construye con SQL sobre obs.inference_log.

Dataset KTO desde 👍/👎

KTO es el método que mejor encaja con la señal que captura cualquier producto de chat decente. La query:

CREATE MATERIALIZED VIEW train.kto_v3_candidate AS
SELECT
 messages AS prompt,
 completion AS response,
 CASE WHEN fb_explicit > 0 THEN true ELSE false END AS label,
 adapter_id, created_at
FROM obs.inference_log
WHERE fb_explicit != 0
 AND created_at > now() - interval '60 days'
 AND pii_flags = 0
 AND tenant_id IN (SELECT id FROM tenant WHERE consent_training);

Simple. Cada fila con feedback explícito se convierte en un ejemplo (prompt, response, deseable_sí_no). KTO entrena directamente sobre esta señal, sin necesidad de construir pares.

Dataset DPO desde “regenerar”

El truco que vale por sí solo este artículo. Cuando el usuario pulsa “regenerar respuesta”, está dando una señal extraordinariamente fuerte: la primera respuesta no le valió. Si la segunda no se regenera ni se valora negativamente, asumimos que sí. Eso es un par DPO sin un solo clic adicional en la UI:

CREATE MATERIALIZED VIEW train.dpo_v3_candidate AS
SELECT
 rej.messages AS prompt,
 cho.completion AS chosen,
 rej.completion AS rejected,
 rej.adapter_id
FROM obs.inference_log rej
JOIN obs.inference_log cho ON cho.parent_id = rej.id
WHERE rej.fb_regen = true
 AND cho.fb_explicit >= 0
 -- mitigación de length bias en DPO clásico
 AND cho.tokens_out BETWEEN rej.tokens_out * 0.5
 AND rej.tokens_out * 2.5;

La cláusula sobre longitudes es la cura barata al length bias documentado en DPO. Sin ella, el modelo aprende que “más largo = mejor” porque las respuestas que el usuario acepta tienden a ser ligeramente más largas. Con SimPO o ORPO este filtro es opcional; con DPO clásico es necesario.

Deduplicación semántica con pgvector

Antes de entrenar, dedup. Dos prompts casi idénticos en el dataset es ruido que sesga el modelo:

WITH ranked AS (
 SELECT id, embedding,
 row_number() OVER (
 PARTITION BY hashtext(messages::text)
 ORDER BY fb_explicit DESC, created_at DESC
 ) AS rn
 FROM obs.inference_log
 WHERE created_at > now() - interval '60 days'
)
DELETE FROM train.kto_v3_candidate kto
USING ranked r
WHERE r.rn > 1 AND kto.id = r.id;

Y para los duplicados semánticos (paráfrasis) usamos directamente pgvector 0.8 con iterative index scan:

-- Buscar near-duplicates de un ejemplo cualquiera
SELECT id, messages, embedding <=> $1 AS dist
FROM obs.inference_log
WHERE created_at > now() - interval '60 days'
 AND embedding <=> $1 < 0.05
ORDER BY embedding <=> $1
LIMIT 50;

El iterative scan es una mejora clave de pgvector 0.8: antes, el índice HNSW podía devolver menos resultados de los pedidos cuando había filtros adicionales (WHERE); ahora itera hasta cumplir el límite. Sin esa mejora, las queries de curación sobre datasets de millones de filas eran inviables sin un pre-filtro brutal.

Eval gates: tres etapas, todo SQL

El error más común al implementar fine-tuning continuo es saltarse o aligerar los eval gates. Eso convierte el ciclo en una ruleta. El patrón que funciona en 2026 son tres etapas, cada una con un trade-off latencia/cobertura distinto:

Y aquí es donde Postgres vuelve a brillar: el gate de promoción se expresa como un predicado SQL. Nada más:

CREATE TABLE train.eval_result (
 adapter_id TEXT REFERENCES serve.adapter(id),
 suite_id TEXT, -- 'safety-es', 'support-helpfulness'
 metric TEXT,
 score NUMERIC,
 judge_model TEXT,
 judged_at TIMESTAMPTZ DEFAULT now(),
 PRIMARY KEY (adapter_id, suite_id, metric)
);

CREATE OR REPLACE FUNCTION serve.can_promote(candidate TEXT, current TEXT)
RETURNS BOOLEAN AS $$
 SELECT NOT EXISTS (
 SELECT 1
 FROM train.eval_result c
 JOIN train.eval_result p USING (suite_id, metric)
 WHERE c.adapter_id = candidate
 AND p.adapter_id = current
 AND suite_id IN ('safety-es','support-helpfulness','refusal-rate')
 AND c.score < p.score * 0.98 -- tolerancia 2 %
 );
$$ LANGUAGE sql STABLE;

Una función SQL como gate. Aplicable desde el CI con psql -c "SELECT serve.can_promote('v4.2','v4.1')" y un exit code 0/1. No hace falta un orquestador, no hace falta una UI específica. La auditoría queda en el log de Postgres.

vLLM multi-LoRA: el deploy es un POST HTTP

Hace dos años, desplegar un fine-tune nuevo era rotar pods de inferencia. Hoy es una llamada HTTP. vLLM 0.7+ soporta cargar y descargar adapters LoRA en caliente, manteniendo varios residentes en VRAM y eligiendo el correcto por petición.

Configuración del servidor:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
 --enable-lora \
 --max-loras 4 \
 --max-lora-rank 64 \
 --env VLLM_ALLOW_RUNTIME_LORA_UPDATING=True

Despliegue de un adapter nuevo:

curl -X POST http://localhost:8000/v1/load_lora_adapter \
 -H "Content-Type: application/json" \
 -d '{
 "lora_name": "support-es-v4.2",
 "lora_path": "/mnt/adapters/support-es-v4.2"
 }'

A partir de ese momento, las peticiones que incluyen "model": "support-es-v4.2" se sirven con ese adapter aplicado sobre el modelo base. El switch entre adapters tiene latencia despreciable (la investigación más reciente sobre Activated LoRA lleva esto a niveles donde el coste de cambio es invisible).

Esto cambia la operación de forma sustancial. El despliegue de un fine-tune nuevo deja de ser un evento de infraestructura para convertirse en un cambio de estado en Postgres. El router consulta la tabla serve.adapter, ve que v4.2 está en canary con traffic_pct=5, y dirige el 5 % de peticiones al nuevo adapter. La ruta exacta del 5 % se decide con hashing determinístico del user_id para que un mismo usuario siempre vea la misma variante (sticky):

-- Sin tabla de asignación, sin estado adicional
-- el variant se calcula in-place en SQL o en el router:
SELECT
 CASE WHEN hashtext($user_id || $experiment) % 100
 < (SELECT traffic_pct FROM serve.adapter WHERE id = $candidate)
 THEN $candidate ELSE $current END AS adapter_id;

A/B con tráfico real: medir o vivir engañado

Los eval gates miden contra benchmarks fijos. Eso es necesario pero insuficiente. La realidad solo se mide con tráfico real. Una vez el adapter está en canary, lo que importa son las métricas online medidas sobre obs.inference_log para cada variante:

SELECT
 adapter_id,
 COUNT(*) AS n,
 AVG(fb_explicit) AS mean_score,
 STDDEV(fb_explicit) / SQRT(COUNT(*)) AS sem,
 AVG(ttft_ms) AS ttft_avg,
 percentile_cont(0.5) WITHIN GROUP
 (ORDER BY ttft_ms) AS ttft_p50,
 percentile_cont(0.95) WITHIN GROUP
 (ORDER BY ttft_ms) AS ttft_p95,
 AVG(CASE WHEN fb_regen THEN 1 ELSE 0 END) AS regen_rate
FROM obs.inference_log
WHERE experiment = $1
 AND created_at > now() - interval '7 days'
GROUP BY adapter_id;

Lo que se mira: feedback explícito, latencia (TTFT, p50, p95), tasa de regeneración. Un adapter que sube el feedback medio pero también sube la tasa de regeneración es sospechoso —probablemente está respondiendo de forma más vistosa pero menos útil—. Un adapter que baja la latencia pero baja el feedback puede merecer estudio: puede que esté siendo más conciso de la cuenta.

La promoción a prod ocurre cuando, después de 24-72 horas en canary, el adapter candidato supera al actual en al menos una métrica clave sin degradar las demás. Otra vez: es un UPDATE en Postgres.

Aplicado a hardware on-premise típico

Bajemos a dos configuraciones representativas, una de iteración y otra de producción.

Caso 1 — RTX 4090 (24 GB) para iteración de desarrollo

Una RTX 4090 con QLoRA 4-bit puede entrenar adapters sobre un modelo 8B sin sobresalto. El presupuesto de VRAM combina cuatro componentes; el KV cache durante las evaluaciones intermedias no es despreciable y conviene reservarle margen explícito:

Modelo base 8B en 4-bit: ~5 GB
Activations + gradientes: ~8 GB (depende de batch y context)
Optimizer state (LoRA r=16): ~0.5 GB
KV cache durante eval: ~2 GB
Margen de seguridad: ~8 GB

Tiempos típicos (estimación basada en benchmarks comunitarios; conviene medir con el lab antes de prometer):

Dataset	Técnica	Adapter rank	Tiempo aproximado
1.000 ejemplos SFT	LoRA r=16	16	20-40 min
5.000 ejemplos SFT	LoRA r=32	32	2-4 h
2.000 pares DPO	LoRA r=16	16	1-2 h
5.000 ejemplos KTO	LoRA r=32	32	3-5 h

Esto pone el ciclo de iteración —cambio en dataset, retrain, eval, ver número— en franja de una jornada de trabajo. Suficiente para validar hipótesis antes de mover nada al cluster de producción.

Caso 2 — Cluster 4×H100 SXM (320 GB, NVLink) para producción

Con un cluster de este orden todo el escenario cambia. Se puede:

Entrenar LoRA sobre 70B en BF16 sin quantización con tensor parallel = 4.
Hacer DPO completo con modelo de referencia residente cuando se cuantiza la referencia a FP8, o pasarse a SimPO / ORPO que eliminan ese modelo intermedio y simplifican la planificación de VRAM (ver tabla de técnicas más arriba).
Soportar multi-tenant fine-tuning: varios adapters de clientes entrenándose en paralelo en pipelines lógicos separados, cada uno aislado en una partición distinta de Postgres con sus propias ACLs.
Servir multi-LoRA con --max-loras 8 sobre el modelo base sin que la concurrencia baje el throughput de forma perceptible.

La regla práctica de presupuesto: en horizonte de 12 meses, un equipo con este cluster puede ejecutar ~150-200 ciclos de fine-tuning continuo (training + eval + canary + promoción o descarte) si la disciplina del dataset y de los eval gates es estricta. Si no lo es, ejecutará el doble pero con la mitad de utilidad.

Posición dentro de la arquitectura: lo que cubre este artículo y lo que no

Para situar el alcance: el ciclo dibujado al principio tiene siete cajas, todas ellas cubiertas aquí en su mecánica. Quedan deliberadamente fuera tres capas transversales que son las que terminan separando un pipeline que funciona técnicamente de uno que sobrevive a una auditoría:

Provenance criptográfico y trazabilidad. Hemos mencionado dataset_snapshot y pg_audit, pero la mecánica completa —el set_hash sobre los ejemplos, la integración con EU AI Act, el query_sql congelado como prueba de qué entrenó al modelo— da para análisis entero.
Calibración del juez. Hemos asumido que LLM-as-judge funciona. Hace falta calibrarlo contra rúbrica humana en, al menos, 100 casos por suite crítica antes de fiarse. Sin esa calibración, los eval gates son teatro.
El problema del olvido. ¿Qué pasa si un usuario ejerce su derecho al olvido GDPR y sus interacciones formaron parte del dataset de un adapter ya en producción? No hay solución limpia. Hay opciones —retrain incremental, machine unlearning a nivel de muestra, negative LoRA— y conviene conocerlas antes de que un cliente pregunte.

Lo que no hemos cubierto (próximos artículos)

Provenance criptográfico sobre Postgres: cómo set_hash y query_sql congelado componen una cadena de custodia auditable bajo EU AI Act.
Judge calibration honesta: por qué score > 0.85 no significa nada sin baseline humana, y cómo construir esa baseline sin que cueste un mes de trabajo.
El problema del olvido en adapters: machine unlearning a nivel de muestra, retrain incremental y otras técnicas para responder a GDPR sin tirar el adapter.
Online DPO y aprendizaje continuo on-policy: estado de la investigación 2026 (Fast-Slow Chasing, RLOO, iterative on-policy) y por qué todavía no es producción.

Ver también

KV cache: la memoria de trabajo que sostiene la inferencia LLM — los fundamentos del cache que entra en juego en cada eval intermedia del entrenamiento y en cada despliegue del adapter resultante.
Disaggregated serving: prefill y decode en pods especializados — el patrón de serving al que se conecta el multi-LoRA hot-swap descrito aquí: cada pod especializado carga sus adapters por separado.

Referencias

Hu et al., LoRA: Low-Rank Adaptation of Large Language Models (ICLR 2022).
Dettmers et al., QLoRA: Efficient Finetuning of Quantized LLMs (NeurIPS 2023).
Rafailov et al., Direct Preference Optimization: Your Language Model is Secretly a Reward Model (NeurIPS 2023).
Meng, Xia, Chen, SimPO: Simple Preference Optimization with a Reference-Free Reward (NeurIPS 2024).
Hong et al., ORPO: Monolithic Preference Optimization without Reference Model (2024).
Ethayarajh et al., KTO: Model Alignment as Prospect Theoretic Optimization (2024).
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — vLLM original.
Documentación oficial de vLLM Multi-LoRA: https://docs.vllm.ai/en/stable/features/lora/.
Documentación oficial de pgvector 0.8: https://github.com/pgvector/pgvector.
TRL (HuggingFace) docs: https://huggingface.co/docs/trl.
EU AI Act, texto consolidado y calendario de aplicación: https://artificialintelligenceact.eu/.

KV cache: la memoria de trabajo que sostiene la inferencia LLM

Mon, 18 May 2026 10:00:00 +0200

Nota técnica para Hugo: los diagramas usan SVG inline. Requiere markup.goldmark.renderer.unsafe = true en hugo.toml. Si no, mover los SVG a static/svg/ y referenciarlos con <img>.

TL;DR

El KV cache es la memoria de trabajo que un modelo de lenguaje mantiene durante una conversación. Sin él, cada token nuevo obligaría a recalcular toda la conversación desde el principio, con un coste cuadrático en la longitud del texto. Con él, el coste es lineal pero a cambio el cache vive en VRAM y crece con cada token. En la práctica, no es el modelo lo que limita cuánto contexto puedes servir: es el KV cache. Para una RTX 4090 con Llama 3 8B, cabe el modelo en 16 GB y queda apenas espacio para ~64 K tokens de cache totales (sumando todas las sesiones simultáneas). Entender este número es la diferencia entre prometerle a un cliente “contexto de 128 K” y entregárselo.

La analogía: el orador con amnesia

Imagina que asistes a una conferencia técnica de dos horas. El ponente, cada vez que va a decir una frase nueva, rebobina mentalmente toda la charla desde el inicio, recompone el hilo, y solo entonces continúa. Su próxima frase requiere rememorar la anterior; la siguiente, las dos anteriores; al cabo de una hora, cada palabra nueva le cuesta una hora de recapitulación. Una conferencia así sería materialmente imposible.

Ahora imagina al mismo ponente con un cuaderno donde apunta, mientras habla, las dos o tres ideas clave de cada frase: sujeto, objeto, vínculo con lo anterior. Antes de cada frase nueva, ojea el cuaderno y sigue. Su próxima palabra sólo cuesta una ojeada al cuaderno, no rebobinar la charla entera.

Ese cuaderno, en un transformer, se llama KV cache. Sin él, los modelos de lenguaje conversacionales serían inviables. Con él, son productos comerciales. Pero el cuaderno pesa: y entender cuánto, dónde y por qué, es lo que separa una infraestructura de inferencia que funciona de una que se cae al tercer cliente concurrente.

El mecanismo en sí (en cristiano)

Un transformer genera texto un token cada vez. Para decidir el siguiente token, el modelo aplica un mecanismo llamado atención sobre todos los tokens previos: pregunta “¿qué partes del contexto anterior son relevantes para predecir lo que viene ahora?”.

Internamente, cada token de entrada se proyecta a tres vectores:

Q (Query): “qué estoy buscando”
K (Key): “qué oferta este token”
V (Value): “qué información lleva este token”

La atención del token actual contra el contexto se calcula multiplicando su Q contra las K de todos los tokens previos, normalizando con softmax, y ponderando las V correspondientes. Resultado: una representación contextualizada del token actual.

Q·Kᵀ → softmax × V

representación del token N

Aquí está la clave: para predecir el token N, sólo necesito Q nuevo (el del token N) y K, V de todos los tokens anteriores. Las K y V de los tokens 1..N-1 no han cambiado desde la iteración anterior. Recalcularlas sería tirar trabajo.

El KV cache es exactamente eso: la memoria que guarda K y V de cada token ya procesado, en cada capa del modelo, para no recalcularlos.

Por qué existe: el coste cuadrático sin él

Generar un texto de N tokens implica N pasos. En el paso i, se calcula la atención sobre i tokens anteriores. Sin cache, en cada paso recomputas las K, V de los i-1 tokens anteriores más las del nuevo. La cuenta total de cómputos de atención crece como:

$$\sum_{i=1}^{N} i = \frac{N(N+1)}{2} \approx \frac{N^2}{2}$$

Con KV cache, sólo procesas el token nuevo en cada paso: coste lineal en N.

0 25% 50% 75% 100%

0 1K 2K 3K 4K

con KV cache (lineal) sin KV cache (cuadrático)

Los números concretos son demoledores:

Tokens generados	Sin KV cache (operaciones)	Con KV cache	Ratio
128	8 256	128	64×
1 024	524 800	1 024	512×
4 096	8 390 656	4 096	2 048×
32 768	536 887 296	32 768	16 384×

A los 32 K tokens, el cache te ahorra cuatro órdenes de magnitud de cómputo. No es una optimización: es lo que hace que la inferencia conversacional sea posible.

El precio: cuánto pesa la mochila

El KV cache se paga en VRAM. La fórmula, por secuencia, es:

KV_size = 2 · n_layers · n_kv_heads · head_dim · context_len · bytes_per_param
↑
K y V

Por token (sin el context_len), es una constante propia del modelo. Veamos números reales:

Modelo	n_layers	n_kv_heads	head_dim	Bytes/token (BF16)	GB a 8 K ctx	GB a 32 K	GB a 128 K
Llama 3 8B (MHA hipotético)	32	32	128	524 288	4.00	16.00	64.00
Llama 3 8B (GQA real)	32	8	128	131 072	1.00	4.00	16.00
Llama 3 70B (GQA)	80	8	128	327 680	2.50	10.00	40.00
Qwen3 8B (GQA)	36	8	128	147 456	1.12	4.50	18.00
Mistral 7B (GQA)	32	8	128	131 072	1.00	4.00	16.00

Dos lecturas inmediatas:

Sin GQA, no hay 128 K que valga. Un Llama 3 8B con atención multi-head clásica necesitaría 64 GB sólo de KV cache para una única secuencia con 128 K tokens. Es decir, no cabe en ninguna GPU consumer. Por eso Meta, Mistral y compañía adoptaron Grouped Query Attention.
El KV cache puede ser mayor que el modelo. Llama 3 8B BF16 ocupa ~16 GB. Con 128 K de contexto, su cache son otros 16 GB. Una sola sesión empata al modelo en VRAM.

0 10 20 30 40 GB

0 8K 32K 64K 128K

≈ VRAM libre tras cargar 8B en una 4090

Llama 3 8B Qwen3 8B Llama 3 70B

La línea roja punteada marca la VRAM realista disponible en una RTX 4090 después de cargar el modelo. Cualquier modelo cuya curva cruza esa línea no podrá servir ese contexto sin estrategias adicionales (cuantización del cache, offload, particionado).

La inferencia es memory-bound, no compute-bound

Hay un equívoco común: pensar que “GPU rápida = inferencia rápida”. En el régimen donde realmente operan los servicios de inferencia con KV cache, lo que se mide es el ancho de banda de memoria. Cada token nuevo exige leer las K y V de todos los tokens anteriores desde HBM. El cómputo es modesto; el movimiento de datos, masivo.

Por eso, una H100 SXM (3.35 TB/s de HBM3) puede ser 2–3× más rápida que una A100 (1.55–2 TB/s) sin que la frecuencia ni el número de cores expliquen del todo la diferencia. Lo explica el ancho de banda.

Y por eso, también, las ofertas de “GPU baratas con mucha VRAM pero HBM lenta” (algunas variantes con GDDR6 o LPDDR5) decepcionan en inferencia con contextos largos: tienen sitio para guardar el cache pero les cuesta una eternidad releerlo.

Trucos para que el cuaderno sea más fino

Tres técnicas, en orden cronológico, han ido aplanando el tamaño del KV cache:

Multi-Head Attention (MHA). El planteamiento original del transformer (Vaswani et al., 2017). Cada cabeza de atención tiene su propia K y V. Caro en cache pero teóricamente máximo en expresividad. Es lo que tenían los modelos hasta ~2023.

Multi-Query Attention (MQA). Una sola K y V compartida por todas las cabezas. Reduce el cache n_heads veces. Funciona razonablemente pero degrada calidad de generación en algunos benchmarks.

Grouped Query Attention (GQA). El término medio que ha ganado. Las cabezas se agrupan: en Llama 3 8B, 32 cabezas de query comparten K, V en grupos de 4 → 8 grupos de KV. Reduce el cache 4× respecto a MHA con casi idéntica calidad. Es el estándar de facto desde 2024.

Multi-Head Latent Attention (MLA). La innovación de DeepSeek-V2/V3: en vez de almacenar K, V por cabeza, comprime el estado en un vector latente más pequeño y proyecta a K, V en el momento. El cache puede llegar a 70 bytes/token, dos órdenes de magnitud menos que GQA. Es la razón principal por la que DeepSeek-V3 (671 B parámetros, 37 B activos) es servible en infraestructura abordable.

Nota: la barra de MLA es ilustrativa con valores típicos publicados por DeepSeek; la implementación exacta depende del tamaño latente. Lo importante es el orden de magnitud.

A esto se suma una cuarta técnica ortogonal: cuantizar el cache a FP8, INT8 o incluso INT4. vLLM y TensorRT-LLM ya lo soportan en producción. Pasar de BF16 (2 bytes) a FP8 (1 byte) divide el cache por dos con coste pequeño en calidad. Pasar a INT4, por cuatro, con coste algo mayor.

El siguiente dragón: la fragmentación

Hasta aquí hemos hablado del cache como si fuera un bloque contiguo. En la práctica, un servidor de inferencia atiende decenas de sesiones simultáneas, cada una con su propio cache que crece a un ritmo distinto. La asignación naïve —reservar el máximo posible por sesión— desperdicia entre el 60 % y el 80 % de la VRAM según el paper original de PagedAttention.

sesión A

sesión B

sesión C

sesión D

→ ~70 % de VRAM reservada y vacía

 <rect x="0" y="22" width="30" height="20" class="used blk"/>
<rect x="30" y="22" width="30" height="20" class="used blk"/>
<rect x="60" y="22" width="30" height="20" class="used blk"/>
<rect x="90" y="22" width="30" height="20" class="used blk"/>
<rect x="120" y="22" width="30" height="20" class="used blk"/>
<rect x="150" y="22" width="30" height="20" class="used blk"/>
<rect x="180" y="22" width="30" height="20" class="free blk"/>
<rect x="210" y="22" width="30" height="20" class="free blk"/>
<rect x="0" y="44" width="30" height="20" class="used blk"/>
<rect x="30" y="44" width="30" height="20" class="used blk"/>
<rect x="60" y="44" width="30" height="20" class="used blk"/>
<rect x="90" y="44" width="30" height="20" class="free blk"/>
<rect x="120" y="44" width="30" height="20" class="free blk"/>
<rect x="150" y="44" width="30" height="20" class="free blk"/>
<rect x="180" y="44" width="30" height="20" class="free blk"/>
<rect x="210" y="44" width="30" height="20" class="free blk"/>
</g>

→ < 4 % desperdicio (paper vLLM)

PagedAttention —la idea de Kwon et al. (2023) que dio origen a vLLM— resuelve esto pidiendo prestada una técnica de los sistemas operativos: dividir la VRAM en bloques pequeños (típicamente de 16 tokens) y mantener una tabla de páginas lógicas → físicas por sesión. Una sesión ya no reserva un bloque contiguo enorme: crece un bloque cada vez, y los bloques pueden estar dispersos por la VRAM. Resultado: ocupación efectiva del 90 % en lugar del 30 %, y por tanto 2–4× más throughput agregado en el mismo hardware.

PagedAttention merece artículo propio. Lo dejo apuntado para el siguiente.

Aplicado a la infraestructura Fibercli

Bajemos a casos concretos.

Caso 1 — RTX 4090 (24 GB, Ada Lovelace)

Configuración típica con Qwen3-8B BF16:

Modelo BF16: ~16 GB
Activations + overhead: ~2 GB
VRAM disponible para KV cache: ~6 GB (con margen)

Con 144 KB/token (Qwen3-8B GQA), eso son ~43 K tokens totales de cache distribuidos entre todas las sesiones simultáneas. En la práctica:

Concurrencia	Contexto máximo por sesión
1	32 768
4	8 192
8	4 096
16	2 048

Si necesitas anunciar “soportamos 32 K de contexto” con concurrencia 4+, hay que cuantizar el cache (FP8 baja a 72 KB/token, duplica capacidad) o subir el modelo de gama (un 4B con GQA y cache cuantizado holgaría).

Caso 2 — Cluster 5×H100 SXM (400 GB total, NVLink)

Con tensor parallel = 5 y Llama 3 70B BF16:

Modelo BF16: ~140 GB (28 GB/GPU)
Overhead vLLM por GPU: ~2 GB
VRAM libre para KV por GPU: ~50 GB → ~250 GB agregados

Con 320 KB/token (Llama 3 70B GQA), eso son ~800 K tokens totales de cache. Mucho margen para servir contextos largos con concurrencia alta:

Concurrencia	Contexto máximo por sesión
4	200 000
16	50 000
64	12 500

Para DeepSeek-V3 671 B con MLA: la economía cambia radicalmente porque el cache es ~100× más fino. Lo que limita ya no es el cache sino la VRAM del propio modelo (cuantizado FP8 son ~671 GB → no cabe en 5×H100, hace falta cluster mayor o FP4).

Implicaciones operativas

Tres observaciones que repetimos en cada consultoría:

Primero, el contexto máximo anunciado por un modelo no es el que puedes servir en tu hardware. Llama 3 8B “soporta” 128 K, pero en una 4090 con 4 sesiones simultáneas tu contexto efectivo son ~8 K. Es trivial comprobarlo antes de prometérselo al cliente.

Segundo, cuantizar el KV cache es de las optimizaciones con mejor relación coste/beneficio en el contexto ENS. No toca los pesos, no afecta a la reproducibilidad de auditoría, y duplica capacidad. vLLM lo soporta vía --kv-cache-dtype fp8.

Tercero, si los SLA dictan contextos largos con muchos usuarios concurrentes, GQA es necesario pero no suficiente. A medio plazo, hay que mirar modelos con MLA o variantes de attention con compresión.

Lo que no hemos cubierto (próximos artículos)

PagedAttention y su implementación en vLLM: bloques, tabla de páginas, evicción.
Prefix caching: cuando varias peticiones comparten el system prompt, no hace falta recomputar las K, V de la parte común.
Speculative decoding y su interacción con el cache.
Cache offloading: mover bloques fríos a RAM o a NVMe, técnica clave para contextos > 1 M.

Ver también

Fine-tuning continuo en producción: del tráfico real al adapter desplegado — cómo se cierra el ciclo entre inferencia y entrenamiento incremental sobre el mismo stack (vLLM + Postgres), con presupuestos de VRAM que incluyen explícitamente el KV cache durante eval.
Disaggregated serving: prefill y decode en pods especializados — el KV cache deja de ser un buffer privado de la GPU para convertirse en el artefacto que se transfiere entre pods. Aquí la fórmula del tamaño del cache determina la economía de la transferencia.

Referencias

Vaswani et al., Attention Is All You Need (NeurIPS 2017) — paper fundacional del transformer.
Ainslie et al., GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints (EMNLP 2023).
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023) — paper original de vLLM.
DeepSeek-AI, DeepSeek-V2 Technical Report (2024) — introducción de Multi-Head Latent Attention.
Documentación oficial de vLLM: https://docs.vllm.ai/.
Llama 3 model card (Meta): especificaciones GQA, n_layers, n_kv_heads.