El catálogo OSS para LLMOps en seis etapas: ficha por ficha, qué hace cada herramienta y cuándo elegirla

TL;DR

Para cada una de las seis etapas LLMOps (Data, Tune, Eval, Deploy, Observe, Retrain) y los dos componentes transversales (prompt + data versioning), el ecosistema open source tiene piezas canónicas que el blog ha estado citando una y otra vez. Este post las junta en un solo sitio con fichas de ~150 palabras por herramienta core: qué hace, en qué se diferencia de sus alternativas dentro del mismo bucket, su licencia y modelo de gobierno, y un gotcha típico que sólo se aprende en producción. Más alternativas como bullets, matriz de decisión por etapa según el caso (corpus pequeño / grande, un tenant / multi-tenant…), diagrama del stack OSS conectado y tabla maestra de licencias / oferta EE. La intención: que el lector cierre el post sabiendo qué hay disponible, qué empresa la mantiene, qué hueco rellena cada pieza, y cuándo elegirla. No es opinión: es catálogo curado.

Estás aquí: todas las etapas, pero por columna OSS

Este post comparte mapa con los dos anteriores de la serie — las seis etapas y los dos transversales están todas activas — pero hace el zoom in en la columna open source.

La analogía: la caja de herramientas del electricista

Un electricista profesional llega a una instalación con una caja organizada por compartimentos. No improvisa: para cada tipo de cable hay un pelacables específico, para cada tornillo un destornillador del calibre exacto, para cada medida un multímetro y unas pinzas amperimétricas, para cada conexión la regleta o el conector adecuado. La diferencia entre un electricista profesional y un manitas no es que sepa más teoría — a menudo el manitas se ha leído manuales —, es que tiene la herramienta correcta al alcance de la mano y sabe cuándo usar cada una. El día que falta el pelacables específico, improvisar con un cúter rompe el aislamiento, deja un cable mal terminado y el cuadro acaba volviendo a su sitio en garantía dos meses más tarde.

El stack OSS LLMOps funciona igual. Para cada problema canónico —versionar un dataset, indexar un corpus para retrieval, servir tokens con batching dinámico, propagar trace_id end-to-end, gestionar prompts con label production, orquestar pipelines de retraining— hay una pieza canónica del ecosistema open source que lo resuelve, mantenida por una comunidad o fundación seria, con licencia clara y un gotcha bien documentado. El consultor que sabe qué herramienta usar para cada cosa monta un sistema robusto en semanas; el que improvisa con “lo que ya conoce el equipo” paga después en operativa, normalmente cuando el sistema lleva ya carga real y cualquier sustitución es caro.

Este post abre la caja de herramientas y enseña cada ficha. No es un manual de uso — para eso están los posts de cada deep-dive enlazados al final —; es el catálogo curado.

Diagrama del stack OSS de referencia conectado

El catálogo cobra sentido cuando se ve cómo se conectan las piezas en una sola arquitectura coherente, que es la que el blog ha estado describiendo a lo largo de la serie. Las cajas no flotan; se hablan unas con otras por contratos estables (HTTP, gRPC, OTel, Kafka, S3/MinIO API).

Las flechas continuas marcan flujo de datos / control; las punteadas azules son trazas OTel. El plano K8s sostiene todo. El control plane abajo es donde viven los pipelines de retraining, los evals en CI, los prompts versionados y el lineage. El plano de datos a la izquierda alimenta tanto el serving (RAG, configs) como el control plane (datasets, lineage). El plano de observabilidad recibe del serving y de todo lo demás.

Ahora vamos por etapas. Cada una abre con un párrafo de contexto, luego fichas de herramientas core (~150 palabras cada una), bullets de alternativas relevantes, y matriz de decisión específica al final.

Etapa 1 — Data + transversal Data versioning

La etapa Data resuelve tres problemas distintos que los principiantes confunden: versionar datasets (que (dataset_id, version, hash) exista y propague), almacenar y servir el corpus operativo (object store + vector index + texto estructurado), y moverlo entre sistemas con CDC y schemas estables. Cubierto en detalle en los posts de data versioning con DVC y lakeFS, PostgreSQL + Qdrant en ingestión y RAG sobre Kafka.

DVC (Data Version Control)

DVC pone los datasets bajo control de versiones con la misma disciplina que git pone el código. Los apuntadores .dvc viven en git (texto plano, ~200 bytes por dataset), el contenido grande vive en un object store remote (S3, MinIO, Azure Blob, GCS). Cada dvc add calcula un hash SHA-256 del dataset, lo sube al remote y guarda el apuntador. La línea fundamental: el dataset_hash se convierte en el ticket de equipaje que viaja al trainer, al experiment tracking y a la lineage. Un mismo dataset reentrenado dos veces produce el mismo hash, por tanto experimentos reproducibles. DVC se integra con MLflow y W&B como input artifact. Gotcha: funciona bien para datasets que cambian por reemplazo (sustituyo train.jsonl por una versión nueva) y peor para datasets con miles de ficheros pequeños que cambian individualmente. Para ese caso, se combina con lakeFS. Licencia Apache 2.0, mantenida por Iterative.ai desde 2017. Hay DVC Studio (gestionado) y dvc data (CLI puro) en distintos planos.

lakeFS

