O Meta lançou o Muse Glimmer, um modelo multimodal com cerca de 30 bilhões de parâmetros, que suporta contexto de 128K e pode operar em dispositivos com 24 GB de memória VRAM. O modelo está disponível sob licença Apache 2.0, utiliza GQA para reduzir o uso de KV Cache, combina uma arquitetura híbrida de Attention Local e Global para diminuir o custo computacional de contextos longos e oferece duas versões quantizadas para adaptação a diferentes dispositivos com memória VRAM. O módulo visual inclui um Encoder de Percepção ViT independente para processar capturas de tela e informações de tela; durante o treinamento, foi introduzida a On Policy Distillation para cobrir desvios de estado em tarefas longas. O componente de aceleração de inferência DFlash emprega Block Diffusion para prever tokens em paralelo, alcançando um aumento de cerca de 3 vezes na velocidade de decodificação no RTX 5090. O modelo apresenta excelente desempenho em benchmarks de agentes como MCP Atlas e DeepSearch QA, mas ainda possui espaço para melhoria em cenários puramente GUI, como OSWorld Verified.

Autor e fonte do artigo: Leifeng.com

Ontem, a Meta lançou o Muse Glimmer. Trata-se de um modelo de agente multimodal com cerca de 30 bilhões de parâmetros, que suporta contexto de nível 128K, pode invocar ferramentas, executar código e processar imagens e informações de tela.

Este modelo está disponível sob a licença Apache 2.0, além de duas versões quantizadas de 4-bit, um codificador visual independente e componentes de aceleração de inferência DFlash, com suporte para implantação local via llama.cpp, MLX, ExecuTorch, entre outros.

Embora o tamanho de 30 bilhões de parâmetros e o contexto de 128K pareçam comuns hoje em dia, o problema é que a Meta quer que ele realize algo além de conversas comuns: quer estabelecer um novo paradigma completo para execução local de Agentes.

O Agente Local de longa duração da Muse Glimmer enfrenta restrições de engenharia rigorosas: ele deve processar capturas de tela em constante geração, ao mesmo tempo em que mantém a lógica da tarefa por dezenas de etapas. Após uma tarefa ser executada por dezenas de etapas, os resultados das ferramentas anteriores, logs de código, estados da página e processos de raciocínio continuam acumulados no contexto.

Neste momento, muitos problemas que não eram evidentes em cenários de chat se amplificam rapidamente. Como inserir 128K de contexto em memória gráfica limitada? Como gerenciar o estado histórico à medida que aumentam as capturas de tela? Como o modelo continua após falhas na chamada de ferramentas? E em que grau os grandes volumes de tokens de raciocínio retardam o decode?

O design técnico do Muse Glimmer gira em torno dessas questões. Em vez de depender de uma nova arquitetura particularmente notável para resolver tudo, ele fez escolhas ousadas em Attention, KV Cache, forma de treinamento, quantização e Decode.

Se os modelos locais anteriores eram “capazes de funcionar”, o objetivo do Muse Glimmer é “funcionar tão bem e de forma contínua quanto na nuvem”.

Vendo essas partes juntas, é mais fácil entender por que a Meta a fez do jeito que está agora, em comparação com analisar apenas o 30B ou o 128K.

Como comprimir 128K de contexto em 24 GB de memória GPU

Muse Glimmer utiliza 52 camadas Dense Transformer, tamanho oculto de 6656, com 32 cabeças de consulta, mas apenas 2 cabeças de KV.

Atenção também não processa o contexto completo em cada camada, mas sim utiliza um ciclo de três Attenções Locais seguidas por uma Attenção Global.

A Atenção Local processa apenas os 2048 tokens próximos; a Atenção Global é responsável pela troca de informações em distâncias maiores.

Esses dois designs na verdade aumentam simultaneamente o custo de contextos longos. Ao gerar novos tokens, o modelo armazena em cache as chaves e valores dos tokens anteriores, conhecidos como KV Cache. Quanto mais longo o contexto, maior o espaço ocupado por essa parte.

