Troquei o modelo local do OpenCode: o que acelerou e o que só parecia erro do modelo

Se você usa ChatGPT para programar, já conhece a cena. Você pede um filtro, um botão, um endpoint. Volta um código que parece certo. Às vezes está. Às vezes compila e está errado no detalhe que você não leu.

Eu faço a mesma coisa, só que o “cérebro” não está na nuvem. Está numa placa de vídeo nesta mesa, uma RTX 5090. O programa que dirige o modelo se chama OpenCode: ele lê arquivo, edita, roda teste. Um estagiário que não cansa e não manda o repositório para fora da casa.

O modelo que eu usava era o Qwen3.6, 27 bilhões de parâmetros. “27B” é o tamanho da cabeça. Quanto maior, em tese, mais ele sabe — e mais memória de vídeo ele come. Aí a Qwen soltou o 3.8. Mesma faixa, mesma licença livre (Apache 2.0), e agora enxerga imagem.

A pergunta que todo mundo faz, inclusive eu: ficou mais rápido? Acerta mais?

Vou te contar o que eu medi nesta mesa. E o dia em que eu achei que o modelo tinha piorado depois da troca — e era eu que tinha configurado errado.

Antes, o que é cada peça

Três nomes que vão aparecer o post inteiro, sem mistério.

OpenCode é o aplicativo. É ele que abre o projeto, chama ferramenta, escreve o git diff. Sem ele, o modelo só conversa.

Qwen é o modelo. 3.6 era o que eu tinha. 3.8 é o sucessor. Os dois cabem nesta placa. Os dois falam português o bastante para o meu dia a dia em .NET, JavaScript e Flutter.

Ollama é o motor que carrega o modelo na GPU e responde no localhost. O OpenCode fala com ele. Se o Ollama anuncia um contexto que a placa não entrega, o agente “fica burro” e a culpa parece ser do Qwen.

Local, aqui, quer dizer: o código não vai para a API da OpenAI nem da Anthropic. A placa trabalha, o disco é meu, o teste roda na pasta do repo.

Dois relógios, e as pessoas misturam os dois

Tem o relógio da placa. Quantos pedacinhos de texto o modelo escreve por segundo, o famoso tok/s. Eu meço isso com curl e nvidia-smi. É o número que o YouTube de hardware adora.

Tem o relógio da tarefa. Do “implementa o filtro” até o dotnet test — ou o vitest, ou o flutter test — passar. Esse relógio inclui o modelo descrever a edição em vez de editar, o raciocínio interno comer a resposta, o programa anunciar 262 mil tokens de memória e jogar as instruções fora no meio do arquivo. Aí eu abro outra sessão e perco dez minutos.

No 3.6 os dois já brigavam. Eu botei o OpenCode para fazer três tarefinhas de código (uma função de paridade, um cache LRU, um merge de intervalos). O Qwen3.6 em Q6 — Q6 é uma compressão do modelo, um pouco mais pesada e um pouco mais fiel — fez 3/3. Empatou o Haiku 4.5, que é um modelo pago da Anthropic, em acerto. O Haiku fechou em uns 24 segundos. O daqui, entre 56 e 103.

Mesmo acerto. Parede duas a quatro vezes maior.

Traduzindo: se a sua métrica é ganhar do ChatGPT no cronômetro, local nesta placa ainda perde. Se a métrica é o patch compilou, o teste passou, e o repositório não viajou para os Estados Unidos, o 3.6 já dava para trabalhar. O 3.8 entra em cima disso.

O que a placa realmente ganhou de velocidade

A arquitetura dos dois é a mesma. 64 andares no prédio, só 16 com aquele “caderno de rascunho” que cresce conforme a conversa anda — o KV cache. A conta do post do 3.6 não envelheceu.

O que mudou no pacote foi um projetor de visão (o modelo passou a olhar print de tela) e, na hora de escrever, mais velocidade.

