Inicio/Blog/Observabilidad de costos cloud FinOpsObservabilidad de costos cloud para workloads de IA
Una factura de provider informa cuánto gastó la organización. Normalmente no informa qué tenant, feature, agente, evaluación, job programado o resultado útil causó el gasto. La observabilidad de costos de IA construye esa cadena ausente.
Publicado el 8 de junio de 202612 min de lecturaFinOps para IA
El gasto de IA cruza demasiados medidores para FinOps basado solo en factura
FinOps Foundation describe FinOps for AI como respuesta a modelos de costo complejos, ciclos rápidos, gasto impredecible y necesidad de alinear consumo con valor. Una feature de IA puede crear tokens, embeddings, consultas vectoriales, object storage, capacidad GPU, logs, egress, tool calls y evaluaciones programadas en varios providers.
Los tags cloud son necesarios, pero terminan en la frontera del recurso. Endpoints de inferencia y clusters vectoriales compartidos atienden muchos tenants y features. La aplicación debe agregar dimensiones que billing no ve: request, tarea, agente, versión de prompt, feature, tenant, entorno, owner y resultado.
Dashboard de asignación de costos de IANegocioCosto por resultado útilResolución, sugerencia aceptada, workflow completado o evento de ingreso.
ProductoCosto por feature y tenantQué superficies y tiers consumen capacidad compartida.
WorkflowCosto por tarea y agenteModel calls, tools, retries, jobs y profundidad de cadena.
ModeloMix de inferencia y embeddingsModelos, providers, cached input, output, batch, evaluaciones y calidad.
PlataformaInfraestructura compartidaGPUs, bases vectoriales, storage, observabilidad, colas y egress.
GobernanzaOwnership y asignaciónEquipo, proyecto, cost center, entorno, presupuesto, anomalías y forecast.
Construye linaje de costo, no otro dashboard de billing
La especificación FOCUS ofrece un lenguaje común para datos de costo y uso. Tags de AWS y reglas de asignación Azure agregan contexto y distribuyen costos compartidos. La Usage API de OpenAI agrupa costos por proyecto y line item. Las convenciones GenAI de OpenTelemetry estandarizan telemetría de operaciones de modelo. Aun hace falta un join key que conecte uso del provider con trace de aplicación y resultado de negocio.
Lleva correlation IDs desde el request hasta tarea del agente, llamada de modelo, embedding, consulta vectorial, storage y tool downstream. Luego une registros de uso y asignación de recursos compartidos a esos IDs. El resultado es un cost trace que explica cargos directos y overhead asignado.
OwnershipEquipo, cost center, producto, entorno, owner y política de presupuesto.
WorkloadFeature, tenant, tarea, agente, modelo, versión de prompt y job.
RecursoTokens, GPU, embeddings, vector DB, storage, egress, logs y tools.
ResultadoCalidad, latencia, conclusión, aceptación, ingreso, falla y abandono.
Asigna infraestructura compartida con drivers de uso
Asignación igual es simple y suele ser incorrecta. Pools GPU pueden usar GPU-seconds o tiempo de secuencia activa. Bases vectoriales pueden usar vectores almacenados, query units y transferencia. Observabilidad puede usar spans o bytes ingeridos. Evaluaciones pueden usar model calls y tamaño de dataset. El driver debe parecerse al comportamiento que crea costo y ser entendible por el equipo cobrado.
Mantén visible la confianza de asignación. Llamadas directamente medidas tienen alta confianza. Un cluster compartido dividido por uso estimado tiene menor confianza. El costo no asignado debe ser una métrica, no distribuirse silenciosamente.
| Superficie | Señal directa | Dimensión útil | Pregunta de optimización |
|---|
| Inferencia | Tokens input, caché, output, reasoning, calls, modelo y tier. | Tenant, feature, tarea, agente, prompt y resultado. | ¿Qué modelo y prompt producen valor con calidad aceptable? |
| Embeddings | Tokens, documentos, frecuencia y batch jobs. | Corpus, producto, tenant, pipeline y owner. | ¿Se reprocesan documentos sin cambios o sin uso? |
| Base vectorial | Vectores, query units, réplicas, index builds y transferencia. | Corpus, tenant, feature y entorno. | ¿Qué índices y réplicas producen retrieval útil? |
| GPU y serving | GPU-seconds, memoria, secuencias, batch fill e idle. | Modelo, clase, tenant share y endpoint. | ¿La capacidad compartida está justa y bien utilizada? |
| Storage y egress | Bytes almacenados, retenidos, leídos, escritos y transferidos. | Dataset, artefacto, tenant, región y retención. | ¿Qué datos están duplicados, stale o cruzando regiones? |
| Jobs y evals | Ejecuciones, calls, filas, duración, fallas y retries. | Versión, experimento, owner y decisión de release. | ¿Qué jobs recurrentes ya no influyen decisiones? |
Lo que yo construiría
Construiría un pipeline de telemetría de costos que enriquece cada operación de IA con dimensiones de aplicación antes de exportar traces y uso. Exports de providers, billing normalizado por FOCUS, APIs de uso, métricas Kubernetes, uso de base vectorial y storage entrarían en un cost ledger.
El dashboard permitiría ir del gasto mensual hasta feature, tenant, workflow, model call y resultado. Destacaría gasto no asignado, asignaciones de baja confianza, anomalías, capacidad ociosa, jobs stale y features cuyo costo crece más rápido que sus resultados útiles.
El principio de diseño
La observabilidad de costo solo está completa cuando quien puede cambiar el sistema ve el costo que influye y el valor creado. Asigna recursos a workloads, workloads a comportamiento de producto y comportamiento a resultados. Todo lo que queda como “costo compartido de IA” es una pregunta de ingeniería aún sin respuesta.