Engenharia de Custo

Engenharia de custo de um sistema multiagente

18 de julho de 2026 · 5 min de leitura

O custo de um sistema multiagente é uma propriedade de design. Ele é decidido quando você escolhe qual modelo roda qual passo, o que acontece na falha, e o que a sua infraestrutura faz enquanto ninguém está usando. Descobrir o custo depois, na fatura, significa que o design pulou um requisito.

Construir o Proposal Architect para o Google for Startups AI Agents Challenge 2026 forçou a pergunta cedo, porque uma demo pública tem o pior perfil de custo que existe: tráfego em rajadas, não autenticado, contra um backend de inferência caro. Estas foram as alavancas que importaram.

Roteie modelos por onde a qualidade se compõe

Um pipeline multiagente não precisa de uma chamada de modelo premium em cada passo. A maioria dos passos (extração, ancoragem, composição) roda bem em modelos rápidos e baratos. Reservamos o tier premium para exatamente um passo, o agente arquiteto, porque a qualidade da arquitetura se propaga para tudo que vem depois: a estimativa, o preço, a narrativa. Uma chamada cara que melhora as baratas ao redor é um bom negócio; um pipeline de chamadas caras é um subsídio para ninguém.

Limite o pior caso, não a média

Retries são onde orçamentos morrem em silêncio. Um pipeline que repete tudo em qualquer falha tem um custo de pior caso várias vezes maior que a média. Dois limites mudam isso: um deadline duro por chamada de modelo e por execução (uma chamada pendurada queima tempo, não orçamento), e retry por estágio reaproveitando o estado anterior, de modo que uma falha do compositor custa uma chamada de compositor, não uma re-execução do pipeline inteiro.

Zere a computação ociosa e torne o pico finito

Frontends de inferência serverless se pagam em demos e produtos iniciais: scale-to-zero significa que a computação do frontend de inferência cai a zero quando parado, e um teto de instâncias significa que um pico de tráfego (ou uma tentativa de abuso) tem um limite conhecido. Adicione um throttle de aplicação na frente das chamadas de modelo e os três limites se compõem: a computação ociosa é grátis, rajadas são limitadas, e um único ator não consegue monopolizar o orçamento.

Trate alertas de billing como parte da arquitetura

Um alerta de orçamento não é um detalhe de operação; é o detector de fumaça do sistema, e pertence à revisão de design ao lado da tabela de timeouts. Se o alerta um dia disparar, algum limite acima falhou, e isso é um sinal de engenharia, não de contabilidade.

Quanto custa uma execução, de verdade

A resposta honesta é uma ordem de grandeza, não um número: uma execução limitada é um punhado de chamadas de modelo, a maioria em tiers baratos, com exatamente uma chamada premium. O valor preciso muda com modelos, tamanhos de prompt e comprimentos de saída, e qualquer precisão decimal que imprimíssemos aqui seria falsa. O que o design garante é a forma: o custo por execução é limitado, conhecido de antemão, e dominado pela única chamada que você escolheu tornar cara.

A lição

Engenharia de custo para agentes é engenharia comum: roteie por valor, limite os modos de falha, coloque teto na infraestrutura e instrumente o dinheiro. Times que tratam custo como propriedade emergente se surpreendem. Times que o tratam como requisito, não.