Open-Source on lo0 — Blog Técnico

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

Sat, 23 May 2026 07:30:00 +0200

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:

Si tu caso es	Elige
Corpus < 1M embeddings, ya tienes Postgres	pgvector (un componente menos)
Corpus 1M-100M, multi-tenant con ACL	Qdrant (filtering integrado, ACLs por colección)
Corpus > 100M, sharding agresivo	Milvus (escala lineal mejor a billones)
Datasets entrenamiento + experiment tracking	DVC sobre MinIO + integración MLflow
Corpus RAG con releases controlados	lakeFS sobre MinIO + hooks pre-merge
Quieres ambos	DVC + lakeFS complementarios (recomendación del blog)

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:

Si tu caso es	Elige
Fine-tune en 1 GPU 24GB (RTX 4090)	QLoRA con bitsandbytes NF4 + Axolotl
Fine-tune en 1 H100 80GB modelos < 13B	LoRA bf16 + Axolotl
Fine-tune en 4-8 GPUs nodo único	transformers + PEFT + Accelerate + MLflow
Fine-tune multi-nodo en cluster K8s	Kubeflow Training Operator o Ray Train
Tracking obligatorio reproducible	MLflow + DVC input artifact
Quieres lo mínimo viable	Axolotl + MLflow

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:

Si tu caso es	Elige
Eval en CI tipo “pytest para LLMs”	Promptfoo + GitHub Actions
Eval específico de pipeline RAG	RAGAS + Langfuse datasets
Eval general con métricas custom	DeepEval + dataset MLflow
Dialog policy con reglas declarativas	NeMo Guardrails (Colang)
Solo PII redaction in/out	Presidio (no necesitas NeMo)
Safety model abierto en español	LlamaGuard 3 o ShieldGemma

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:

Si tu caso es	Elige
Production serving en NVIDIA H100/A100	vLLM (default seguro)
Squeezing absoluto de throughput Hopper	TensorRT-LLM + plugin vLLM o standalone
Edge / dev local sin GPU	llama.cpp
Multi-modelo (LLM + clasificadores + encoders)	Triton con backend vLLM
K8s declarativo con autoscaling	KServe + vLLM como predictor
AI Gateway con token rate limiting	Envoy AI Gateway
Cluster GPU multi-nodo disaggregated	NVIDIA Dynamo sobre vLLM

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:

Si tu caso es	Elige
Stack mínimo viable	OTel Collector + Tempo + Prometheus + Grafana + Langfuse
Traces con búsqueda ad-hoc fuerte	Añadir Jaeger con sampling agresivo
Compliance ENS / NIS2 runtime audit	Tetragon + Hubble + retention obligada
Investigación exploratoria del modelo	Phoenix Arize OSS además de Langfuse
Drift detection estadístico	Evidently sobre embeddings + inputs
Cluster > 1M series Prometheus	Mimir (Grafana Labs) o Thanos

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:

Si tu caso es	Elige
Pipelines simples con catálogo de operators	Airflow
Todo es K8s, minimalismo de componentes	Argo Workflows
ML pipelines con artifact tracking	Kubeflow Pipelines
Anotación HiL para retrain LLM	Argilla + integración Langfuse
Features compartidas entre training e inference	Feast
Sin features complejos, sólo prompts + LLM	Saltar Feast
Prompt registry ligero	Langfuse Prompts
Ya hay MLflow centralizado	MLflow Prompt Registry

Tabla maestra: licencia, gobierno y oferta enterprise

Herramienta	Licencia	Gobierno / mantenedor	EE / SaaS comercial
DVC	Apache 2.0	Iterative.ai	DVC Studio
lakeFS	Apache 2.0	Treeverse	lakeFS Cloud
MinIO	AGPL v3	MinIO Inc.	SUBNET / AIStor
Qdrant	Apache 2.0	Qdrant GmbH	Qdrant Cloud
pgvector	PostgreSQL License	Andrew Kane + community	— (built-in Postgres clouds)
PostgreSQL	PostgreSQL License	PostgreSQL Global Dev Group	múltiples managed (Crunchy, Neon, Aiven, EDB)
Apache Kafka	Apache 2.0	ASF	Confluent Cloud
Debezium	Apache 2.0	Red Hat / ASF	Debezium Server / Confluent Connectors
Apache Flink	Apache 2.0	ASF	Ververica Platform, Aiven
HF Transformers	Apache 2.0	Hugging Face SAS	HF Inference Endpoints / Enterprise Hub
PEFT	Apache 2.0	Hugging Face SAS	— (parte de la oferta HF)
bitsandbytes	MIT	Tim Dettmers + community	—
MLflow	Apache 2.0	LF AI & Data	Databricks MLflow
Axolotl	Apache 2.0	OpenAccess AI Collective	—
Ray (Train)	Apache 2.0	Anyscale + community	Anyscale Platform
DeepSpeed	MIT	Microsoft	—
DeepEval	Apache 2.0	Confident AI	Confident AI SaaS
RAGAS	Apache 2.0	Exploding Gradients	—
Promptfoo	MIT	Promptfoo, Inc.	Promptfoo Cloud
NeMo Guardrails	Apache 2.0	NVIDIA	NeMo Microservices
Presidio	MIT	Microsoft	—
Phoenix (Arize)	Elastic v2	Arize AI	Arize Platform
vLLM	Apache 2.0	vLLM Project / LF AI & Data	múltiples (Red Hat, AWS, IBM, NVIDIA)
TGI	Apache 2.0	Hugging Face SAS	HF Inference Endpoints
SGLang	Apache 2.0	LMSys + community	—
TensorRT-LLM	Apache 2.0	NVIDIA	NVIDIA AI Enterprise
llama.cpp	MIT	Georgi Gerganov + community	—
Triton Inference Server	BSD-3	NVIDIA	NVIDIA AI Enterprise
KServe	Apache 2.0	LF AI & Data (Kubeflow)	—
Envoy AI Gateway	Apache 2.0	CNCF / Tetrate	Tetrate Service Bridge
LiteLLM	MIT	BerriAI	LiteLLM Cloud
OpenTelemetry	Apache 2.0	CNCF	múltiples vendor (Honeycomb, Datadog, Grafana)
Tempo	AGPL 3.0	Grafana Labs	Grafana Cloud Tempo
Jaeger	Apache 2.0	CNCF	—
Prometheus	Apache 2.0	CNCF	Grafana Cloud, AMP, GCP Managed Prom, Azure
Grafana	AGPL 3.0	Grafana Labs	Grafana Cloud, Grafana Enterprise
Loki	AGPL 3.0	Grafana Labs	Grafana Cloud Loki
Langfuse	MIT (core) / EE	Langfuse GmbH	Langfuse Cloud
Tetragon	Apache 2.0	Cilium / CNCF / Isovalent	Isovalent Enterprise
Hubble	Apache 2.0	Cilium / CNCF	Isovalent Enterprise
Evidently AI	Apache 2.0	Evidently AI	Evidently Cloud
Apache Airflow	Apache 2.0	ASF	Astronomer, MWAA, Cloud Composer
Argo Workflows	Apache 2.0	CNCF	—
Kubeflow Pipelines	Apache 2.0	CNCF / LF AI & Data	—
Feast	Apache 2.0	LF AI & Data	Tecton (commercial)
Argilla	Apache 2.0	Hugging Face	HF Hub features
OpenLineage	Apache 2.0	LF AI & Data	—
DataHub	Apache 2.0	Acryl Data	Acryl Cloud

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:

