La métrica que falta entre los tokens y el gasto en la nube

El problema no es que los equipos de IA carezcan de datos de costos. Es que el panel de tokens y la factura de la nube describen sistemas diferentes, pertenecientes a equipos distintos, sin una forma fiable de conectarlos.

Un agente de soporte puede resolver un ticket después de cinco llamadas al modelo, un paso de recuperación, dos llamadas a herramientas y un reintento. El negocio registra un caso completado. La infraestructura registra una dispersión de solicitudes, pods, memoria, tiempo de acelerador y servicios compartidos. Hasta que esos registros coincidan, la optimización de costos es en parte una conjetura.

¿Por qué las métricas de tokens y las facturas de la nube cuentan historias diferentes?

Los recuentos de tokens son útiles. Muestran cuánto texto recibió y devolvió un modelo, y ayudan a los equipos a comparar indicaciones, modelos o decisiones de enrutamiento. Pero no indican qué ocurrió alrededor de la llamada al modelo, cuánto cómputo respaldó la recuperación y el uso de herramientas, cuántos intentos fallidos ocurrieron primero, o si el resultado final fue útil.

El State of FinOps 2026 muestra la rapidez con la que la IA se incorporó al trabajo ordinario de FinOps: el 98 % de los encuestados ahora gestiona el gasto en IA, frente al 63 % en 2025. Pero una línea de presupuesto mayor aún no indica qué flujo de trabajo consumió el dinero ni por qué.

Dos trabajos de procesamiento de documentos pueden usar aproximadamente la misma cantidad de tokens. Uno puede terminar con una única solicitud al modelo. El otro puede recuperar contexto de varios almacenes, llamar a un servicio externo, recurrir a otro modelo y volver a ejecutar el documento después de una verificación de validación fallida que el usuario nunca ve. Los totales de tokens se ven similares, mientras que las rutas de ejecución no.

Unite.ai ya ha examinado por qué los recuentos de tokens no representan automáticamente el valor comercial. El siguiente paso es conectar esos recuentos con las cargas de trabajo que los generaron. De lo contrario, un equipo puede mejorar el costo por token mientras empeora el costo por tarea completada.

¿Cómo se ve una cadena de costos completa?

Una cadena de costos útil comienza con el resultado que le importa al negocio. Puede ser un caso de soporte resuelto, un documento procesado, un cambio de código aceptado o un flujo de trabajo de agente completado. Todo lo que está debajo necesita una identidad que pueda seguirse a través del sistema.

La capa de aplicación proporciona la primera conexión. Un ID de solicitud, ID de rastreo, nombre del flujo de trabajo o ID de conversación pueden vincular varias operaciones de modelo y herramienta a una pieza de trabajo. Sin ese hilo, diez eventos relacionados parecen diez cargos no relacionados.

Las convenciones de OpenTelemetry para agentes GenAI ofrecen un vocabulario emergente para esta capa. Cubren operaciones, proveedores, modelos solicitados, agentes, conversaciones, uso de tokens, ejecución de herramientas, errores y flujos de trabajo. Las convenciones aún se consideran en desarrollo, por lo que los equipos no deberían tratarlas como un estándar universal terminado. Son útiles porque hacen concreto el problema de correlación.

Luego viene la infraestructura. Los datos de asignación de costos divididos para EKS de AWS pueden asignar costos compartidos de cómputo y memoria a los pods de Kubernetes y exponer detalles como clúster, espacio de nombres, despliegue, nodo, nombre de carga de trabajo y tipo de carga de trabajo. Para instancias aceleradas compatibles, los datos también cubren reservas de GPU, Trainium e Inferentia.

Esa es la otra mitad de la cadena. Un rastreo puede explicar lo que la aplicación intentó hacer; la asignación de Kubernetes puede mostrar qué recursos llevaron el trabajo. La guía de Unite.ai sobre despliegue y monitoreo de LLMs en Kubernetes brinda el contexto de producción más amplio, incluyendo asignación de recursos, escalado y observabilidad.

La unión no ocurrirá por accidente. Los equipos necesitan un identificador estable que sobreviva lo suficiente para conectar la telemetría de la aplicación con las etiquetas de carga de trabajo, los registros de asignación u otra capa de mapeo. Los datos de clientes no deben incluirse en etiquetas de Kubernetes. Los equipos deben decidir qué identificadores de baja cardinalidad pueden conectar de forma segura una categoría de flujo de trabajo, servicio o característica con los recursos que consumió.

