FinOps para LLM
Actualizado: August 1, 2026
FinOps para LLM es la práctica de hacer que el gasto en IA sea visible, atribuible, optimizable y responsable. Toma prestado del FinOps en la nube, pero los drivers de costo son diferentes. Una factura de nube depende de instancias, almacenamiento, transferencia y compromisos. Una factura de LLM depende de tokens de entrada, tokens de salida, escrituras en caché, lecturas en caché, reintentos, mix de modelos, longitud de contexto, elegibilidad por lotes y requisitos de calidad.
El primer error que cometen los equipos es tratar el gasto en LLM como un número a nivel de proveedor. Eso oculta las palancas reales. Un endpoint de resumen de soporte, un flujo de agente, un trabajo nocturno de enriquecimiento y un conjunto de evaluación pueden usar el mismo modelo, pero tienen diferentes necesidades de latencia, umbrales de calidad, capacidad de caché y propiedad. FinOps comienza cuando esas cargas de trabajo se separan.
| Pilar | Pregunta clave | Qué produce |
|---|---|---|
| 1. Visibilidad | ¿Qué estamos pagando realmente, solicitud por solicitud? | Registros de uso normalizados divididos por gasto de entrada, salida, escritura en caché, lectura en caché, lotes y reintentos |
| 2. Atribución | ¿Qué equipo, funcionalidad, cliente o carga de trabajo lo causó? | Gasto asignado a propietarios: entorno, endpoint, equipo, inquilino, modelo, clase de carga de trabajo |
| 3. Optimización | ¿Qué palanca reduce el costo por tarea exitosa sin degradar calidad? | Cambios de enrutamiento, caché, lotes, compactación y arbitraje lanzados detrás de banderas |
| 4. Responsabilidad | ¿Quién revisa los números y actúa cada mes? | Informes de showback (y luego chargeback) y un ritmo operativo reconciliado contra facturas |
1. Visibilidad
La visibilidad significa normalizar las facturas de los proveedores y los logs de gateway en un registro común. Cada solicitud debe llevar suficientes metadatos para responder: quién la posee, qué funcionalidad la generó, qué modelo la atendió, cuántas clases de tokens se facturaron, si la llamada reintentó y si la salida produjo valor para el usuario.
2. Atribución
La atribución asigna el gasto a equipos, productos, clientes y cargas de trabajo. El punto no es culpar; el punto es la calidad de las decisiones. El equipo de finanzas no puede gobernar el gasto si cada línea dice “OpenAI”. El líder de ingeniería no puede optimizar una superficie de producto si el gasto se agrupa solo por cuenta de proveedor.
3. Optimización
La optimización debe seguir a la atribución. Las palancas comunes son enrutamiento de modelos, caché semántica, caché de prompts, compactación de contexto, enrutamiento por lotes, arbitraje de proveedores y ajuste de políticas de respaldo. Cada palanca cambia la factura de manera diferente.
4. Responsabilidad
El showback debe venir antes que el chargeback. Primero se da a los equipos una vista mensual creíble de su gasto y drivers. Una vez que los números son confiables, el chargeback puede tener sentido para organizaciones maduras.