Mlops on lo0 — Blog Técnico

El cluster GPU como plataforma: cómo convertir un cluster compartido en un servicio multi-tenant que tus equipos puedan consumir

Thu, 21 May 2026 07:15:00 +0200

TL;DR

Tener un cluster de GPUs caro y muchas cargas distintas que lo quieren usar no es un problema de infraestructura: es un problema de producto interno. Lo que separa “tenemos un cluster” de “tenemos una plataforma de inferencia” son cuatro capas que el mercado ha consolidado en 2026: una capa de gateway que centraliza autenticación, routing y políticas (LiteLLM, Portkey, Kong AI Gateway); un modelo de aislamiento GPU apropiado al perfil de los tenants (MIG hardware-isolation para multi-tenant no confiable, MPS para procesos del mismo equipo, time-slicing solo para dev); un sistema de quotas y rate limiting con presupuestos por tenant/equipo/proyecto (LiteLLM lo hace en su core a nivel team/user/api-key con 429s descriptivos); y un plano de observabilidad multi-tenant que permite cost attribution real (showback como paso intermedio, chargeback como destino), tracing por tenant y dashboards diferenciados. Aplicado a un cluster GPU mid-scale típico (un nodo con 4-8 H100 SXM y NVLink, un punto habitual para empezar en producción), esto se traduce en decisiones concretas: con ~640 GB de VRAM agregada en 8 GPUs y dos modelos típicos en producción (un modelo grande de 70B+ con tensor parallel y un modelo mediano replicado), el cluster sirve entre decenas y bajos centenares de sesiones simultáneas según mix; el aislamiento GPU se suele resolver con MIG en cargas inferiores y dedicación per-model en cargas grandes; y la métrica de éxito de la plataforma es la utilización efectiva, que en producción típica está en 30-40% y el objetivo razonable de optimización es subirla a 60-70% sin degradar SLA.

Este es el quinto post de la serie MLOps para LLMs. Es el más operacionalmente orientado y atraviesa varias etapas del pipeline (Deploy + Observe + transversales). El “estás aquí” señala las dos etapas activas porque la noción de plataforma multi-tenant no vive en una sola.

Estás aquí: Deploy + Observe (cluster como producto)

La pregunta que cambia el marco

Cuando un equipo de plataforma adquiere hardware GPU caro y empieza a montar inferencia, la primera versión casi siempre es mononosa: un modelo, un cliente, una latencia objetivo. Funciona. Cuando llega el segundo equipo pidiendo el mismo recurso, la mononosa se vuelve política interna: ¿cuántas réplicas le damos? ¿Qué hacemos si chocan los SLA? ¿Quién paga los tokens del experimento del equipo B? Y cuando llega el tercero, lo que era un proyecto de SRE pasa a ser un proyecto de producto interno.

La distinción no es técnica, es de marco. Un cluster es infra. Una plataforma es un servicio con clientes, contratos y métricas de éxito. El cambio de marco implica:

Clientes identificables (tenants), no usuarios anónimos.
Contratos (latency SLA, throughput garantizado, modelos disponibles), no “lo que dé tiempo”.
Métricas de éxito que no son técnicas sino de producto: adopción, satisfaction, cost per query por tenant, tiempo del primer “hello world”.

Este post recorre cómo se opera ese cambio de marco. Lo aterriza sobre un cluster mid-scale (4-8 H100 SXM con NVLink en un solo nodo), configuración habitual cuando se empieza con inferencia LLM seria; pero los principios se generalizan a cualquier topología, desde un nodo único con dos GPUs hasta clusters multi-nodo con InfiniBand.

Las cuatro capas de una plataforma de inferencia multi-tenant

La arquitectura canónica que se ha establecido en 2026 tiene cuatro capas que cualquier plataforma multi-tenant seria implementa, en orden de afuera hacia adentro:

Cada capa resuelve un problema concreto. Vamos a una por una.

Capa 1 — AI Gateway: la puerta de entrada única

El AI Gateway es el componente que tus tenants ven. Es una API HTTP/gRPC compatible con OpenAI (típicamente /v1/chat/completions, /v1/embeddings, /v1/models) que centraliza todo lo que pasa antes de tocar los backends de inferencia.

Por qué centralizar

Sin gateway, los tenants se conectan directamente a vLLM o al modelo que sea. Cada cambio (rotar un endpoint, añadir un modelo, cambiar credenciales, aplicar política) requiere notificar a todos los tenants. Cada tenant tiene su propia lógica de retry, su propio logging, su propio modelo de auth. Es inoperable a partir del tercer cliente.

Con gateway, el cambio se hace en un sitio. Los tenants tienen una URL estable y unas credenciales; el resto es problema del gateway.

Las tres opciones dominantes 2026

LiteLLM es la opción OSS más popular, Python-first, modelo de despliegue como proxy. Soporta 100+ proveedores (OpenAI, Anthropic, Bedrock, vLLM self-hosted, Ollama, etc.) detrás de una API OpenAI-compatible unificada. Hierarchy nativa multi-tenant con Organizations → Teams → Users → API Keys, cada nivel con budget independiente. Versión Apache 2.0 cubre lo básico; RBAC, SSO, audit logs y team-level enforcement requieren versión Enterprise paga. Despliegue en K8s con Helm chart oficial.

Portkey es la opción comercial / SaaS más madura. Single control plane que enforces budgets, quotas, permissions, compliance. Real-time spending tracking con alerting. RBAC, audit, workspaces, SSO incluidos. Trade-off: dependencia de un servicio externo y modelo de pricing por requests.

Kong AI Gateway es la opción para organizaciones que ya tienen Kong como API gateway. Plug-in AI sobre el gateway Kong existente, integra con su modelo de plugins, consumers y rate-limits. Si tu equipo de plataforma ya opera Kong, es la fricción más baja.

Cuándo elegir cada uno

Situación	Gateway
OSS puro, self-host, equipo Python-first	LiteLLM
Necesitas RBAC, SSO, audit log out-of-the-box, presupuesto disponible	Portkey
Ya operas Kong como API gateway corporativo	Kong AI Gateway
Greenfield enterprise con compliance estricto	Portkey (probablemente)
Empresa media OSS-first sin compliance regulado	LiteLLM (típicamente)

Lo que el gateway tiene que hacer mínimo

Independientemente de la opción, lo que cualquier deployment serio debe enforcer:

Auth y identidad: cada request lleva una API key resoluble a un tenant + usuario + equipo.
Routing por modelo: el tenant pide model: "gpt-4o"; el gateway decide si va a OpenAI, a Azure OpenAI, a tu vLLM con Qwen3 32B (fallback más barato), según política.
Rate limiting: RPS por tenant, TPM (tokens por minuto), concurrency limits.
Caching de respuestas idénticas: 5-30% de las queries de RAG son repetidas; cachear ahorra latencia y coste.
OTel emission: cada llamada produce un span con gen_ai.* semantic conventions y tenant_id como atributo. Cubierto en post de Evals y MCP observability.
Failover: si vLLM se cae, el gateway redirige a OpenAI API. Si OpenAI rate-limita, el gateway tira a Anthropic. Política configurable.

Ejemplo de configuración LiteLLM multi-tenant

# litellm-config.yaml — ejemplo simplificado
model_list:
 - model_name: llama-3-70b
 litellm_params:
 model: openai/llama-3-70b
 api_base: http://vllm-llama3-70b.inference/v1
 api_key: os.environ/VLLM_API_KEY

 - model_name: qwen3-32b
 litellm_params:
 model: openai/qwen3-32b
 api_base: http://vllm-qwen3-32b.inference/v1
 api_key: os.environ/VLLM_API_KEY

 - model_name: gpt-4o
 litellm_params:
 model: openai/gpt-4o
 api_key: os.environ/OPENAI_API_KEY

router_settings:
 routing_strategy: usage-based-routing-v2
 fallbacks:
 - llama-3-70b: [qwen3-32b, gpt-4o]  # si vLLM cae, fallback al externo

general_settings:
 master_key: os.environ/LITELLM_MASTER_KEY
 database_url: os.environ/DATABASE_URL  # Postgres para budgets/keys

# Hierarchy: Organizations → Teams → Users → API Keys
# Se crean vía API, no en YAML estático

Crear un team con presupuesto:

curl -X POST http://litellm/team/new \
 -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
 -d '{
 "team_alias": "soporte-chat",
 "max_budget": 500, # 500 USD/mes
 "budget_duration": "30d",
 "tpm_limit": 100000, # 100K tokens/min
 "rpm_limit": 1000, # 1000 requests/min
 "models": ["llama-3-70b", "qwen3-32b"] # acceso a estos
 }'

Y la API key del team:

curl -X POST http://litellm/key/generate \
 -H "Authorization: Bearer ${LITELLM_MASTER_KEY}" \
 -d '{
 "team_id": "<team-id>",
 "duration": "30d",
 "metadata": {"environment": "production", "app": "support-bot"}
 }'

Esa API key es lo que el tenant usa. Cada request que pase con ella consumirá del budget del team. Cuando se agote, LiteLLM devuelve HTTP 429 con descripción.

Capa 2 — Policy & Quota Plane: qué puede hacer cada tenant

El gateway es donde se enforza. La política es lo que se enforza. Cinco ejes de política multi-tenant:

Quotas técnicas

TPM (tokens por minuto): el límite duro de consumo. Para un Llama 3 70B en TP=5, ~3000 tokens/s salidos sostenidos = 180K TPM agregados. Si tienes 10 tenants, asignar 18K cada uno como techo.
RPS / RPM: control de carga, no de consumo. Una sesión de 4K tokens cuenta como una request; un batch de 100 mini-completions también. Útil contra abuso.
Concurrency: cuántas requests simultáneas activas por tenant. Importante para SLA de latencia: 100 RPS con concurrency=50 se traducen en 2 segundos por request.

Budgets económicos

Mensual por tenant: hard cap en USD.
Diario y por hora: soft caps para evitar runaway en un solo día.
Por proyecto / API key: granularidad fina dentro de un mismo tenant.

LiteLLM tiene un campo max_budget en cada nivel de la jerarquía (organization, team, user, api key). Los presupuestos se heredan/restringen hacia abajo.

Whitelist y blacklist de modelos

Tenants con cargas críticas → solo modelos estables (llama-3-70b, gpt-4o). Tenants de investigación → acceso también a modelos experimentales.

Priority classes

No todos los requests son iguales. Tres clases típicas:

Guaranteed: cargas con SLA, latencia respetada incluso bajo presión.
Best-effort: cargas normales sin SLA estricto.
Spot: batches que pueden esperar, evictable si llega un guaranteed.

El paper Token Management in Multi-Tenant AI Inference Platforms (2026) formaliza esto con un modelo de token pools por priority class que se ha empezado a adoptar en producción. Mantiene P99 latency garantizada para guaranteed workloads incluso bajo overload, throttling selectivo sobre spot.

Admission control

Antes de aceptar una request: ¿hay capacidad? Si no, devolver 429 inmediatamente en vez de encolar y degradar a todos. Es la disciplina operacional más infravalorada — un cluster con admission control bien hecho tiene latencia predecible; sin él, catastrophic degradation cuando llega el pico.

El patrón típico en 2026

# Política conceptual para un tenant "soporte-chat"
tenant: soporte-chat
quotas:
 tpm: 50000
 rpm: 500
 max_concurrency: 30
budget:
 monthly_usd: 800
 alert_thresholds: [0.5, 0.8, 0.95] # avisa cuando llegues
models_allowed:
 - llama-3-70b
 - qwen3-32b
priority: guaranteed
fallback_on_overload:
 - qwen3-32b  # si guaranteed se llena, fallback
 - gpt-4o-mini  # último recurso, modelo externo

Capa 3 — Isolation Plane: aislar las cargas físicamente

Esta es la capa más densa técnicamente. Tienes un nodo con varias GPUs H100 SXM interconectadas por NVLink. ¿Cómo las particionas entre tenants?

Tres mecanismos NVIDIA para compartir GPU

MIG (Multi-Instance GPU) es el aislamiento más fuerte. Particiona la GPU en hasta 7 instancias con memoria HBM separada físicamente y compute units (SMs) dedicados. Los tenants en MIG diferentes no pueden tocarse: una carga no consume memoria que otra necesita, una no degrada el throughput de otra. Aislamiento hardware. Disponible en A100, H100, B100, B200.

MPS (Multi-Process Service) es soft. Múltiples procesos comparten la GPU concurrentemente, NVIDIA reparte SMs según uso. Buen rendimiento si todos los procesos son tuyos y confías en ellos. Peor para multi-tenant entre clientes que no se conocen porque un proceso ruidoso puede degradar a los otros.

Time-slicing es lo más simple: la GPU se asigna alternadamente, slot por slot, a procesos distintos. Latencia mucho peor (waits entre slots); no se recomienda para cargas de producción con SLA.

La elección para multi-tenant 2026

Según el survey de adopción enterprise: 80% usa MIG para multi-tenant no confiable (clientes distintos que no se conocen) y MPS para entornos confiados (procesos del mismo equipo) donde quieres maximizar throughput. Time-slicing solo se usa en dev/staging para que cada developer toque GPU sin coste de exclusividad.

Limitación importante de MIG: aísla compute y memoria HBM, pero el camino PCIe sigue siendo compartido. Para cargas PCIe-bound (mucho tráfico host↔device), tenants en MIG distintos pueden seguir afectándose. Para inferencia LLM, el path principal es HBM, así que esto rara vez es problema. Pero conviene saberlo.

Las particiones MIG en H100

Una H100 (80GB HBM3) se puede particionar en perfiles fijos:

Perfil	SM	Memoria	Instancias máx por GPU
1g.10gb	14	10 GB	7
1g.20gb	14	20 GB	4
2g.20gb	28	20 GB	3
3g.40gb	42	40 GB	2
7g.80gb	98	80 GB	1 (toda la GPU)

Para un cluster mid-scale con NVLink, MIG tiene un problema fundamental: cuando particionas con MIG, se desactiva el NVLink entre GPUs. Una H100 en MIG no participa en tensor parallel multi-GPU. Si vas a servir un modelo grande con tensor parallel (Llama 3 70B con TP=4 o TP=8, por ejemplo), esas GPUs deben estar enteras, sin MIG.

Esto define la decisión arquitectónica. Hay dos enfoques principales:

Enfoque A — Modelo grande compartido con quotas en gateway

Todas las GPUs del nodo sirven un único modelo grande con tensor parallel que abarca el nodo entero. Todos los tenants comparten esa instancia. El aislamiento se hace en la capa de gateway (quotas, rate limiting) y la capa de policy (priority classes). El kernel del cluster es una sola instancia vLLM enorme con --max-num-seqs=128 o similar; vLLM internamente reparte tiempo de GPU entre las requests activas con continuous batching.

Ventajas: aprovechas todas las GPUs al máximo, NVLink activo, mejor utilización del KV cache. Desventajas: aislamiento blando — un tenant que satura no degrada a otros directamente (vLLM bachea), pero sí compite por slots del batch. Necesitas priority classes serias.

Enfoque B — Dedicar GPUs por modelo / tenant

Divides las GPUs en pools dedicados a modelos distintos. Ejemplos en un nodo de 8 GPUs:

4 GPUs: modelo grande de 70B con TP=4.
2 GPUs: modelo mediano de 32B replicado (2 instancias independientes) para tenants con SLA estricto.
2 GPUs: cargas misceláneas (modelos más pequeños, experimentación).

Ventajas: aislamiento físico entre modelos / tenants críticos. Desventajas: peor utilización agregada; algunas GPUs idle mientras otras saturan.

Enfoque C (avanzado) — MIG en algunas GPUs + dedicar el resto

Si tienes cargas pequeñas (modelos de 4B, 7B), puedes hacer MIG en 1-2 GPUs para servirlas y dedicar las restantes a tensor parallel del modelo grande. Combina aislamiento fuerte para cargas chicas con aprovechamiento del NVLink para el modelo grande.

La elección operativa: empieza por A, sube a C si hace falta

En la mayoría de despliegues, el Enfoque A (modelo grande compartido + quotas) es el punto de partida correcto. La utilización es mejor, la operación es más simple, y los aislamientos blandos del gateway funcionan para cargas razonables.

