Pular para o conteúdo principal

Roteamento automático de modelos: efeito sobre custo e falha operacional

Limitação de validade — leia antes de citar

Na janela analisada, todo o volume veio da própria operação interna da plataforma, não de conversas de clientes. O contexto médio por turno foi de 471.750 tokens de entrada — um perfil muito diferente do de um atendimento comum.

A economia aparente desta versão (70,8% a 98,1%) descreve o custo de a plataforma operar a si mesma e não é generalizável para o uso real da plataforma. A hipótese segue não confirmada em tráfego de cliente.

Status: análise observacional preliminar, em janela única de 7 dias. O achado mais importante desta versão é uma limitação de validade externa, não uma confirmação da hipótese.

Resumo​

Contexto — Plataformas de agentes autônomos compõem especialistas a partir de prompt, skills e tools; a escolha do modelo de linguagem que atende cada turno é, crescentemente, automatizada por um resolvedor em múltiplos níveis de precedência.

Objetivo — Quantificar, em um ambiente de produção real, se o roteamento automático de modelo reduz o custo por conversa sem aumentar a falha operacional do serviço, em relação a um baseline de modelo único fixo.

Métodos — Estudo observacional sobre telemetria auditada de turnos, em janela rolante de 7 dias. Unidade de análise: conversa. Desfecho primário: custo por conversa. Gate de não-inferioridade (Δ = 2 pp): falha operacional do serviço, por dois sinais independentes — turnos sem saída e conversas com erro associado. Baseline: contrafactual sintético por recálculo de custo sob um modelo forte único, com análise de sensibilidade multi-baseline.

Resultados — Na janela, o custo contrafactual de modelo único ficou entre 3,4 e 52,2 vezes o custo observado no braço roteado — economia aparente de 70,8% a 98,1%. A validade externa é limitada pelo perfil de tráfego (operação interna, contexto muito grande).

Conclusão — O método (recálculo contrafactual de custo + gate de não-inferioridade validado contra o formato real da telemetria) é aplicável e revela economia aparente de custo; a generalização para tráfego de cliente permanece em aberto, dependente de uma janela com conversas reais de diferentes organizações.

Palavras-chave: agentes autônomos; roteamento de modelos; custo de inferência; large language models; observabilidade.

1. Introdução​

1.1 Problema​

Agentes autônomos baseados em large language models (LLMs) têm custo de inferência variável e material em produção. Em uma plataforma como a Lab019, um mesmo especialista pode ser atendido por modelos de custo unitário muito distinto — de um modelo compacto a um modelo de raciocínio caro — em função da decisão de roteamento tomada turno a turno. A pergunta de engenharia econômica que este trabalho ataca é direta: a automação dessa escolha entrega custo menor do que a alternativa simples de fixar um único modelo forte, sem piorar o serviço?

1.2 Objeto de estudo​

A plataforma é tratada como um único agente (o software). Os especialistas — configurações de prompt, skills e tools — são o contexto fixo; a variável de interesse é o modelo selecionado pelo resolvedor, que decide em cinco níveis de precedência: escolha explícita do cliente, fixação da conversa, padrão da organização, padrão do especialista e padrão da plataforma.

1.3 Hipótese​

H₁: o roteamento automático reduz o custo médio por conversa em relação ao baseline de modelo único, mantendo não-inferioridade (Δ = 2 pp) na taxa de falha operacional do serviço.

Por que "falha operacional" e não "qualidade" de forma ampla: a telemetria disponível não contém sinal de sucesso de tarefa (ver Seção 2.6). A hipótese é restrita à dimensão de qualidade observável em produção.

1.4 Contribuições​

  1. Operacionalização de variáveis a partir de telemetria nativa, sem instrumentação adicional.
  2. Baseline contrafactual reprodutível, com os custos unitários registrados na janela do estudo e análise de sensibilidade multi-baseline.
  3. Método de avaliação de roteamento em produção sem rótulos de tarefa, com a distinção explícita entre falha operacional (N1/N2) e sucesso de tarefa (N3).
  4. Achado metodológico transferível: proxies de qualidade precisam ser validados contra o formato real da telemetria — o gate original era vazio (sinais que nunca coexistem), e a unidade "conversa" exige auditar a semântica do identificador.

1.5 Trabalhos relacionados​

