Se o seu tráfego para a OpenAI passa por LiteLLM, Portkey, Kong AI Gateway ou por um gateway interno, seu modelo de atribuição de custos já está quebrado.
Todo chamador upstream é unificado numa única identidade de workload exatamente no ponto em que o dinheiro começa a sair. O billing do provedor, as ferramentas de FinOps baseadas em tags e as plataformas de custos de nuvem não conseguem repartir esse custo de volta por serviço, time, feature ou cliente.
Esse é o ponto cego do LLM gateway. Ele está virando rapidamente um problema central em DevOps e FinOps for AI, onde os gastos baseados em tokens e a infraestrutura compartilhada rompem os modelos tradicionais de atribuição de custos.
É a lacuna que mais cresce na atribuição de custos de nuvem e segue o mesmo padrão que os times já viram com Kafka, Snowflake e outros sistemas compartilhados. A diferença é que agora o gasto é baseado em tokens, cresce rápido e está diretamente atrelado ao uso do produto.
Por que a cadeia se rompe no gateway
Uma chamada intermediada por gateway tem dois saltos:
upstream-svc ──► llm-gateway ──► api.openai.com
A identidade que interessa está no primeiro salto: serviço, tenant, feature, cliente.
O evento cobrável acontece no segundo salto: consumo de tokens.
As faturas do provedor só enxergam a identidade do gateway. Depois que essa unificação acontece, os sistemas downstream não conseguem mais reconstruí-la.
Toda fonte de dados padrão fica depois desse ponto:
- Exportações de billing do provedor mostram custo por API key ou por projeto, não por serviço
- Billing de nuvem ( CUR, GCP, Azure) não enxerga o gasto com a OpenAI ou continua atribuindo esse gasto ao gateway
- Ferramentas de FinOps baseadas em tags atribuem o custo ao recurso que gastou: o llm-gateway
O resultado é um balaio de custos de infraestrutura compartilhada em vez de unit economics que realmente sirvam para algo.
Como isso aparece na prática
| Visão | Padrão (unificado) | O que o negócio precisa |
| Custo por workload | llm-gateway = US$ X | Dividido entre os serviços reais por consumo de tokens |
| Custo por cliente | Infra compartilhada | Custo de IA por cliente |
| Custo por feature | IA parece de graça | COGS real de IA por feature |
| Sinal de precificação | % agregada do custo | Lucratividade por cliente |
Não é só um problema de visibilidade. Impacta diretamente:
- Análise de lucratividade por cliente
- Decisões de precificação
- ROI de features
- Otimização de custos de nuvem
Por que tags e logs não resolvem
A maioria dos times tenta resolver isso com propagação de headers e logs. Funciona em staging. Falha em produção.
1. A propagação sai do lugar Novos serviços, retries ou caminhos alternativos criam lacunas de atribuição. Com o tempo, uma parcela cada vez maior do gasto cai no "desconhecido".
2. Logs não são um sistema de custos Sampling, limites de retenção e viés de ingestão comprometem o dataset. Cruzar logs com billing vira um pipeline frágil.
3. Chamadas compartilhadas não têm como ser divididas por tags Retries, batching, caching e workflows de fan-out fazem com que vários chamadores compartilhem uma única requisição ao provedor. Tags não conseguem alocar custo de forma justa. Só a contabilização em nível de token dá conta.
4. Logs deixam passar o "espaço negativo" Chamadas com falha, retries e fallbacks continuam pressionando o custo de infraestrutura, mas não são totalmente capturados.
É por isso que os times que buscam formas de alocar custos compartilhados de nuvem entre microsserviços sem depender de tags acabam travando. Tagging estreita a lacuna. Não fecha.
Atribuição em runtime: observe a requisição, não tente reconstruí-la
A única solução confiável é observar o custo em runtime em vez de reconstruí-lo a partir dos dados de billing.
O Attribute™ usa um sensor eBPF que roda ao lado do gateway e observa os dois lados da requisição:
- Primeiro salto: serviço upstream → gateway (identidade preservada)
- Segundo salto: gateway → provedor (consumo de tokens e custo)
Ao correlacionar os dois, ele mapeia o custo do provedor de volta ao workload de origem com base no consumo real de tokens.
Isso permite:
- Visibilidade de custos de Kubernetes por workload de origem
- Atribuição de custo de IA em nível de cliente
- COGS de IA em nível de feature
- Sinais de custo em tempo real
- Alocação precisa de custos de nuvem sem depender de tags
Detalhes de implementação que fazem diferença
- Sensor somente leitura
- PII e segredos são removidos antes de qualquer dado sair do ambiente
- Eventos mínimos de OpenTelemetry via TLS com autenticação JWT
- Funciona com os coletores OTel existentes
- Sem sidecars, sem mudanças de código, sem alterações na configuração do gateway
Resultado: o balaio de custo do llm-gateway desaparece. Cada dólar gasto com a OpenAI fica atrelado a um workload, time, feature e cliente.
Checklist de avaliação
Se você está avaliando ferramentas de FinOps para IA e infraestrutura compartilhada, pergunte:
- Ela consegue dividir o custo do gateway por workload de origem sem propagação de tags?
- Consegue atribuir custo de IA a clientes e features?
- Ela lê tráfego ao vivo ou exportações de billing?
- Consegue dividir chamadas compartilhadas proporcionalmente pelo consumo de tokens?
- A telemetria pode ficar dentro do seu ambiente?
A maioria das ferramentas falha em vários desses pontos porque começa depois do evento de billing.
Os LLM gateways quebram a atribuição de custos exatamente no ponto em que o gasto começa. Se o seu modelo de FinOps parte dos dados de billing, o sinal mais importante já se perdeu. A única forma de recuperá-lo é observar o sistema enquanto ele roda. É essa a diferença entre estimar custo e realmente entendê-lo.