
Monitoreo de Costes LLM: Detecta el Gasto Antes de que se Dispare (2026)
El monitoreo de costes LLM es la diferencia entre una factura sorpresa de $412 y un ping en Slack al 80% del presupuesto. Claude Sonnet 5 cobra $3.00 por millón de tokens de entrada este mes, y un solo bucle de agente descontrolado puede quemar eso en una tarde. La mayoría de los equipos configuran el rastreo en un día; la alerta es la parte que se saltan.
Puntos clave:
- El monitoreo de costes LLM asigna un conteo de tokens y una estimación en dólares a cada request, y luego agrega por modelo y equipo.
- Rastrea cinco métricas: tokens por request, coste por función/equipo/modelo, tasa de aciertos de caché, coste por conversación, tasa de picos.
- Los presupuestos de LiteLLM, las trazas de Langfuse o Datadog LLM Observability configuran la visibilidad del gasto en menos de un día.
- Los dashboards muestran estimaciones; los precios de entrada en caché y los descuentos por lotes hacen que la factura suele quedar por debajo.
¿Qué Rastrea Realmente el Monitoreo de Costes LLM?
El monitoreo de costes LLM consiste en asignar un conteo de tokens y una estimación en dólares a cada request de LLM, y luego agregar esas estimaciones por modelo, función y equipo para poder alertar sobre el gasto antes de que llegue la factura. La estimación se calcula por request a partir de los precios publicados de tokens, se consolida según las etiquetas que asignes a la llamada, y se compara contra un presupuesto definido de antemano.
La matemática subyacente es neutral respecto al proveedor. La respuesta de uso de cada proveedor desglosa los tokens en campos, y la documentación de costes de Datadog documenta las relaciones explícitamente. Las convenciones semánticas de GenAI de OpenTelemetry estandarizan esos mismos campos entre proveedores, así que un dashboard construido sobre ellas no queda atado a uno solo.
| Campo | Qué cuenta | Se factura a |
|---|---|---|
| input_tokens | Todo lo que envías: system prompt, historial, contexto recuperado, la pregunta | Tarifa base de entrada |
| output_tokens | Todo lo que genera el modelo | Tarifa base de salida (3-6x entrada) |
| cache_read_tokens | Entrada reutilizada de una caché anterior | 0.1x-0.25x de la entrada base |
| cache_write_tokens | Entrada escrita en la caché por primera vez | ~1.25x entrada base (TTL de 5 min en Anthropic) |
| reasoning_tokens | Cadena de pensamiento interna, subconjunto de la salida | Tarifa de salida |
Tres relaciones hacen la mayor parte del trabajo: tokens totales = entrada + salida; entrada = no cacheada + cache_read + cache_write; y los tokens de razonamiento van dentro de la salida, a tarifa de salida. Si las capturas bien, la estimación por request se mantiene cercana; si las ignoras, el dashboard se desvía de la factura cada mes. El monitoreo de costes es un pilar de la observabilidad de IA; el tracing y las evaluaciones son los otros dos, y comparten este mismo vocabulario de campos.
Tu dashboard muestra una estimación; la factura es la única métrica de coste que nunca se cachea.
¿Cuánto cuesta 1 millón de tokens en un LLM?
Depende del modelo y la dirección: 1M de tokens cuesta $0.14 como entrada de DeepSeek-V4 y $15.00 como salida de GPT-5.6 Terra, una diferencia de 100x en la misma unidad. Aquí van cuatro modelos de nuestra investigación de precios del 14 de julio de 2026, verificados contra las páginas oficiales:
| Modelo | Entrada / 1M tokens | Salida / 1M tokens | Entrada en caché / 1M tokens |
|---|---|---|---|
| Claude Sonnet 5 | $3.00 | $15.00 | $0.30 |
| GPT-5.6 Terra | $2.50 | $15.00 | $0.25 |
| Gemini 2.5 Pro | $1.25 | $10.00 | $0.31 |
| DeepSeek-V4 | $0.14 | $0.28 | $0.003 |
Fuentes: precios de OpenAI y precios de Anthropic. Una nota: Claude Sonnet 5 tiene precios introductorios de $2.00 entrada / $10.00 salida hasta el 31 de agosto de 2026, luego vuelve a los números de arriba.
Las 5 Métricas que Realmente Importan
Cinco métricas cubren el seguimiento de costes LLM, y la mayoría de los equipos solo alertan sobre dos. Empieza por las dos primeras filas: los tokens por request detectan la hinchazón del prompt el día que aparece, y el coste por equipo es el número que finanzas eventualmente pide. Las otras tres refinan el panorama una vez que esas están conectadas.
| Métrica | Cómo calcularla | Por qué importa | Umbral de alerta |
|---|---|---|---|
| Tokens por request | Suma entrada + salida por llamada, agrupa por función | La hinchazón de prompts y el relleno de contexto aparecen aquí primero | +30% sobre la mediana de 7 días |
| Coste por función / equipo / modelo | Suma el coste estimado, agrupa por etiqueta o clave virtual | La base real de chargebacks y presupuestos | 80% del presupuesto mensual |
| Tasa de aciertos de caché | cache_read / tokens de entrada totales | Tasas bajas significan que pagas precio completo por prompts repetidos | Por debajo de 50% en tráfico estable |
| Coste por conversación / sesión | Suma el coste de todos los turnos de una sesión | Expone agentes multi-turno descontrolados que la vista por request no ve | 2x la sesión del percentil 90 |
| Tasa de picos / anomalías | Cambio día a día en el gasto total | La única métrica que detecta un bucle roto antes de la factura | +50% día a día |
Una nota sobre granularidad: Datadog almacena el coste a nivel de request en nanodólares (mil millonésimas de dólar) según su documentación de costes. A $0.14 por millón de tokens, un solo request de DeepSeek-V4 puede costar menos de una milésima de centavo, así que agrega antes de redondear, o el tráfico de modelos pequeños desaparece del reporte.
Si no rastreas nada más, rastrea las filas uno y dos. Los tokens por request son la advertencia más temprana que tienes; el coste por equipo es el que sobrevive al contacto con un departamento de contabilidad.
Tres Formas de Configurar el Monitoreo de Costes LLM
Ninguna de las páginas mejor posicionadas para esta consulta incluye una sola línea de código ejecutable, así que aquí van tres setups funcionales. Cada uno se pone en marcha en menos de un día, y se combinan: nosotros ejecutamos los dos primeros juntos.
Lo que realmente ejecutamos en producción: en nuestro setup, cada agente cliente habla con el proxy de LiteLLM a través de su propia clave virtual, con un presupuesto mensual en cada clave y Langfuse trazando cada request detrás del proxy. Cuando desplegamos los dos juntos, la división del trabajo era el punto: el proxy aplica los límites, y las trazas explican qué los consumió. Cada una de nuestras claves de cliente también lleva un tpm_limit de 100,000 tokens por minuto como segundo fusible; según la documentación de LiteLLM, el proxy rechaza requests una vez que se alcanza un límite, y ese comportamiento documentado es en lo que confiamos, no un benchmark que medimos nosotros. Nuestra configuración omite LiteLLM 1.82.7 y 1.82.8 por completo, las dos versiones afectadas por el incidente de cadena de suministro de marzo de 2026, y fija la etiqueta de imagen en lugar de flotar en latest.
Proxy de LiteLLM: claves virtuales + presupuestos
Techsy ejecuta un setup de proxy LiteLLM en producción con una clave virtual por cliente y un presupuesto mensual en cada clave. El request de abajo es la forma documentada en la documentación de virtual_keys de LiteLLM: según esa documentación, una vez que el gasto acumulado en esta clave cruza $50 en un mes, el proxy rechaza requests adicionales con un error de presupuesto excedido en lugar de registrar una advertencia después del hecho.
curl -X POST http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"key_alias": "client-acme-search",
"max_budget": 50.0,
"budget_duration": "monthly",
"tpm_limit": 100000,
"models": ["anthropic/claude-sonnet-4-5"]
}'Haz la aritmética contra los precios publicados: a $3.00 / $15.00 por millón de tokens de Claude Sonnet 5, $50 compra aproximadamente 16.7M de tokens de entrada o 3.3M de tokens de salida, aproximadamente una semana de tráfico para uno de nuestros agentes cliente más ligeros. Ese es exactamente el radio de explosión que queremos. El tpm_limit es el segundo fusible: un bucle descontrolado dispara los 100K tokens por minuto mucho antes de disparar el presupuesto mensual. La atribución por usuario funciona igual a través del endpoint de usuarios, y nuestra guía de las mejores herramientas de gateway LLM cubre cuándo un proxy se gana su lugar versus cuándo es solo otro salto más.
Langfuse: tracing de costes con @observe
El autocompletar de Google empareja "langfuse monitoring" con esta consulta, y por buena razón: Langfuse es el estándar de tracing open source. Su SDK de Python envuelve tu cliente de proveedor para que cada llamada se convierta en una traza que lleva conteos de tokens y un coste calculado, según la documentación de tracing de Langfuse:
# pip install langfuse openai
from langfuse import observe
from langfuse.openai import openai # drop-in wrapper, auto-traces
@observe()
def answer(question: str):
return openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": question}],
)
answer("what is llm cost monitoring")
# the trace now carries usage.total_tokens and total_cost,
# priced from Langfuse's model price cardsEl coste aterriza en la traza sin que tengas que hacer matemática de tokens de tu lado; agrupa trazas por sesión o id de usuario para consolidados por función, y autoalója si los datos no pueden salir de tu red.
Datadog LLM Observability: si ya estás dentro
Si tu equipo ya despacha agentes de Datadog, su documentación de costes LLM es la referencia individual más profunda en esta página: coste a nivel de request en nanodólares, cost_tags personalizados para desgloses por equipo y función, y una sección real de resolución de problemas para brechas de coste parcial. El límite honesto: es solo Datadog. Las métricas no salen de la plataforma, y no hay alternativa open source si los precios dejan de encajar. Elígelo para consolidación, no para flexibilidad.
¿Cómo Configuras Presupuestos, Alertas y Chargeback?
Lo configuras en tres capas: un límite de presupuesto que rechaza requests al tope, una alerta por webhook que se dispara a un umbral porcentual antes del tope, y claves virtuales por equipo que convierten el showback y el chargeback en una consulta en lugar de una discusión. LiteLLM incluye las tres de forma nativa; los patrones se transfieren a cualquier gateway con presupuestos a nivel de clave.
Un presupuesto que solo cuenta es un reporte; un presupuesto que rechaza requests al tope es un control.
Alertas que se disparan antes del pico
Configura la alerta al 80% del tope, no al 100%. LiteLLM incluye alertas de Slack integradas: configura alerting: ["slack"] y alerting_threshold: 80 en general_settings, apunta la variable de entorno SLACK_WEBHOOK_URL a un canal, y un mensaje como este llega cuando una clave cruza el umbral:
{
"text": "LLM budget alert: client-acme-search spent $40.18 of its $50.00 monthly cap (80.4%). Top model: anthropic/claude-sonnet-4-5."
}Al 80%, un humano todavía tiene días para actuar: bajar el modelo, ajustar el prompt, o subir el tope con un nombre en la aprobación. Una alerta al 100% es una autopsia.
De showback a chargeback
Showback significa que cada equipo ve su propio gasto; chargeback significa que sale de su presupuesto. Ambos funcionan con un ingrediente: una clave virtual por equipo, etiquetada al crearla. El reporte mensual es entonces un group-by sobre la tabla de gasto:
| Equipo | Presupuesto mensual | Gasto hasta la fecha | Estado |
|---|---|---|---|
| search | $50 | $40.18 | alerta disparada al 80% |
| support-chat | $200 | $112.40 | en camino |
| evals-batch | $30 | $29.97 | tope alcanzado, rechazando |
| sandbox | $10 | $1.06 | en camino |
Formato de ejemplo, no datos de clientes. La fila de evals-batch es el patrón funcionando como debe: el trabajo por lotes corrió hasta su tope y se detuvo, en lugar de sangrar silenciosamente hacia la factura. El comportamiento de aplicación está documentado en la documentación de virtual_keys de LiteLLM, incluyendo cómo se reinicia la duración del presupuesto.
¿Por Qué Tu Dashboard No Coincide Con la Factura?
Porque los dashboards facturan a precio de lista mientras las facturas aplican descuentos que tu monitoreo nunca ve. La entrada en caché aterriza a 0.1x a 0.25x del precio base, los lotes a la mitad, y los tokens de razonamiento se facturan a tarifa de salida desde dentro del conteo de salida. Cuando los dos números divergen, la factura suele ser el menor, y la brecha es casi siempre uno de cuatro modificadores.
| Modificador de precio | Multiplicador típico | Efecto en tu estimación |
|---|---|---|
| Entrada en caché (lectura de caché) | 0.1x-0.25x de la entrada base | El dashboard queda alto si factura los aciertos de caché a precio completo |
| API por lotes | 0.5x en entrada y salida | Los trabajos asíncronos cuestan la mitad del número rastreado |
| Tokens de razonamiento | 1x tarifa de salida, contados dentro de la salida | Las cadenas largas de pensamiento queman presupuesto de salida en silencio |
| Escritura en caché | ~1.25x entrada base | El primer request en una ventana de caché cuesta ligeramente más |
El catálogo abierto pydantic/genai-prices muestra por qué estos multiplicadores difieren por modelo: cada proveedor define sus propios factores de caché y lotes, así que una tabla de precios hardcodeada se desvía el día que un proveedor revisa sus tarjetas. La documentación de costes de Datadog documenta la otra mitad del problema, brechas de coste parcial donde un campo de token faltante devuelve COST UNAVAILABLE para un request. Revisa ahí cuando el dashboard lee más bajo que la factura; revisa la tabla de descuentos cuando lee más alto. El mecanismo detrás del mayor multiplicador es la caché de prompts LLM, y una tasa alta de aciertos de caché es la razón más común por la que una estimación rastreada supera la factura real.
Una estimación de costes sin descuentos de caché y lotes es un techo, no un pronóstico.
¿Qué Herramientas Hacen Realmente el Seguimiento de Costes LLM?
Seis herramientas cubren la mayoría de los setups de producción: Langfuse, LiteLLM, Helicone y Portkey del lado open source y de gateway, Datadog y Braintrust del lado comercial. La división honesta es aplicación versus observabilidad: un proxy puede rechazar requests a un presupuesto, mientras que una herramienta de tracing mide el gasto después del hecho. La mayoría de los stacks maduros terminan con una de cada una.
| Herramienta | Tipo | Enfoque de seguimiento de costes | Plan gratuito | Elige esta si... |
|---|---|---|---|---|
| Langfuse | Open source | Coste por traza desde tarjetas de precios de modelos, autoalojable | Self-hosted gratis; plan hobby gratis en la nube | Quieres open source y ser dueño de los datos |
| LiteLLM | Proxy open source | Presupuestos por clave y equipo aplicados en el gateway | Gratis (OSS); enterprise de pago | Necesitas presupuestos que rechacen requests, no solo que cuenten |
| Helicone | Gateway open source | Registros de coste a nivel de proxy por clave y modelo | Plan gratuito con límites de tasa | Quieres un cambio de proxy de una línea sin cambios de SDK |
| Portkey | Gateway comercial | Presupuestos de claves virtuales más analítica de costes | Plan developer gratuito | Quieres gateway, prompts y evaluaciones en un panel |
| Datadog LLM Observability | Comercial | Métricas de request en nanodólares más cost_tags | Prueba de 14 días | Ya ejecutas Datadog para todo lo demás |
| Braintrust | Comercial | Gasto vinculado a evaluaciones por proyecto | Plan gratuito | Tu trabajo de costes empieza desde evaluaciones, no desde facturas |
Una advertencia sobre el contenido de proveedores en este espacio: la propia comparación de herramientas de seguimiento de costes de Braintrust de 2026 se posiciona primera y omite todas las opciones open source de la tabla de arriba. Lee los listicles de proveedores por sus datos, no por sus rankings.
Para un equipo que empieza desde cero, ejecutaríamos LiteLLM al frente y Langfuse detrás: el proxy aplica los presupuestos, las trazas los explican, y la combinación no cuesta nada hasta que cruzas a planes alojados. Si estás sopesando los dos estándares de tracing, nuestro desglose de Langfuse vs Langsmith profundiza en esa elección, y el roundup de las mejores plataformas de observabilidad de IA cubre el campo completo.
Del Monitoreo a Reducir Costes
El monitoreo muestra a dónde va el dinero; el siguiente paso es decidir cuánto va ahí. Las tres palancas, en orden de retorno: cachear entrada repetida, enrutar requests fáciles a modelos más baratos, y reducir el modelo donde la calidad todavía aguanta. Nuestra guía para reducir costes de API LLM cubre cada palanca, y la comparativa de precios de API LLM es el insumo para toda la matemática de arriba.
Nuestra perspectiva: cuando el gasto de LLM de un cliente le sorprende, monitoreamos primero y cortamos segundo, nunca al revés. Los equipos que cachean antes de medir terminan cacheando los prompts equivocados. El monitoreo te dice a dónde va el dinero; la caché y el enrutamiento deciden cuánto va ahí. Si tu factura ya duele, obtén una consulta gratuita y miramos los números contigo.
Sobre el Autor
Mert Batur es Co-Fundador de Techsy.io, donde el equipo despacha agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre el stack de herramientas LLM que el equipo de Techsy realmente usa en producción. Conecta en LinkedIn.
Preguntas Frecuentes
¿Cuánto cuesta 1 millón de tokens en un LLM?
A precio de lista, desde $0.14 hasta $15 por millón dependiendo del modelo y la dirección: la entrada de DeepSeek-V4 cuesta $0.14 por millón, mientras que la salida de GPT-5.6 Terra cuesta $15. Los tokens de salida cuestan de 3 a 6 veces la tarifa de entrada en todos los proveedores principales. La tabla de la primera sección tiene cuatro modelos, y nuestra comparativa de precios de API LLM tiene los diecisiete, verificados contra las páginas de OpenAI y Anthropic en julio de 2026.
¿Qué es la optimización de costes LLM?
La práctica de reducir el coste por request sin bajar la calidad: caché de prompts para entrada repetida, enrutamiento de tareas fáciles a modelos más baratos, APIs por lotes para trabajo asíncrono, y dimensionar el modelo por función. El monitoreo de costes LLM es el prerrequisito, ya que no puedes optimizar lo que no has atribuido. La tasa de aciertos de caché y el coste por función son las dos métricas que apuntan a las palancas más grandes primero.
¿Por qué los LLMs son tan caros?
La inferencia está limitada por cómputo: cada token generado ejecuta un forward pass completo del modelo en GPUs, y los modelos de razonamiento gastan tokens extra pensando antes de responder, facturados a tarifas de salida. Los system prompts largos multiplican ese coste en cada request. La factura crece con la verbosidad en ambos lados de la llamada, por eso los tokens por request son la primera métrica que vale la pena vigilar.
¿Cuánto cuesta un LLM en EE.UU.?
Los precios de API están denominados en USD y son globales: OpenAI, Anthropic y Google cobran el mismo precio de lista por millón de tokens ya sea que el request se origine en Ohio o en Osaka. Las diferencias regionales aparecen en el self-hosting, donde las horas de GPU varían por región de nube, y en plataformas alojadas que agregan margen. Para trabajo de API, la ubicación cambia la latencia, no el precio.
¿Cómo rastreo costes de LLM por equipo?
Emite una clave virtual por equipo a través de un proxy como LiteLLM, etiqueta cada clave con el nombre del equipo al crearla, y agrega el gasto por esa etiqueta. Cada request entonces lleva atribución desde el momento en que se hace, sin parsear logs. La tabla de showback en la sección de presupuestos de arriba es el producto final: equipo, presupuesto mensual, gasto hasta la fecha, estado.
Langfuse vs Datadog para seguimiento de costes LLM: ¿cuál elijo?
Elige Langfuse si quieres open source, self-hosting y datos que controlas; es gratis de ejecutar y traza el coste por request desde el primer momento. Elige Datadog solo si tu equipo ya lo ejecuta para infraestructura, ya que sus funciones de costes LLM no salen de la plataforma. Para la mayoría de los equipos que empiezan de cero, Langfuse más un proxy de LiteLLM supera a cualquiera de las dos opciones solas.
¿Los costes estimados de LLM coinciden con la factura real?
No, y generalmente la factura es menor. Los dashboards facturan a precio de lista mientras la entrada en caché aterriza a 0.1x a 0.25x y los trabajos por lotes a 0.5x, así que una carga de trabajo con mucha caché ve la factura real muy por debajo de la estimación rastreada. Los campos de token faltantes empujan el error en la otra dirección. La tabla de desviación de arriba lista cada multiplicador y dónde buscar.
¿Cómo alerto sobre picos de gasto en LLM?
Configura una alerta de umbral al 80% del presupuesto mensual de cada equipo, entregada a Slack por webhook, más una alerta de anomalía día a día al +50% para bucles que queman rápido. LiteLLM incluye el patrón de umbral de forma nativa a través de su configuración alerting_threshold. Una alerta al 80% deja días para reaccionar; una alerta al 100% solo confirma que el tope hizo su trabajo.
¿Existe un rastreador de costes LLM gratuito?
Sí, tres creíbles. Langfuse self-hosted es gratis y open source, con un plan hobby gratis en la nube según la página de precios de Langfuse. Los presupuestos de clave integrados de LiteLLM no cuestan nada en el proxy open source. El plan gratuito de Helicone cubre registros de coste a nivel de proxy con límites de tasa. Los planes gratuitos cubren el monitoreo; la aplicación y las alertas a escala es donde empiezan los planes de pago.
Conclusión
Elige una ruta de setup hoy, porque la alerta que vas a querer en seis semanas toma una tarde configurarla ahora. La versión corta:
- Rastrea tokens por request y coste por equipo primero; agrega las otras tres métricas una vez que esas funcionen.
- Un presupuesto que rechaza requests es un control; uno que solo cuenta es un reporte.
- Configura la alerta al 80%, en Slack, antes de que la factura pueda sorprender a alguien.
- Tu dashboard es una estimación; los precios de entrada en caché y por lotes hacen que la factura usualmente quede por debajo.
Si prefieres que alguien mire tus números contigo, obtén una consulta gratuita.