FinOps para IA: cómo controlar el coste de tokens en producción sin sacrificar calidad
Si tu producto ya usa un LLM en producción, el coste no se resuelve "eligiendo el modelo barato". Se resuelve con arquitectura. La respuesta corta: aplica las palancas en orden de retorno —enrutado por caso de uso, prompt caching, procesamiento por lotes, ingeniería de contexto y guardarraíles anti-derroche— y mide el coste por transacción antes de tocar nada. Con eso, recortes del 60–90% en la factura de inferencia son habituales sin degradar la calidad percibida.
Este artículo es la guía de FinOps aplicada a IA que nos habría gustado tener la primera vez que un agente en bucle se comió un presupuesto mensual en una tarde.
Por qué el coste de tokens se descontrola
En una demo, un LLM cuesta céntimos. En producción, tres dinámicas lo disparan:
- Contexto que engorda. Cada mensaje arrastra historial, instrucciones y documentos recuperados. Un prompt de sistema de 10.000 tokens que se reenvía en cada turno se paga íntegro en cada turno.
- Agentes que iteran. Un agente que planifica, llama herramientas y se autoverifica puede encadenar 10–40 llamadas para resolver una sola petición del usuario. El coste no es por petición: es por paso.
- Tráfico real. Lo que en pruebas eran 200 peticiones al día, en producción son 200.000, con picos y usuarios que reintentan.
El error clásico es optimizar el precio unitario del modelo (dólares por millón de tokens) ignorando cuántos tokens consume de verdad tu sistema. Un modelo "caro" que resuelve en 3.000 tokens sale más barato que uno "barato" que necesita 30.000 y dos reintentos.
Las cinco palancas, en orden de retorno
No las apliques todas a ciegas. Este es el orden en el que, en nuestra experiencia, dan más ahorro por hora de ingeniería.
1. Enrutado y tiering de modelos
La mayoría de peticiones no necesitan tu modelo más capaz. Define una política por caso de uso: un modelo pequeño y barato como opción por defecto (clasificar, extraer, formatear, responder FAQ) y escalada a un modelo frontier solo cuando la tarea lo exige o la confianza es baja. Los proveedores ya empujan esta lógica con familias escalonadas —OpenAI con GPT-5.6 en niveles Sol/Terra/Luna, Google con Gemini 3.6 Flash y Flash-Lite— y con diales de esfuerzo (Claude Opus 5 ofrece cinco niveles de razonamiento) que permiten pagar por profundidad de pensamiento solo cuando hace falta.
La clave de ingeniería: no cablees el proveedor en tu código. Coloca un gateway de modelos delante para poder enrutar, mezclar proveedores y renegociar sin refactorizar. Lo desarrollamos en detalle en nuestra guía de LLM gateway.
Cuándo NO: si tu volumen es bajo (unas miles de llamadas al mes), montar enrutado por confianza es sobreingeniería. Empieza por un modelo bueno y mide.
2. Prompt caching (la palanca de mayor ROI inmediato)
Si reenvías el mismo prefijo —prompt de sistema, instrucciones, documentos estables— en muchas llamadas, la caché de prompts te cobra ese prefijo una fracción del precio. Según la documentación de cada proveedor, la lectura de tokens cacheados ronda el 10% del precio de entrada en Anthropic (≈90% de ahorro), alrededor de la mitad en OpenAI y en torno al 10% de la tarifa base en los aciertos de caché de Google. En Anthropic hay que contar el sobrecoste de escritura de caché (≈1,25× para la ventana de 5 minutos, ≈2× para la de 1 hora), que se amortiza en cuanto reutilizas el prefijo unas pocas veces.
Ordena tu prompt de estable → variable: sistema e instrucciones fijas primero, contexto dinámico y pregunta del usuario al final. Así el prefijo cacheable es lo más largo posible.
Cuándo NO: si cada petición es única (prefijos que nunca se repiten), la caché no ayuda e incluso penaliza por el coste de escritura.
3. Procesamiento por lotes (batch) para lo que no es tiempo real
Todo lo que no necesite respuesta inmediata —clasificar catálogos, generar resúmenes nocturnos, enriquecer datos, evaluaciones— puede ir por el endpoint asíncrono, que la mayoría de proveedores ofrece con ≈50% de descuento a cambio de una ventana de entrega diferida. Y las palancas se acumulan: batch sobre la parte cacheable puede acercarte al 95% de ahorro en el trozo repetido.
Cuándo NO: flujos conversacionales o cualquier cosa con un usuario esperando. El batch es para trabajo de fondo.
4. Ingeniería de contexto para coste
Cada token de contexto se paga en cada llamada. Recortar contexto es recortar factura de forma lineal:
- Recupera, no metas todo el manual. Un buen RAG que trae 3 fragmentos relevantes bate a inyectar 50 páginas "por si acaso". Y sale mucho más barato que estirar el context window al máximo.
- Resume el historial de conversaciones largas en lugar de arrastrarlo entero.
- Poda las salidas de herramientas antes de devolverlas al modelo: rara vez necesita el JSON de 8.000 tokens completo.
Es la otra cara de la moneda de la calidad: gestionar bien el contexto mejora resultados y baja coste. Lo tratamos a fondo en ingeniería de contexto para agentes.
5. Guardarraíles anti-derroche
El gasto que más asusta no es el estable: es el runaway. Un agente que entra en bucle, un reintento sin límite, un usuario malicioso. Pon límites duros:
- Tope de pasos/tokens por tarea y cortocircuito si se supera.
- Límites de gasto por usuario y por día, con alerta.
- Timeouts y detección de bucles en la orquestación (más sobre patrones en orquestación multiagente en producción).
Estos límites no optimizan el caso medio, pero evitan la factura de cuatro cifras de un martes cualquiera.
Tabla resumen: qué palanca, cuánto ahorra, cuándo evitarla
| Palanca | Ahorro típico | Esfuerzo | Cuándo NO usarla |
|---|---|---|---|
| Enrutado / tiering de modelos | 30–70% | Medio | Volumen bajo; una sola tarea homogénea |
| Prompt caching | Hasta ~90% del prefijo | Bajo | Prefijos que nunca se repiten |
| Batch asíncrono | ~50% | Bajo | Cualquier cosa en tiempo real |
| Ingeniería de contexto | Lineal con los tokens recortados | Medio-alto | Cuando ya recuperas lo mínimo imprescindible |
| Guardarraíles de gasto | Evita picos catastróficos | Bajo | Nunca: son innegociables |
Lo que no se mide, no se optimiza
Antes de tocar arquitectura, instrumenta. Necesitas coste por transacción de negocio (no por token), atribuido por caso de uso, por cliente y por modelo. Sin esa foto, optimizas a ciegas y celebras ahorros que el usuario paga en calidad.
Y ahí está el riesgo real: recortar tokens puede degradar la respuesta. Por eso el coste no se optimiza contra una hoja de cálculo, sino contra una batería de evals. Cada cambio (bajar de modelo, podar contexto, subir la caché) se valida contra un conjunto de casos con criterios objetivos, no "a ojo". Lo defendemos en evaluar agentes con evals, no con vibes.
Cuándo NO optimizar (todavía)
Ser honestos incluye decir cuándo esto no toca:
- Si aún no tienes product-market fit en la feature de IA. Optimizar coste de algo que quizá elimines la semana que viene es tiempo perdido. Primero valida, luego optimiza.
- Si la factura es de tres cifras al mes. El coste de tu ingeniería optimizando supera con creces el ahorro. Deja que crezca y vuelve cuando duela.
- Si el cuello de botella es la calidad, no el coste. Un producto que responde mal no se arregla haciéndolo más barato.
La regla: optimiza cuando el coste de inferencia es una línea material en tu P&L y la feature está aquí para quedarse.
Cómo lo abordamos en Dribba
Llevamos desde 2011 (15 años) construyendo producto digital, con equipo 100% senior in-house y oficinas en Barcelona y Andorra. Cuando entramos en un proyecto con IA en producción, el orden es siempre el mismo: instrumentar el coste por caso de uso, poner los guardarraíles, y luego aplicar caching, enrutado y contexto validando cada paso contra evals. No perseguimos el modelo más barato del mes; diseñamos el sistema para que el coste sea predecible y baje solo cuando bajen los precios del mercado.
Si tienes una feature de IA cuyo coste no cuadra —o quieres montarla bien desde el principio—, podemos ayudarte a extender tu equipo con perfiles senior que ya han pasado por esto: staff augmentation en Dribba.
Conclusión
El coste de los tokens es un problema de arquitectura, no de tarifa. Enruta por caso de uso, cachea el prefijo estable, manda a batch lo que no es tiempo real, adelgaza el contexto y pon límites duros al derroche. Mídelo todo por transacción de negocio y valida cada recorte contra evals. Hecho en ese orden, la factura de IA deja de ser una sorpresa a fin de mes y pasa a ser una palanca más que controlas tú.
