Si tu tráfico de OpenAI pasa por LiteLLM, Portkey, Kong AI Gateway o un gateway interno, tu modelo de atribución de costos ya está roto.
Cada caller upstream termina fundido en una sola identidad de workload justo en el punto donde empieza a gastarse la plata. La facturación del proveedor, las herramientas de FinOps basadas en tags y las plataformas de costos en la nube no logran repartir ese costo por servicio, equipo, feature o cliente.
Ese es el punto ciego de los LLM gateways. Se está volviendo un problema central en DevOps y en FinOps for AI, donde el gasto por tokens y la infraestructura compartida rompen los modelos tradicionales de atribución de costos.
Es la brecha que más rápido crece en la atribución de costos en la nube y repite el patrón que los equipos ya vivieron con Kafka, Snowflake y otros sistemas compartidos. La diferencia es que ahora el gasto se mide en tokens, crece rápido y está atado directamente al uso del producto.
Por qué la cadena se rompe en el gateway
Una llamada que pasa por un gateway tiene dos saltos:
upstream-svc ──► llm-gateway ──► api.openai.com
La identidad que te interesa vive en el primer salto: servicio, tenant, feature, cliente.
El evento facturable ocurre en el segundo: el consumo de tokens.
Las facturas del proveedor solo ven la identidad del gateway. Una vez que se produce esa fusión, los sistemas downstream ya no la pueden reconstruir.
Todas las fuentes de datos estándar quedan después del colapso:
- Los exports de facturación del proveedor muestran el costo por API key o por proyecto, no por servicio.
- La facturación en la nube ( CUR, GCP, Azure) no ve el gasto de OpenAI o lo sigue atribuyendo al gateway.
- Las herramientas de FinOps basadas en tags le asignan el costo al recurso que lo gastó: llm-gateway.
El resultado es una bolsa de costos de infraestructura compartida en lugar de unit economics accionables.
Cómo se ve esto en la práctica
| Vista | Por defecto (colapsada) | Lo que necesita el negocio |
| Costo por workload | llm-gateway = $X | Repartido entre servicios reales según el consumo de tokens |
| Costo por cliente | Infra compartida | Costo de IA por cliente |
| Costo por feature | La IA parece gratis | COGS real de IA por feature |
| Señal de pricing | % agregado del costo | Rentabilidad a nivel de cliente |
No es solo un problema de visibilidad. Impacta directamente en:
- El análisis de rentabilidad por cliente
- Las decisiones de pricing
- El ROI por feature
- La optimización de costos en la nube
Por qué el tagging y los logs no alcanzan
La mayoría de los equipos intenta resolverlo con propagación de headers y logs. Funciona en staging. En producción, no.
1. La propagación se pierde. Servicios nuevos, reintentos o rutas alternativas dejan huecos de atribución. Con el tiempo, cada vez más gasto cae en "desconocido".
2. Los logs no son un sistema de costos. El sampling, los límites de retención y el sesgo de ingesta rompen el dataset. Cruzar logs con facturación se vuelve un pipeline frágil.
3. Las llamadas compartidas no se pueden repartir con tags. Los reintentos, el batching, el caching y los flujos de fan-out hacen que varios callers compartan una misma request al proveedor. Los tags no reparten el costo de forma justa. Solo la contabilidad a nivel de token puede hacerlo.
4. Los logs no ven el espacio negativo. Las llamadas fallidas, los reintentos y los fallbacks siguen generando presión de costo sobre la infraestructura, pero no quedan capturados por completo.
Por eso los equipos que buscan repartir costos compartidos en la nube entre microservicios sin tagging se quedan trabados. El tagging achica la brecha, pero no la cierra.
Atribución en runtime: observa la request, no la reconstruyas
La única solución confiable es observar el costo en runtime en lugar de reconstruirlo a partir de los datos de facturación.
Attribute™ usa un sensor eBPF que corre junto al gateway y observa los dos lados de la request:
- Primer salto: servicio upstream → gateway (identidad intacta).
- Segundo salto: gateway → proveedor (consumo de tokens y costo).
Al correlacionar ambos, devuelve el costo del proveedor al workload que lo originó, en función del consumo real de tokens.
Esto permite:
- Visibilidad de costos de Kubernetes por workload de origen
- Atribución de costos de IA a nivel de cliente
- COGS de IA a nivel de feature
- Señales de costo en tiempo real
- Asignación precisa de costos en la nube sin tagging
Detalles de implementación que importan
- Sensor de solo lectura
- PII y secretos eliminados antes de que cualquier dato salga del entorno
- Eventos mínimos de OpenTelemetry sobre TLS con autenticación JWT
- Compatible con collectors OTel existentes
- Sin sidecars, sin cambios de código y sin tocar la configuración del gateway
El resultado: la bolsa de costos del llm-gateway desaparece. Cada dólar de OpenAI queda ligado a un workload, un equipo, una feature y un cliente.
Checklist de evaluación
Si estás evaluando herramientas de FinOps para IA e infraestructura compartida, pregunta:
- ¿Puede repartir el costo del gateway por workload de origen sin propagación de tags?
- ¿Puede atribuir el costo de IA a clientes y features?
- ¿Lee tráfico en vivo o exports de facturación?
- ¿Puede repartir llamadas compartidas de forma proporcional al consumo de tokens?
- ¿La telemetría se puede quedar dentro de tu entorno?
La mayoría de las herramientas falla en varios puntos porque arranca después del evento de facturación.
Los LLM gateways rompen la atribución de costos justo donde empieza el gasto. Si tu modelo de FinOps arranca con datos de facturación, la señal más importante ya se perdió. La única manera de recuperarla es observar el sistema mientras corre. Esa es la diferencia entre estimar el costo y entenderlo de verdad.