MTP Mudou o Coding Local: Qwen 3.6 e Gemma 4 no Seu Notebook

Sexta-feira passada eu fiz uma coisa que já tinha tentado e abandonado três vezes: apontei meu agente de código para um modelo rodando na minha própria máquina e trabalhei um dia inteiro assim. As três tentativas anteriores morreram sempre no mesmo ponto, e nunca foi por qualidade de resposta. Foi por espera.

O detalhe que quase ninguém menciona ao comparar modelo local com API é que um agente de código não faz uma chamada longa. Ele faz dezenas de chamadas curtas em sequência: lê um arquivo, decide o próximo passo, chama uma tool, lê o resultado, decide de novo. Se o modelo produz 25 tokens por segundo, cada passo custa alguns segundos de silêncio — e um único ciclo de "corrige o teste que quebrou" empilha quinze desses passos. O modelo até acertava. Só que a sessão virava uma espera do tipo que faz você abrir outra aba e perder o fio.

Dessa vez foi diferente, e a diferença tem nome: Multi-Token Prediction. É uma mudança de arquitetura de inferência, não de qualidade do modelo, e por isso passou meio despercebida em quem lê só manchete de benchmark. Mas foi ela que moveu o modelo local da coluna "roda, mas é lento demais para um loop agentic" para a coluna "dá para trabalhar".

Este post é uma atualização direta do que escrevi em maio. Vou cobrir o que MTP é de fato e por que ele importa mais no workflow agentic do que no chat, o mapa de qual modelo cabe em qual faixa de hardware, o setup prático com runtime, quantização e contexto, o critério honesto de quando o local basta — e o que continua não funcionando bem localmente, porque continua tendo coisa nessa lista.

O Que Mudou Desde Maio

Quando publiquei o guia de rodar agentes de código no próprio hardware com o Qwen3-Coder, o argumento era basicamente de privacidade. Você aceitava um modelo pior em troca de o código não sair da sua infraestrutura, e o cálculo fechava para fintech, healthtech, contrato com NDA agressivo. Para todo o resto, a recomendação honesta era continuar na API.

Três meses depois, dois números mudaram esse cálculo. O primeiro é qualidade: o Qwen3.6-27B, lançado em abril sob Apache 2.0, marca 77,2 no SWE-bench Verified, 53,5 no SWE-bench Pro e 59,3 no Terminal-Bench 2.0, segundo os dados de release compilados pelo MarkTechPost a partir do blog da Qwen. Para comparação, na mesma compilação o Claude 4.5 Opus aparece com 80,9 no SWE-bench Verified e com os mesmos 59,3 no Terminal-Bench 2.0. É um modelo denso de 27B, cabendo numa RTX 3090, empatando com um modelo de fronteira num benchmark de agente de terminal.

O segundo número é velocidade, e é o que este post trata. MTP entregou entre 1,4x e 2,2x mais throughput em GGUF nos testes do Unsloth, e o Google reivindica até ~3x em configurações específicas do Gemma 4. Concretamente: o Qwen3.6 27B com MTP chega a 160 tokens por segundo e o Qwen3.6 35B-A3B a 240 tokens por segundo numa RTX 6000, de acordo com a documentação do Unsloth. Esses são números de hardware de estação de trabalho, não de notebook — mas o multiplicador se aplica igual na máquina menor.

Vale também uma correção. Em maio eu descrevi o Qwen3-Coder-Next como um denso de 3B rodando em ~6GB de VRAM; o levantamento da Kilo de julho coloca ele em outra faixa completamente, 48GB de VRAM ou um Mac de 64GB. Não sei se foi confusão de nomenclatura entre variantes ou leitura errada da fonte, mas o número que publiquei não se sustenta.

E uma segunda correção, mais sutil. Escrevi em maio que "para agentes de código, latência por token é menos crítica que custo total". Isso vale para batch, e só. Num loop interativo, onde você está olhando o agente trabalhar, latência por token é exatamente o gargalo — e foi essa premissa errada que me fez subestimar o quanto MTP ia importar.

