eBPF en inferencia local y detección estadística de drift: el cierre del ciclo de observabilidad LLM en 2026

TL;DR

Tracing, evals, guardrails, MCP observability: las capas que ya hemos cubierto ven qué está pasando ahora mismo. Lo que no ven es lo que cambia silenciosamente: el agente que la semana pasada respondía bien y esta semana, sin que nadie haya tocado nada, responde algo peor. Lo que no ven tampoco es la mecánica fina de la inferencia local: por qué un llama.cpp en un edge device tarda 200 ms cuando debería tardar 100, qué función del runtime concreta es el cuello. Este post cierra las dos series de la semana con las dos capas que faltaban: eBPF aplicado a inferencia local (uprobes en llama.cpp, vLLM, libcudart.so, hardware perf counters integrados, con <4% de overhead — formalizado en el paper ProfInfer 2026 que es a inferencia local lo que Hubble es a la red) y análisis estadístico de flows de agentes para detectar drift antes de que tu usuario lo note (KS, PSI, MMD, embedding-space clustering, con Evidently AI, NannyML y WhyLabs como herramientas dominantes). Las tres tipologías de drift LLM en 2026 — prompt drift, model drift, eval-score drift — exigen tests distintos. El stack completo —tracing, evals, guardrails, MCP observability, eBPF observability, drift detection— forma el bucle que cualquier sistema agentic serio necesita para operar con SLA real, no con esperanza.

Este post cierra dos series: la serie post-tracing (Evals, Guardrails, MCP observability) y la serie eBPF (eBPF de cero a Cilium, Tetragon, Hubble, AgentSight). Junta los dos hilos: eBPF aplicado al motor de inferencia local + análisis estadístico de los flows que todas las capas producen.

La analogía: el cardiograma del agente

Un médico que sólo mira síntomas agudos —el paciente llega con fiebre alta, hay que actuar— está haciendo medicina reactiva. Para hacer medicina preventiva, necesita series temporales: la tensión arterial cada año, el colesterol cada seis meses, el ECG cuando hay sospecha. No es información de “ahora mismo”, es información sobre cómo evoluciona algo que debería estar estable. Cuando una serie temporal se desvía de su línea base, hay que investigar antes de que sea fiebre alta.

Las capas de observabilidad LLM que llevamos vistas son medicina reactiva: tracing te dice qué pasó en una conversación concreta; evals te dice si esa conversación fue buena; guardrails te dice si había una amenaza específica; MCP observability te dice qué tools se invocaron y cómo. Todas miran eventos, no tendencias.

Drift detection es la medicina preventiva. Mira series temporales —de embeddings de prompts, de scores de evaluación, de distribuciones de tokens generados— y dispara alertas cuando algo se aleja de su normalidad. No te dice “esta respuesta es mala”; te dice “la distribución de prompts de las últimas 6 horas no se parece a la distribución del último mes”. Ahí decides si investigar.

Y la otra mitad del post —eBPF en inferencia local— es el equivalente al resonador magnético: cuando ya sabes que hay un problema, te permite ver el interior del modelo a una resolución que ningún wrapper externo da. Ver qué función concreta del runtime tarda, qué kernel CUDA es el cuello, cómo se mueven los tokens en los buffers internos antes de salir al cliente.

Las dos juntas cierran el ciclo: las series temporales detectan que algo va mal, el resonador localiza dónde.

Parte 1 — eBPF aplicado a inferencia local

Por qué la inferencia local cambia el juego

Cuando el LLM corre localmente —vLLM en un nodo Kubernetes, llama.cpp en un edge device, Ollama en una workstation, MLX en macOS— y no detrás de una API externa, la observabilidad cambia de forma:

• Controlas el binario: puedes adjuntar hooks que de otra manera serían imposibles.
• Los buffers internos existen en RAM accesible: el stream de tokens-output, los logits, las cachés KV, las estructuras de scheduler están ahí, en direcciones que un uprobe puede leer.
• No hay cable que esnifar: la analogía de AgentSight con SSL hooks no aplica porque no hay TLS — el modelo te responde con un retorno de función en proceso, no con una respuesta HTTPS.
• La distancia entre kernel y modelo es mínima: los kernels CUDA que ejecutan la atención están a una syscall de profundidad; eBPF puede observar ambos lados de esa frontera con el mismo trazador.

Esto abre una clase de observabilidad que con LLM-as-a-service (API de Anthropic, OpenAI, Vertex) es estructuralmente imposible. Para apps que sirven inferencia on-premise o on-edge — un cluster de inference, un dispositivo móvil, un servidor RTX 4090 en el rack — es una capa nueva.

ProfInfer: el paper que formaliza el patrón

ProfInfer (arxiv 2601.20755, 2026) es la pieza académica de referencia que sistematiza lo que el ecosistema venía haciendo de manera ad-hoc. El subtítulo del paper lo dice todo: An eBPF-based Fine-Grained LLM Inference Profiler.

Lo que propone:

• Atachar uprobes dinámicamente a funciones runtime de motores como llama.cpp (y por extensión vLLM, Ollama). No recompila, no modifica el código fuente. Es como bpftrace para inferencia LLM.
• Combinar runtime events con hardware performance counters. Una uprobe te dice cuándo se ejecuta llama_decode; un hardware counter te dice cuántas instrucciones flotantes se ejecutaron mientras estaba dentro. La correlación entre ambas es lo que da la resolución fina.
• <4% overhead medido en cargas reales. Es coste de producción.
• Visualizaciones en tres vistas: operadores (qué operaciones tensoriales se ejecutaron), grafos (cómo se relacionan), timelines (cuándo).

El paper se enfoca especialmente en modelos en plataformas móviles (Llama servido en un Pixel o iPhone), donde la observabilidad clásica con Prometheus y métricas exportadas casi no existe. Pero el patrón aplica a cualquier inferencia local.

Dónde hookear: el mapa por motor

Vamos al detalle de los hooks. Las funciones objetivo varían por motor:

llama.cpp

llama.cpp es C++ puro, símbolos visibles en el binario. Los hooks típicos:

• llama_decode: la función que ejecuta una pasada de inferencia (procesa el batch actual). Spans para latencia por iteration, tokens procesados.
• llama_token_to_piece: convierte un token ID a texto. Hook aquí captura el stream de tokens generados antes de devolver al caller. Es el equivalente local a las uprobes de SSL: ves la salida del modelo sin que llegue siquiera al consumidor.
• llama_get_logits: lee los logits del último decode. Si quieres registrar las probabilidades del modelo (no solo el token elegido), aquí.
• ggml_compute_forward_* (varias funciones): los kernels de operaciones (matmul, attention, layernorm). Hooks para profiling por operación.
• ggml_backend_*: las funciones del backend (CPU, Metal, CUDA, ROCm). Hooks aquí desglosan el coste por dispositivo.

Ejemplo con bpftrace:

# Latencia y count de llama_decode
bpftrace -e '
uprobe:/path/to/llama-server:llama_decode {
    @start[tid] = nsecs;
}
uretprobe:/path/to/llama-server:llama_decode /@start[tid]/ {
    @decode_lat = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}
'

Salida: histograma de latencias de decode en microsegundos. Cero modificación al binario.

vLLM

vLLM es Python en su mayor parte. Los símbolos C/CUDA están en sus extensiones nativas (vllm._C, vllm._moe_C). Los hooks típicos:

• uprobes en vllm._C.* para operadores custom (paged attention kernel, sampling kernel).
• uprobes en libcudart.so y libcuda.so para capturar cudaMalloc, cudaLaunchKernel, cudaMemcpy. Sirve para mapear costes de transferencias host↔device y de lanzamientos de kernels.
• Tracepoints Python con bpftrace sobre usdt puntos: vLLM no expone tracepoints estáticos nativos, pero se pueden colocar con USDT (dtrace style) en lugares estratégicos del scheduler.

