Aplicando a Arquitetura do Claude Code a Modelos Locais de 9B: Principais Descobertas e Otimizações

Configuração Experimental e Descoberta Principal

O desenvolvedor utilizou uma RTX 5070 Ti (16GB de VRAM) com qwen3.5:9b via Ollama (6.6GB) e o framework de agente local OpenClaw. Após 18 testes e 10 otimizações, a descoberta principal foi que o qwen3.5:9b possui tool_calls estruturados nativos, enquanto o qwen2.5-coder:14b e o qwen2.5:14b colocam JSON no campo de conteúdo em vez de tool_calls adequados, exigindo análise extra.

Comparação de Desempenho

Comparação de desempenho dos modelos:

• qwen3.5:9b: Estrutura de tool_calls nativa, cadeia de pensamento habilitada, 39 tok/s
• qwen2.5-coder:14b: Chamada de ferramentas quebrada (no campo de conteúdo), sem cadeia de pensamento, ~30 tok/s
• qwen2.5:14b: Chamada de ferramentas quebrada (no campo de conteúdo), sem cadeia de pensamento, ~35 tok/s

10 Otimizações da Arquitetura do Claude Code

• Prompt de sistema estruturado → +600% de qualidade na saída (teste A/B: 4 problemas encontrados vs 25+)
• MicroCompact (compressão de resultados de ferramentas) → 80-93% de compressão, 11KB reduzidos para 367 caracteres
• Corte forçado (transição explorar→produzir forçada) → Resolveu loops de exploração onde modelos de 9B ficam presos lendo arquivos sem produzir saída
• think=false → 8-10x eficiência de tokens, elimina contaminação de linguagem
• Carregamento adiado do ToolSearch → -60% de espaço no prompt (229 vs 568 tokens)
• Sistema de memória de quatro tipos (usuário/feedback/projeto/referência) → Respostas personalizadas
• Bifurcação do cache KV → Efeito mínimo em GPU única (1.1x), precisa de vLLM
• Disciplina de escrita rigorosa → Verificar antes de atualizar a memória, previne corrupção de memória
• Inicialização paralela → 9% mais rápido na inicialização a frio
• Rastreamento de quebra de cache → Ollama armazena prompts idênticos em cache (182ms→75ms)

Descoberta Principal: Autodisciplina como o Limite Real

A maior descoberta foi que o limite real para modelos de 9B não é a capacidade de raciocínio ou a precisão no uso de ferramentas, mas a autodisciplina — saber quando parar de explorar e começar a produzir saída. Sem o corte forçado, o modelo usou todos os 12 passos lendo arquivos e produziu 0 bytes de relatório. Com corte forçado: 5 passos de leitura + 1 passo de escrita = 6080 bytes de relatório estruturado.

O que o qwen3.5:9b Pode Realmente Fazer

• Ler scripts bash de 800 linhas e encontrar bugs reais (condições de corrida, operações não atômicas) — 2 min
• Projetar uma arquitetura de sistema de feedback de vendas — documento de 8.7KB em 2.5 min
• Construir um projeto completo (calculadora + testes + executar testes) — 28 segundos
• Execução autônoma de 10 passos: escrever raspador web → instalação pip falha → encontrar solução alternativa → tentar novamente → testes passam — zero intervenção humana
• Pipeline completo de mini-fábrica: pesquisar → escrever artigo → revisar → publicar em HTML — 2.5 min

Desempenho Completo do Motor

Todas as 10 otimizações foram empacotadas em um único motor Python (~280 linhas). Resultados da primeira execução:

• Inicialização: 527ms (memória paralela + aquecimento do modelo)
• Exploração: 5 passos de ferramentas com MicroCompact (88% de compressão)
• Produção: 1947 caracteres de relatório estruturado
• Total: 39.4s / custo zero de API

O que Não Funcionou

• Bifurcação do cache KV em GPU única (precisa de multi-GPU ou vLLM)
• Orçamento de passos no prompt do sistema (o modelo ignora meta-instruções sobre seu próprio comportamento)
• Série qwen2.5 para chamada de ferramentas (problemas de formato)

O desenvolvedor executou isso no WSL2 + Ubuntu 24.04 e está disposto a compartilhar mais detalhes ou o código do motor.