O Que É MTP E Por Que Ele Importa No Loop Agentic

Multi-Token Prediction é, na prática, decodificação especulativa embutida na arquitetura do modelo. A documentação do Gemma 4 explica o mecanismo de forma direta: em vez de o modelo grande gerar um token por vez de forma autorregressiva, um "drafter" pequeno e rápido prevê vários tokens à frente, e o modelo alvo verifica todos eles em uma única passada. Se o alvo rejeita um token proposto, ele mesmo produz o token correto para aquela posição — nada se perde — e o drafter recomeça a partir dali.

O detalhe que faz isso funcionar bem é que o drafter do Gemma 4 não é um modelo independente. Ele compartilha a tabela de embeddings de entrada com o modelo alvo e é construído diretamente sobre as ativações da última camada dele. Ou seja: não é "carregar dois modelos na memória", que era a crítica clássica à decodificação especulativa em ambiente local. O Qwen foi por um caminho parecido e mais integrado ainda — treinou MTP dentro dos próprios modelos Qwen3.6 e Qwen3.5, com as cabeças de predição fazendo parte do checkpoint.

A garantia importante é que a saída é idêntica. Só tokens verificados pelo modelo alvo entram no resultado final. Não é quantização, não é destilação, não é aproximação: você não troca qualidade por velocidade aqui. O que você troca é memória — o Unsloth recomenda reservar cerca de 2GB extras de RAM ou VRAM para rodar com MTP ligado.

O gargalo que isso ataca é de largura de banda de memória, não de compute. Como os engenheiros do Google descrevem, durante a inferência o processador passa a maior parte do tempo movendo bilhões de parâmetros da VRAM para as unidades de cálculo, uma vez por token gerado, e o compute fica ocioso esperando dados. Pior: o modelo gasta o mesmo cálculo para prever o fechamento óbvio de um parêntese e para resolver um problema de lógica difícil. MTP usa esse compute ocioso para adivinhar os pedaços óbvios e confirmar vários de uma vez.

Isso explica por que MTP é uma tecnologia especificamente local-first. Um comentário no Hacker News que a InfoQ destacou na cobertura do lançamento resume bem: MTP é útil principalmente quando você tem um ou poucos usuários, ou seja, quando compute é abundante e a máquina está subutilizada. Num provedor de API servindo milhares de requisições simultâneas, o batching já ocupa o hardware e o ganho some. No seu notebook, com uma sessão só, é exatamente o cenário ideal.

E aí a conexão com o loop agentic fica óbvia. Código é um dos textos mais previsíveis que existem: imports, boilerplate, fechamento de blocos, assinaturas repetidas, chamadas de tool em JSON com formato fixo. O drafter acerta muito nesses trechos. Um agente que faz quinze chamadas curtas gerando 200 tokens cada não está pedindo criatividade — está pedindo estrutura. É a carga de trabalho onde MTP rende mais, e é por isso que o ganho percebido numa sessão de agente é maior que o número bruto de tokens por segundo sugere.

O Mapa Por Faixa De Hardware

Aqui está o problema de escrever sobre isso: os números de VRAM variam bastante entre fontes, porque cada uma mede uma coisa. Blog A mede só os pesos, blog B mede pesos mais KV cache num contexto específico, blog C mede memória total do sistema. A tabela abaixo usa as faixas de memória total publicadas pelo Unsloth para modelos com MTP — que contam RAM mais VRAM, ou memória unificada — cruzadas com as recomendações por placa do levantamento da Kilo.

A linha do Qwen3.5 9B é a única estimada, porque ela não aparece na tabela de requisitos do Unsloth; deduzi das faixas por placa da Kilo, que aponta uma RTX 5060 de 8GB com ~32K de contexto e uma 5060 Ti de 16GB com o contexto cheio de 262K. Trate como ordem de grandeza.

