Como medir o custo operacional de um gateway de IA

A empresa fecha o contrato do gateway de IA olhando preço de token e lista de modelos. Três meses depois, o custo que dói no P&L não é o token. É a latência que o gateway engoliu, a memória que o cluster não tinha orçado e o tempo de operação que ninguém colocou na planilha de compra. O custo operacional de um gateway de IA se mede como delta: mesma carga, mesmo modelo, mesma região, com e sem o gateway no caminho. Sem esse harness, a compra é fé.

O que é o custo operacional de um gateway de IA?

O custo operacional de um gateway de IA é o overhead que o gateway adiciona em produção: latência extra em p50, p95 e p99, memória e CPU do processo, custo de infraestrutura amortizado por milhão de requests e, quando material, tempo de operação dedicado à camada.

Não é preço de token. Não é qualidade do modelo. É o preço de colocar o gateway entre o cliente e o provedor.

Esse overhead existe em qualquer arquitetura. Proxy dedicado, sidecar no cluster, gateway gerenciado. A forma muda. A conta, não. Quem compra o gateway sem medir o delta aceita um imposto invisível sobre cada chamada de produção.

A confusão começa no vocabulário. Time de produto fala "custo de IA" e aponta para a fatura do provedor. Time de plataforma fala "custo de IA" e aponta para o nó que encheu de memória. Time financeiro fala "custo de IA" e aponta para o câmbio e a nota. São três contas diferentes. Misturá-las é o defeito que este método existe para impedir.

Pré-requisitos antes de medir

Antes do passo 1, o comprador precisa de um ambiente controlado, de métricas comparáveis nos dois caminhos e de um dono claro da medição, com critério de aceite escrito antes do primeiro run. Sem isso, o harness vira teatro de dashboard e o gráfico de latência vira argumento de venda, não evidência de compra.

Três insumos abrem a porta. Acesso a um endpoint direto do provedor (baseline) e ao endpoint do gateway sob avaliação, na mesma região e com o mesmo modelo. Ferramenta de carga HTTP que exporte percentis (p50, p95, p99), não só média: k6, vegeta, Locust ou equivalente interno. Payload representativo da produção: tamanho de prompt, streaming ou não, tool calls se existirem, temperatura e max tokens fixos.

Sem payload de produção, o teste mede o laboratório. O restante do kit fecha a conta em dinheiro e em processo.

• Métricas de processo no host do gateway: RSS/memória residente, CPU por request ou por segundo, réplicas ativas.
• Preço unitário da infra onde o gateway roda (vCPU-hora, GB-hora, request de load balancer) ou unit economics do cluster.
• Janela de teste com carga estável o bastante para a cauda: milhares de requests por cenário, não dezenas.

Falta ainda o dono. Um nome de plataforma ou de SRE e um critério de aceite escrito antes do primeiro run, não depois de ver o gráfico. Sem preço de infra, o teste para em milissegundos e nunca vira dinheiro. Os dois erros são comuns e caros.

Passo a passo: o método em seis movimentos

O método completo tem seis passos executáveis em ordem fixa: define o que conta como overhead do gateway de IA, monta o baseline, mede latência adicionada, mede memória e CPU, converte tudo em custo por milhão de requests e só então fixa critérios de aceite antes de escalar.

A ordem importa. Critério sem número é opinião. Número sem critério é decoração.

Os três primeiros movimentos abrem o harness:

1. Isolar o overhead do gateway de IA dos outros dois custos de IA.
2. Montar o harness baseline cliente → provedor.
3. Medir latência adicionada em p50, p95 e p99.

Os três seguintes fecham a conta e a decisão de escala:

1. Medir memória, CPU e réplicas sob a mesma carga.
2. Converter recursos em custo operacional por milhão de requests.
3. Fixar critérios de aceite da carga e decidir escala.

Cada passo abaixo carrega o próprio bloco de resposta, o procedimento e o critério de saída. Pular a ordem é o caminho mais curto para um relatório bonito e inútil.

