Observabilidad de LLM: trazas, costes y calidad

Actualizado: 2026-05-03

Las aplicaciones basadas en LLM presentan un perfil de observabilidad diferente al de las aplicaciones tradicionales. Una API REST bien instrumentada expone latencia, tasa de error y throughput —métricas que Prometheus y Grafana gestionan perfectamente. Una aplicación LLM necesita además capturar pares prompt/respuesta para depurar alucinaciones, rastrear el coste real en tokens por función y por usuario, y medir la calidad de las respuestas de formas que los instrumentos de infraestructura convencional no cubren. El stack de observabilidad LLM en 2024 ya tiene herramientas maduras para esos tres planos.

Puntos clave

• La observabilidad LLM tiene tres planos distintos: trazas de prompts, costes de tokens y calidad de respuesta. Cada uno requiere instrumentación específica.
• Langfuse es open-source y auto-hosteable; LangSmith está integrado de forma nativa con LangChain; Helicone es el proxy más simple de desplegar.
• El patrón de evaluación más escalable combina un juez-LLM automático para calidad con muestras humanas periódicas para calibrar el juez.
• El coste por feature o por usuario requiere pasar metadata explícita en cada llamada —no es automático en ninguna herramienta.
• Prometheus + las métricas nativas de vLLM cubren el plano de infraestructura; las herramientas especializadas cubren el plano de aplicación.

Qué trackear en una aplicación LLM

Las métricas de infraestructura —latencia p95, tasa de error, throughput de tokens— son necesarias pero no suficientes. Lo que añade la capa LLM:

Trazas de prompt/respuesta: capturar el prompt completo, la respuesta, el modelo usado, la temperatura y el número de tokens en cada llamada. Imprescindible para depurar comportamientos inesperados —no puedes reproducir una alucinación si no tienes el prompt exacto.

Costes de tokens: el input y el output de cada llamada, con el precio por modelo, agregado por usuario, por sesión, por feature del producto. Sin este tracking, el coste de un modelo en producción es opaco hasta que llega la factura.

Calidad de respuesta: métricas que varían según la aplicación —fidelidad en RAG, relevancia de la respuesta, ausencia de alucinaciones, cumplimiento del formato esperado. Estas métricas no son automáticas; requieren o evaluación humana o un juez-LLM.

Latencia desglosada: tiempo hasta el primer token (TTFT) y latencia extremo a extremo. En aplicaciones con streaming, el TTFT es lo que el usuario percibe como “rápido” o “lento”; la latencia total es secundaria.

Langfuse: open-source y auto-hosteable

Langfuse^[1] se ha convertido en la herramienta de observabilidad LLM open-source más completa disponible. Puede desplegarse en Kubernetes (hay un chart oficial de Helm) o usarse como servicio gestionado. La integración es directa:

from langfuse import Langfuse
from langfuse.decorators import observe, langfuse_context

langfuse = Langfuse()

@observe()
def process_query(user_id: str, query: str) -> str:
    langfuse_context.update_current_observation(
        metadata={"user_id": user_id, "feature": "search"},
    )

    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": query}],
    )
    return response.choices[0].message.content

# Cada llamada a process_query genera una traza automáticamente
result = process_query("user-123", "¿Qué es eBPF?")

El decorador @observe captura automáticamente los inputs, outputs, latencia y coste de la llamada. Las traces se muestran en la interfaz de Langfuse con el prompt completo, la respuesta, el coste en tokens y el coste monetario calculado.

Para aplicaciones de RAG en producción, Langfuse tiene soporte nativo de evaluación de fidelidad y relevancia con un flujo de anotación que combina evaluación LLM automática y feedback humano.

LangSmith: integración nativa con LangChain

LangSmith^[2] es la herramienta de observabilidad de Anthropic (a través de LangChain). La principal ventaja es la integración transparente con LangChain y LangGraph: si tu aplicación usa cadenas o grafos de LangChain, LangSmith las traza sin instrumentación adicional.

import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "..."
os.environ["LANGCHAIN_PROJECT"] = "mi-app-produccion"

# A partir de aquí, todas las ejecuciones de LangChain se trazan
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

llm = ChatOpenAI(model="gpt-4o")
prompt = ChatPromptTemplate.from_template("Responde: {question}")
chain = prompt | llm

result = chain.invoke({"question": "¿Qué es PagedAttention?"})

LangSmith también incluye evaluadores automáticos para criterios como concisión, corrección, relevancia y toxicidad, y permite definir evaluadores personalizados con un LLM como juez.

Helicone: el proxy más simple