O Qwen 3.6 27B é o ponto de equilíbrio da lista, e é a recomendação que mais vejo repetida com convicção — tanto a Kilo quanto o KDnuggets chamam ele de melhor modelo local de código de 2026 para quem tem 24GB. A arquitetura é curiosa: 64 camadas com um padrão que repete três sublayers de Gated DeltaNet, uma forma de atenção linear, para cada sublayer de Gated Attention tradicional. Atenção linear escala em O(n) em vez de O(n²), e as camadas de atenção cheia usam 24 cabeças de query contra apenas 4 de key/value, o que derruba muito o custo de KV cache. É um modelo desenhado para contexto longo caber em pouca memória, com 262.144 tokens nativos e YaRN estendendo até cerca de 1,01 milhão. A equipe do Qwen recomenda manter pelo menos 128K para não degradar a capacidade de raciocínio.

O Gemma 4 26B A4B é a peça que mais me interessou conceitualmente. São 26B de parâmetros totais com apenas 4B ativos por token, via 128 especialistas de granularidade fina e roteamento top-8, segundo a recipe oficial do vLLM. A promessa é rodar na velocidade de um 4B puxando qualidade de um pool de 26B — verdade em throughput bruto, com um asterisco que vem da própria documentação do Google. Em MoE, cada token pode ativar especialistas diferentes, então verificar tokens rascunhados pode exigir carregar pesos adicionais da memória, o que come o ganho do drafting. Com batch maior há mais sobreposição de especialistas entre sequências e o reuso melhora; em batch size 1 — exatamente o seu caso rodando local — o Google diz explicitamente que o drafter do 26B A4B pode não entregar speedup em plataformas sem bom paralelismo. MTP ajuda menos no MoE local do que no denso local, o que inverte a intuição de quem, como eu, escreveu em abril sobre Gemma 4 e o cálculo de open source contra APIs fechadas tratando MoE como o caminho óbvio para eficiência.

O Gemma 4 12B é a escolha para 12–16GB, e o argumento a favor dele não é benchmark de código. É formato. A Kilo aponta que ele perde para Qwen de tamanho similar em coding, mas tem tool calling nativo e confiabilidade de formato de saída — o que, para agente, vale mais que dois pontos de HumanEval, porque um modelo que gera código bom e emite uma tool call malformada a cada dez chamadas quebra o loop. A atenção dele é intercalada — 40 camadas de janela deslizante com cache limitado a 1024 tokens e 8 camadas globais sem limite — o que mantém o contexto barato até perto da janela cheia.

Setup Prático: Runtime, Quantização E Contexto

O runtime é a primeira decisão, e ela mudou desde maio. Já escrevi um guia comparando SGLang, vLLM e Ollama como frameworks de inferência, e a lógica geral continua valendo — mas o suporte a MTP não está uniforme entre eles, e isso agora pesa mais que qualquer outro critério.

O llama.cpp é onde o suporte está mais maduro para uso local em GGUF, e é o que eu recomendo se você quer o caminho mais previsível. A flag central é --spec-type draft-mtp, combinada com --spec-draft-n-max para controlar quantos tokens o drafter propõe por passada.

# Build com CUDA (troque -DGGML_CUDA=ON por OFF em Mac/Metal ou CPU)
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first \
  --target llama-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

# Qwen 3.6 27B com MTP, servidor compatível com OpenAI API
export LLAMA_CACHE="unsloth/Qwen3.6-27B-MTP-GGUF"
./llama.cpp/llama-server \
    -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q4_K_XL \
    --temp 0.6 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.00 \
    --spec-type draft-mtp \
    --spec-draft-n-max 2 \
    --port 8000

# Gemma 4: o GGUF já traz o arquivo MTP embutido, o -hf resolve sozinho
./llama.cpp/llama-server \
    -hf unsloth/gemma-4-31B-it-GGUF \
    --spec-type draft-mtp \
    --spec-draft-n-max 4

Duas notas sobre esses comandos. A temperatura de 0.6 para o Qwen vem da recomendação da própria equipe para tarefas precisas de código — o padrão de 1.0 dos exemplos gerais é alto demais. E --spec-draft-n-max 2 é ponto de partida, não ótimo: o Unsloth é explícito em dizer que o valor ideal depende do hardware e que vale testar de 1 a 6.

