Qwen3.6-27B como Camada de Raciocínio Local: Resultados do Teste Multi-Agente de 2 Semanas

Um desenvolvedor substituiu o Claude pelo Qwen3.6-27B em um orquestrador multiagente por duas semanas, executando inteiramente em uma única RTX 3090. O objetivo era direto: testar se um modelo local poderia servir como camada de raciocínio — loop líder/gerente/subagente — em fluxos de trabalho de codificação reais. Os resultados oferecem números concretos para quem considera reduzir custos de nuvem.

Configuração e Linha de Base

• Hardware: RTX 3090, 24 GB de VRAM
• Modelo: Qwen3.6-27B com quantização Q6_K (~22 GB na GPU), contexto efetivo de 32k
• Motor de inferência: Ollama
• Orquestrador: Sistema multiagente com planos JSON estruturados, modal de aprovação de plano e etapa de revisão automática após conclusão do subagente
• Carga de trabalho: 47 fluxos de trabalho de codificação em várias etapas em dois repositórios reais

O Que Funcionou (A Camada de Raciocínio)

Geração de planos. O Qwen3.6 gerou planos de várias etapas aproximadamente tão bem quanto o Claude nessas tarefas. Ligeiramente mais conservador — menos sugestões de refatoração não solicitadas — mas coerente e com esquema válido ~95% do tempo após ajustes no prompt. Os 5% restantes foram corrigíveis com um único novo prompt.

Extração de memória. A extração de fatos no estilo Mem0 a cada 6 turnos funcionou bem. O Qwen extraiu os mesmos fatos que o Claude (por exemplo, "o usuário prefere sem comentários, a menos que expliquem um 'porquê'") e os armazenou de forma limpa no Qdrant.

Revisão automática da saída do subagente. Uma segunda instância do Qwen revisando o código da primeira detectou ~60% dos bugs que a revisão do Claude detectou no mesmo conjunto. Menos agressivo, ainda útil e gratuito.

Onde Quebrou

Confiabilidade de chamada de ferramenta. A saída JSON de chamada de ferramenta do Qwen3.6 teve uma taxa de erro de formato de ~12% em 47 tarefas. O Claude teve ~0,5% na mesma carga de trabalho. Os erros não eram JSON malformados — eram nomes de campos errados, tipos errados, assinaturas de ferramenta alucinadas. Usar Outlines ou modo de saída estrita reduziu os erros, mas não os eliminou.

Deriva de contexto longo. Após ~14 mil tokens de contexto de sessão acumulado, o Qwen começou a lembrar mal das decisões (por exemplo, "você disse para usar Postgres" quando o contrário foi dito). O limite prático efetivo é de ~12 mil tokens, depois é necessário um resumo agressivo e reinício.

Tratamento de falhas em cascata. Quando um subagente falhava, o planejador do Claude geralmente percebia e replanejava. O Qwen às vezes gerava etapas subsequentes assumindo que o subagente teve sucesso. Três alucinações em cascata em 47 execuções — não catastrófico com controle de plano, mas seria sem ele.

Implicações Práticas

A opinião do desenvolvedor: "O Qwen3.6-27B é uma camada de raciocínio viável para sistemas multiagente locais hoje. NÃO é uma camada de execução viável." Se você está construindo agentes exclusivamente locais, precisa de:

1. Imposição de saída estruturada no limite da chamada de ferramenta (Outlines, lm-format-enforcer ou modo de gramática do seu motor de inferência)
2. Controle de aprovação de plano para que os 12% de erros de formato nunca cheguem à escrita real de arquivos
3. Lógica de replanejamento em caso de falha — o modelo em si não pode ser confiado para lidar com falhas em cascata

A diferença de 12% nos erros de chamada de ferramenta é a métrica a ser observada. Quando o Qwen3.6 ou o próximo modelo local atingir ~2% nessa métrica, o caso para raciocínio em nuvem em loops de agente enfraquece consideravelmente.