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

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

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

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:

1. TTFT p50/p95 (time to first token) — lo que el usuario percibe.
2. TPOT p50/p95 (time per output token) — velocidad de streaming.
3. Throughput (tokens/segundo agregados) — capacity planning.
4. 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:

• The Complete MLOps/LLMOps Roadmap for 2026 (Sanjeeb Panda).
• MLOps in 2026: Architecture, Trends & Strategy (Hyscaler).

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.