Passo 1: Isolar três custos que a planilha costuma misturar

O primeiro passo separa, por escrito, três linhas de custo que a maioria das empresas trata como uma só: latência e qualidade do provedor, preço de token e overhead do gateway de IA. Esta medição cobre só a terceira linha. Qualquer métrica que misture as outras duas com o overhead do gateway invalida o harness na origem.

A linha (a) responde se o modelo escolhido atende o SLA de qualidade e de tempo de resposta do provedor. Isso se mede com avaliação de saída e com latência ponta a ponta no caminho direto, tema coberto em como medir o desempenho de provedores de LLM. A linha (b) responde quanto custa cada mil tokens depois de câmbio, imposto e roteamento de modelo, tema de colapso do preço do token e de economia de modelo em geral. A linha (c) responde o que a empresa paga, em tempo e em infra, por colocar o gateway no caminho.

O erro clássico é reportar a latência ponta a ponta com gateway e chamar isso de "overhead do gateway". Não é. É a soma do provedor, da rede e do gateway. Overhead é diferença. Sem a subtração, o gateway herda a culpa (ou o mérito) do modelo.

Outro erro clássico: usar economia de token como prova de que o gateway "se paga". Economia de token é linha (b). Pode ser real e ainda assim o gateway estar caro demais em latência p99 ou em memória. As duas contas precisam fechar juntas, em planilhas separadas.

Escreva as três linhas no documento de aceite antes de rodar carga. Se alguém misturar de novo na reunião de resultado, o documento existe para recusar o gráfico.

Passo 2: Montar o harness baseline e o harness com gateway

O segundo passo monta dois caminhos idênticos em tudo, exceto na presença do gateway de IA. Baseline: cliente de carga → provedor. Sob teste: cliente de carga → gateway → provedor. Mesmo modelo, mesma região, mesmo payload, mesma concorrência e mesma duração definem o laboratório; overhead é a diferença entre os dois caminhos, agregada em percentis.

Controle o que o laboratório costuma deixar solto. DNS e TLS warm-up nos dois caminhos, mesma versão de cliente HTTP e mesmo keep-alive. Mesma política de retry (de preferência zero retry no harness de overhead, para não mascarar falha como latência). Mesma janela horária, porque congestionamento de rede e de provedor varia ao longo do dia.

A carga precisa ser a da produção, não a do demo. Se 40% das chamadas em produção usam streaming, o harness usa streaming. Se o prompt mediano tem 2.400 tokens de entrada, o harness não roda com "Hello". Se tool calls existem, eles entram no cenário ou viram um cenário separado. Um único cenário "feliz" subestima a cauda.

Registre o harness como artefato versionado: script de carga, arquivo de payload, variáveis de endpoint, commit hash do gateway sob teste, data e hora UTC do run. Overhead sem reprodutibilidade vira slide. Com reprodutibilidade, vira critério de compra e de release.

Passo 3: Medir latência adicionada em p50, p95 e p99

O terceiro passo calcula a latência que o gateway de IA adiciona, em percentis, nunca só em média. Para cada percentil pXX, overhead_pXX = latência_pXX(com gateway) − latência_pXX(baseline), na mesma carga. Reporte p50, p95 e p99. A média sozinha esconde a cauda e não sustenta critério de produção.

A razão é aritmética, não estética. Em tráfego alto, p99 é o percentil que o usuário "sazonal" sente e que o SLO quebra. Um gateway com +8 ms de média e +120 ms de p99 não é um gateway de +8 ms. É um gateway que falha 1 em cada 100 chamadas no orçamento de latência. A literatura de engenharia de performance trata percentis como o padrão de leitura de cauda precisamente porque a média mente sob distribuição assimétrica (guia de percentis p50/p95/p99).

