Subagentes Baratos: Como Modelos "Lite" Redesenham o Cálculo da Orquestração Multiagente

Na sexta passada eu abri a fatura de API de um sistema de agentes que a gente subiu em abril e passei uns bons vinte minutos olhando para uma linha só. O orquestrador — a parte que decide, planeja e sintetiza — respondia por menos de um quinto do gasto. Todo o resto era fan-out: subagentes lendo documentos, extraindo campos, checando links, rodando o mesmo tipo de tarefa repetitiva dezenas de vezes por requisição. A parte cara do sistema não era a parte inteligente. Era a parte braçal.

Isso não é novidade para ninguém que já colocou multiagente em produção, mas costumava ser um beco sem saída: você sabia que o fan-out era o custo dominante e não tinha muito o que fazer, porque o modelo bom o suficiente para o subagente não errar era, invariavelmente, o mesmo modelo caro que rodava no topo. A resposta padrão era reduzir o número de subagentes. Ou seja, desistir da arquitetura que você escolheu por um bom motivo.

O que mudou em julho é que o Google separou explicitamente essas duas camadas de preço. O Gemini 3.6 Flash entrou como o modelo de trabalho — melhor em código, conhecimento e planejamento agentic — a US$ 1,50 por milhão de tokens de entrada e US$ 7,50 de saída, abaixo do preço de saída do 3.5 Flash. E o Gemini 3.5 Flash-Lite entrou embaixo dele a US$ 0,30 e US$ 2,50, com a documentação oficial descrevendo o modelo, em texto, como otimizado para "execução de alto throughput e baixo custo para tarefas de subagente". Não é interpretação minha: a camada de subagente virou um produto nomeado.

Este post fecha uma sequência de três. No sábado escrevi sobre roteamento SLM→LLM e o que isso faz com a arquitetura de custo de inferência, e no domingo sobre deep agents e planejamento hierárquico com LangGraph. Aqui eu junto os dois eixos: o que acontece com a topologia de um sistema multiagente quando a camada de baixo fica três a cinco vezes mais barata que a de cima, o que você pode rebaixar sem se arrepender, e como medir isso sem cair na armadilha de achar que economizou quando na verdade só empurrou o custo para outro lugar.

Por Que A Conta Do Fan-Out Sempre Foi O Gargalo

A economia de multiagente sempre foi desconfortável por um motivo estrutural: o ganho de qualidade vem principalmente de gastar mais computação, e a conta cresce de forma multiplicativa. O relato de engenharia da Anthropic sobre o sistema multiagente de research é o dado público mais citado nesse ponto — o sistema deles consome cerca de quinze vezes mais tokens que uma interação de chat comum, e o volume de tokens sozinho explica algo em torno de 80% da variação de desempenho observada. Traduzindo: boa parte do que chamamos de "arquitetura melhor" é, na prática, orçamento de computação maior com um nome mais bonito.

Isso coloca o arquiteto numa posição chata. Se o ganho é proporcional ao gasto, e o gasto do fan-out é o número de subagentes vezes o contexto médio de cada um, então cada decisão de topologia é uma decisão de orçamento disfarçada. Já escrevi sobre isso quando comparei os cinco padrões de orquestração que dominam a produção: o overhead de coordenação não é um detalhe de implementação, é o que decide se o padrão se paga.

O detalhe que mais me incomodava é que o custo do fan-out é dominado por entrada, não por saída. Um subagente típico de extração recebe um documento inteiro — quarenta, sessenta, cem mil tokens — e devolve um JSON de dois mil. Você está pagando preço de modelo de fronteira para o modelo ler, não para ele pensar. E ler é justamente a parte da tarefa em que a diferença entre um modelo grande e um modelo pequeno bem instruído é menor.

