Um request de IA pode funcionar tecnicamente e ainda ser uma falha de produto porque consumiu tokens demais, esperou em uma fila ilimitada, ocupou memória GPU cara ou disparou uma cadeia de chamadas cujo valor nunca justificou o custo.
A orientação de custos da OpenAI agrupa as alavancas óbvias: fazer menos requests, usar menos tokens e selecionar modelos menores quando preservam qualidade. A orientação de latência acrescenta um alerta importante: geração de output costuma ser a etapa mais lenta, e um LLM não deve ser a opção padrão para trabalho que um método determinístico resolve. Essas são decisões de arquitetura, não truques de prompt.
Um budget de request deve declarar o máximo de chamadas de modelo, tokens de entrada, tokens de saída, tool calls, tempo total, tempo em fila, retries e dinheiro que uma tarefa pode consumir. Sem esse contrato, um agente pode estar “funcionando corretamente” enquanto gasta a margem do produto de forma recursiva.
Meça entrada sem cache, entrada em cache, saída, reasoning, tool calls, retrieval, storage, rede e retries separadamente. Um único total de tokens esconde se o sistema envia contexto inchado, gera respostas verbosas ou paga repetidamente pelo mesmo prefixo. Prompt caching da OpenAI expõe o uso de cached tokens e recomenda colocar conteúdo estável primeiro para reutilizar prefixos idênticos.
Em inferência self-hosted, prefix caching cumpre o mesmo papel econômico. O vLLM documenta reutilização de blocos de KV cache quando requests compartilham prefixo, evitando computação redundante. Mas cache hit rate é uma propriedade do workload. Um cache que consome memória GPU sem atender prefixos repetidos pode aumentar o custo.
Uma GPU pode ser cara quando ociosa e lenta quando sobrecarregada. Dynamic batching combina requests compatíveis para melhorar throughput, mas troca um pouco de espera por melhor utilização. NVIDIA Triton expõe batch size, atraso máximo, tamanho de fila, prioridades e timeouts porque não existe uma configuração correta universal. Chat interativo e enriquecimento noturno não devem competir sob a mesma política de latência.
Autoscaling só ajuda quando o sinal representa o gargalo real e a nova capacidade chega antes do backlog ficar obsoleto. Kubernetes HPA escala com métricas customizadas e externas, mas opera como control loop com atrasos e estabilização. Profundidade da fila, idade da mensagem mais antiga, sequências ativas, pressão de cache e saturação GPU costumam ser mais úteis que CPU isolada.
Filas tornam bursts sobrevivíveis, mas também escondem sobrecarga até o trabalho em espera ficar impossível de drenar. A Builders' Library da Amazon descreve como evitar backlogs insuperáveis, priorizar workloads e fazer load shedding. Em sistemas de IA, trabalho stale é especialmente caro: uma sugestão atrasada, execução duplicada de agente ou avaliação de uma versão antiga pode consumir inferência completa e não entregar valor.
Limite filas por quantidade, idade e valor econômico. Rejeite cedo quando a tarefa não puder cumprir seu deadline. Cancele chamadas downstream quando o usuário sair ou a tarefa pai expirar. Separe filas interativas, background, avaliação e baixa prioridade. Backpressure não é falha de produto; gasto silencioso e ilimitado é.
| Pressão de custo | Sinal observado | Controle de engenharia | Falha se ignorado |
|---|---|---|---|
| Contexto grande demais | Input tokens, qualidade do retrieval, proporção em cache. | Filtrar contexto, resumir, versionar prompts e estabilizar prefixos. | Custo repetido de prefill e latência maior. |
| Geração verbosa | Output tokens, tempo total, respostas abandonadas. | Limites de output, respostas estruturadas, prompts concisos e modelo menor. | Custo de decode domina enquanto usuários esperam ou saem. |
| Chamadas demais | Calls por tarefa, profundidade, retries e tool loops. | Orquestração com budget, combinar ou paralelizar etapas, alternativas determinísticas. | Loops de agentes multiplicam custo e falhas. |
| Baixa utilização GPU | Sequências ativas, batch size, memória e compute GPU. | Dynamic batching, routing, modelos adequados e batch agendado. | Pagamento por capacidade ociosa. |
| Sobrecarga de fila | Profundidade, maior idade, deadlines perdidos e cancelamentos. | Filas limitadas, prioridade, admission control, load shedding e backpressure. | Trabalho stale consome capacidade e backlog não drena. |
| Gasto descontrolado por tenant | Custo por tenant, tarefa, feature, resultado e janela. | Quotas, budgets por tarefa, tiers de modelo, alertas e degradação. | Um workflow destrói margem para todos. |
Eu construiria um control plane de custos de inferência que atribui budget a cada tarefa antes da execução. Ele rotearia trabalho simples para código determinístico ou modelos menores, preservaria prefixos favoráveis a cache, escolheria capacidade interativa ou batch e encerraria cadeias quando o valor marginal ficasse abaixo do custo restante.
O dashboard conectaria dinheiro a comportamento: custo por resultado útil, tokens de entrada, saída e cache, utilização GPU, preenchimento de batch, idade de fila, deadlines perdidos, cancelamentos, retries e custo evitado por routing, caching ou rejeição. A melhor métrica de economia não é “gastou menos”; é “removeu desperdício sem reduzir resultados úteis”.
Capacidade não é infinita só porque uma API aceita outro request. Engenharia de custos torna escassez explícita em cada camada. Defina budget antes do trabalho, reutilize computação quando for realmente reutilizável, faça batching onde a latência permite e aplique backpressure antes que filas transformem trabalho caro em trabalho sem valor.
Artigo sobre engenharia de custos de compute para IA, cobrindo budgets por request, tokens, utilização GPU, prompt e prefix caches, dynamic batching, filas limitadas, backpressure e custo por resultado útil.