El coste de la IA no se descontrola por el precio del token, sino por la latencia con la que se conoce el consumo

Este artículo propone un criterio de diseño: tratar la latencia del dato de consumo como un requisito de arquitectura, con objetivo medible, igual que la latencia de una API.

1. La pregunta que llega siempre

Cuando la IA generativa pasa de piloto a servicio, la primera pregunta de un comité de dirección es siempre la misma: «¿cuánto me va a costar?». Es razonable y, con el enfoque habitual, casi imposible de responder con honestidad: el coste de una carga de IA no depende de la plantilla ni de las licencias, sino del número de peticiones, del contexto que cada una arrastra, de los tokens de salida, del razonamiento que se active y del modelo elegido para cada tarea.

Una consecuencia práctica: el coste unitario es variable y se decide en el código y en la configuración, no en el contrato. Un cambio de prompt, una herramienta nueva que devuelve documentos largos o un agente que reintenta en bucle mueven el gasto sin que cambie ni una tarifa. Por eso el control tiene que estar donde se toman esas decisiones y con un reloj mucho más rápido que el de facturación.

2. El error habitual: negociar precio antes de medir

El reflejo corporativo es negociar descuentos por volumen o compromisos de consumo. Es una palanca legítima, pero tiene dos problemas cuando se aplica primero:

• Sin medición no hay base de negociación. Un compromiso de gasto dimensionado sobre un consumo que nadie ha observado a nivel de equipo o de aplicación se queda corto o sobrado.
• El descuento no corrige comportamientos. Un agente que reenvía en cada turno el contexto completo seguirá haciéndolo con una tarifa menor; solo costará algo menos un error que debería haberse detectado a las pocas horas.

La FinOps Foundation, en su guía de FinOps para IA, recoge justo esta lógica: recomienda «seguir y revisar de forma regular los costes y el uso de IA, fijar cuotas, etiquetar recursos» (FinOps Foundation, FinOps for AI Overview). Señala además una dificultad específica de los tokens: el recuento en la entrada del usuario no coincide necesariamente con el recuento del prompt real que llega al modelo.

3. Los cuatro relojes del dato de consumo

Un mismo euro de IA se «ve» en momentos distintos según dónde se mire. Conviene poner cifras a esos relojes, porque en ellos está el diagnóstico:

Las cifras de los relojes 3 y 4 proceden de la documentación de Microsoft Learn sobre los datos de Cost Management: los cargos del periodo abierto son estimados y se actualizan varias veces al día, y «el uso puede seguir acumulándose y cambiando hasta el quinto día posterior al final del periodo» (Understand Cost Management data); y los datos de coste se refrescan cada cuatro horas, sin que llamar más a menudo aporte datos nuevos (Manage costs with automation). Las guías de arquitectura de coste del propio marco Well-Architected describen un retraso de ingesta de 24–72 h para los costes reales (Collect and review cost data).

La lectura es incómoda: si el único reloj que alguien mira es el 3 o el 4, la organización opera con un retraso de uno a tres días en el mejor caso, y de semanas si la revisión es mensual. En ese intervalo, y como ejemplo hipotético, una carga mal configurada podría consumir una parte importante del presupuesto antes de que nadie lo vea. Los relojes 1 y 2 son los que convierten la latencia en minutos.

4. Mecanismos que recortan la latencia

4.1 Cuota por área, aplicada en el punto de entrada

El mecanismo más eficaz es el más simple: que ninguna aplicación hable directamente con el modelo, sino a través de una pasarela que aplica una cuota por consumidor. En Azure API Management, la política llm-token-limit permite fijar un límite en tokens por minuto, una cuota por periodo (horario, diario, semanal, mensual o anual) o ambos, sobre una clave arbitraria: suscripción, dirección de origen o cualquier expresión. Al superar el límite de ritmo devuelve 429; al superar la cuota, 403 (Limit large language model API token usage).

Es asignar el presupuesto antes de gastarlo: la cuota se reparte por área o producto y el exceso se detiene en el borde. La propia documentación presenta el reparto de tokens por minuto entre equipos y departamentos como el escenario central de la pasarela de IA (AI gateway in Azure API Management). Una aplicación práctica de este criterio, publicada en este mismo sitio, es el control de acceso a modelos con cuota por área y registro por inferencia.