vLLM expone además métricas Prometheus nativas (vllm:num_requests_running, vllm:gpu_cache_usage_perc, etc.). El valor añadido del enfoque eBPF es bajar de las métricas del scheduler a las funciones individuales: cuando una request es lenta, ver si fue prefill, decode, scheduler overhead, transferencia o sincronización.

CUDA en general

Independiente del motor, las uprobes en libcudart.so capturan toda la actividad CUDA del proceso:

• cudaMalloc(size) → tracking de allocations en device memory.
• cudaLaunchKernel(func, ...) → spans por cada lanzamiento de kernel.
• cudaMemcpyAsync(dst, src, size, kind) → transferencias host↔device.
• cudaStreamSynchronize(stream) → puntos de sincronización (donde el host espera al device).

Esto te da una timeline completa de actividad CUDA sin necesidad de NVIDIA Nsight Systems (que es excelente pero pesado y orientado a desarrollo, no a producción continua).

Hardware counters: la otra mitad

eBPF puede leer performance counters del PMU (Performance Monitoring Unit) del CPU/GPU. Esto incluye instrucciones ejecutadas, cache misses, branch mispredictions y, en GPUs con soporte, FLOPS, ocupación de SM, ancho de banda HBM.

Combinar:

• uprobe: “se ejecutó llama_decode desde T1 a T2 con tokens=4”.
• perf counter: “durante esa ventana, cache misses L2 = 15000, instrucciones = 2.3 millones”.

Permite responder: ¿por qué tarda? ¿es memory-bound (muchos cache misses), compute-bound (todas las instrucciones en FPU), bandwidth-bound (mucho movimiento de datos)? Estado del arte para profiling profesional.

Comparativa con AgentSight

Hay dos productos eBPF para LLMs hoy con foco distinto:

• AgentSight (cubierto en la serie eBPF): observa agentes que llaman a APIs externas. Hookea SSL para ver el plaintext de las llamadas HTTPS al LLM remoto, más stdio para servers MCP locales. Visión cliente.
• ProfInfer / patrón de eBPF en inferencia local: observa el motor que ejecuta el modelo localmente. Hookea las funciones internas del motor (llama.cpp, vLLM) y la capa CUDA. Visión servidor (interno).

Son complementarios. Si tu agente usa Claude API + tu propio vLLM local con Llama 3 para tareas específicas, AgentSight ve lo primero, eBPF/ProfInfer ve lo segundo. Si todo es local, dominio claramente del segundo. Si todo es API externa, del primero.

Casos de uso de eBPF en inferencia local

Tres casos donde es la herramienta correcta:

Profiling fino para optimización: tu vLLM tarda 50ms más por token de lo esperado. Con eBPF + hardware counters localizas en qué kernel concreto. Antes esto requería Nsight Systems en una sesión de desarrollo; ahora es continuo en producción.

Token-level observability sin modificar el motor: capturar el stream de tokens generados antes de devolverlos al cliente. Útil para auditoría, para drift detection sobre los outputs, para tracing local sin pasar por instrumentación del wrapping.

Detección de degradación específica: una versión nueva de vLLM mete una regresión sutil en el paged attention. Con baselines de perf counters, detectas el cambio incluso si la métrica externa (tokens/sec) parece igual.

Parte 2 — Análisis estadístico de flows: detectar drift

Pasamos al otro lado del problema: las series temporales.

Por qué tracing, evals y guardrails no detectan drift

Las capas que ya hemos visto operan sobre eventos individuales:

• Tracing: una traza de una conversación.
• Evals: un score de una respuesta.
• Guardrails: un veredicto sobre un prompt o respuesta.
• MCP observability: spans de una invocación de tool.

Cada uno responde a una pregunta puntual ("¿está bien esto?"). Ninguno responde a la pregunta de evolución ("¿está cambiando algo a lo largo del tiempo?").

