El problema es que nadie sabe lo que cuesta realmente sus prompts.
  1. 1 - El problema es que nadie sabe lo que cuesta realmente sus prompts.
  2. 2 - El prompt dejó de ser una simple pregunta.
  3. 3 - El contexto crece constantemente
  4. 4 - Memoria
  5. 5 - RAG: cuando responder implica leer primero.
  6. 6 - MCP: ahora el modelo conoce herramientas
  7. 7 - Tool Calling
  8. 8 - Agentes
  9. 9 - El gran problema: seguimos midiendo aplicaciones modernas con métricas del pasado.
  10. 10 - De la teoría a la práctica: cuando medir dejó de ser suficiente

El problema es que nadie sabe lo que cuesta realmente sus prompts.

Cuando se habla de modelso de lenguaje, casi toda la conversacioń gira alrededor de una única métrica:

GPT cuesta X dólares por millón de tokens. Claude es más barato Gemni Flasj tiene un coste ridículo

Y siendo sinceros es cierto. Los proveedores publican sus precios por ttokens de entrada y salida, aparecen comparativas constantemente y existen decenas de calculadoras para estimar cuanto cosatará una llamada. Pero tenemosun problema.

En una aplicación real práctiamente nadie envía únicamente un prompt, y ahí es donde empiezan los costes que nadie está midiendo.

El prompt dejó de ser una simple pregunta.

Hace apenas dos años una petición era algo parecido a: Resume este documento., a día de hoy las peticiones son más parecidas a:

System Prompt
    |
    v
Historial de conversación
    |
    v
Memoria del usuario
    |
    v
Resultados del RAG
    |
    v
Herramientas disponibles
    |
    v
Descripción de cada Tool
    |
    v
Schemas JSON
    |
    v
Mensajes internos del framework
    |
    v
REspuesta del modelo

Lo que el usuario escribe suele representar una parte muy pequeña del contexto total. En muchos casos, ni siquiera llega al 5% de todos los tokens enviados. La mayor parte del coste está en información que el usuario nunca llega a ver.

El contexto crece constantemente

Cada nueva capacidad que añadimos a una aplicación basada en IA hace crecer el contexto, y eso significa más tokens. Más latencia, y por ende más dinero. No es una decisión puntual, es acumulativa.

Memoria

Queremos que el asistente recuerde conversaciones anteriores, perfecto. Ahora cada petición incorpora parte del historial.

RAG: cuando responder implica leer primero.

Aquí dedicaría una sección únicamente a explicar RAG. No una definición académica. Algo como:

Imagina que preguntas cuál es la política de devoluciones de una empresa.

El modelo realmente no la conoce. Así que primero alguien tiene que buscar ese documento. Lo habitual es utilizar un sistema RAG (Retrieval-Augmented Generation), que recupera los fragmentos más relevantes desde una base de conocimiento y los añade al contexto antes de generar la respuesta. Eso tiene una ventaja enorme: el modelo responde utilizando información actualizada. Pero también introduce un coste. Si recuperamos cinco documentos de dos mil tokens cada uno, acabamos de añadir diez mil tokens antes incluso de que el modelo empiece a responder. Y eso ocurre en cada petición. Aquí incluso puedes mencionar algo muy interesante: Muchas optimizaciones de RAG se centran en mejorar la recuperación, pero pocas veces se analiza cuánto contexto se está enviando realmente.

MCP: ahora el modelo conoce herramientas

Aquí haría exactamente lo mismo. Primero explicar el concepto. No asumir que el lector sabe qué es. Por ejemplo: El Model Context Protocol nace para resolver un problema evidente: los modelos de lenguaje viven aislados. No conocen nuestras bases de datos. No pueden consultar un ERP. No pueden leer un repositorio privado. No saben acceder a un CRM. MCP proporciona un protocolo común para exponer todas esas capacidades al modelo. Pero esa integración no es gratuita. Cada servidor MCP debe describir qué herramientas ofrece, qué parámetros acepta, cómo debe utilizarse y qué resultados devuelve. Toda esa información también forma parte del contexto. Y cuanto más crece un servidor MCP, mayor es el prompt que recibe el modelo.

Tool Calling