A literatura de roteamento de LLMs converge na formulação que este trabalho adota: rotear cada consulta ao menor modelo capaz, mantendo a qualidade do modelo forte. O baseline canônico — "um único modelo para todas as tarefas" — foi formalizado por Shnitzer et al. [1]. Dois trabalhos seminais estabelecem o resultado que se busca replicar: RouteLLM [9] (roteador por preferência humana, custo reduzido >2×) e FrugalGPT [10] (cascata iguala o melhor LLM individual com até 98% de redução de custo).

A linha de cascatas tem fundamento teórico sólido: mistura de representações de pensamento [11] (ICLR'24, ~40% do custo de um modelo de fronteira), aprendizado online com no-regret [12] (ICML'24, até 90% de corte), C3PO [13] (predição conformal, garantias de orçamento sem rótulos) e UCCI [14] — que avalia cascata calibrada em produção real (75k consultas, 31% de corte, IC [27%, 35%]). No domínio multi-agente: ProgRouter [15] (EMNLP'26), CASTER [16] (até 72,4% de corte) e COREA [17] (EACL'26). A ressalva teórica de Zeng e Jing [8] — controle ponto a ponto é forte demais, só o conjunto é viável — descreve exatamente o roteamento por especialista e nível de esforço desta plataforma.

Lacuna: quase toda a literatura mede qualidade por acurácia em benchmark ou LLM-as-a-Judge; não há estudo observacional com recálculo contrafactual de custo sobre telemetria nativa de uma plataforma de agentes em produção, explicitando o que é mensurável sem rótulos.

2. Métodos​

2.1 Fonte de dados​

Telemetria auditada de turno, mantida em janela rolante de 7 dias. Cada registro traz, entre outros: instante, identificadores de organização, conversa, mensagem e agente, o modelo pedido e o modelo efetivamente servido, o provedor, a base de custo, tokens de entrada, de saída e de raciocínio, custo em dólares, latência até o primeiro token e duração total, a origem da decisão de modelo e quantas vezes houve fallback de modelo.

Ausentes no registro: papel de quem fala, conteúdo de mensagem, avaliação do cliente, motivo de término e transferência para atendimento humano.

2.2 Unidade de análise e estrutura de erros​

  • Unidade primária: conversa; custo agregado por conversa.
  • Suposição: turnos da mesma conversa são correlacionados → erros agrupados por conversa (ou efeitos mistos).
  • Estratificação por agente obrigatória.
  • Auditoria do identificador: a plataforma atribui o identificador de conversa por dois caminhos distintos, com semânticas de vida diferentes. Um deles é estável; o outro é reiniciado depois de um período de inatividade, e é esse — o curto — que faz uma mesma relação de turnos aparecer como conversas separadas. Na janela, 80,6% dos registros vinham do identificador estável e 19,4% do reiniciável. A taxa de conversas de um turno só foi de 29,0% no reiniciável e 95,5% no estável — a maior parte dessa diferença é real, mas parte é inflada pelo reinício por inatividade.

2.3 Variáveis​

PapelVariávelOperacionalização
Desfecho primárioCusto por conversasoma do custo em dólares dos turnos da conversa
Gate (a)Turno sem saídaproporção de turnos sem tokens de saída
Gate (b)Conversa com erro associadoconversas casadas com um registro de erro
SecundárioLatênciaduração total e tempo até o primeiro token
TratamentoRoteamento automáticodecisão de modelo do especialista ou fixada na conversa
ControleBaseline de modelo únicocontrafactual sintético (Seção 2.4)
Correção do gate N1

"Sem tokens de saída" e "registro de erro" nunca coexistem no mesmo registro — são schemas diferentes. Foram tratados como dois sinais independentes.

Observação: a escolha de modelo feita à mão na configuração ficou fora da análise principal — nesse caso o custo não é atribuível ao roteador, e a falha tende a ser de infraestrutura, não de decisão.

2.4 Baseline sintético​

custo_contrafactual = tokens_de_entrada × preço_de_entrada(M*)
                    + tokens_de_saída × preço_de_saída(M*)

Os custos unitários de entrada e saída foram capturados da plataforma durante a janela analisada e versionados com os dados do estudo. Eles não são reproduzidos aqui, porque mudam ao longo do tempo.

Escolha do baseline (risco de cherry-picking): o "modelo forte" não é inequívoco — adota-se sensibilidade multi-baseline, com três modelos fortes de custo unitário distinto, e reporta-se a faixa.