Muse Glimmer possui apenas 2 KV Heads por camada, com cada Head Dimension de 128. Calculando aproximadamente em BF16, um Token em uma camada ocupa cerca de 1024 Bytes de KV.

Se todas as 52 camadas armazenarem completamente o contexto de 128K, o KV Cache exigirá aproximadamente 6,5 GiB. No entanto, o Muse Glimmer possui na realidade 39 camadas locais e 13 camadas globais. As camadas locais precisam manter apenas uma janela deslizante de cerca de 2048 tokens; apenas as camadas globais precisam armazenar o contexto longo completo.

Usando a mesma estimativa, o KV Cache pode ser reduzido para cerca de 1,7 GiB. Este não é o consumo de memória GPU oficialmente divulgado, mas sim uma estimativa teórica baseada nos parâmetros da arquitetura publicamente disponíveis; no entanto, já é suficiente para explicar por que essa estrutura foi projetada dessa forma.

Se, em vez de usar 2 KV Heads, ele armazenasse KV independentes para todos os 32 Heads, como no MHA tradicional, sob as mesmas condições, o KV Cache teoricamente aumentaria cerca de 16 vezes, chegando diretamente a mais de 20 GiB.

O cache KV isolado já excede um GPU de 24 GB. Aqui, na verdade, foram utilizados dois métodos. O GQA reduz a quantidade de KV que cada token precisa armazenar, enquanto o Local Attention reduz o número de camadas que precisam armazenar permanentemente o KV completo.

Após concluir este passo, a quantização de peso ganha sentido. O peso do Muse Glimmer K Quant 17GB é de aproximadamente 16,8 GB, o módulo visual cerca de 1,4 GB e o DFlash cerca de 1,6 GB; juntos, esses componentes já somam quase 20 GB. Esta versão é voltada para dispositivos com 24 GB de memória VRAM, enquanto outra versão de aproximadamente 20 GB do Dynamic K Quant é destinada a dispositivos com 32 GB.

As duas quantizações não diferem apenas no tamanho do arquivo. Entre as 15 métricas de benchmark fornecidas pelo Meta, a perda média de precisão para o Dynamic K Quant é de cerca de 0,2%, enquanto para o K Quant de 17 GB é de cerca de 1,0%.

Ou seja, a versão de 24 GB reduz ainda mais a memória VRAM, ocupando menos espaço, mas exige aceitar uma perda de desempenho ligeiramente mais perceptível. A versão de 32 GB busca preservar o desempenho original do modelo.

O contexto de 128K do Muse Glimmer é possível com essa combinação. O Attention reduz primeiro a carga computacional, o GQA reduz depois o KV Cache e, por fim, a quantização comprime os pesos do modelo.

Essa abordagem também tem um custo. As 39 camadas Locais só podem acessar diretamente 2048 tokens próximos; informações de longa distância precisam ser propagadas através da camada Global. Portanto, ser capaz de inserir 128K ainda não é o mesmo que conseguir utilizar de forma estável os 128K completos.

Os resultados do Beam128K da Meta mostram que essa estrutura híbrida local e global ainda possui boa capacidade de aproveitamento de informações de longo alcance, mas ela resolve o contexto longo, não a memória de longo prazo. Quais informações devem ser mantidas, quais já estão obsoletas e quando atualizar o estado ainda precisam ser tratados pelo Agent Runtime.

Essa questão fica ainda mais evidente no agente visual.

128K também não é espaço ilimitado

Muse Glimmer também possui um ViT G 14 Perception Encoder com aproximadamente 1,8 bilhão de parâmetros, projetado para processar capturas de tela, páginas da web, gráficos e documentos. Uma imagem pode ser convertida em até 4.096 Visual Tokens.

Atualmente, é entrada de texto e imagem, com saída de texto, e não todos os modos inseridos no mesmo modelo de geração.

Dentro do fluxo de trabalho do Agente, essa capacidade visual é responsável por ler o estado do ambiente. O Agente de Uso do Computador primeiro observa a tela atual, identifica a posição das páginas, botões e textos, e então executa uma ação. Após a mudança na página, ele lê a nova captura de tela e continua decidindo o próximo passo.