Dos matices que conviene no olvidar: el límite de ritmo «nunca es completamente exacto» por la naturaleza distribuida de la arquitectura de limitación (Advanced request throttling), y los contadores se llevan por pasarela y región, sin agregarse en toda la instancia. Una cuota de pasarela es un freno, no un libro contable.

La cuota de capacidad que el propio servicio de modelos asigna por suscripción, región y modelo (tokens por minuto) tampoco sustituye a la medición de gasto: la documentación aclara que la estimación de tokens que se usa para el límite de ritmo no es el recuento que se usa para facturar, que se calcula al terminar el procesamiento (Manage Azure OpenAI quota).

4.2 Registro por inferencia con dimensiones de negocio

Si la pasarela frena, el registro por inferencia explica. La política llm-emit-token-metric envía a Application Insights métricas de consumo de tokens (totales, de entrada y de salida, y en vista previa también de caché y razonamiento) y admite hasta cinco dimensiones personalizadas además de las predeterminadas, como producto o suscripción (LLM emit token metric policy). La disciplina de diseño es decidir qué dimensiones se necesitan para atribuir el gasto: área, producto, entorno, tipo de tarea y modelo. Hay un límite de cardinalidad que respetar: Azure Monitor admite un máximo de 10 claves de dimensión por métrica y 50.000 series temporales activas por región y suscripción en una ventana de 12 horas, y API Management impone además un tope de 100 valores únicos por dimensión y 1.000 series activas por espacio de nombres; al alcanzarlo, los datos nuevos se descartan sin aviso. Una dimensión con valores abiertos (usuario, petición) rompe la métrica en silencio.

4.3 Alertas con umbral diario y mensual

Con la atribución resuelta, las alertas se vuelven triviales y útiles. Dos umbrales, con dueño nombrado:

• Diario, para detectar anomalías en horas (un bucle, un cambio de prompt, una integración nueva).
• Mensual acumulado, para detectar derivas lentas y gestionar la previsión.

Los presupuestos de la herramienta de costes del proveedor son el respaldo, no la primera línea: heredan su latencia.

4.4 Modelo por tarea y trabajo diferible

No todas las peticiones necesitan el modelo más capaz. Microsoft propone, en su guía de optimización de costes de IA para startups, usar un modelo pequeño para la clasificación o extracción de primera pasada y escalar a un modelo mayor solo cuando el primero no está seguro, y reevaluar la elección de modelo cada trimestre porque precios y calidad se mueven rápido. Para el trabajo que admite espera (refrescos de índices, evaluaciones, resúmenes asíncronos), la API por lotes se ofrece con un 50 % de descuento frente al tiempo real a cambio de una ventana de hasta 24 horas (Optimize cost for AI workloads on Azure). El criterio es mantener la selección de modelo como configuración con dueño, no como constante enterrada en el código.

También conviene acotar la salida: en modelos de razonamiento, los tokens de razonamiento se facturan como tokens de salida, de modo que una petición que «piensa más» cuesta más aunque la respuesta visible sea corta, y existen parámetros para limitar el total generado (Azure OpenAI reasoning models).

4.5 La caché de contexto como palanca de coste

En flujos multiturno y en agentes que trabajan sobre código, cada petición reenvía el contexto acumulado: instrucciones, definiciones de herramientas, ficheros leídos, historial. La caché de prompts abarata justamente ese prefijo repetido, pero su economía depende del proveedor y del modelo, y por eso debe revisarse en la documentación de precios de cada uno antes de dar nada por supuesto:

• En Azure OpenAI, las lecturas de caché se facturan con descuento sobre el precio de entrada; en los modelos anteriores a GPT-5.6, las cachés en memoria suelen vaciarse tras 5–10 minutos de inactividad y siempre antes de una hora desde el último uso; en GPT-5.6 y posteriores, la retención mínima configurable es de 30 minutos y el servicio puede conservar el prefijo durante más tiempo. En ambos casos la coincidencia exige un prefijo idéntico de al menos 1.024 tokens. En los modelos anteriores a la familia GPT-5.6 escribir en caché no cuesta más; desde esa familia, las escrituras pueden tener cargo propio, y se recomienda un identificador de caché (prompt_cache_key) para mejorar los aciertos (Prompt caching).
• En la API de Anthropic, con carácter general, escribir en una caché de 5 minutos cuesta 1,25 veces el precio base de entrada, en una de 1 hora 2 veces, y leer 0,1 veces, con excepciones por modelo (Prompt caching, Anthropic).

