Troquei Sonnet por Qwen 7B local em 3 tarefas: bill de US$ 47 virou R$ 0 (e 2 tarefas ficaram melhores)
Paguei US$ 47 em Claude Sonnet 4.5 num mês só rodando 3 fluxos de código que eu automatizei no meu harness. R$ 254 pelo dólar PTAX de agosto de 2026 (R$ 5,40). Não é dinheiro que quebra ninguém, mas é uma assinatura mensal a mais que virou reflexo.
Aí eu peguei um Qwen 2.5 7B Instruct rodando local via llama.cpp (Q4_K_M, ~5,5 GB de VRAM), passei as mesmas 3 tarefas com contexto enxuto, e olhei o resultado sem olhar o rótulo.
O modelo pequeno ganhou em 2 das 3 tarefas. A conta mensal virou zero. E não, o Sonnet não é ruim — a tarefa é que estava no modelo errado.
As 3 tarefas que eu rodava no Sonnet
Antes de qualquer coisa: eu não peguei benchmark público. Rodei o que eu de fato uso todo dia, e a maioria de dev também roda:
- Tarefa 1: escrever mensagem de commit a partir de
git diff— recebe o diff, devolve subject + body em português. Volume: ~15 commits/dia. - Tarefa 2: gerar teste unitário a partir de função existente — recebe uma função (em Python ou TypeScript), devolve teste com 2-3 casos incluindo edge case. Volume: ~4 testes/dia.
- Tarefa 3: revisar PR pequeno (até 200 linhas de diff) — recebe o diff, devolve 3-5 comentários priorizados (bug > estilo > sugestão). Volume: ~2 PRs/dia.
Uso mensal médio: ~500 chamadas, ~4M tokens input, ~1M tokens output. Preço Sonnet 4.5 na tabela oficial de 2026 (input US$ 3 / output US$ 15 por 1M tokens): US$ 12 input + US$ 15 output + overhead de context caching = US$ 47/mês real na fatura.
O setup do Qwen 7B local
Máquina: um mini-PC caseiro com RTX 4060 8 GB. Nada exótico.
- Modelo: Qwen 2.5 7B Instruct
- Quantization: Q4_K_M (~5,5 GB de VRAM, sobra folga para contexto)
- Runtime: llama.cpp (compilado com CUDA)
- Server:
llama-serverna porta 8080, endpoint OpenAI-compatible
Por que Q4_K_M e não Q5_K_M? Q5_K_M pesa ~6,5 GB e a diferença de qualidade em código, na minha comparação cega, foi menor que a diferença de latência. Q4_K_M ficou em ~55 tokens/s, Q5_K_M em ~42. Para uma tarefa que roda 500x no mês, isso importa.
Custo marginal: ~2 kWh/mês de energia extra do PC ligado nas horas que uso. R$ 1,80 na conta de luz. Praticamente zero.
O experimento cego
Rodei cada tarefa 20 vezes no Sonnet e 20 vezes no Qwen (mesmos inputs, mesma temperatura 0,3). Salvei 40 saídas por tarefa num CSV embaralhado sem o nome do modelo. Depois, dois dias depois, avaliei cada saída em 3 critérios (0-2 pontos cada):
- Correção: a saída faz o que devia fazer?
- Concisão: sem enrolação, sem
Ah, ótima pergunta!? - Formato: markdown / código do jeito que eu preciso?
Score máximo por saída: 6 pontos. Média por modelo por tarefa:
| Tarefa | Sonnet 4.5 | Qwen 7B Q4_K_M | Vencedor |
|---|---|---|---|
| Commit messages | 4,8 | 5,3 | Qwen |
| Testes unitários | 5,4 | 4,1 | Sonnet |
| Review de PR | 4,2 | 4,9 | Qwen |
Sonnet manteve vantagem só em testes unitários. Nas outras duas, o Qwen local com contexto certo bateu o modelo caro.
Por que o Qwen ganhou em commit messages
Meu prompt para commit é curto e concreto: “Dado esse diff, escreva subject + body em português. Subject ≤ 50 chars. Body explica o porquê.” Nada mais.
O Sonnet, provavelmente treinado com muito material corporativo, inventa razão de negócio quando não tem. “Refatora o método validateUser para melhorar a manutenibilidade” — mesmo quando o diff é s/isValid/isActive/g. É verboso e às vezes errado.
O Qwen 7B, sem tanto reforço de “seja explicativo”, produz commit mais parecido com o que eu escrevo à mão: “renomeia flag isValid para isActive (era ambíguo com o campo do banco)”. Curto, factual.
O contexto certo aqui é a tarefa ser pequena e ter uma forma óbvia. Qwen 7B sabe qual é a forma. Sonnet sabe demais e enfeita.
Por que o Qwen ganhou em review de PR
Similar. Meu prompt de review inclui 3 exemplos few-shot de PRs anteriores meus com o tipo de comentário que quero. Sonnet às vezes ignora o padrão dos exemplos e volta pra ## Suggestions com bullet longo. Qwen 7B copia o formato dos few-shots quase literalmente.
Isso é context engineering clássico: quando você dá exemplos concretos, um modelo pequeno segue instrução tão bem quanto um grande — às vezes melhor, porque não tem “opinião própria” para desviar. O meu experimento anterior comparando Haiku 4.5 e Qwen 4B contra Opus em 47 tarefas mostrou o mesmo padrão em escala maior.
Por que Sonnet ainda ganha em testes unitários
Aqui o Sonnet manteve a vantagem, e olhando saída por saída eu entendi por quê: o Qwen 7B gera testes que passam, mas cobrem só o caminho feliz. O Sonnet identifica edge cases que eu não tinha pensado — null vs empty string, boundary de índice, ordem de argumentos.
Ou seja: para tarefa onde a qualidade do output depende do modelo imaginar casos que o input não menciona, modelo grande ganha. Para tarefa onde a resposta certa está quase toda nos exemplos e no input, modelo pequeno com contexto certo ganha.
Como fica minha stack agora
Depois de 2 meses, minha divisão real:
- Commit messages → Qwen 7B local (100% do volume)
- Review de PR → Qwen 7B local (80% dos casos, fallback pro Sonnet quando o diff > 200 linhas)
- Testes unitários → Sonnet 4.5 (mantive, o custo é pequeno em relação ao valor)
Conta atual: US$ 4-6/mês em Sonnet só para testes. R$ 22 no dólar de hoje. Contra US$ 47 antes. 88% de corte, sem perder qualidade nas 2 tarefas onde o pequeno ganhou.
O que eu não recomendo
Não jogue tudo no local só porque é grátis. A migração dos testes unitários teria me dado ~US$ 40 de economia adicional e ~2 horas por semana debugando edge case que o Qwen não pegou. Conta ruim.
Não subestime a latência local. llama.cpp na 4060 dá ~55 tokens/s no Q4_K_M. Sonnet via API me dá ~120 tokens/s incluindo network. Para tarefa interativa (você esperando o output), Sonnet ganha em UX. Para tarefa em batch (commit hook rodando em background), local ganha.
Não use Q3 ou menor. Testei Q3_K_M rapidinho: qualidade caiu visível em commit messages (voltou a inventar razão). Q4_K_M é o piso prático em 2026.
Como eu decido caso a caso
Regra que virei prática, escrita em post-it na tela:
- Tarefa tem forma óbvia + exemplos few-shot bons? → Qwen 7B local ganha.
- Tarefa precisa de imaginação (edge case, refactor grande, código novo)? → Sonnet ganha.
- Volume alto (>100 chamadas/dia)? → Vale a pena montar local mesmo que perca um pouco de qualidade.
- Volume baixo (<10 chamadas/dia)? → Sonnet, o custo total vai ser menor que o tempo de setup.
E a maior lição de todo o experimento: modelo pequeno com contexto enxuto derrota modelo grande com contexto ruim. Não é sobre parâmetro. É sobre o que você põe no prompt.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Livro relacionado Transformando LLMs de Mentirosos em Especialistas Engenharia de Contexto na Prática | RAG · MCP · CLAUDE.md · Agentic RAG, com benchmarks de ponta a ponta Ver a página do livro → Este artigo foi útil?