Vale fazer a conta com números reais, porque ela é mais reveladora do que a intuição. Imagine um fan-out de oito subagentes, cada um recebendo 40 mil tokens de contexto e devolvendo 2 mil. Com tudo rodando em Gemini 3.6 Flash, são 8 × (40k × US$ 1,50/1M + 2k × US$ 7,50/1M) = 8 × US$ 0,075 = US$ 0,60 por requisição. Com os mesmos oito subagentes em 3.5 Flash-Lite, são 8 × (40k × US$ 0,30/1M + 2k × US$ 2,50/1M) = 8 × US$ 0,017 = cerca de US$ 0,136. Um fator de aproximadamente 4,4 vezes, e a maior parte da economia veio da entrada, não da saída.

Note que a razão de preço não é uniforme: a entrada é cinco vezes mais barata, a saída é três vezes. Isso significa que o ganho real depende do perfil da tarefa. Fan-out de leitura pesada e resposta curta se aproxima do fator cinco. Fan-out que gera muito texto — rascunhar variações, escrever código — fica perto do fator três. É a primeira coisa que eu olho antes de decidir se vale reescrever a camada de subagentes: qual é a proporção entrada/saída dessa etapa.

O Que Muda Quando O Subagente Custa Um Quarto Do Orquestrador

Três padrões que eu descartava por custo passaram a fechar a conta, e vale nomear cada um pelo mecanismo, não pelo hype.

O primeiro é paralelismo agressivo. Quando o subagente custa cerca de um quarto — o fator de 4,4 do exemplo acima, no meio da faixa de três a cinco —, o mesmo orçamento que comportava três subagentes comporta doze. Isso não é apenas "mais do mesmo": muda o que você pode decompor. Uma tarefa que você fatiava em três blocos grandes — porque cada chamada doía — pode ser fatiada em doze blocos pequenos, e blocos pequenos têm contexto mais restrito, o que reduz a chance de o subagente se perder. O próprio Google usou esse desenho como exemplo público do lançamento: o 3.6 Flash como agente mestre e o 3.5 Flash-Lite gerando 25 conceitos de web design de uma vez. Não é uma tarefa difícil por conceito, é uma tarefa cara por volume — exatamente o tipo que a camada lite existe para absorver.

O segundo é exploração redundante. Rodar três abordagens diferentes para a mesma subtarefa e deixar o orquestrador escolher a melhor sempre foi tecnicamente trivial e economicamente indefensável. Com os candidatos custando o mesmo que a resposta final, virava um "não" automático na revisão de arquitetura. A um quarto do preço na camada de baixo, redundância deixa de ser luxo e vira mitigação de variância — que é, no fundo, o que ela sempre foi. O ponto importante: a escolha entre as alternativas continua sendo trabalho de orquestrador. O barateamento não muda quem julga, muda quantos candidatos você pode gerar antes de julgar.

O terceiro é verificação cruzada. Esse é o que mais me interessa. Um subagente barato dedicado a conferir a saída de outro subagente — validar schema, checar se a citação existe mesmo no documento de origem, confirmar que o número extraído aparece na página indicada — costumava parecer overhead. Com a diferença de preço atual, um verificador roda por uma fração do custo do que ele verifica, e o retorno em confiabilidade é desproporcional. Um verificador de US$ 0,017 que impede uma alucinação de chegar ao usuário é o melhor negócio disponível nesse desenho.

O que não muda é o custo de coordenação. Doze subagentes exigem doze contratos de entrada e saída, doze modos de falha, doze pontos onde a agregação pode receber lixo. O preço do token caiu; o preço da complexidade não. Um sistema com fan-out de doze e agregação ingênua é pior que um com fan-out de três e agregação cuidadosa, e nenhuma tabela de preços conserta isso.

Há também um efeito de latência que costuma passar batido na discussão de custo. O 3.5 Flash-Lite roda a 350 tokens de saída por segundo segundo o índice da Artificial Analysis, o mais rápido da série 3.5. Em fan-out paralelo, a latência total é a do subagente mais lento, não a soma — então rebaixar a camada de baixo frequentemente melhora a percepção de velocidade ao mesmo tempo que corta o custo. É raro os dois eixos andarem juntos, e quando andam, vale conferir se não há uma troca escondida em qualidade que você ainda não mediu.