Disparador	Componente que añadir
Multi-tenant con corpus aislados	Qdrant (colecciones por tenant, ACL)
Corpus se renueva frecuente y se rompe periódicamente	lakeFS (branches con hooks pre-merge)
Embedding pipeline necesita streaming	Kafka + Debezium + Flink
Retrain pasa de mensual a semanal	Airflow o Argo Workflows
Aparecen features compartidas (perfil cliente, scoring)	Feast
Anotación supera la capacidad informal	Argilla
Eval RAG necesita métricas específicas	RAGAS + Langfuse datasets
Compliance ENS exige runtime audit	Tetragon + Hubble
Drift es invisible y aparece tarde	Evidently
Stack único deja de cubrir multi-modelo	Triton o KServe con varios predictors
Múltiples adapters multi-tenant simultáneos	vLLM Production Stack + Operator dedicado

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.

El catálogo paralelo: las seis etapas LLMOps en open source y en los hyperscalers (AWS, GCP, Azure)

Sat, 23 May 2026 07:00:00 +0200

TL;DR

El post forense anterior usó una única request para recorrer las seis etapas del pipeline LLMOps y los dos componentes transversales. Este post recorre las mismas etapas pero las cruza con tres columnas extra: cómo se monta cada etapa en open source on-premise, y cuáles son los servicios equivalentes en AWS, GCP y Azure. No es una guía de migración ni un benchmark de coste: es un catálogo de equivalencias con sus gaps. El patrón general que verás: el OSS te da control, soberanía y composición libre a cambio de operativa cara; los hyperscalers te dan integración y time-to-market a cambio de lock-in en márgenes, contratos de datos y dependencia política. Para escenarios sometidos a ENS / NIS2 con datos críticos del cliente, el OSS gana por defecto; para proyectos de descubrimiento donde el time-to-market es la métrica que decide, el hyperscaler gana por defecto. La parte interesante está en el medio. Como hilo concreto, al final tomamos el chatbot multi-tenant del post anterior y lo portamos a AWS pieza a pieza para mostrar qué desaparece, qué aparece, y dónde se materializa el lock-in.

Estás aquí: las mismas seis etapas, pero por columna

Este post comparte mapa con el post anterior — las seis etapas y los dos transversales están todas activas — pero cambia el corte: en lugar de seguir una request horizontalmente, hace el corte vertical y muestra qué herramientas viven en cada etapa según el modelo de despliegue.

La analogía: la panadería propia y la franquicia

Un panadero abre negocio. Tiene dos modelos posibles.

Puede abrir panadería propia: alquila el local, compra el horno, elige los proveedores de harina, contrata a su maestro panadero, escribe sus recetas, decide los precios, decora el escaparate. El día que quiere lanzar un pan ecológico de masa madre de centeno, no pide permiso a nadie. El día que el precio de la harina sube, busca otro proveedor. Pero todo lo paga él: la inversión inicial, el riesgo, la operativa diaria, los meses en los que no acierta con el barrio. La panadería es suya.

O puede entrar en franquicia: el franquiciador le entrega el local llave en mano, el horno con contrato de mantenimiento, los proveedores ya negociados, los manuales operativos, las recetas escritas, el marketing centralizado, la app de fidelización, el sistema TPV. La curva de aprendizaje es de semanas, no de años. Pero las recetas son del franquiciador, los proveedores también, el precio del pan está en el catálogo y el día que cambia la fórmula del croissant le llega un correo informativo, no una decisión de negocio.

Ambas panaderías sacan pan. Ambas cumplen sanidad y producen ingresos. La diferencia operativa es enorme y no es de tecnología: es de propiedad, control y plazo.

El paralelismo con LLMOps es directo. El stack OSS on-premise es la panadería propia. El stack gestionado en hyperscalers es la franquicia. Las piezas que aparecen en cada etapa son equivalentes funcionalmente — al final del día las dos resuelven el mismo problema técnico —, pero el modelo de gobierno, el coste operativo, el lock-in y las garantías de cumplimiento son distintos. Este post hace el catálogo paralelo para que la elección no se haga por defecto.

Recap rápido del post anterior

En el post forense seguimos una request específica: un usuario premium-es de una aseguradora preguntando "¿Cómo cancelo mi suscripción premium?" al chatbot de soporte multi-tenant del proveedor SaaS que la hospeda. El recorrido atravesó las seis etapas del pipeline LLMOps —Data, Tune, Eval, Deploy, Observe, Retrain— más los dos componentes transversales —prompt versioning y data versioning— sobre una infraestructura on-premise: RKE2 con Cilium BGP, cluster 4×H100 SXM, RTX 4090 de desarrollo, vLLM en Kubernetes, Langfuse + OTel + Prometheus + Tempo, Postgres + Qdrant, DVC + lakeFS + MinIO, Kafka y MLflow. El sistema cumple ENS / NIS2 y mantiene trace_id propagado extremo a extremo.

Lo que viene ahora es ese mismo sistema, pieza a pieza, mostrando para cada caja qué herramienta hace el trabajo si estás en cloud público — porque la pregunta del integrador rara vez es “¿OSS sí o no?”: es “¿qué pierdo y qué gano si esta caja la cojo gestionada?”. Y la respuesta es distinta por caja.

Etapa 1 — Data