lakeFS lleva la semántica git (branch, commit, merge, rollback) a un bucket S3/MinIO/ADLS entero. Donde DVC versiona archivos individuales como apuntadores en git, lakeFS versiona el bucket completo: puedes crear un branch del corpus, ingerir datos nuevos en el branch, validar que pasan checks (recall@10 sobre golden queries para embeddings, completitud para corpus tabular), y sólo entonces hacer merge a main. Es la pieza que hace seguro el RAG continuo: el corpus en producción está siempre en main, las actualizaciones se prueban en branches. Cuenta con hooks (pre-merge, pre-commit) que disparan validaciones automáticas, y con time-travel para reproducir el estado del bucket en una fecha pasada. Gotcha: el overhead del manifest sobre buckets enormes (cientos de millones de objetos) merece dimensionamiento; lakeFS guarda metadatos en su propio Postgres, no en el bucket. Licencia Apache 2.0, mantenida por Treeverse desde 2020. Oferta gestionada: lakeFS Cloud.

MinIO

MinIO es el object store S3-compatible que rellena el hueco “S3 on-premise” sin sobresaltos. API idéntica a S3 (los SDKs de AWS funcionan apuntándole un endpoint distinto), cliente CLI propio (mc), modo erasure-coded para tolerancia a fallo, replicación bucket-a-bucket, encryption at rest. Es la base sobre la que se montan los demás componentes del plano de datos: DVC remote, lakeFS underlying storage, snapshots de Postgres, MLflow artifacts, datasets de eval, modelos guardados, KV cache fabric distribuido. En despliegues pequeños se monta single-node multi-disk; en serios, clusters distribuidos. Gotcha: la licencia cambió a AGPLv3 en 2021 (era Apache 2.0 antes), lo que implica que distribuir software conectado a MinIO obliga a abrir el código que se conecta. Para uso interno on-premise no es problema; para vendor que empaqueta MinIO en producto comercial, sí. Mantenida por MinIO Inc. con oferta enterprise SUBNET y un fork comunitario llamado AIStor lanzado en 2025.

Qdrant

Qdrant es el vector database OSS más alineado con el patrón “corpus RAG por tenant con ACLs estrictas” del blog. Escrito en Rust, expone API REST + gRPC, indexa con HNSW + quantization scalar/binary para reducir memoria, soporta payload filtering eficiente (no es post-filtering: integra el filtro en la búsqueda HNSW), y permite colecciones aisladas por tenant. Para el escenario del chatbot multi-tenant, Qdrant es donde viven las tenant_<id>_kb_v3 con ACL strict. Escala bien horizontalmente (sharding por payload) y vertical (millones de chunks en un nodo con 64GB RAM). Gotcha: la quantization binaria es agresiva — reduce VRAM 32× pero degrada recall 10-20%; activarla sin re-tune de threshold rompe retrieval silenciosamente. Licencia Apache 2.0, mantenida por Qdrant Solutions GmbH (Alemania). Hay Qdrant Cloud (gestionado) y soporte EU-only para casos ENS.

PostgreSQL + pgvector

Postgres 18 con la extensión pgvector es el “vector database escondido” del stack: cuando el corpus es pequeño (sub-millón de embeddings) y ya hay Postgres en producción para datos operativos, montar Qdrant aparte es operativa cara. pgvector añade un tipo vector(dim), índices HNSW y IVF, y operadores <->, <#>, <=> para coseno, L2 y dot product. Combinado con tsvector (búsqueda full-text de Postgres) permite hybrid search dense + sparse en una sola query SQL. La 0.8 (2025) introdujo soporte halfvec y bit para reducir tamaño 4×-8×. Gotcha: HNSW en pgvector consume bastante RAM para construir el índice (multiplica por ~2 el tamaño de los embeddings) y bloquea inserts durante el build; en producción se construye en un secondary, se promociona, y se descarta el primary. Licencia PostgreSQL License (BSD-style permisiva) tanto en core como en pgvector. Mantenido por la PostgreSQL Development Group + pgvector por Andrew Kane + Crunchy Data + Neon.

Apache Kafka + Debezium

Kafka es el bus de eventos donde se materializa el “todo lo que pasa en la empresa es un stream”. Para LLMOps en producción cumple dos funciones: CDC desde sistemas fuente (Debezium captura cambios en Postgres / MySQL / MongoDB y los publica como topics) y buffer de eventos LLM (cada request, cada feedback, cada eval result acaba en un topic con el trace_id propagado). Como cuenta el post sobre RAG sobre Kafka, el corpus RAG se mantiene fresco capturando los cambios del CMS / sistema fuente como CDC, ejecutando el embedding en Flink streaming, e ingestando en Qdrant continuamente. Gotcha: Kafka mal dimensionado con retención larga + topics multi-cliente se convierte en un agujero de disco rápido; medir el throughput por topic y la cardinalidad de keys antes de producción es obligatorio. Licencia Kafka Apache 2.0 (proyecto ASF); Debezium Apache 2.0 (proyecto incubado por Red Hat). Alternativa drop-in compatible Kafka: Redpanda (BSL — uso comercial restringido).

Apache Flink (mención breve)

Flink procesa streams con latencia sub-segundo y semántica exactly-once. En el plano LLM se usa para: ejecutar embeddings en streaming (sobre topics CDC), agregar métricas online, materializar features para retraining. Licencia Apache 2.0, ASF. Alternativa común: Spark Structured Streaming (también ASF, micro-batch latency).

Más opciones para Data, mencionadas en el blog:

• Ceph — object store para clusters grandes con replicación geo-distribuida. Licencia LGPL/Apache, Red Hat / IBM.
• Milvus — vector database C++ alternativa a Qdrant; mejor para corpus de miles de millones. Apache 2.0, Zilliz.
• Karapace — Schema Registry compatible Confluent OSS. Apache 2.0, Aiven.
• DataHub / Apache Atlas / OpenMetadata — catalog + lineage. Apache 2.0, Acryl Data / ASF / Collate respectivamente.
• OpenLineage — estándar de eventos lineage cross-system. Apache 2.0, Linux Foundation AI&Data.