Cuando hay un tenant con SLA estricto que no tolera competir con otros, mueves a Enfoque B para ese tenant en particular (dedicar GPUs a una instancia del modelo solo para él), manteniendo el resto del cluster compartido.

Enfoque C es para cuando tienes 10+ tenants con perfiles muy heterogéneos.

Aislamiento a nivel Kubernetes

Independiente del aislamiento GPU, en K8s se aplica aislamiento de pod:

Namespaces por tenant: tenant-soporte, tenant-legal, etc.
ResourceQuotas y LimitRanges: límites de CPU/memoria por namespace.
NetworkPolicies: tenant A no puede hablar con namespaces de tenant B.
PriorityClasses K8s: clases con valor numérico que define preemption order si llega un pod más crítico.
PodDisruptionBudgets: cuántos pods de cada deployment pueden caer simultáneamente.

Capa 4 — Observability Plane: ver lo que pasa por tenant

La cuarta capa: observabilidad con dimensión tenant. Sin esto, no puedes hacer cost attribution, no puedes debugear incidentes de un solo tenant, no puedes mostrar dashboards a stakeholders.

Las cuatro propiedades obligatorias

1. tenant_id en todos los spans. El AI gateway resuelve la API key y atribuye un tenant_id. Ese ID se propaga vía params._meta o headers OTel a todos los componentes downstream (vLLM, retrieval, MCP servers, tools). Cualquier span en cualquier sistema lleva ese label. Es lo que permite reconstruir traces tenant-específicos.

2. Métricas labeled por tenant. gen_ai.usage.input_tokens{tenant="soporte-chat"} o equivalentes. Prometheus, Grafana, agrupable por tenant.

3. Cost attribution real. La suma de tokens × cost/token por tenant da el coste. Para vLLM self-hosted, el coste es por hora de GPU + parte proporcional de tokens (puedes calcular un cost-per-1k-tokens equivalente).

4. Audit log inmutable. Cada API key usada, cada modelo invocado, cada cambio de quota, cada budget exceeded. Para compliance.

Showback vs chargeback

Distinción importante de FinOps que ha ganado claridad en 2026:

Showback: visibilidad sin consecuencia. “Equipo de soporte, has consumido $623 este mes en LLM”. Información, no factura. Permite detectar abusos sin penalizar antes de que el equipo entienda.

Chargeback: el coste se imputa al presupuesto del equipo. Cuando se acaba, se acaba. Cambia comportamiento.

La práctica que funciona: 6-18 meses en showback mientras se calibran tags, se identifican misattributions, se forma a los equipos. Después chargeback cuando los números son creíbles. Lanzar chargeback el día 1 cuando los costs aún están sucios crea pelea política inmediata; lanzar showback prepara terreno para que el chargeback aterrice ordenadamente.

Solo 14% de organizaciones tienen chargeback activo según un survey reciente, lo que indica que esto sigue siendo mayoritariamente showback en producción real.

Herramientas

Kubecost: cost allocation por namespace, deployment, pod en Kubernetes. Para el coste de la GPU compartida, allocate proporcionalmente a tokens consumidos por tenant.
Finout: FinOps platform que combina cloud bills + LLM API costs en una vista unificada con tagging virtual.
Langfuse: ya cubierto. Cost tracking por trace, agrupable por usuario o session metadata.
LiteLLM tracking nativo: el master DB de LiteLLM mantiene running spend por team, user, API key, accesible vía API o UI.

Dashboard mínimo multi-tenant

Cualquier plataforma debería tener:

Resumen por tenant: spend mensual, RPS actual, TPM consumido, % budget gastado, sesiones activas.
Top usuarios dentro de cada tenant (para detección de abuso interno).
Latencia p95 por tenant: SLA tracking.
Errores 429 / 503: cuántas requests están siendo rate-limitadas o rechazadas por overload.
Cost trend: trayectoria mensual con proyección.
Drift por tenant (de la serie post-tracing): si un tenant empieza a tener peores resultados, alerta.

Dimensionado en clusters GPU mid-scale: decisiones concretas

Bajemos a hardware. Tomamos como referencia un nodo con N H100 SXM (entre 4 y 8) con NVLink/NVSwitch, 80 GB HBM3 cada una. Eso da entre 320 GB y 640 GB de VRAM agregada. Conectividad inter-GPU 900 GB/s (NVLink 4) o 600 GB/s (NVLink 3) según generación. Ancho de banda HBM por GPU 3.35 TB/s.

Decisiones por defecto

Empezar con Enfoque A: todas las GPUs del nodo sirviendo un único modelo grande de 70B en BF16 con tensor parallel = N. Capacidad real esperada (calculada para un nodo HGX estándar de 8 GPUs como ejemplo; escala aproximadamente lineal con N):

VRAM modelo (70B BF16): ~140 GB (≈ 17.5 GB/GPU en TP=8).
VRAM overhead vLLM + activations: ~10 GB/GPU.
VRAM libre para KV cache: ~52 GB/GPU. En un nodo de 8 GPUs son ~416 GB agregados; en uno de 4 son ~210 GB.
Con --kv-cache-dtype=fp8 y un modelo 70B GQA: ~320 KB/token.
Capacidad agregada de cache (nodo de 8 GPUs): ~1.3M tokens repartibles entre sesiones simultáneas.

Esto se traduce en throughput y concurrencia (cifras orientativas para un nodo de 8 GPUs):

Sesiones simultáneas	Contexto medio por sesión	Throughput agregado (tokens/s)
32	16K	~5000
64	8K	~8000
128	4K	~12000

Latencias típicas: TTFT ~150ms a tráfico bajo, TPOT ~15-20 ms/tok. Con concurrencia alta, TTFT sube hasta ~500ms si el queue está saturado.

Esquema de tenants ejemplo

Cluster con 4 tenants y un pool de research:

Tenant	TPM cap	RPM cap	Concurrency	Budget	Priority	Modelos
Soporte chat	80K	800	50	1500 USD/mes	Guaranteed	llama-3-70b, qwen3-32b
Legal RAG	30K	200	15	600 USD/mes	Guaranteed	llama-3-70b
Agente code	50K	300	25	1200 USD/mes	Best-effort	llama-3-70b, qwen-coder
Data extr. batch	40K	1000	40	400 USD/mes	Spot	llama-3-70b, qwen3-32b
Research / notebooks	10K	100	5	200 USD/mes	Spot	todos

Suma TPM: 210K. Capacidad agregada del cluster: ~180K TPM sostenidos. Está overcommit del ~15%, asumiendo que no todos los tenants llegan al techo simultáneamente. Es lo normal y deseable; si todos lo hacen al mismo tiempo, las priority classes degradan ordenadamente.

Cuándo añadir hardware

Señales que indican que el nodo se ha quedado pequeño:

TTFT p95 sostenida > 500 ms durante horas de pico → el queue se está acumulando.
vllm:num_requests_waiting constantemente > 20 → admission control empezando a rechazar.
Utilización GPU sostenida > 80% en horas críticas sin caer abajo en horas valle → no hay margen.
Tasa de 429 sobre los tenants guaranteed > 1% → la plataforma rompe SLA en producción.

Cuando varios de estos se cumplan, el siguiente paso natural es añadir otro nodo HGX con NVLink interno y montar una segunda instancia vLLM del mismo modelo. El gateway hace load balancing entre las dos instancias. Throughput agregado se duplica; latencia se mantiene.

Trampas operativas comunes

Gateway sin auth: backdoor al cluster

Tu vLLM está en un Service ClusterIP, la app principal habla con él. Algún tenant directo descubre el endpoint y le pega directamente sin pasar por el gateway. Quotas y costs se evaden silenciosamente. NetworkPolicy estricta: solo el gateway puede hablar con los Service vLLM; el resto del cluster no.

MIG y NVLink incompatibles

Activas MIG en una GPU pensando que tendrás aislamiento + multi-GPU; descubres que MIG desactiva NVLink. Cualquier modelo grande con TP queda inservible. Decide MIG vs NVLink globalmente por cluster, no por GPU individual.

Quotas pegadas al techo del cluster

Sumas los TPM de todos los tenants y dan exactamente la capacidad del cluster. Cuando dos tenants pico simultáneamente, ambos esperan o uno rechaza. Overcommit 10-20% es saludable (asume que no todos pican a la vez); más es peligroso.

Sin observabilidad multi-tenant desde el día 1

Lanzas con quotas y aislamiento pero sin tenant_id en spans. A los 3 meses, tu CFO pregunta “¿cuánto cuesta el agente de soporte vs el de legal?” y no puedes responder. OTel con tenant_id obligatorio desde la primera versión, aunque no haya dashboards aún; tener los datos vale más que tener dashboards perfectos sin datos.

Showback que nunca llega a chargeback

Llevas 18 meses en showback, los equipos saben los números, nadie cambia comportamiento. Sin la presión del chargeback real, el incentivo se diluye. Calendario explícito para la transición a chargeback, con dueño y deadline.

Modelos no whitelisteados consumiendo presupuesto

Un equipo descubre que LiteLLM tiene gpt-4o configurado. Lo usa sin permiso. El budget se quema en API externa cuando la idea era usar el self-hosted barato. Whitelist explícita por team de modelos accesibles.

Priority classes mal calibradas

Todo el mundo se declara “guaranteed”. En el primer pico, no queda nada por degradar y todo sufre. Priority classes solo para casos críticos con justificación. La mayoría debería ser best-effort.

Sin failover desde el gateway

Tu vLLM se cae. El gateway no tiene fallback configurado y devuelve 503 a todos los tenants. Fallback configurado a otro modelo, idealmente externo (OpenAI) para cargas guaranteed, aunque pague más por hora — la disponibilidad vale más que el coste por hora.

Roadmap operativo de arranque

Si parte de cero con un nodo GPU vacío, el orden mínimo es el siguiente. Cada hito es un día de trabajo con margen, no apretado:

Día 1-2 — Infra base K8s. NVIDIA GPU Operator + nvidia-device-plugin + dcgm-exporter + NetworkPolicies cluster-default. Validación: un pod básico con nvidia.com/gpu: 1 se schedulea.

Día 3 — vLLM con un modelo grande y tensor parallel del nodo entero. Helm chart de vLLM Production Stack (o vLLM bare manifests). Pesos del modelo en PVC compartido (CephFS o NFS). Validación: una petición curl contra el Service interno responde.

Día 4 — AI Gateway: LiteLLM. Helm chart, Postgres para budgets, master key, primer model_list pointing a vLLM. Validación: una petición OpenAI-compatible vía LiteLLM responde con el mismo contenido que el vLLM directo.

Día 5 — Multi-tenancy básica. Crear teams, API keys, budget, model whitelist. Probar con dos teams. Validación: el segundo team usando el modelo que no tiene whitelisteado recibe 403.

Día 6 — Observabilidad mínima. Prometheus + Grafana scraping vLLM y LiteLLM. Dashboard con TTFT, TPOT, throughput, num_requests_waiting, budget_consumed_per_team. Validación: visible en Grafana con datos reales.

Día 7-8 — Cliente piloto. Un tenant real (idealmente uno interno controlado) empieza a usar. Mide latencias reales, descubre los primeros incidentes operativos.

Día 9-10 — Tuning. Ajustar --max-num-seqs, --gpu-memory-utilization, priority classes, quotas según lo aprendido del piloto.

Día 11-14 — Onboarding del segundo tenant + iteración. Repeat. Cada nuevo tenant onboarded revela nuevos casos.

A las dos semanas tienes una plataforma operacional con dos tenants reales y datos para decidir si está lista para más. La línea de avance de aquí en adelante es horizontal (más tenants) hasta saturar; a partir de ahí, vertical (más hardware).

Lo que no hemos cubierto (próximos posts)

Fine-tuning continuo en producción (post 6, decidido): LoRA/QLoRA/DPO, dataset curation, eval gates, A/B versioning con tráfico real entre versiones del modelo.
Constitutional AI y alignment runtime: opción que sigue en la mesa.
Edge LLMs: cuando un cluster H100 es demasiado caro para una carga concreta, modelos distillados corriendo en NPUs o GPUs consumer.
GPU networking deep dive: NCCL, InfiniBand, GPUDirect, RDMA. Para clusters multi-nodo con tensor parallel cross-host.

Referencias

Multi-tenancy y aislamiento GPU:

Multitenant GPU Infrastructure: 4 Powerful Design Rules — survey de patrones enterprise.
Run Multiple LLMs on One GPU: MIG, Time-Slicing, and MPS Guide (Spheron).
A Practical Guide to GPU Partitioning with MIG (Medium).
GPU Partitioning for AI Workloads: NVIDIA MIG with SUSE Virtualization (KubeCon EU 2026).
Predictable LLM Serving on GPU Clusters (arxiv 2508.20274).
Token Management in Multi-Tenant AI Inference Platforms (arxiv 2603.00356) — paper de priority + admission control.

AI Gateways:

FinOps multi-tenant:

Cross-references:

Posts previos serie 4: Panorama MLOps LLMs, RAG sobre Kafka, Pipeline de 6 etapas, PostgreSQL + Qdrant.
Posts relevantes de la serie inferencia: vLLM en Kubernetes — el escenario de nodo HGX multi-GPU que aquí desarrollamos. Operators LLM K8s — vLLM Production Stack y OME que el gateway puede dirigir.
Observabilidad: Evals, MCP observability, eBPF + drift.

PostgreSQL + Qdrant en la etapa de ingestión: patrones de sincronización, microservicios y cómo encaja todo sin romperse

Thu, 21 May 2026 06:50:00 +0200

TL;DR

PostgreSQL es la fuente de verdad transaccional de la mayoría de las empresas; Qdrant es el motor de búsqueda vectorial que más equipos eligen cuando pgvector se queda corto. Combinarlos no es trivial: tu modelo de dominio vive en Postgres con ACID, las relaciones, las constraints, los triggers; los embeddings viven en Qdrant con HNSW filterable, quantization escalar, multivectors, sparse-dense hybrid search. Mantener los dos sincronizados es el problema operacional número uno que el campo LLMOps ha codificado en 2026 con tres patrones canónicos: dual-write (simple, frágil, válido para prototipos), transactional outbox + CDC con Debezium (la opción “correcta” para producción seria) y event-driven directo a Kafka (cuando el evento es el ciudadano de primera y la DB es proyección). La elección de Qdrant sobre pgvector se justifica con números concretos —filtered search 6ms vs 29ms en 500K vectores, 65% menos memoria con scalar quantization, HNSW filterable que no se hunde con metadata, escalabilidad horizontal—. El precio es operacional: un servicio stateful adicional que mantener, snapshots que gestionar, gRPC que asegurar. Este post entra en detalle en cómo se sitúa PostgreSQL + Qdrant en la etapa Data del pipeline LLMOps que dibujamos en el post anterior, qué microservicios participan, cómo se sincronizan, cómo se observan y dónde están las trampas que se ven una y otra vez en producción.

Este es el cuarto post de la serie MLOps para LLMs y el primero que aplica el patrón “estás aquí” sobre el mini-mapa que definimos en el post anterior sobre el pipeline de seis etapas. Aquí estamos plenamente en la primera etapa: Data.

Estás aquí: etapa Data del pipeline

La pregunta que define la arquitectura: ¿una DB o dos?

Antes de hablar de patrones, vamos a la decisión que marca el resto del diseño. Tienes datos transaccionales en PostgreSQL —usuarios, productos, documentos, conversaciones— y necesitas búsqueda vectorial sobre ellos para RAG. Dos respuestas razonables:

Opción A — pgvector dentro de Postgres: añades la extensión vector, una columna embedding vector(1536), un índice HNSW. Cero arquitectura nueva, cero servicio nuevo. Tu DBA sigue siendo el DBA. Una sola DB, ACID con tus tablas relacionales, JOINs entre embedding y metadata. Una sola fuente de verdad.

Opción B — Qdrant separado: dejas Postgres como está y montas Qdrant como servicio stateful aparte. Tu microservicio escribe a las dos. Dos fuentes parciales que mantener en sync.

La elección depende de números. Vamos a ellos.

Cuándo pgvector basta y cuándo no

