Muse Glimmer 30B cabe mesmo numa RTX 3090? A Meta diz uma coisa, quem testou diz outra

A briga começou umas seis horas depois do anúncio.

De um lado, a imprensa: a Meta Superintelligence Labs lançou o Muse Glimmer, 30 bilhões de parâmetros, pesos abertos sob Apache 2.0, e ainda assim "você vai precisar de um PC poderoso". Do outro, o r/LocalLLaMA postando print de nvidia-smi: rodando numa RTX 3090 usada de 2020, com 130 mil tokens de contexto, sobrando VRAM.

As duas coisas não podem estar certas ao mesmo tempo. Só que estão.

Neste post eu resolvo a contradição com as únicas coisas que importam quando o assunto é modelo local: o orçamento de VRAM item por item, a conta do KV cache que explica o truque de engenharia da Meta, e uma estimativa honesta de tokens por segundo numa 3090, com a matemática à mostra para você conferir.

TL;DR

• O que é: Muse Glimmer 30B, modelo denso da Meta Superintelligence Labs com encoder de percepção de 1,8B, otimizado para workflows de agente local.
• Licença: Apache 2.0. Uso comercial liberado, sem cláusula de usuários ativos mensais.
• Cabe na 3090? Cabe. O modelo de linguagem em 4 bits ocupa ~17 GB e o KV cache de 131k tokens custa ~1,7 GB. Sobra folga em 24 GB.
• Onde a imprensa acerta: se você quiser modelo + visão + drafter de speculative decoding tudo carregado ao mesmo tempo, 24 GB não fecha.
• Stack: ollama run muse-glimmer ou GGUF da Unsloth no llama.cpp.
• Oficial: research.meta.ai e developer.meta.com.

O contexto: por que virou briga de VRAM

O anúncio oficial da Meta é cuidadoso. Diz que o modelo é "pequeno o suficiente para rodar num Mac ou PC com uma única GPU de consumidor" e que a quantização de 4 bits deixa o modelo de linguagem "abaixo de 20 GB", cabendo num "envelope de 24 GB ou 32 GB".

Note o plural. São dois envelopes, e a Meta publicou dois checkpoints diferentes para eles:

Fonte: model card no Hugging Face.

A imprensa pegou a linha de cima e o Reddit pegou a de baixo. O Notebookcheck resumiu assim: "você precisa de 24 GB de memória de vídeo, então uma RTX 5090, uma RTX 4090 ou um Mac com M4 Max". Repara no que ficou de fora dessa lista. A RTX 3090 também tem 24 GB. Ela simplesmente não aparece em nenhum blog de vendor, porque nenhum vendor tem interesse em benchmarkar uma placa de 2020.

O blog da NVIDIA fez pior: a página oficial destaca a RTX 5090 de 32 GB como "a opção de consumidor" e joga o número de throughput de um Blackwell Ultra de datacenter no meio do texto. É marketing de placa nova usando modelo aberto como isca.

E aqui está o ponto que separa quem lê release de quem coloca coisa em produção: o número que decide se cabe na sua placa não é o tamanho do modelo. É a soma de quatro coisas que disputam a mesma VRAM. Se você quer aplicar esse tipo de conta em produto de verdade, junto com outros devs fazendo a mesma coisa, é essa a conversa que rola dentro da Beer And Code.

Vamos fazer a soma.

A conta de VRAM que ninguém fez

Um modelo denso de 30B roda em quatro pedaços na memória: os pesos do modelo de linguagem, o KV cache, o encoder de percepção (se você quiser entrada de imagem) e o drafter do speculative decoding (se você quiser velocidade).

Os pesos

A Unsloth publicou a tabela de GGUF no dia do lançamento:

Na 3090, o alvo é o UD-Q4_K_XL: 17 GB. Sobram 7 GB.

O KV cache (aqui está o truque)

Essa é a parte que a cobertura toda ignorou, e é onde mora a engenharia de verdade.

O model card entrega a arquitetura: 52 camadas, atenção com grouped-query de 32 query heads para 2 KV heads, head dimension 128, e um padrão de atenção [Local, Local, Local, Global] repetido, com janela deslizante de 2048 tokens nas camadas locais.

Traduzindo para bytes. Cada token, em cada camada, guarda chave e valor:

2 (K e V) × 2 KV heads × 128 dims × 2 bytes (fp16) = 1.024 bytes = 1 KiB por camada

Das 52 camadas, só 1 em cada 4 é global. São 13 camadas globais que guardam o contexto inteiro e 39 locais que só guardam os últimos 2048 tokens.

Globais:  13 camadas × 1 KiB × 131.072 tokens = 1,63 GiB
Locais:   39 camadas × 1 KiB ×   2.048 tokens = 0,08 GiB
------------------------------------------------------
KV cache a 131k de contexto:                    ~1,7 GiB

