Qwen3.6 27B: quanta VRAM ele precisa de verdade

Um modelo de 27B que gasta metade do KV cache de um Llama 3 8B. A arquitetura híbrida quebra a conta usual — e decide, por menos de 1 GB, quais placas ficam de fora.

25 de junho de 2026

Com pressa? Peça o TL;DR ao Claude — ele lê a página e resume.

O Qwen3.6 27B saiu em abril de 2026 como modelo denso, licença Apache 2.0, 262 mil tokens de contexto nativo e entrada multimodal. Denso de 27B costuma significar “esquece, não cabe na sua placa”.

Só que ao abrir o config.json dele a conta não fecha do jeito esperado. Ele gasta metade do KV cache de um Llama 3 8B — um modelo três vezes e meia menor.

O motivo está numa linha da configuração que quase ninguém lê.

Qwen3.6-27B · do config.json oficial

Parâmetros: 27,8 B (denso)
Camadas: 64
Atenção plena: apenas 16 delas
Cabeças KV: 4 (GQA 24:4)
Dimensão da cabeça: 256
Contexto nativo: 262.144 tokens

A linha que muda tudo

No config.json, entre as chaves comuns, está esta:

"full_attention_interval": 4,
"layer_types": ["linear_attention", "linear_attention", "linear_attention", "full_attention", ...]

O modelo tem 64 camadas, mas só uma a cada quatro usa atenção plena. As outras 48 usam atenção linear.

Essa distinção é a coisa mais importante deste post, porque as duas se comportam de maneira oposta na memória:

Atenção plena guarda um par chave/valor por token, em cada camada. É o KV cache, e ele cresce sem parar conforme a conversa anda.
Atenção linear mantém um estado de tamanho fixo, comprimindo o passado num resumo de dimensão constante. Dobre o contexto e esse estado não muda de tamanho.

Ou seja: 48 das 64 camadas simplesmente não participam do crescimento de memória. Quem aplicar a fórmula usual — a do post anterior sobre VRAM — sobre as 64 camadas vai errar por um fator de quatro.

O KV cache real

A fórmula continua a mesma, mudando apenas quantas camadas entram nela:

bytes por token = 2 × camadas_de_atenção_plena × cabeças_kv × dim_cabeça × bytes

2 × 16 × 4 × 256 × 2 = 65.536 bytes = 64 KiB por token

Sessenta e quatro KiB. Para comparar, com a mesma matemática:

Modelo	Camadas com KV	KiB/token	128k de contexto (GB)
Llama 3 8B	32 de 32	128	17,18
Qwen3.6 27B (real)	16 de 64	64	8,59
Qwen3.6 27B se fosse denso	64 de 64	256	34,36

Aritmética a partir do config.json de cada modelo, com cache em FP16 — não é medição. A terceira linha é um contrafactual: o que o mesmo modelo custaria se todas as camadas fossem de atenção plena.

Um modelo de 27 bilhões de parâmetros com metade do custo de contexto de um de 8 bilhões. É contraintuitivo, e é a razão pela qual esse modelo cabe onde não deveria caber.

Os pesos

Com 27,8 bilhões de parâmetros:

Quantização	Pesos (GB)
BF16	55,6
Q8_0	29,5
Q6_K	22,9
Q5_K_M	19,8
Q4_K_M	17,0

Bits por peso efetivos dos K-quants do llama.cpp. O Ollama publica qwen3.6:27b com 17 GB em Q4_K_M — a conta bate na casa decimal, o que é um bom sinal de que os bits por peso usados aqui estão corretos.

Cabe na sua placa?

Aqui a conta encontra o hardware. Pesos em Q4_K_M, mais o KV cache do contexto, mais 1 GB de folga para o runtime:

Máquina	Memória (GB)	Sobra p/ contexto (GB)	Contexto possível
RTX 5070 · 12 GiB	12,9	—	não cabe
RTX 5070 Ti · 16 GiB	17,2	—	falta 0,8 GB
RTX 4090 · 24 GiB	25,8	7,7	115k
RTX 5090 · 32 GiB	34,4	16,3	243k
MacBook Pro M4 Max · 48 GiB	51,5	33,5	262k (teto)
Mini PC · 96 GiB	103,1	85,1	262k (teto)

Aritmética, não medição: pesos em Q4_K_M (17,0 GB) + KV cache a 64 KiB/token + 1 GB de overhead. Não inclui o estado das camadas lineares nem o que o sistema já ocupa da GPU. Números medidos vêm no próximo post.

Olhe a segunda linha. A 5070 Ti fica de fora por 0,8 GB — menos de 5% da memória da placa. Os pesos sozinhos ocupam 17,0 dos 17,2 GB que ela tem; sobram 200 MB para runtime e contexto, o que não dá nem para carregar.

É o tipo de margem que faz alguém comprar a placa errada. Uma placa de 16 GB parece confortável para um modelo “de 17 GB” até você lembrar que GB de arquivo e GiB de placa não são a mesma unidade, e que ainda faltam o cache e o overhead.

O que dá para reproduzir agora

A parte aritmética deste post você confere sozinho, sem baixar 17 GB:

# A configuração oficial — a fonte de tudo que está acima
curl -sL https://huggingface.co/Qwen/Qwen3.6-27B/raw/main/config.json \
  | python3 -c "
import json,sys
from collections import Counter
t = json.load(sys.stdin)['text_config']
tipos = Counter(t['layer_types'])
plenas = tipos['full_attention']
kv = 2 * plenas * t['num_key_value_heads'] * t['head_dim'] * 2
print('camadas:', t['num_hidden_layers'], dict(tipos))
print('KV por token:', kv, 'bytes =', kv // 1024, 'KiB')
"

E, para conferir na sua própria placa depois de baixar:

ollama pull qwen3.6:27b

# Com contexto declarado — o padrao do runtime nao e o que voce vai usar
OLLAMA_CONTEXT_LENGTH=131072 ollama run qwen3.6:27b "ok"

# Quanto reservou de fato, e se sobrou algo na CPU
ollama ps
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

O que eu ainda não sei

Sendo explícito sobre a fronteira entre o que este post prova e o que ele apenas sugere.

Provado aqui: a arquitetura híbrida, o KV cache de 64 KiB/token e o que a aritmética diz sobre cada máquina. Tudo derivado do config.json oficial, reproduzível pelo comando acima.

Ainda não medido: o estado das camadas lineares, o consumo real na GPU depois de carregado, tokens por segundo em cada máquina, e o que a atenção linear cobra em qualidade num contexto de 200 mil tokens — porque comprimir o passado num estado fixo não é de graça, e é justamente o teste que interessa.

Essa última é a pergunta boa. Um modelo que promete 262k de contexto e cabe numa 4090 é notícia; se ele lembra do que estava no token 30 mil quando chega no 200 mil é outra conversa, e ninguém responde isso com aritmética.

No próximo post eu meço, nas seis máquinas. A conta diz o que cabe; só a medição diz o que presta.

Fontes: config.json oficial no Hugging Face · anúncio do modelo · qwen3.6:27b no Ollama