Qwen 3.6: Comparação 35B vs 27B - resultados de benchmark
Finalmente resumi todos os resultados dos testes dos modelos Qwen 3.6 que coletei nos últimos dias. Comparei dois modelos em detalhes: o Qwen3.6-35B-A3B (MoE, hybrid attention/delta) e o Qwen3.6-27B (dense, hybrid attention/delta). Executei ambos com compressão de cache KV turbo3 em uma RTX 4090 como servidor llama.cpp.
Se eu tivesse que resumir brevemente: o 35B-A3B é 3-4x mais rápido em tudo, mas o 27B entrega melhor qualidade. Este é o tradeoff clássico MoE vs. dense, apenas apoiado por números.
Arquitetura - qual é a diferença?#
Ambos os modelos vêm da mesma família Qwen3.6, ambos usam uma arquitetura hybrid Mamba/attention, mas suas abordagens são completamente diferentes:
35B-A3B:
- 35B parâmetros totais, mas apenas 3B ativos por token
- 40 camadas: 10 × (3× Gated DeltaNet → MoE) + 1 × (Gated Attention → MoE) por bloco
- Apenas 10 camadas de attention completo (GQA, 16Q/2KV, 256-dimensionais)
- 30 camadas Gated DeltaNet (recorrentes, sem cache KV)
- Roteamento MoE: 8+1 shared expert de 256 experts
- Contexto nativo: 262.144 tokens
27B Dense:
- 27B parâmetros totais, 27B ativos por token (todo parâmetro é ativado)
- 64 camadas: 16 × (3× Gated DeltaNet → FFN) + 1 × (Gated Attention → FFN) por bloco
- Apenas 16 camadas de attention completo (GQA, 24Q/4KV, 256-dimensionais)
- 48 camadas Gated DeltaNet (recorrentes, sem cache KV)
- FFN denso - sem MoE, tudo calculado a cada token
- Contexto nativo: 262.144 tokens
O ponto principal: o 35B-A3B chama apenas 9 de 256 experts por token, enquanto o 27B precisa processar todos os seus parâmetros. Isso significa 9x menos computação por token.
Needle-In-Haystack (NIAH) - recuperação de contexto longo#
Este teste mede se o modelo consegue encontrar uma informação-chave em um texto enorme. A agulha é uma frase que escondi em algum lugar no feno, e o modelo precisa recuperá-la.
35B-A3B (quant IQ4_XS, cache KV turbo3):
| Contexto | 0% | 5% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|
| 4k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 8k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 16k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 32k | 1.0 | - | 1.0 | 1.0 | - | 1.0 |
| 64k | 1.0 | - | 1.0 | 1.0 | - | 1.0 |
| 128k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 200k | 1.0 | - | - | 1.0 | - | 1.0 |
Total: 100% (74/74 testes) - perfeito em todos os comprimentos de contexto e posições de profundidade.
27B (quant UD-Q5_K_XL, cache KV turbo3):
| Contexto | 0% | 5% | 25% | 50% | 75% | 100% |
|---|---|---|---|---|---|---|
| 4k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 8k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 16k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 32k | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| 64k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 100k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
| 130k | 1.0 | - | 1.0 | 1.0 | 1.0 | 1.0 |
Total: 100% (78/78 testes) - também perfeito em todos os lugares.
Veredito: Ambos os modelos produzem resultados NIAH perfeitos, sem degradação observada sob quantização de cache KV turbo3. Testei o 35B-A3B até comprimentos de contexto maiores (200k vs 130k), mas o 27B também deu 100% estável em todos os pontos testados.
Velocidade de geração de tokens - a grande diferença#
É aqui que a diferença MoE vs. dense se torna verdadeiramente impressionante. Em uma RTX 4090 com cache KV turbo3:
Decode (geração de token):
| Contexto | 35B-A3B (tok/s) | 27B (tok/s) | Razão |
|---|---|---|---|
| Curto ctx (pico) | 161.8 | 40.3 | 4.0× |
| 4k | 152.6 | 38.7 | 3.9× |
| 8k | 142.7 | 36.5 | 3.9× |
| 16k | 122.2 | 32.4 | 3.8× |
| 32k | 96.0 | 28.1 | 3.4× |
| 64k | 65.4 | 18.6 | 3.5× |
| 100k+ | ~55 (estimado) | 16.6 | ~3.3× |
Prefill (processamento de prompt):
| Contexto | 35B-A3B (tok/s) | 27B (tok/s) | Razão |
|---|---|---|---|
| Pico | 5912 (em 4k) | 2620 (em 4k) | 2.3× |
| 4k | 5912 | 2620 | 2.3× |
| 16k | 5441 | 2610 | 2.1× |
| 32k | 5271 | 2331 | 2.3× |
| 64k | 4688 | 1959 | 2.4× |
| 100k | ~4200 (estimado) | 1733 | 2.4× |
O que isso significa na prática?
O 35B-A3B é 3,5-4x mais rápido na geração de tokens. Isso significa que se o 27B leva 10 segundos para escrever um parágrafo, o 35B-A3B faz o mesmo em 2,5 segundos. O cenário é semelhante para prefill: 2-2,4x mais rápido no processamento de prompt.
A coisa interessante é que o 35B-A3B tem mais parâmetros totais no geral (35B vs 27B), mas ainda é muito mais rápido porque precisa carregar e processar apenas 3B por token devido ao roteamento MoE. O 27B precisa processar todos os seus parâmetros a cada token.
VRAM e capacidade de contexto#
É aqui que o 35B-A3B realmente brilha:
| 35B-A3B (IQ4_XS) | 35B-A3B (Q4_K_S) | 27B (UD-Q5_K_XL) | |
|---|---|---|---|
| Tamanho do modelo | 17,7 GB | 20,9 GB | 18,65 GB |
| VRAM idle | ~20400 MB | ~22700 MB | ~22900 MB |
| Contexto máximo | 262k | 188k | 156k |
| VRAM livre no máximo | ~3600 MB | ~1300 MB | ~1134 MB |
Nota importante: o contexto de 262k do 35B-A3B é alcançável com quantização IQ4_XS. Com a mesma quantização Q4_K_S (que é mais próxima da UD-Q5_K_XL do 27B), o máximo é 188k. Isso ainda é mais do que os 156k do 27B, mas não tão dramático quanto 262k.
O ponto principal: a arquitetura MoE do 35B-A3B consome menos VRAM por token porque precisa carregar apenas 3B de parâmetros durante o forward pass. Isso deixa mais espaço para o cache KV.
Os testes são realizados não apenas pela compressão de cache KV turbo3, mas também pela técnica Sparse V (desquantização de valor com gate de attention). Esta é uma otimização que filtra posições no kernel de attention flash onde o peso de attention é desprezível (abaixo de 10⁻⁶), e não realiza a desquantização V (valor) ali. O ponto principal: em vez de tentar acelerar a desquantização de cada posição (que atinge limites de hardware), simplesmente pulamos as operações desnecessárias. Em contexto longo, isso pode significar até 22,8% de melhoria na velocidade de decode, sem nenhuma perda de qualidade. E a melhor parte: esta técnica não é específica do turboquant, mas funciona em qualquer formato de cache KV quantizado (q8_0, q4_0, turbo3), porque é baseada na distribuição de attention, não no mecanismo de desquantização.
Qualidade - onde o 27B vence#
Com base nos resultados oficiais de benchmark do Qwen, o 27B supera o 35B-A3B em todos os benchmarks:
| Benchmark | 35B-A3B | 27B | Vencedor |
|---|---|---|---|
| SWE-bench Verified | 73.4 | 77.2 | 27B |
| SWE-bench Pro | 49.5 | 53.5 | 27B |
| Terminal-Bench 2.0 | 51.5 | 59.3 | 27B |
| SkillsBench | 28.7 | 48.2 | 27B (+19.5!) |
| MMLU-Pro | 85.2 | 86.2 | 27B |
| GPQA Diamond | 86.0 | 87.8 | 27B |
| AIME 2026 | 92.7 | 94.1 | 27B |
| LiveCodeBench v6 | 80.4 | 83.9 | 27B |
| HLE | 21.4 | 24.0 | 27B |
| QwenWebBench | 1397 | 1487 | 27B |
O destaque especial é o SkillsBench: +19.5 pontos a favor do 27B. Este é um benchmark especializado em tarefas de agente de codificação, e ali o 27B é imbatível. A diferença é igualmente grande no Terminal-Bench (+7.8) e SWE-bench (+3-4).
Resumo - qual escolher?#
Para o 35B-A3B:
- 🚀 3-4x mais rápido na geração
- 📏 Mais contexto (188k-262k vs 156k)
- Ótimo para RAG, longas conversas, alto throughput
- Qualidade: muito boa, quase no mesmo nível que o 27B
Para o 27B Dense:
- 🏆 Melhor qualidade em todos os benchmarks
- Especialmente melhor para tarefas de agente de codificação (SkillsBench: +19.5)
- Mais lento, mas se a qualidade é o objetivo, a espera vale a pena
- Menos contexto (156k max)
Meu conselho prático:
Se você está executando RAG, gerenciando conversas de longo contexto, ou simplesmente quer que as respostas venham rápido - 35B-A3B. Se você está executando um agente de codificação, resolvendo tarefas lógicas complexas, ou a qualidade é o mais importante - então 27B.
Ambos os modelos funcionam maravilhosamente bem com compressão de cache KV turbo3, e ambos alcançaram 100% no NIAH. Turbo3 não degrada nada - na verdade, devido à economia de VRAM, não foi necessário comprometer o comprimento do contexto de forma alguma.