Assim, as entradas visuais continuam a entrar no contexto. Se todas as capturas de tela das dezenas de etapas forem mantidas integralmente, mesmo com 128K, o contexto será rapidamente preenchido por tokens visuais. As capturas de tela antigas também podem entrar em conflito com o estado atual. A página já mudou, mas os botões e janelas anteriores ainda permanecem no contexto, e o modelo precisa fazer julgamentos adicionais para determinar qual é o estado mais recente.

Meta também não mantém o histórico de capturas de tela ilimitado na avaliação do OSWorld, mas apenas as capturas mais recentes. Isso indica que o Perception Encoder e o Context Management são dois problemas distintos.

O primeiro é responsável por converter a tela atual em informações que o modelo possa entender, enquanto o segundo deve decidir quais estados históricos ainda têm valor e quais devem ser excluídos. Portanto, 128K parece mais fornecer um espaço de trabalho maior para o Agente, em vez de eliminar o gerenciamento de estado.

E à medida que o agente interage continuamente com o ambiente, a questão passa de o que o modelo viu para o que o modelo acabou de fazer.

Agora entre na parte de treinamento do Muse Glimmer.

Como continuar após o agente desviar-se

Muse Glimmer é destilado a partir do maior Muse Spark.

O Meta divide o treinamento em Pre Training, Mid Training e Post Training. O Pre Training utiliza Logit Distillation, o Mid Training adiciona mais dados de contexto longo, Reasoning Trace e Agent, e o Post Training inclui SFT, On Policy Distillation e RL.

A destilação Logit difere ligeiramente do treinamento comum de um modelo menor usando as respostas de um modelo maior. Quando o Teacher prevê o próximo Token, ele fornece uma distribuição de probabilidade para todo o vocabulário. O Student não apenas aprende o Token final selecionado, mas também vê o julgamento relativo do Teacher sobre outros candidatos.

Isso é útil para o Agente, pois muitos cenários não possuem uma única ação única. Diante de uma página da web, o modelo pode continuar pesquisando, abrir algum resultado ou trocar de ferramenta. A distribuição de probabilidade do Professor incluirá suas preferências em relação a essas ações, e não apenas o texto final produzido.

Na Mid Training, o treinamento passa de respostas individuais para trajetórias completas de tarefas. Após a execução de uma ferramenta, o ambiente muda. A busca retorna novos resultados, a execução de código mal-sucedida gera erros e clicar incorretamente na interface gráfica altera a página. Ou seja, a saída do Agente altera diretamente a entrada para o próximo passo.

Suponha que a trajetória correta do Teacher seja de A para B, depois para C e, finalmente, para D. Se o Student aprender apenas os dados do Teacher, ele verá repetidamente A para B e B para C. Mas, em execução real, o Student pode, na primeira etapa, já ir para outro estado B.

A partir deste momento, o contexto mudou, e o treinamento de B para C no conjunto de treinamento não pode mais dizer diretamente ao modelo como agir agora. A On Policy Distillation atua exatamente aqui. O Student primeiro realiza um Rollout por conta própria, entrando nos estados que realmente produzirá, e depois recebe supervisão de um modelo mais forte nesses estados.

Os dados de treinamento, portanto, não contêm apenas a rota ideal do Professor, mas também começam a cobrir os estados de erro criados pelo Aluno. Isso está ligado à Recuperação de Falhas enfatizada pela Muse Glimmer.

Após preencher incorretamente os parâmetros, se o modelo conseguir entender o erro e realizar uma nova chamada à ferramenta, a tarefa ainda pode prosseguir. Se você errar o caminho na web, desde que consiga identificar que o estado atual está incorreto, também é possível retroceder ou mudar de rota. O verdadeiramente problemático é quando o modelo não percebe o erro e continua executando com base no estado incorreto, permitindo que o desvio se acumule.