2.5 Plano de análise​

  1. Descritiva por origem da decisão de modelo e por especialista.
  2. Inferência primária: custo por conversa (roteado vs. cada baseline), com intervalo de confiança e erros agrupados por conversa.
  3. Não-inferioridade (Δ = 2 pp) das duas taxas de falha.
  4. Sensibilidade: baselines × premissas de custo unitário.
  5. Robustez: outliers.
  6. Exploratória: desfecho operacional.

2.6 Adequação da métrica de "sucesso"​

NívelMétricaViabilidade no formato real
N1 — operacionalturnos sem saída + conversas com erro associadoVIÁVEL (gate, com correção)
N2 — desfecho operacionalturnos, conversas de um turno, erro associado, saída vaziaPARCIALMENTE VIÁVEL
N3 — sucesso de tarefaLLM-as-a-Judge / benchmarkNÃO DISPONÍVEL

A afirmação central é "reduz custo sem aumentar falha operacional" — não "sem degradar qualidade".

3. Resultados​

3.1 Resultados observados​

Volume e perfil: 888 turnos, 356 conversas — todo o volume vindo da operação interna da plataforma. Média de 471.750 tokens de entrada por turno.

Braço de tratamento (decisão do especialista ou fixada na conversa): 870 turnos, 355 conversas, 410.422.539 tokens de entrada, 7.465.036 de saída e 472.715 de raciocínio.

Comparação de custo (contrafactual):

Baseline forte únicoCusto relativo (observado = 1)Economia aparente
Modelo C3,4×70,8%
Modelo A16,7×94,0%
Modelo B52,2×98,1%

Síntese interpretativa (não é achado): a economia é dominada pela diferença de custo unitário de entrada sobre contexto gigante, não pelo mecanismo "rotear fácil vs. difícil" da literatura. O número é real, mas mede um fenômeno diferente daquele de RouteLLM/FrugalGPT.

Descritiva por origem da decisão de modelo:

Origem da decisãoturnosconversas*turnos sem saídamediana de duração (ms)
padrão do especialista8293546,27%69.993
fixada na conversa41140,0%21.775
modelo escolhido à mão na configuração18427,8%16.388
padrão da organização / da plataforma00——

* conversas não exclusivas entre as origens: 13 conversas aparecem nas duas primeiras linhas ao mesmo tempo. Por isso a soma das colunas excede as 356 conversas do total — a coluna de conversas é uma contagem por origem, não uma partição.

Taxas de falha observadas (critério definido em Δ = 2 pp; o teste formal de não-inferioridade está pendente — ver Seção 3.2):

  • Turnos do braço sem tokens de saída: 52/870 = 5,98% — todos na origem "padrão do especialista"; na origem "fixada na conversa", 0%.
  • Conversas do braço com pelo menos um registro de erro: 14/355 = 3,94%.
  • Desagregado: 6,27% na origem "padrão do especialista" contra 0,0% na origem "fixada na conversa" — o braço não é homogêneo.

Semântica do identificador de conversa (auditoria):

  • Formatos: identificador curto em 19,4%; identificador de vida longa em 80,6%. Zero truncamento.
  • Conversas de um turno: 29,0% (curto) contra 95,5% (longo).
  • Turnos por conversa: no curto, mediana 3 (p90 entre ~21 e 30, máximo 59); no longo, mediana 1 (p90 1, máximo 30).

3.2 Resultados planejados (análise definitiva — pendente)​

  • Tabela 1 — descritiva por origem da decisão de modelo (preenchida na Seção 3.1).
  • Tabela 2 — custo por conversa com intervalo de confiança e p-valor (requer granularidade por conversa com bootstrap e agrupamento — pendente).
  • Tabela 3 — teste de não-inferioridade formal (Δ = 2 pp) — pendente.
  • Tabela 4 — sensibilidade baselines × premissas de custo unitário.
  • Tabela 5 — desfecho operacional (N2), desagregado por formato do identificador de conversa.