O Que Desce Para O Modelo Lite E O Que Não Desce

A heurística que venho usando é simples e tem se sustentado: desce bem o que tem output verificável e contexto restrito; não desce o que exige julgamento ou síntese.

Output verificável quer dizer que existe um teste barato e determinístico para saber se a saída está certa — um schema JSON que valida ou não, um número que confere ou não com a fonte, um teste que passa ou não. Contexto restrito quer dizer que o subagente não precisa carregar o estado global da tarefa para fazer o trabalho dele; ele recebe um pedaço bem delimitado e devolve um pedaço bem delimitado. Quando as duas condições valem, o rebaixamento é seguro porque o erro é detectável e o espaço de erro é pequeno.

Julgamento e síntese violam as duas condições ao mesmo tempo. Decidir qual das três abordagens é a melhor não tem gabarito; consolidar doze resultados parciais num relatório coerente exige exatamente o contexto amplo que a camada lite não deveria carregar. Aqui não há economia real — há transferência de erro para um lugar onde ninguém vai detectar.

Tarefa	Desce para o lite?	Por quê	Sinal de que deu errado
Extração estruturada de documento	Sim	Schema valida, contexto é o documento	Taxa de falha de validação sobe
Classificação e roteamento de itens	Sim	Rótulo é discreto e auditável	Distribuição de classes distorce
Busca e recuperação de trechos	Sim	Trecho existe ou não no corpo	Citações que não batem com a fonte
Verificação de saída de outro agente	Sim	Tarefa é binária por desenho	Verificador aprova tudo
Geração de variações e candidatos	Sim	Julgamento fica com o orquestrador	Candidatos convergem entre si
Transformação mecânica de formato	Sim	Diff é comparável linha a linha	Perda silenciosa de campos
Decomposição da tarefa em subtarefas	Não	Define o resto da execução	Fan-out com dependência oculta
Síntese final de resultados parciais	Não	Exige contexto global	Relatório perde nuance ou contradiz
Escolha entre alternativas concorrentes	Não	Julgamento sem gabarito	Escolhe sempre a primeira opção
Decisão com efeito irreversível	Não	Custo do erro domina o custo do token	Você descobre pelo cliente
Escrita de código com efeito colateral	Depende	Só com teste executável fechando o loop	Testes verdes, comportamento errado

A coluna que mais uso na prática é a última. Rebaixar um subagente sem definir de antemão qual sinal indicaria que o rebaixamento foi ruim é a forma mais comum de economizar hoje e pagar em dobro em três semanas. Se você não sabe dizer o que vai piorar primeiro, você não sabe o que está medindo.

O 3.5 Flash-Lite tem um detalhe de operação que ajuda aqui: os níveis de pensamento são configuráveis. Você pode fixar o nível mínimo para tarefas de alto volume e latência crítica, ou subir o nível para cargas de subagente com múltiplos passos. Na prática isso cria uma faixa intermediária entre "modelo lite burro" e "modelo caro" que não existia antes — e é onde eu tenho colocado as tarefas da linha "depende" da tabela. O modelo é o mesmo; o que muda é quanto orçamento de raciocínio você autoriza por chamada.

Uma observação sobre a linha de escrita de código: a diferença entre as gerações é real e mensurável, mas não é uniforme. O Google reporta o 3.5 Flash-Lite em 54% no Terminal-Bench 2.1 contra 31% da geração Flash-Lite anterior, e em 54,2% no SWE-Bench Pro contra 49,6% do 3 Flash — ou seja, em algumas avaliações agentic o lite da geração nova supera o Flash da geração anterior. Isso significa que a fronteira do que "desce bem" se moveu, não que ela desapareceu. Continua havendo tarefa que só fecha com o modelo de cima.