Portanto, a capacidade do agente não pode ser avaliada apenas com base em uma única chamada de ferramenta estar correta, mas também em se a tarefa inteira pode ser concluída e se o agente pode se recuperar após erros intermediários. Isso também explica por que o Muse Glimmer se sai melhor em alguns benchmarks de agentes de fluxos longos.

No entanto, o fato de a tarefa ser concluída não significa que não haja mais problemas na execução local. Se uma tarefa complexa gerar um grande número de Tokens de Raciocínio, o novo gargalo rapidamente se tornará o Decode.

Duas perguntas, uma após a outra

Muse Glimmer oferece quatro níveis de Força de Raciocínio: low, medium, high e xhigh. Essa configuração pode ser entendida como orçamento de inferência em tempo de execução.

Níveis mais altos geralmente fazem com que o modelo gere mais tokens de raciocínio, podendo resultar em taxas de sucesso mais altas em tarefas complexas de codificação e agentes, mas o custo é direto: o contexto cresce mais rapidamente e o tempo de decodificação aumenta.

Meta usa high Reasoning Strength no benchmark público. Isso levou ao DFlash.

A decodificação do Transformer é autoregressiva. O segundo token deve esperar pelo primeiro, e o terceiro depende do segundo. Para respostas de centenas de tokens, isso é aceitável, mas uma tarefa única de um agente pode acumular milhares ou até dezenas de milhares de tokens.

A abordagem de Decodificação Especulativa consiste em adicionar um Drafter menor. O Drafter primeiro prevê um trecho futuro de tokens, e então o modelo principal verifica tudo de uma vez. Se múltiplos candidatos puderem ser aceitos consecutivamente, o número de etapas de Decode executadas pelo modelo principal de 30B pode ser reduzido.

O problema com os métodos tradicionais é que o próprio Drafter geralmente também é um modelo autoregressivo. Se ele precisar gerar 16 tokens, ainda assim precisa gerá-los um por um.

DFlash substituiu este trecho por Block Diffusion.

O tamanho do bloco DFlash do Muse Glimmer é 16, permitindo prever em paralelo um conjunto de tokens candidatos. Mas o Drafter não basta ser rápido. Se as previsões forem imprecisas, o modelo principal rejeitará muitos candidatos, e a vantagem de velocidade anterior será rapidamente perdida.

Portanto, o DFlash também lê diretamente os Recursos Ocultos das camadas 1, 13, 25, 37 e 49 do Muse Glimmer e envia essas representações intermediárias ao Drafter, que possui apenas 5 camadas. Assim, o Drafter não precisa recompilar o contexto completo, mas sim aproveitar diretamente as representações internas já formadas pelo modelo principal de 30B.

Esses recursos também não são usados apenas uma vez na entrada, mas são continuamente injetados nas chaves e valores de cada camada do Drafter, evitando que se enfraqueçam à medida que a rede se aprofunda.

Há outro detalhe durante o treinamento. Em um bloco de 16 tokens, os tokens iniciais são mais importantes do que os finais. Se o primeiro token estiver errado, mesmo que os subsequentes sejam adivinhados corretamente, o comprimento da sequência aceita continuamente será muito curto.

Portanto, o DFlash atribui maior Loss Weight aos tokens antes do bloco, reduzindo gradualmente após isso. Ele otimiza o prefixo aceitável mais longo possível, em vez de buscar simplesmente a precisão média nos 16 primeiros posições. Nos dados K Quant de 17 GB fornecidos pela Meta, a velocidade de decode no RTX 5090 aumentou de aproximadamente 74,9 tokens/s para 233,4 tokens/s.

Se uma Tarefa de Agent acumular 10.000 tokens gerados, considerando apenas o Decode, o primeiro leva aproximadamente 134 segundos, enquanto o segundo leva cerca de 43 segundos. Tarefas reais também incluem Prefill, execução de ferramentas e espera de rede, mas para Agents com alta Força de Raciocínio, essa diferença já afeta significativamente a experiência completa da tarefa.

