Hay un patrón que aparece repetidamente en equipos que llevan meses ejecutando IA en producción: configuran dashboards para monitorizar el gasto en LLM, crean alertas para cuando los costes se disparan, y revisan las facturas cuidadosamente a posteriori.
Todo eso es útil. Nada de eso evita que el pico ocurra.
Validar costes después de llamar al modelo es el error más caro en operaciones de IA. Para cuando tu alerta se dispara, ya has gastado el dinero.
En 30 segundos
Monitorizar costes está bien, pero no evita el gasto excesivo. La única forma de controlar presupuesto de verdad es decidir antes de ejecutar si una request puede pasar.
Qué te llevas en este artículo:
- Un modelo práctico de control de costes pre-ejecución
- Una fórmula simple para estimar coste por request
- Un ejemplo mensual para detectar desvíos antes de factura
Fórmula simple de coste por request
Úsala como baseline operativa:
coste_request = (tokens_input / 1.000 * precio_input) + (tokens_output / 1.000 * precio_output)
Luego aplica una pequeña banda de seguridad (por ejemplo, +10% a +15%) para cubrir variación de salida.
Por qué fallan las comprobaciones post-ejecución
La mayoría de los equipos recurren al tracking de costes post-ejecución porque es fácil. Tu proveedor de LLM te da un endpoint de uso. Puedes registrar conteos de tokens. Puedes construir un dashboard en una tarde.
Pero la comprobación post-ejecución tiene un problema fundamental: la llamada ya ocurrió.
Considera estos escenarios:
Escenario 1, El bucle descontrolado. Un job de background procesa documentos a través de un LLM. Un bug hace que procese el mismo documento 10.000 veces. Tu alerta se dispara después de 2 horas y 4.000€ de gasto. Matas el job. El daño está hecho.
Escenario 2, El usuario adversarial. Un usuario descubre que tu asistente de IA genera respuestas largas cuando se le pide que "explique en detalle." Envía 500 requests en una hora. Tu comprobación de rate limit se ejecuta en el servidor, después de la llamada al LLM. Cada request se factura.
Escenario 3, La sorpresa de fin de mes. Las requests individuales parecen bien. Pero un tenant está consistentemente al 90% de su presupuesto para el día 15. Nadie lo nota hasta que llega la factura. No hay mecanismo para limitar o avisar a mitad de ciclo.
En cada caso, la comprobación llegó demasiado tarde.
El modelo correcto: aplicar límites pre-ejecución
La solución es arquitectónica. El enforcement de límites de coste y rate debe ocurrir en el pipeline de requests, antes de que la llamada salga hacia cualquier proveedor.
Esto significa:
1. Comprobaciones de presupuesto a nivel de request Antes de reenviar la request, calcula el coste estimado (basado en el conteo de tokens de input y el precio del modelo) y compáralo con el presupuesto restante del tenant. Si la llamada superaría el límite, bloquéala y devuelve un error estructurado.
2. Enforcement de RPM en el gateway Registra requests-por-minuto por tenant y por modelo. Cuando un tenant alcanza su límite de RPM, rechaza la request inmediatamente, antes de que llegue al proveedor. Sin llamada, sin coste.
3. Caps por proveedor y por modelo Algunos proveedores son más baratos que otros. Algunos modelos cuestan 10 veces más por token. Los caps deben ser configurables en ambos niveles para que puedas aplicar diferentes límites a distintas partes de tu stack.
4. Límites estrictos vs. políticas de overage Los límites estrictos bloquean la request completamente. Las políticas de overage permiten que la request continúe pero facturan el exceso, útil para clientes enterprise que necesitan garantías de continuidad. Ambos necesitan aplicarse pre-ejecución, solo con resultados diferentes.
Ejemplo mensual rápido
Supón este tenant:
- 1.200.000 requests/mes
- coste medio estimado de 0,0042€ por request
- presupuesto mensual de 4.500€
Estimación:
1.200.000 x 0,0042€ = 5.040€
Ya sabes en semana 1 que el presupuesto no cuadra. Puedes actuar antes:
- bajar modelo en rutas de baja complejidad
- reducir output máximo
- aplicar cap por caso de uso
Si no haces este cálculo al principio del ciclo, el ajuste siempre llega tarde.
Cómo se ve el pipeline
Un pipeline de control de costes pre-ejecución se ve aproximadamente así:
Llega la request
→ Autenticar tenant
→ Comprobar límite de RPM (rechazar si se supera)
→ Estimar coste en tokens
→ Comprobar presupuesto restante (rechazar si se supera, o marcar para overage)
→ Enrutar al proveedor
→ Ejecutar
→ Registrar coste real
La clave es que la comprobación de presupuesto se sitúa antes del paso de ejecución. Es una puerta, no un monitor.
Los beneficios operativos más allá del control de costes
Cuando pasas a enforcement pre-ejecución, obtienes tres cosas que el monitoring post-ejecución no puede darte:
Predictibilidad. Los tenants no pueden superar sus límites. Los presupuestos se convierten en restricciones rígidas, no en objetivos blandos.
Prevención de incidentes. Los bucles descontrolados se detienen después del primer lote que supera el límite, no tras horas de gasto sin control.
Confianza. Los clientes enterprise pueden comprometerse con un cap de coste y saber que se aplicará. Eso es un diferenciador comercial.
El Checklist
Antes de tu próximo ciclo de facturación:
- Los límites de presupuesto se aplican a nivel de gateway, no en el código de aplicación
- Los límites de RPM se comprueban antes de la llamada al LLM, no después
- Tienes límites separados para cada proveedor y cada modelo
- Tienes una política de overage definida (bloqueo estricto o facturación del exceso) por tenant
- Las requests bloqueadas generan un registro de auditoría con motivo y timestamp
- Puedes ver el consumo de presupuesto en tiempo real por tenant, no solo totales de fin de mes
Qué hacer esta semana
- Implementa la estimación por request en el gateway.
- Define un cap mensual por tenant y un cap por modelo.
- Activa bloqueo pre-ejecución en modo "log-only" 48 horas y luego en modo estricto.
La sorpresa en la factura es opcional. El enforcement pre-ejecución la hace evitable.