4. Discussão​

  • Validade externa (a conclusão mais importante desta versão): a janela não contém tráfego de cliente final — só a operação interna, com contexto gigante (~471k tokens por turno). A economia aparente (70,8% a 98,1%) não é generalizável para o uso real da plataforma. A hipótese permanece não confirmada em tráfego de cliente.
  • Mecanismo: a economia observada vem da diferença de custo unitário de entrada sobre contexto gigante, não do roteamento por dificuldade. É um fenômeno distinto da literatura de cascatas. Reconhecer isso evita overclaim.
  • Robustez metodológica: o desenho (contrafactual multi-baseline + gate de não-inferioridade validado contra o formato real da telemetria) é reutilizável, e revelou dois defeitos latentes que teriam invalidado o estudo: o gate N1 vazio e a semântica dupla do identificador de conversa.
  • Limitações: (i) janela única de 7 dias; (ii) uma única organização; (iii) baseline contrafactual (os tokens do modelo forte não são reais); (iv) qualidade restrita a N1/N2; (v) identificador de conversa com dois caminhos, sendo um reiniciado por inatividade — o que infla a taxa de conversas de um turno.
  • Trabalhos futuros: (a) re-executar em janela com tráfego real de múltiplas organizações; (b) separar a operação interna do tráfego de cliente como análise de sensibilidade; (c) baseline controlado ao vivo; (d) instrumentar fim de sessão; (e) métrica N3 (LLM-as-a-Judge).

Referências​

  1. T. Shnitzer et al., "Large Language Model Routing with Benchmark Datasets," arXiv:2309.15789, 2023.
  2. R. Zhuang et al., "EmbedLLM: Learning Compact Representations of Large Language Models," arXiv:2410.02223, 2024.
  3. W. Jitkrittum et al., "Universal Model Routing for Efficient LLM Inference," arXiv:2502.08773, 2025.
  4. D. Sikeridis, D. Ramdass, P. Pareek, "PickLLM: Context-Aware RL-Assisted Large Language Model Routing," Workshop SEAS, AAAI 2025, arXiv:2412.12170, 2024.
  5. K. Huang et al., "UniScale: Adaptive Unified Inference Scaling," ICML 2026, arXiv:2605.30898, 2026.
  6. S. Lee et al., "Confidence-Guided Stepwise Model Routing for Cost-Efficient Reasoning (STEER)," arXiv:2511.06190, 2025.
  7. W. Si, I. Lee, O. Bastani, "Policy-Guided Stepwise Model Routing for Cost-Effective Reasoning," arXiv:2605.06116, 2026.
  8. H. Zeng, B. Jing, "A note on conditional PAC-efficient reasoning in large language model routing," arXiv:2512.03057, 2025.
  9. I. Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data," arXiv:2406.18665, 2024.
  10. L. Chen, M. Zaharia, J. Zou, "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance," arXiv:2305.05176, 2023.
  11. M. Yue et al., "Large Language Model Cascades with Mixture of Thoughts Representations for Cost-efficient Reasoning," ICLR 2024, arXiv:2310.03094, 2023.
  12. L. Nie et al., "Online Cascade Learning for Efficient Inference over Streams," ICML 2024, arXiv:2402.04513, 2024.
  13. A. Valkanas et al., "C3PO: Optimized Large Language Model Cascades with Probabilistic Cost Constraints for Reasoning," arXiv:2511.07396, 2025.
  14. V. Kotte, "UCCI: Calibrated Uncertainty for Cost-Optimal LLM Cascade Routing," arXiv:2605.18796, 2026.
  15. S. Li, A. M. Abdelmoniem, S. Wang, "ProgRouter: Online Progress-Guided Orchestration for Multi-Agent LLM Workflows," Findings of EMNLP 2026, arXiv:2608.25992, 2026.
  16. S. Liu et al., "CASTER: Breaking the Cost-Performance Barrier in Multi-Agent Orchestration," arXiv:2601.19793, 2026.
  17. C. Zhang et al., "Confidence-Calibrated Small-Large Language Model Collaboration for Cost-Efficient Reasoning (COREA)," EACL 2026, arXiv:2603.03752, 2026.

Estado desta versão​

Feito: critério de não-inferioridade definido em 2 pontos percentuais; análise preliminar executada, com o caveat de validade declarado; proxy operacional validado; semântica do identificador de conversa auditada.

Em aberto: re-executar em janela com tráfego real de cliente e múltiplas organizações, para testar a hipótese de fato; captura de granularidade por conversa com bootstrap e agrupamento, para intervalo de confiança e p-valor formais; e separar a operação interna do tráfego de cliente como análise de sensibilidade.

Sobre este artigo​

Estudo conduzido na Lab019 sobre a própria plataforma. Esta é a versão pública do texto, e é a mesma que vai para o repositório aberto de preprints: o que a análise usa vem de métricas agregadas de operação, e nenhum dado de cliente, de organização ou de conversa individual é publicado aqui.

Veja também​