Como Medir A Troca Sem Se Enganar

O erro de medição mais comum aqui é avaliar só o resultado final. Você troca o modelo de oito subagentes, roda a suíte de eval de ponta a ponta, vê o score cair de 84% para 82% e conclui que a troca saiu barata. Só que essa queda de dois pontos pode estar escondendo um subagente que passou de 95% para 60% de acerto, compensado por um orquestrador que ficou bom em contornar o erro dele. Você acabou de comprar uma dívida silenciosa: no dia em que a distribuição de entrada mudar, a compensação para de funcionar e o sistema cai de uma vez.

A disciplina que resolve isso é eval por subtarefa. Cada subagente precisa do próprio conjunto de casos, com gabarito próprio, medido isoladamente — sem o orquestrador no meio para maquiar. Isso dá trabalho de montar, mas é o único jeito de saber onde a degradação de fato aconteceu. E como as tarefas que descem bem para o lite são justamente as de output verificável, o gabarito quase sempre já existe em algum lugar: o schema, o teste, o documento de origem.

Além do score, meça três coisas por subagente antes e depois da troca. Primeira, a taxa de retry — se o subagente barato erra e o sistema tenta de novo, você pode estar pagando duas chamadas baratas onde pagava uma cara, e o saldo pode ser negativo. Segunda, o tamanho médio da saída — modelo mais barato costuma ser mais prolixo, e saída maior no subagente vira entrada maior no agregador, com o custo aparecendo na conta do orquestrador. Terceira, a taxa de escalonamento — quantas vezes o orquestrador precisou refazer o trabalho do subagente por conta própria.

Essa terceira métrica é a que mais me salvou. Escalonamento é custo transferido, não custo eliminado: o token saiu da linha barata e reapareceu na linha cara, e o dashboard de custo por modelo não conta essa história. Se o custo do lite caiu 70% e o do orquestrador subiu 40%, você precisa olhar a conta consolidada por requisição antes de comemorar. Já tratei desse tipo de contabilidade honesta no post sobre a stack de eficiência de token, e o princípio é o mesmo: custo por token é métrica de fornecedor, custo por tarefa concluída é métrica de engenharia.

A própria comunicação do Google sobre o 3.6 Flash é um bom exemplo dessa distinção bem feita. O que eles destacam não é o preço por token isolado, é a combinação: 17% menos tokens de saída que o 3.5 Flash pelo índice da Artificial Analysis, chegando a até 65% em benchmarks como o DeepSWE, somado a um preço menor por token. Menos passos de raciocínio e menos chamadas de ferramenta para completar fluxos multi-etapa. É o custo por tarefa que cai, não só o custo por token — e é exatamente essa a métrica que você deveria estar reproduzindo no seu ambiente antes de dar a troca como ganha.

Quando Muitas Chamadas Baratas Saem Mais Caro Que Poucas Caras

Aqui está o efeito colateral que quase ninguém coloca no slide. Barateamento de subagente convida a decompor mais, e decompor mais nem sempre é melhor — em algumas classes de tarefa, é mensuravelmente pior, e não só em custo.

Um trabalho de Tran e Kiela, de Stanford, testou exatamente isso: comparou sistemas single-agent e multiagente em raciocínio multi-hop mantendo o orçamento de tokens de raciocínio constante entre os dois. O resultado é desconfortável para quem vende topologia: com orçamento igual, o agente único iguala ou supera o sistema multiagente. O argumento teórico deles se apoia na desigualdade do processamento de dados — cada handoff entre agentes só pode perder informação, nunca criar. E o achado metodológico é ainda mais incômodo: a maioria das comparações públicas favoráveis a multiagente compara um agente único contra um sistema que gasta muito mais computação, o que infla o ganho aparente.

