Qwen 3.8 27B tem a mesma arquitetura do 3.6, linha por linha: 100% do ganho veio do treino

A Alibaba lançou um modelo novo e o diff de arquitetura veio zerado

A Qwen soltou os pesos do Qwen 3.8 27B em 14/08/2026, às 15:00 UTC — meia-noite do dia 15 no Japão. Apache 2.0, denso, vision-language nativo. Ritual de sempre: tabela de benchmark, salto grande, gente correndo pro Ollama.

Aí alguém fez a coisa mais chata e mais útil possível: abriu o config do 3.6 e o do 3.8 lado a lado.

Não mudou nada. Nem uma camada, nem um head, nem um dim. O grafo do modelo de agosto é o mesmo de abril, e o salto de benchmark é gigante. Este post é sobre o que isso prova — e sobre o que não prova.

TL;DR

• O que é: denso de 27,78 bilhões de parâmetros, vision-language nativo, contexto 262K, Apache 2.0.
• O achado: o diff de arquitetura contra o 3.6 27B tem um único campo diferente, e é metadado (transformers_version). 59 de 59 nós do grafo mapeiam um pra um.
• O que significa: o ganho não veio de arquitetura. Veio de treino, pós-treino e otimização — nenhum dos três divulgado.
• Onde dói: KV cache de ~64KB/token, xhigh como raciocínio default, e o template Jinja oficial quebrando tool call OpenAI.
• Custo/acesso: pesos abertos no Hugging Face; via API, US$ 0,45 input / US$ 3,20 output por 1M no OpenRouter.
• Não confunda: o Qwen 3.8 27B é o denso de pesos abertos que roda na sua máquina. O Qwen 3.8 Max é outro modelo, o MoE de 2,4T parâmetros com ~95B ativos, servido por API. Dois lançamentos, duas decisões diferentes.

O diff que provou: mesma arquitetura do 3.6 (e do 3.5)

O comparativo está público no hfviewer, e a frase dele é seca: "59 of 59 source-faithful nodes map one-to-one; no nodes, edges, repeat counts, or graph-visible dimensions changed."

Na prática, os dois configs dizem a mesma coisa:

// Qwen3.6-27B (abril/2026) e Qwen3.8-27B (agosto/2026)
"architectures":            ["Qwen3_5ForConditionalGeneration"],
"hidden_size":              5120,
"num_hidden_layers":        64,
"intermediate_size":        17408,
"vocab_size":               248320,
"max_position_embeddings":  262144
// padrão híbrido: 16 × [3 × (Gated DeltaNet → FFN) + 1 × (Gated Attention → FFN)]
// 24 heads Q / 4 KV @ dim 256 · 48 heads V / 16 QK @ dim 128
//
// único campo com valor diferente entre os dois: "transformers_version"

Repara no nome da classe: Qwen3_5ForConditionalGeneration. Não é typo. É o bloco da geração 3.5 ainda declarado no arquivo do 3.8. Três releases, um desenho.

Agora a parte que o hype ignorou, escrita na mesma página do achado: "This is an architecture result, not a claim that the checkpoints are identical. Training data, optimization, learned weights, post-training and behavior can change substantially while the computation graph stays fixed."

Ou seja: os pesos são diferentes. O que é idêntico é a planta da casa, não a casa. Quem sair dizendo "é byte a byte igual ao 3.6" vai ser desmentido pela primeira pessoa que abrir os safetensors.

E, sendo honesto até o fim: a evidência sustenta apenas "não foi arquitetura". A comunidade completou sozinha o "logo, foi dado". Pode ter sido dado, pode ter sido pós-treino, pode ter sido receita de otimização — a Qwen não divulgou nenhum dos três, nem contagem de tokens, nem knowledge cutoff, nem avaliação de segurança. Trocamos caixa-preta de arquitetura por caixa-preta de treino.

Nada disso, aliás, é o que vai te queimar. O que queima é a terça-feira em que o seu agente morre com um erro de template Jinja e você perde o dia inteiro caçando o fix num discussion perdido do Hugging Face — que é o tipo de coisa que se resolve em minutos quando você tem com quem trocar, e em dias quando você está sozinho. É basicamente isso que o Clã Beer and Code é: gente construindo com IA ao vivo, toda semana, dividindo o que já quebrou.

Benchmarks reais, e o que a tabela do vendor omite

Os números do 3.8 27B contra o 3.6 27B, todos reportados pela própria Qwen:

O DeepSWE 1.1 é o número violento: triplicou com o mesmo grafo. E o OSWorld-Verified, +20,4 pontos, é uso de computador — o modelo é vision-language nativo, não só-texto. Mesmo desenho de rede, vinte pontos a mais controlando uma tela.

Outro dado publicado sem alarde: o 27B denso bate o Qwen3.7-Plus, tier superior da própria casa, em SWE-bench Pro (61,7 vs 57,6), QwenSWEBench (79,0 vs 59,2), CoWorkBench (70,7 vs 61,0) e JobBench (33,4 vs 21,8). Modelo que roda na sua máquina passando o pago da casa.

Contra o Muse Glimmer 30B, a imprensa carimbou o "beats on many benchmarks" — Terminal-Bench 73,0 vs 51,7, GPQA Diamond 89,2 vs 83,5. Só que a tabela omite o Glimmer em NL2Repo-Bench, DeepSWE 1.1, JobBench e LiveCodeBench v6. Comparação incompleta por omissão do vendor.

E onde ele perde: 5,2 pontos atrás do Opus 4.6 Max no Terminal-Bench (73,0 vs 78,2), 9,2 no HLE, e NL2Repo-Bench 42,3 vs 47,6.

Aviso de método, e vale por metade do post: zero desses números foi reproduzido de forma independente. A kingy.ai é literal — "Every launch score comes from Qwen", "several benchmarks are in-house, corrected or modified". Até o "FP8 empata com BF16" é, nas palavras deles, "a vendor claim until evaluated".

O problema do thinking token: 10x mais para o mesmo resultado

Aqui mora a conta que não aparece na tabela.

O card recomenda xhigh como esforço de raciocínio default, e o preserve_thinking vem ligado por padrão em todos os workloads. Junte os dois: um modelo que pensa muito, pensa de novo, e carrega o raciocínio adiante entre turnos.

Na thread do Hacker News — 1.269 pontos e 741 comentários quando conferi, número que se move — o CMay conta que o 3.8 acertou um benchmark privado dele, mas "it took 5x as many tokens to do it and 12m30s with MTP enabled". O Casteil é mais duro: o Gemma 4 26B chega na mesma resposta com "only 1/10th as many 'thinking' tokens", numa fração do tempo. E o dofm descreve o trace como "almost caveman" — o modelo larga palavras funcionais e escreve em nota ("Need be helpful concise"), levantando a hipótese de que "this rather unique thinking trace pattern is actually hobbling the MTP predictions".

Traduzindo pra produto: se o modelo gasta 5x mais token de raciocínio pro mesmo resultado, o preço por 1M de output deixou de ser a métrica relevante. Baixe o esforço.

{
  "model": "qwen/qwen3.8-27b",
  "reasoning": { "effort": "low" },
  "messages": [{ "role": "user", "content": "..." }]
}

Rodando o Qwen 3.8 27B local: VRAM real, KV cache e o fix dos templates Jinja

A imprensa simplificou o requisito para "24GB, classe RTX 4090". Os números reais são outros:

A frase da fonte: "A 24GB GPU is a plausible target for a four-bit quant at moderate context, not for BF16, FP8 or the full 262K window." Numa RTX 5090 de 32GB você roda Q4 confortável e FP8 nunca.

Mas o custo real não é o peso — é o KV cache. A conta que circula no HN dá ~64KB por token no Qwen contra ~13KB no Glimmer: 32K de contexto comem 2,5GB de VRAM, enquanto Gemma 4 e Glimmer entregam 256k–768k na mesma memória, com o Glimmer chegando a "4x the aggregate tokens/s". E quantizar o cache pra compensar não salva: o relato é que "doing any quantizing definitely hurt results a lot" — o modelo exige F16 em K e V.

O segundo tropeço é o template. O oficial do 3.8 tem quatro bugs conhecidos, dois bloqueantes pra quem monta agente: ele "throws a fatal runtime exception if you pass enable_thinking=false" — você não consegue desligar o raciocínio — e quebra com TypeError: Can only get item pairs from a mapping ao receber argumentos de tool no formato OpenAI. No repo do Unsloth, o troed reportou "System message must be at the beginning." rodando GGUF no llama.cpp; o danielhanchen corrigiu em ~23h.

O fix da comunidade é um arquivo só, o froggeric/Qwen-Fixed-Chat-Templates v22 (13/08/2026), cobrindo 3.5, 3.6 e 3.8:

llama-server -m Qwen3.8-27B-Q4_K_M.gguf \
  --jinja \
  --chat-template-file chat_template.jinja \
  --reasoning-format deepseek \
  --ctx-size 32768 \
  --cache-type-k f16 --cache-type-v f16

Se você nunca subiu um modelo local de ponta a ponta, o caminho está mastigado no nosso guia de como rodar LLM local.

Qwen 3.8 27B denso vs Qwen 3.8 Max (2,4T MoE): qual dos dois é pra você

Confusão comum nesta semana, e vale separar: são dois modelos diferentes.

O 3.8 27B é o denso deste post: 27,78B de parâmetros, pesos abertos, roda na sua máquina. O Qwen3.8-Max é o MoE topo de linha (Qwen3.8-2.4T-A95B) — 2,4 trilhões de parâmetros totais, ~95B ativos, anunciado em 03/08/2026, e com post próprio aqui: Qwen 3.8 Max, mais o desdobramento dos pesos abertos.

A decisão prática: 27B denso se o requisito é dado que não sai da sua infra, custo previsível ou latência sem rede — via API, US$ 0,45/US$ 3,20 por 1M contra US$ 2/US$ 6 do Max, ~4,4x mais barato no input. Max se a tarefa é de fronteira e você aceita depender de API de terceiro.

Não é "menor vs maior". É "onde o dado mora vs quanto de raciocínio você precisa".

Limitações e pontos de atenção

Onde este release ainda está no escuro, sem enfeite:

• Nenhuma reprodução independente. Todo score é da Qwen. Não trate a tabela como fato de engenharia até alguém de fora rodar.
• Treino não divulgado. Dados, contagem de tokens, knowledge cutoff, avaliação de segurança: nada publicado. A tese "foi dado" é inferência, não documentação.
• Tokens/s da comunidade não são comparáveis. Relatos vão de 40 a 200 tokens/s conforme quantização, speculative decoding e hardware.
• Carregar ≠ operar. NxCode: "A laptop that loads the model may still struggle with a 256K agent session." Com preserve_thinking no default, você ainda carrega suposição errada de um turno pro outro.
• Rumores não confirmados: um "Qwen 3.8 35B-A3B" avistado (o 35B-A3B publicado é da geração 3.6) e uma versão abliterada do 3.8 (as que localizei são todas de 3.6). Números de threads do Reddit que circulam por aí também não foram verificados aqui — verificado mesmo, só o Hacker News linkado acima.
• Segurança: peso aberto sem avaliação de segurança publicada não vira endpoint exposto ao cliente sem guardrail e log seus.

FAQ

Se a arquitetura é a mesma, dá pra usar o 3.8 como drop-in do 3.6? Na inferência, quase — o grafo é o mesmo e o stack de serving reconhece. Na prática não, por causa do template: o oficial do 3.8 quebra com enable_thinking=false e com tool call OpenAI. Troque o template antes de apontar seu agente pra ele.

Roda na minha RTX 5090 de 32GB? Q4_K_M sim, com folga (15,93 GiB de peso + KV). FP8 não fecha com contexto útil, e BF16 nem perto. Contexto grande custa mais VRAM que o modelo em si.

Vale mais que o Gemma 4 26B pra agente local? Depende do que dói mais em você. O Qwen pontua mais nos benchmarks de agente; o Gemma 4 resolve tarefas parecidas com uma fração dos tokens de raciocínio e muito mais contexto na mesma VRAM. Meça no seu caso, com o seu prompt.

Por que o enable_thinking=false estoura exceção? Bug do template Jinja oficial, não do modelo. Corrigido no pacote do froggeric e nas variantes UD-* do Unsloth.

Conclusão

O mais interessante deste release não é o modelo. É a evidência pública de que, em quatro meses, a mesma rede — mesmo grafo, mesmos dims, mesma classe herdada do 3.5 — triplicou num benchmark de engenharia de software. Arquitetura parou de ser o gargalo. Treino e pós-treino são o campo de batalha agora.

Só não confunda "não foi arquitetura" com "foi dado". A primeira frase está provada por diff. A segunda é palpite bem-educado sobre uma caixa-preta.

E, na sua máquina, nada disso pesa tanto quanto o KV cache, o template quebrado e o raciocínio no default errado. Modelo bom que você não consegue operar não vira produto. Baixe o reasoning_effort, troque o template, meça token por tarefa — e só depois olhe a tabela.