Velocidade de escrever na 5090 · sem raciocínio interno · contexto curto

Modelo	Memória de vídeo	Escreve (tok/s)	Lê o pedido (tok/s)
Qwen3.6 27B Q4	16,95 GB	76,0	1372
Qwen3.8 27B Q4	18,25 GB	111,8	1141

Uns 100 a 110 tokens por segundo contra 76. Você sente isso no trecho em que o modelo está digitando o arquivo.

Você quase não sente no trecho em que ele lê o arquivo. Nessa bateria o 3.8 leu mais devagar: 1141 contra 1372. E um agente de código lê muito mais do que escreve. Ele abre o serviço, abre o teste, abre o componente, e só depois mexe três linhas.

Ou seja: comprar a troca só porque “escreve mais rápido” é olhar o relógio errado.

O outro número que eu medi, já no 3.8 comprimido em Q6 e com visão, foi o seguinte. Pedido mínimo: “usa a ferramenta”. O modelo devolveu um comando de verdade, não um parágrafo dizendo “vou editar o arquivo”. 14 segundos, 67 tokens. No 3.6 isso oscilava. Quando ele narra a ferramenta, o OpenCode não edita. A tarefa não fica lenta. Ela simplesmente não acontece.

O folheto da Qwen diz que ele acerta mais em código

Isso eu não rodei. São os números que a própria Qwen colocou no card do 3.8, comparando com o 3.6.

Pensa nesses nomes como provas padronizadas. SWE-bench é “consegue consertar bug de repositório de verdade?”. Terminal Bench é “consegue se virar no terminal?”. LiveCodeBench é “consegue passar em exercício de programação ao vivo?”.

Números da Qwen, não desta mesa

Prova	Qwen3.6 27B	Qwen3.8 27B
Terminal Bench 2.1	63,4	73,0
SWE-bench Pro	53,5	61,7
DeepSWE 1.1	13,3	42,2
LiveCodeBench v6	83,9	90,3

O salto que ela declara está em “usar ferramenta e mexer em projeto”, não em pergunta de ciência. Se você troca esperando o modelo gabaritar quiz, a tabela não promete isso. Se troca porque o 3.6 já era o 27B local de código, é exatamente o caso em que ela aponta o ganho.

Na minha mesa o 3.6 em Q6 já tinha empatado o Haiku nas três tarefinhas. A versão mais espremida, Q4, fez 1/3 no mesmo teste. A compressão mexeu mais naquele acerto do que a troca de família ia mexer numa função de paridade. Por isso eu fico no Q6 para dirigir ferramenta, e deixo o Q4 para conversa. Não voltei atrás.

Culpei o modelo. Era configuração.

Depois da troca o 3.8 “alucinava” e parava no meio da frase. Culpa clássica: o modelo novo é pior. Fui ler o log do servidor que o Ollama sobe por baixo.

Três defeitos. Nenhum era o peso.

Primeiro: a caixa diz 262 mil tokens de contexto. Contexto é a memória de curto prazo da conversa — o arquivo que ele leu, o teste que rodou, as instruções. 262 mil é o que o modelo aceita. Nesta placa, com o Q6, 262 mil empurra um pedaço do modelo para a memória RAM comum, fora da GPU. A leitura do pedido cai 29%. E tem um detalhe feio: o servidor tenta “deslizar” a memória quando ela enche, o híbrido não deixa, e o programa guarda só 4 tokens. As instruções vão embora. O modelo passa a responder pergunta que ninguém fez. Parece alucinação. É amnésia configurada.

O teto que cabe inteiro na GPU, do jeito que o Ollama está hoje, é uns 139 mil. Eu travei o OpenCode em 131 mil. 262 mil é o número da caixa. Não é o número desta 5090.

