)
¿Qué es la monitorización del uso de tokens?
La monitorización del uso de tokens es la práctica de registrar cada llamada a la API de un LLM con su conteo de tokens, coste, modelo y metadatos de origen. Bien implementada, sabes exactamente qué funcionalidad cuesta cuánto, quién está generando el gasto innecesario y dónde aplicar compresión, caché o enrutamiento. Sin ella, la optimización de costes es pura especulación.
TL;DR - Puntos Clave
- La mayoría de los equipos consolidan todos los costes de la API de LLM en una única línea sin desglose por funcionalidad, equipo o usuario
- Los tokens de salida cuestan significativamente más que los de entrada en la mayoría de los modelos; sin registros por solicitud no puedes ver qué está disparando la factura
- Cuatro cosas que todo sistema LLM en producción debe registrar: conteo de tokens de entrada, conteo de tokens de salida, modelo y etiquetas de metadatos (funcionalidad, usuario, entorno)
- Herramientas como Helicone y LangSmith ofrecen observabilidad a nivel de solicitud con un único cambio de configuración; un gateway añade cumplimiento de políticas encima
- No puedes enrutar, comprimir ni cachear eficazmente sin tener primero una distribución de uso de referencia
Si estás recortando costes de LLM sin una capa de monitorización, estás tomando decisiones sin datos. Esta guía cubre qué registrar, cómo atribuirlo a los centros de coste correctos, qué herramientas usar y qué hacer con los números una vez que los tienes.
Para el marco completo, lee la guía de Optimización de Tokens de IA.
Todo el Mundo Habla de Optimizar Costes. Nadie Soluciona la Visibilidad Primero
Aquí está el patrón que veo constantemente. Un equipo decide recortar su factura de LLM. Implementan compresión de prompts. Añaden caché. Cambian una funcionalidad a un modelo más barato. Dos meses después, revisan la factura. Apenas se ha movido.
¿Por qué? Porque no tenían ni idea de qué partes de su sistema eran realmente caras.
Es como ponerse a dieta sin controlar lo que comes. Eliminas el postre. El verdadero problema eran los tres cafés con leche al día que nunca aparecieron en la hoja de cálculo.
La monitorización de tokens es el paso que la mayoría de los equipos omite. Es también el paso que hace que todo lo demás funcione.
Qué Necesitas Registrar Realmente
No todos los datos de tokens son útiles. El agregado bruto en el panel de tu proveedor es casi inútil para la optimización. Necesitas datos granulares y etiquetados a nivel de solicitud.
Este es el conjunto mínimo viable.
Tokens de entrada y tokens de salida, por separado. Los tokens de salida cuestan más en la mayoría de los modelos. Un prompt que genera una respuesta de 3.000 tokens es un problema muy diferente al que genera 50 tokens. Necesitas ambos conteos o no puedes diagnosticar el problema.
Modelo. Obvio en teoría. En la práctica, muchos equipos registran todas las llamadas a LLM en la misma tabla sin etiquetar el modelo. No puedes comparar eficiencia ni tomar decisiones de enrutamiento sin este dato.
Latencia. P50 y P95 por modelo y por funcionalidad. Un modelo que es 3 veces más lento en tu carga de trabajo cambia el cálculo de enrutamiento aunque sea más barato por token.
Coste. Calcúlalo en el momento del registro usando los conteos de tokens y el precio actual del modelo. No lo reconstruyas después. Los precios de OpenAI cambian. Tener el coste embebido en tus registros significa que siempre tienes el número real en el momento de la consulta.
Etiquetas de metadatos. Esta es la que la mayoría de los equipos omite por completo. Etiqueta cada solicitud con: nombre de funcionalidad, ID de usuario o identificador hasheado, entorno (producción/staging/dev) e ID de experimento si ejecutas pruebas A/B. Sin etiquetas, tienes un número de coste. Con etiquetas, tienes un mapa de costes.
El Problema de la Atribución
Aquí está el problema real. Los costes de LLM en la mayoría de las empresas aparecen como una única línea en la factura mensual.
18.400 € a OpenAI. Eso es todo.
¿Qué funcionalidad? Ni idea. ¿Qué equipo? Desconocido. ¿Qué entorno está quemando créditos de desarrollo con modelos de nivel frontier? Buena pregunta.
Este es el problema de la atribución. Es lo que separa a los equipos que pueden optimizar realmente de los que simplemente están adivinando.
Una buena atribución significa que puedes responder preguntas como:
- "Nuestra funcionalidad de soporte al cliente cuesta 0,004 € por conversación. Nuestro resumidor de documentos cuesta 0,12 € por documento."
- "La funcionalidad del equipo móvil es responsable del 40% de nuestro gasto en tokens este mes."
- "Estamos gastando 800 € al mes en entornos no productivos usando modelos frontier." No puedes llegar ahí sin etiquetas de metadatos a nivel de solicitud. Y no puedes garantizar un etiquetado consistente sin una capa de registro centralizada por la que pase todo el tráfico de LLM.
)
Las herramientas que hacen el trabajo pesado
Existen cuatro niveles de herramientas para la monitorización de tokens. La mayoría de las empresas comienzan en el nivel uno y descubren rápidamente sus limitaciones. Las que han resuelto el problema de atribución de forma definitiva operan en el nivel cuatro.
Nivel 1: Paneles de proveedores (OpenAI, Anthropic)
La página de uso de OpenAI y la consola de Anthropic muestran el uso agregado por clave API, modelo y período de tiempo. Son el punto de partida de todos los equipos, y son suficientes para responder una pregunta: ¿cuánto hemos gastado este mes?
No pueden responder las preguntas que importan para la optimización: qué funcionalidad, qué equipo, qué agente, qué cambio en el prompt causó ese pico. La atribución se detiene en la clave API.
Úsalos para establecer la línea base. No intentes optimizar desde ellos.
Nivel 2: Herramientas de trazado por solicitud (LangSmith, Helicone)
LangSmith traza cada llamada en un pipeline de LangChain: recuentos de tokens, estimaciones de coste, latencia, solicitud y respuesta completas. Etiquetas las trazas con metadatos personalizados y construyes dashboards. Funciona bien para sistemas basados en LangChain. Menos útil si llamas directamente a la API del LLM sin un framework.
Helicone es un proxy que se sitúa entre tu aplicación y tu proveedor de LLM. Cambia la URL base en tu cliente y registra todo: tokens, coste, latencia y propiedades personalizadas que defines por solicitud. Open source. Compatible con OpenAI, Anthropic, Azure y otros.
Ambas herramientas te dan datos reales. Ninguna aplica nada. Si un equipo omite las etiquetas de metadatos, los datos tienen lagunas. Si una funcionalidad se pasa del presupuesto, te enteras cuando llega la factura.
Nivel 3: Proxy con controles de presupuesto (LiteLLM)
LiteLLM Proxy gestiona el enrutamiento, el balanceo de carga y el seguimiento de costes en una sola capa. Obtienes claves virtuales por equipo, límites de presupuesto, alertas de uso y un dashboard. Ideal para equipos que necesitan monitorización, enrutamiento multi-proveedor y gestión básica del gasto en una única herramienta autoalojada.
La brecha: LiteLLM es una herramienta para desarrolladores. No proporciona seguridad en tiempo real para IA, detección de amenazas a nivel de sesión, gobernanza MCP ni red teaming. Cuando empieza la conversación sobre seguridad empresarial de IA, queda fuera de alcance.
Nivel 4: Gateway de seguridad de IA empresarial (NeuralTrust, recomendado para grandes empresas)
NeuralTrust es la plataforma diseñada para equipos empresariales que necesitan monitorización de tokens, aplicación de políticas, seguridad de IA y gobernanza desde un único plano de control, no cuatro herramientas independientes unidas con cinta.
La atribución de tokens en NeuralTrust es automática. Cada llamada LLM que pasa por TrustGate se registra con recuentos de tokens completos, coste, modelo, latencia e identidad del consumidor. Defines la taxonomía de atribución una sola vez (por equipo, funcionalidad, entorno o agente) y el tráfico de cada equipo se etiqueta sin depender de que cada desarrollador lo haga correctamente. Finanzas ve los costes por unidad de negocio. Ingeniería ve los costes por funcionalidad y modelo. Cuando una funcionalidad alcanza un umbral de presupuesto, TrustGate bloquea la solicitud antes de que llegue a la API.
Pero la monitorización de tokens es solo una capa de lo que cubre NeuralTrust. Para las empresas que ejecutan agentes de IA en producción, la capa de seguridad es igual de crítica que la capa de costes:
- AI Runtime Defense: TrustGuard se conecta a cada ruta e inspecciona cada prompt y respuesta en tiempo real, con memoria de sesión que detecta ataques multi-turno — los que superan los filtros de una sola solicitud por diseño.
- Gobernanza MCP: TrustGate incluye un catálogo de más de 200 herramientas MCP con control de acceso por consumidor y auditoría por herramienta en cada invocación.
- Agent Posture Management: TrustLens descubre y evalúa cada agente de IA en la empresa, incluidos los que no pasan por el gateway.
- AI Red Teaming: El red teaming pone a prueba los modelos contra ataques adversariales antes de que lleguen a producción.
NeuralTrust está reconocida como vendor de referencia en AI Runtime Defense en el Gartner Hype Cycle for Application Security 2026, y fue reconocida en la Guía de Mercado de Gartner 2025 para AI Gateways y Guardian Agents. Está certificada ISO 27001, tiene un núcleo open source bajo licencia Apache 2.0 y es autoalojable en entornos VPC o air-gapped en el nivel empresarial.
Para las empresas en las que la pregunta sobre costes y la pregunta sobre seguridad deben responderse desde la misma plataforma, esta es la herramienta correcta. No es un proxy de monitorización con seguridad añadida a posteriori. Es una plataforma de seguridad de IA donde la monitorización es uno de los pilares nativos.
| Herramienta | Seguimiento de costes | Etiquetas de atribución | Aplicación de políticas | Seguridad en tiempo real | Autoalojable |
|---|---|---|---|---|---|
| OpenAI Dashboard | Solo agregado | Solo clave API | No | No | No |
| Anthropic Console | Solo agregado | Solo clave API | No | No | No |
| LangSmith | Por traza | Metadatos personalizados | No | No | Parcial |
| Helicone | Por solicitud | Propiedades personalizadas | Básica | No | Sí |
| LiteLLM Proxy | Por clave virtual | Clave virtual / equipos | Límites de presupuesto | No | Sí |
| NeuralTrust | Por consumidor | Taxonomía completa | Aplicación total | Sí — con memoria de sesión | Sí |
Para los equipos que empiezan su camino en la monitorización, Helicone o LiteLLM te llevan rápidamente a la atribución por solicitud. Para las empresas que necesitan monitorización, aplicación de políticas, seguridad y gobernanza en una sola plataforma (y que deben responder una pregunta sobre riesgo de IA al consejo junto a una pregunta del CFO sobre el gasto) NeuralTrust es donde termina esa conversación.
)
Qué Hacer con los Datos
La monitorización sin acción es simplemente un registro caro.
Una vez que los datos de tokens etiquetados están fluyendo, esta es la secuencia que realmente mueve los costes.
Primero: encuentra tu distribución. ¿Qué porcentaje de tus solicitudes son genuinamente simples? Menos de 500 tokens de entrada, salida corta, tarea estructurada. En la mayoría de los sistemas en producción, entre el 60 y el 70% de las solicitudes encajan en ese perfil. Esa es tu oportunidad de enrutamiento. Sin los datos, estás adivinando el porcentaje.
Identifica tus dos o tres funcionalidades más caras. Ordena por gasto total de tokens por mes y funcionalidad. Una reducción del 30% en tu funcionalidad más cara supera una reducción del 10% repartida entre todo. Céntrate donde está el dinero.
Revisa tu ratio de tokens de salida respecto a los de entrada. Un conteo alto de tokens de salida es casi siempre un problema de diseño de prompt. Los prompts que no restringen el modelo generan respuestas largas y dispersas. Añadir una instrucción simple como "responde en dos frases" a los prompts adecuados puede reducir los tokens de salida entre un 40 y un 60% sin pérdida de calidad. Consulta la guía de Compresión de Prompts para el kit de herramientas completo.
Busca oportunidades de caché. Si el mismo prompt se ejecuta 20 veces por minuto, es un problema de caché, no de generación. Consulta la guía de Estrategias de Caché para LLM para saber dónde la caché semántica resulta más rentable.
Enruta según lo que encuentres. Una vez que sabes qué funcionalidades son genuinamente complejas frente a simples, establece reglas de enrutamiento que lo reflejen. La guía de Enrutamiento de Modelos LLM cubre los mecanismos del enrutamiento basado en clasificador, en cascada y semántico. Y para la gestión del tamaño de contexto dentro de cada funcionalidad, la guía de Optimización de la Ventana de Contexto es la lectura complementaria.
La monitorización es lo que te dice si alguna de estas medidas funcionó. Los conteos de tokens antes y después por funcionalidad son tu prueba de impacto. Sin ellos, cada optimización es una suposición.
Monitorización en la Capa de Gateway
La configuración más limpia es aquella en la que la monitorización no es algo que cada equipo implemente por funcionalidad. Se aplica en la capa de infraestructura y ocurre automáticamente.
Cuando todas las llamadas a LLM pasan por un gateway de IA, obtienes atribución de tokens por defecto, para cada aplicación, desde el primer día. Nadie tiene que acordarse del registro. Nadie puede saltarse las etiquetas de metadatos. Los datos simplemente están ahí.
El AI Gateway de NeuralTrust registra cada solicitud con conteos completos de tokens, atribución de costes, modelo, latencia e identidad del consumidor. Defines las taxonomías de atribución una vez. El tráfico de todos los equipos fluye a través y queda etiquetado. Finanzas ve los costes por unidad de negocio. Ingeniería ve los costes por funcionalidad y por modelo. Cuando una funcionalidad se dispara en gasto o alcanza un umbral de presupuesto, lo detectas antes de que aparezca en la factura del mes siguiente.
Para los equipos que ya usan compresión de prompts y enrutamiento de modelos, la capa de observabilidad es lo que lo conecta todo. No puedes saber si tu estrategia de compresión está funcionando sin conteos de tokens antes y después. No puedes saber si los umbrales de enrutamiento están bien calibrados sin datos de calidad y coste por funcionalidad. La monitorización no es un añadido al final del proceso de optimización. Es la base.
Preguntas Frecuentes sobre Monitorización del Uso de Tokens
1. ¿Cómo rastro el uso de tokens en producción?
Registra cada llamada a la API de LLM con el conteo de tokens de entrada, conteo de tokens de salida, modelo, coste calculado, latencia y etiquetas de metadatos (funcionalidad, ID de usuario, entorno). Usa un proxy como Helicone o LiteLLM, una herramienta de rastreo como LangSmith o un gateway de IA que haga esto automáticamente para todo el tráfico. Los paneles de los proveedores muestran el uso agregado pero no la atribución granular que necesitas para la optimización.
2. ¿Qué metadatos debo etiquetar en cada solicitud a un LLM?
Como mínimo: nombre de funcionalidad, ID de usuario o sesión, entorno (producción/staging/dev) y modelo. Añade ID de experimento si ejecutas pruebas A/B. Estas etiquetas convierten un número de coste en un mapa de costes, permitiéndote ordenar el gasto por centro de coste y identificar qué funcionalidades están disparando la factura.
3. ¿Cómo atribuyo los costes de LLM a equipos o funcionalidades?
Usa claves virtuales o etiquetas de metadatos a nivel de solicitud. LiteLLM admite claves virtuales por equipo con límites de presupuesto separados. Helicone y LangSmith admiten propiedades personalizadas por solicitud. Un gateway de IA puede imponer una taxonomía de etiquetado para que el tráfico de cada equipo quede atribuido automáticamente sin depender de que cada desarrollador añada la etiqueta correcta.
4. ¿Por qué son tan caros mis tokens de salida?
Los tokens de salida cuestan más que los de entrada en la mayoría de los modelos. Para GPT-4o, los tokens de salida cuestan cuatro veces más que los de entrada a mediados de 2026 (10 frente a 2,50 dólares por millón). Los conteos altos de tokens de salida son casi siempre un problema de diseño de prompt. Los prompts que no restringen la longitud de respuesta generan muchos más tokens de los necesarios. Añadir instrucciones de longitud a tu prompt de sistema es el arreglo más rápido.
5. ¿Necesito una herramienta de monitorización separada o puedo usar el panel del proveedor?
Los paneles de los proveedores (OpenAI, Anthropic) muestran el uso agregado por clave de API y periodo de tiempo. No admiten atribución a nivel de funcionalidad o usuario. Para sistemas en producción con múltiples funcionalidades y equipos, necesitas registros a nivel de solicitud con metadatos. Un proxy, herramienta de rastreo o gateway te da esto sin cambios significativos en el código.
6. ¿Con qué frecuencia debo revisar los datos de uso de tokens?
Semanalmente como mínimo. Diariamente para sistemas de alto tráfico. El objetivo es detectar regresiones pronto: una nueva funcionalidad inesperadamente cara, cambios en prompts que duplicaron los conteos de tokens de salida, un fallo de caché que está costando dinero real. Las revisiones mensuales significan que descubres lo que salió mal cuando llega la factura.
Related articles
- Optimización de Tokens de IA: Guía Completa para Reducir los Costes de LLM
- Compresión de Prompts: Reduce los Costes de Tokens Sin Perder Calidad
- Estrategias de Caché para LLM: Caché de Prompts, Caché Semántico y Cuándo Usar Cada Uno
- Reducción de Costes de LLM: 12 Estrategias para Bajar los Costes de Inferencia de IA
- Optimización Ventana de Contexto: 6 Estrategias para LLMs (2026)
- Enrutamiento de Modelos LLM: Envía Consultas al Modelo Correcto Automáticamente
- Control de Longitud de Salida: Cómo Evitar que los LLMs Generen Tokens de Más
- LLM Batching e Inferencia Asíncrona: Reduce Costes en Cargas de IA de Alto Volumen
- Fine-Tuning vs Prompting: Comparativa de Costes para IA Empresarial
Sobre el Autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización para LLMs. Especializado en búsqueda potenciada por IA, estrategia de contenidos, desarrollo de enlaces y SEM. Conecta en LinkedIn.
NeuralTrust es una plataforma de seguridad para agentes de IA, reconocida en la Guía de Mercado de Gartner 2025 para AI Gateways y Guardian Agents, el Gartner Hype Cycle for Application Security 2026 y el KuppingerCole Leadership Compass 2025 para Generative AI Defense. Certificada ISO 27001. Sede central en Barcelona.
)