Meta diz 3.1x mas não diz de quanto: rodando Muse Glimmer 30B local com llama.cpp
Meta Superintelligence Labs liberou o Muse Glimmer em 10 de agosto: um modelo denso de 30 bilhões de parâmetros, Apache-2.0, destilado por logits a partir do Muse Spark, multimodal e treinado com dados de mais de 100 idiomas. O enquadramento do próprio blog é inusitadamente estreito para o lançamento de um modelo — isso não é apresentado como um 30B de propósito geral, é apresentado para um único trabalho: “Muse Glimmer is a 30-billion-parameter model optimized for always-on local agent workflows.”
O argumento técnico por trás desse pitch é um envelope de memória. Em precisão completa o modelo precisa de mais de 55 GB. Quantizado para 4 bits com K-quants, o language model desce de 20 GB, o que o coloca dentro de máquinas de 24 e 32 GB. E para que um agente always-on seja tolerável nesse tamanho, Meta inclui um drafter de speculative decoding, DFlash, com três speedups publicados: 3.1x em uma RTX 5090, 1.8x em uma M5 Max, 1.5x em uma M4 Max.
Esses são os números do anúncio. Há duas coisas que convém saber sobre eles antes de planejar uma máquina em torno deles.
Primeiro: os speedups não têm denominador. Meta publica multiplicadores e nenhum throughput absoluto em lugar nenhum — nem no blog, nem no model card. Um 3.1x sobre um tok/s que não é declarado te diz que o drafter funciona; não te diz se o agente é usável na sua máquina. Esse número você tem que medir você mesmo, e a última seção deste artigo é como.
Segundo: os “menos de 20 GB” são apenas o modelo de texto. O vision encoder e o drafter são arquivos separados, e cada um é memória que você também tem que sustentar. A cifra real vem mais abaixo.
O que saiu de verdade, e o que não
O blog diz que as otimizações do llama.cpp, MLX e ExecuTorch “will land in the coming days”. Isso foi verdade por cerca de um dia, e já ficou desatualizado justamente para o que mais importa.
O suporte do llama.cpp está mergeado e funcionando hoje — build b10353 ou posterior, chegou em 10 de agosto. Meta publicou GGUFs oficiais em meta-models/Muse-Glimmer-30B-GGUF, e a comunidade tinha conversões disponíveis no mesmo dia (bartowski, unsloth). MLX e ExecuTorch sim ainda estão pendentes de verdade. Então se você está em Apple silicon e esperava MLX, continua esperando; se quer rodar isso hoje em qualquer coisa, llama.cpp é o caminho, Metal incluído.
Essa é a diferença entre uma integração anunciada e uma mergeada, e neste lançamento importa para os dois lados.
Quanta máquina você realmente precisa
O repositório oficial de GGUFs da Meta traz quatro arquivos. Esta é a tabela que o título de “menos de 20 GB” comprime:
| Arquivo | Tamanho | O que é |
|---|---|---|
muse-glimmer-30B-kquant-17gb.gguf |
16,8 GB | Modelo de texto, direcionado para 24 GB de VRAM |
muse-glimmer-30B-kquant-dynamic.gguf |
19,7 GB | Variante de maior qualidade, direcionada para 32 GB |
mmproj-kquant.gguf |
1,4 GB | Vision encoder — necessário para imagens |
dflash-kquant.gguf |
1,6 GB | Drafter de speculative decoding DFlash |
O que dá três configurações reais, de acordo com os próprios requisitos declarados pela Meta:
- Apenas texto — ~17–20 GB
- Texto + visão — ~19–22 GB
- Texto + visão + drafter — ~20–23 GB
E isso é antes do KV cache. Veja o que isso significa para a placa de 24 GB para a qual o quant de 17 GB é direcionado: com visão e drafter carregados você está em ~20–23 GB de pesos, e a janela de contexto que você pode pagar é o que sobra. Muse Glimmer suporta 131.072 tokens de contexto e até 262.144 — você não vai servir o teto desse alcance em uma placa de 24 GB com o vision encoder residente. O envelope de 32 GB é onde a configuração completa deixa de ser uma negociação.
Este é um número de viabilidade, não de velocidade. Te diz se o modelo cabe, e não diz nada sobre quão rápido ele roda uma vez que cabe.
Se você quer mais espaço, os dynamic quants do Unsloth descem mais: UD-Q2_K_XL em 12–14 GB, UD-Q3_K_XL em 14–15 GB, UD-Q4_K_XL em 17 GB (seu ponto de partida recomendado), UD-Q6_K_XL em 20–22 GB, UD-Q8_K_XL em 34 GB. Um aviso de sua documentação: NVFP4 está marcado como work-in-progress e por enquanto não funciona. Não planeje em torno disso.
Comece pelo quant de 17 GB mesmo que você tenha 32 GB. Ele faz download mais rápido, te deixa espaço para adicionar o vision encoder e o drafter um de cada vez, e você vai aprender onde está seu próprio teto andando em direção a ele em vez de começar acima.
Como rodá-lo
O caminho mínimo é um comando, uma vez que você tenha um llama.cpp atual:
# build b10353 ou posterior é necessário
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON # Metal é ativado por padrão no macOS; remova a flag para CPU-only
cmake --build build --config Release -j
Depois, o modelo:
llama serve -hf meta-models/Muse-Glimmer-30B-GGUF
Isso baixa o quant padrão e te deixa um endpoint compatível com OpenAI. Os configurações de sampling recomendados pela Meta são temperature 1.0, top-p 0.95, top-k 64 — convém defini-los de forma explícita, porque rodar um 30B com defaults ajustados para outro modelo é uma forma comum de concluir que um modelo é pior do que é.
Para adicionar visão, carregue o multimodal projector junto com os pesos de texto:
llama-server \
-m muse-glimmer-30B-kquant-17gb.gguf \
--mmproj mmproj-kquant.gguf \
-c 32768
Mantenha o contexto moderado no início. -c 32768 em uma placa de 24 GB é um ponto de partida realista com visão carregada; suba até que você esbarre em um erro de alocação de memória e depois desça um degrau. Tenha em mente que o vídeo é processado apenas como frames individuais — não há modelagem temporal aqui.
Para adicionar o drafter, DFlash entra como draft model:
llama-server \
-m muse-glimmer-30B-kquant-17gb.gguf \
--model-draft dflash-kquant.gguf \
-c 32768
Vale a pena entender o mecanismo, porque explica de onde sai o speedup e quando ele desaparece. DFlash é um drafter de 5 camadas com sliding-window attention que prediz blocos inteiros de 16 tokens em um único forward pass; depois o 30B verifica o bloco de uma única vez. Quando o drafter acerta, você obtém muitos tokens para cada forward pass caro. Quando erra, você paga o pass do drafter e recebe pouco em troca. O speculative decoding é uma aposta à previsibilidade — que é exatamente por que funciona bem em cargas agênticas cheias de tool calls estruturados e JSON, e pior em prosa aberta.
Isso também explica a diferença entre hardware: 3.1x em uma RTX 5090 contra 1.8x em uma M5 Max não é o drafter se comportando diferente, é quanto o passo de decode base estava limitado pela largura de banda de memória.
Medindo o número que Meta não publicou
Como não há nenhum tok/s de referência em todo o lançamento, assim você consegue o seu. llama-bench te dá prefill e decode separadamente:
llama-bench -m muse-glimmer-30B-kquant-17gb.gguf -p 512 -n 128
pp512 é prefill (processamento do prompt), tg128 é decode (geração de tokens). São números distintos com gargalos distintos e você quer os dois — um agente que lê um contexto grande antes de cada ação vive ou morre pelo prefill, não pelo decode.
Depois rode a mesma coisa com o drafter conectado e compare. Seu multiplicador não vai ser 3.1x a menos que você esteja em uma RTX 5090 rodando uma carga tão previsível quanto a da Meta, e esse é justamente o ponto: o multiplicador é uma propriedade de sua carga de trabalho, não do modelo.
Faça a medição com os prompts reais que seu agente envia. Um loop de tool-calling e uma sessão de chat vão te dar taxas de aceitação bastante distintas.
É realmente melhor do que o que você já está rodando?
A tabela de benchmarks da Meta compara Muse Glimmer contra Gemma4-31B e Qwen3.6-27B. Todos os números são auto-reportados pela Meta:
| Benchmark | Muse Glimmer | Gemma4-31B | Qwen3.6-27B | |
|---|---|---|---|---|
| Agentic | MCP Atlas | 75.5 | 54.2 | 62.5 |
| DeepSearch QA | 74.6 | 61.7 | 71.1 | |
| Coding | SWE-Bench Pro | 51.2 | 36.9 | 50.2 |
| SWE-Bench Verified | 76.0 | 66.6 | 77.2 | |
| Multimodal | Charxiv Reasoning | 78.8 | 77.7 | 78.4 |
| MMMU Pro | 74 | 73 | 75 | |
| Reasoning | AIME 2026 | 94.7 | 89.2 | 94.1 |
| GPQA Diamond | 83.5 | 85.7 | 84.2 |
Leia essa tabela com honestidade e diga algo mais útil que “Meta vence”. Em coding, multimodal e reasoning, Muse Glimmer e Qwen3.6-27B se alternam em posições dentro de um ou dois pontos, e Qwen leva SWE-Bench Verified e MMMU Pro. Gemma4-31B leva GPQA Diamond. Essas colunas descrevem três modelos da mesma classe.
O único lugar onde a lacuna não é marginal é o agêntico: MCP Atlas 75.5 contra 62.5 do Qwen — treze pontos — e DeepSearch QA em 74.6 contra 71.1. É aí que aparecem o mid-training com dados de contexto longo carregados de agentes e o RL do pós-treinamento, e é a única coluna que justifica o enquadramento do lançamento.
A thread de HN (1.123 pontos, 609 comentários) chegou à mesma leitura por outro lado: os usuários descrevem o Glimmer apenas acima do Qwen3.6-27B em quase tudo exceto em tool-calling. Não aparecem autores da Meta na thread. Outros relatórios que vale a pena considerar: os tamanhos quantizados ficam próximos (um Q4_K_XL em ~15.9 GB contra os 17.6 GB do Qwen3.6-27B), o KV cache limita a inferência paralela prática a cerca de 4 requisições concorrentes em hardware de consumidor, e os rastreamentos de raciocínio do Glimmer são consistentemente descritos como concisos.
Assim, a decisão é mais apertada do que o anúncio sugere. Se você executa um modelo local para chat, autopreenchimento de código ou escrita, o caso para mudar é fraco — um ou dois pontos de benchmark, de qualquer forma. Se você executa um modelo local como agente — servidores MCP, loops de ferramentas, workflows com múltiplas etapas — essa lacuna de treze pontos em MCP Atlas é a razão inteira pela qual este modelo existe, e vale a pena medi-la contra seu próprio setup.
O que revisar antes de se comprometer
Três coisas que este lançamento não te diz, em ordem de quanto vão te custar:
- O throughput absoluto. Meça. Um 3.1x em uma máquina que decodifica a 4 tok/s é um produto diferente de um 3.1x em uma que decodifica a 40.
- Seu prefill. Os loops de agente releem contexto o tempo todo. Ninguém publicou uma cifra de prefill e
llama-bench -pte dá a sua em um minuto. - Se você precisa do vision encoder ou não. São 1.4 GB de memória residente mais sua parte do envelope. Se seu agente nunca vê uma imagem, deixar
mmprojsem carregar te devolve contexto.
E se você estiver em Apple silicon: llama.cpp com Metal funciona hoje, MLX ainda não. Convém saber qual você está esperando antes de planejar em torno de um número.
Se você já executa um modelo local como agente — quanto do seu setup está limitado por tokens por segundo, e quanto pelo modelo simplesmente escolhendo a ferramenta errada? Nos conte o que você está rodando e sobre o quê.