Segundo: o limite de resposta curto demais. O 3.8 pensa em voz alta antes de responder. Se você deixa só 512 tokens de teto, o pensamento come tudo e a resposta corta no primeiro item. Com 2048, os cinco itens saem. Medido nesta placa, mesmo pedido, só mudando o teto.

Terceiro: OpenCode passando por um intermediário. Eu tinha um programa no meio do caminho, o LiteLLM. O fluxo de texto vinha num formato que o OpenCode antigo rejeitava. O caminho que funciona aqui é o OpenCode falando direto com o Ollama, na porta 11434. O intermediário fica para wiki, chave de projeto e modelo na nuvem.

Quando o agente “ficou burro” depois da troca, na maior parte das vezes ele não ficou. Eu tinha deixado o motor mentir a memória.

Como isso aparece em .NET, JavaScript e Flutter

O jeito de pedir é o mesmo nos três. Abro o OpenCode na pasta do projeto. O modelo é o daqui. Ele pode editar e pode rodar comando. Eu não peço “escreve o sistema”. Peço a tarefa com o contrato à vista: o que entra, o que sai, o que o teste tem que quebrar.

No .NET, uma pasta de feature cabe nesses 131 mil tokens junto com o teste. As regras da casa — Result, ProblemDetails, sem exception para fluxo — estão no repositório, e o agente local lê. O ganho que eu sinto contra o 3.6 não é o dotnet build mais rápido. É o modelo chamar o ler-arquivo e o editar-arquivo, em vez de colar um trecho no chat. Quando ele narra, eu perco o turno inteiro. É como um estagiário que descreve a correção no Slack e não abre o Visual Studio.

No JavaScript eu tenho número de teste: as três tarefinhas do OpenCode no 3.6 Q6 passaram. No dia a dia é Next, um componente, um teste. O 3.8 com visão ajuda quando a tela está errada. O print entra na conversa, o arquivo do componente também. Antes eu descrevia o layout em prosa (“o botão ficou à esquerda, com um gap estranho”) e ele inventava um flex que não estava no pixel.

Flutter é a mesma lógica da tela. Print do emulador mais o widget. As regras da casa continuam sendo spec, não milagre do modelo. O 3.8 não me poupou de escrever o caso esquisito. Já medi isso: escrever o que acontece no caso estranho sobe o acerto de 46% para 90%. A tabela bonita em markdown, contra o mesmo texto corrido, quase não paga.

O tempo que eu ganhei, nos três, é menos retrabalho. Sessão que não morre no pensamento interno. Ferramenta que dispara. Memória que não descarta as instruções no meio do arquivo.

Escrever a 100 tokens por segundo é o bônus que aparece quando ele já está mexendo no arquivo certo.

O que eu faria no seu lugar

Se você já usa OpenCode com o 3.6 27B Q6 numa placa de 24 GB ou mais, eu trocaria. Custa cerca de 1,3 GB a mais na placa e um Ollama recente (0.32.12 para cima). A escrita sobe. O folheto da Qwen promete o ganho onde você usa — mexer em projeto, não gabaritar quiz. Trava o contexto no que a sua placa entrega. Aqui, 131 mil. E aponta o OpenCode direto no Ollama, sem intermediário.

Se a sua comparação é o Haiku na nuvem, prepara o relógio. O daqui continua mais lento por tarefa pequena e continua ganhando em dado que não viaja. São contas diferentes. Eu uso as duas. O 3.8 local ficou bom o bastante para o turno em que o repositório não pode sair daqui.

Se a placa tem 16 GB, o 3.8 não resolve o que o 3.6 já não resolvia. Continua o recado do post da memória de vídeo.

Eu não rodei SWE-bench nesta mesa. O que este post prova é a velocidade de escrever, o comando de ferramenta de verdade, o teto real de 131 mil tokens e o que quebra quando você acredita nos 262 mil da caixa. O resto é o que a Qwen publicou.

Número de fabricante é ponto de partida. Não é encerramento. Roda na sua placa e olha o teste passar — ou não.