O primeiro artigo sobre o Qwen 3.6 27B rodando na RTX 4090 gerou uma enxurrada de comentários no LinkedIn. Muita curiosidade legítima e um bom nível de ceticismo saudável. Este post responde as seis perguntas mais importantes que apareceram por lá, com números que dá pra reproduzir e fontes públicas.

Antes de entrar nas respostas, uma coisa que o texto original não deixou clara o suficiente. Rodar o Qwen local não é mágica. Tudo que se ganha em custo, privacidade e independência da nuvem, se paga em latência de sessão e em tempo de operação. Na minha experiência real, resolver a mesma tarefa complexa localmente demora aproximadamente 3 a 5x mais que a mesma tarefa via Claude Sonnet 4.5. Só que o custo em tokens é zero. Pra alguns fluxos isso vale ouro, pra outros nem tanto.

Com isso dito, vamos aos comentários.

1. “Quantos tokens por segundo? Capacidade autônoma?” (D.O.)

Números medidos publicamente na RTX 4090 com llama.cpp e Qwen 3.6 27B:

Pra ter uma noção, uma resposta longa de uns 2 mil tokens leva de 15 a 40 segundos pra sair completa, dependendo da quantização escolhida.

Sobre autonomia: como qualquer LLM sem grounding externo, ele não é autônomo por si só. Quem dá autonomia é o agente que envolve o modelo (Aider, Qwen Code, Cline, OpenCode). Todos são open source e funcionam com Qwen local. Falo mais sobre eles na resposta 3.

2. “Benchmark sozinho não diz nada. O tooling open source que funciona decentemente é o difícil” (D.L.L.)

Esse comentário está totalmente correto, e provavelmente é o mais valioso da thread. Um modelo isolado no llama.cpp é praticamente inútil pra trabalho de verdade. É o ecossistema que separa “curiosidade” de “produção pessoal”.

A boa notícia é que o tooling open source estabilizou em 2026. Os quatro que funcionam sem gambiarra hoje:

• Qwen Code. CLI da Alibaba (Apache 2.0), otimizado pros modelos Qwen3-Coder. Espelha a interação do Claude Code e aponta pra qualquer endpoint compatível com OpenAI (Ollama local, Alibaba Cloud, etc.).
• Aider. Melhor opção quando disciplina Git e reversibilidade importam. Faz commits atômicos por edição.
• Continue.dev. Extensão VSCode/JetBrains com Config As Code, review rules e integração CI.
• OpenCode. Zero-cost drop-in do Claude Code, com o maior suporte a modelos.

Isso resolve completamente o problema? Não. A comparação honesta com Copilot GPT ou Claude Opus continua desfavorável em três frentes: reasoning multi-arquivo denso, refactor com muitos side effects e uso complexo de MCPs. Pra CRUD, testes unitários, documentação e refactors localizados, o gap virou marginal.

3. “Como manter a codebase em contexto? Qual IDE?” (L.G.P.)

Duas partes.

Na parte da IDE ou interface: o Qwen Code roda no terminal (é o meu preferido se você já usa Claude Code). O Continue.dev roda dentro do VSCode. O Aider roda no terminal com integração Git nativa. Todos aceitam apontar pra um endpoint OpenAI-compatible local. O llama-server do llama.cpp expõe exatamente isso em http://localhost:8080/v1.

Na parte do contexto da codebase, três coisas importam:

O Qwen 3.6 27B (base) tem 128k tokens de context window. O Qwen3-Coder-Next chega a 256k.

Aider e Cline gerenciam mapping automático de arquivos (repo-map), enviando só os arquivos relevantes pra cada turno em vez de despejar tudo dentro.

Pra codebases acima de 500k tokens, o caminho é RAG local, com Chroma ou LanceDB usando embeddings do próprio Qwen.

Na prática, pra um monorepo médio de 10 a 50k linhas, Aider com repo-map dá conta sem precisar de RAG.

4. “Pode me contar mais sobre o processo migratório pro Qwen?” (A.C.)

Vou contar como está sendo aqui, sem romantizar. Migração é uma palavra forte demais pro que rolou. O que aconteceu foi uma divisão de trabalho entre Claude e Qwen.

De onde eu vim: Claude Code no dia a dia, em 100% das tarefas técnicas. A fatura de API era o segundo maior custo da operação. Curiosidade sobre modelos abertos somada a uma RTX 4090 parada boa parte do tempo foi motivação suficiente pra tentar de verdade.

Sobre o setup: sim, subi o stack completo. llama.cpp compilado com CUDA, llama-server na porta 8080 expondo API OpenAI-compatible, e um agente rodando em cima (testei Aider e Qwen Code, os dois funcionaram sem gambiarra). Do primeiro git clone do llama.cpp até a primeira resposta funcional do Qwen num agente foi coisa de umas 2 ou 3 horas. A maior parte disso foi CUDA, drivers e escolha de quantização, não o modelo em si.

Onde estou hoje é um uso híbrido bem pragmático:

Qwen local pega 100% das tarefas simples e de dificuldade média-baixa. CRUD, testes unitários, geração de boilerplate, documentação, refactor localizado, scripts utilitários, “escreva essa função que faz X”. Nesse território o Qwen 3.6 27B em Q6_K entrega bem. A diferença de qualidade contra Claude Sonnet aqui virou marginal, e a economia de tokens é gigante.

