FinOps aplicado a IA: dónde se va el coste de verdad
Actualizado: 2026-05-03
Los equipos que han hecho FinOps bien en nube tradicional se encuentran, cuando llegan a cargas de IA, con que las herramientas que usaban dejan de servir. Kubecost, OpenCost y los dashboards de facturación AWS o GCP son muy buenos atribuyendo coste a instancias, almacenamiento y tráfico. No están preparados para decirte cuánto cuesta una llamada de agente que invoca tres herramientas y genera dos mil tokens de salida. Y es ahí donde se concentra la factura cuando el sistema IA pasa a producción.
Puntos clave
- El grueso del gasto de IA en 2025 es inferencia vía API de terceros, no cómputo GPU propio.
- Los tokens de entrada son los que más se descontrolan: los sistemas RAG con contexto generoso multiplican por 5–6 el coste de entrada.
- Las llamadas de herramientas en cadena pueden costar 10–15 veces más que una llamada directa.
- El gasto experimental mensual puede superar al de producción si no hay convenio organizativo.
- La primera palanca de optimización siempre es visibilidad: facturación segmentada por proyecto, clave API o tag.
- La reducción de chunks recuperados en RAG y el enrutamiento a modelos más baratos son los dos cambios con mejor ratio coste-beneficio.
Dónde se va el coste de verdad
La intuición inicial suele engañar. Muchos equipos asumen que el grueso del gasto será cómputo GPU para entrenamiento o fine-tuning propios. En realidad, salvo que uno opere un laboratorio de modelos, la mayor parte del gasto en IA en 2025 es inferencia vía API de terceros, con dos componentes claros: tokens de entrada y tokens de salida.
Dentro de inferencia, los tokens de entrada son los que más suelen descontrolarse. Se pagan por cada llamada, aunque la respuesta sea corta, y crecen de forma invisible cuando se introduce contexto adicional. Sistemas RAG que recuperan ocho o diez chunks de tamaño generoso pueden multiplicar por cinco o seis el coste de entrada respecto a una llamada sin contexto. Agentes con memoria persistente y acumulación de historial crecen incluso más rápido.
Los tokens de salida son más baratos en frecuencia pero más caros por unidad. Si la aplicación tiende a respuestas largas con razonamiento paso a paso, la parte de salida puede dominar la factura. Modelos con razonamiento extendido como OpenAI o1 o la variante de Claude con thinking tienen una multiplicación adicional por tokens de razonamiento ocultos que se facturan aunque el usuario no los vea.
Las llamadas de herramientas son el tercer vector menos comprendido. Cada vez que un agente invoca una herramienta, la respuesta vuelve al modelo como entrada para la siguiente generación. En agentes que usan muchas herramientas, las llamadas se encadenan y cada una añade contexto adicional. Un agente que llama tres o cuatro herramientas antes de responder puede estar gastando 10–15 veces más que una llamada directa sin agentes.
El cuarto vector es el reindexado. Sistemas RAG reindexan documentos cuando cambian, y cada reindexado incurre coste de embedding. Si un equipo no controla la frecuencia de reindexado sobre corpus grandes, el embedding puede ser una fracción significativa del total. El coste de reindexado también es un factor en la evaluación continua de RAG.
Los experimentos fallidos son el gasto fantasma
Cada evaluación de un prompt nuevo, cada fine-tuning probado, cada comparación A/B entre modelos consume tokens. En equipos que iteran rápido, la suma puede ser sustancial. A diferencia del gasto de producción, los experimentos raramente tienen atribución clara a una unidad de negocio.
He visto casos en los que el gasto experimental mensual superaba al de producción, simplemente porque varios ingenieros iteraban sobre sus propias cuentas de API sin que nadie agregara. Los proveedores ofrecen proyectos o claves segmentadas por equipo, pero el uso disciplinado requiere convenio organizativo, no solo capacidad técnica.
Controles que sirven
- Primera capa: visibilidad. Facturación segmentada por proyecto, clave API o tag es condición previa. Todos los proveedores grandes lo ofrecen. Sin segmentación, no hay diagnóstico.
- Segunda capa: instrumentación por petición. Cada llamada a un modelo debe emitir al menos tres métricas: modelo usado, tokens de entrada, tokens de salida. Con eso agregado por servicio y usuario se construye el gráfico de coste que permite localizar los puntos calientes. Herramientas como Helicone[1], LangSmith[2] o un sidecar con OpenTelemetry funcionan para esto.
- Tercera capa: límite blando por unidad de negocio. Cada equipo o aplicación debería tener un presupuesto mensual asignado y avisos al 80 % antes de agotar. Los límites duros son arriesgados porque rompen servicio.
- Cuarta capa: selección de modelo por contexto. No toda llamada necesita el modelo más caro. Las diferencias de precio entre GPT-4 y GPT-4o-mini, o entre Claude Sonnet y Haiku, son de un orden de magnitud. Aprovecharlas requiere lógica de enrutamiento más que optimización fina.
Controles que son teatro
Algunos controles que suenan sensatos no rinden en la práctica:
- Cachear respuestas LLM parece una optimización obvia pero falla en la mayoría de aplicaciones. El cache hit ratio en RAG productivo suele estar por debajo del 5 % salvo en FAQ o soporte repetitivo.
- Limitar tokens máximos por respuesta solo corta respuestas sin ahorrar dinero si el proveedor factura por tokens generados reales, no por el límite.
- Optimizar en exceso los prompts de sistema tiene retornos decrecientes: el ahorro es marginal frente a reducir contexto de RAG.
Ejemplos de números reales
Un agente corporativo de soporte con acceso a base de conocimiento, atendiendo unos dos mil usuarios mensuales con tres consultas de media, generaba unos 1.200 euros de gasto OpenAI mensual antes de optimización. Después de aplicar enrutamiento a modelo más barato para clasificación inicial, reducción de chunks recuperados de diez a cuatro y caché de embeddings, el coste bajó a 380 euros con calidad equivalente según evaluación humana.
Un sistema de generación de borradores de correo costaba 2.800 euros mensuales. El diagnóstico mostró que el grueso era tokens de salida por respuestas largas que los usuarios luego cortaban. Modificar el prompt para pedir borrador inicial más breve redujo el coste a 1.100 euros, con la mayoría de usuarios reportando preferencia por la versión más corta.
Un sistema RAG con reindexado diario completo sobre corpus de dos millones de documentos gastaba más en embedding que en inferencia. Pasar a reindexado incremental con detección de cambios redujo el coste de embedding en un 90 % sin impacto en calidad de búsqueda.
Mi lectura
FinOps en IA exige herramientas nuevas y patrones nuevos. Los paradigmas de instancia y almacenamiento no se traducen bien, y las herramientas genéricas de observabilidad de coste no captan la unidad que importa: la llamada al modelo con su contexto y su salida.
Lo que más me sorprende cuando reviso casos es cuán variable es el ratio coste por usuario entre equipos con productos comparables. He visto diferencias de factor cinco o seis entre dos compañías con funcionalidad parecida, atribuibles casi siempre a decisiones arquitectónicas: enrutamiento de modelo, tamaño de contexto, frecuencia de reindexado y número de iteraciones por llamada. Ninguna de esas decisiones es irreversible.
La recomendación práctica es la misma que con cualquier nube: instrumenta antes de optimizar. Sin datos por petición, por usuario y por modelo, las optimizaciones son intuición. Con esos datos, casi siempre aparecen dos o tres puntos calientes que concentran la mitad del gasto y que, con cambios moderados, bajan el coste total sin tocar la calidad percibida.