Los benchmarks 2026 son consistentes. La regla del pulgar:

Hasta ~1M vectores: pgvector es excelente. Setup en minutos, cero overhead operacional, queries ACID con JOINs naturales.
1-10M vectores: pgvector funciona pero ya empiezas a sufrir. Index builds tardan, recall baja bajo carga, memoria sube linealmente.
>10M vectores: pgvector se hunde a no ser que tunes mucho. Index build pasa de horas; query p95 deriva por encima de 200ms.
>50M vectores: pgvector deja de ser opción razonable en single-node.

Qdrant escala a billones con sharding. Numéricamente, en 500K vectores con 3 condiciones de payload:

Qdrant: 6 ms p95 (filtered HNSW).
pgvector: 29 ms p95 (heap scans rompen la localidad del índice).

Y en memoria: Qdrant con scalar quantization usa 65% menos RAM que pgvector con IVFFlat sobre el mismo dataset. Para 50M vectores de 1024 dimensiones eso son decenas de GB de diferencia. Multiplicado por tres réplicas para HA, es un nodo entero menos.

Pero pgvector tiene una ventaja decisiva en proyectos pequeños y medianos: es gratis, embebido, y lo opera tu DBA. La fricción de adoptar Qdrant —un servicio stateful nuevo, gRPC, snapshots, observabilidad propia— solo se justifica cuando el dolor de pgvector es real, no anticipado.

El veredicto operativo 2026

Empieza con pgvector si tu corpus es <5M vectores y tu equipo es pequeño.
Migra a Qdrant cuando uno de los tres siguientes signos aparezca: latencia p95 inaceptable, presión de memoria sobre el cluster Postgres principal, necesidad de hybrid search (sparse + dense) avanzada.
No migres anticipadamente: el coste operacional de Qdrant es real; sufre cuando lo necesitas, no por si acaso.

Lo importante: diseña la capa de acceso a embeddings con una abstracción (un VectorStore interface en tu código) para que cambiar de pgvector a Qdrant sea cambiar la implementación, no reescribir la app.

Qdrant en detalle: lo que ofrece sobre pgvector

Si decides que Qdrant es la opción, vale la pena entender qué te da más allá del rendimiento bruto. Cinco features dominantes:

1. Filterable HNSW

El HNSW filterable es lo que más se nota en producción. En pgvector, filtrar por metadata (WHERE category = 'tech' AND date > '2026-01-01') hace que el índice HNSW pierda eficiencia: la búsqueda tiene que recorrer más nodos para encontrar los que cumplen el filtro. En Qdrant, el HNSW está construido para podar la búsqueda con filtros dentro del propio recorrido del grafo, sin escapar a heap scans externos. Para queries con filtros densos (lo normal en RAG con permisos multi-tenant), la diferencia es brutal.

2. Multivector y late-interaction (ColBERT)

Qdrant permite almacenar una matriz de vectores por punto, no solo un vector. Esto soporta nativamente modelos late-interaction como ColBERT, que codifican un vector por token y comparan con MaxSim. La calidad de retrieval con ColBERT-style multivectors es típicamente 5-15% mejor que single-vector en cargas semánticas complejas.

3. Sparse + dense hybrid search

Hybrid search combina un vector denso (semántico, eg embeddings de SentenceTransformers) con un vector disperso (lexical, eg SPLADE, BM25 reproducido como sparse). El denso captura “esto es semánticamente similar”; el disperso captura “esta palabra concreta aparece”. Combinados —tipicamente con reciprocal rank fusion o weighted combination— recuperan tanto la similitud semántica como los matches exactos de keyword. Es el patrón de retrieval que más calidad da en 2026 y Qdrant lo trae nativo desde la versión 1.10.

4. Quantization escalar y binaria

Para cargas grandes, Qdrant ofrece scalar quantization (int8 en lugar de float32, 4× menos memoria con pérdida marginal de recall) y binary quantization (1 bit por dimensión, 32× menos memoria con pérdida moderada que se recupera con rescoring de los top-K). En el roadmap 2026 está la 4-bit quantization, que será un punto medio.

5. Named vectors

Una colección Qdrant puede tener múltiples espacios vectoriales por punto, llamados named vectors. Caso típico: el mismo documento se indexa con un vector denso (text-embedding-3-small) y un vector sparse (SPLADE), bajo el mismo point_id. Las queries pueden buscar en el vector concreto que les interesa.

A esto se suma el roadmap 2026: 4-bit quantization, read-write segregation, expanded inference capabilities (Qdrant puede embeddar texto él mismo, sin un servicio externo).

La arquitectura de microservicios: dónde encaja cada pieza

Aquí está lo que el usuario que monta esto en producción tiene que diseñar. La arquitectura típica que se ha estabilizado tiene cinco microservicios que tocan estas piezas, cada uno con su responsabilidad clara:

Vamos a cada microservicio.

1. Domain Service

Responsabilidad: la lógica de negocio. CRUD de documentos, productos, conversaciones. Endpoints REST/gRPC para el front-end o para otros servicios. Solo conoce PostgreSQL como sistema de persistencia; no sabe nada de Qdrant.

Esto es importante por diseño: el domain service no debería tener nunca una referencia directa a Qdrant. Si la tiene, ya estás en el antipattern del dual-write. El domain service escribe a Postgres en una transacción ACID; el resto del pipeline se entera vía eventos.

2. PostgreSQL

Responsabilidad: source of truth transaccional. Schemas relacionales, constraints, triggers, ACID. Y la outbox table que veremos en breve, que es lo que va a permitir la sincronización fiable.

Patrón típico de despliegue: HA con Patroni + repmgr + PgBouncer para connection pooling, replicas de lectura para offloading.

3. Kafka

Responsabilidad: el bus de eventos. Recibe los cambios capturados por CDC (Debezium leyendo el WAL de Postgres o leyendo la outbox table) y los pone disponibles para los consumidores. Cubierto en profundidad en RAG sobre Kafka.

Topics típicos:

documents.changes: eventos crudos de cambio (insert/update/delete).
documents.embedded: eventos con embedding ya calculado.

4. Embedding Service

Responsabilidad: consumir eventos de cambio, calcular embeddings, publicar al topic embedded. Esta es la pieza que más coste consume si usas embeddings vía API (OpenAI, Cohere, Voyage AI).

Estructura típica:

Consumer Kafka con consumer group propio.
Batching de eventos para llamadas embedding (mucho más eficiente que uno a uno).
Llamadas paralelas con concurrency control.
Retry con exponential backoff ante rate limits.
Métricas exportadas (latencia, throughput, errores, coste).
Idempotencia (key del topic = doc_id, mismo doc no se re-embedea sin necesidad).

Patrón de optimización clave: deduplicate por hash de contenido. Si el documento se actualiza pero el texto no cambió (solo metadata), no merece la pena re-embedear. Hash + cache de embeddings ahorra 30-70% del coste en cargas reales.

5. Indexing Worker

Responsabilidad: consumir el topic embedded y hacer upsert a Qdrant. Es la pieza más simple de toda la arquitectura: lee del topic, escribe al vector store. Pero importante para la fiabilidad: tiene que ser idempotente (el mismo doc_id puede llegar varias veces si el consumer reinicia) y resiliente (si Qdrant está caído, reintentar sin perder eventos).

Estructura: Consumer Kafka con commit manual de offset solo después de confirmación del upsert. Si Qdrant falla, el offset no se commitea y el evento se reprocesa.

6. Retrieval Service

Responsabilidad: la cara que el LLM Service ve. Recibe una query del usuario, hace búsqueda en Qdrant (vector + filtros + reranker), enriquece los resultados con metadata fresca de PostgreSQL si hace falta, y devuelve top-K documentos con su contenido para que el LLM construya su prompt.

Es el único servicio que consulta Qdrant. Esto centraliza la lógica de retrieval: cuando quieras añadir reranking, hybrid search, query rewriting, lo haces aquí sin tocar el resto.

7. LLM Service

Responsabilidad: la generación. Recibe del Retrieval Service el contexto + query, construye el prompt, llama al LLM (self-hosted vLLM o API externa vía LiteLLM), devuelve la respuesta. Lo cubrimos en posts anteriores; no es el foco aquí.

El problema del dual-write y los tres patrones de solución

Aquí está la pieza arquitectónica más importante del post. El problema: tu Domain Service necesita escribir a dos lugares: PostgreSQL (el documento) y, indirectamente vía pipeline, Qdrant (el embedding del documento). Si lo haces ingenuamente —escribir a uno y luego al otro— tienes el problema del dual-write:

La escritura a Postgres tiene éxito, pero la publicación del evento a Kafka falla → el embedding no se calcula, Qdrant nunca se entera.
La publicación a Kafka tiene éxito, pero el commit a Postgres falla → evento fantasma, el embedding se calcula sobre algo que no existe.
El servicio crashea entre las dos operaciones → estado parcial, no sabes qué pasó.

Distributed transactions (two-phase commit) son la solución teórica pero nadie las quiere en producción: requieren coordinator XA, latencia alta, locking distribuido. La solución práctica son los patrones modernos. Tres opciones:

Patrón 1 — Dual-write naïve (prototipos)

El Domain Service escribe a Postgres, luego publica a Kafka:

async def create_document(doc):
 async with db.transaction():
 doc_id = await db.execute("INSERT INTO documents ...")
 await kafka.publish("documents.changes", {...})
 return doc_id

Funciona en happy path. Falla cuando algo entre las dos operaciones se rompe. Para prototipos donde la inconsistencia es aceptable, vale; para producción seria, no.

Patrón 2 — Transactional outbox + CDC con Debezium (la opción correcta)

Solución elegante: el Domain Service escribe a Postgres en una sola transacción que incluye tanto la tabla principal como una outbox table. La outbox no es consumida directamente; Debezium lee el WAL de Postgres y produce a Kafka los eventos de la outbox.

Schema típico:

CREATE TABLE outbox (
 id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
 aggregate TEXT NOT NULL, -- 'document', 'user', 'product'
 aggregate_id TEXT NOT NULL, -- el doc_id que cambió
 event_type TEXT NOT NULL, -- 'created', 'updated', 'deleted'
 payload JSONB NOT NULL,
 created_at TIMESTAMPTZ DEFAULT NOW()
);

Cuando el Domain Service crea un documento:

async def create_document(doc):
 async with db.transaction():
 doc_id = await db.execute("INSERT INTO documents (id, body) VALUES (...)", ...)
 await db.execute(
 "INSERT INTO outbox (aggregate, aggregate_id, event_type, payload) VALUES (...)",
 "document", doc_id, "created", json.dumps(doc)
 )
 # transacción committed; Debezium leerá el WAL y publicará a Kafka
 return doc_id

Lo crucial: las dos inserciones están en la misma transacción ACID de Postgres. O las dos van, o ninguna va. Garantía absoluta de consistencia local.

Configuración Debezium para leer la outbox:

{
 "name": "outbox-debezium-connector",
 "config": {
 "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
 "database.hostname": "postgres",
 "database.dbname": "app",
 "table.include.list": "public.outbox",
 "transforms": "outbox",
 "transforms.outbox.type": "io.debezium.transforms.outbox.EventRouter",
 "transforms.outbox.route.by.field": "aggregate",
 "transforms.outbox.table.field.event.id": "id",
 "transforms.outbox.table.field.event.key": "aggregate_id",
 "transforms.outbox.table.field.event.type": "event_type",
 "transforms.outbox.table.field.event.payload": "payload",
 "transforms.outbox.route.topic.replacement": "${routedByValue}.changes",
 "key.converter": "org.apache.kafka.connect.storage.StringConverter",
 "value.converter": "org.apache.kafka.connect.json.JsonConverter"
 }
}

EventRouter enruta a topics distintos según el valor de aggregate: eventos de document van a document.changes, los de user a user.changes, etc.

Ventajas: garantía “exactly-once” desde el punto de vista de la aplicación; eventos en orden del commit; sin polling.

Coste: una tabla extra, una configuración Debezium, ~5-10 ms extra de latencia en la escritura.

Patrón 3 — Event-driven directo (event sourcing puro)

Variante más radical: el evento es el primer ciudadano; PostgreSQL es solo una proyección. El Domain Service publica el evento a Kafka, y un consumer lo escribe a Postgres y otro lo procesa para embedding. No hay tabla principal, no hay outbox; el log Kafka es la fuente de verdad.

Más limpio conceptualmente pero requiere repensar el modelo de dominio (eventos como source of truth, queries reconstruidas de la proyección). Más adecuado para greenfield con equipo que entiende event sourcing.

Comparativa

Patrón	Setup	Consistencia	Cuando
Dual-write naïve	Trivial	Frágil	Prototipos, PoC
Outbox + CDC	Medio	Sólido	Producción seria (default)
Event-driven directo	Alto	Sólido	Greenfield con event sourcing

El default en 2026 para producción es outbox + CDC con Debezium. Es lo suficientemente simple para mantenerse, lo suficientemente robusto para no preocupar de noche.

Manifest completo: despliegue Qdrant en Kubernetes

Ya cubrimos cómo se monta el resto del pipeline (Kafka, Debezium, Flink) en el post anterior de Kafka. La pieza que añadimos aquí es Qdrant. Despliegue típico vía Helm chart oficial:

# values.yaml para qdrant/qdrant chart
replicaCount: 3 # cluster con 3 réplicas

image:
 repository: qdrant/qdrant
 tag: "v1.14.0"

persistence:
 enabled: true
 storageClassName: "fast-ssd"
 size: 200Gi

resources:
 requests:
 cpu: 2
 memory: 8Gi
 limits:
 cpu: 8
 memory: 16Gi

# clustering: cada réplica conoce a las otras
cluster:
 enabled: true
 consensus:
 tickPeriodMs: 100

# auth via API key
apiKey:
 enabled: true
 secretKeyRef:
 name: qdrant-auth
 key: api-key

# observability
metrics:
 enabled: true
 serviceMonitor:
 enabled: true # scrapping desde kube-prometheus

# snapshots periódicos
snapshots:
 enabled: true
 schedule: "0 3 * * *" # diario a las 3 AM
 retention: 7
 storage: "s3"
 s3:
 bucket: "qdrant-snapshots-prod"

config:
 storage:
 performance:
 max_search_threads: 8
 quantization:
 always_ram: true # quantized vectors en RAM
 service:
 enable_tls: true

Y la creación de la colección con configuración para hybrid search:

from qdrant_client import QdrantClient
from qdrant_client.models import (
 VectorParams, SparseVectorParams, Distance,
 HnswConfigDiff, ScalarQuantization, ScalarType
)

client = QdrantClient(url="https://qdrant.internal:6333", api_key=API_KEY)

client.create_collection(
 collection_name="documents",
 vectors_config={
 "dense": VectorParams(
 size=1536,
 distance=Distance.COSINE,
 on_disk=False, # en RAM para latencia
 )
 },
 sparse_vectors_config={
 "sparse": SparseVectorParams() # para BM25-style lexical
 },
 hnsw_config=HnswConfigDiff(
 m=16,
 ef_construct=128,
 on_disk=False
 ),
 quantization_config=ScalarQuantization(
 scalar=ScalarType.INT8 # 65% menos memoria
 ),
 on_disk_payload=True, # payload en disco
 shard_number=6, # particionado para escala
 replication_factor=2, # cada shard replicado
 write_consistency_factor=1
)

Con esta config, una colección de 50M vectores de 1536 dimensiones ocupa ~150-200 GB en RAM (vs ~600 GB con float32 puro), con queries p95 sub-10ms en cargas típicas.

Observabilidad: ver qué está pasando

Cuatro métricas que cualquier dashboard mínimo de la etapa Data debería tener:

1. Lag del outbox

debezium_lag_seconds: cuánto tarda Debezium en leer un evento desde que se commitea. Objetivo: <1 segundo. Si sube, indica WAL retention insuficiente o consumer rate menor que producer.

2. Lag del embedding service

embedding_service_consumer_lag_messages: cuántos eventos pendientes hay en el topic documents.changes. Objetivo: <100 sostenido. Si crece, indica que el rate de cambios supera la capacidad del embedding service. Soluciones: más consumers (paralelismo), batching más grande, modelo de embedding más rápido.

3. Tasa de upsert a Qdrant