El problema operacional: drift es invisible en eventos individuales. Si el score medio de eval baja de 0.92 a 0.85 a lo largo de tres semanas, ninguna evaluación individual marcará alarma —todas siguen siendo “razonables”—. Lo que cambia es la distribución. Y eso solo se ve mirando muchas evaluaciones agregadas en el tiempo.

Las tres tipologías de drift LLM en 2026

FutureAGI las consolida así, y la industria está convergiendo en este vocabulario:

1. Prompt drift: alguien actualiza el prompt sistema y los efectos secundarios rompen casos que antes funcionaban. Casi siempre intencional pero con consecuencias no anticipadas. Detección: comparar distribuciones de respuestas antes y después del cambio, monitorizar eval scores por versión de prompt (linked en Langfuse, ver post de AgentSight donde cubrimos prompt management).

2. Model drift: el proveedor (OpenAI, Anthropic) actualiza el modelo sin avisar. El mismo prompt produce respuestas con tonalidad ligeramente distinta, calidad similar pero diferente, o degradación en algún subset. Detección: comparar embeddings de respuestas de hoy con baseline; monitorizar rubric scores; alertar si la varianza intra-modelo crece.

3. Eval-score drift: la rolling mean de tus métricas de eval (faithfulness, answer relevancy, custom rubrics) tiende a la baja. Causa raíz puede ser cualquiera de las anteriores o un cambio en el mix de usuarios. Detección: alertas sobre tendencias de las series de evals.

A estas tres se suma una cuarta más sutil:

4. Persona drift / user mix shift: la población de usuarios que usa el sistema cambia. No es que el modelo o el prompt empeoraron; es que los nuevos usuarios hacen preguntas distintas y el sistema, aunque sigue siendo igual de bueno en lo que era bueno, falla en lo nuevo. Detección: embedding clustering de prompts, monitorizar aparición de clusters nuevos o crecimiento de uno minoritario.

El concepto técnico clave: embedding-space shift

Stack Pulsar lo dice claro: en LLMs, el drift se mide mejor en el espacio de embeddings. Las distancias clásicas en espacio de tokens no capturan semántica fina; en embedding space sí.

El pipeline canónico:

1. Establecer baseline: durante un periodo estable (digamos las primeras dos semanas tras un release), captura una muestra grande de embeddings de prompts y respuestas.
2. Monitorización continua: cada hora o cada día, captura una nueva muestra del tráfico de producción.
3. Comparar distribuciones: aplica un test estadístico que compare la distribución actual con la baseline en el espacio de embeddings.
4. Alertar: si la divergencia supera un umbral, dispara una alerta y un workflow de investigación.

Como bonus, monitorizar clusters: si tu baseline tiene 5 clusters de prompts (preguntas técnicas, soporte general, ventas, etc.) y de pronto aparece un sexto cluster que no estaba, lo más probable es que un nuevo segmento de usuarios haya llegado.

Tests estadísticos: KS, PSI, MMD

Tres tests que cualquier sistema de drift usa, cada uno con su lugar:

Kolmogorov-Smirnov (KS): no-paramétrico. Calcula la máxima distancia entre dos CDFs empíricas. Devuelve un statistic y un p-value. Ventaja: muy sensible a cambios sutiles, especialmente en colas. Desventaja: con datasets grandes, “demasiado sensible” — dispara alarmas por cambios reales pero clínicamente irrelevantes.

Population Stability Index (PSI): bineas la distribución de referencia y la actual, luego sumas (p_actual - p_ref) × log(p_actual / p_ref) sobre los bines. Interpretación canónica: PSI < 0.1 estable, 0.1-0.25 drift suave, > 0.25 drift significativo. Ventaja: interpretable, threshold-based, tradición de uso en credit scoring (Capital One, Goldman Sachs). Desventaja: menos sensible que KS — pierde drift en colas.

Maximum Mean Discrepancy (MMD): mide la divergencia entre dos distribuciones embebiendo cada una en un espacio de Hilbert vía kernel. Sirve para distribuciones multivariadas complejas (embeddings de alta dimensión). Ventaja: la única que escala razonablemente a embeddings de 768/1024/4096 dimensiones. Desventaja: más compleja de interpretar.

