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 facturacion AWS o GCP son muy buenos atribuyendo coste a instancias, almacenamiento y trafico. No estan preparados para decirte cuanto cuesta una llamada de agente que invoca tres herramientas y genera dos mil tokens de salida. Y es ahi donde se concentra la factura cuando el sistema IA pasa a produccion.
Este post es un repaso pragmatico de como se distribuye el coste en una carga IA tipica, que controles funcionan, cuales son teatro y que deberia vigilar cualquier equipo que este empezando a gastar mas de unos pocos miles de euros al mes en modelos y servicios relacionados.
Donde se va el coste de verdad
La intuicion inicial suele enganar. Muchos equipos asumen que el grueso del gasto sera computo 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 via API de terceros, con dos componentes claros: tokens de entrada y tokens de salida.
Dentro de inferencia, los tokens de entrada son los que mas suelen descontrolarse. Se pagan por cada llamada, incluso si la respuesta es corta, y crecen de forma invisible cuando se introduce contexto adicional. Sistemas RAG que recuperan ocho o diez chunks de tamano generoso pueden multiplicar por cinco o seis el coste de entrada respecto a una llamada sin contexto. Agentes con memoria persistente y acumulacion de historial crecen incluso mas rapido.
Los tokens de salida son mas baratos en frecuencia pero mas caros por unidad, al menos en la mayoria de proveedores. Si la aplicacion tiende a respuestas largas, formateadas con bastante detalle o 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 multiplicacion adicional por ocultos tokens de razonamiento 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 de esa herramienta vuelve al modelo como entrada para la siguiente generacion. En agentes que usan muchas herramientas, las llamadas se encadenan y cada una anade contexto adicional en la siguiente iteracion. Un agente que llama tres o cuatro herramientas antes de responder puede estar gastando diez o quince veces mas que una llamada directa sin agentes.
El cuarto vector es reindexado. Sistemas RAG reindexan documentos cuando cambian, y cada reindexado incurre coste de embedding. Si un equipo no controla la frecuencia de reindexado, especialmente sobre corpus grandes, el embedding puede ser una fraccion significativa del total.
Los experimentos fallidos son el gasto fantasma
Un apartado propio merece el gasto en experimentos. Cada evaluacion de un prompt nuevo, cada fine-tuning probado con suerte desigual, cada comparacion A/B entre modelos consume tokens. En equipos que iteran rapido, la suma puede ser sustancial. Y, a diferencia del gasto de produccion, los experimentos no suelen tener atribucion clara a una unidad de negocio.
He visto casos en los que el gasto experimental mensual superaba al de produccion, simplemente porque varios ingenieros estaban iterando sobre sus propias cuentas de API sin que nadie agregara. Los proveedores ofrecen proyectos o claves segmentadas por equipo, pero el uso disciplinado requiere convencion organizativa, no solo capacidad tecnica.
Controles que sirven
La primera capa de control es visibilidad. Facturacion segmentada por proyecto, clave API o tag es condicion previa. Todos los proveedores grandes lo ofrecen, OpenAI y Anthropic via organization scopes, Google y AWS via etiquetas de recurso y cuentas de servicio diferenciadas. Sin segmentacion, no hay diagnostico.
La segunda capa es instrumentacion por peticion. Cada llamada a un modelo debe emitir al menos tres metricas: modelo usado, tokens de entrada, tokens de salida. Con eso agregado por servicio, endpoint y usuario se construye el grafico de coste que permite localizar los puntos calientes. Herramientas como Helicone, LangSmith o un sidecar casero con OpenTelemetry funcionan para esto.
La tercera capa es limite blando por unidad de negocio. Cada equipo o aplicacion deberia tener un presupuesto mensual asignado, y el sistema debe avisar cuando un equipo se acerca al 80% del presupuesto antes de que lo agote. Los limites duros son arriesgados porque rompen servicio, pero avisos a tiempo permiten reaccionar.
La cuarta capa es seleccion de modelo por contexto. No toda llamada necesita el modelo mas caro. Un sistema bien disenado enruta cada peticion al modelo mas pequeno capaz de responderla, con fallback al mas grande si la respuesta del pequeno es insatisfactoria. 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 logica de enrutamiento mas que optimizacion fina.
Controles que son teatro
Algunos controles que suenan sensatos no rinden en la practica.
Cachear respuestas LLM parece una optimizacion obvia pero falla en la mayoria de aplicaciones. Las preguntas raramente son identicas, el contexto cambia, y el cache hit ratio en RAG productivo suele estar por debajo del 5% salvo en casos muy concretos como FAQ o soporte repetitivo. Mejor invertir el esfuerzo en reducir tokens de entrada.
Limitar tokens maximos por respuesta tampoco suele ayudar tanto como parece. Muchos proveedores facturan por tokens generados reales, no por el limite, asi que reducir el max_tokens solo corta respuestas sin ahorrar dinero. Lo que si sirve es instruir al modelo a responder de forma mas concisa. Optimizar en exceso los prompts de sistema tiene retornos decrecientes: el ahorro es marginal frente a reducir contexto de RAG.
Ejemplos de numeros reales
Para poner escala, aqui algunas cifras de casos que he revisado. Un agente corporativo de soporte con acceso a base de conocimiento, atendiendo unos dos mil usuarios mensuales con tres consultas de media, generaba unos 1200 euros de gasto OpenAI mensual antes de optimizacion. Despues de aplicar enrutamiento a modelo mas barato para clasificacion inicial, reduccion de chunks recuperados de diez a cuatro y cache de embeddings, el coste bajo a 380 euros con calidad equivalente segun evaluacion humana.
Un sistema de generacion de borradores de correo que los usuarios editaban costaba 2800 euros mensuales. El diagnostico mostro que el grueso era tokens de salida por respuestas largas que los usuarios luego cortaban. Modificar el prompt para pedir borrador inicial mas breve redujo el coste a 1100 euros, con la mayoria de usuarios reportando preferencia por la version mas corta.
Un sistema RAG con reindexado diario completo sobre corpus de dos millones de documentos estaba gastando mas en embedding que en inferencia. Pasar a reindexado incremental con deteccion de cambios redujo el coste de embedding en un 90% sin impacto en calidad de busqueda.
Mi lectura
FinOps en IA exige herramientas nuevas y patrones nuevos. Los paradigmas de instancia y almacenamiento no se traducen bien, y las herramientas genericas de observabilidad de coste no captan la unidad que importa, que es la llamada al modelo con su contexto y su salida. Los equipos que estan haciendo esto bien en 2025 han construido instrumentacion propia o han adoptado herramientas especificas, y se estan ahorrando fracciones sustanciales de factura.
Lo que mas me sorprende cuando reviso casos es cuan variable es el ratio coste por usuario entre equipos con productos comparables. He visto diferencias de factor cinco o seis entre dos companias con funcionalidad parecida, atribuibles casi siempre a decisiones arquitectonicas: enrutamiento de modelo, tamano de contexto, frecuencia de reindexado y numero de iteraciones por llamada. Ninguna de esas decisiones es irreversible; todas se pueden ajustar en semanas si hay datos que las sustenten.
La recomendacion practica a quien esta empezando a gastar en IA de forma significativa es la misma que con cualquier nube: instrumenta antes de optimizar. Sin datos por peticion, por usuario y por modelo, las optimizaciones son intuicion. 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.