El problema. Hay tres sub-problemas que la etapa Data resuelve, frecuentemente confundidos. Primero, versionado e identidad del corpus y de los datasets de entrenamiento (que un dataset_id, dataset_version exista y propague). Segundo, almacenamiento y servido del corpus operativo (object store + vector index + texto estructurado). Tercero, streams e ingestión desde sistemas fuente con CDC, transformación y esquemas estables (Schema Registry).

Stack OSS de referencia. El versionado vive en DVC (apuntadores en git, contenido en object store) combinado con lakeFS para semántica branch/merge sobre datos. El post sobre data versioning profundiza en la diferencia funcional. El object store es MinIO o Ceph. El vector index es Qdrant o Milvus para corpus grandes (millones de chunks) y pgvector sobre Postgres 18 para casos pequeños donde la operativa de un componente menos compensa. La capa stream es Kafka (Apache puro o Redpanda) con Schema Registry (Confluent o Karapace OSS), CDC con Debezium o Flink CDC, transformación con Flink o Spark Structured Streaming. El catálogo / lineage es DataHub, Apache Atlas o OpenMetadata con eventos OpenLineage entre sistemas. El post sobre ingestión PostgreSQL + Qdrant y el post sobre RAG sobre Kafka cubren la operativa detallada.

Equivalentes hyperscaler. En AWS, el corpus vive en S3 (con versioning habilitado, que es el sustituto barato del data versioning serio), las consultas tabulares en Athena o Redshift, el vector index en Amazon OpenSearch con plug-in vectorial o en Amazon Aurora pgvector. La capa stream es MSK (Kafka gestionado) o Kinesis Data Streams, CDC con AWS DMS, transformación con Glue Streaming o MSK Connect. El catálogo es AWS Glue Data Catalog + AWS Lake Formation para gobierno de datos. Y para el caso RAG hay además Amazon Bedrock Knowledge Bases, que es el atajo gestionado: le das S3, te indexa en OpenSearch o Aurora pgvector, te expone un retrieval API y se acaba la operativa — a cambio de pagar por chunk indexado y consulta.

En GCP, el corpus vive en Cloud Storage (con object versioning), el almacén analítico es BigQuery (con BigQuery Vector Search ya integrado), el vector dedicado es Vertex AI Vector Search (antes Matching Engine). La capa stream es Pub/Sub + Dataflow, CDC con Datastream. El catálogo y lineage es Dataplex (que en 2024-2025 absorbió Data Catalog y añadió lineage automático). El equivalente gestionado de Knowledge Bases es Vertex AI Search (antes Discovery Engine).

En Azure, el corpus vive en ADLS Gen2, las consultas tabulares en Microsoft Fabric / Azure Synapse, el vector index en Azure AI Search (vector mode) o Azure Cosmos DB for PostgreSQL con pgvector. La capa stream es Event Hubs + Stream Analytics o Microsoft Fabric Real-Time Intelligence, CDC con Azure Data Factory. El catálogo es Microsoft Purview, que cubre catalog, lineage y data governance integrados con Entra ID.

Tabla resumen — Etapa Data.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Object store	MinIO, Ceph	S3	Cloud Storage	ADLS Gen2
Versionado de datasets	DVC, lakeFS	S3 Versioning (limitado), Lake Formation	GCS Versioning, Dataplex	ADLS versioning, Purview
Vector index	Qdrant, Milvus, pgvector	OpenSearch, Aurora pgvector, Bedrock KB	Vertex Vector Search, BigQuery VS	Azure AI Search, Cosmos pgvector
Stream + CDC	Kafka + Debezium + Flink	MSK / Kinesis + DMS + Glue	Pub/Sub + Datastream + Dataflow	Event Hubs + ADF
Schema Registry	Karapace, Confluent OSS	Glue Schema Registry	Pub/Sub schemas	Schema Registry (Event Hubs)
Catalog + lineage	DataHub, Atlas, OpenLineage	Glue Catalog + Lake Formation	Dataplex	Purview
RAG gestionado end-to-end	— (lo montas)	Bedrock Knowledge Bases	Vertex AI Search	Azure AI Studio Knowledge

Dónde los nombres engañan. S3 Versioning no es DVC. Conserva versiones de objetos pero no tiene noción de dataset (¿qué objetos forman juntos la versión 3 del enriquecido?), no propaga dataset_hash al trainer, no integra con experiment tracking, y no falla un CI si un dataset rompe schema. Cubrirlo de verdad en AWS exige combinarlo con Lake Formation, Glue Data Catalog y registros propios en SageMaker Experiments. Lo mismo en GCP con Dataplex y en Azure con Purview. El gap es real y se paga en operativa o en lineage roto.

Etapa 2 — Tune

El problema. Producir un nuevo model_id, model_version —típicamente un adapter LoRA sobre un base estable, como cuenta el post de fine-tuning continuo— con lineage hasta el dataset que lo entrenó y experiment tracking que permita reproducirlo seis meses después.

Stack OSS. Núcleo técnico: HuggingFace Transformers + PEFT (LoRA, QLoRA), bitsandbytes para quantization, DeepSpeed o FSDP para paralelismo. Experiment tracking: MLflow (autoritativo) o Weights & Biases self-hosted. Frameworks de conveniencia: Axolotl y Llama Factory envuelven la maquinaria anterior con configuración declarativa. Orquestación distribuida: Kubeflow Training Operator o Ray Train. En infraestructuras pequeñas, scripts directos con Slurm o K8s Jobs sobre GPU pools. La cadena de lineage dataset → run → model se cierra registrando el dataset como input artifact MLflow.

Equivalentes hyperscaler. En AWS, SageMaker Training Jobs sirve para la mayoría de cargas, SageMaker HyperPod para entrenamientos grandes con resiliencia a fallos de nodo, SageMaker JumpStart ofrece fine-tuning click-to-train sobre catálogo de modelos pre-curados. Para fine-tuning de modelos Bedrock (Claude, Llama, Mistral hospedados) está Bedrock Custom Models: tú subes el dataset al S3, Bedrock entrena, te devuelve un endpoint privado con throughput provisionado. El experiment tracking equivalente es SageMaker Experiments o MLflow gestionado en SageMaker (sí, AWS hospeda MLflow oficialmente desde 2024).

En GCP, Vertex AI Custom Training corre cualquier contenedor con GPUs o TPUs; Vertex AI Tuning es la API gestionada para fine-tunear Gemini y modelos del Model Garden. Experiment tracking en Vertex AI Experiments (con compatibilidad MLflow).

En Azure, Azure ML Training Jobs sobre clusters propios o managed compute; Azure OpenAI fine-tuning para fine-tunear GPT y o-series; Azure ML Experiments con MLflow integrado nativamente desde 2022.