Um KV cache de 1,7 GB para 131 mil tokens num modelo de 30B. Para você ter escala: se as 52 camadas fossem todas globais com esse mesmo GQA, dariam 6,5 GiB. Se além disso fossem 8 KV heads em vez de 2, como é comum, dariam 26 GiB. Ou seja, mais que a placa inteira, só de cache.

Não é o modelo que é pequeno. É o cache que foi projetado para caber. A combinação de GQA agressivo com sliding window em 3 de cada 4 camadas é o que transforma "30B com 131k de contexto" em algo que uma placa de consumidor segura.

A conta fecha

Um dev benchmarkou numa RTX 4090 e reportou 19,34 GB de VRAM usados, com Q4_K_XL e 130 mil tokens de contexto, sem quantizar o KV cache.

Nossa conta: 17 GB de pesos + 1,7 GB de KV + buffers de compute do llama.cpp. Dá 19,3 GB.

Bate. A arquitetura publicada explica o número observado. É isso que eu quero dizer com "resolver a contradição com números": a comunidade não está exagerando, e dá para provar no papel antes de baixar 17 GB.

Mão na massa: o orçamento real da 3090

Agora o cenário completo, numa placa de 24 GB:

As duas últimas linhas são estimativa aritmética, não número publicado: 1,8B de parâmetros em BF16 dá 3,6 GB, e o drafter tem 5 camadas com 32 query heads e 8 KV heads.

O veredito, em três linhas:

• Só texto, 131k de contexto: cabe com folga de quase 5 GB. É o caso de uso de agente de código local, e é o que o pessoal do Reddit está rodando.
• Texto + imagem: cabe raspando. Se a 3090 também é a placa que desenha o seu desktop, você vai brigar por 1 GB. Rode headless ou baixe o contexto.
• Texto + imagem + drafter: não fecha em 24 GB. Aqui a imprensa está certa. Você desce para UD-Q3_K_XL e aceita a perda, ou aceita rodar sem speculative decoding.

Rodando com Ollama, que ganhou suporte no dia:

ollama run muse-glimmer

# reasoning controlável: low / medium / high / xhigh
# e um atalho pra plugar num harness de agente:
ollama launch claude --model muse-glimmer

Ou direto no llama.cpp, que é onde você controla o orçamento de VRAM de verdade:

# só texto, contexto cheio
./llama.cpp/llama-cli \
    -hf unsloth/Muse-Glimmer-30B-GGUF:UD-Q4_K_XL \
    --ctx-size 131072 \
    --n-gpu-layers 99 \
    --temp 1.0 --top-p 0.95 --top-k 64

# com visão: some ~3,6 GB do mmproj no orçamento
./llama.cpp/llama-cli \
    --model Muse-Glimmer-30B-UD-Q4_K_XL.gguf \
    --mmproj mmproj-BF16.gguf \
    --ctx-size 65536 \
    --temp 1.0 --top-p 0.95 --top-k 64

Os parâmetros de sampling não são chute meu: temperature 1.0, top_p 0.95, top_k 64 são os recomendados pela Unsloth. Modelo de agente com temperatura errada vira gerador de tool call inválida, e você vai passar a tarde culpando o modelo.

Se essa é sua primeira vez subindo modelo na própria máquina, o caminho mais curto está no guia de como rodar um LLM local.

E os tokens por segundo?

Ninguém publicou número de 3090. Nem a Meta, nem a NVIDIA, nem a AMD. Então vamos estimar com a conta que funciona para decode, que é dominado por banda de memória:

tokens/s (teto) ≈ largura de banda ÷ bytes lidos por token

Na prática, você lê os pesos inteiros a cada token gerado.

• RTX 5090: 1.792 GB/s. Com ~20 GB de pesos, teto de ~90 tok/s. A Meta mediu 74,9 tok/s sem drafter. Eficiência real de ~84% do teto teórico.
• RTX 3090: 936 GB/s. Com 17 GB de pesos, teto de ~55 tok/s. Aplicando a mesma eficiência: ~40 tok/s.

Coloque a margem de erro que quiser: algo entre 30 e 45 tokens por segundo, sem speculative decoding. Para um agente que roda em background, mastigando tarefa longa enquanto você faz outra coisa, isso é mais que suficiente. Para chat interativo, é confortável. Não é lento.

O DFlash, o drafter de speculative decoding da Meta, prevê 16 tokens por forward pass e por isso quebra o teto de banda: na 5090, a Meta reporta salto de 74,9 para 233,4 tok/s, 3,1x. Em Apple Silicon o ganho é menor, 1,5x no M4 Max (23,7 para 37,8) e 1,8x no M5 Max (26,6 para 50,2).

Não espere 3,1x na 3090. Ampere não tem os caminhos de FP8 e FP4 que a Blackwell usa, e como vimos acima o drafter ainda precisa caber na VRAM que sobrou. Trate o 3,1x como teto de marketing.