qdrant_upsert_rate y qdrant_upsert_p95_latency. Objetivo: latencia <50 ms p95, tasa estable acorde al CDC rate. Si la latencia sube, Qdrant está degradado (memory pressure, disk slow, conn pool saturado).

4. Recall en producción (offline check)

Una vez al día, ejecutar un job que toma N queries reales, busca en Qdrant, busca en pgvector si lo mantienes en paralelo, compara recall@k. Si Qdrant deja de devolver lo que debería, lo detectas antes de que un usuario se queje.

Trampas operativas comunes

Sin outbox: el equipo aprende dual-write a base de incidentes

Lo más común. La primera versión hace dual-write directo “para empezar simple”; un día se cae Kafka durante 10 minutos y miles de embeddings quedan sin generar. Migrar a outbox después de tener tráfico es caro porque hay que backfill. Outbox desde el día 1.

Reembedding ignorante del coste

Cambias el modelo de embedding (text-embedding-3-small → text-embedding-3-large). Tu pipeline reemboda los 5M documentos. 17 horas y $1500 de coste que nadie anticipó. Calcular reembedding upfront: documentos × tokens promedio × coste/1k tokens × throughput limits.

Snapshot de Qdrant sin testear restore

Sacas snapshots diarios pero nunca pruebas restaurar. Un día Qdrant se corrompe y descubres que el snapshot está incompleto o que tu storage class no permite recuperarlo. Test trimestral de restore en entorno paralelo, obligatorio para producción.

Qdrant detrás de Service ClusterIP estándar sin gRPC affinity

Qdrant habla gRPC. Si el Service hace round-robin connection-level pero el cliente reusa connections, todo el tráfico va a un solo pod. Headless Service + client-side load balancing o gRPC-aware service mesh.

PG y Qdrant sin shared trace id

El Domain Service recibe un request, lo procesa, escribe a PG, dispara evento. Cuando un día algo va mal, no puedes correlar el span del Domain Service con el span del Indexing Worker porque no propagaste trace context. OTel context propagation por el topic Kafka (vía headers Kafka), igual que hicimos en el post de MCP observability.

Vector y metadata en sync nominal pero no real

PG dice “documento X tiene categoría tech”; Qdrant dice “documento X tiene categoría legal” (porque el cambio de categoría se actualizó en PG pero el evento de update no llegó a regenerar el payload en Qdrant). Filtras category=tech, no aparece. Tests periódicos de consistencia cross-store sobre muestreo aleatorio.

Dimensión del vector hardcodeada en mil sitios

1536 aparece en el código del Domain Service, del Embedding Service, del Indexing Worker, del Retrieval Service, en la creación de la colección Qdrant. Cuando cambias modelo (a uno de 768 dimensiones), olvidas uno y todo se rompe. Configuración centralizada del modelo + dimensión.

Sin rate limiting al embedding provider

Tu CDC procesa una migración masiva: 1M documentos cambian. El embedding service intenta procesar todo a la vez. OpenAI te rate-limita, el consumer queda atascado, los eventos se acumulan, tu cluster Kafka queda con horas de lag. Rate limiting en el consumer, no en el producer.

Cuándo NO usar Qdrant: el contrapunto honesto

Para no presentar Qdrant como bala de plata:

Tu corpus es <1M vectores y no esperas crecer. pgvector basta y te ahorra un servicio.
Tu equipo es pequeño y no tiene capacidad de operar un stateful service más. Qdrant añade snapshots, gRPC, mTLS, observabilidad propia. Cada uno de esos puntos es un día de trabajo de un SRE.
Tu retrieval es batch off-hours, no real-time. Si solo haces RAG para reportes nocturnos, la latencia de pgvector no duele.
Necesitas JOINs nativos entre embeddings y tablas relacionales en queries críticos. pgvector permite hacer JOIN documents d ON d.id = embedding.doc_id WHERE d.tenant_id = X. Qdrant lo simula con payload pero menos elegante.

Y al revés, cuando Qdrant gana claramente:

Corpus >10M vectores con queries con filtros densos.
Necesidad de hybrid search nativo (sparse + dense + multivector).
Multi-tenant con strict latency requirements por cliente.
Quantization agresiva para mantener todo en RAM en hardware limitado.
Cluster mode con sharding horizontal real.

Lo que no hemos cubierto

Migración pgvector → Qdrant en vivo: patrón con dual-read durante la transición.
Vector search federation: queries que cruzan múltiples Qdrant collections o múltiples vector stores. Tema propio.
Multi-tenancy en Qdrant: payload filters + namespace isolation + per-tenant rate limiting.
Cold storage para vectores antiguos: archivo de partitions a object storage con índice secundario.
Embedding model self-hosted con vLLM: alternativa a OpenAI API que reduce coste y mejora privacidad. Tema cruzado con la serie de inferencia.

Referencias

PostgreSQL y pgvector:

PostgreSQL pgvector extension (GitHub) — el de toda la vida.
Pgvector vs Qdrant (Tiger Data) — comparativa con números.
Start with pgvector: Why You’ll Outgrow It Faster Than You Think (Qdrant blog) — los tradeoffs honestos desde Qdrant.

Qdrant:

Qdrant — sitio oficial.
Qdrant changelog.
Sparse Vectors in Qdrant — hybrid search nativo.
Multivectors and Late Interaction — ColBERT-style.
Qdrant 2025 Recap: Powering the Agentic Era — estado del proyecto y roadmap.

Outbox y CDC:

Reliable Microservices Data Exchange With the Outbox Pattern (Debezium blog) — el post canónico.
The Outbox Pattern Explained (Streamkap).
Outbox Pattern with Debezium (Thorben Janssen).
Distributed Data for Microservices — Event Sourcing vs CDC (Debezium blog) — comparativa entre patrones.

Comparativas 2026:

Cross-references:

Post anterior: Pipeline LLMOps de 6 etapas — donde definimos el mini-mapa.
RAG sobre Kafka — arquitectura técnica — la pieza que precede a Qdrant en el pipeline.
Panorama MLOps LLMs 2026 — el marco general.
Series previas: post-tracing y eBPF.

El pipeline LLMOps de seis etapas: arquitectura global y deep dive en cada componente

Thu, 21 May 2026 06:30:00 +0200

TL;DR

Los dos primeros posts de la serie establecieron el panorama LLMOps y bajaron al detalle del pipeline de datos con Kafka. Este post hace el zoom intermedio: dibuja el mapa completo del sistema —una arquitectura global de un LLMOps moderno con todas las piezas que el campo ha estabilizado en 2026— y entra en profundidad en cada una de las seis etapas canónicas del pipeline: Data, Tune, Eval, Deploy, Observe, Retrain. Para cada etapa damos las sub-tareas operativas, las herramientas dominantes, las decisiones de diseño que aparecen siempre, y las trampas específicas que se ven repetidamente en producción. Y, lo más importante operativamente: cada etapa lleva un mini-mapa “estás aquí” sobre el ciclo, que se reutilizará en cualquier post posterior de la serie para situar al lector. La idea: que cualquiera leyendo un post sobre fine-tuning, sobre prompt versioning, sobre eval gates o sobre drift detection, pueda mirar el mini-mapa y saber inmediatamente en qué pieza del sistema más grande está pensando ese día.

Este es el tercer post de la serie MLOps específico para LLMs. Anteriores: Panorama 2026 y RAG sobre Kafka. Aquí pasamos de “el qué” y “una pieza” a el mapa entero, con detalle por etapa.

La arquitectura global: el mapa maestro

Antes de bajar a cada etapa, fijemos el mapa entero. Lo que sigue es el dibujo de referencia de un sistema LLMOps de producción en 2026, con todos los componentes que el campo ha estabilizado en su lugar:

Lo que ves: las seis cajas grandes son las etapas; las flechas continuas son el flujo del pipeline; la flecha discontinua que va de Retrain a Data es el ciclo de feedback que convierte LLMOps en un proceso vivo, no en un proyecto que termina. La banda gris al pie son componentes transversales —observabilidad, prompt versioning, MCP, gateway, schema— que atraviesan todas las etapas y se conectan a cada una.

Tres lecturas rápidas del mapa:

Horizontal arriba: el camino feliz, data → tune → eval. Lo que pasa cuando preparas el modelo.
Horizontal abajo: el camino de servicio, deploy → observe → retrain. Lo que pasa cuando el modelo está vivo.
Vertical: la conexión entre los dos pisos. Eval gateway alimenta Deploy; Observe alimenta Retrain; Retrain devuelve a Data.

Cada etapa de aquí en adelante incluirá un mini-mapa de navegación (“estás aquí”) para situarte en el ciclo completo. Vamos a cada una.

Etapa 1 — Data: ingestión, transporte, versionado, indexación

Sub-tareas operativas

La etapa Data es la más infravalorada y la que más bloquea proyectos. Sus sub-tareas:

Ingestión desde origenes heterogéneos: bases de datos OLTP (Postgres, MySQL), APIs externas, file shares, scraping, sistemas SaaS, logs de aplicaciones, mensajería interna.
Captura de cambios (CDC) en streaming si el dato es dinámico. Debezium sobre Kafka, Flink CDC, alternativas modernas como RisingWave que lee WAL directamente.
Transformación (cleansing, dedup, normalización, sanitization de PII).
Schema management: registro de esquemas, evolución compatible, compatibilidad backward/forward.
Versionado de datasets de training y golden datasets: DVC + lakeFS (unificadas en noviembre 2025).
Indexación para RAG: chunking, embeddings, escritura a vector stores. Cubierto en profundidad en el post de Kafka.
Materialización a tablas analíticas: Tableflow → Iceberg/Delta, para consumo de BI y queries de baja latencia.

Herramientas dominantes

Sub-tarea	Herramientas 2026
CDC	Debezium, Flink CDC, RisingWave
Transport	Kafka (Confluent Cloud, Redpanda, Apache puro)
Schema Registry	Confluent Schema Registry, Apicurio
Stream processing	Apache Flink, RisingWave, Kafka Streams
Versionado de datos	DVC + lakeFS
Vector stores	Milvus, Qdrant, Weaviate, pgvector, LanceDB
Tablas materializadas	Tableflow → Iceberg/Delta
ETL/ELT batch (cuando aplica)	dbt + Snowflake/Databricks

Decisiones de diseño

Las tres decisiones que aparecen siempre:

Batch vs streaming: cuanto más dinámico sea el dato, más streaming. Para corpus estáticos (manuales que nunca cambian) batch nocturno basta; para datos transaccionales que el agente necesita ver minuto a minuto, streaming desde el día 1.

Embedding model: cambiar el modelo de embeddings invalida todos los vectores indexados. Decisión arquitectónica: pinning del modelo + plan explícito de migración (dual-index pattern visto en el post de Kafka).

Vector store: pgvector si ya tienes Postgres operado y eres <10M vectores; Qdrant si quieres simplicidad mid-scale; Milvus si necesitas billones; Weaviate si valoras hybrid search nativo.

Trampas

Hardcodear conexiones a la fuente (sin abstracción): cuando la base de datos cambia (versión, host, esquema), rompes todo el pipeline. Adapter layer desde el día 1.
Sin schema registry: los topics empiezan a romperse silenciosamente.
Reindexación full cuando algo cambia: cuesta horas o días. Diseñar dual-index pattern desde el principio.
PII no sanitizada: el RAG está sirviendo datos sensibles sin querer. Anonymización en el pipeline, no en el consumo.

Etapa 2 — Tune: preparar el modelo para tu caso

Sub-tareas operativas

Selección de modelo base: Llama, Qwen, Mistral, Gemma, DeepSeek según licencia, tamaño, calidad en tu dominio.
Preparación del dataset: split train/val/test, formato (chat templates, JSONL), augmentación si aplica.
Configuración del adapter: LoRA rank, target modules, alpha; QLoRA si quieres entrenar en una GPU consumer; full fine-tune solo si tienes presupuesto.
Training loop: HuggingFace Transformers + PEFT + TRL como stack canónico; Axolotl o llama-factory como wrappers convenience; Unsloth si quieres 2-4× más velocidad en GPUs consumer.
Hyperparameter sweep: W&B Sweeps, Optuna, Ray Tune.
Checkpointing y resumability: save cada N pasos, resume desde fallo.
Promotion: el adapter promueve al registry tras pasar la siguiente etapa (Eval).

Las tres modalidades de Tune

Detalle del cuadro que vimos en el panorama:

Fine-tuning supervisado (SFT) con LoRA/QLoRA. Recoges pares (prompt, ideal-response), aplicas SFT con cross-entropy loss. Lo más simple. La regla del pulgar: 300-3 000 ejemplos bien curados suelen ser más útiles que 50 000 ruidosos.

DPO (Direct Preference Optimization) y RLAIF. En vez de “ideal-response”, recoges pares (prompt, respuesta_buena, respuesta_mala) y entrenas al modelo a preferir la buena. Más estable que RLHF clásico, mismo objetivo. Es lo que la mayoría de equipos usa cuando van más allá de SFT.

Agent training (RFT / Reinforcement Fine-Tuning, RLHF puro). Para casos donde el modelo necesita aprender trayectorias multistep: cuándo elegir tool A vs B, cuándo pedir confirmación, cómo descomponer una tarea grande. Mucho más caro y complejo. Lo de OpenAI con RFT marcó el patrón en 2024-2025; en 2026 está saliendo del experimental.

RAG como alternativa a Tune: aunque conceptualmente es otra etapa (vive en Data + Deploy), funcionalmente compite con fine-tuning para muchos casos. El veredicto 2026: hybrid es default (60% de despliegues), fine-tune para behavior + RAG para conocimiento volátil.

Herramientas

Aspecto	Herramientas 2026
Framework base	HuggingFace Transformers, PEFT, TRL
Wrappers convenience	Axolotl, llama-factory
Velocidad consumer	Unsloth (2-4× speedup en GPUs RTX)
Distributed training	DeepSpeed, FSDP, NeMo Framework
Experiment tracking	MLflow, W&B, ClearML
Adapter registry	HuggingFace Hub privado, MLflow registry
Hyperparameter	W&B Sweeps, Optuna, Ray Tune

Trampas

Catastrophic forgetting: SFT muy agresivo destruye capacidades generales del modelo. Conservar small % del dataset original o usar regularización.
Overfitting al golden dataset: el modelo aprende a memorizar el set de eval. Mantener un test set holdout que nadie del equipo mira hasta el release final.
Train/serve skew: prompts en training con formato distinto al de producción. Mismo chat template en ambos.
Lora rank demasiado alto: parece mejorar metricas pero infla el adapter sin beneficio real. Empezar con r=8 o r=16; subir solo si hay evidencia.

Etapa 3 — Eval: validar antes de promover

Sub-tareas operativas

Cubierto en profundidad en Evals: la capa después del tracing. Resumen estructurado para el pipeline:

Curación del golden dataset: 100-500 ejemplos como mínimo, mantenidos activamente con casos de incidentes.
Evaluators: heurísticos (regex, length), semánticos (embeddings), LLM-as-judge (G-Eval), humanos (golden labels).
Ejecución en CI: bloquear el merge si métricas críticas caen >X%.
Ejecución en platform: sobre tráfico de producción muestreado, persistir resultados, detectar regresión a largo plazo.
Calibración del judge: 85-90% agreement con humanos antes de aceptar el judge como productivo.
Eval gates: thresholds explícitos por métrica (faithfulness > 0.85, relevancy > 0.80, etc.).

Herramientas

CI gates: DeepEval (Apache 2.0, pytest-style), Promptfoo (MIT, CLI), Ragas (RAG-specific), Inspect AI (safety/capability).
Platform: Langfuse (MIT, suite completa), LangSmith (LangChain), Phoenix (ELv2, OTel), Braintrust.
Judges: GPT-4 (caro pero referencia), Claude 3.5 Sonnet, Prometheus (OSS 0.897 correlación), JudgeLM.

Trampas

Golden dataset envejecido: si no se actualiza, deja de reflejar producción.
Judge contaminado: el judge sabe del dataset (apareció en su training).
Sample size insuficiente: <50 ejemplos hace que diferencias parezcan ruido.
Costes runaway: G-Eval con GPT-4 sobre muchos casos cuesta miles USD/mes.
Olvidar el segmento: media 0.85 puede esconder 0.55 en alemán.

