Qwen3.6-27B: desempenho de codificação em nível flagship em um modelo dense de 27 bilhões

 (qwen.ai)
7 pontos por GN⁺ 2026-04-23 | 4 comentários | Compartilhar no WhatsApp
  • Lançado como um modelo multimodal dense de 27 bilhões de parâmetros, com suporte conjunto a modos thinking e non-thinking e processamento de imagens e vídeos em um único checkpoint unificado
  • O desempenho em agentic coding supera o flagship open source da geração anterior, Qwen3.5-397B-A17B, nos principais benchmarks de codificação, e até ultrapassa modelos com até 15 vezes mais parâmetros no total
  • Registrou 77.2 no SWE-bench Verified, 53.5 no SWE-bench Pro, 59.3 no Terminal-Bench 2.0 e 48.2 no SkillsBench; também foram divulgadas métricas de raciocínio em texto e STEM como 87.8 no GPQA Diamond e 94.1 no AIME26
  • Com a adoção de uma arquitetura dense, elimina a complexidade de roteamento de MoE e simplifica o deployment, além de oferecer pesos abertos, API, uso imediato no Qwen Studio e suporte a integração com OpenClaw, Qwen Code e Claude Code
  • Mostra que um modelo dense bem treinado pode superar uma geração anterior muito maior em tarefas centrais para desenvolvedores, além de ampliar o foco da linha Qwen3.6 em agentic coding

Visão geral

  • Qwen3.6-27B foi lançado como um modelo multimodal dense de 27 bilhões de parâmetros, com suporte tanto a modo multimodal thinking quanto non-thinking
  • Em agentic coding, supera o flagship open source da geração anterior, Qwen3.5-397B-A17B, nos principais benchmarks de codificação
  • Ao adotar uma arquitetura dense sem a complexidade de roteamento do MoE, simplifica o deployment e entrega desempenho de codificação de ponta em uma escala prática e amplamente distribuível
  • Já está disponível para uso imediato no Qwen Studio, com pesos abertos para a comunidade e acesso via API
  • Entre as características centrais estão agentic coding em nível flagship, forte raciocínio textual e capacidades de raciocínio multimodal

Desempenho

  • O Qwen3.6-27B foi avaliado de forma abrangente contra modelos de referência dense e MoE, com grande avanço em benchmarks de agentic coding
  • É declarado que ele supera até modelos com 15 vezes mais parâmetros no total
  • Os itens de avaliação abrangem linguagem, conhecimento, STEM e raciocínio, visão-linguagem, compreensão de documentos, compreensão de vídeo e visual agent

  • Linguagem

    • Com apenas 27 bilhões de parâmetros, supera o Qwen3.5-397B-A17B em todos os principais benchmarks de codificação
      • SWE-bench Verified 77.2 vs 76.2
      • SWE-bench Pro 53.5 vs 50.9
      • Terminal-Bench 2.0 59.3 vs 52.5
      • SkillsBench 48.2 vs 30.0
    • Também fica bem à frente de outros modelos dense de porte semelhante
    • Em tarefas de raciocínio, registra 87.8 pontos no GPQA Diamond, um nível competitivo com modelos várias vezes maiores da própria empresa
    • A tabela detalhada inclui comparações entre Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B e Qwen3.6-27B
    • Principais números da categoria Coding Agent
      • SWE-bench Multilingual 71.3
      • QwenWebBench 1487
      • NL2Repo 36.2
      • Claw-Eval Avg 72.4
      • Claw-Eval Pass^3 60.6
      • QwenClawBench 53.4
    • Principais números da categoria Knowledge
      • MMLU-Pro 86.2
      • MMLU-Redux 93.5
      • SuperGPQA 66.0
      • C-Eval 91.4
    • Principais números da categoria STEM e raciocínio
      • HLE 24.0
      • LiveCodeBench v6 83.9
      • HMMT Feb 25 93.8
      • HMMT Nov 25 90.7
      • HMMT Feb 26 84.3
      • IMOAnswerBench 80.8
      • AIME26 94.1

  • Configuração das avaliações de linguagem

    • A SWE-Bench Series usa scaffold interno de agent, ferramentas bash e de edição de arquivos, com temp 1.0, top_p 0.95 e janela de contexto de 200K
      • Todos os modelos de referência foram avaliados em um benchmark refinado que corrige algumas tarefas problemáticas do conjunto público SWE-bench Pro
    • O Terminal-Bench 2.0 usa harness Harbor ou Terminus-2
      • timeout de 3 horas, 32 CPU, 48 GB de RAM
      • temp 1.0, top_p 0.95, top_k 20, max_tokens 80K, ctx 256K
      • média de 5 execuções
    • O SkillsBench avalia 78 tarefas com OpenCode
      • subset autocontido, excluindo tarefas dependentes de API
      • média de 5 execuções
    • As avaliações de outros modelos no NL2Repo usam Claude Code
      • temp 1.0, top_p 0.95, max_turns 900
    • O QwenClawBench é um benchmark do agente Claw baseado na distribuição de uso real dos usuários
      • temp 0.6, ctx 256K
    • O QwenWebBench é um benchmark interno de geração de código frontend
      • composição bilíngue em EN e CN
      • 7 categorias: Web Design, Web Apps, Games, SVG, Data Visualization, Animation e 3D
      • a avaliação usa auto-render e judge multimodal para verificar código e consistência visual
      • usa sistema de rating BT ou Elo
    • O AIME 26 usa integralmente o AIME 2026 I e II
      • é informado que a pontuação pode diferir das notas do Qwen 3.5

  • Visão-linguagem

    • O Qwen3.6-27B suporta modos de thinking e non-thinking em visão-linguagem em um único checkpoint unificado
    • Processa imagens e vídeos junto com texto
    • Dá suporte a raciocínio multimodal, compreensão de documentos e tarefas de visual question answering
    • A tabela comparativa usa Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B e Qwen3.6-27B como referência

    • STEM e puzzles

      • MMMU 82.9
      • MMMU-Pro 75.8
      • MathVista mini 87.4
      • DynaMath 85.6
      • VlmsAreBlind 97.0

    • VQA geral

      • RealWorldQA 84.1
      • MMStar 81.4
      • MMBench EN-DEV-v1.1 92.3
      • SimpleVQA 56.1

    • Compreensão de documentos

      • CharXiv RQ 78.4
      • CC-OCR 81.2
      • OCRBench 89.4

    • Inteligência espacial

      • ERQA 62.5
      • CountBench 97.8
      • RefCOCO avg 92.5
      • EmbSpatialBench 84.6
      • RefSpatialBench 70.0

    • Compreensão de vídeo

      • VideoMME(w sub.) 87.7
      • VideoMMMU 84.4
      • MLVU 86.6
      • MVBench 75.5

    • Visual Agent

      • V* 94.7
      • AndroidWorld 70.3

    • Observação

      • Os campos em branco (--) na tabela significam que ainda não há pontuação ou que não se aplica

Uso do Qwen3.6-27B

  • É informado que o suporte no Alibaba Cloud Model Studio será disponibilizado em breve
  • Os pesos abertos estão disponíveis no Hugging Face e no ModelScope, com possibilidade de self-hosting
  • Há acesso via API do Alibaba Cloud Model Studio e caminho para teste imediato no Qwen Studio
  • Também há suporte a integração com assistentes de codificação de terceiros como OpenClaw, Claude Code e Qwen Code
  • É mencionada a simplificação do workflow de desenvolvimento e suporte a uma context-aware coding experience

  • Uso via API

    • Esta release oferece suporte ao recurso preserve_thinking
    • Trata-se de uma função que preserva o conteúdo de thinking gerado em todos os turnos anteriores da conversa, recomendada para agentic task

  • Alibaba Cloud Model Studio

    • Suporte a chat completions e responses API compatíveis com o padrão OpenAI
    • Também há suporte a interface de API compatível com Anthropic
    • A documentação oficial fornece exemplos de variáveis de ambiente
      • DASHSCOPE_API_KEY
      • DASHSCOPE_BASE_URL
      • DASHSCOPE_MODEL
    • Também são mostrados exemplos de Base URL por região
    • No código de exemplo, o nome de modelo padrão é qwen3.6-27b
    • Em extra_body, inclui enable_thinking: True
      • preserve_thinking: True aparece em forma de comentário
    • Há exemplo de resposta em streaming separando a coleta de reasoning_content e answer content
    • Para mais informações, é indicado consultar o link da API doc

  • Coding & Agents

    • O Qwen3.6-27B tem capacidade de agentic coding e pode ser integrado de forma fluida com OpenClaw, Claude Code e Qwen Code

    • OpenClaw

      • OpenClaw é um agente open source de AI coding self-hosted, anteriormente chamado Moltbot ou Clawdbot
      • Conectado ao Model Studio, oferece uma experiência completa de agentic coding no terminal
      • O script inicial inclui Node.js 22+, execução do script de instalação, configuração de DASHSCOPE_API_KEY e execução de openclaw dashboard ou openclaw tui
      • No primeiro uso, é preciso editar ~/.openclaw/openclaw.json
        • É explicitamente indicado que não se deve sobrescrever o arquivo inteiro
        • Para preservar as configurações existentes, devem ser mesclados apenas os campos necessários
      • A configuração de exemplo inclui o provider modelstudio e o modelo qwen3.6-27b
        • api é openai-completions
        • reasoning é true
        • Os tipos de entrada são text, image
        • contextWindow é 131072
        • maxTokens é 16384
        • O modelo primary padrão é modelstudio/qwen3.6-27b

    • Qwen Code

      • Qwen Code é um agente open source para terminal, profundamente otimizado para a série Qwen
      • O script inicial inclui Node.js 20+, instalação de @qwen-code/qwen-code@latest e execução de qwen
      • Dentro da sessão, são mostrados exemplos de uso dos comandos /help e /auth
      • No primeiro uso, aparece um prompt de login, e é possível alternar o método de autenticação com /auth

    • Claude Code

      • As Qwen APIs também suportam o protocolo de API da Anthropic
      • É informado que podem ser usadas com ferramentas como Claude Code
      • O exemplo de configuração inclui as seguintes variáveis de ambiente
      • O comando de execução é claude

Encerramento

  • O Qwen3.6-27B demonstra que um modelo dense bem treinado pode superar uma geração anterior muito maior em tarefas importantes para desenvolvedores
  • Mesmo com 27 bilhões de parâmetros, supera o Qwen3.5-397B-A17B em todos os principais benchmarks de agentic coding
  • Sua estrutura simplifica deployment e operação, e a linha open source Qwen3.6 passa a cobrir uma gama mais ampla de configurações de modelos com a adição do Qwen3.6-27B

Leituras relacionadas

4 comentários

 
kaydash 2026-04-23

Teria que ser A3B pra pelo menos rodar um pouco localmente haha
 
kirinonakar 2026-04-23

Dizem que os benchmarks são bons, mas no uso real ainda não parece estar num nível utilizável como agente de programação.
 
b89kim 2026-04-26

Eu usei e não há grandes problemas para codificação agêntica. No entanto, como você disse, em uso real + programação geral ele inevitavelmente fica atrás de modelos com mais parâmetros. As configurações são diferentes da 3.5 e o modo preserve_thinking também foi adicionado, então vale ter isso em mente. Algo como a quantização 4bit de 27B não apresentou problemas para uso local.
 
GN⁺ 2026-04-23
Comentários no Hacker News
  • Para mim, como modelo local quantizado em 16,8 GB, o resultado do pelican foi realmente excelente. Resumi em https://simonwillison.net/2026/Apr/22/qwen36-27b/; rodei em um M5 Pro com 128 GB de RAM, mas a memória realmente necessária parecia ser algo em torno de 20 GB, então imagino que também rode tranquilamente em uma máquina com 32 GB. Na leitura, processou 20 tokens em 0,4 segundo, dando 54.32 tokens/s, e na geração produziu 4.444 tokens em 2 min 53 s, ou 25.57 tokens/s. Gostei mais deste resultado do que do pelican que fiz há alguns dias com Opus 4.7. https://simonwillison.net/2026/Apr/16/qwen-beats-opus/
    • Saiu bom demais, a ponto de me dar a sensação de que isso talvez estivesse nos dados de treinamento. Queria ver como a diferença aparece em outros testes também
    • Fico pensando, meio em tom de piada, se um dia os fornecedores de modelos vão começar a otimizar para o influente teste do pelican riding a bicycle do Simon
    • A gravata borboleta do Qwen Flamingo também ficou perfeita demais
    • Pelo que me lembro, quase nunca ouvi alguém usar a palavra excellent para o teste do pelican, mas desta vez parece merecido mesmo. Por um tempo a tendência foi para MoE, e agora é interessante ver um modelo dense voltar a chamar atenção. Também fico curioso se os modelos fechados vão seguir com linhas rápidas em MoE e linhas pro em dense
    • A esta altura, talvez os LLMs já tenham entendido que o quadro da bicicleta é basicamente um losango cortado ao meio → ◿◸. Só espero não estar estragando o teste ao dizer isso
  • Desde que o Gemma 4 saiu lá pela época da Easter, sinto que a diferença entre modelos de self hosting e o Claude diminuiu bastante. Claro, a diferença ainda é grande, mas os modelos locais de antes eram tão pouco competitivos que agora a situação melhorou muito. E, se o Qwen 3.6 estiver um degrau acima do Gemma 4, isso é bem empolgante. Ainda assim, modelos locais continuam às vezes se perdendo ou falhando de formas estranhas, então eu sempre mantenho o Opus por perto. Mesmo assim, toda vez que um modelo local realmente me ajuda, eu me sinto mais perto da ideia de que programar ainda deve ser livre. Livre no sentido de gratuito e também de liberdade. Meu setup é uma máquina Ubuntu separada com RTX 5090, e neste momento o Qwen 3.6 27B está usando 29 GB dos 32 GB de VRAM. Rodo o Ollama em uma instância rootless do podman e conecto o OpenCode ao editor como ACP Service; recomendo muito. ACP é Agent Client Protocol, e, para mim, é para essa direção que o mundo deveria ir. E também sou grato à equipe do Qwen por ter tornado o mundo um pouco melhor num mundo cheio de Sam Altman
    • Dos modelos que rodei localmente no meu M5 MBP, o Gemma4 foi o que mais pareceu com o Claude
    • Também simpatizo com esse ideal de free e local, mas no fim acho que o importante é concorrência sustentável. Só o fato de haver pressão para derrubar um custo mensal de 200 dólares para algo bem menor já me deixa satisfeito
    • Fico curioso sobre até que ponto um modelo 27B aguenta tarefas de programação de verdade. Até o Claude às vezes decepciona, então é difícil imaginar quão prático um 27B seria no uso real
    • Queria saber quantos tokens/s saem numa RTX 5090
  • Sempre que anunciam um modelo, eu queria que mostrassem junto em que consumer hardware ele roda agora, quanto custa e qual é o tok/s
    • Para rodar nativamente em 16-bit o modelo 27B que eles distribuíram, é preciso um hardware considerável. Você vai precisar de Mac ou sistema Strix Halo com 128 GB, várias GPUs de consumidor com bastante memória, ou uma placa workstation nível RTX 6000. Então acho que eles não divulgam muito agressivamente em quais hardwares de consumidor isso roda. O release original que produz aqueles resultados simplesmente não cabe bem em sistemas de consumidor comuns. A maioria das pessoas roda versões quantizadas com menos bits em vez do original. Só que quantização tem trade-offs claros, então é difícil esperar exatamente a mesma qualidade dos resultados divulgados. O Qwen3.5 27B anterior ainda ficava bem utilizável até Q5 ou Q4, dependendo de quanta perda de qualidade você aceita, e em sistemas de memória unificada precisava de 32 GB extras de RAM, então algo como um Mac de 64 GB costumava ser o ideal. Também dava para usar uma NVIDIA 5090 de 32 GB ou duas GPUs de 16 GB ou 24 GB, mas ficava mais lento por causa da distribuição. Eu teria cautela com alegações de que roda em iPhone ou em sistemas menores. Até pode ser possível fazer executar com quantização extrema e várias gambiarras, mas muitas vezes a qualidade da saída não serve para uso real. De vez em quando aparecem repositórios para se exibir nas redes sociais dizendo que rodaram em hardware minúsculo, mas frequentemente o resultado na prática não é bom
    • No meu M4 com 32 GB de RAM, eu consegui algo como ~5 tokens/s. Rodei unsloth/Qwen3.6-27B-GGUF:Q4_K_M com llama-server, e o modelo 35B-A3B ficou em cerca de 25 t/s. Para comparar, num A100 foram algo como 41 t/s e 97 t/s, respectivamente. Ainda não testei o 27B por muito tempo, mas o 35B-A3B frequentemente saía dos trilhos quando o contexto passava de 15k~20k tokens. Dá para usar em tarefas básicas com estabilidade, mas eu não diria que isso está no nível de modelos frontier
    • As combinações de CPU/GPU para rodar LLM local são praticamente infinitas, então em geral a pessoa escolhe um sistema de acordo com orçamento e objetivo, depois estima mais ou menos o uso de VRAM olhando o tamanho do modelo e a quantização. Se precisar de uma análise mais detalhada, dá para usar calculadoras online de VRAM, por exemplo https://smcleod.net/vram-estimator/. Se você tiver conta no Hugging Face, também pode informar sua configuração e ver por cores a chance de cada quant servir. E o t/s também depende demais de variáveis, inclusive do tamanho do contexto, então no máximo dá para fazer estimativas. No momento, LLM local é literalmente um mundo de trade-offs em todos os pontos, e você fica escolhendo o tempo todo o que otimizar para cada tarefa
    • O Qwen3.5-27B roda tranquilamente numa placa de 24 GB em 4bit quant. Eu estou atendendo 10 desenvolvedores com duas Nvidia L4 e alguns flags do vllm, entregando 20~25 tok/s, e quando está vazio chega a uns 40 tok/s. Os desenvolvedores estão satisfeitos com esse desempenho, mas já pediram mais GPUs para aumentar a vazão
    • Na minha RTX 4090D eu consigo cerca de 30 t/s, usando 42 GB de VRAM de um total de 48 GB. A quantização é UD-Q6_K_XL, e há uma discussão sobre isso em https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7
  • Lugares como Qwen ou Minimax estão lançando modelos open source com resultados de benchmark parecidos, ainda que um pouco abaixo, dos da OpenAI ou Anthropic, então fico me perguntando qual é exatamente a vantagem competitiva que OpenAI ou Anthropic têm agora. Ainda por cima, o preço por token desses modelos abertos é só uma fração do Anthropic Opus 4.6. https://artificialanalysis.ai/models/#pricing
    • Em coding, os últimos poucos por cento de diferença de qualidade importam o bastante para justificar pagar um prêmio. É diferente de gerar spam em massa ou comentários no HN. Acho que é a mesma lógica pela qual existe tanta diferença de remuneração entre um engenheiro mediano e um engenheiro P99. E o fato de empresas frontier continuarem competitivas apesar do custo alto de P&D, neste momento, pode até ser bom no longo prazo, porque as força a criar produtos melhores e mais valor agregado. Especialmente a Anthropic parece querer ocupar a posição de fornecedor mais confiável. Até a Ali hospeda modelos frontier pagos, mas, se você não for uma empresa chinesa, será mesmo que colocaria workloads de desenvolvimento de código de produção num provedor hospedado na China? O OpenAI também causa alguma desconfiança, mas ainda parece menos provável que copie todos os seus segredos comerciais. Na Anthropic confio um pouco mais do que nisso. Acho que é daí que vem o prêmio. Há precedentes históricos fortes demais de empresas chinesas de hospedagem poderem usar toda vantagem competitiva disponível e compartilhar com o governo ou com outras empresas, então as pessoas precificam esse risco
    • Eu uso tanto Opus quanto Qwen, e na prática a diferença entre os dois parece muito maior do que os gráficos de benchmark sugerem. Se for comparar com modelos hospedados, acho que hoje faz mais sentido olhar para a GLM. É a que parece mais próxima dos grandes players; antes vendia muito barato, mas recentemente começou a subir os preços
    • Se esses resultados forem por causa de vampire attacks, talvez eles deixem de parecer tão bons quando os modelos fechados aprenderem a contaminar os caminhos por onde as respostas são sugadas. E, no uso em fluxos de trabalho cotidianos, eles ainda não são tão equivalentes assim. Em raciocínio raso podem até ir bem, mas em coding e tarefas mais difíceis a diferença continua grande. Pelo menos entre os modelos abertos que usei, ainda não encontrei nenhum tão bom quanto os fechados. Se alguém tiver uma boa configuração, eu adoraria receber
    • Neste momento, eu diria que não há vantagem competitiva. Mas, quando algum ecossistema começar a se integrar de verdade, aí sim acho que essa vantagem aparece
    • O preço por token alto do Opus é quase uma prova de que as pessoas estão dispostas a pagar por um modelo realmente melhor. Os novos modelos da OpenAI e da Anthropic são visivelmente melhores do que open source; open source não é inútil, mas frontier é claramente superior e provavelmente continuará sendo por um tempo. Se o tempo de um SWE vale mais de 1 dólar por minuto, então gastar 10 dólares numa conversa já compensa se isso economizar 10 minutos. Em trabalho com código, especialmente, melhorias sutis de qualidade podem se traduzir em bastante tempo poupado
  • Estou usando Qwen 3.6 35B e Gemma 4 26B num M4 MBP e, embora não estejam no nível do Opus, eles já fazem 95% do que eu preciso, e o fato de tudo isso rodar totalmente local já é impressionante por si só
    • Fico curioso sobre que tipo de tarefas você faz e como conecta o Qwen ou o Gemma, em termos de harness ou abordagem. Em outras palavras, queria entender como é seu fluxo de trabalho e sua stack de software
    • Agora já está útil o bastante para que eu passe a delegar mais tarefas para esses modelos locais, assim como o Codex vai reduzindo o próprio trabalho. E no meu M4 a versão 122B tem uma taxa de processamento muito melhor do que o dense 27B, então estou bem animado com ela também
    • Você usa isso com Ollama ou com outra coisa?
    • Queria entender melhor o que significa esse 95%. Tenho duas perguntas. Primeiro, isso quer dizer algo como 95% da precisão do Opus 4.5 ou 4.6 em termos de qualidade de saída? Segundo, em chamadas de ferramentas ou tarefas agentic, como por exemplo planejar uma viagem, isso quer dizer 95% do desempenho do Opus?
  • Ainda não estou acostumado com inferência local, então ontem passei um tempo configurando e testando alguns modelos Qwen3.6-35B-A3B. Acho que eram mlx 4b e 8b, gguf Q4_K_M e Q4_K_XL. No meu M4 de 64 GB, o desempenho foi bastante impressionante. Mas, olhando a tabela da TFA, este novo modelo parece um pouco mais inteligente, embora consuma mais VRAM; então fiquei curioso se a principal diferença é justamente ele ser dense. E, como 27B é menor que 35B, também fico na expectativa de surgirem logo modelos quantizados com exigência menor de VRAM
    • A questão principal não é só comparar quantidade de parâmetros. O 35B-A3B é um modelo Mixture of Experts, então em cada passo só uns 3B de parâmetros ficam ativos. Por isso, a demanda real de computação escala muito mais perto desses 3B do que dos 35B. Claro que ainda é necessário acesso de alta largura de banda a todas as camadas do conjunto de 35B. Já este modelo novo é dense, então no Mac ele provavelmente vai ser bem mais lento. Por exemplo, no meu M4 Pro ele fazia cerca de 9 tok/s em Q6 gguf, enquanto o 35-A3B fazia uns 70 tok/s com Q4 em mlx — não é uma comparação totalmente justa, mas dá uma ideia. Em geral, modelos dense como este rodam melhor em GPU dedicada, e, se você tiver VRAM suficiente para manter o modelo inteiro residente, a decisão fica fácil. Acho que este modelo pede algo em torno de 24 GB de VRAM ou mais, então uma NVIDIA 3090, 4090 ou 5090 deve servir bem
  • Rodando no llama server com Q4_K_M, em 24 GB dá para ter algo como 91k context, e, fazendo as contas, o KV-Cache fica em algo perto de 70 MB por 1K de contexto. Se fosse Q5, provavelmente ainda sobraria espaço para algo como 30K tokens, o que me parece bem impressionante
  • Eu tentei gerar um pelican andando de bicicleta em SVG, e o resultado foi https://codepen.io/chdskndyq11546/pen/yyaWGJx. Também tentei um dragão comendo hot dog enquanto dirige um carro, e o resultado foi https://codepen.io/chdskndyq11546/pen/xbENmgK. Não ficou perfeito, mas só de olhar esses resultados já dá para ver como os modelos ficaram poderosos
    • A imagem do dragão tem problemas como olho único ou cauda estranha, mas a do pelican ficou quase perfeita, a ponto de eu achar que é a melhor que já vi
    • Isso já virou um benchmark famoso demais, então fico me perguntando se os modelos não estão sendo treinados especificamente para esse teste
  • Pela minha experiência até agora com inferência local, ainda não fiquei muito impressionado. No M5 Pro com 128 GB de RAM, com o omlx eu tive algo como 11 tokens/s e, no fim, levei uma hora para escrever algumas centenas de linhas de código que nem funcionavam. Opus e Sonnet fizeram a mesma tarefa com sucesso em poucos minutos no CC. O modelo 3.6 35b que rodei ontem no Ollama pareceu razoavelmente bom. Pretendo testar outros harnesses além do Claude Code, mas, no momento, minha sensação é que os modelos locais ainda são lentos demais
    • Como este é um dense model, é natural que fique lento no Mac. Se você estiver no Mac, vale mais a pena experimentar o release Mixture of Experts do Qwen3.6, o Qwen3.6-35B-A3B. No meu M4 Pro ele chegou a uns 70 tok/s. Se você estiver vendo algo muito mais lento do que isso, talvez tenha usado GGUF sem querer. No Mac, o formato MLX, voltado para Apple, costuma ser mais rápido
    • No meu MacBook M2 Max, com a versão MLX em quantização 8-bit, eu vi velocidade de geração de 7 tokens/sec
    • Tive a impressão de que o OpenCode aproveita melhor modelos locais do que o Claude
  • Fico curioso para saber o que dá para rodar num M4 Pro com 48 GB de RAM