12
kenimo49
5 min de leitura ·

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-server na 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:

TarefaSonnet 4.5Qwen 7B Q4_K_MVencedor
Commit messages4,85,3Qwen
Testes unitários5,44,1Sonnet
Review de PR4,24,9Qwen

Sonnet manteve vantagem só em testes unitários. Nas outras duas, o Qwen local com contexto certo bateu o modelo caro.

Comparação de scores: Sonnet 4.5 vs Qwen 7B Q4_K_M nas 3 tarefas

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

Carregando publicação patrocinada...
4

Os modelos menores estao melhorando muito. As empresas estão cada vez mais conseguindo condensar a inteligência.

Entretanto, acredito que existe um limite de usabilidade. De fato, para escrita de commits um modelo de 7B de parâmetros funciona muito bem. Llms são muito boas em resumir texto. O problema com modelos pequenos é que não são bons em generalizar tarefas e não tem grande quantidade de informação "salva" em seus pesos; sendo assim, não são adequados para uso agentico, ou planejamento de tarefas, na minha opinião.

De toda forma, acredito que o futuro seja esse mesmo: delegar tarefas específicas para modelos menores em ambiente local. Boa parte do código que desenvolvo hoje em dia vem do GLM 5.3 Flash. Um modelo de 300B de parâmetros, que, independente da crise do hardware, já pode, em teoria, ser rodado em hardware de consumidor (novos Mac Studio).

1

Isso bate com o que eu vi na prática: a única tarefa em que o Qwen perdeu foi justamente a que exige generalizar além do input, os edge cases de teste unitário.

Só mudaria um pouco o eixo. No meu teste cego o que separou os dois não foi o tamanho do modelo, e sim se a resposta certa já estava no input e nos few-shots. Quando estava, o 7B só copiava o formato dos exemplos, enquanto o Sonnet melhorava o que eu não tinha pedido para melhorar. Generalizar bem e obedecer bem puxam para lados opostos.

Sobre uso agêntico eu concordo contigo: nem cheguei a tentar, e meu fallback pro Sonnet já dispara quando o diff passa de 200 linhas, que é mais ou menos onde o 7B começa a inventar.

Esse "em teoria" do Mac Studio é o que mais me interessa. É exatamente onde o meu teste apanhou: a distância entre rodar e rodar rápido o suficiente para compensar o setup. Com os meus 8 GB de VRAM eu nem sonho com 300B. Se você já viu alguém medir tokens/s do GLM 5.3 Flash nessa máquina, manda aí. Valeu pelo

1

Então, esse "em teoria" é justamente por não haver benchmarks. Os Macs com M5 ultra, se não me engano, só vão começar a ser enviados no final do mês.

A questão de rodar rápido suficiente é bem interessante mesmo. A quantidade de VRAM é importante, mas no fim das contas a largura de banda é um dos principais fatores que determinam a velocidade da inferência - a performance bruta da GPU é importante, mas a memória pode se tornar um gargalo. É por isso que não é viável carregar um modelo direto do SSD, por exemplo - é possível, mas muito lento.

O novo M5 Ultra deve entregar ~1200 GB/s de largura de banda. Para efeito de comparação, o anterior M5 Max entrega ~600 GB/s; A RTX 4060,~270 GB/s; e a RTX 5090, ~1800 GB/s. Sim, a 5090, a grosso modo, é a placa de consumidor que vai entregar o melhor desempenho de inferência, mas tem a limitação dos seus 32GB de VRAM, enquanto um Mac Studio, com a memória unificada, pode chegar a 512GB.

Um projeto interessante é o ds4, uma engine de inferência focada no Deepseek-v4-Flash e otimizada para os dispositivos da Apple. Atualmente, o projeto também dá suporte a outros modelos e hardwares. Os benchmarks do projeto reportam algo na casa de ~30 tokens/s no M5 Max.

Dado isso, acredito, sim, que os novos chips, junto de tecnologias como o speculative decoding (MTP, Dspark, etc), que podem em determinadas situações quase dobrar a geração de tokens, conseguirão um bom desempenho no modelo citado.