La práctica recomendada en 2026:

• PSI para features simples (longitud de prompt, tokens, número de tools invocadas).
• KS para features continuos donde quieras alta sensibilidad.
• MMD para embeddings (espacios de alta dimensión).

Análisis de Evidently en datasets reales mostró que KS detecta drift 6+ horas antes que PSI en algunos incidentes. La consecuencia operativa: usa KS para early warning, PSI para confirmación con threshold interpretable.

Herramientas 2026

Tres productos dominan el campo:

Evidently AI

Evidently es open-source (Apache 2.0), Python-first. Su valor:

• Drift reports HTML: generas un report comparando dos datasets (referencia vs actual) y obtienes un archivo HTML con todos los tests estadísticos, visualizaciones, conclusiones. Sin servidor, sin infra; un fichero compartible.
• Soporte de LLM nativo: además de tabular, soporta texto. Compute embeddings, aplica los tests adecuados.
• 100+ métricas en la suite. Te lo cubre todo desde un único framework.
• Integración con MLflow y kube: workflows de CI con reports en cada release.

from evidently import Report
from evidently.metrics import DataDriftPreset

ref = load_baseline_dataset()  # prompts de la semana pasada
cur = load_current_dataset()   # prompts de la última hora

report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=ref, current_data=cur)
report.save_html("drift_report.html")

Cuando esta funcionalidad detecta drift, además te dice qué columna y qué test disparó.

NannyML

NannyML tiene un foco distinto: estimar el rendimiento del modelo cuando no tienes ground truth. Las técnicas:

• CBPE (Confidence-Based Performance Estimation): estima accuracy usando la confianza del modelo en sus predicciones.
• DLE (Direct Loss Estimation): estima la pérdida directamente.

Útil cuando tu app LLM no tiene feedback humano inmediato pero quieres saber si su calidad ha bajado. Apache 2.0, Python.

WhyLabs

WhyLabs es comercial (con whylogs como librería OSS subyacente), enfocada a producción enterprise:

• SaaS managed con SOC 2 Type 2 y HIPAA compliance.
• Real-time monitoring vía ingesta continua de logs.
• Embedding tracking: soporte nativo para distribuciones de embeddings, no solo features tabulares.
• Token probability shifts: monitorea la distribución de probabilidades de tokens generados, no solo metadata.

Para empresas regulated que no quieren operar su propia plataforma de drift detection, es la opción de menos fricción.

Otras menciones

Arize Phoenix (visto en post de Evals) incluye drift detection como módulo. Galileo tiene productos comerciales especializados en LLM monitoring. Fiddler AI y Alibi Detect (Seldon) son alternativas más generalistas que también cubren LLM.

Parte 3 — El stack completo: cómo encaja todo

Recapitulemos las capas que las dos series han cubierto, ordenadas de más cercana al request individual a más cercana a la tendencia agregada:

EVENTOS individuales                          TENDENCIAS agregadas
       │                                                  │
  Tracing  ──→  Evals  ──→  Guardrails  ──→  MCP obs  ──→  Drift detection
       │                                                  │
  AgentSight ──→ Tetragon ──→ Hubble  ──→  eBPF on-device
       │                                                  │
  (qué pasa)                                       (qué cambia)

Cada capa responde una pregunta distinta:

Ninguna sustituye a las demás. La cobertura completa requiere las siete. La operación práctica:

1. Capas 1-3 (tracing, evals, guardrails) son obligatorias desde el día uno. Cualquier app LLM en producción que no las tenga está pilotando a ciegas.
2. Capa 4 (MCP) se vuelve obligatoria cuando hay agentes con tools, que es la mayoría en 2026.
3. Capas 5-6 (eBPF) se vuelven valiosas cuando la escala justifica el coste de operación (>10 servicios, >100 pods de inferencia).
4. Capa 7 (drift) es la que más se descuida y más caro sale ignorar: se cubre con un día de trabajo para tener el pipeline básico y ahorra semanas de incidencias futuras.