Matriz de decisión — Data:

Etapa 2 — Tune

La etapa Tune produce un nuevo model_id, model_version —típicamente un adapter LoRA sobre un base estable— con lineage hasta el dataset y experiment tracking para reproducir. Detalle en el post de fine-tuning continuo.

HuggingFace Transformers + PEFT

transformers es la biblioteca canónica para cargar y entrenar modelos de la familia decoder-only (Llama, Mistral, Qwen, Gemma…) y encoder-decoder. peft (Parameter-Efficient Fine-Tuning) es el complemento que añade soporte declarativo de LoRA, QLoRA, IA3 y adapters varios. Juntos forman el core obligatorio del stack Tune OSS: cualquier framework superior (Axolotl, LLaMA-Factory) los usa por debajo. PEFT permite entrenar un adapter de ~280 MB (orden de magnitud) en lugar de un modelo completo de ~140 GB, con resultado funcional equivalente en la mayoría de tareas de ajuste de estilo / dominio. Gotcha: PEFT con target_modules mal configurado entrena un adapter que cubre solo Q y V de la atención, dejando fuera key, output proj y MLP. El resultado parece entrenado pero rinde mal; añadir target_modules=["all-linear"] corrige (a costa de adapter más grande). Licencia Apache 2.0, mantenidas por Hugging Face SAS (empresa francesa); modelo de gobierno open con maintainers externos activos.

bitsandbytes

bitsandbytes implementa quantization de pesos a 8-bit y 4-bit con NF4 para modelos cargados con transformers. Reduce los 140 GB de Llama 3 70B FP16 a ~40 GB en NF4, permitiendo entrenamiento QLoRA en una sola H100 80GB. El truco está en que los pesos quedan quantized en memoria pero los cómputos sensibles (atención, gradient updates en el adapter) se hacen en FP16/BF16 con dequantization al vuelo. Ideal para fine-tuning en hardware limitado y para serving con vLLM cuando se quiere reducir VRAM. Gotcha: la NF4 quantization es lossy; en modelos pequeños (< 7B) la degradación de calidad es perceptible. Para production serving de modelos < 7B, se prefiere INT8 (más memoria, menos pérdida) o FP8 si el hardware lo soporta (H100 sí). Licencia MIT, mantenida por Tim Dettmers (originalmente en U. Washington, ahora con apoyo de Anthropic y HuggingFace).

MLflow Tracking

MLflow es el experiment tracking OSS de referencia: cada run del trainer registra parameters (lr, batch size, epochs, target_modules), metrics (loss curves, eval scores), artifacts (modelo, tokenizer, configs) y crucialmente input artifacts (dataset_id, dataset_hash, parent_run). El registry de modelos asocia cada model_version a un run_id reproducible. La línea de continuidad entre Tune y Deploy pasa por aquí: el deployment lee del registry el modelo a servir, con su lineage explícito. MLflow 2.x integra MLflow Prompts (registry de prompts) y MLflow Tracing (spans OTel-compatible), reduciendo número de componentes necesarios. Gotcha: el backend store por defecto es SQLite — funciona para experimentos personales y se rompe en cluster compartido. En producción: Postgres como backend store + MinIO/S3 como artifact store. Licencia Apache 2.0, mantenida por LF AI & Data (donado por Databricks en 2020).

Axolotl

Axolotl envuelve transformers + PEFT + bitsandbytes + DeepSpeed + FSDP en una configuración YAML declarativa: en lugar de escribir un script de ~300 líneas para configurar un fine-tuning, defines config.yml con base model, dataset path, LoRA config, training hyperparams y run de una línea. Soporta cargas Llama, Mistral, Qwen, Gemma, Phi… Mantiene compatibilidad con HuggingFace Hub para descargar modelos y datasets, y con MLflow / W&B para tracking. Es el framework de conveniencia que el blog cita cuando habla de “fine-tuning productivo sin reinventar la rueda”. Gotcha: el ritmo de cambios de la community es rápido; un config.yml que funcionaba hace 6 meses puede romper con una versión actual por refactors internos. Pinneando la versión exacta de Axolotl en el entorno se mitiga. Licencia Apache 2.0, mantenida por OpenAccess AI Collective (community-driven). Alternativa muy similar y más usada en China: LLaMA-Factory (Apache 2.0, Beihang U.).

Ray Train

Ray Train escala fine-tuning a múltiples nodos distribuyendo los workers en un cluster Ray. Mientras DeepSpeed y FSDP son paralelismo intra-job (varios GPUs colaborando en un job), Ray Train es el plano de orquestación que monta el cluster, lanza workers, gestiona checkpoints, recupera de fallos de nodo, integra con Slurm o Kubernetes. Para entrenamientos > 8 GPUs en clusters cambiantes, Ray Train evita la operativa de “lanzar manualmente N procesos torchrun con NCCL”. Se combina con MLflow para tracking. Gotcha: la curva de aprendizaje de Ray es real; para un solo nodo 4-8 GPUs, torchrun o Hugging Face Accelerate son más simples. Ray Train brilla cuando hay N nodos cambiantes. Licencia Apache 2.0, mantenida por Anyscale Inc. (commercial backer) + community. Alternativa más K8s-native: Kubeflow Training Operator (Apache 2.0, LF AI & Data).

Más opciones para Tune:

• DeepSpeed — paralelismo ZeRO 3 stages, mixed precision, offload CPU/NVMe. MIT, Microsoft.
• FSDP (Fully Sharded Data Parallel) — paralelismo PyTorch nativo, alternativa a DeepSpeed. BSD, Meta.
• LLaMA-Factory — equivalente a Axolotl con foco en Llama family. Apache 2.0, Beihang University.

