1. 1 - La observabilidad en aplicaciones con LLM, el problema que nadie estaba midiendo.
2. 2 - La observabilidad ha evolucionado… pero no tanto con los LLMs.
3. 3 - Los LLM cambian completamente el tipo de información que necesitamos.
4. 4 - El problema no es el precio por millón de tokens.
5. 5 - Lo que no podemos responder hoy
6. 6 - La telemetría ya no es suficiente
7. 7 - El origen de la investigación.

La observabilidad en aplicaciones con LLM, el problema que nadie estaba midiendo.

Llevo un tiempo trabajando con la IA, pero no ha sido hasta ahora después de montar herramientas, trabajar con ellas y lo cierto es que me preguntaba… ¿qué están consumiendo mis LLMs?, ¿Por qué estoy pagando? y todo esto no venía porque funcionaran mejor o peor, por la velocidad o el recorrido, sino que llegaba un momento en el que dejaba de tener tokens y no sabía por qué, unos días parece que había hecho más cosas que otros, esos días “más productivos” era una sensación o quizás era verdad o también podía ser que no hubiera hecho tantas peticiones o los que hacía eran más “simples”. Como ves eran muchas preguntas, muchas casuísticas y cómo no, no me podía ir a la cama con tanta duda y menos si era teniendo en cuenta que datos iba a necesitar. Al final todo esto es como un símil a mi forma de ver, lo veía como las preguntas que surgen cuando el servidor consume mucho CPU , una API responde lenta o una base de datos empieza a saturarse, pero aquí era como… “no sé nada”.

La observabilidad ha evolucionado… pero no tanto con los LLMs.

Durante años, los logs fueron la única forma de entender que ocurría en una aplicación. Analizábamos miles de líneas intentando encontrar una pista sobre el origen del problema. Con el tiempo aparecieron más métricas. Dejamos de preguntarnos únicamente qué había pasado para empezar a medir cómo estaba funcionando el sistema. CPU, memoria, tiempos de respuesta, número de peticiones o trasas de error comenzaban a ofrecer una visión mucho más clara del estado de una aplicación. Más adelante llegaron las trazas distribuidas. Ya no bastaba con saber que una petición tardaba demasiado; necesitábamos conocer exactamente qué servicios intervenían, cuánto tiempo dedicaba cada uno y dónde se producia el cuello de botella. Finalmente, proyectos como OpenTelemetry unificaron la forma de capturar toda esa información, convirtiéndose en un estándar de facto para instrumentar aplicaciones modernas independientemente del lenguaje, la estructura o el proveedor cloud. A día de hoy damos muchas cosas por hechas en muchos de los sistemas modernos, donde podemos ver cosas como:

• ¿Qué servicio está fallando?
• ¿Qué endpoint tiene mayor latencia?
• ¿Qué consulta SQL tarda más tiempo?
• ¿Dónde se está produciendo el mayor número de errores?
• ¿Qué dependencia externa está degradando el rendimiento?

Responder estas preguntas a día de hoy ya no supone un reto técnico. Disponemos de herramientas maduras, estándares consolidados y una enorme cantidad de soluciones comerciales y de código abierto. Pero ahora todas estas soluciones tienen un punto ciego. Las aplicaciones basadas en modelos de lenguaje (LLM) han cambiado por completo la naturaleza de las peticiones que enviamos, pero seguimos intentando observarlas con herramientas diseñadas para otro tipo de software. Y ahí es donde encontramos un problema.

Los LLM cambian completamente el tipo de información que necesitamos.

Una llamada a un modelo de lenguaje no es simplemente una petición HTTP. Desde fuera puede parecerlo, enviamos un JSON y recibimos una respuesta. Pero internamente ocurre algo completamente distinto, cada petición incorpora una enorme cantidad de dimensiones que antes simplemente no existían. Ahora también necesitamos conocer:

• el modelo utilizado;
• el proveedor que lo ejecuta;
• los tokens enviados;
• los tokens generados;
• el coste asociado;
• el contexto completo enviado al modelo;
• las herramientas utilizadas durante la ejecución;
• el uso de caché;
• el razonamiento empleado por determinados modelos;
• la temperatura;
• si la respuesta se ha generado mediante streaming;
• o incluso cuántas iteraciones ha necesitado un agente para completar una tarea.

De repente aparecen más métricas que no tienen equivalente en las aplicaciones más tradicionales. Y lo más interesante es que muchas de ellas están relacionadas entre sí. Una pequeña modificación. Cambiar de modelo puede reducir la latencia pero aumentar el coste. Una herramienta adicional puede mejorar la calidad de la respuesta… o disparar el consumo de contexto sin aportar valor. La naturaleza de la observabilidad cambia completamente. Existe una frase que resume muy bien este cambio de paradigma: Un LLM no consume CPU. Consume contexto. La CPU, la memoria o la red siguen siendo importantes. Pero dejan de ser el recurso crítico. El nuevo recurso limitado que enviamos al modelo y la forma en la que este lo utiliza para generar una respuesta.