Tabla resumen — Etapa Tune.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Framework de entrenamiento	HF Transformers + PEFT	SageMaker SDK	Vertex AI SDK	Azure ML SDK
Quantization / paralelismo	bitsandbytes, DeepSpeed, FSDP	SageMaker libs + soporte HF	Vertex + soporte HF	Azure ML + soporte HF
Fine-tuning gestionado (caja negra)	—	Bedrock Custom Models, JumpStart	Vertex Tuning (Gemini)	Azure OpenAI fine-tuning
Distribuido en cluster	Kubeflow, Ray Train, Slurm	SageMaker HyperPod	Vertex AI Training (multinodo)	Azure ML compute clusters
Experiment tracking	MLflow, W&B self-hosted	SageMaker Experiments, MLflow gestionado	Vertex Experiments	Azure ML + MLflow
Acceso a base de modelo	El que descargues (Llama, Mistral, Qwen)	Bedrock catalog + HF Hub	Vertex Model Garden + HF Hub	Azure ML model catalog + HF Hub

Dónde los nombres engañan. Los fine-tunings managed (Bedrock Custom, Vertex Tuning, AOAI fine-tuning) son caja negra: no eliges hiperparámetros más allá de un puñado, no ves los logs detallados del trainer, no puedes inspeccionar el dataset una vez en su pipeline. El experiment tracking que ofrecen no es comparable al MLflow puesto al lado del trainer, donde puedes capturar cualquier métrica y artefacto. Para escenarios donde operativamente no necesitas inspección esto es liberador; para escenarios de ENS / NIS2 donde tienes que demostrar qué entrenó qué, el caja negra incumple por construcción.

Etapa 3 — Eval

El problema. Validar candidatos antes y después de promotion contra un golden set, con métricas operativas (faithfulness al RAG, tono, format compliance, toxicidad, jailbreak resistance, PII leakage) ejecutadas como gates en CI y como sampling online. Cubierto en el post sobre evals y en el de guardrails.

Stack OSS. Suites de evals: DeepEval, RAGAS (especializada en RAG), Promptfoo (declarativa, ideal para CI), lm-eval-harness (académica), HELM. Evals integrados con tracing: Langfuse Evals, Phoenix Arize OSS. Judges LLM-as-judge: cualquier modelo OSS local; en sistemas serios, dos judges distintos para reducir sesgo. Safety y guardrails: NeMo Guardrails (NVIDIA), Guardrails AI, LlamaGuard + PromptGuard (Meta), ShieldGemma (Google, pesos abiertos), PII detectors tipo Presidio (Microsoft) on-prem.

Equivalentes hyperscaler. En AWS, Bedrock Model Evaluation ofrece evals automáticos (toxicity, accuracy, robustness) y human-in-the-loop, Bedrock Guardrails cubre la capa de safety (denied topics, PII, prompt injection, contextual grounding check), SageMaker Clarify añade bias y explainability sobre modelos generales.

En GCP, Vertex AI Evaluation Service ejecuta evals con métricas automáticas y judge LLM, Vertex AI Model Armor y los safety filters integrados en Gemini API cubren la capa de guardrails. Vertex AI Studio expone Eval interactivo para iteración con prompts.

En Azure, Azure AI Evaluation SDK corre evals offline contra datasets, Azure AI Content Safety cubre safety (Prompt Shields contra jailbreak, Groundedness detection, content categories, PII detection). Todo accesible desde Azure AI Foundry.

Tabla resumen — Etapa Eval.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Suite de evals automáticos	DeepEval, RAGAS, Promptfoo	Bedrock Model Evaluation	Vertex AI Evaluation Service	Azure AI Evaluation SDK
LLM-as-judge	Cualquier modelo OSS	Bedrock judge models	Vertex judge (Gemini)	Azure OpenAI judges
Golden set management	Langfuse datasets, manual	SageMaker Ground Truth datasets	Vertex Datasets	Azure ML Datasets
Guardrails (jailbreak, PII, prompt injection)	NeMo Guardrails, LlamaGuard, Presidio	Bedrock Guardrails	Vertex Model Armor + Gemini safety	Azure AI Content Safety (Prompt Shields, Groundedness)
Eval en CI	Promptfoo + GitHub Actions	Bedrock Eval API + CodeBuild	Vertex Eval API + Cloud Build	Azure AI Eval + Azure Pipelines

Dónde los nombres engañan. Los guardrails gestionados son convenientes pero opacos: las reglas de Bedrock Guardrails son configurables pero la implementación de detección no se inspecciona; lo mismo en Azure AI Content Safety. En OSS, NeMo Guardrails te enseña el grafo de Colang y Presidio te enseña los recognizers — auditables, modificables. Para sistemas regulados donde un auditor pregunta "¿cómo detecta exactamente PII?", el OSS responde con código; el cloud responde con documentación.

Etapa 4 — Deploy

El problema. Servir tokens al usuario final con latencia y throughput predecibles, ratio coste / token decente, soporte de adapters hot-swap, y multi-tenancy si el negocio lo exige. Cubierto en los posts de KV cache, PagedAttention, disaggregated serving, vLLM en K8s, operators LLM y cluster multi-tenant.

Stack OSS. Motor de inferencia: vLLM (PagedAttention, prefix caching, LoRA hot-swap, OpenAI-compatible API) como referencia, TensorRT-LLM para máxima optimización sobre Hopper / Ada, SGLang para cargas con muchas restructuraciones de prompt, TGI (Hugging Face) como alternativa madura, llama.cpp para edge y CPUs, NVIDIA Dynamo para disaggregated serving multinodo en clusters grandes. Orquestación en Kubernetes: KServe, KubeRay, operators dedicados como llm-d, vLLM Production Stack y KAITO. Gateway / control plane: Envoy AI Gateway, LiteLLM Proxy, Portkey AI Gateway, Kong AI Gateway. Triton Inference Server cubre cargas mixtas (LLM + tradicionales) donde un solo backend importa.

Equivalentes hyperscaler. En AWS, dos rutas distintas. La ruta gestionada por modelo es Amazon Bedrock: catálogo de modelos hospedados (Claude, Llama, Mistral, Cohere, Titan), pago por token o Provisioned Throughput con SLA, Bedrock Prompt Caching equivalente conceptual al prefix caching de vLLM, Bedrock Agents y Bedrock Knowledge Bases integrados. La ruta gestionada por infraestructura es SageMaker Endpoints (real-time, async, serverless, batch) con Inference Components para densificar múltiples modelos en una instancia. Hardware propio: AWS Inferentia y Trainium vía el chip Neuron, alternativa a NVIDIA con coste / token mejor en cargas estables si compila tu modelo.