Matriz de decisión — Tune:

Etapa 3 — Eval + Guardrails

Eval valida candidatos pre y post promotion contra un golden set con métricas operativas; Guardrails ejecuta safety online. Detallado en los posts de evals y guardrails.

DeepEval

DeepEval es la suite OSS de evals “tipo pytest”: defines tests con assertions sobre faithfulness, answer relevancy, contextual precision, hallucination rate, summarization quality… y los ejecutas en CI. Cada métrica es un evaluator: algunos rule-based, otros LLM-as-judge con prompts auditables. La filosofía es “evals como tests unitarios”: parametrizable por dataset, fallable en CI, integrable con GitHub Actions. Gotcha: las métricas LLM-as-judge varían entre versiones de modelo judge — si el judge sube de versión, los thresholds dejan de tener significado estadístico anterior. Pinning explícito del modelo judge en config + recalibration periódico del threshold es disciplina obligatoria. Licencia Apache 2.0, mantenida por Confident AI (empresa); oferta SaaS comercial paralela. Comparable: TruLens (MIT, TruEra) y G-Eval (académica).

RAGAS (RAG Assessment)

RAGAS está especializada en evaluar pipelines RAG. Define cuatro métricas canónicas: faithfulness (la respuesta se sostiene en los chunks recuperados), answer relevancy (la respuesta responde a la query), context precision (los chunks recuperados son relevantes), context recall (se recuperaron todos los chunks relevantes). Cada métrica se computa con LLM-as-judge sobre un dataset de (query, contexto, respuesta esperada). Para un sistema RAG, RAGAS es el evaluator que mide si el retrieval está alineado con la generación. Se integra con Langfuse y MLflow para guardar resultados. Gotcha: RAGAS funciona bien con golden sets de < 1000 ejemplos; sobre golden sets enormes el coste de judge LLM por evaluación se dispara — la práctica es muestrear. Licencia Apache 2.0, mantenida por Exploding Gradients (empresa de los autores).

Promptfoo

Promptfoo es el evaluator declarativo orientado a CI: defines en promptfooconfig.yaml un set de prompts y un set de assertions (contiene texto X, no contiene Y, faithfulness > 0.8, judge approves…), apuntas a un provider (OpenAI compatible, vLLM, Ollama…), y promptfoo eval corre la matriz prompts × providers × assertions, devuelve diff vs baseline y falla CI si algo regresiona. Es la pieza más “DevOps-friendly” del ecosistema de evals: integra trivial con GitHub Actions, GitLab CI o Jenkins. Gotcha: los thresholds de assertions hay que calibrarlos con datos reales; arrancar con > 0.5 por defecto produce false positives que erosionan la confianza del equipo. Calibrar tras la primera semana. Licencia MIT, mantenida por Promptfoo, Inc. (empresa); oferta SaaS comercial Promptfoo Cloud existe pero el OSS es completo.

NeMo Guardrails

NeMo Guardrails es el framework de NVIDIA para definir y aplicar políticas en sistemas LLM mediante un DSL llamado Colang. Permite expresar reglas como “si el usuario pregunta sobre tema X, contestar con plantilla Y” o “si el modelo intenta hacer Z, bloquear” en una sintaxis tipo guion conversacional, no en Python. Se ejecuta como middleware entre app y modelo: input rails (validan lo que entra), output rails (validan lo que sale), dialog rails (controlan el flujo). Pensado para sistemas multi-turn complejos donde las políticas son nontriviales. Gotcha: Colang añade latencia por turno (~50-200 ms dependiendo del policy graph); para chat conversacional alto throughput se desactivan dialog rails y se quedan solo input + output. Licencia Apache 2.0, mantenida por NVIDIA.

Microsoft Presidio

Presidio es el detector OSS de PII (Personally Identifiable Information) más maduro del ecosistema. Detecta DNI, NIE, IBAN, números de teléfono, emails, direcciones físicas, números de tarjeta de crédito, nombres propios, fechas de nacimiento… con recognizers basados en regex + NER (spaCy) + custom validators. Permite redacción (sustituir por placeholders), enmascarado (asteriscos) o anonimización determinista (hash repetible). Para escenarios ENS/NIS2, es la pieza que se pone delante (en input) y detrás (en output) del LLM para garantizar que no se procesa ni emite PII. Gotcha: los recognizers built-in cubren bien inglés y mal el resto; para español, catalán y vasco hay que añadir recognizers custom — disciplinada pero hacedero. Licencia MIT, mantenida por Microsoft.

Más opciones para Eval:

• Phoenix Arize OSS — combina tracing + evals, alternativa a Langfuse Evals. ELv2, Arize AI.
• lm-eval-harness — suite académica con benchmarks estándar (MMLU, HellaSwag…). MIT, EleutherAI.
• HELM — evals holísticos académicos. Apache 2.0, Stanford CRFM.
• Guardrails AI — alternativa pythonic a NeMo Guardrails. Apache 2.0, Guardrails AI Inc..
• LlamaGuard / PromptGuard / ShieldGemma — modelos de safety, no frameworks. Pesos abiertos, Meta / Google.

Matriz de decisión — Eval + Guardrails:

Etapa 4 — Deploy

Deploy sirve tokens al usuario con throughput y latencia predecibles, adapter hot-swap y multi-tenancy si aplica. Cubierto en los posts de vLLM en K8s, operators LLM, cluster multi-tenant, KV cache, PagedAttention y disaggregated serving.

vLLM