O Google SRE Book fixa a mesma disciplina do outro lado do contrato: SLIs de latência se expressam em distribuição, e alertas baseados só em média chegam tarde demais (Service Level Objectives, Google SRE). O harness de gateway herda essa regra. Quem aceita média aceita surpresa.

Meça também a taxa de erro e de timeout nos dois caminhos. Um gateway que adiciona 3 ms no p50 e dobra o timeout sob a mesma carga não passou. Overhead de latência e overhead de confiabilidade andam juntos no relatório.

Não invente um limiar universal de p99 "bom". O orçamento de latência é da carga. Um assistente interno assíncrono tolera dezenas de milissegundos a mais; um autocomplete síncrono no checkout não tolera. O passo 6 transforma esse orçamento em critério de aceite. Aqui o trabalho é só medir o delta com honestidade estatística: amostra grande, carga estável, warm-up descartado, cold start isolado se o runtime tiver cold start.

Passo 4: Medir memória, CPU e réplicas sob a mesma carga

O quarto passo captura o custo de recurso do processo do gateway de IA enquanto a carga do passo 3 roda. Memória residente (RSS) por réplica, CPU média e de pico por réplica, número de réplicas necessárias para sustentar a concorrência alvo sem quebrar o p99 de latência. Sem esses três números, o overhead parece só latência.

Gateway é software que processa cada request: parse, auth, regra de roteamento, log, eventual cache, eventual política de fallback. Isso consome CPU e memória de forma proporcional ao tráfego e, em muitos desenhos, ao tamanho do payload. Um teste de latência com uma réplica ociosa subestima o que a produção vai pedir quando o autoscaler acordar.

Meça em platô, não em pico transitório de subida de carga. Suba a concorrência em degraus. Em cada degrau, espere estabilizar, colete percentis de latência e RSS/CPU, só então suba de novo. O gráfico que importa é latência p99 e memória versus requests por segundo, com e sem o gateway no caminho. No baseline, a memória do gateway é zero por definição; o que sobra é a memória do cliente de carga, que se cancela na comparação de infra do gateway.

Separe memória steady-state de vazamento. Um run de 10 minutos não revela leak. Se a decisão de compra é material, rode ao menos uma janela longa (horas) com carga constante e olhe a inclinação do RSS. Inclinação positiva contínua é custo operacional futuro, não detalhe de telemetria.

Anote a configuração: limites de CPU e memória do container ou da VM, política de GC se houver, tamanho de buffer de log, sampling de trace. Mudar sampling de 100% para 1% no meio do teste invalida a série. O harness mede um binário e uma config, não uma ideia.

Passo 5: Converter recursos em custo operacional por milhão de requests

O quinto passo transforma milissegundos e megabytes em dinheiro por milhão de requests do gateway de IA. Some infraestrutura amortizada do gateway (compute, memória, load balancer, observabilidade dedicada) e, quando material, tempo de operação (plantão, tuning, incidentes atribuíveis à camada). Divida pelo volume. Esse é o custo operacional unitário do gateway. Ainda não é preço de token.

Fórmula mínima, por período estável:

Custo_infra_gateway = (vCPU-hora × preço_vCPU) + (GB-hora × preço_GB) + (LB e egress atribuíveis) + (backend de log/trace se exclusivo do gateway).

Custo_ops_gateway = horas de engenharia no período × custo interno da hora, só o que o gateway exige além do caminho direto.

Custo_operacional_por_1M = (Custo_infra_gateway + Custo_ops_gateway) / (requests no período) × 1.000.000.

O preço de token continua fora. Ele entra no business case total da IA, em outra aba, junto com a economia de roteamento de modelo descrita em model router middleware em escala. Aqui a pergunta é outra: quanto a empresa paga para ter o gateway ligado, independentemente de qual modelo atendeu o request.