Etapa 4 — Deploy: poner el modelo en producción

Sub-tareas operativas

Cubierto en profundidad en vLLM en Kubernetes y Operators LLM K8s. Resumen para el pipeline:

Selección del runtime: vLLM (default), SGLang (agentes con prefix caching alto), TensorRT-LLM (latencia pura), llama.cpp (edge).
Selección del operator: vLLM Production Stack, KServe, OME (LMSYS), NVIDIA Dynamo, llm-d (CNCF).
Configuración del serving: --tensor-parallel-size, --kv-cache-dtype=fp8, --enable-prefix-caching, --enable-chunked-prefill, --gpu-memory-utilization=0.92.
Routing entre modelos: LiteLLM como abstracción para multi-provider.
Estrategia de release: canary (1% → 10% → 100%), blue-green (todo o nada con rollback rápido), shadow (eval en paralelo sin afectar usuarios).
Autoscaling con métricas LLM: KEDA + Prometheus sobre vllm:num_requests_waiting o equivalente.
Gateway / Inference Extension: Gateway API Inference Extension cuando esté GA.

Herramientas dominantes

Serving engines: vLLM, SGLang, TensorRT-LLM, llama.cpp, MLX.
Operators: OME, vLLM Production Stack, NVIDIA Dynamo, llm-d, KServe.
Routing: LiteLLM (100+ providers), OpenRouter (managed), LangChain Router.
GPU primitivas: NVIDIA GPU Operator, LeaderWorkerSet (LWS) para tensor parallel multi-pod, KEDA para autoscaling.

Trampas

Rolling update naïve que corta sesiones: maxUnavailable: 0, maxSurge: 1 y terminationGracePeriodSeconds: 120+.
readiness probe corta que mata pods cargando: startupProbe con failureThreshold: 60.
HPA por CPU% sin métricas LLM: vLLM bachea internamente, una réplica atiende decenas. KEDA por queue depth.
KV cache sin cuantizar: --kv-cache-dtype=fp8 casi siempre rentable.
Tensor parallel en GPUs sin NVLink: all-reduce satura PCIe, throughput se hunde.

Etapa 5 — Observe: ver lo que pasa en producción

Sub-tareas operativas

Esta es la etapa que más profundamente hemos cubierto en series previas: toda la serie eBPF (4 posts) y la serie post-tracing (4 posts) tratan sub-tareas de Observe. Resumen estructurado:

Tracing: OpenLLMetry/Traceloop, Langfuse, Phoenix, LangSmith. Spans con OTel GenAI semantic conventions (gen_ai.*, mcp.*).
Métricas: Prometheus + Grafana. TTFT, TPOT, throughput, queue depth, KV cache usage, cost por tool.
Guardrails activos (no solo eval): NeMo Guardrails con rails de 5 tipos, Llama Guard 4 multimodal, Llama Prompt Guard 2 (86M/22M), LLM Guard.
eBPF observability (zero-instrumentation): Hubble (red), Tetragon (proceso/syscall), AgentSight (agente LLM con SSL uprobes + stdiocap MCP).
eBPF en motor local (inferencia): ProfInfer-style con uprobes en llama.cpp / vLLM / libcudart.
Drift detection: Evidently AI, NannyML, WhyLabs. KS, PSI, MMD sobre embeddings.
MCP observability: OpenTelemetry GenAI MCP semantic conventions, trace propagation via params._meta, MCP Gateway centralizado.

Las cuatro métricas obligatorias

De todo lo cubierto, las cuatro que cualquier dashboard mínimo debe tener:

TTFT p50/p95 (time to first token) — lo que el usuario percibe.
TPOT p50/p95 (time per output token) — velocidad de streaming.
Throughput (tokens/segundo agregados) — capacity planning.
Queue depth (vllm:num_requests_waiting) — indicador adelantado.

A esto se suman, por dominio:

Para RAG: faithfulness rolling mean, retrieval hit rate.
Para agentes: tool call accuracy, multi-step task completion.
Para multi-tenant: cost per tenant, p95 latency per tenant.

Trampas

Cardinalidad en Prometheus: las métricas con todos los labels K8s explotan.
Tracing sin sampling: el storage crece sin control.
Guardrails permanentemente en monitoring mode: nunca llegan a enforce.
Drift sin alertas: detectas drift en el dashboard una vez al mes; mientras tanto el problema lleva semanas.
OTel sin propagación: spans MCP, Tetragon, AgentSight desconectados.

Etapa 6 — Retrain: cerrar el bucle

Sub-tareas operativas

Esta es la etapa que más se descuida en proyectos GenAI. Cerrar el bucle convierte LLMOps en una práctica viva; no cerrarlo lo deja como un proyecto que envejece.

Feedback explícito: thumbs up/down en la UI, anotaciones por usuarios power, formularios para “qué falló”.
Feedback implícito: latencia anómala, abandonment rate, retries del usuario, sesiones abortadas.
Triaging de incidentes: clasificar incidentes por causa raíz (model issue, retrieval issue, prompt issue, infra issue).
Dataset enrichment: incorporar al golden dataset los casos donde el sistema falló, con la respuesta correcta etiquetada por humano.
Cadence de retrain: trimestral por defecto, incident-driven cuando un patrón problemático supera threshold.
Promotion: el nuevo modelo/adapter pasa por las etapas Tune → Eval → Deploy, con eval gates que comparan contra el modelo en producción.

Las dos cadencias

Scheduled retrain (trimestral o semestral): un proceso establecido. Permite planificar capacity, presupuesto, riesgo. El default.

Incident-driven retrain: cuando un incidente serio (drift detectado, segmento que falla, ataque de prompt injection) supera threshold, se dispara un mini-ciclo. Más caro pero necesario para casos críticos.

Herramientas dominantes

Annotation y feedback collection: Langfuse (UI built-in), Argilla (OSS), Label Studio.
Dataset enrichment: pipelines en Airflow o Argo Workflows.
Triaging: dashboards Langfuse + filtros por traces con eval bajo.
Promoting candidate: MLflow model registry stages.

Trampas

Bucle abierto: producción no informa al dataset; el modelo nunca mejora.
Feedback humano se pierde: thumbs down sin canal de captura estructurado.
Cadence sin definir: “ya retrenamos cuando haga falta” → nunca se retrena.
Sin holdout test set: el golden dataset se enriquece con los mismos casos que se usan para evaluar; eval mide memorización.
Promotion sin gates: el nuevo modelo entra a producción sin pasar las verificaciones de los modelos anteriores.

El ciclo completo: cómo encajan las etapas

Ahora que vimos cada etapa por separado, el insight clave es cómo se enganchan. Cinco propiedades emergentes del ciclo:

1. Data es la materia prima de todas las etapas. Tune lee del golden dataset. Eval lee del eval dataset. Deploy lee del RAG (vector store). Observe produce nuevos datos. Retrain crea datasets nuevos. El log Kafka es el evangelio del sistema entero (post 2 de la serie).

2. Eval es el gatekeeper bidireccional. Antes de Deploy: bloquea release si el modelo regresa. Después de Observe: alimenta Retrain identificando casos peor evaluados. La calidad del eval determina la calidad del ciclo entero.

3. Observe alimenta a Retrain y a Eval simultáneamente. Las traces producen métricas para Observe; las traces problemáticas se anotan y van al dataset; los nuevos casos enriquecen el eval golden. Observe es la fuente de verdad operativa.

4. Los componentes transversales (banda gris del mapa) no son una etapa, son una infraestructura. OpenTelemetry, prompt versioning, MCP gateway, model gateway, schema registry. Mal configurados, cada etapa sufre por separado. Bien configurados, las etapas se integran sin fricción.

5. El ciclo no es secuencial estricto, es concurrente. En cualquier momento dado, el sistema tiene: requests siendo servidas (Deploy + Observe), una versión nueva en training (Tune), eval continuo en CI (Eval), datos llegando del CDC (Data), análisis de incidentes (Retrain). Todas las etapas están vivas a la vez.

Trampas cross-etapa: cosas que rompen el sistema entero

Hay errores que no son de una etapa, sino de las interfaces entre etapas. Los más comunes:

Train/serve skew

El formato exacto del prompt en training es distinto al de producción. Resultado: el modelo entrenado para responder a <|im_start|>user\n...\n<|im_end|> recibe en producción User: ...\nAssistant: y rinde peor. Solución: extraer el chat template en una librería compartida que use el pipeline de Tune y el de Deploy.

Eval que no refleja producción

Tu golden dataset son preguntas cuidadas; producción es preguntas reales con errores tipográficos, idiomas mezclados, etc. Eval pasa al 95%, producción rinde al 70%. Solución: enriquecer continuamente el golden con muestras reales.

Drift sin pipeline de respuesta

Detectas drift en el dashboard de Observe; nadie tiene un workflow definido sobre qué hacer. Solución: cada alerta de drift debe tener un runbook claro: investiga, clasifica, actúa (retrain, ajustar prompt, ampliar retrieval).

Schema break cascada

Cambias el schema en la fuente OLTP; Debezium lo refleja; Flink job se rompe; topic embedded deja de actualizarse; vector store envejece; RAG responde sobre datos viejos. Tres etapas afectadas por un cambio en Data. Solución: schema evolution backward-compatible obligatoria, contracts entre productores y consumidores.

Sin observabilidad del propio pipeline

El pipeline LLMOps es un sistema complejo. Si no tiene observabilidad propia (cuánto tarda el entrenamiento, cuántos jobs fallan, cuántas re-embedding pasan), debugar fallos es un proceso de spelunking. Solución: OTel sobre el pipeline mismo, no solo sobre las llamadas LLM.

Vendor lock-in invisible

Pipelines escritos contra LangChain, prompts pegados en LangSmith, embeddings en Pinecone, modelo en OpenAI. Migrar es un proyecto de meses. Solución: abstracciones LiteLLM, OpenLLMetry, vendor-neutral desde el principio.

Lo que viene en los siguientes posts

Post 4 — PostgreSQL + Qdrant en la etapa de ingestión — primer post que aplica el patrón “estás aquí” sobre la etapa Data. Patrones de sincronización (outbox + CDC), arquitectura de microservicios, manifests de despliegue.
Próximos posts — pendientes de decidir: el cluster como plataforma multi-tenant, Constitutional AI / alignment runtime, fine-tuning continuo en profundidad, edge LLMs.
En cualquier post posterior de esta o futuras series, el mini-mapa “estás aquí” te dirá en qué etapa del ciclo encaja el tema. Si lees un post sobre quantization, sabrás que estás en Deploy. Si lees uno sobre evaluator ensembles, sabrás que estás en Eval. Si lees uno sobre RAG sobre Iceberg, sabrás que estás en Data.

Referencias

Foundations:

Por etapa (entradas de la serie del blog):

Data: RAG sobre Kafka — arquitectura técnica.
Tune: cubierto parcialmente en Panorama 2026; profundización en post 4 si se elige fine-tuning continuo.
Eval: Evals: la capa después del tracing.
Deploy: vLLM en Kubernetes y Operators LLM K8s.
Observe: serie eBPF entera y serie post-tracing entera.
Retrain: cubierto en este post; profundización pendiente.

Componentes transversales:

Prompt versioning: en deep dive de Langfuse dentro del post de AgentSight.
MCP: MCP observability profunda.
Drift detection: eBPF + drift detection.
Inferencia local: PagedAttention deep dive, KV cache.

Frameworks y herramientas referenciadas:

MLflow, W&B, Kubeflow, ZenML, BentoML, Metaflow.
HuggingFace PEFT, TRL, Axolotl, Unsloth.
DVC + lakeFS.
Langfuse, Evidently AI, Phoenix.
vLLM Production Stack, KServe, OME, NVIDIA Dynamo, llm-d.

RAG sobre Kafka: arquitectura técnica de referencia para datalakes en streaming, con embeddings frescos y vector stores siempre al día

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

TL;DR

La pieza que más bloquea proyectos GenAI empresariales en 2026 no es el modelo, ni siquiera los guardrails: es la ingestión de datos para RAG. Las empresas tienen información valiosa en bases de datos OLTP, en logs operacionales, en sistemas SaaS, y todo eso está silenciosamente cambiando cada segundo. Los RAG batch que se reindexan cada noche llegan tarde —la respuesta del modelo está respaldada en un snapshot de hace 18 horas— y dan paso a alucinaciones operacionales aunque el retriever sea perfecto. La respuesta dominante en producción en 2026 es montar la pieza RAG sobre Kafka como source-of-truth: log inmutable, throughput masivo, schema evolution gestionada, y un ecosistema de stream processing maduro (Flink, Kafka Streams, RisingWave) que permite transformar y embedder eventos a medida que ocurren, llevándolos en milisegundos a vector stores (Milvus, Qdrant, Weaviate, pgvector). El patrón canónico: origen → CDC con Debezium → topics Kafka → Flink SQL con embedding UDF → sink connector a vector store → serving con vLLM o equivalente. Las novedades 2026 que cambian el juego: Confluent Tableflow convierte topics Kafka en tablas Iceberg/Delta automáticamente (lectura desde Snowflake/Databricks/Trino sin ETL, 30-50% menos TCO); Flink SQL nativo trae openai_embedding() y vector search integrado con Cosmos DB y Amazon S3 Vectors; el MCP server oficial de Confluent permite a agentes IA consultar Kafka/Flink/Tableflow en lenguaje natural. Este post desarrolla la arquitectura end-to-end con manifests, código Flink SQL y números concretos.

Este es el segundo post de la serie MLOps específico para LLMs. El primero (Panorama 2026) estableció el marco. Aquí bajamos a la pieza más operacional del stack: cómo se conecta un sistema empresarial real a un agente LLM manteniendo el RAG fresco sin caer en complejidad explosiva.

La analogía: Kafka como el “single source of truth”

Quien lleva tiempo en sistemas distribuidos ha visto el patrón una y otra vez: un log inmutable, append-only, replicado, ordenado en el tiempo se ha vuelto la primitiva canónica para reconstruir sistemas complejos. Los DBAs lo conocen como write-ahead log (PostgreSQL WAL, MySQL binlog). Los desarrolladores de sistemas de eventos lo conocen como event sourcing. Los arquitectos de datos lo conocen como Kappa architecture. Kafka es la implementación masiva, distribuida y madura de esa primitiva: un log que vive en disco, particionado para escalar, replicado para durabilidad, retenido por tiempo o tamaño, legible desde cualquier punto histórico.

Cuando se piensa en RAG, esto es exactamente lo que se necesita. Un sistema RAG bien diseñado tiene dos preguntas críticas: ¿cómo se mantiene fresco el índice? y ¿cómo se reconstruye el índice cuando algo se rompe? Las dos las contesta Kafka de manera natural: fresco porque cada cambio en el origen se publica como evento al log y el pipeline lo procesa en milisegundos; reconstruible porque el log entero está ahí: borras el vector store, dispones del topic Kafka desde el offset 0 y vuelves a construir el índice tal como estaba.

Hay además una segunda capa de analogía. Kafka, para una arquitectura GenAI moderna, juega el papel del WAL del sistema entero. Igual que el WAL de Postgres es el evangelio del estado de la base de datos —si pierdes la DB pero conservas el WAL, puedes reconstruirla—, el log de Kafka es el evangelio del estado del conjunto del negocio: pedidos, usuarios, transacciones, documentos. Conectar tu agente IA a Kafka es conectarlo al pulso real del sistema, no a snapshots obsoletos.

El problema del RAG estático

Antes de presentar la arquitectura, vale la pena fijar qué problema concreto estamos resolviendo. El antipattern que tropieza a la mayoría de proyectos GenAI:

Equipo construye RAG sobre un dataset estático: vuelca documentos de Confluence, PDFs de productos, snapshots de base de datos.
Lo embedea con un cron nocturno que regenera el índice cada 24 horas.
Lanza el producto.
Día 2: usuario pregunta sobre un cambio que ocurrió hace dos horas. El RAG no lo tiene; el modelo responde sobre la versión vieja.
Equipo añade lógica frágil: “si la query menciona una fecha reciente, escalar a un agente humano”.
Día 30: el dataset se ha movido tanto que media RAG está desactualizado. El equipo decide refactor y migrar a streaming.