vLLM es el motor de inferencia OSS de referencia. Implementa PagedAttention (paging del KV cache estilo memoria virtual, evita fragmentación), continuous batching (las requests se incorporan al batch a medida que llegan, en lugar de esperar al batch siguiente), prefix caching (los prefijos comunes — system prompts — no recomputan KV cache), LoRA hot-swap (--enable-lora permite cargar y descargar adapters sin reiniciar el motor), API OpenAI-compatible, y soporte disaggregated prefill/decode desde 2025. Cubre del modelo Llama 3 / Mistral / Qwen / DeepSeek casi todo. Gotcha: el throughput máximo solo se alcanza con --max-num-seqs y --gpu-memory-utilization tuneados para el modelo y hardware concretos; valores por defecto son conservadores. La sesión inicial de tuning compensa: 2-3x de throughput. Licencia Apache 2.0, originada en UC Berkeley, hoy mantenida por vLLM Project / LF AI & Data + comunidad amplia (Red Hat, NVIDIA, AWS, IBM contribuyen). Alternativas serias en el mismo bucket: TGI (Apache 2.0, Hugging Face), SGLang (Apache 2.0, LMSys), TensorRT-LLM (Apache 2.0, NVIDIA, requiere conversión).

KServe

KServe es el operator de Kubernetes para servir modelos ML, incluido LLM, en un patrón declarativo: defines un InferenceService YAML con el modelo y predictor (que puede ser vLLM, TGI, Triton, o un container custom) y KServe se encarga de scheduling sobre nodos GPU, autoscaling (incluido scale-to-zero), traffic splitting para canary, model registry integration. Es la capa que estandariza el “cómo se despliega un modelo en K8s” entre múltiples motores, en lugar de inventar YAML específicos por motor. Soporta multi-modelo con Inference Graphs (encadenar prepocesador → modelo → postprocesador) y integra con KEDA/Karpenter para autoscaling de GPU pools. Gotcha: scale-to-zero en GPU funciona mal en la práctica porque el warm-up (cargar pesos en VRAM) tarda decenas de segundos; mejor minReplicas: 1. Licencia Apache 2.0, mantenido por Kubeflow / LF AI & Data. Alternativas: KubeRay (Apache 2.0, Anyscale), llm-d (Apache 2.0, CNCF), KAITO (MIT, Microsoft Azure).

Triton Inference Server

Triton sirve modelos heterogéneos en un solo backend: LLM (vía backend vLLM o TensorRT-LLM), modelos tradicionales (ONNX, TorchScript, TensorFlow), modelos custom. Para sistemas donde se mezclan inferencia LLM con clasificadores tradicionales, encoders de embeddings, reranking models, OCR, etc., Triton evita tener N motores distintos en N pods. Soporta ensemble models (encadenar modelos en una sola request), dynamic batching, model versioning, model warmup. Gotcha: Triton es flexible pero pesado de operar; para sistemas que sirven sólo LLM, vLLM directamente es más simple y más optimizado. Triton brilla cuando hay heterogeneidad real. Licencia BSD-3-Clause, mantenido por NVIDIA.

Envoy AI Gateway

Envoy AI Gateway es el “API gateway con conciencia de LLM” del ecosistema CNCF. Construido sobre Envoy Proxy, añade conocimiento de las APIs OpenAI-compatible (chat completions, embeddings, etc.), routing entre múltiples backends (vLLM local + OpenAI + Anthropic + Bedrock), token-based rate limiting (limita por tokens/minuto, no por requests), retries inteligentes, fallback entre proveedores, observability OTel built-in. Es la pieza que materializa “AI Gateway” como categoría arquitectónica. Gotcha: la integración con autenticación (OIDC, JWT) es flexible pero requiere configuración Envoy detallada; un AI Gateway “out of the box” sin configuración produce un Envoy que pasa todo. Licencia Apache 2.0, mantenido por CNCF desde la donación inicial de Tetrate. Alternativas: LiteLLM Proxy (MIT, BerriAI), Portkey (MIT, Portkey AI), Kong AI Gateway (Apache 2.0 base + EE, Kong Inc.).

llama.cpp

llama.cpp sirve LLMs en CPUs (y Apple Silicon, GPUs vía Vulkan/Metal/CUDA) con quantization muy agresiva (GGUF format, hasta 2-bit). Es la opción canónica para inferencia en hardware sin GPU dedicada — edge devices, workstations, máquinas de desarrollo. Cubre desde modelos pequeños (Phi-3, Gemma 2B) a Llama 70B en hardware con suficiente RAM. Gotcha: la latencia en CPU es órdenes de magnitud peor que en GPU dedicada — útil para evals offline, drift checks, desarrollo local, no para serving productivo en cargas reales. Licencia MIT, mantenida por Georgi Gerganov + community.

Más opciones para Deploy:

• TensorRT-LLM — máxima optimización en NVIDIA Hopper/Ada. Apache 2.0, NVIDIA.
• SGLang — buena para cargas con structured generation y JSON. Apache 2.0, LMSys.
• TGI — alternativa madura, foco en HuggingFace ecosystem. Apache 2.0, HuggingFace.
• NVIDIA Dynamo — disaggregated serving multinodo. Apache 2.0, NVIDIA.
• llm-d — operator K8s específico para LLM. Apache 2.0, CNCF.

Matriz de decisión — Deploy:

Etapa 5 — Observe

Observe propaga trace_id end-to-end, emite métricas runtime, ejecuta judge LLM sobre sampling y detecta drift. Detallado en tracing con AgentSight, MCP observability con OTel y eBPF + drift.

OpenTelemetry Collector