Em empresas brasileiras que pagam provedor em dólar e infra local em real, mantenha as moedas explícitas. Infra de cluster em BRL. Token em USD. Somar sem FX é o mesmo erro que misturar linha (b) com linha (c). A página pública do Nexforce Router sustenta cobrança em moeda local e o enquadramento de crédito fiscal no caminho de aquisição; câmbio, IRRF, CIDE e demais encargos sobre o token ficam na aba de token (linha b), não como atalho para "provar" o gateway sem medir o overhead do próprio gateway.

Não invente um percentual universal de overhead de infra. Clusters spot, on-demand, serverless e bare metal mudam a conta por um fator grande. O método exige o preço da sua conta cloud ou o unit economics do seu cluster. Sem esse input, o passo 5 para e o relatório fica em recursos físicos, o que já é melhor do que média de latência sozinha, mas ainda não é P&L.

Passo 6: Fixar critérios de aceite da carga e só então escalar

O sexto passo fecha o ciclo com critérios de aceite escritos em cima da carga real, não em cima de um benchmark genérico de vendor. Antes de promover o gateway de IA para 100% do tráfego, a empresa declara o orçamento de overhead que a workload tolera e verifica se o harness passou nos três eixos.

Três eixos bastam na maioria dos casos:

Os valores de X, Y, Z e W saem do produto e do SRE, não deste artigo e não do marketing do fornecedor. Um autocomplete pode fixar p99 adicionado em poucos milissegundos. Um pipeline batch noturno pode fixar o teto em custo por 1M e quase ignorar p50. O método é o mesmo. O orçamento muda.

Escale em fatias. 5% do tráfego com o harness contínuo colado no deploy. Compare percentis da fatia com o baseline sintético e com o histórico do caminho direto. Só aumente a fatia se os três eixos do aceite continuarem verdes. Rollback é parte do critério, não improvisação de madrugada.

Reavalie quando mudar o que o harness controlou: versão major do gateway, regra de roteamento que adiciona fan-out, sampling de trace, modelo dominante, tamanho mediano de prompt. Overhead medido no trimestre passado em outro payload é arqueologia.

Como verificar se a medição está correta

A verificação confirma que o harness mede overhead de verdade, e não um artefato de laboratório criado por amostra curta, carga instável ou caminhos que diferem em modelo, região ou payload. Rode o baseline duas vezes seguidas; a diferença entre as duas corridas baseline deve ser muito menor que o overhead reportado do gateway.

Se o ruído do baseline engolir o delta, a amostra é pequena ou a carga é instável.

Os primeiros três itens matam o harness se falharem:

1. Modelo, região, payload e concorrência idênticos nos dois caminhos.
2. Warm-up descartado; cold start isolado ou eliminado.
3. p50, p95 e p99 reportados; média, se aparecer, é anexo, não titular.

Os três seguintes fecham a aritmética e a telemetria:

1. Overhead_pXX calculado por subtração de percentis do mesmo cenário, não por feeling de dashboard.
2. RSS/CPU coletados no platô, com config de observabilidade fixa.
3. Custo por 1M usa preço real da conta, com moeda explícita.

Faltam processo e artefato. Critérios de aceite datados e assinados antes do run de go/no-go. Artefatos versionados: script, payload, hash, timestamp UTC. Se o item 1 falha, o resto é ficção. Se o critério chega depois do gráfico, o time negocia o teto depois de ver o número que não gostou. Os dois são falhas de processo, não de ferramenta.

Erros comuns ao medir overhead de gateway

Os erros abaixo aparecem com regularidade em bakes de compra e em postmortems de "o gateway ficou caro", quase sempre porque o time mediu a soma errada, misturou abas do business case ou aceitou o gráfico do fornecedor no lugar do harness interno. Cada um tem correção direta.

Medir só a latência ponta a ponta com gateway e chamar de overhead. Correção: sempre subtrair o baseline no mesmo cenário.

Reportar média e esconder p99. Correção: p50, p95 e p99 obrigatórios no relatório de aceite; média opcional.