Es la historia repetida de tantos proyectos que el ecosistema ha aprendido la lección: streaming desde el día 1, aunque el volumen sea bajo. La complejidad operacional de un pipeline streaming bien diseñado es constante; la complejidad de migrar de batch a streaming en proyecto vivo es enorme.

Del Lambda al Kappa al Streaming RAG

Tres arquitecturas en orden histórico:

Lambda (clásica de big data 2014): dos pipelines paralelos, uno batch para precisión y uno streaming para freshness. La consulta combina ambos. Funciona pero exige mantener dos pipelines.

Kappa (Jay Kreps 2014, mainstream desde 2020): solo un pipeline streaming. El batch es un caso particular del streaming (reprocesar desde el principio). Simplifica mucho.

Streaming RAG (emergente 2025-2026): variante específica de Kappa donde el output del pipeline son embeddings indexados en un vector store que el LLM consulta en runtime. El log Kafka es la fuente de verdad, el vector store es un proyección consultable.

La conversión mental: piensa en el vector store como la vista materializada del log Kafka. Si la vista se corrompe, la reconstruyes desde el log. Si quieres una vista nueva (otro embedding model, otro chunking strategy), creas otro consumer del log y construyes una segunda vista en paralelo.

La arquitectura de referencia

Vamos al diagrama. Voy a presentar la arquitectura canónica que se ha estabilizado en 2026, mostrando dónde encaja cada componente:

[OLTP DB (Postgres)] [Otros origenes]
│ │
│ WAL via logical decoding │
▼ ▼
┌──────────────────────────────────────────────────────────┐
│ Debezium / Kafka Connect (Sources) │
└──────────────────────────────────────────────────────────┘
│
▼ produce eventos
┌──────────────────────────────────────────────────────────┐
│ Kafka cluster │
│ ┌───────────────────────────────────────────────────┐ │
│ │ topic: orders.raw (3 particiones, RF=3) │ │
│ │ topic: users.raw (3 particiones, RF=3) │ │
│ │ topic: documents.raw (6 particiones, RF=3) │ │
│ └───────────────────────────────────────────────────┘ │
│ + Schema Registry (Avro/Protobuf) │
└──────────────────────────────────────────────────────────┘
│
▼ consume y transforma
┌──────────────────────────────────────────────────────────┐
│ Flink SQL streaming jobs │
│ - chunking text │
│ - llamadas a embedding model (UDF) │
│ - enriquecimiento con metadata │
│ - sink a topic curado: documents.embedded │
└──────────────────────────────────────────────────────────┘
│
┌───────────┼────────────────────┐
▼ ▼ ▼
[Vector store] [Tableflow] [Iceberg/Delta]
Milvus/Qdrant auto-convert para analytics
/pgvector/ topics →
Weaviate tables
│
▼ consultado en runtime
┌──────────────────────────────────────────────────────────┐
│ LLM serving (vLLM / SGLang) + Retriever │
│ - recibe query del agente │
│ - busca top-K en vector store │
│ - construye prompt + contexto │
│ - genera respuesta con citas │
└──────────────────────────────────────────────────────────┘

Las cinco capas que ves —fuente, ingestión (CDC), transporte (Kafka), procesamiento (Flink), almacenamiento (vector + tablas)— son las que estructuran cualquier RAG sobre datalake serio en 2026. Vamos a cada una.

Capa 1 — Fuentes: tu OLTP como punto de partida

La fuente típica es una base de datos OLTP (Postgres, MySQL, SQL Server). Es donde vive el estado vivo del negocio. La técnica para extraer cambios en tiempo real es Change Data Capture (CDC): leer el log de transacciones de la base de datos (PostgreSQL WAL, MySQL binlog) y convertir cada commit en un evento Kafka.

El estándar OSS es Debezium. Soporta Postgres, MySQL, SQL Server, MongoDB, Oracle, Cassandra y otros. Despliegue típico como cluster Kafka Connect con conectores Debezium.

Ejemplo de configuración Debezium para PostgreSQL:

{
 "name": "postgres-orders-connector",
 "config": {
 "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
 "tasks.max": "1",
 "database.hostname": "postgres.prod.internal",
 "database.port": "5432",
 "database.user": "debezium",
 "database.password": "${secret:postgres-creds}",
 "database.dbname": "ecommerce",
 "database.server.name": "ecommerce-prod",
 "table.include.list": "public.orders,public.users,public.products",
 "publication.autocreate.mode": "filtered",
 "slot.name": "debezium_slot",
 "plugin.name": "pgoutput",
 "topic.prefix": "ecommerce",
 "key.converter": "io.confluent.connect.avro.AvroConverter",
 "value.converter": "io.confluent.connect.avro.AvroConverter",
 "key.converter.schema.registry.url": "http://schema-registry:8081",
 "value.converter.schema.registry.url": "http://schema-registry:8081"
 }
}

Esto produce, por cada commit en la base de datos, un evento Avro al topic correspondiente (ecommerce.public.orders, ecommerce.public.users, etc.) con el cambio: tipo (INSERT/UPDATE/DELETE), valores antes y después, timestamp del commit, posición en el WAL.

Alternativa más simple para 2026: RisingWave puede leerse el WAL de Postgres directamente, sin Debezium ni Kafka Connect intermedio. Cuando el caso es solo CDC sin más fuentes, es operacionalmente más simple. Para arquitecturas con múltiples fuentes (CDC + APIs + scrapers + logs), Debezium sigue siendo la pieza estándar.

Capa 2 — Kafka como transporte y persistencia

El cluster Kafka es donde aterrizan todos los eventos. Decisiones operativas clave:

Topics: raw vs curated

Convención que se ha establecido en 2026:

*.raw: el evento crudo tal como llegó. CDC sin transformar, log de aplicación sin parsear.
*.cleaned: tras dedup, validación de schema, normalización de tipos.
*.enriched: tras añadir metadatos (geolocalización, identificadores cruzados, etc.).
*.embedded: el evento con su vector embedding ya calculado.

Multi-stage topics permite debug por capa y reprocesamiento parcial: si cambias el embedding model, descartar *.embedded y reconstruir desde *.enriched cuesta horas; reconstruir desde *.raw cuesta días.

Schema Registry

Sin schema registry, los topics se rompen silenciosamente cuando alguien cambia el schema en origen. Confluent Schema Registry o el OSS Apicurio son las opciones dominantes.

Formatos comunes:

Avro: schema versionado, evolution rules estrictas. El default histórico.
Protobuf: compatible con stacks gRPC, buena performance.
JSON Schema: textual, debuggable a ojo, menos eficiente.

Para RAG sobre Kafka recomendamos Avro por defecto. Schema evolution es importante porque las tablas origen cambian con el tiempo, y un esquema sin versión rompe consumidores aguas abajo.

Particiones, replicación y retención

Decisiones operativas para topics de RAG:

Particiones: típicamente 3-12. Más particiones = más paralelismo en consumer Flink, pero más overhead. La regla del pulgar: particiones = pico esperado de eventos/s ÷ 1000.
Replication factor: 3 mínimo en producción. La replicación protege contra fallo de broker; con RAG el coste de perder un topic puede ser semanas de re-embedding.
Retención: para topics que alimentan RAG, retención larga o compactada por key. Si el documento doc-42 cambia 100 veces, compactación solo guarda el último estado por key, dejando un log más pequeño y reconstruible. Para datos que no se actualizan (logs históricos), retención por tiempo (90 días, 1 año).

Replicación cross-cluster

Para deployments multi-región o multi-cloud, MirrorMaker 2 o Cluster Linking (Confluent) replican topics entre clusters Kafka. El RAG puede consultar el cluster local sin tener que cruzar región.

Capa 3 — Flink como procesador streaming

Apache Flink es la pieza dominante de stream processing en 2026. Apache 2.0, distribución mature, ecosistema amplio. La alternativa principal es Kafka Streams (más simple, Java-only); RisingWave es la opción emergente para casos SQL puros.

Lo que Flink añade a Kafka:

Stateful streaming: agregaciones temporales, joins entre streams, sesiones.
Exactly-once semantics: con checkpoint coordination.
Watermarks: handling correcto de eventos out-of-order.
UDFs en Python/Java: incluyendo llamadas a modelos LLM.

Flink SQL: la pieza más operacional

Flink SQL es la pieza más usable de Flink para data engineers que no son streaming experts. Veamos un ejemplo realista de pipeline RAG:

-- 1. Definir la fuente: topic Kafka con eventos CDC de documentos
CREATE TABLE documents_raw (
 doc_id STRING,
 title STRING,
 body STRING,
 category STRING,
 updated_at TIMESTAMP_LTZ(3),
 PRIMARY KEY (doc_id) NOT ENFORCED
) WITH (
 'connector' = 'upsert-kafka',
 'topic' = 'ecommerce.public.documents',
 'properties.bootstrap.servers' = 'kafka:9092',
 'key.format' = 'avro-confluent',
 'value.format' = 'avro-confluent',
 'value.fields-include' = 'EXCEPT_KEY'
);

-- 2. Definir el sink: vector store via Kafka topic intermedio
CREATE TABLE documents_embedded (
 doc_id STRING,
 chunk_id INT,
 title STRING,
 chunk_text STRING,
 category STRING,
 embedding ARRAY<FLOAT>,
 embedded_at TIMESTAMP_LTZ(3),
 PRIMARY KEY (doc_id, chunk_id) NOT ENFORCED
) WITH (
 'connector' = 'upsert-kafka',
 'topic' = 'rag.documents.embedded',
 'properties.bootstrap.servers' = 'kafka:9092',
 'key.format' = 'json',
 'value.format' = 'json'
);

-- 3. UDF para chunking (definida en Python o Java)
-- CREATE TEMPORARY FUNCTION chunk_text AS 'com.example.ChunkingUDF';

-- 4. Pipeline: chunkear, embedder, escribir al sink
INSERT INTO documents_embedded
SELECT
 doc_id,
 chunk_idx AS chunk_id,
 title,
 chunk AS chunk_text,
 category,
 OPENAI_EMBEDDING(chunk,
 'text-embedding-3-small') AS embedding,
 CURRENT_TIMESTAMP AS embedded_at
FROM documents_raw
CROSS JOIN UNNEST(chunk_text(body, 512, 64))
 WITH ORDINALITY AS t(chunk, chunk_idx);

Lo que pasa aquí, línea a línea:

La tabla documents_raw lee el topic CDC en modo upsert-kafka (cada nuevo evento por la misma key reemplaza el anterior). Esto refleja correctamente la semántica “esta es la última versión del doc 42”.
La tabla documents_embedded será el topic intermedio donde Flink escribe los chunks embedded.
La UDF chunk_text (definida en Python o Java) divide cada doc en chunks de 512 tokens con overlap de 64.
La consulta INSERT INTO se ejecuta continuamente: cada evento nuevo en documents_raw se chunkea, cada chunk se embedea con OPENAI_EMBEDDING (función built-in de Flink SQL en Confluent Cloud 2026), y se escribe al topic embedded.

OPENAI_EMBEDDING puede sustituirse por una función custom que llame a un modelo self-hosted (vLLM con un encoder), a SentenceTransformers, o a un servicio managed. La sintaxis es la misma; cambias el provider.

Watermarks y late events

Para casos donde un evento puede llegar tarde (eg el WAL de Postgres se retrasa porque hubo un network blip), Flink permite definir watermarks:

CREATE TABLE documents_raw (
 doc_id STRING,
 title STRING,
 body STRING,
 updated_at TIMESTAMP_LTZ(3),
 WATERMARK FOR updated_at AS updated_at - INTERVAL '5' MINUTE
) WITH (...)

Esto le dice a Flink “asume que ningún evento llega más de 5 minutos tarde respecto al timestamp del evento”. Para joins y agregaciones temporales, Flink usa el watermark para decidir cuándo “cerrar” una ventana.

Capa 4 — Sinks a vector stores

El último paso es indexar los embeddings en un vector store. Tres patrones en 2026:

Patrón A — Kafka Connect sink directo

Cada vector store tiene su connector oficial:

Milvus: sink connector oficial de Zilliz. Soporta named/unnamed dense/sparse vectors.
Qdrant: sink connector oficial. Soporta dense, sparse, multi-vector.
pgvector: no tiene connector dedicado, pero se usa el JDBC Sink Connector con SQL custom.
Weaviate: connector community.
LanceDB: connector community.

Ejemplo de configuración Milvus sink:

{
 "name": "milvus-rag-embeddings-sink",
 "config": {
 "connector.class": "com.milvus.io.kafka.MilvusSinkConnector",
 "tasks.max": "3",
 "topics": "rag.documents.embedded",
 "milvus.host": "milvus.prod.internal",
 "milvus.port": "19530",
 "milvus.collection.name": "documents",
 "milvus.collection.dim": "1536",
 "milvus.collection.partition": "default",
 "key.converter": "org.apache.kafka.connect.storage.StringConverter",
 "value.converter": "org.apache.kafka.connect.json.JsonConverter",
 "value.converter.schemas.enable": false
 }
}

Tres tasks en paralelo (tasks.max: 3) consumen el topic embedded y escriben a la colección Milvus. La latencia desde “evento en Kafka” hasta “vector indexable en Milvus” es típicamente <5 segundos.

Patrón B — pgvector con CDC pipe directo

Para equipos que ya viven en PostgreSQL, pgvector es la opción de menor fricción. Patrón: el mismo cluster Postgres origen tiene una segunda DB para embeddings con extensión pgvector activada; el pipeline Flink escribe directamente vía JDBC.

-- En el cluster Postgres con pgvector activado
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_embeddings (
 doc_id TEXT,
 chunk_id INT,
 chunk_text TEXT,
 category TEXT,
 embedding vector(1536),
 embedded_at TIMESTAMP,
 PRIMARY KEY (doc_id, chunk_id)
);

CREATE INDEX ON document_embeddings
 USING hnsw (embedding vector_cosine_ops)
 WITH (m = 16, ef_construction = 64);

Ventajas: tu mismo DBA opera todo, transactionality cross-tables, joins con metadatos relacionales triviales. Limitación: a >10M vectores, el rendimiento de pgvector empieza a ceder respecto a sistemas dedicados.

Patrón C — Confluent Tableflow → Iceberg + vector search Flink SQL

Esta es la novedad 2026 que cambia la mecánica. Confluent Tableflow materializa automáticamente topics Kafka como tablas Apache Iceberg o Delta Lake. Características:

Sin pipeline ETL: no escribes Flink/Spark jobs para mover Kafka a tabla. Lo hace Tableflow.
Schema evolution automática: cambios en el schema del topic se reflejan en la tabla.
Catálogo unificado: la tabla aparece en Glue, Unity Catalog, Snowflake, Databricks. Cualquier motor analítico la consulta sin copiar datos.
CDC nativo: maneja inserts, updates, deletes correctamente.
30-50% menos TCO según las cifras que Confluent publica vs pipelines tradicionales.

Y desde 2026, Tableflow + Flink SQL ofrecen vector search nativo integrado con Cosmos DB y Amazon S3 Vectors. La consulta RAG se puede hacer directamente en Flink SQL:

SELECT doc_id, chunk_text, category
FROM documents_embedded
WHERE VECTOR_SEARCH(embedding,
 OPENAI_EMBEDDING('query del usuario', 'text-embedding-3-small'),
 top_k => 10) > 0.7
ORDER BY VECTOR_SEARCH_SCORE DESC;

Esto unifica capas que antes eran separadas (vector store + analytics). Para muchos casos, elimina la necesidad de mantener un vector store dedicado.

El MCP server oficial de Confluent

Una pieza añadida en 2026 que merece mención: Confluent ha publicado un MCP server oficial que expone Kafka, Flink y Tableflow como tools accesibles a agentes IA vía MCP. Cualquier MCP client (Claude Desktop, Cursor, agentes propios) puede:

Listar topics, leer mensajes recientes, publicar a topics.
Ejecutar queries Flink SQL en lenguaje natural (“dame las órdenes de las últimas 24 horas con valor > 1000€”).
Consultar tablas Tableflow Iceberg.
Gestionar conectores Kafka Connect.