Aquí puedes contar algo que casi nadie explica. El modelo no “ejecuta funciones”. Lo único que hace es decidir: Creo que para responder necesito llamar a esta herramienta. Después el framework ejecuta realmente la función. Obtiene el resultado. Y vuelve a llamar al modelo. Es decir. Una sola pregunta puede convertirse en:

LLM

↓

Tool

↓

LLM

↓

Tool

↓

LLM

Cada flecha implica otra petición.

Agentes

Los agentes llevan este problema todavía más lejos. Ya no existe una única conversación, existen razonamientos internos, planificaciones, reintentos, subagentes, validaciones, llamadas entre modelos y cada paso consume tokens. Muchos de ellos invisibles para el desarrollador.

El coste que nadie está viendo cuando alguien dice:

Estos pasos son los que decimos que hace:

La realidad es que, en la mayoría de proyectos, nadie lo sabe porque normalmente sólo se registra la petición principal. Todo lo demás queda oculto dentro del framework utilizado.

El gran problema: seguimos midiendo aplicaciones modernas con métricas del pasado.

El gran problema: seguimos midiendo aplicaciones modernas con métricas del pasado Durante los últimos años nos hemos acostumbrado a comparar modelos utilizando una cifra muy sencilla: el precio por millón de tokens. OpenAI, Anthropic, Google o cualquier otro proveedor publican sus tarifas y, a partir de ahí, resulta tentador pensar que calcular el coste de una aplicación es tan fácil como contar los tokens de entrada y salida y multiplicarlos por el precio correspondiente. Sobre el papel parece una aproximación razonable. El problema es que esa métrica únicamente describe el coste de una llamada individual al modelo. No describe el coste de una aplicación basada en IA. Y ambas cosas hace tiempo que dejaron de ser equivalentes. Una aplicación moderna rara vez envía al modelo únicamente el texto que ha escrito el usuario. Antes de generar una respuesta pueden recuperarse documentos mediante RAG, añadirse fragmentos de memoria, incorporarse instrucciones del sistema, describirse decenas de herramientas disponibles, ejecutarse varias llamadas mediante Tool Calling o incluso coordinarse varios agentes especializados. Todo ese proceso genera contexto, nuevas peticiones y, por supuesto, nuevos tokens. Sin embargo, cuando intentamos responder cuánto ha costado esa interacción seguimos utilizando exactamente la misma fórmula que utilizaríamos para un simple chatbot:

Coste = tokens de entrada + tokens de salida

La realidad es bastante más compleja. ¿Estamos contabilizando únicamente la llamada final o también las anteriores? ¿El coste del RAG forma parte de la misma interacción? ¿Qué ocurre si el modelo decide llamar tres veces a una herramienta antes de construir la respuesta definitiva? ¿Y si un agente delega parte del trabajo en otros modelos? ¿Debemos atribuir ese consumo a la petición inicial, al agente que tomó la decisión o a cada componente por separado? La mayoría de aplicaciones actuales no pueden responder a esas preguntas. No porque la información no exista, sino porque nunca se ha diseñado una forma de observarla de manera unificada. Como consecuencia, sabemos cuánto cuesta utilizar un modelo, pero no cuánto cuesta ejecutar nuestro sistema. Y esa diferencia tiene implicaciones mucho más importantes de lo que parece. Cuando una factura aumenta, resulta imposible identificar qué componente está provocando el incremento. Si una optimización reduce el número de tokens enviados al modelo, tampoco podemos asegurar que realmente haya reducido el coste global de la aplicación. Incluso comparar dos modelos diferentes puede llevar a conclusiones erróneas si uno necesita más llamadas, más herramientas o más contexto para resolver exactamente la misma tarea. En otras palabras, estamos optimizando a ciegas. Disponemos de métricas muy precisas sobre el proveedor del modelo, pero apenas tenemos información sobre el comportamiento de nuestra propia arquitectura. Sabemos cuánto cobra OpenAI, Anthropic o Gemini por procesar un millón de tokens, pero desconocemos qué parte de ese consumo proviene de nuestro RAG, qué herramientas se ejecutan con más frecuencia, qué agentes son responsables de la mayor parte del presupuesto o qué porcentaje del contexto enviado ni siquiera termina siendo relevante para la respuesta. Y ahí es donde aparece el verdadero problema. El reto ya no consiste en medir el precio de un modelo. Ese dato ya lo proporcionan los propios proveedores. El reto consiste en comprender el coste real de un sistema compuesto por múltiples capas, múltiples componentes y múltiples interacciones, donde una única pregunta puede desencadenar decenas de operaciones invisibles para el usuario y, en muchos casos, también para el propio desarrollador. Porque solo cuando somos capaces de observar todo ese proceso de extremo a extremo podemos responder una pregunta aparentemente sencilla, pero fundamental para cualquier aplicación de IA en producción: ¿Cuánto ha costado realmente responder a esta petición y por qué? Ese fue, precisamente, el punto de partida que nos llevó a desarrollar OxideGate.