El problema no es el precio por millón de tokens.

Cuando se habla del coste de los modelos de lenguaje, la conversación suele centrarse siempre en el mismo punto, el precio por millón de tokens. Cada vez que llega un modelo el proveedor publica sus tarifas y la mayoría de las discusiones terminan ahí. Sin embargo, esa comparación es incompleta. Imaginemos dos empresas, las dos tienen exactamente el mismo núimero de usuarios, las dos utilizan GPT-4.1, las dos pagan exactamente el mismo precio por cada millón de tokens. Sin embargo, una de ellas termina gastando diez veces más dinero al final del mes. ¿por qué?, No porque OpenAI cobre distinto, no porque tenga más tráfico, sino porque nadie está midiendo lo que realmente importa. Quizás una aplicación envía prompts innecesariamente largos, quizás mantiene un historial completo de la conversación aunque ya no aporten ningún valor.

Lo que no podemos responder hoy

Si trasladamos esta conversación a una aplicación real, empiezan a surgir preguntas aparentemente sencillas. Preguntas que cualquier equipo técnico debería poder responder. Por ejemplo:

• ¿Qué prompt consume más tokens?
• ¿Qué usuario genera mayor coste?
• ¿Qué agente resulta menos eficiente?
• ¿Qué herramienta añade más contexto?
• ¿Cuántos tokens son realmente útiles para la respuesta final?
• ¿Qué porcentaje del contexto nunca llega a utilizar el modelo?
• ¿Qué modelo responde más rápido para una misma tarea?
• ¿Qué parte del coste proviene del sistema y cuál del usuario?
• ¿Qué conversaciones reutilizan correctamente la caché?
• ¿Qué instrucciones del sistema nunca tienen impacto sobre la respuesta?

Aunque nos parezca sorprendente, estas preguntas siguen siendo complicadas. La mayoría de plataformas ofrecen métricas básicas, algunas muestran el número de tokens y otras permiten consultar el coste de una petición… pero cada proveedor ofrece la información de forma distinta. Cada SDK devuelve estructuras diferentes. Cada framework instrumenta únicamente aquello que considera importante. Y cuando una aplicación combina varios proveedores, varios modelos o distintos agentes, obtener una visión unificada deja de ser una tarea sencilla. Seguimos teniendo datos. Pero lo que no tenemos es una observabilidad.

La telemetría ya no es suficiente

Hasta ahora la observabilidad se apoyaba principalmente en métricas técnicas.

• CPU.
• Memoria.
• Latencia.
• Uso de red.
• Errores.

Todo eso sigue siendo necesario pero ya no es suficiente. Ahora necesitamos entender el comportamiento semántico de una petición.

• No basta con saber cuánto tarda una respuesta, necesitamos saber por qué tarda.
• No basta con conocer cuánto cuesta una llamada, necesitamos entender qué está provocando ese coste.
• No basta con contar tokens. Necesitamos descubrir de dónde provienen esos tokens y cuál es su impacto real.

Porque no todos los tokens aportan el mismo valor. En muchas aplicaciones descubrimos un patrón que se repetía una y otra vez. La mayor parte del coste no provenía de la respuesta generada por el modelo. Provenía del contexto que nosotros mismos enviábamos. Documentos redundantes. Historiales excesivamente largos. Prompts duplicados. Herramientas que añadían información irrelevante. Todo ello terminaba convirtiéndose en un coste silencioso. Un impuesto invisible que pagábamos en cada petición sin ser realmente conscientes de ello. Más adelante le pondríamos un nombre. Context Tax.

Pero todavía no sabíamos hasta qué punto iba a convertirse en uno de los principales problemas de las aplicaciones basadas en LLM.

El origen de la investigación.

Toda esta situación nos llevó a plantearnos una pregunta muy sencilla.

¿Y si pudiéramos observar una petición a un LLM con el mismo nivel de detalle con el que hoy observamos cualquier sistema distribuido?

No buscábamos construir otro SDK. Tampoco otro wrapper específico para un proveedor. Y mucho menos depender de una plataforma concreta. Lo que necesitábamos era una forma de capturar toda esa información de manera uniforme, independientemente del modelo utilizado, del framework o del proveedor que hubiese detrás. Queríamos observar una petición a un modelo de lenguaje igual que hoy observamos una llamada HTTP, una consulta SQL o una traza distribuida. Sin perder información. Sin modificar la aplicación. Y sin imponer una forma concreta de desarrollar. Esa idea fue el punto de partida de OxideGate. Lo que inicialmente parecía una necesidad de instrumentación terminó convirtiéndose en una investigación mucho más amplia sobre cómo consumen contexto los modelos de lenguaje, qué información resulta realmente útil para optimizar una aplicación y por qué las herramientas actuales todavía no responden a muchas de las preguntas que realmente importan.