Claude segue com as tarefas média-alta e tudo que precisa de contexto elevado. Refactor multi-arquivo, orquestração com MCPs, raciocínio denso sobre codebase, decisões arquiteturais. Aqui o Claude 4.5 ainda ganha com folga, e o custo da API paga a produtividade sem discussão.

Sobre as diferenças que senti na prática, quatro pontos aparecem toda semana:

Latência de sessão. Qwen local tem uma textura diferente. A resposta chega em stream mais lento e mais uniforme, enquanto o Claude tem picos rápidos seguidos de pausas. Você adapta o ritmo de trabalho.

Recuperação de erro. Claude entende quando errou e volta com correção de forma fluida. Qwen às vezes precisa de um empurrão explícito, do tipo “não, revise o output anterior”.

Prompt tool-heavy. Claude executa read → grep → edit → verify sem tropeçar. Com Qwen local no Aider, em cadeias longas de tool-use, é onde eu mais senti diferença de robustez.

Fluxo mental. Saber que o modelo tá rodando na minha máquina, sem cobrança por token nem log em servidor de terceiros, muda como eu prompt. Faço mais experimentação exploratória com Qwen, coisa que eu evitaria em prod com API paga.

O que economiza de verdade não é apenas dinheiro (embora seja bastante). É a liberdade de não pensar em tokens pra toda a camada média-baixa do dia. Isso desbloqueia um tipo de uso que era caro demais na API: prototipar em rascunho, testar 5 versões de uma função, gerar documentação exaustiva sem ficar contabilizando.

Ponto honesto pra fechar: isso funciona porque tenho uma RTX 4090 ociosa. Sem ela, o cálculo muda. Se você trabalha em máquina compartilhada ou GPU mais modesta, dá uma olhada na resposta 5 antes de investir tempo nesse caminho.

5. “Comparativo em GPUs mais acessíveis, como RTX 4060 e 4070?” (B.M.)

Bem lembrado. O artigo original focou na 4090 e deixou os leitores da faixa mainstream sem número. Dados públicos consolidados:

O ponto menos óbvio dessa tabela é que a RTX 4070 Super com um MoE (35B-A3B) supera a 4090 com modelo denso em throughput bruto. Isso acontece porque o MoE só ativa 3B parâmetros por token. A qualidade não é a mesma da 27B densa, mas é a melhor combinação de velocidade em hardware acessível hoje.

Pra 4060 8GB, o realista é rodar Qwen3-Coder 14B em Q4 com contexto reduzido (uns 16k), ou ficar em modelos 7B/8B pra tarefas mais simples.

6. “Lorota! Quantos tokens por segundo? Vai levar horas pra tarefa complexa” (V.Q.)

Esse é o comentário que exige mais rigor, então vou responder com fontes explícitas.

Sobre tokens por segundo, os números da resposta 1 são medidos e publicados. Não são estimativa nem hype. Você reproduz com o comando llama-bench -m modelo.gguf em qualquer RTX 4090 com CUDA 12+.

Sobre a parte de “horas pra tarefa complexa”, aqui a crítica não procede na forma colocada, mas procede parcialmente. Comparativos independentes (Composio, 2026) executaram a mesma tarefa (implementar um typing game funcional) nos dois modelos e mediram:

• Claude Sonnet 4.5: cerca de 3 minutos.
• Qwen3-Coder: significativamente mais lento que Sonnet, mas na ordem de 5 a 10 minutos, não horas.

Pra tarefas realmente complexas (multi-arquivo, refactor com side effects), Claude Opus 4.8 continua na frente com folga. Nenhum benchmark público sério mostra Qwen3-Coder demorando “horas” pra uma tarefa que Claude resolve em minutos. O que existe é aquele gap de 3 a 5x em latência de sessão que mencionei lá no início, mais o gap de qualidade em prompts tool-heavy (uso de MCPs, orquestração complexa), onde Claude 4.5 e o 4.8 continuam superiores.

Resumindo com números verificáveis:

Nenhum dos dois é melhor em absoluto. São fits diferentes pra necessidades diferentes.

O trade-off honesto

Rodar Qwen 3.6 27B local não substitui Claude na velocidade nem na qualidade das tarefas mais complexas. Ele substitui bem em outros cenários:

• Codebases sensíveis, com privacidade regulatória ou código proprietário estratégico.
• Uso pesado onde a fatura de API vira um ativo relevante do orçamento.
• Ambientes sem conectividade estável.
• Aprendizado profundo sobre como esses modelos funcionam por dentro.

Se você usa Claude Code 4 a 6 horas por dia e a produtividade paga a assinatura sem esforço, migrar pra Qwen local vai te custar 3 a 5x mais tempo de máquina. Só faz sentido se um dos pontos acima for verdadeiro pra você.

É esse tipo de pragmatismo que a thread cobrou, com razão.

Fontes

• Qwen3-Coder no GitHub oficial
• Qwen Code CLI
• Benchmarks reprodutíveis Qwen3.6-27B na RTX 4090 (outsourc-e/qwen36-4090-recipes)
• Composio: Qwen 3 Coder vs Claude 4 Sonnet coding comparison
• Artificial Analysis: Sonnet 4.5 vs Qwen3-Coder 30B
• 110 tok/s no RTX 4070 Super com Qwen 3.6 35B
• Qwen 3 GPU Requirements Guide 2026 (Will It Run AI)