En GCP, Vertex AI Prediction Endpoints corre tus contenedores o modelos del Model Garden, Gemini API vía Vertex AI ofrece los Gemini gestionados, Cloud TPU v5e / v5p / Trillium (v6) como hardware propio competidor de H100 para entrenamiento e inferencia. Para soberanía está Google Distributed Cloud air-gapped, que lleva Vertex AI a un rack on-premise certificable.

En Azure, Azure OpenAI Service sirve modelos OpenAI (GPT-4.1, o-series, GPT-image), Azure ML Managed Online Endpoints corre cualquier modelo (incluido OSS vía contenedor), Azure AI Foundry models absorbió en 2025 el catálogo de modelos abiertos servidos as-a-service. Hardware: Azure ND H100 v5, ND H200 v5, ND GB200 v6 y la apuesta propia Microsoft Maia 100 para inferencia interna.

Tabla resumen — Etapa Deploy.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Motor de inferencia	vLLM, TensorRT-LLM, SGLang, TGI	Bedrock (modelo gestionado), SM Endpoints (tu contenedor)	Vertex Prediction, Gemini API	Azure OpenAI, Azure ML Endpoints
Prefix / prompt caching	vLLM nativo	Bedrock Prompt Caching	Vertex AI context caching	Azure OpenAI prompt caching
Adapter hot-swap (LoRA)	vLLM `--enable-lora`, S-LoRA	Bedrock Custom Models endpoints	Vertex Tuning endpoints	Azure OpenAI fine-tuned deployments
Disaggregated serving	NVIDIA Dynamo, vLLM PD-disagg	— (interno gestionado, no expuesto)	— (interno gestionado, no expuesto)	— (interno gestionado, no expuesto)
Hardware acelerador	NVIDIA H100/H200/B200, AMD MI300	Inferentia, Trainium, NVIDIA	TPU v5/v6, NVIDIA	Maia, NVIDIA
AI Gateway / proxy	Envoy AI Gateway, LiteLLM, Portkey, Kong	API Gateway + Bedrock	Vertex AI + Apigee	Azure API Management + AOAI
Orquestación K8s	KServe, KubeRay, llm-d, KAITO	EKS + SageMaker Operators	GKE + Vertex AI	AKS + KAITO

Dónde los nombres engañan. Bedrock Prompt Caching y Vertex context caching suenan equivalentes al prefix caching de vLLM, pero operativamente son distintos: el cache vive en el plano del hyperscaler, su política de eviction es opaca, su coste se cobra aparte, y no podés ver hit ratio por tenant fácilmente. En vLLM ves el hit ratio en métricas Prometheus y decides la política. Igual con disaggregated serving: los hyperscalers lo implementan internamente para reducir su propio coste de servir, pero no exponen el control de prefill/decode al usuario — si necesitas que tu workload tenga TTFT controlado por separado del TPS, no es palanca disponible.

Etapa 5 — Observe

El problema. Trazas LLM end-to-end con trace_id propagado por todos los componentes, métricas de runtime por tenant, scoring online (judge LLM sobre sampling), drift estadístico, y safety / guardrails monitoring. Cubierto en los posts de tracing AgentSight, MCP observability con OTel y eBPF + drift.

Stack OSS. Estándar base: OpenTelemetry (especificación + collector + SDKs) con las gen_ai semantic conventions que se estabilizaron en 2025. Backends: Tempo o Jaeger para traces, Prometheus para metrics, Loki para logs, Grafana como UI común. Capa LLM-específica: Langfuse (self-hosted con licencia EE opcional) y Phoenix Arize OSS. Capa eBPF para observabilidad de bajo nivel: Pixie, Hubble, y Cilium Tetragon para runtime security. Drift: Evidently AI, NannyML, Alibi Detect.

Equivalentes hyperscaler. En AWS, CloudWatch (metrics + logs) + AWS X-Ray (traces) son la base, CloudWatch Application Signals añade APM con OTel compatible, Amazon Managed Prometheus y Amazon Managed Grafana sirven el plano si quieres mantener Prom + Grafana sin operar. Bedrock logging integrado con CloudWatch y S3. ADOT (AWS Distro for OpenTelemetry) es el collector oficial.

En GCP, Cloud Monitoring + Cloud Logging + Cloud Trace + Cloud Profiler forman el quinteto, todos compatibles con OTel. Vertex AI Model Monitoring ofrece drift detection (feature skew, prediction drift) integrado con runs.

En Azure, Azure Monitor + Application Insights + Log Analytics cubren la pila APM con OTel nativo, Azure ML Model Monitor añade drift y data quality, Azure OpenAI diagnostic logs enriquecen los traces con metadata de tokens y modelo.

Tabla resumen — Etapa Observe.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Traces (OTel)	OTel + Tempo / Jaeger	X-Ray + ADOT, App Signals	Cloud Trace	App Insights + Azure Monitor
Metrics	Prometheus + Grafana	CloudWatch + AMP / AMG	Cloud Monitoring	Azure Monitor Metrics
Logs	Loki, ELK	CloudWatch Logs	Cloud Logging	Log Analytics
LLM-específico (prompt, scores, sessions)	Langfuse, Phoenix Arize OSS	Bedrock logging + CW + custom	Vertex AI tracing + custom	App Insights + AOAI logs + custom
Drift detection	Evidently, NannyML, Alibi Detect	SageMaker Model Monitor	Vertex AI Model Monitoring	Azure ML Model Monitor
eBPF / runtime	Pixie, Hubble, Tetragon	— (no equivalente directo)	GKE Dataplane v2 / Cloud Service Mesh	Azure CNI + Defender for Cloud

Dónde los nombres engañan. Las herramientas APM clásicas del cloud (X-Ray, Cloud Trace, App Insights) no entienden prompt versioning ni adapter id como conceptos nativos. Aceptan los atributos gen_ai.* como dimensions, pero las UIs no priorizan esas vistas. Langfuse y Phoenix sí, porque están diseñadas para LLM. En cloud, el patrón habitual es enviar dual: APM al servicio gestionado para infra + Langfuse / Phoenix self-hosted para el plano LLM. Eso compensa.

Etapa 6 — Retrain + transversales