No Ollama, o suporte chegou pelo runner MLX no Mac, com um PR específico para a família gemma4 que adiciona importação de draft models via safetensors e um comando DRAFT no Modelfile, com relatos de ganho acima de 2x no Gemma 4 31B em Apple Silicon. Encontrei números de versão inconsistentes entre fontes sobre quando o MTP virou estável ali, então não vou citar release — confira o changelog do seu build antes de assumir que está ligado. No vLLM, o caminho é --speculative-config apontando para o modelo assistant correspondente, com num_speculative_tokens: 4 recomendado para o 26B A4B; a ressalva da própria recipe é que, quando ela foi publicada, isso estava só na build nightly.

Sobre quantização, o padrão prático é Q4 para caber e Q6 quando o loop agentic começa a falhar. A Kilo faz uma observação que bate com o que senti na prática: em coding agentic de horizonte longo, a formatação de tool call pode degradar em Q4. Faz sentido, porque tool call é estrutura rígida e é a parte mais sensível a ruído de quantização. Se o seu agente resolve a lógica certa mas quebra o parsing das chamadas, subir de Q4 para Q6 resolve mais rápido que trocar de modelo.

E sobre contexto: o número da janela é marketing até você contar o KV cache. O caso extremo é o Devstral Small 2, que faz 68,0 no SWE-bench Verified e é totalmente denso — pesos de 15GB, mas cache de 40GB em 262K. Do outro lado, o Nemotron Cascade 2 30B-A3B usa atenção cheia em apenas 6 das 52 camadas e o cache custa 1,5GB no contexto completo. Mesma faixa de tamanho, duas realidades de memória. Configure --max-model-len pelo que você usa, não pelo que o model card anuncia.

O Critério Honesto: Quando O Local Basta

O critério que eu usava em maio era binário e baseado em compliance: se o código não pode sair, roda local; senão, usa API. Esse critério ficou pequeno, porque agora tem uma faixa grande de trabalho onde o local é bom o suficiente mesmo sem restrição jurídica nenhuma.

O corte que estou usando hoje é por natureza da tarefa, não por sensibilidade do dado. Trabalho onde o modelo executa um plano que você já tem — escrever os testes que faltam, aplicar um refactor mecânico em vinte arquivos, converter um módulo de callback para async, gerar migrations a partir de um schema, escrever a camada de serialização — roda muito bem local. É volume de token estruturado, é onde MTP rende mais, e é onde a diferença de raciocínio entre 77,2 e 80,9 no SWE-bench Verified simplesmente não aparece.

Trabalho onde o modelo precisa descobrir o plano continua sendo território de frontier. Bug que atravessa três serviços, decisão de arquitetura que depende de contexto implícito que não está em nenhum arquivo, refactor onde a pergunta certa é "isso deveria existir?" — ali a diferença de qualidade é visível e cara. E não é uma questão de benchmark: é que o modelo local erra de um jeito mais confiante e você gasta mais tempo revisando do que teria gasto fazendo.

O que mudou de verdade desde maio é a proporção entre essas duas caixas. Quando a segunda tarefa custava três segundos de espera por passo, você mandava tudo para a API porque o overhead de decidir não valia a pena. Com o loop local rodando em ritmo de conversa, roteamento por complexidade deixa de ser um exercício teórico e vira algo que você faz sem pensar: o agente local resolve o feijão com arroz, e você escala para a API quando trava. Esse padrão híbrido eu já tinha descrito em maio, mas ele era desconfortável na prática. Agora não é.

O argumento de custo também ficou mais forte por via indireta: uma GPU de 24GB é custo fixo com capacidade ociosa, e quando o throughput dobra a mesma placa atende mais trabalho por hora. O ponto de equilíbrio contra API chega antes.

