Inicio/Blog/Observabilidad de costos cloud
FinOps

Observabilidad 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.

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 IA
NegocioCosto 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.

SuperficieSeñal directaDimensión útilPregunta de optimización
InferenciaTokens input, caché, output, reasoning, calls, modelo y tier.Tenant, feature, tarea, agente, prompt y resultado.¿Qué modelo y prompt producen valor con calidad aceptable?
EmbeddingsTokens, documentos, frecuencia y batch jobs.Corpus, producto, tenant, pipeline y owner.¿Se reprocesan documentos sin cambios o sin uso?
Base vectorialVectores, query units, réplicas, index builds y transferencia.Corpus, tenant, feature y entorno.¿Qué índices y réplicas producen retrieval útil?
GPU y servingGPU-seconds, memoria, secuencias, batch fill e idle.Modelo, clase, tenant share y endpoint.¿La capacidad compartida está justa y bien utilizada?
Storage y egressBytes 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 evalsEjecuciones, 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.