OTel Collector es el agente que recibe traces, metrics y logs en formato OTel (o en cualquier otro vía receivers), los procesa (filtros, sampling, atributo enrichment, redacción PII), y los enruta a uno o varios backends (Tempo, Jaeger, Prometheus, Loki, Langfuse…). Es la pieza que desacopla las apps del backend de observabilidad: cambiar de Tempo a Jaeger es cambiar el exporter del Collector, no la app. Para LLMOps, importa especialmente porque la spec OTel GenAI semantic conventions define los atributos gen_ai.request.model, gen_ai.prompt.version, gen_ai.response.tokens, etc., que cosen el trace_id con el lineage del sistema. Gotcha: la configuración del Collector tiende a crecer; sin disciplina y revisión periódica, acaba en un YAML de 800 líneas que nadie entiende. Modularizar con extensions ayuda. Licencia Apache 2.0, mantenido por CNCF / OpenTelemetry Project.

Tempo (traces) + Jaeger

Grafana Tempo es el backend de trazas distribuidas optimizado para coste: usa object store (S3/MinIO) en lugar de Elasticsearch, deduplica por trace_id, integra nativamente con Grafana para visualización. Para LLMOps, donde una request real genera 10-30 spans (gateway, prompt pull, RAG retrieval, prefill, decode N veces, scoring), Tempo aguanta volúmenes altos con coste razonable. Jaeger es la alternativa CNCF más establecida, mejor para casos < 100k traces/día, peor para object store nativo. Gotcha: Tempo no tiene indexing tradicional; búsquedas como “traces que tardaron > 5s y tocaron al tenant X” requieren el TraceQL + Grafana, no son tan rápidas como en Jaeger con Elasticsearch. Para diagnóstico ad-hoc inmediato, conviene mantener un Jaeger paralelo con sampling agresivo. Licencias AGPL 3.0 (Tempo) y Apache 2.0 (Jaeger), mantenidas por Grafana Labs y CNCF respectivamente.

Prometheus + Grafana

Prometheus es la base de métricas time-series del ecosistema. Modelo pull (scrapes endpoints /metrics), PromQL para queries, exporters para todo (Postgres, Kafka, NVIDIA GPU vía dcgm-exporter, vLLM nativo). Grafana visualiza Prometheus + Tempo + Loki en un solo plano. Para LLMOps, las métricas críticas son gpu_utilization, kv_cache_usage_pct, tokens_per_second, prefill_latency_p95, decode_latency_p95, queue_depth, agregadas por tenant. Gotcha: Prometheus es muy bueno hasta ~1M series activas; por encima conviene Thanos o Mimir para retención larga y escalabilidad horizontal. Para LLM cluster típico de blog (4-8 H100), Prometheus solo basta. Licencias Apache 2.0 (Prometheus, CNCF) y AGPL 3.0 (Grafana 10+, Grafana Labs).

Langfuse

Langfuse es el observability + prompt management OSS específico para LLM. Captura spans con semantic conventions LLM (input, output, model, tokens, latency, score, user_id, session_id), las visualiza como traces conversacionales (no solo árboles de spans), gestiona prompts versionados con label production y permite datasets curados + evals desde la misma UI. Para LLMOps en serio, Langfuse rellena el hueco que ni Tempo ni Jaeger cubren: una UI de tracing pensada para LLM-first. Gotcha: Langfuse mantiene su propio store (Postgres + ClickHouse para alto volumen); en cluster grandes la operativa de ClickHouse merece atención. Para arrancar, solo-Postgres aguanta. Licencia MIT del OSS core, EE Enterprise Edition con features adicionales (SSO, audit logs, advanced RBAC). Mantenida por Langfuse GmbH (Berlín, alemana). Hay Langfuse Cloud (SaaS).

Phoenix Arize OSS

Phoenix es el OSS de Arize AI para LLM observability + evals, alternativa a Langfuse con énfasis distinto: más orientado a evaluation y debugging visual (embedding drift, cluster analysis), menos a prompt management. Buena pareja con Langfuse cuando se quiere doble enfoque: Langfuse para “traces conversacionales producción”, Phoenix para “investigación exploratoria del comportamiento del modelo”. Gotcha: Phoenix duplica funcionalidad con Langfuse y con MLflow; tener los tres en producción multiplica operativa. Elegir uno principal y los otros como complemento. Licencia Elastic License 2.0 (no es OSI strictly), mantenida por Arize AI.

Cilium Tetragon + Hubble

Tetragon (eBPF runtime security observer) y Hubble (eBPF network observer) son las piezas de bajo nivel que dan visibilidad de runtime real al cluster: qué procesos se ejecutan en qué pods, qué syscalls hacen, qué conexiones de red abren, en tiempo real. Para entornos ENS/NIS2 que exigen “demuestra qué se ejecutó en producción”, Tetragon es la capa de auditoría irrefutable: cada ejecución de proceso con su parent, sus capabilities, su contexto K8s. Hubble visualiza flujos network por pod, namespace, service. Gotcha: la cantidad de eventos generados es alta; sin filtrado en kernel (que Tetragon soporta con TracingPolicy), satura el plano observability rápido. Disciplina en policies. Licencia Apache 2.0 ambos, mantenidos por Cilium / CNCF / Isovalent.

Evidently AI

Evidently es la librería OSS para drift detection: compara distribuciones de inputs y outputs entre dos ventanas temporales (entrenamiento vs producción, semana actual vs semana anterior), aplica tests estadísticos (KS, PSI, Wasserstein, chi-square) y genera reports HTML. Para LLMOps detecta cuándo la distribución de prompts cambia (nuevos temas, nuevas longitudes, nuevos idiomas) o cuándo el modelo empieza a responder más corto/largo/diferente. Gotcha: Evidently está orientada a tabular y embeddings; para texto crudo conviene combinarla con un encoder embedder que produzca vectores antes de aplicar tests. Licencia Apache 2.0, mantenida por Evidently AI (empresa). Alternativas: NannyML (Apache 2.0, NannyML BV), Alibi Detect (Apache 2.0, Seldon).