Para quem chegou até aqui pensando "então eu quero um modelo que conheça o meu código", o passo seguinte não é escolher outro modelo da lista. É o caminho que discuti em destilar um modelo próprio de 8B e o custo real disso em produção, onde local deixa de ser "API mais barata" e vira ativo técnico do time. Só não comece por aí: rode o Qwen 3.6 27B com MTP por duas semanas antes de investir em treino.

O Que Ainda Não Funciona Bem Localmente

Confiabilidade de tool calling em sessão longa continua sendo o ponto fraco. Não é que o modelo não saiba chamar tool — os modelos de 2026 fazem isso bem. É que a taxa de erro de formato, mesmo baixa, se acumula: 2% de falha por chamada, em quarenta chamadas, vira uma sessão com quase certeza de pelo menos um tropeço. Modelo de fronteira tem essa taxa mais baixa, e num loop longo a diferença composta importa muito mais que a diferença por chamada.

Contexto efetivo continua sendo diferente de contexto anunciado. O Qwen 3.6 27B suporta 262K nativos e a própria equipe recomenda não descer de 128K para preservar o raciocínio — mas isso é um piso recomendado, não uma garantia de que a atenção em 200K seja tão boa quanto em 32K. Na prática, eu continuo montando contexto com curadoria e não jogando o repositório inteiro na janela.

Multimodal local para código ainda é promessa mais que ferramenta. O Gemma 4 26B A4B e o 31B são nativamente multimodais, com resolução de visão configurável por requisição, e a ideia de mandar um screenshot de bug de UI para o agente é excelente. Testei pouco e não vou afirmar que funciona bem: a capacidade existe, o custo em tokens de imagem é real, e o resto é conversa para outro post.

E tem o custo operacional, que continua sendo o item mais subestimado. Rodar isso bem exige alguém que entenda de quantização, KV cache, flags de speculative decoding, versão de runtime. As notas de rodapé deste post — MTP só em nightly no vLLM, versão de Ollama inconsistente entre fontes, --spec-draft-n-max dependente de hardware — não são detalhe. São o trabalho. Se o seu time não tem apetite para isso, a API paga continua sendo mais barata em custo total, mesmo custando mais em dólar.

Conclusão

O que MTP mudou não foi a qualidade do modelo local. Foi a viabilidade do loop. E é uma lição que eu venho aprendendo devagar: em sistema agentic, o que determina se a ferramenta é usável raramente é a métrica que aparece no gráfico do lançamento. É a latência acumulada, a taxa de erro de formato, o quanto o ciclo cabe na sua paciência. Benchmark de qualidade mede a caixa errada.

Se você tem 24GB de VRAM ou um Mac de 32GB e tentou modelo local antes de abril, vale tentar de novo. A instrução mínima é essa: baixe o Qwen 3.6 27B em Q4 com MTP ligado, aponte seu agente para o endpoint local, e trabalhe um dia inteiro assim antes de julgar. Não é a mesma experiência de três meses atrás, e não é por causa dos benchmarks.

O que eu ainda não sei é se essa faixa continua avançando ou se ela estabiliza aqui. A distância entre 77,2 e 80,9 no SWE-bench Verified é pequena o suficiente para não importar na maior parte do trabalho, mas ela existe, e existe justamente nas tarefas em que a gente mais precisa de ajuda. Minha aposta é que o próximo salto vem de arquitetura de contexto e de confiabilidade de tool use, não de mais parâmetros — mas é aposta, não previsão.

Fontes:

• How to Run MTP Models: Multi-Token Prediction Guide — Unsloth Documentation
• Speed-up Gemma 4 with Multi-Token Prediction — Google AI for Developers
• Gemma 4 Multi-Token Prediction Delivers up to ~3x Faster Token Generation — InfoQ
• Alibaba Qwen Team Releases Qwen3.6-27B — MarkTechPost
• The Best Local Coding Models for Any Setup — Kilo Blog
• Top 7 Coding Models You Can Run Locally in 2026 — KDnuggets
• Google/gemma-4-26B-A4B-it — vLLM Recipes