Patrón operativo de drift en 2026

La receta mínima que cualquier app LLM seria debería tener:

Paso 1 — Establecer baseline

Durante un periodo estable post-release (2 semanas mínimo), almacena:

• Embeddings de todos los prompts (vector + metadata: timestamp, user_segment, tenant).
• Embeddings de las respuestas.
• Scores de evals automatizados sobre muestra (eg 5-10% del tráfico con G-Eval).
• Distribución de tools invocadas (qué tools, con qué argumentos típicos, con qué frecuencia).

Storage: cualquier vector store + relational. Cardinalidad razonable a la escala que tengas.

Paso 2 — Pipeline continuo de comparación

Cada hora (o cada día según escala):

• Toma la muestra del periodo actual (última hora).
• Aplica los tests estadísticos contra el baseline:
  • PSI sobre features simples (longitud prompt, tokens, num tools).
  • KS sobre features continuos (latencia, score).
  • MMD sobre embeddings.
• Genera un drift report (Evidently lo hace en una línea de Python).

Paso 3 — Alertas y workflow de investigación

Configurar thresholds y rutas:

• PSI > 0.25 sobre tokens consumidos: alerta moderada (puede ser legítimo, investigar segmentos).
• MMD significativo sobre embeddings de prompts: alerta alta (cambio en user mix o ataque coordinado).
• Eval rubric score baja >5% en rolling 7d: alerta crítica.
• Nuevo cluster en embedding space del 10%+ del tráfico: workflow de revisión (puede ser nuevo segmento legítimo o anomalía).

Cada alerta debe llevar a un dashboard de drill-down con los segmentos afectados, no a un Slack message vacío. La regla operativa: si alguien no puede investigar el alert en <5 minutos, no se va a investigar.

Paso 4 — Refresh de baseline

El baseline no es estático. Cada N semanas, refresca el baseline incorporando lo “estable nuevo”. Si en 3 meses el patrón de uso ha cambiado legítimamente (más usuarios internacionales, idiomas nuevos), el baseline debe reflejarlo. La cadencia típica: trimestral.

Trampas operativas

Baseline contaminado

Tomas el baseline de un periodo que ya contenía el problema en germen. Resultado: el baseline incluye el comportamiento malo, los tests no disparan nunca. Solución: verificar el baseline contra una segunda muestra independiente (por ejemplo, la primera semana vs la segunda) antes de bendecirlo.

Threshold demasiado bajo

PSI > 0.05 dispara constantemente. Tu equipo aprende a ignorar las alertas. Calibrar thresholds según el ruido natural de tu sistema: corre el sistema con baseline + muestras semanales sucesivas y mide la distribución de PSI; pon el threshold un par de desviaciones por encima de lo normal.

Embeddings no representativos

Usas el embedding model de OpenAI text-embedding-3-small para detectar drift en un sistema que sirve preguntas técnicas en español sobre redes Cisco. Resultado: el embedding model no captura la semántica fina del dominio. Solución: usar embeddings finetuned para tu dominio o uno fuerte en multilenguaje y técnico.

Sobrecarga de almacenamiento

Almacenar embedding de cada prompt en producción a escala (millones de prompts/día) llena disco y aumenta coste. Sampling estratificado: guarda 5-10% del tráfico, pero asegúrate de que los segmentos minoritarios están sobrerrepresentados para no perderlos.

Confundir drift con “el sistema funciona”

A veces el drift es buen drift: los usuarios nuevos descubren que el agente sabe hacer X cosa, y de pronto el 30% del tráfico es para X cosa. La distribución cambió porque el producto encontró un nuevo uso. Antes de tirar de la alarma, verifica si el cambio es deseable.

Privacy en almacenamiento de embeddings

Embeddings pueden ser invertidos parcialmente a su texto original con técnicas de embedding inversion. Si los prompts contienen PII, almacenar embeddings durante meses para drift detection es un vector de fuga. Cifrar at rest y rotar regularmente, o trabajar con embeddings agregados/promediados.