Esto cierra el círculo: tu agente IA, además de leer datos del datalake vía RAG (con vector search), puede escribir datos al log (vía MCP) y disparar transformaciones (vía Flink SQL en natural language). Es el punto de fusión más profundo entre LLM ops y data ops del año.

Conexión con la serie anterior: este MCP server emite traces con las OpenTelemetry GenAI MCP semantic conventions que cubrimos en el post de MCP observability. Los spans aparecen en Langfuse, Phoenix o tu OTel backend con la cardinalidad correcta. Cero código de instrumentación.

Vector stores: comparativa 2026

Las cinco opciones dominantes:

Vector store	Licencia	Operación	Cuándo encaja
pgvector	Postgres ext, OSS	Tu DBA	<10M vectores, equipo Postgres-heavy
Qdrant	Apache 2.0	Self-host o managed	Mid-scale, foco performance
Milvus	Apache 2.0	Self-host o Zilliz Cloud	Large-scale, foco escalabilidad
Weaviate	BSD-3	Self-host o managed	Hybrid search nativo, semantic rich
LanceDB	Apache 2.0	Embedded o serverless	Small-medium, simplicidad

La selección depende de:

Escala: pgvector se queda corto >10M vectores. Milvus y Qdrant escalan a billones.
Hybrid search: Weaviate trae lexical + vector nativo. Otros lo soportan pero menos integrado.
Operación: pgvector si ya tienes Postgres operado. Qdrant si quieres simplicidad. Milvus si necesitas máxima escala.
Cloud managed: Zilliz Cloud para Milvus, Qdrant Cloud para Qdrant, Pinecone si quieres SaaS puro (sin OSS detrás).

Freshness vs accuracy: el trade-off operativo

Una decisión crítica que cualquier sistema RAG sobre Kafka debe responder: ¿cuándo se considera que un nuevo documento está “live” en el índice?

Tres opciones:

Streaming síncrono: el evento llega a Kafka, Flink lo embedea, el sink lo escribe al vector store, y solo entonces se considera live. Latencia típica: 1-5 segundos. La mejor freshness. Pero si el embedding model falla o el vector store es lento, los eventos se acumulan en el topic.

Streaming asíncrono con baseline: el evento se considera live inmediatamente; un proceso de fondo lo embedea cuando puede. Mientras tanto, queries que pidan ese documento no lo encuentran. Latencia típica: 5-60 segundos. Aceptable para la mayoría de aplicaciones.

Batch micro: se procesa en mini-batches cada 1-5 minutos. Menos eficiente que streaming continuo pero más estable bajo carga variable. Latencia: 1-5 minutos.

La decisión depende del SLA del producto. Para chatbots de soporte al cliente, 5-60 segundos es aceptable. Para sistemas que reaccionan a eventos críticos (precios financieros, alarmas), streaming síncrono es necesario.

Schema evolution y reembedding

Cuando el embedding model cambia (cambias de text-embedding-3-small a text-embedding-3-large, o pasas de OpenAI a Cohere), los vectores existentes en el índice son incompatibles: dimensiones distintas, espacios semánticos distintos. La distancia entre un vector viejo y uno nuevo no significa nada.

Patrón estándar para handle de esto: dual-index durante la migración.

T0: índice activo es V1 (embedding model A).
T1: empieza pipeline paralelo que escribe a un índice V2 (embedding model B), consumiendo el topic desde offset 0 (reprocesar todo el log).
T2: V2 ha caught-up al presente.
T3: cambias el retriever para que use V2.
T4: una semana después, descartas V1.

El log de Kafka hace este patrón factible porque es inmutable y reproducible. Sin el log, este patrón se vuelve un proyecto de migración de datos de semanas.

Trampas operativas

Topics sin retención adecuada

Configurar topics con retención de 7 días pensando “ya tengo el vector store” lleva a perder la capacidad de reconstruir si el vector store falla. Retención larga (90+ días) o compactada por key para topics que alimentan RAG.

CDC pesado en cargas pico

Debezium leyendo el WAL en horas pico puede impactar performance de la base de datos origen. Replica de lectura dedicada para Debezium, no la primaria de producción. O usar logical replication específica solo para las tablas necesarias.

Embedding cost run-away

OPENAI_EMBEDDING en cada evento de un topic con millones de mensajes/día son miles de USD/mes. Estrategias: filtrar antes de embedder (solo embedder lo que aporta valor); deduplicar por hash de contenido; usar embedding models open-source self-hosted (BGE, E5, GTE) cuando el coste cloud sea prohibitivo.

Reembedding lento por throughput limitado

Recalcular 10M embeddings con OpenAI API a 3000 req/min tarda 55 horas. Si esperas a un incidente para reembeder, son dos días sin servicio. Embedding throughput es un capacity planning explícito; reservar capacity o tener un job offline pre-arrancable.

Schema breaks aguas abajo

Un cambio en el schema del topic raw rompe Flink jobs aguas abajo. Schema Registry con compatibility BACKWARD obligatoria; nunca ALLOW_ALL. Y test schema evolution en CI.

Vector store sin backup

Tu vector store tiene 50M vectores. Es la única copia (los topics expiraron). Un fallo lo borra. Vector stores deben ser backed up igual que cualquier persistencia primaria. Para Milvus/Qdrant: snapshots periódicos. Para pgvector: el propio pg_dump.

Multi-region sin replicación cross-cluster

Tu RAG sirve a usuarios en US y EU. El vector store está en US-east. Latencia desde EU = 100ms+ por query. MirrorMaker o Cluster Linking para replicar topics y vector stores en ambas regiones.

Lo que no hemos cubierto

Hybrid search en producción: combinar BM25/lexical + vector + reranker. Tema de su propio post.
Multimodal RAG: indexar imágenes, audio, vídeo además de texto. Embeddings multimodales (CLIP, Imagebind), arquitectura específica.
GraphRAG: usar conocimiento estructurado (knowledge graphs) además de vector retrieval. Microsoft GraphRAG, LlamaIndex KnowledgeGraphQueryEngine.
RAG con ACL multi-tenant: filtrar por permisos en runtime. Patrón con metadatos en el vector store + filtros server-side.
Query rewriting con LLM: usar un primer LLM para expandir la query antes del retrieval (HyDE, multi-query, step-back prompting).

Referencias

Kafka y stream processing:

Apache Kafka y Debezium.
Confluent Schema Registry y Apicurio Registry.
Apache Flink y Flink SQL docs.
RisingWave — alternativa SQL streaming con embedding built-in.

Vector store connectors:

Tableflow y arquitectura 2026:

RAG streaming:

Cross-references:

Post anterior: MLOps específico para LLMs en 2026: el panorama.
Serie post-tracing: Evals, Guardrails, MCP observability, eBPF + drift.
Serie eBPF: eBPF de cero a Cilium, Tetragon, Hubble, AgentSight.

MLOps específico para LLMs en 2026: el panorama de tres modalidades, seis etapas y diez herramientas que las hacen funcionar

Thu, 21 May 2026 05:30:00 +0200

TL;DR

Esta es la cuarta serie del blog y se llama MLOps específico para LLMs. Toma el oficio operativo de MLOps tradicional —pipelines reproducibles, model registries, dataset versioning, eval gates, despliegues controlados— y lo redibuja para un mundo donde el modelo es probabilístico, las salidas son subjetivas, las dependencias incluyen vendors externos que actualizan pesos sin avisar, y la “aplicación” no es un modelo sino una orquestación de modelos, embeddings, retrievers, guardrails y routers. Gartner predice que más del 50% de los despliegues GenAI empresariales fracasarán antes de que acabe 2026, y la causa principal no es el modelo: es que se aplicaron suposiciones de software determinístico a sistemas probabilísticos. Este post abre la serie con el marco: las siete diferencias estructurales entre LLMOps y MLOps clásico; el pipeline de seis etapas (data → tune → eval → deploy → observe → retrain); las tres modalidades de preparar un modelo (fine-tuning continuo, RAG sobre datalakes, agent training) con su matriz de decisión —el 60% de despliegues 2025-2026 usa hybrid porque cada modalidad resuelve un problema distinto: “fine-tune para behavior, RAG para conocimiento volátil”—; y el panorama de herramientas 2026 que ya forma capas razonablemente estables: MLflow 3.10 (marzo 2026) como registry GenAI-aware, W&B Weave y ZenML para tracing y pipelines, Kubeflow + KServe vLLM 0.8.1+ para serving, BentoML para flexibilidad, DVC + lakeFS (unidos desde noviembre 2025) para data, Langfuse para prompts y observabilidad. Los tres posts siguientes bajarán al detalle de las piezas más críticas.

Esta es la apertura de la serie 4: MLOps para LLMs. Continúa la tradición de las series previas: inferencia LLM (la primera), eBPF (la segunda) y post-tracing (la tercera). Aquí entramos en la disciplina que ata todas las piezas: cómo se opera un sistema LLM en producción durante meses, no solo se despliega una vez.

La analogía: el oficio del SRE redibujado

Quien lleva años trabajando como SRE o como ingeniero de plataforma reconoce los pilares clásicos: reproducibilidad (mismo código + misma data + misma config = mismo resultado), observabilidad (lo que pasa se puede medir), rollback seguro (si algo va mal, vuelvo atrás en minutos), gradual rollout (lo nuevo entra al 1% antes que al 100%). Estos pilares no son negociables. La pregunta es si se sostienen cuando el componente central es un LLM.

La respuesta es: mismos pilares, mecánica radicalmente distinta. Reproducibilidad: ya no basta con versionar código y datos; hay que versionar prompts, configuraciones de retrieval, snapshots del modelo del vendor (que cambian sin avisar). Observabilidad: ya no basta con métricas de error y latencia; hay que medir calidad subjetiva vía LLM-as-judge y drift de embeddings. Rollback: ya no basta con bajar la versión del binario; hay que mantener el modelo viejo cacheado porque cargar uno nuevo tarda minutos. Gradual rollout: ya no basta con un % de tráfico; hay que decidir qué % de qué tipo de queries por segmento.

Es el mismo oficio, ejercido con herramientas y reflejos parcialmente nuevos. MLOps específico para LLMs —o “LLMOps”, como el campo se ha autobautizado— es la disciplina que codifica esos reflejos.

Las siete diferencias estructurales entre LLMOps y MLOps tradicional

Antes de bajar al pipeline, fijemos las diferencias que hacen este territorio nuevo, no una mera continuación. Cada una tiene consecuencias prácticas concretas.

1. Salidas no-determinísticas

MLOps tradicional: el modelo recibe input estructurado, devuelve una predicción acotada y reproducible. Mismo input → mismo output. Tests unitarios funcionan.

LLMOps: mismo input → output distinto cada vez (por sampling, por temperature, por orden de tools invocadas, por el contexto retrieval que cambió). La idea de “test unitario” se rompe.

Consecuencia operativa: tests sobre propiedades (¿se mantuvo el tono?, ¿menciona la fuente?, ¿respeta el JSON schema?), no sobre igualdad. Evals estadísticos sobre distribución, no sobre muestras.

2. Métricas behavior, no statistical accuracy

MLOps tradicional: F1, accuracy, AUC, RMSE. Métricas con un número claro.

LLMOps: rubric scores subjetivos (G-Eval, faithfulness, helpfulness, toxicity), judge LLMs, human feedback. El “número” depende de quién juzga.

Consecuencia operativa: las plataformas tienen que tratar evals como artifacts versionados —no solo “el modelo v3 sacó 0.87”, sino “el modelo v3 evaluado con el judge claude-3-5-sonnet-20251022 sobre el dataset gold-rag-v7 con el prompt judge-v2 sacó 0.87”—. Versionar el judge es tan importante como versionar el modelo evaluado.

3. El modelo es dependencia externa, no asset interno

MLOps tradicional: el modelo lo entrenas tú, vive en tu registry, no cambia hasta que lo cambies.

LLMOps: el modelo base es de Anthropic, OpenAI, Google, Meta. Te lo cambian sin avisar. La versión claude-3-5-sonnet que respondía bien ayer responde algo distinto hoy.

Consecuencia operativa: drift detection se vuelve mucho más crítico (post anterior). Pinning a snapshots específicos (claude-3-5-sonnet-20251022) cuando el vendor lo permite. Para apps de alto compromiso, self-host del modelo base para garantizar reproducibilidad.

4. La aplicación es una orquestación, no un modelo

MLOps tradicional: una app llama un modelo y consume su output.

LLMOps 2026: una app conecta foundation model + adapters LoRA + retrievers + vector stores + guardrails + routers + tool servers (MCP) + evaluators, todos componiendo el comportamiento final. Cualquier componente puede degradar el resultado.

Consecuencia operativa: el debugging cross-componente requiere tracing distribuido con OTel (cubierto en posts previos). El registry no solo guarda “el modelo” sino la composición: qué versión del prompt + qué adapter + qué vector store + qué retriever config.

5. Coste por inferencia, no por training

MLOps tradicional: el coste alto es entrenar; servir es barato. Optimizas training.

LLMOps: el coste alto es servir (cada token cuesta, cada llamada al vendor se paga, las GPUs que sirven están encendidas 24/7). Optimizas inferencia.

Consecuencia operativa: cost accountability por tenant, por agente, por tool. Métricas como gen_ai.usage.input_tokens agregadas a nivel cliente y producto. Decisiones de modelo según coste por query, no solo según calidad.

6. Infra GPU-pesada con primitivas específicas

MLOps tradicional: CPU + algo de GPU para entrenamiento. Kubernetes estándar.

LLMOps: GPUs Hopper/Blackwell SXM, NVLink/NVSwitch, tensor parallel, paged attention, KV cache. Infra que solo encaja en Kubernetes con primitivas como LeaderWorkerSet, GPU Operator, KEDA con métricas LLM (cubierto en vLLM en Kubernetes).

Consecuencia operativa: la pila de orquestación incluye operadores especializados (OME, vLLM Production Stack, NVIDIA Dynamo, llm-d, ver Operators LLM K8s) que el MLOps tradicional no contempla.

7. RLHF y feedback humano como ciudadano de primera

MLOps tradicional: el feedback humano es etiquetar datos antes del training.

LLMOps: el feedback humano vive dentro del modelo en producción, ya sea por RLHF de los foundation models (Anthropic, OpenAI), por RLAIF, por DPO, o por feedback explícito de usuarios que se reincorpora al fine-tuning.

Consecuencia operativa: pipelines bidireccionales producción → training. Datasets crecen con incidentes reales. Las decisiones de modelo se toman con feedback continuo, no en un proyecto de training cada N meses.

Por qué Gartner predice 50%+ de fracasos

Gartner publicó que más del 50% de los despliegues GenAI empresariales fracasarán antes de 2026. Las causas no son técnicas sobre el modelo sino sobre el sistema:

Hallucinated outputs por mal grounding: RAG mal diseñado, retrieval pobre, contexto insuficiente.
Arquitecturas de datos no preparadas: las empresas tienen datos en silos, sin schemas estables, sin freshness controlado. Conectar un LLM a estos datos sin pipeline serio produce respuestas erráticas.
Falta de workflows estructurados para sistemas prompt-driven: equipos que tratan los prompts como código en strings hardcodeados, sin versionado, sin tests, sin gates.

La conclusión que el campo extrae: LLMOps no es opcional. Las empresas que despliegan GenAI sin disciplina operacional caen en uno de los tres modos de fracaso. Las que la aplican —MLflow/W&B para tracking, DVC/lakeFS para datos, Langfuse para prompts y evals, KServe o vLLM Production Stack para serving, drift detection en producción— son las que mantienen el sistema funcionando seis meses después del primer release.

El pipeline LLMOps de seis etapas

Vamos al pipeline. Las seis etapas que cualquier sistema LLM serio recorre, en orden:

[1. Data] → [2. Tune] → [3. Eval] → [4. Deploy] → [5. Observe] → [6. Retrain]
│
└─→ vuelve a 1

Cada etapa es un dominio operacional propio con sus herramientas y trampas:

Etapa 1 — Data

Qué pasa: ingestión, limpieza, curación, versionado, indexación del corpus. Es donde más se sufre en proyectos reales porque las empresas tienen datos en silos heterogéneos.