El problema (Retrain). Cerrar el bucle feedback → triage → dataset enriquecido → adapter nuevo, con cadencia mixta (trimestral + incident-driven). Cubierto en el post de Retrain.

Stack OSS Retrain. Orquestación: Apache Airflow, Prefect, Dagster o Argo Workflows y Kubeflow Pipelines para K8s-native. Feature store cuando aplica: Feast. Annotation y human-in-the-loop: Argilla, Label Studio, Trubrics. Captura de feedback estructurado: tabla Postgres propia + Langfuse scores + Phoenix annotations. Lineage del ciclo cerrado: OpenLineage atando dataset → run → model → deployment → feedback → dataset siguiente.

Equivalentes hyperscaler Retrain. En AWS, SageMaker Pipelines orquesta el ciclo, SageMaker Ground Truth y A2I (Augmented AI) gestionan annotation y HiL, SageMaker Model Monitor dispara alertas que pueden invocar pipelines de retrain. AWS Step Functions sirve como orquestador alternativo más general.

En GCP, Vertex AI Pipelines (basado en Kubeflow Pipelines, compatible) orquesta, Vertex AI Data Labeling Service anota, Vertex AI Feature Store gestiona features, Workflows o Cloud Composer (Airflow gestionado) como alternativas de orquestación.

En Azure, Azure ML Pipelines orquesta, Azure ML Data Labeling anota, Azure ML Feature Store gestiona features.

El problema (transversales: prompt + data versioning). Que prompt_id, prompt_version y dataset_id, dataset_version propaguen por todo el sistema y aparezcan en spans, runs y métricas. Cubiertos en los posts de prompt versioning y data versioning.

Equivalentes prompt versioning. OSS: Langfuse Prompts, MLflow Prompt Registry. AWS: Bedrock Prompt Management (catalog, versiones, labels, A/B testing integrado) y SageMaker Prompt Hub. GCP: Vertex AI Prompt Management dentro de Vertex AI Studio. Azure: Azure AI Foundry Prompt flow y prompt versioning en Azure OpenAI deployments.

Equivalentes data versioning. OSS: DVC + lakeFS (ya cubierto en Data). AWS: S3 Versioning + Lake Formation + Glue Catalog (no son DVC pero juntos cubren parte). GCP: Cloud Storage versioning + Dataplex (idem). Azure: ADLS Gen2 versioning + Purview (idem). El gap real aquí es que ningún hyperscaler ofrece DVC nativamente — la operativa de dataset-as-first-class-citizen sigue requiriendo capa propia.

Tabla resumen — Etapa Retrain + transversales.

Pieza funcional	OSS on-premise	AWS	GCP	Azure
Orquestación pipelines ML	Airflow, Dagster, Argo, Kubeflow	SageMaker Pipelines, Step Functions	Vertex AI Pipelines, Cloud Composer	Azure ML Pipelines
Feature store	Feast	SageMaker Feature Store	Vertex AI Feature Store	Azure ML Feature Store
Annotation / HiL	Argilla, Label Studio	SageMaker Ground Truth, A2I	Vertex Data Labeling	Azure ML Data Labeling
Captura de feedback	Postgres + Langfuse scores	Bedrock + custom + Ground Truth	Vertex + custom	App Insights + custom
Prompt versioning	Langfuse Prompts, MLflow Prompts	Bedrock Prompt Management	Vertex Prompt Management	Azure AI Foundry Prompt flow
Data versioning	DVC + lakeFS + OpenLineage	S3 Versioning + Lake Formation	GCS + Dataplex	ADLS + Purview
Lineage cross-system	OpenLineage + DataHub	SageMaker Lineage Tracking	Dataplex lineage	Purview

El chatbot del post anterior portado a AWS

Para que el catálogo deje de ser abstracto, tomamos el escenario completo del post anterior — el chatbot multi-tenant de soporte para aseguradoras sobre stack OSS on-premise — y lo describimos componente a componente con stack AWS. No es una migración ejecutable; es el mapa de qué desaparece, qué aparece y dónde aparece el lock-in.

El plano de red. Edge LB y WAF: AWS WAF + CloudFront. Ingress al cluster: AWS Load Balancer Controller sobre EKS. Lo que era Cilium BGP + RKE2 se sustituye por EKS con VPC CNI (o Cilium en EKS, posible). El equivalente conceptual de Tetragon es Amazon GuardDuty for EKS + Falco opcional. Lock-in moderado: el control de red se acopla a VPC.

El gateway de chat y la auth. Lo que era una API gateway propia con JWT verificación se materializa como Amazon API Gateway + Amazon Cognito (o IAM Identity Center si es B2B). El AI-aware routing del gateway se cubre con Bedrock + tags por cliente o con AWS API Gateway custom authorizers invocando una Lambda para tenant resolution. Lock-in alto en la capa de identidad si se elige Cognito.

El motor de inferencia. Tres opciones distintas, con trade-off claro.

Bedrock con modelo gestionado (Claude / Llama / Mistral): se elimina toda la operativa de vLLM, K8s Operators, KV cache y disaggregated serving. Se pasa a Provisioned Throughput para garantía de latencia. Se gana time-to-market; se pierde control sobre prefill/decode, sobre adapter LoRA custom (Bedrock acepta fine-tunes Bedrock-managed pero no LoRAs arbitrarios), y se entra en lock-in de modelo (cambiar de Claude a Llama es cambiar de API).
SageMaker Endpoints con tu contenedor vLLM: se mantiene vLLM y sus optimizaciones, pero K8s desaparece y SageMaker lo reemplaza como plano de orquestación. Inference Components permite densificar múltiples adapters. El KV cache, prefix caching y LoRA hot-swap funcionan igual. Lock-in moderado en el SDK SageMaker y en el formato de Inference Components.
EKS con vLLM (la opción minimalista): básicamente el stack OSS pero con EKS en lugar de RKE2 y EBS/EFS en lugar de Ceph. Lock-in bajo, beneficio limitado del cloud.

Data layer. El corpus pasa a S3 con versioning, los embeddings a Amazon OpenSearch Service o a Aurora pgvector. La opción gestionada radical es Bedrock Knowledge Bases: subes documentos a S3, te indexa, te expone un retrieval API. Eliminamos Qdrant, eliminamos pipelines de embedding manuales, eliminamos parte de Kafka + Flink. Pero el control sobre reranking custom, ACL fino por chunk y la posibilidad de re-embeber con un encoder propio nuevo desaparece — Bedrock KB usa los embedders de Titan o Cohere disponibles en Bedrock, y cambiarlos es cambiar todo el índice. Compliance ENS: hay que validar que los buckets y el índice viven en regiones EU y que el modelo de embedding también.