Helicone^[3] toma un enfoque diferente: en lugar de SDK o decoradores, funciona como un proxy HTTP entre tu aplicación y la API del modelo. Cambiar la URL base es el único cambio de código:

import openai

client = openai.OpenAI(
    api_key="...",
    base_url="https://oai.helicone.ai/v1",
    default_headers={
        "Helicone-Auth": f"Bearer {helicone_api_key}",
        "Helicone-Property-UserId": "user-123",
        "Helicone-Property-Feature": "search",
    },
)

Todas las requests pasan por Helicone, que registra el prompt, la respuesta, los tokens y el coste. La ventaja es que funciona con cualquier SDK o librería sin modificaciones; la desventaja es que añade latencia de red (generalmente 10-30 ms) y que si Helicone tiene un problema, tu aplicación también lo tiene.

Arize Phoenix: evaluación de calidad

Arize Phoenix^[4] se especializa en la evaluación de calidad de respuestas LLM más que en el tracking operacional. Su diferencial es un framework de evaluación con:

• Evals automáticos: evalúa fidelidad en RAG, relevancia, corrección factual y hallucination rate usando un LLM como juez.
• Rastreo de experimentos: compara diferentes versiones de prompt o modelos sobre el mismo set de evaluación.
• Interoperabilidad: importa trazas de Langfuse o LangSmith para evaluarlas con sus métricas.

Para observabilidad de LLM self-hosted con vLLM, el stack más común es Prometheus (métricas de GPU, cola y latencia) + Langfuse (trazas de prompt y coste) + Arize Phoenix para evaluación periódica de calidad.

El plano de infraestructura: Prometheus + métricas nativas

Las herramientas especializadas de LLM cubren el plano de aplicación, pero el plano de infraestructura sigue siendo Prometheus. Para servicios basados en vLLM o TGI, las métricas nativas de Prometheus cubren:

• Peticiones en curso y en cola.
• Ocupación de la caché KV de GPU.
• Tiempo hasta el primer token (p50, p95, p99).
• Latencia extremo a extremo.
• Tasas de error por tipo.

El dashboard oficial de Grafana para vLLM combina estas métricas con alertas sobre ocupación de cola creciente —la señal más importante de capacidad insuficiente.

Patrones de evaluación de calidad escalables

El mayor reto de la observabilidad LLM no es el tracking operacional —eso está resuelto— sino la evaluación de calidad a escala. Las evaluaciones humanas son costosas; las automáticas requieren un juez-LLM que puede equivocarse. El patrón que mejor escala combina ambas:

• Evaluación automática continua: un LLM (GPT-4o mini, Claude Haiku) evalúa cada respuesta según criterios definidos —relevancia, fidelidad, formato. Coste: 0,1-0,5 céntimos por evaluación.
• Muestreo humano periódico: humanos anotan el 1-5 % de las evaluaciones para calibrar el juez automático. Si el juez automático diverge del humano más de un umbral definido, se ajusta el prompt del juez.
• Evaluación de regresión: cuando se cambia el prompt principal o el modelo, se reevalúa un conjunto de referencia para detectar regresiones.

Este patrón permite escalar la evaluación de calidad a millones de respuestas sin coste prohibitivo, mientras mantiene la calibración con criterio humano.

Coste por feature: el tracking que más falta hace

El dato más útil para decisiones de producto —“¿cuánto cuesta la feature X por usuario activo?”— es el que ninguna herramienta da automáticamente. Requiere pasar metadata explícita en cada llamada e implementar un pipeline de agregación:

# En cada llamada al LLM
langfuse.trace(
    name="feature-search",
    metadata={
        "user_id": user_id,
        "feature": "search",
        "plan": user.plan,
    },
    input={"query": query},
    output={"response": response},
    usage={"input": tokens_input, "output": tokens_output},
)

Con esa metadata, Langfuse permite filtrar y agregar coste por feature, por plan o por segmento de usuario. Sin esa instrumentación explícita, solo tienes el coste total —inútil para decisiones de pricing.

Conclusión

La observabilidad LLM madura tiene tres planos que requieren instrumentación separada: la infraestructura (Prometheus + métricas nativas del servidor), la aplicación (Langfuse, LangSmith o Helicone para trazas y costes) y la calidad (evaluación automática + calibración humana). Las aplicaciones que solo tienen el primer plano instrumentado tienen visibilidad de la GPU pero son ciegas a la calidad y al coste por feature —los dos datos que más importan para decisiones de producto y de negocio.

1. Langfuse
2. LangSmith
3. Helicone
4. Arize Phoenix