Sub-tareas típicas: extracción desde origen (CDC sobre Kafka, batch desde data lakes, scraping), limpieza (PII removal, dedup, formato), curación (labeling para fine-tuning, golden datasets para eval), versionado (DVC + lakeFS), indexación (embeddings + vector store para RAG).

Trampas: drift de schema en el origen, PII no detectada, dedup pobre que mete redundancia en training, vector store que no se actualiza.

Etapa 2 — Tune

Qué pasa: preparar el modelo para tu caso de uso. Tres modalidades (las profundizamos en breve): fine-tuning, RAG, agent training.

Sub-tareas típicas: selección de modelo base, preparación del adapter (LoRA, QLoRA), training loop con eval continuo, hyperparameter sweep (Optuna, W&B Sweeps), guardado del checkpoint.

Trampas: catastrophic forgetting si el fine-tuning es muy agresivo, overfitting al dataset golden, sin validation set independiente.

Etapa 3 — Eval

Qué pasa: validar que el modelo + adapters + RAG configuration es aceptable antes de promotar. Cubierto en Evals.

Sub-tareas típicas: ejecución de eval framework (DeepEval, Promptfoo, Ragas) contra golden dataset, judge LLM evaluations, human review sobre muestreo, gates con thresholds.

Trampas: golden dataset que envejece, judge no calibrado, evals que pasan en CI pero fallan en producción por shift de distribución.

Etapa 4 — Deploy

Qué pasa: pasar de “el modelo se evaluó bien” a “el modelo sirve tráfico real”. Cubierto en Operators LLM K8s.

Sub-tareas típicas: serving con vLLM/SGLang/TRT-LLM, configuración del runtime, rollout gradual (canary, shadow, blue-green), routing entre modelos (LiteLLM, OpenRouter, LangChain routers).

Trampas: rolling update naive que corta sesiones, autoscaling por CPU% que no responde a métricas LLM (cubierto), modelo nuevo que rinde peor en producción que en eval.

Etapa 5 — Observe

Qué pasa: ver lo que está pasando en tiempo real. Cubierto en la serie post-tracing entera y la serie eBPF.

Sub-tareas típicas: tracing (Langfuse, LangSmith, Phoenix, OpenLLMetry), métricas (TTFT, TPOT, queue depth, cost per query), guardrails activos (NeMo, Llama Guard), drift detection (Evidently, NannyML, WhyLabs).

Trampas: explosión de cardinalidad en métricas, evals batch sin tail-sampling sobre traces reales, drift que se ignora hasta que el incidente lo materializa.

Etapa 6 — Retrain

Qué pasa: cerrar el bucle. El feedback de producción (incidentes, casos peor evaluados, drift detectado) genera nuevos datos para volver a la etapa 1.

Sub-tareas típicas: extracción de logs problemáticos, labeling humano de la muestra, incorporación al dataset golden, re-fine-tuning si aplica, decisión sobre nuevo release.

Trampas: bucle “abierto” donde producción no informa nunca al dataset, feedback humano que se pierde, falta de cadencia clara de retrain.

Las tres modalidades de “preparar el modelo”

La etapa 2 (Tune) es donde más confusión hay. En 2026 conviven tres modalidades, cada una resolviendo un problema distinto:

Fine-tuning

Qué hace: modificar los pesos del modelo (o de un adapter LoRA/QLoRA encima) para que aprenda patrones de comportamiento específicos: tono, estructura de output, decisiones idiomáticas del dominio.

Cuándo: cuando tu fallo principal es inconsistencia de comportamiento entre llamadas. El modelo a veces responde formal, a veces no; a veces estructura el JSON, a veces no; a veces sigue las convenciones de la empresa, a veces inventa. Fine-tuning lo estabiliza.

Cuándo NO: cuando lo que necesitas es conocimiento actualizado. Fine-tuning fija conocimiento en pesos congelados; al día siguiente del fine-tuning, el modelo no sabe nada nuevo.

RAG (Retrieval-Augmented Generation)

Qué hace: dejar el modelo intacto y, en cada llamada, recuperar contexto fresco de un knowledge base (vector store + lexical search típicamente) y pasárselo al modelo para que responda basándose en él.

Cuándo: cuando el conocimiento que necesitas es dinámico o muy grande. Documentación que cambia, catálogo de productos que se actualiza, knowledge base interna que crece.

Cuándo NO: cuando el problema es behavioral (RAG no enseña al modelo a comportarse, solo le da información). O cuando el retrieval es tan ruidoso que el contexto que llega es peor que nada.

Agent training

Qué hace: ir más allá del fine-tuning convencional con técnicas de Reinforcement Learning. RFT (Reinforcement Fine-Tuning de OpenAI), RLHF clásico, RLAIF (con AI feedback), DPO (Direct Preference Optimization) sobre datasets de pares (good, bad).

Cuándo: cuando el modelo necesita aprender trayectorias multistep complejas —cuando elegir cada tool, cómo descomponer una tarea, cuándo pedir confirmación al usuario—. Es lo que está convirtiendo a Claude, Gemini, GPT en agentes capaces de tareas largas.

Cuándo NO: cuando tu caso es chat simple o RAG. Es overkill, caro y complicado para problemas que las modalidades anteriores resuelven.

Matriz de decisión

Problema observado	Modalidad
Respuestas inconsistentes en tono/estructura	Fine-tuning
El modelo inventa cosas (alucina)	RAG
Conocimiento desactualizado (>1 año)	RAG
El modelo elige mal las tools	Agent training (RLAIF/RFT)
Behavior + conocimiento mixto	Hybrid (fine-tune + RAG)
Multi-step trajectory falla	Agent training
Idioma/estilo regional concreto	Fine-tuning

El veredicto 2026: hybrid es el default

Múltiples reports coinciden en que en 2025-2026, alrededor del 60% de proyectos productivos usan hybrid: fine-tuning para behavior + RAG para knowledge. El insight clave:

Fine-tune para comportamiento (brand voice, decision protocol, output structure); usa RAG para conocimiento volátil que necesitas que el modelo cite. No fuerces una sola herramienta a hacer ambos trabajos.

Una observación práctica: las mejoras de calidad más grandes de 2025-2026 vienen de mejor reranking en RAG (cross-encoders), no de mejores embeddings. Los rerankers añaden 15-35% de calidad con poca complejidad.

Sobre coste: combined fine-tuning + RAG suele ser 30-50% más barato que RAG puro con frontier models a volumen alto, porque el modelo finetuneado puede ser más pequeño y barato manteniendo calidad equivalente.

El panorama de herramientas 2026

Vamos a las piezas concretas, agrupadas por función. El campo ha madurado lo suficiente para que cada pieza tenga 2-3 opciones razonables y un par de líderes.

Experiment tracking y model registry

MLflow sigue siendo el estándar de facto, ahora con tracción específica LLM. MLflow 3 se publicó en junio 2025; la versión 3.10.1 (marzo 2026) añadió:

GenAI Overview dashboard con métricas pre-hechas para LLM apps.
Multi-workspace support para equipos grandes.
Cost tracking en traces (gen_ai.usage.* agregados por experimento).
MemAlign: nuevo algoritmo de eval específico.
OpenTelemetry tracing nativo integrado.
Soporte de primera para LangChain, LlamaIndex, AutoGen como frameworks.

MLflow trata prompts y agents como ciudadanos de primera clase junto a los modelos clásicos. Es el cambio mayor respecto a MLflow 2.x.

Weights & Biases (W&B) con su producto Weave específico para LLM ofrece tracing + eval + debug con UI muy pulida. Más comercial, menos self-host friendly, pero excelente UX.

ZenML es la pieza que más limpia integra “MLOps clásico + LLMOps emergente” en un solo framework. Su artifact versioning automático captura prompt templates, retrieval chunks, agent conversation histories sin trabajo extra. Open-source. La opción de unificación más completa que existe.

Dataset versioning

DVC sigue siendo el estándar OSS. Extiende Git a archivos grandes y pipelines. Noticia importante de noviembre 2025: lakeFS adquirió DVC, consolidando los dos proyectos OSS de versionado de datos bajo una organización. La hoja de ruta combinada está orientada a LLM training y RAG datalakes específicamente.

Patrón típico: Git para código + DVC para data/modelos + MLflow o W&B para experiment tracking + registry. Pocas teams usan uno solo; la combinación es lo que cubre el ciclo.

Prompt versioning y observability

Cubierto en profundidad en el post de AgentSight donde profundizamos en Langfuse como referencia OSS. Resumen aquí:

Langfuse: MIT, self-host, prompt management con versionado v1/v2/v3 + labels + cache + linkage con traces.
LangSmith: si tu stack es LangChain.
Arize Phoenix: ELv2, OTel-native.

Pipeline orchestration

Para los pasos del pipeline LLMOps, las opciones dominantes:

Kubeflow Pipelines: el estándar K8s-native. KServe (la parte de serving de Kubeflow) tiene vLLM runtime upgraded a v0.8.1+ con soporte para reasoning models, tool calling, embeddings, reranking, Llama 4 y Qwen 3.
ZenML: ya mencionado; también orquestador de pipelines.
Metaflow (Netflix-originated): pipelines Python-first, menos LLM-específico pero workable.
Argo Workflows: alternativa OSS pura K8s.
Flyte: Kubernetes-native, OSS.

Serving

Cubierto en profundidad en vLLM en Kubernetes y Operators LLM K8s. Resumen:

vLLM Production Stack: Helm chart curado.
KServe vLLM runtime: K8s-native, vLLM 0.8.1+ con soporte agentic completo.
BentoML: serving flexible, popular en startups por su simplicidad.
NVIDIA Dynamo: el sucesor de Triton.
llm-d: CNCF Sandbox.
OME: LMSYS operator con SGLang nativo.

Evals y guardrails

Cubierto en Evals y Guardrails. Resumen ultra-corto:

Evals CI: DeepEval, Promptfoo, Ragas.
Evals platform: Langfuse, LangSmith, Phoenix, Braintrust.
Guardrails: NeMo Guardrails, Llama Guard 4, Llama Prompt Guard 2, LLM Guard, Lakera.

Drift detection y observability

Cubierto en el post de cierre eBPF. Resumen:

Drift: Evidently AI, NannyML, WhyLabs.
Tracing: Langfuse, OpenLLMetry, Phoenix.
eBPF: AgentSight, Hubble, Tetragon, ProfInfer.

La tabla de stack típico 2026

Etapa	Pieza dominante	Alternativas
Data ingestión + versioning	DVC + lakeFS (unificadas Nov 2025)	Pachyderm, Quilt
Vector store / RAG index	Milvus, Qdrant, pgvector, Weaviate	LanceDB, Pinecone, Chroma
Experiment tracking	MLflow 3.10	W&B Weave, Neptune
Pipeline orchestration	Kubeflow + Argo	ZenML, Metaflow, Flyte
Model registry	MLflow registry	W&B Models, KServe ModelMesh
Prompt versioning	Langfuse	LangSmith, MLflow Prompts
Serving	vLLM Production Stack	KServe, BentoML, Dynamo, llm-d, OME
Evals CI	DeepEval, Ragas	Promptfoo, OpenAI Evals
Evals platform	Langfuse, Phoenix	LangSmith, Braintrust
Guardrails	NeMo + Llama Guard	LLM Guard, Lakera
Tracing	OpenLLMetry + Langfuse	Phoenix, LangSmith
Drift detection	Evidently AI	NannyML, WhyLabs
eBPF observability	AgentSight + Tetragon + Hubble	(territorio nuevo, pocas alternativas)

13 piezas. Ninguna org usa todas; cualquier org seria usa al menos seis. Esto es el LLMOps stack actual.

La realidad operativa: nadie usa una sola herramienta

Múltiples comparativas coinciden en algo: los equipos que ganan combinan. Patrones recurrentes:

ZenML para orquestar + MLflow para tracking + KServe para serving: el stack OSS más popular en empresas que vienen de MLOps clásico.
Kubeflow + W&B + BentoML: para equipos con foco en research.
Langfuse + DeepEval + Phoenix + LiteLLM: para equipos LLM-puros sin background MLOps clásico.
MLflow + DVC + Argo + KServe: stack idiomático cloud-native sin LLM-specifics adicionales (con sus limitaciones).

La elección depende del background del equipo, del modelo de licencia que pueden permitirse, del nivel de self-hosting que necesitan, y de qué fricciones les bloquearon más en proyectos previos. No hay “una respuesta correcta”; hay un meta-patrón estable de capas que conviene cubrir.

Trampas operativas comunes

Tratar el prompt como texto en código

Hardcodear prompts en strings en el repo. Cambiarlos requiere PR + redeploy. Resultado: equipos que no iteran sobre prompts porque cada cambio cuesta horas de pipeline. Solución: prompt management externalizado (Langfuse, MLflow Prompts) con versionado, etiquetas, hot-reload.

Saltarse el dataset versioning

“DVC es complicado, ya lo metemos después”. Resultado: dos meses después, nadie sabe qué dataset entrenó qué modelo. Imposible reproducir incidentes. Solución: DVC + lakeFS desde el día 1, aunque sea con un subset pequeño.

Mezclar capas en el mismo pipeline

Equipos que meten ingestión, fine-tuning, eval, deploy en un único pipeline gigante. Cuando algo falla, todo el pipeline falla. Solución: pipelines independientes por etapa, con artifacts versionados como interfaces entre ellos.

Tracking sin estructura

Loguear todo en stdout y “ya lo veremos en CloudWatch”. Resultado: imposible correlar, comparar, debugear. Solución: OTel desde el día 1 con gen_ai.* semantic conventions.

Evals que no bloquean nada

Tienes evals, los corres, los miras, pero no impiden el deploy si bajan. Eventualmente baja gradualmente y nadie lo nota. Solución: eval gates en CI/CD que bloquean merge si métricas críticas regresan más de X%.

Sin retrain cadence

Lanzas v1 y nunca vuelves al modelo. Seis meses después, drift lo ha degradado pero el equipo está en otros proyectos. Solución: cadencia formal de retrain (mensual, trimestral) ligada a la cola de incidentes de producción.

Vendor lock-in invisible

Empiezas con OpenAI API + LangSmith + Pinecone. Cuando quieres self-host, descubres que migrar es un proyecto de 3 meses. Solución: capas de abstracción (LiteLLM, OpenLLMetry) y vendor-neutrality desde el principio.

Lo que viene en los siguientes posts de la serie

Post 2 — RAG sobre datalakes con Kafka: arquitectura técnica end-to-end — el más hands-on. Kafka como source-of-truth, Flink CDC, embedding pipelines, indexación continua en Milvus/Qdrant, ejemplo completo con números reales y manifests.
Post 3 — El pipeline LLMOps de seis etapas: arquitectura global — el mapa maestro del sistema completo con SVG reutilizable de “estás aquí” para los siguientes posts. Deep dive en cada una de las seis etapas (Data, Tune, Eval, Deploy, Observe, Retrain).
Post 4 — PostgreSQL + Qdrant en la etapa de ingestión — patrones de sincronización (dual-write, outbox + CDC, event-driven), arquitectura de microservicios completa, manifest de Qdrant cluster.
Próximos posts — pendientes de decidir: el cluster como plataforma multi-tenant, Constitutional AI / alignment runtime, fine-tuning continuo en profundidad, edge LLMs.

Referencias

LLMOps vs MLOps:

Herramientas:

MLflow — registry + tracking + serving.
Weights & Biases Weave — LLM tracing.
ZenML — pipeline orchestration MLOps + LLMOps.
Kubeflow — K8s-native MLOps.
KServe — model serving K8s.
BentoML — serving flexible.
Metaflow — Netflix’s pipelines.
DVC — dataset versioning.
lakeFS — data versioning enterprise, adquirió DVC en Nov 2025.

Comparativas 2026:

RAG vs Fine-Tuning:

Cross-references (las tres series previas):

Serie inferencia LLM: KV cache, vLLM en K8s, PagedAttention, Operators LLM K8s.
Serie eBPF: eBPF de cero a Cilium, Tetragon, Hubble, AgentSight.
Serie post-tracing: Evals, Guardrails, MCP observability, eBPF + drift.