Una vez que ese contexto de aplicación está en su lugar, los equipos pueden comenzar a rastrear los costos de Kubernetes por carga de trabajo y conectar el uso de espacio de nombres, CPU, memoria y GPU con el trabajo que se está realizando. Eso aún no indica si el flujo de trabajo generó valor comercial, pero brinda al lado de infraestructura del cálculo algo concreto a lo que adherirse.

¿En qué métrica unitaria debe confiar la empresa?

No existe una única métrica de costo de IA que todos los equipos deban usar. El costo por token responde a una pregunta de consumo del modelo. El costo por pod responde a una pregunta de asignación de infraestructura. Ninguna indica a un propietario de producto si la característica está justificando su existencia.

El mejor denominador suele ser el resultado más pequeño que el negocio pueda definir claramente y que el equipo de producto pueda influir. Una operación de soporte podría rastrear el costo por caso resuelto. Un sistema de documentos podría usar el costo por archivo procesado con éxito, mientras que un asistente de codificación podría examinar el costo por cambio aceptado en lugar del costo por sugerencia.

El éxito cambia la ecuación.

Un flujo de trabajo con un bajo costo por intento puede resultar caro si falla con frecuencia, genera validaciones repetidas o envía demasiados casos a revisión humana. Por eso los equipos deben separar el costo por intento del costo por finalización y, cuando sea posible, el costo por resultado aceptado. Este último número suele ser el más útil porque incluye el trabajo que el sistema produjo pero que el negocio no pudo utilizar.

Los sistemas de agentes dificultan esto porque sus rutas pueden cambiar de una ejecución a otra. El análisis de Unite.ai sobre la economía de escalar cargas de trabajo de IA agente cubre el enrutamiento, llamadas a herramientas, reintentos y atribución a nivel de flujo de trabajo. esos comportamientos forman parte de la métrica unitaria cuando consumen recursos, incluso cuando el usuario final solo ve una respuesta.

La métrica aún no será perfecta. Los servicios compartidos, resultados en caché, trabajos por lotes y procesamientos retrasados pueden difuminar la atribución. Una estimación útil para la toma de decisiones es mejor que una precisión falsa, especialmente cuando indica a los ingenieros qué capa merece investigación.

¿Quién posee el número?

La parte más difícil puede ser organizacional. Los equipos de ML entienden las llamadas al modelo y la evaluación. Los equipos de plataforma comprenden las cargas de trabajo y el comportamiento del clúster. FinOps entiende los datos de facturación y las reglas de asignación. Los equipos de producto saben qué resultado importa.

Ningún equipo posee la cadena completa.

Eso genera una discusión predecible sobre cuál panel es correcto. El equipo de ML puede señalar un menor uso de tokens, mientras que el equipo de plataforma ve aumentar las horas de GPU y el equipo de producto observa menos tareas completadas que antes. Las tres observaciones pueden ser verdaderas simultáneamente. La métrica compartida debe explicar la relación entre ellas.

Un punto de partida viable es un flujo de trabajo de producción con un evento de finalización claro. Asignarle un identificador estable. Llevar ese contexto a través de los rastros de modelo y herramienta, mapearlo al servicio o carga de trabajo que se ejecuta en Kubernetes y elegir un denominador de negocio. Luego reunir a los equipos cuando el número cambie inesperadamente.

Esa revisión importa más que un panel pulido. Un aumento repentino puede deberse a indicaciones más largas, una nueva ruta de contingencia, capacidad de GPU subutilizada, una política de autoescalado modificada o una decisión de producto que envía más trabajo a través de la función de IA. Cada causa pertenece a un propietario diferente.

La automatización debe llegar después. Un motor de recomendación solo puede actuar sobre las etiquetas y umbrales que recibe, y un denominador incorrecto puede hacer que un sistema eficiente parezca derrochador o recompense un flujo de trabajo barato que los usuarios rechazan. Los equipos necesitan suficiente visibilidad compartida para distinguir el comportamiento del modelo del diseño de la aplicación y la asignación de infraestructura antes de permitir que un sistema actúe sobre el resultado. De lo contrario, una corrección automática de costos puede reducir la capacidad, aumentar la latencia y trasladar el gasto a un lugar menos visible.

La cadena de costos debe ser compartida

El control de costos de IA seguirá fragmentado mientras cada equipo optimice solo la capa que puede ver. Los tokens, rastros, pods, aceleradores y facturas no son mediciones rivales. Son piezas de la misma cadena de costos.

Las empresas que los conecten no obtendrán un número perfecto en el primer día. Lo que importa es si el equipo puede rastrear una factura alta hasta el flujo de trabajo que la provocó, averiguar qué cambió y decidir si el resultado justificó el costo.