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

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

TL;DR

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

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

La analogía: el oficio del SRE redibujado

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

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

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

Las siete diferencias estructurales entre LLMOps y MLOps tradicional

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

1. Salidas no-determinísticas

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

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

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

2. Métricas behavior, no statistical accuracy

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

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

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

3. El modelo es dependencia externa, no asset interno

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

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

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

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

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

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

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

5. Coste por inferencia, no por training

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

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

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

6. Infra GPU-pesada con primitivas específicas

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

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

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

7. RLHF y feedback humano como ciudadano de primera

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

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

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

Por qué Gartner predice 50%+ de fracasos

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

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

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

El pipeline LLMOps de seis etapas

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

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

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

Etapa 1 — Data

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

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

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

Etapa 2 — Tune

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

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

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

Etapa 3 — Eval

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

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

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

Etapa 4 — Deploy

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

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

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

Etapa 5 — Observe

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

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

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

Etapa 6 — Retrain

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

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

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

Las tres modalidades de “preparar el modelo”

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

Fine-tuning

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

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

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

RAG (Retrieval-Augmented Generation)

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

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

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

Agent training

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

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

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

Matriz de decisión

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

El veredicto 2026: hybrid es el default

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

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

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

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

El panorama de herramientas 2026

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

Experiment tracking y model registry

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

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

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

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

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

Dataset versioning

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

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

Prompt versioning y observability

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

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

Pipeline orchestration

Para los pasos del pipeline LLMOps, las opciones dominantes:

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

Serving

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

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

Evals y guardrails

Cubierto en Evals y Guardrails. Resumen ultra-corto:

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

Drift detection y observability

Cubierto en el post de cierre eBPF. Resumen:

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

La tabla de stack típico 2026

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

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

La realidad operativa: nadie usa una sola herramienta

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

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

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

Trampas operativas comunes

Tratar el prompt como texto en código

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

Saltarse el dataset versioning

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

Mezclar capas en el mismo pipeline

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

Tracking sin estructura

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

Evals que no bloquean nada

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

Sin retrain cadence

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

Vendor lock-in invisible

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

Lo que viene en los siguientes posts de la serie

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

Referencias

LLMOps vs MLOps:

Herramientas:

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

Comparativas 2026:

RAG vs Fine-Tuning:

Cross-references (las tres series previas):

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

Fine-Tuning on lo0 — Blog Técnico