Usar payload de demo. Correção: capturar distribuição real de tamanho de prompt e de streaming da produção; rodar ao menos o percentil 50 e o 95 dessa distribuição.

Misturar economia de token com custo do gateway é o atalho retórico mais comum em reunião de compra. Correção: abas separadas no business case; gate de compra exige as duas verdes, não uma compensando a outra no discurso.

Ignorar memória e réplicas. Correção: passo 4 obrigatório antes de declarar custo operacional; latência sozinha não fecha P&L.

Aceitar benchmark de fornecedor como aceite interno. Correção: o harness é da empresa, na conta da empresa, no payload da empresa. Número de marketing é hipótese, não critério.

Mudar config de trace ou de log entre baseline e teste. Correção: congelar sampling e nível de log; medir o binário que vai para produção.

Declarar o teto de p99 depois do gráfico. Correção: critério escrito nos pré-requisitos e no passo 6, com data anterior ao run final.

Tabela de métricas do harness

A tabela resume o que coletar no harness do gateway de IA, onde coletar cada série e para que serve no aceite de compra ou de release. Use-a como capa do relatório de medição e como checklist de completude antes de apresentar número algum à diretoria.

Nenhum percentual mágico de "overhead aceitável" entra na tabela. O número que importa é o que a workload assinou no passo 6. O teto é da carga.

FAQ

Qual a diferença entre custo operacional do gateway e custo de token?

Custo operacional do gateway é o overhead do gateway de IA: latência adicionada, compute, memória, operação. Custo de token é o que o provedor cobra pela inferência, mais FX e encargos quando aplicáveis. São abas diferentes do business case. Um pode melhorar enquanto o outro piora.

Dá para medir overhead sem ter o gateway em produção?

Sim. O harness roda em homologação ou em uma fatia sombra, desde que o caminho baseline e o caminho com gateway usem o mesmo modelo, região e payload. Produção valida o que o laboratório mediu; não substitui o método.

Por que p99 importa mais que a média na latência de gateway LLM?

Porque a distribuição de latência de chamadas a modelo é assimétrica e a cauda é onde o SLO quebra. A média dilui timeouts e spikes. Em volume alto, 1% das chamadas é muita chamada. Critérios de produção se escrevem em p95 e p99; a média é comentário.

O Nexforce Router elimina a necessidade desse harness?

Não. Nenhum gateway de IA sério pede fé no lugar de medição. O Nexforce Router concentra observabilidade, regras, limites de spend e fallback em uma API. O harness continua sendo do comprador: é ele que define o orçamento de latência e de infra da própria carga e verifica o delta antes de escalar.

Com que frequência repetir a medição?

A cada mudança que altere o caminho crítico: nova major do gateway, regra de roteamento com fan-out, mudança de sampling de trace, troca do modelo dominante, salto grande no tamanho de prompt. No mínimo, a cada ciclo de capacidade em que o volume ou o mix de cenários muda de patamar.

Referências e Leitura Complementar

• Service Level Objectives, Google SRE Book
• Performance Percentiles: p50, p95, p99
• Como medir o desempenho de provedores de LLM
• Model Router middleware em escala
• Colapso do preço do token e custo de IA
• Nexforce Router

O próximo passo depois do harness

Com o overhead isolado, o comprador para de discutir gateway de IA em abstrato e passa a discutir um número que cabe em critério de aceite, em fatia de tráfego e em renovação de contrato: latência adicionada em p99, custo por milhão de requests do gateway, taxa de erro contra o baseline.

A camada certa de gateway se justifica duas vezes. Uma na aba de token e de modelo, onde regras, limites e fallback protegem margem e continuidade. Outra na aba de custo operacional, onde o harness prova que o gateway cabe no orçamento de latência e de infra da carga. O Nexforce Router existe para a primeira conversa com governança centralizada. A segunda conversa ninguém terceiriza: mede, subtrai, aceita ou recusa.

Quem escala sem delta compra narrativa. Quem escala com delta compra infraestrutura.