Con esos multiplicadores generales, la aritmética es instructiva: un prefijo que se lee al menos una vez dentro de su vida útil sale a cuenta (1,25 + 0,1 = 1,35 frente a 2,0 sin caché), pero un prefijo que se escribe y nunca se reutiliza cuesta más que no cachear. Y la cifra no es universal: en algunos modelos de la familia 5 la lectura baja a 0,05× o 0,025×, así que el punto de equilibrio cambia y hay que calcularlo con la tabla de precios del modelo concreto. La caché es una palanca, no un descuento automático: exige estabilizar el prefijo (instrucciones y herramientas al principio, contenido variable al final) y medir la tasa de aciertos con el registro por inferencia del apartado 4.2.

5. Trade-offs que hay que decidir explícitamente

Nota sobre la última fila: la telemetría propia calcula un coste estimado (tokens por tarifa publicada) que no coincidirá al céntimo con la factura. Concilia periódicamente y documenta la desviación aceptable.

6. Arquitectura de referencia

  Aplicaciones / agentes / asistentes de programación
                     │  (clave por área y producto)
                     ▼
        ┌──────────────────────────────┐
        │  Pasarela de acceso a modelos │──► cuota por área (ritmo + periodo)
        │  (único camino de red)        │──► selección de modelo por tarea
        └──────────────┬───────────────┘
                       │ métrica por inferencia (tokens, caché, modelo, área)
                       ▼
        ┌──────────────────────────────┐
        │  Telemetría + almacén de      │──► alerta diaria / mensual → dueño
        │  consumo atribuido            │──► panel de showback por área
        └──────────────┬───────────────┘
                       │ conciliación periódica
                       ▼
        Gestión de costes del proveedor / factura (reloj lento)

Principios: un solo camino hacia los modelos; cada clave identifica a un responsable; la telemetría se emite al inferir y no se reconstruye después; la factura concilia, no opera.

7. Qué hacer el lunes

1. Fija el objetivo de latencia. Decide por escrito en cuánto tiempo debe conocerse el consumo de cada área (por ejemplo, el mismo día) y mide cuánto tardas hoy. Si la respuesta es «al cierre», ya tienes el problema delimitado.
2. Cierra el camino directo. Inventaría quién llama a modelos sin pasar por una pasarela y fija una fecha para que todo el tráfico de IA corporativo pase por un único punto con clave por área.
3. Asigna cuota y dueño por área. Una cuota por periodo y un nombre responsable de cada una. Sin dueño no hay alerta que importe.
4. Activa la telemetría por inferencia con pocas dimensiones (área, producto, entorno, modelo, tipo de tarea) y define dos alertas: diaria y mensual acumulada.
5. Revisa la política de caché y de modelo. Estabiliza los prefijos de los prompts, mide la tasa de aciertos y documenta qué tareas pueden ir a un modelo menor o a procesamiento por lotes.

Fuentes

Todas las páginas se consultaron entre el 3 y el 4 de octubre de 2026. Las cifras de precios, caché y latencia pueden cambiar: conviene revalidarlas antes de tomar decisiones.

• FinOps Foundation. FinOps for AI Overview
• Microsoft Learn. Understand Cost Management data
• Microsoft Learn. Manage costs with automation
• Microsoft Learn. Architecture strategies for collecting and reviewing cost data
• Microsoft Learn. Limit large language model API token usage (llm-token-limit)
• Microsoft Learn. AI gateway in Azure API Management
• Microsoft Learn. Advanced request throttling with Azure API Management
• Microsoft Learn. Emit large language model API token metrics (llm-emit-token-metric)
• Microsoft Learn. Manage Azure OpenAI quota
• Microsoft Learn. Optimize cost for AI workloads on Azure
• Microsoft Learn. Azure OpenAI reasoning models
• Microsoft Learn. Prompt caching
• Anthropic. Prompt caching