Isso não invalida multiagente. O próprio artigo aponta o regime onde o multiagente volta a ganhar: contextos degradados, grandes demais para um único agente manter coerência. Mas coloca uma pergunta que subagente barato torna mais urgente, não menos. Se o ganho que você atribui à sua topologia é na verdade ganho de orçamento de computação, então baratear o token não melhora a arquitetura — só torna mais barato continuar errado por mais tempo.

Os sinais de que você caiu nessa são razoavelmente fáceis de reconhecer quando você sabe o que procurar. O primeiro é custo por requisição estável ou crescente apesar da troca de modelo: você trocou o modelo, cortou o preço unitário pela metade, e a conta não se moveu — porque o número de chamadas cresceu na mesma proporção. O segundo é o agregador virando o gargalo: se o contexto que chega ao orquestrador cresceu porque agora são doze saídas em vez de três, o custo migrou para a etapa mais cara do pipeline. O terceiro é qualidade estável com variância maior: mesma média, cauda pior, que é o padrão típico de decomposição excessiva com handoffs perdendo informação.

O teste que eu recomendo é chato e funciona: antes de expandir o fan-out, rode a versão com orçamento fixo. Pegue o orçamento de tokens que a arquitetura barata consome, dê o mesmo orçamento para uma versão mais simples com menos subagentes e modelos melhores, e compare. Se a versão simples ganhar, o problema nunca foi preço — era decomposição. Se a versão com fan-out ganhar de verdade sob orçamento igual, aí sim você tem uma arquitetura que se justifica, e o barateamento é lucro em cima de uma decisão que já estava certa.

Conclusão

O que o Gemini 3.5 Flash-Lite representa não é um modelo novo a mais no catálogo, é o reconhecimento explícito de que a camada de subagente é uma categoria de produto com requisitos próprios: throughput alto, latência baixa, custo por chamada que sobrevive a ser multiplicado por doze. A documentação da Google diz isso com todas as letras. Quem projeta sistema multiagente vinha improvisando essa camada com modelos que não foram feitos para ela, e a diferença de preço entre os US$ 1,50/US$ 7,50 do 3.6 Flash e os US$ 0,30/US$ 2,50 do lite é o que torna a separação prática, não só conceitual.

Ainda assim, eu terminaria essa análise com mais cautela do que ela pede. A tentação óbvia é usar o barateamento para expandir o fan-out, e o achado de Tran e Kiela sugere que boa parte do ganho que atribuímos a topologias elaboradas era, o tempo todo, orçamento de computação disfarçado. Se isso for verdade no seu sistema — e você só descobre medindo com orçamento fixo —, subagente barato não vai te dar uma arquitetura melhor. Vai te dar a mesma arquitetura, mais barata, com mais espaço para não descobrir que ela está errada.

O uso que eu acho mais defensável não é expandir, é adensar. Manter a topologia que já se provou, rebaixar as etapas que passam no teste de output verificável e contexto restrito, e reinvestir a economia em verificação cruzada — a parte que a gente nunca conseguiu justificar quando cada checagem custava o preço de uma chamada de fronteira. Um sistema com o mesmo número de subagentes e um verificador barato atrás de cada etapa crítica é um upgrade que eu consigo defender numa revisão de arquitetura. Doze subagentes onde antes havia três, sem eval por subtarefa, é uma conta que só aparece depois.

Fontes:

Subagentes Baratos: Como Modelos "Lite" Redesenham o Cálculo da Orquestração Multiagente

Subagentes Baratos: Como Modelos "Lite" Redesenham o Cálculo da Orquestração Multiagente

Por Que A Conta Do Fan-Out Sempre Foi O Gargalo

O Que Muda Quando O Subagente Custa Um Quarto Do Orquestrador

O Que Desce Para O Modelo Lite E O Que Não Desce

Como Medir A Troca Sem Se Enganar

Quando Muitas Chamadas Baratas Saem Mais Caro Que Poucas Caras

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose