Qwen3.8-27B, o modelo que pensa demais

Lançado numa sexta-feira, 14 de agosto, o Qwen3.8-27B chegou com o pacote completo: ~27,8 bilhões de parâmetros contando a vision tower, multimodal, denso, 262 mil tokens de contexto nativo (estendíveis a 1 milhão com YaRN), licença Apache 2.0. Em um dia, a thread de lançamento no Hacker News somou 993 pontos e 458 comentários, o repositório base acumulou ~92 mil downloads e o repo FP8 passou de 123 mil (relato da comunidade). O veredito coube em uma frase: o modelo é ótimo, e o padrão de fábrica é terrível.

A briga mais reveladora desses cinco dias, porém, não é sobre o modelo — é sobre quem está do outro lado da tela. Loop supervisionado, com um humano esperando cada resposta, pede raciocínio curto. Execução desacompanhada — agentes em lote rodando de madrugada — aceita raciocínio no máximo. O 3.8-27B sai da caixa configurado para o segundo mundo. A maioria dos usuários vive no primeiro. Todo o resto deste texto é consequência dessa escolha.

O padrão que queima o contexto

O modelo vem com esforço de raciocínio em xhigh, o nível máximo. A análise que definiu a narrativa é do Simon Willison, que chamou o ajuste de hilarious default. O teste dele com um pelicano de bicicleta em SVG: 22.276 tokens de raciocínio durante 21 minutos para produzir 3.223 tokens de saída. O resultado foi, na avaliação dele, “de longe o melhor SVG de pelicano que já consegui com um modelo que roda em máquina local” — e não valeu nem perto a espera.

No mesmo post, um prompt ainda mais simples: “desenhe um SVG de um círculo”. O rastro de raciocínio do modelo começa assim (tradução livre do original): “O usuário pede um desenho SVG de um círculo. Pedido simples — mas quero que seja uma peça cuidadosamente construída. Deixe-me fazer algo que vá além de <circle>: um arquivo autossuficiente com caráter — talvez um estudo geométrico, com animação sutil, anéis em camadas e uma paleta distinta.” Um círculo virou briefing de direção de arte.

Medições da comunidade confirmam o tamanho do problema. Um usuário de RTX 5090 mediu no mesmo prompt: raciocínio em medium reduz a espera em cerca de um terço sem queda de qualidade mensurável, e desligar o raciocínio derruba o tempo de primeira resposta de 2,18 segundos para 0,21. A função existe, funciona, e é uma linha de configuração. O modelo não vem com ela.

O campo minado operacional

Estado dos runtimes verificado em 19/08/2026 — os itens abaixo refletem o llama.cpp, o Ollama e os templates na data; os bugs citados podem já ter sido corrigidos.

Rodar o 3.8-27B local hoje exige contornar o próprio lançamento. Os pontos que custam horas:

• Só low, medium e xhigh funcionam. O llama.cpp aceita minimal, high e max, mas o template do modelo rejeita: o servidor sobe e falha em toda requisição (relato).
• No Ollama, nada disso funciona na versão atual.
• Os templates Jinja do repositório saem quebrados. A comunidade mantém o projeto Qwen-Fixed-Chat-Templates para consertar a chamada de ferramentas sem perder acerto de cache de KV (contexto).

Há também uma alegação de defeito estrutural nas camadas temporais (ssm_conv1d) como causa raiz do excesso de raciocínio, feita por um quantizador que se recusou a portar seu pipeline para o modelo. É tese isolada, sem corroboração. Trate como hipótese, não como diagnóstico.

Lento demais, ou relógio errado?

O campo se dividiu em duas narrativas, e a divisão é instrutiva porque não é sobre o modelo.

O lado contra tem relatos como este: tarefa simples de correção de bug, o modelo identifica o problema em um ou dois minutos de leitura — e depois sai vasculhando arquivos não relacionados por mais de meia hora, até o usuário interromper. O mesmo usuário reporta que isso nunca aconteceu com o Qwen3.6-27B. Conclusão dele: bom para invocar ferramentas, lento demais para uso real com alguém esperando na ponta.

O lado a favor inverte a métrica. A OVERBRING Labs testou em bases de código de produção e argumenta que o que importa é o tempo de relógio até o resultado correto — não tokens por segundo. Um modelo “lento” que termina a tarefa sozinho vence um modelo rápido que te mantém no loop corrigindo metade do caminho. No argumento deles, não é raciocínio excessivo: é pensar sobre a tarefa e suas subtarefas.

A divergência só faz sentido quando você olha para quem está do outro lado da tela. Loop supervisionado pede medium ou menos. Execução desacompanhada aceita xhigh sem dor. É a mesma lição de sempre com modelos de raciocínio, agora com um padrão de fábrica que escolheu o segundo mundo por você.

O que cada hardware aguenta

Medições reais da comunidade, não benchmarks de fabricante:

Três achados operacionais que valem mais que a tabela:

1. --cache-type-k/v q8_0 é o único quant de KV seguro na imagem pré-construída server-cuda. O q5_1 dispara um bug documentado de execução na CPU (llama.cpp#24485), com prefill 33 a 45 vezes mais lento (detalhe).
2. No SGLang, o parâmetro que importa em modelos híbridos é --mamba-full-memory-ratio: o padrão 0,9 superprovisiona o pool de KV e limita a concorrência em silêncio (documentação).
3. Na receita do vLLM, os números medidos na inicialização, numa RTX 5090 de 32 GB a 262 mil de contexto: FP8 serve 377.456 tokens de KV com 14,3 GiB de pesos; NVFP4 chega a 920.517 tokens com 10,6 GiB (build unsloth). O número de vitrine da receita — 6,6 milhões de tokens de KV a 1 milhão de contexto — pressupõe uma Blackwell de datacenter, não a placa da sua mesa.

O custo por token de KV depende da arquitetura e do runtime. Só 16 das 64 camadas são atenção completa com KV; as outras 48 são atenção linear de estado fixo. A conta teórica em fp16 — 4 cabeças de KV, 256 dimensões, 16 camadas, K mais V, 2 bytes — fecha em 64 KiB por token: exatamente o que o llama.cpp reporta. No vLLM, com o cache de KV em fp8 (metade dos bytes por token), os pools medidos implicam 24 a 48 KiB por token conforme o build — uma divergência de 2:1 entre builds no mesmo dtype de cache que a própria receita registra sem explicar. Contexto grande no papel continua caro na memória na prática.

A guerra das quantizações

A AtomicChat quantizou 16 arquivos com imatrix próprio e mediu 20 GGUFs da comunidade no mesmo ambiente de testes, contra os logits de uma conversão BF16 de 88 GB. Entre 12 e 21 GB, a curva deles deriva menos que a concorrência: no ponto de 13,8 GB, 33% menos que o Q3_K_M da Unsloth (KLD média de 0,0325 contra 0,0484). Dias depois, a Unsloth publicou o Dynamic V3.0 (19/08), alegando 10% mais acurácia no mesmo tamanho. Metodologia pública dos dois lados — o consumidor só tem a ganhar.

Uma nota de segurança que diz muito sobre o momento: existiram repositórios falsos de Qwen3.8-27B no Hugging Face antes de os pesos reais existirem (relato). Verifique quem publica antes de baixar qualquer coisa.

A comunidade votou no comportamento do 3.6

A direção das destilações é o dado mais revelador da semana. Quase ninguém está destilando do 27B. O fluxo é o inverso: LoRAs treinados em 50 mil rastros de raciocínio do Qwen 3.8 Max, fundidos no Qwen3.6-27B. Há variantes multi-teacher com rastros do 3.8 Max, do GLM 5.2 e do Kimi K3 sobre a mesma base 3.6. A leitura é direta: a comunidade prefere o comportamento do 3.6 e quer apenas o conhecimento do 3.8.

Dos finetunes publicados — dezenas, num contador que muda todo dia —, quase todos são abliteração. E um deles expôs uma limitação estrutural: segundo a equipe que publicou a própria tentativa de abliteração, o Heretic falhou no 3.8 porque só edita o_proj e down_proj — foi escrito para transformers de atenção completa pura. Não tocou o linear_attn.out_proj das 48 camadas de atenção linear, que é o caminho dominante de tokens na arquitetura híbrida, nem os embeddings. Resultado: o modelo ainda recusava 97 de 100 prompts. Arquitetura híbrida quebra ferramental que assume o layout clássico — e esse alerta vale para qualquer pipeline que pretenda manipular esse modelo camada por camada.

O que muda para pipelines de agentes

O risco silencioso para quem orquestra agentes é o preserve_thinking ligado por padrão: o 3.8 carrega o rastro completo de raciocínio pela conversa inteira. Isso melhora consistência e reuso de cache, e queima janela de contexto fazendo isso. Numa pipeline onde você comprou 262 mil tokens para colocar material extenso — código legado, contratos, transcritos —, a deliberação do modelo compete com o próprio material pelo espaço.

A configuração que a experiência da semana recomenda, por papel do agente:

• Agentes de reconhecimento e triagem → low, preserve_thinking: false
• Agentes de execução e análise → medium
• O agente que decide a arquitetura → xhigh, e só ele
• Templates: os fixos da comunidade, nunca os do repositório
• Cache de KV: q8_0, nada além

Fecho

O 3.8-27B não chegou sozinho. Na mesma leva, a Alibaba liberou os pesos do Qwen3.8-2.4T-A95B — 2,4 trilhões de parâmetros, 95 bilhões ativos por token, 4,9 TB de armazenamento na precisão plena, segundo a documentação da Unsloth, que apresenta 27B, 2.4T-A95B e o produto de API Max como a mesma família 3.8. Na avaliação do Matthew Berman, é o segundo modelo chinês de pesos abertos na faixa de fronteira, do tamanho do Kimi K3. Um 27B local que precisa de raciocínio desligado para o uso diário, e um 2,4T aberto competitivo com a fronteira fechada, são o mesmo evento visto de dois tamanhos.

O debate entre “lento demais” e “tempo de relógio até o resultado” não vai se resolver, porque não é uma disputa técnica. É a diferença entre quem opera o modelo no loop com um humano e quem delega e vai embora. O Qwen3.8-27B serve bem os dois mundos — desde que você saiba em qual deles está, porque o padrão de fábrica escolheu por você, e escolheu o mundo errado para a maioria.