A Força de Raciocínio Alta aumenta a geração de tokens, e o DFlash é responsável por reduzir esse tempo. Contextos longos aumentam o KV Cache, enquanto o GQA e o Local Attention reduzem o uso de memória. A quantização continua a manter os pesos do modelo dentro dos limites suportados por placas de vídeo de consumo.

Além disso, o Muse Glimmer apresentou bom desempenho nos benchmarks de agentes MCP Atlas, DeepSearch QA e Gaia2. Essas tarefas exigem cadeias de execução mais longas.

O MCP Atlas requer que o modelo selecione e invoque ferramentas entre vários servidores MCP. O DeepSearch QA precisa buscar continuamente, abrir páginas, localizar informações e continuar executando com base nos novos resultados. O Gaia2 simula aplicativos com estado, como e-mail, calendário e contatos, e o próprio ambiente muda durante a execução da tarefa.

Essas tarefas são mais alinhadas com o método de treinamento do Muse Glimmer. No entanto, no OSWorld Verified, TerminalBench e SWE Bench Verified, ele não mantém a mesma vantagem. Por exemplo, no OSWorld Verified, o Muse Glimmer obteve 65,9, enquanto o Qwen3.6 27B obteve 75,6. No TerminalBench 2.1, o Muse Glimmer obteve 51,7, enquanto o outro alcançou 60,7.

Sua distribuição de capacidades é, portanto, mais clara. O Research Agent, a cooperação de ferramentas e tarefas de longo fluxo com estado demonstram maior desempenho, enquanto cenários puramente GUI, terminal e parte dos Agentes de Codificação ainda apresentam espaço significativo para melhoria. Esses escores não podem ser totalmente compreendidos conforme as listas tradicionais de modelos.

Os resultados do Agent Benchmark também podem ser afetados pelo System Prompt, Tool Definition, Scaffold, número máximo de passos de execução, parâmetros de amostragem e até mesmo pelo Judge Model. A própria Meta esclarece que as Ferramentas de Agentes e os System Prompts utilizados por modelos de terceiros nem sempre foram otimizados especificamente para eles.

Então, na fase do Agente, comparar apenas o Checkpoint já se torna cada vez mais difícil para indicar a situação completa. A segurança apresenta um problema semelhante.

Executar localmente realmente reduz o envio frequente de arquivos, capturas de tela e Contexto privado para a nuvem, mas isso resolve apenas o caminho dos dados. Injeção de Prompt, chamadas incorretas de Ferramenta, excesso de permissões e operações irreversíveis ainda persistem. O Meta também avaliou separadamente os riscos Agênticos, Privacidade e Injeção de Prompt, e recomenda que, na implantação real, continuem a ser adicionados Guardrails e a presença humana necessária.

Um caminho de habilidades claro

A cadeia completa de tecnologia da Muse Glimmer pode finalmente ser conectada em uma linha bastante clara.

O tamanho do modelo é mantido em torno de 30B, com GQA e Local Attention reduzindo o custo de memória GPU para contexto de 128K; a quantização permite que o modelo seja executado em dispositivos de 24GB e 32GB; o Perception Encoder é responsável por ler o ambiente visual; o On Policy Distillation cobre desvios de estado em tarefas longas; a Reasoning Strength permite aos desenvolvedores controlar o orçamento de raciocínio; o DFlash trata a latência de decodificação causada por grandes quantidades de tokens de raciocínio.

O Muse Glimmer não provou que um modelo local de 30B pode substituir o modelo Frontier na nuvem, mas demonstrou que o fim último de um modelo local de 30B não reside na simples escala, mas na engenharia de sistema que integra hedge para diversas restrições físicas. Ele já incorporou dentro de um único design de sistema as quatro restrições mais difíceis de lidar em Agentes locais: memória de vídeo, contexto, percepção de estado do ambiente e velocidade de inferência.

Muse Glimmer, embora ainda não possa substituir totalmente os modelos de ponta em nuvem, já traçou um caminho viável para implementação industrial rumo ao objetivo de "cada pessoa ter seu próprio agente privado".