Stream + CDC. Kafka + Debezium se reemplaza por MSK + MSK Connect o por Kinesis + DMS. Schema Registry: Glue Schema Registry. Los eventos siguen siendo equivalentes funcionalmente. Lock-in moderado si vas a Kinesis (Kinesis no es Kafka), bajo si vas a MSK (compatibilidad Kafka).

Data versioning. Aquí el gap es claro. S3 Versioning + Lake Formation + Glue Catalog no es DVC. Para conservar la disciplina del post anterior — (dataset_id, dataset_version, sha256_hash) propagado como input artifact al trainer — se puede mantener DVC sobre S3 (DVC funciona perfectamente con S3 como remote) o aceptar la limitación y registrar manualmente el lineage en SageMaker Lineage Tracking. La primera opción mantiene la operativa; la segunda acepta degradación.

Etapa Tune. El adapter LoRA customer_support_v7 se entrena con SageMaker Training Jobs sobre instancias ml.p5.48xlarge (8× H100), usando un contenedor HuggingFace + PEFT estándar. MLflow gestionado por SageMaker o MLflow propio en EC2 cubren el tracking. Alternativa: si se acepta el caja negra, Bedrock Custom Models con un dataset en S3 produce un modelo Bedrock fine-tuneado sin instanciar GPU manualmente, a cambio de no poder inspeccionar el run.

Etapa Eval. Promptfoo + RAGAS en CI corre igual sobre CodeBuild. Bedrock Model Evaluation sustituye buena parte de la suite de evals automáticos. Bedrock Guardrails sustituye NeMo Guardrails + Presidio + LlamaGuard, con la pérdida de transparencia comentada antes.

Etapa Deploy. Si se eligió Bedrock como motor, esta etapa se desvanece — Bedrock sirve. Si se eligió SageMaker Endpoints + vLLM, KServe se sustituye por SageMaker Operators (o se conserva KServe sobre EKS). El AI Gateway que en OSS era Envoy AI Gateway o LiteLLM pasa a ser API Gateway + Bedrock o API Gateway + Lambda + SageMaker.

Etapa Observe. OTel Collector sigue siendo el estándar. Trazas a AWS X-Ray + CloudWatch Application Signals. Métricas a Amazon Managed Prometheus. Logs a CloudWatch Logs + opcional OpenSearch para búsqueda. Langfuse se hospeda en ECS Fargate o EKS porque el cloud no tiene equivalente nativo del prompt + traces + scores integrado. Drift: SageMaker Model Monitor sustituye Evidently / NannyML. eBPF (Pixie / Hubble / Tetragon) no tiene equivalente directo en AWS gestionado — Falco o instalación de Tetragon en EKS sigue siendo la ruta.

Etapa Retrain. SageMaker Pipelines orquesta el ciclo trimestral. SageMaker Ground Truth + A2I sustituyen Argilla. El feedback_signals en Postgres se mantiene tal cual (RDS Postgres) o se traslada a DynamoDB para escalas grandes.

Cuánto pesa el lock-in. El componente con lock-in más alto es Bedrock + Bedrock Knowledge Bases + Bedrock Guardrails: salir de ahí requiere reescribir el plano de inferencia y reindexar todo el RAG. Le sigue SageMaker SDK (Pipelines, Endpoints, Training) — salir cuesta pero es reescribir scripts, no datos. Datos en S3 son portables (S3 → MinIO con rclone funciona). El observabilidad OTel es portable casi sin coste si se mantiene el collector como abstracción. El gateway de auth es el otro punto de lock-in alto si va Cognito.

Qué se gana. Reducción dramática de operativa de infraestructura GPU, parches K8s, gestión de drivers CUDA, dimensionamiento de prefill/decode, gestión de Ceph / MinIO. Curva de arranque muy corta: una request servida en menos de un sprint vs varias semanas de bring-up del stack OSS. SLAs explícitos del proveedor.

Qué se pierde. Soberanía contractual de datos (los datos siguen en regiones EU si así se configura, pero el operador es un tercero estadounidense bajo Cloud Act). Visibilidad de la pila completa (Bedrock es caja negra desde el modelo hacia abajo). Independencia de roadmap (la decisión de discontinuar un modelo, subir precios o cambiar guardrails no la controla el cliente). Optimización fina del coste por token (las palancas son las que el proveedor expone). Para clientes ENS bajo declaración ALTA o NIS2 categoría esencial, varios de estos puntos son incumplimiento, no preferencia.

Tabla maestra: el catálogo paralelo entero

Etapa / componente	OSS on-premise (referencia del blog)	AWS	GCP	Azure
Data	DVC + lakeFS + MinIO + Qdrant + Kafka + Debezium	S3 + Lake Formation + OpenSearch / Aurora pgvector + MSK + DMS	GCS + Dataplex + Vertex Vector Search + Pub/Sub + Datastream	ADLS Gen2 + Purview + Azure AI Search + Event Hubs + ADF
Data versioning (transv.)	DVC + lakeFS + OpenLineage	S3 Versioning + Lake Formation + Glue Catalog	GCS Versioning + Dataplex lineage	ADLS versioning + Purview
Tune	HF Transformers + PEFT + bitsandbytes + MLflow + Ray/Kubeflow	SageMaker Training + HyperPod + Bedrock Custom + SM Experiments	Vertex AI Training + Vertex Tuning + Vertex Experiments	Azure ML Training + Azure OpenAI fine-tuning + Azure ML + MLflow
Eval	DeepEval + RAGAS + Promptfoo + Langfuse Evals + NeMo Guardrails	Bedrock Model Evaluation + Bedrock Guardrails + SageMaker Clarify	Vertex AI Evaluation Service + Model Armor + Gemini safety	Azure AI Evaluation SDK + Content Safety (Prompt Shields, Groundedness)
Deploy	vLLM + KServe + LLM Operators + Envoy AI Gateway	Bedrock + SageMaker Endpoints (+ Inferentia / Trainium)	Vertex AI Prediction + Gemini API (+ TPU)	Azure OpenAI + Azure ML Endpoints (+ Maia)
Observe	OTel + Tempo + Prometheus + Loki + Langfuse + Phoenix + Hubble	CloudWatch + X-Ray + ADOT + AMP/AMG + SM Model Monitor	Cloud Monitoring + Cloud Trace + Vertex Model Monitoring	Azure Monitor + App Insights + Azure ML Model Monitor
Retrain	Airflow / Argo / Kubeflow Pipelines + Argilla + Feast	SageMaker Pipelines + Ground Truth + A2I + SM Feature Store	Vertex AI Pipelines + Data Labeling + Vertex Feature Store	Azure ML Pipelines + Data Labeling + Azure ML Feature Store
Prompt versioning (transv.)	Langfuse Prompts + MLflow Prompt Registry	Bedrock Prompt Management + SM Prompt Hub	Vertex AI Prompt Management	Azure AI Foundry Prompt flow