eBPF en producción sin profile guardrails

Adjuntar uprobes en funciones de hot path como llama_decode puede impactar throughput si no se hace con cuidado. Probar siempre en staging y monitorizar overhead. ProfInfer reporta <4%; lo que tú midas puede variar según tu binario y kernel.

Cerrando las dos series

Esta semana hemos escrito 12 artículos que recorren el stack moderno de inferencia LLM en producción de arriba abajo:

Serie inferencia LLM (4 artículos):

• KV cache: la memoria de trabajo que sostiene la inferencia LLM — fundamentos.
• vLLM en Kubernetes — el motor.
• PagedAttention deep dive — cómo funciona por dentro.
• Operators LLM en Kubernetes — orquestación.

Serie eBPF (4 artículos):

• eBPF de cero a Cilium — el sustrato.
• Tetragon — seguridad runtime.
• Hubble — observabilidad de red.
• AgentSight — observabilidad de agentes.

Serie post-tracing (4 artículos):

• Evals — calidad reactiva.
• Guardrails — seguridad preventiva.
• MCP observability — protocolo de herramientas.
• Este — drift detection y eBPF en inferencia local.

Si lees los doce en orden tienes un mapa razonablemente completo de qué hace falta para operar agentes IA en producción seria en 2026, con el detalle suficiente para no chocarte con los problemas habituales en el primer mes. Y, sobre todo, con la mentalidad de que observabilidad LLM es un stack, no un producto: cada capa resuelve un problema, ninguna las resuelve todas, y la combinación es lo que define a un sistema operable de uno que aguanta hasta el primer incidente.

Lo que queda para futuras series

• MLOps específico para LLMs: fine-tuning continuo, RAG over data lakes, agent training.
• Constitutional AI y alignment runtime: cómo el modelo se autorregula con guardrails internos.
• GPU networking: InfiniBand, NCCL, GPUDirect — el ángulo que dejamos sin tocar.
• Edge inference: llama.cpp en móviles, MLX en macOS, Snapdragon NPU.
• Inference scheduling teórico: CFS-like algorithms aplicados a LLM serving multi-tenant.

Los iremos cubriendo. Hasta aquí, gracias por leer estos doce posts. Si te ha aportado algo, compártelo con un colega.

Referencias

eBPF en inferencia local:

• ProfInfer: An eBPF-based Fine-Grained LLM Inference Profiler (arxiv 2601.20755) — paper de referencia 2026.
• Monitor LLM Inference in Production 2026 (Glukhov) — Prometheus + Grafana para vLLM/TGI/llama.cpp.
• AI Inference Server Observability in Kubernetes (ARMO) — las cuatro señales que MLOps tools no capturan.
• vLLM vs llama.cpp: Choosing the right engine (Red Hat).

Drift detection conceptos:

• What is LLM Drift? Types, Detection, Mitigation 2026 (FutureAGI).
• LLM Model Drift Detection 2026 (Stack Pulsar).
• 9 Best LLM Drift Monitoring Platforms in 2026 (Galileo).
• Open-Source Drift Detection Tools in Action (arxiv 2404.18673).
• Detecting covariate drift in text data using document embeddings (arxiv 2309.10000).
• Best AI Drift Detection Tools in 2026 (FutureAGI).

Herramientas:

• Evidently AI (GitHub) — open-source.
• Evidently — sitio oficial.
• NannyML — performance sin ground truth.
• WhyLabs — managed observability.
• Alibi Detect (Seldon) — drift detection general.
• Arize Phoenix — drift integrado con tracing.

Tests estadísticos:

• Data drift detection: PSI vs Kolmogorov–Smirnov (MLPipeline) — comparativa práctica.
• Population Stability Index for Model Drift Detection.
• Which test is the best? 5 methods to detect data drift (Evidently) — los 6 horas de ventaja de KS.

Cross-references (las tres series completas):

• 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.