Saltar al contenido

Compare

Olivares AI vs observabilidad LLM (LiteLLM, Langfuse)

LiteLLM y Langfuse trazan las llamadas a modelos que hace tu aplicación. Olivares mapea cada agente de tu parque y todo lo que lee o escribe. Altitud diferente. Se complementan.

Un stack self-hosted habitual y sensato combina un LLM gateway (por ejemplo LiteLLM) con una plataforma de observabilidad LLM (por ejemplo Langfuse). Si ya tienes uno, es razonable preguntarse si necesitas un control plane. Esta página responde con honestidad — incluidos los casos en que la respuesta es no.

TL;DR: LiteLLM y Langfuse se ocupan de las llamadas a modelos que hace tu aplicación: enrutarlas, trazarlas, gestionar prompts, contabilizar el coste por llamada. Olivares AI se ocupa de cada agente de tu parque y todo lo que lee o escribe — bases de datos, object stores, servidores MCP, herramientas, ficheros — y de si eso coincide con lo que la política permite. Altitud diferente. Se complementan; ingerimos la misma señal OpenTelemetry gen-ai que ellos emiten y consumen.

Lo que ese stack hace bien (úsalo para esto)

  • LiteLLM — un gateway unificado y compatible con OpenAI delante de múltiples proveedores: enrutamiento, fallbacks, reintentos, claves virtuales, presupuestos y rate limits por clave, y contabilización de costes de las llamadas a modelos que pasan por él.
  • Langfuse — ingeniería y observabilidad LLM: trazas de petición/respuesta, gestión y versionado de prompts, evaluaciones, datasets y una interfaz orientada a desarrolladores para depurar cadenas.

Si tu problema es «instrumentar las llamadas LLM de mi aplicación, depurar prompts y gestionar el acceso a modelos desde un único endpoint», este stack es excelente y self-hostable. No necesitas un control plane para eso, y no vamos a pretender lo contrario.

Donde Olivares AI es estructuralmente diferente

DimensiónLLM gateway + observabilidadOlivares AI
Unidad de interésUna llamada a modelo (prompt → completion)Un agente y cada recurso que lee/escribe — BDs, object stores, MCP, herramientas, ficheros
Punto de observaciónEn la ruta de la petición (proxy/SDK); ve lo que la aplicación envíaFuera de banda, lectura primero; observa telemetría, auditoría nativa y un backstop a nivel de kernel — nunca en la ruta de datos
Fuente de verdadLo que la aplicación/proxy reportaTelemetría auto-reportada corroborada contra el propio registro del sistema — pgAudit (lectura vs escritura), CloudTrail (acceso a objetos), backstop eBPF
La pregunta clave«¿Qué hizo este prompt y cuánto costó?»«¿Este agente está usando accesos que nadie le concedió?» — Deriva entre lo permitido y lo observado
EnforcementEl gateway puede bloquear llamadas a modelos (claves, presupuestos)Gates deny-closed sobre acciones y acceso a recursos: aprobaciones, el Claude Code hooks PEP, gating de herramientas MCP, kill switches
Artefacto de auditoríaTrazas / logs para depuraciónLedger append-only, encadenado por hash, firmado con Ed25519, verificable off-box, exportable como paquetes de evidencia OSCAL
Postura de despliegueSelf-hostableSelf-hosted o air-gapped; el plano de datos nunca sale de tu perímetro; AGPL, source-available

La diferencia de fondo es la fuente de verdad. Una traza de observabilidad te dice lo que la aplicación dijo que hizo. No puede decirte que un agente accedió a una tabla que la traza nunca mencionó. Olivares AI cruza la señal cooperativa con el plano de datos, de modo que «lo que el agente tocó» es un hecho corroborado, no un auto-reporte.

Es «y», no «o» — ingerimos tu telemetría

Olivares AI no es un sustituto de tu gateway ni de tu herramienta de trazado, y no pretende ocupar la ruta de petición que ellos ocupan. Consume la misma señal: el control plane ingiere spans de convenciones semánticas OpenTelemetry GenAI, la misma telemetría gen-ai que estas herramientas emiten y consumen. Así que una disposición saludable es:

  • Mantén LiteLLM como tu gateway de modelos y Langfuse para el trazado orientado a desarrolladores y el trabajo con prompts.
  • Apunta el flujo OTel gen-ai hacia Olivares AI como una fuente corroboradora, y deja que el mapa de acceso, la detección de deriva y el ledger proporcionen la capa de gobernanza a escala de todo el parque por encima.

Cuándo no deberías recurrir a Olivares AI

La honestidad funciona en ambas direcciones. Probablemente no necesitas este control plane si:

  • Tu único objetivo es trazar y depurar llamadas LLM en una o dos aplicaciones, con un playground de prompts — Langfuse solo es una opción más adecuada.
  • Solo necesitas un gateway multi-proveedor con presupuestos y failover — ese es el trabajo de LiteLLM, y nosotros nos integramos con ese patrón en lugar de reimplementarlo.
  • No tienes un parque que gobernar: un único servicio, un único modelo, ningún agente tocando bases de datos/object stores/MCP, y ninguna obligación regulatoria ni de auditoría.

Olivares AI se justifica cuando las preguntas pasan a ser de escala de parque y adversariales: qué agentes existen, qué puede alcanzar realmente cada uno, dónde se está desviando el acceso de la política, puedo demostrarlo ante un auditor, y puedo detener una acción maliciosa deny-closed — todo sin enviar esa imagen a la nube de otro.

Preguntar a Claude

Preguntas

¿Olivares sustituye a LiteLLM o Langfuse?

No. Ellos trazan llamadas a modelos a nivel de aplicación. Olivares mapea lo que los agentes leen y escriben en tu plano de datos — bases de datos, object stores, MCP, ficheros. Consume la misma señal OpenTelemetry que ellos emiten.