Cuándo elegir cada lado — la decisión real

La pregunta correcta no es "¿OSS o cloud?". Es por etapa.

El lado OSS gana por defecto cuando hay:

Datos sometidos a ENS categoría ALTA, NIS2 sectores esenciales o equivalentes (datos sanitarios identificables, banca regulada, infra crítica). Aquí la trazabilidad del proveedor y el contrato de procesamiento no son negociables; usar un servicio cuyo operador esté sometido a Cloud Act, FISA 702 o equivalente compromete la base legal.
Requisitos de inspección auditable del modelo, los guardrails y el pipeline completo. Si un regulador pregunta "¿cómo detecta exactamente PII?" y la respuesta acabable en código abierto es obligatoria.
Volúmenes grandes con cargas estables. Por encima de cierto umbral de tokens/mes, el coste de Bedrock / AOAI / Vertex se aleja del coste amortizado de un cluster GPU propio. El umbral depende de carga, pero típicamente está entre 5-50 mil millones de tokens/mes para modelos del rango Llama 70B.
Independencia de roadmap es prioritaria. El día que el proveedor discontinúa un modelo o sube el precio un 40%, la organización tiene que poder ignorarlo.

El lado hyperscaler gana por defecto cuando hay:

Time-to-market crítico, MVP en semanas. La operativa del stack OSS pesa demasiado para un proyecto que aún no ha probado producto-mercado.
Equipo pequeño sin SREs / MLEs especializados en inferencia GPU. La operativa de KServe + vLLM + KV cache + multi-tenant no es trivial; si el equipo no puede sostenerla, hospedar es el camino.
Cargas variables / spikes impredecibles. Bedrock on-demand y SageMaker serverless cobran lo que usas; un cluster propio paga la GPU esté ocupada o no.
Necesidad de modelos propietarios específicos (Claude, GPT-4.1, Gemini Pro) que no tienen equivalente OSS aceptable para el caso.

Las etapas mixtas son frecuentes y razonables. En la práctica, un patrón común en 2026 es: data, observe y retrain en OSS self-hosted (lineage y soberanía), tune en OSS sobre cluster propio, eval en OSS + guardrails gestionados según safety profile, deploy gestionado para modelos propietarios y self-hosted para modelos abiertos. La pregunta a hacerse para cada etapa es: “si el proveedor sube precios un 50% o discontinúa un componente mañana, ¿cuánto cuesta moverlo?”. El catálogo paralelo de este post da la respuesta para cada caja.

Lo que no hemos cubierto (todavía)

Quedan piezas merecedoras de su propio post:

OpenAI / Anthropic API directamente (no a través de Bedrock o AOAI): otro nivel de gestionado, otro contrato.
Híbridos serios: Outposts AWS, Distributed Cloud GCP, Azure Stack HCI / Azure Local — el hyperscaler en tu sala.
Cost accounting por tenant comparado OSS vs cloud: cómo se hace la factura y dónde se rompe la atribución.
Migración real OSS → cloud o cloud → OSS: pasos, scripts, gotchas.
Soberanía europea concreta: GAIA-X, EuroHPC, oferta de cloud europeo (OVHcloud, Scaleway, IONOS, Aruba), comparativa con los tres grandes para casos ENS / NIS2.
AWS Inferentia / Trainium, GCP TPU v6 Trillium, Azure Maia: chips propios y cómo cambian el cálculo de coste / token.

Ver también

Anatomía de una petición LLM en producción — el recorrido forense de una request por las seis etapas, hilo del que este post hace el corte vertical.
El catálogo OSS para LLMOps en seis etapas: ficha por ficha — el zoom in al lado open source de la tabla maestra de este post: ficha de ~150 palabras por herramienta OSS core (vLLM, Langfuse, DVC, Qdrant, Airflow, NeMo Guardrails, Presidio…), licencia y gobierno, matriz de decisión por etapa y diagrama del stack OSS conectado.
El pipeline LLMOps de seis etapas — el mapa maestro al que este catálogo es complemento.
MLOps específico para LLMs en 2026 — contexto general sobre por qué LLMOps no es MLOps clásico.
Data versioning con DVC y lakeFS — el deep-dive del transversal Data.
Prompt versioning con Langfuse y MLflow — el deep-dive del transversal Prompt.
Fine-tuning continuo en producción — Tune detallado.
Evals: la capa después del tracing — Eval detallado.
Guardrails y safety en LLMs — la capa de safety en detalle.
KV cache · PagedAttention · Disaggregated serving — Deploy desde dentro.
vLLM en Kubernetes · Operators LLM en K8s · Cluster GPU multi-tenant — Deploy operativo.
AgentSight tracing LLM · MCP observability con OTel · eBPF + drift — Observe en sus capas.
Retrain: cerrar el bucle feedback → dataset → adapter — Retrain detallado.

Referencias

vLLM documentation y vLLM Production Stack — motor de inferencia OSS de referencia.
Amazon Bedrock documentation — catálogo de modelos gestionados AWS, Knowledge Bases, Guardrails y Prompt Management.
Amazon SageMaker AI — training, endpoints, pipelines, model monitoring.
Google Vertex AI documentation — training, prediction, evaluation, model monitoring.
Azure AI Foundry documentation — plano unificado de Microsoft para AI applications.
Azure OpenAI Service documentation — modelos OpenAI hospedados en Azure.
OpenTelemetry GenAI semantic conventions — el estándar que cose la observabilidad a través de las fronteras OSS / cloud.
Langfuse documentation y Arize Phoenix — LLM observability OSS de referencia.
DVC y lakeFS — data versioning OSS.
NeMo Guardrails — safety + dialog policy OSS.
ENS (Esquema Nacional de Seguridad) y NIS2 (Network and Information Security Directive 2) — los marcos de cumplimiento que tienen la última palabra en la elección OSS vs cloud para clientes regulados de la UE.