De la teoría a la práctica: cuando medir dejó de ser suficiente

Hasta este punto hemos hablado de conceptos que, de una forma u otra, afectan a cualquier aplicación moderna basada en modelos de lenguaje. Hemos visto cómo el contexto ha dejado de ser un simple historial de conversación para convertirse en una combinación de memoria, documentos recuperados mediante RAG, herramientas, servidores MCP, agentes y múltiples llamadas al modelo. También hemos visto que, aunque los proveedores nos ofrecen métricas muy precisas sobre el consumo de tokens, esas cifras únicamente representan una pequeña parte de lo que realmente ocurre durante una interacción. La pregunta que inevitablemente surge es muy sencilla:

¿Cómo se mide entonces el comportamiento real de una aplicación basada en LLMs?

Nuestra primera reacción fue pensar que seguramente ya existía una solución. Después de todo, el ecosistema del software lleva décadas resolviendo problemas de observabilidad. Cuando desplegamos una API podemos medir el tiempo de respuesta de cada petición. Si un servicio consume demasiada memoria, existen herramientas capaces de mostrar exactamente qué proceso está provocando el problema. Podemos conocer el uso de CPU de cada contenedor, analizar consultas lentas en una base de datos, visualizar trazas distribuidas entre microservicios o generar métricas prácticamente de cualquier componente de nuestra infraestructura. La observabilidad tradicional está extraordinariamente madura. Sin embargo, cuando empezamos a construir aplicaciones apoyadas en modelos de lenguaje descubrimos que esa visibilidad desaparecía justo en la parte más importante del sistema. Podíamos saber cuánto tardaba una petición HTTP, pero no cuánto tiempo había dedicado el modelo a razonar. Podíamos medir la latencia de una base de datos, pero no cuánto contexto estaba incorporando nuestro sistema RAG. Podíamos conocer el consumo de memoria del servidor, pero no qué herramienta estaba generando el mayor número de llamadas al modelo. Y, sobre todo, seguíamos sin poder responder una pregunta aparentemente trivial:

¿Cuánto ha costado realmente responder a esta petición?

No el coste de una llamada aislada. No el precio por millón de tokens publicado por el proveedor. El coste completo de una interacción. Es decir, cuánto consumió el prompt inicial, cuántos documentos recuperó el RAG, cuántas herramientas se ejecutaron, cuántas veces volvió a invocarse el modelo, qué agente realizó cada operación y cuánto terminó costando todo ese proceso de principio a fin. La información existía, pero estaba completamente fragmentada. Una parte aparecía en los logs del framework. Otra en la respuesta de la API del proveedor. Otra en la herramienta de monitorización. Otra, simplemente, no se registraba. Reconstruir lo que había ocurrido implicaba revisar múltiples fuentes de información y, aun así, era muy difícil obtener una visión completa de una única conversación. Fue entonces cuando comprendimos que el problema no era únicamente medir tokens. El verdadero desafío consistía en observar el ciclo de vida completo de una interacción con un modelo de lenguaje, del mismo modo que hoy observamos una petición HTTP o una consulta SQL. Necesitábamos responder preguntas mucho más útiles para un entorno de producción:

¿Listo para hacer crecer tu negocio?

Analicemos tu proyecto y definamos la estrategia perfecta para alcanzar tus objetivos

Solicitar consultoría gratuita