Glimmer contra Qwen: onde ele ganha e onde perde

O pós-anúncio virou "bateu o Qwen3.6-27B" na timeline. Os números oficiais são mais interessantes que isso, porque contam uma história de especialização:

O Glimmer domina em orquestração de ferramenta (MCP Atlas, 13 pontos acima) e perde em uso de computador e trabalho de terminal. Faz sentido com o que a Meta diz ter otimizado: uso de tool, tarefa longa e recuperação de falha.

O índice agregado da Artificial Analysis, segundo o AINews, coloca o Glimmer em 35, atrás do Qwen3.6-27B em 38. Ou seja: como modelo geral, o Qwen ainda é melhor. Como motor de agente com MCP, o Glimmer é melhor. Escolha pelo trabalho, não pelo ranking.

E tem um detalhe de calendário que muda a conta na semana que vem: a Alibaba prometeu abrir os pesos do Qwen3.8 na semana de 10 de agosto, e o checkpoint que interessa para quem tem 24 GB é o Qwen3.8-27B, não o Max de 2,4 trilhões. Já detalhei essa conta no post sobre os pesos abertos do Qwen 3.8 Max. Se o 27B vier com uma arquitetura de cache tão agressiva quanto a do Glimmer, a briga pela sua 3090 fica boa.

Limitações e pontos de atenção

Segurança de agente é o buraco. No AgentDojo com o ataque Siren, o Glimmer teve 28,4% de taxa de sucesso de ataque com 94,2% de utilidade. Traduzindo: em quase 1 de cada 3 tentativas de prompt injection, o agente foi virado. Agente local com acesso ao seu shell e ao seu filesystem não é brinquedo. Sandbox, allowlist de ferramenta e aprovação humana em ação destrutiva continuam obrigatórios.

A degradação de 1% não é zero. O checkpoint K-Quant-17GB, o que cabe em 24 GB, perde 1,0% contra o BF16. O de 32 GB perde 0,2%. Num agente que encadeia 20 chamadas de ferramenta, 1% de degradação por passo compõe.

Knowledge cutoff em 4 de janeiro de 2026. Ele não sabe nada de 2026 pra frente. Para agente de código isso importa menos, porque a informação vem do seu repositório. Para pergunta aberta, importa muito.

Cuidado com os números de vendor. O blog da NVIDIA fala em "mais de 20K tokens/s por GPU" numa seção e "mais de 20 tokens/s por GPU" em outra, e o contexto é Blackwell Ultra de datacenter, não a sua placa. Antes de repetir número de blog de fabricante, pergunte: em qual hardware, com qual quantização, com ou sem drafter, batch de quanto?

Placa de 12 GB está fora, e não adianta insistir. Dá para forçar UD-Q2_K_XL em 12 a 14 GB, mas 2 bits num modelo de agente é receita para tool call malformada.

FAQ rápido

Vale trocar minha 3090 por uma 5090 por causa disso? Para esse modelo, não. Os 24 GB da 3090 seguram o checkpoint que a Meta desenhou para 24 GB. Você ganha velocidade e o caminho completo do DFlash na 5090, mas a diferença é entre "rápido" e "muito rápido", não entre "roda" e "não roda".

Posso usar comercialmente? Sim. Apache 2.0, sem teto de usuários ativos mensais e sem cláusula de branding, diferente das licenças anteriores de Llama. É provavelmente a notícia mais importante do lançamento e a que menos gerou manchete.

Preciso do encoder de visão? Só se o seu agente lê screenshot, PDF escaneado ou mockup. Ele custa ~3,6 GB de VRAM que você poderia gastar em contexto. Para agente de código puro, deixe fora.

Roda em Mac? Roda, e bem: ollama run muse-glimmer:30b-mlx. M4 Max faz 23,7 tok/s sem drafter e 37,8 com. Memória unificada ajuda aqui, você não briga com o limite rígido de VRAM.

Conclusão

A contradição era falsa desde o começo. A imprensa está descrevendo o envelope de 32 GB e o pessoal do Reddit está rodando o checkpoint de 24 GB, e os dois checkpoints existem porque a Meta publicou os dois de propósito.

O que vale levar embora não é "cabe na 3090". É o método: quando alguém disser que um modelo cabe ou não cabe na sua placa, some os quatro pedaços (pesos, KV cache, encoder, drafter), olhe a arquitetura de atenção antes de olhar a contagem de parâmetros, e divida a banda de memória pelo tamanho dos pesos para estimar velocidade. Três contas de guardanapo que valem mais que dez threads.

E olhe onde a fronteira andou. Um modelo denso de 30B com 131k de contexto, entrada de imagem e licença Apache 2.0, rodando numa placa usada de 2020 sem uma única chamada de rede. Há dois anos isso era um cluster.