73% de los proyectos de IA exceden el presupuesto, según el State of FinOps 2026 de la FinOps Foundation. Algunos hasta 2,4 veces lo planificado. El presupuesto empresarial promedio saltó de US$ 1,2 millones a US$ 7 millones en dos años, y la mayoría de los CFO no sabe cuánto cuesta cada token. En Tech86 vimos empresas quemando US$ 2,3 millones en costos que nadie previó porque nadie instrumentó. Sin costo por token, cualquier optimización es una corazonada.
El problema de visibilidad
La factura de Anthropic llega como una sola línea: US$ 100 mil/mes. Sin detalle por cliente, feature o workflow. Una query de banking dispara 1 orchestrator, 3 retrievers, 4 tool calls y 7 model invocations. El costo queda enterrado 6 niveles abajo. El Cost Explorer no lo ve.
El problema no es falta de herramientas, es falta de granularidad. El FinOps tradicional opera a nivel de instancia. El FinOps para IA necesita operar a nivel de token. Si usted no sabe cuánto cuesta cada token procesado por endpoint, no sabe dónde está quemando dinero. Y el 98% de los equipos de FinOps ahora gestiona gasto de IA, según el State of FinOps 2026: era 31% en 2024. La demanda explotó, la guía todavía no existe.
80-90% del gasto es inferencia, y la GPU está ociosa
El entrenamiento domina el hype. La inferencia domina la cuenta. El 80-90% del gasto de IA es inferencia, según datos de la industria, no entrenamiento. Y la utilización promedio de GPU queda entre 15-30%, según análisis de FinOps. La mitad del presupuesto paga hardware ocioso.
El culpable principal: el endpoint aprovisionado para picos. Usted configura la infraestructura para soportar el horario comercial del lunes, y factura la hora completa 24/7. De madrugada, tráfico cero, GPU cobrando. Una utilización inferior al 50% es dinero recuperable. Es como alquilar un camión para entregar una carta y pagar la tarifa diaria completa.
En Tech86, cuando auditamos workloads de IA, el primer número que buscamos es la utilización de GPU por endpoint y por horario. Si está por debajo del 50%, ya sabemos que hay un margen significativo de ahorro.
Costo por token: la métrica que separa el control de la corazonada
El costo por token es simple en teoría: gastos diarios de inferencia divididos por tokens procesados. En la práctica, exige instrumentación en la capa de aplicación. Usted necesita rastrear tokens por endpoint, por modelo, por cliente, por feature. Sin eso, está volando a ciegas.
Un ejemplo concreto: Opus 4.6 cuesta 21 veces más que MiniMax M2.5 para una diferencia de 0,6% en el benchmark. Si usted no tiene el costo por token por endpoint, no sabe qué modelo está consumiendo cuánto. No sabe si Opus está corriendo para tareas comunes que MiniMax resolvería. No sabe si un cliente que representa el 12% del revenue está consumiendo el 78% del gasto de LLM. Esa asimetría es invisible sin la métrica correcta.
El costo por token transforma la optimización de corazonada en decisión basada en datos. Con ella, usted compara modelos por el costo real por tarea, identifica endpoints sobredimensionados y cuantifica el impacto de cada cambio de arquitectura.
Las palancas que funcionan
El dynamic batching y el caching son la ganancia más rápida. Al agrupar solicitudes y hacer cache de respuestas frecuentes, la utilización de GPU sube de 30% a 70%. El costo baja proporcionalmente. No es teoría: es lo que sucede cuando la GPU deja de procesar una solicitud a la vez y empieza a trabajar en batch.
El model routing por complejidad es la segunda palanca. Tareas comunes en modelo barato, reasoning en modelo de punta. Ahorro de 5-10x. Ya lo cubrimos en detalle en nuestro artículo sobre model selection; aquí el foco es que, sin costo por token, usted no sabe si el routing está funcionando.
El autoscaling con GPU metrics es la tercera. El autoscaling basado en CPU no funciona para GPU. Un endpoint puede tener CPU baja pero GPU saturada. Lo correcto es usar KEDA con NVIDIA GPU Operator para escalar según la utilización real de GPU. Scale to zero en períodos de baja demanda. Sin eso, el endpoint aprovisionado para picos sigue facturando 24/7.
Spend caps y inferencia local: cuando la nube no es la respuesta
Los spend caps son el freno que faltaba. Google Cloud lo lanzó en 2026: pausa automática al alcanzar el presupuesto. Sin eso, un agentic loop descontrolado genera costos que parecen tráfico legítimo hasta que llega la factura. Spend caps por endpoint y por proyecto son gobernanza básica, no lujo.
La inferencia local es la cuenta que pocos hacen. Para workloads con volumen estable y alto, el punto de equilibrio puede llegar en 3 meses, según datos del Signal 65 / Futurum Group. La nube gana cuando el volumen es esporádico o impredecible: el autoscaling compensa el precio por hora. Pero si su inferencia corre 24/7 con carga predecible, la infraestructura local puede ser significativamente más barata. El cálculo debe incluir hardware, energía, cooling y equipo de operación.
Conclusión
FinOps para IA es una práctica paralela: instrumentación a nivel de token, asignación en la capa de aplicación, gobernanza de model routing, budget enforcement en la API call. Sin factura sorpresa. Sin agentic runaway que parece tráfico normal. Sin GPU reservada que nadie usa.
La pregunta para el CFO: ¿cuánto cuesta cada token de su chatbot? ¿Qué modelo corre para qué query? ¿Qué cliente consume el 78% del gasto de LLM pagando el 12% del revenue? Si la respuesta es "no sé" para alguna de ellas, usted está quemando dinero.
En Tech86 diseñamos FinOps para IA con el costo por token, el model routing y la utilización de GPU como métricas centrales. Si usted no sabe cuánto cuesta cada token, es hora de descubrirlo.