Más opciones para Observe:

• Loki — backend logs estilo Prometheus para Grafana. AGPL 3.0, Grafana Labs.
• Pixie — eBPF observability auto-instrumentado. Apache 2.0, CNCF.

Matriz de decisión — Observe:

Etapa 6 — Retrain + transversales

Retrain cierra el bucle feedback → triage → dataset enriquecido → adapter nuevo. Prompt versioning y data versioning cosen lineage cross-stage. Detallado en retrain, prompt versioning y data versioning.

Apache Airflow

Airflow es el scheduler de DAGs OSS más establecido. Defines workflows como código Python (DAGs), cada DAG con tareas (operators) que se ejecutan según dependencias declaradas + schedule cron. Para retraining: una DAG semanal que extrae feedback de Postgres, lo triagea con LLM-as-classifier, enriquece el dataset enriquecido en DVC, lanza el job de fine-tuning en Kubernetes, ejecuta evals contra el golden set, y promueve si pasa gates. Ecosistema enorme de operators para todo (S3, Postgres, Kafka, Slack, K8s, Spark…). Gotcha: Airflow 2.x mejoró mucho desde el caos de 1.x, pero el scheduler sigue siendo un componente que merece atención operativa (Postgres backend, executor pool, sidecar workers); para pipelines simples es over-engineering. Licencia Apache 2.0, mantenido por ASF.

Argo Workflows

Argo Workflows es el equivalente K8s-native de Airflow: cada paso es un container, los DAGs se definen como YAML K8s, el ejecutor es el propio Kubernetes. Para entornos donde todo es K8s, Argo encaja sin un componente extra que mantener. Las tareas largas (fine-tuning de 6 horas) se ejecutan como Pods que sobreviven a fallos del control plane. Integra trivial con Kubeflow Pipelines (que se construye encima). Gotcha: la sintaxis YAML de Argo es verbosa; para DAGs complejos, Argo se siente menos productivo que Airflow en Python. Soluciones: Hera (DSL Python para Argo, DataBricks contribution) o Argo + custom CRDs. Licencia Apache 2.0, mantenido por CNCF.

Kubeflow Pipelines

Kubeflow Pipelines es la capa por encima de Argo Workflows orientada específicamente a ML: artifact tracking, experiment tracking, pipeline templates reutilizables, componentes versionados. Construido sobre Argo, añade el modelo conceptual ML (input artifact, output artifact, metrics) que Argo crudo no tiene. Para retraining cíclico en cluster K8s, es la opción más “ML-ready” del ecosistema OSS. Gotcha: Kubeflow como suite completa es pesada (10+ componentes); muchas org instalan solo Pipelines + Training Operator + Katib y omiten Notebook Server / KFServing legacy. Licencia Apache 2.0, mantenido por CNCF / LF AI & Data.

Feast

Feast es el feature store OSS más usado. Define feature views sobre fuentes batch (BigQuery, Postgres, Parquet) y online (Redis, DynamoDB, Postgres con extension), expone una API consistente para read-during-training y read-during-inference (point-in-time correctness), y garantiza que las features del modelo en producción son las mismas que con las que se entrenó. Para LLMOps donde el modelo necesita features de usuario / sesión / contexto consistentes (último plan, antigüedad como cliente, tickets recientes), Feast da la disciplina. Gotcha: para muchos sistemas LLM puros (chatbot RAG sin features complejas), Feast es over-engineering — basta con Postgres. Cuando hay features de verdad (recomendación, scoring, ranking), Feast brilla. Licencia Apache 2.0, mantenido por LF AI & Data.

Argilla

Argilla es la plataforma OSS de anotación + HiL (human-in-the-loop) más alineada con LLMOps moderno. Crea proyectos de anotación con templates (clasificación, ranking, span annotation, RLHF preference, free-form text), conecta con HuggingFace datasets, integra con Langfuse para importar traces desde producción como casos a anotar. Soporta múltiples anotadores con reconciliación, kappa scoring, control de calidad. Para enriquecer datasets de retrain con casos del cluster “tono brusco” del post de Retrain, Argilla es el frontend. Gotcha: Argilla requiere Elasticsearch para production performance; para experimentos pequeños vale con SQLite. Licencia Apache 2.0, mantenida por Argilla, Inc. (adquirida por Hugging Face en 2024). Alternativa: Label Studio (Apache 2.0, HumanSignal), más generalista, menos LLM-first.

Langfuse Prompts + MLflow Prompt Registry

Langfuse Prompts gestiona prompts como entidades versionadas con labels (production, staging, experiment). El cliente lee el prompt activo de Langfuse en el path de la request (con cache local de pocos segundos) y propaga prompt_id, prompt_version al span OTel — exactamente como hace el post forense. MLflow Prompt Registry hace lo mismo con un modelo conceptual ligeramente distinto (sin labels-as-pointers; usa stages como Models registry). Ambas válidas; la elección depende de qué herramienta de tracking ya hay. Gotcha (Langfuse): las labels son mutables — cambiar production apunta a otra versión sin auditoría explícita; conviene desplegar prompts vía PR contra el repo de configs, no manualmente en UI. Licencias y gobierno cubiertos arriba.

Más opciones para Retrain + transversales:

• Prefect — DAGs Python “moderno”, alternativa a Airflow. Apache 2.0, Prefect Tech.
• Dagster — DAGs con foco fuerte en data assets. Apache 2.0, Dagster Labs.
• Label Studio — anotación generalista. Apache 2.0, HumanSignal.
• OpenLineage — estándar de eventos lineage cross-system. Apache 2.0, LF AI & Data.
• DataHub / Apache Atlas / OpenMetadata — catalog + lineage con UI. Apache 2.0.

Matriz de decisión — Retrain + transversales:

Tabla maestra: licencia, gobierno y oferta enterprise

Patrón a mirar al leer la tabla: las AGPL 3.0 y Elastic v2 son las que más fricción meten en empresas con políticas estrictas de licencias (legal pide review específico). Las Apache 2.0 son las que pasan compliance sin discusión. Las que tienen “EE Enterprise” o equivalente esconden una decisión: la versión OSS es funcionalmente completa para producción, pero features de equipo (SSO, audit, advanced RBAC) viven en la versión comercial. Para clientes ENS bajo declaración ALTA, las features EE (SSO con SAML/OIDC corporativo, audit logs inmutables) suelen ser obligatorias — vale la pena conocer el precio antes.

Cuándo subir desde el “stack mínimo” al “stack completo”

El catálogo entero puede ser intimidante. Pero no se monta todo desde el primer día. Hay un orden razonable que el blog ha estado validando en posts a lo largo de la serie. El stack mínimo viable que sirve una API LLM con disciplina aceptable:

• Serving: vLLM en Kubernetes + un Envoy AI Gateway delante.
• Datos: Postgres + pgvector (sin Qdrant), MinIO para object store, sin Kafka.
• Tune: Axolotl + MLflow, sin Ray Train.
• Eval: Promptfoo en CI, sin RAGAS ni judge en producción.
• Observe: OTel Collector + Prometheus + Grafana + Langfuse, sin Phoenix ni Tetragon.
• Retrain: feedback en Postgres + scripts crontab, sin Airflow.
• Versioning: prompts en Langfuse + datasets en DVC sobre MinIO, sin lakeFS.

Eso son ~8-10 componentes y sirve un sistema LLM razonable para un solo tenant con tráfico moderado. Cuando el sistema crece, hay momentos identificables donde añadir cada pieza compensa:

Cada salto añade 1-2 componentes y vale el coste solo cuando el disparador está claro. Añadir Kafka “por si acaso” cuando el corpus se actualiza una vez al mes es trabajo neto negativo.

Lo que no hemos cubierto (todavía)

Quedan piezas merecedoras de su propio post:

• Schema Registry para LLM data y prompts (Confluent OSS, Karapace, JSON Schema Registry).
• Catálogo + lineage profundizado: DataHub vs Atlas vs OpenMetadata + OpenLineage en serio.
• Federated learning sobre OSS (Flower, FedML) para escenarios donde los datos no se centralizan.
• MCP Servers OSS y su lugar en el stack como capa de tools / acciones.
• Evals “agéntic” específicos para sistemas multi-step con tool use.
• Mejores prácticas de upgrade de cada componente (vLLM cada 6 semanas, Kafka mayor cada 18 meses, etc.).

Ver también

• Anatomía de una petición LLM en producción — la pieza forense que sigue una request por las seis etapas; este catálogo es la lista de herramientas que aparecieron en ese recorrido.
• El catálogo paralelo OSS vs hyperscalers — el corte horizontal que enseña, para cada etapa, qué hace cada herramienta OSS y cuál es su equivalente en AWS, GCP y Azure.
• El pipeline LLMOps de seis etapas — el mapa maestro del pipeline al que este catálogo pone nombres OSS concretos.
• MLOps específico para LLMs en 2026 — contexto general sobre LLMOps.
• Data versioning con DVC y lakeFS — el deep-dive de los dos protagonistas OSS de la etapa Data + transversal.
• Prompt versioning con Langfuse y MLflow — el deep-dive del transversal Prompt.
• Fine-tuning continuo en producción — la etapa Tune en operativa real.
• Evals: la capa después del tracing y Guardrails y safety en LLMs — los deep-dives de Eval + safety.
• KV cache · PagedAttention · Disaggregated serving · vLLM en K8s · Operators LLM K8s · Cluster GPU multi-tenant — Deploy en todas sus capas.
• AgentSight tracing LLM · MCP observability con OTel · eBPF + drift — Observe en sus tres ángulos.
• Retrain: cerrar el bucle — la etapa Retrain detallada.

Referencias

• vLLM · vLLM Production Stack · TGI · SGLang · TensorRT-LLM · llama.cpp — motores de inferencia OSS.
• Triton Inference Server · KServe · Envoy AI Gateway · LiteLLM — orquestación y AI gateway.
• Qdrant · pgvector · Milvus — vector databases.
• DVC · lakeFS · MinIO — versioning y object store.
• Apache Kafka · Debezium · Apache Flink — streams y CDC.
• Hugging Face Transformers · PEFT · bitsandbytes · Axolotl — fine-tuning.
• MLflow · Ray Train · Kubeflow Training Operator — orquestación de entrenamiento.
• DeepEval · RAGAS · Promptfoo · NeMo Guardrails · Presidio — evals y guardrails.
• OpenTelemetry · OTel GenAI semconv · Tempo · Prometheus · Grafana · Loki — observability foundation.
• Langfuse · Phoenix Arize · Evidently AI — LLM observability y drift.
• Cilium · Tetragon · Hubble — eBPF runtime.
• Apache Airflow · Argo Workflows · Kubeflow Pipelines · Feast · Argilla — orquestación + retrain + anotación.