Meta libera modelo multimodal de 816 bilhões de parâmetros com pesos abertos

Um modelo gigante, mas com os pesos liberados

A Meta publicou em 15 de outubro de 2026, pelo blog da Hugging Face, os pesos do Muse Spark Open, o maior modelo multimodal de código aberto que a empresa já lançou. Ele é sucessor do Muse Glimmer, um modelo denso menor lançado em agosto de 2026 e pensado para rodar localmente; os dois compartilham tokenizador e vocabulário. "Open-weight" quer dizer que qualquer um pode baixar os parâmetros treinados e rodar o modelo onde quiser, sem depender de uma API fechada da Meta, da OpenAI ou do Google.

O modelo tem cerca de 816 bilhões de parâmetros no total, organizados num formato chamado mixture-of-experts (mistura de especialistas), que ativa só uma fração desse total a cada token gerado. Essa arquitetura é o que separa os dois caminhos do desenvolvedor hoje: pagar por token numa API fechada ou baixar os pesos e arcar com a conta do hardware. O Muse Spark Open empurra a segunda opção para um patamar que só empresas com cluster de GPU conseguem bancar sozinhas, mas também abre espaço para versões comprimidas rodando numa única estação de trabalho, como o próprio post da Hugging Face mostra.

Como a mistura de especialistas economiza computação

O modelo ativa apenas cerca de 42 bilhões de parâmetros por token processado, mesmo tendo 816 bilhões no total. Isso acontece porque cada camada tem um bloco de mistura de especialistas (MoE) com 256 "especialistas" (redes menores), e um roteador escolhe 8 deles para processar cada token. Os especialistas sozinhos respondem por cerca de 97% de todos os parâmetros do modelo.

Isso tem uma consequência prática direta: mesmo rodando só 42 bilhões de parâmetros por token, o servidor precisa ter memória para guardar o modelo inteiro, porque qualquer token pode acionar qualquer combinação de especialistas. A velocidade de inferência é a de um modelo de 42B, mas o requisito de memória é o de um modelo de 816B.

A espinha dorsal de texto tem 62 camadas, dimensão oculta de 8192, 128 cabeças de atenção para consulta e 16 cabeças de chave-valor (grouped-query attention, que reduz o tamanho do cache de atenção). Cada camada normaliza separadamente as consultas e as chaves (QK-norm) e combina entrada e saída por um "portão residual" aprendido, em vez da soma direta usada na maioria dos transformers.

Texto, imagem, áudio e vídeo na mesma janela de um milhão de tokens

O que diferencia o Muse Spark Open de um modelo de texto puro é que ele aceita quatro tipos de entrada, texto, imagem, áudio e vídeo, todos convertidos para a mesma sequência de tokens que o modelo de linguagem processa. A saída continua sendo só texto. Um encoder de percepção (1,8 bilhão de parâmetros, 50 camadas, dimensão oculta de 1536) transforma imagens e quadros de vídeo em tokens, dividindo cada imagem em patches de 14x14 pixels. Um encoder de áudio separado converte o som em um token a cada 80 milissegundos, o que dá 12,5 tokens por segundo (um áudio de 10 segundos vira 125 tokens de entrada).

A janela de contexto chega a 1.048.576 tokens, e imagem, vídeo e áudio entram nessa mesma contagem. Isso tem custo de memória real: segundo as contas publicadas no post, cada token de contexto adiciona 126.976 valores ao cache de atenção (KV cache), o que dá cerca de 250 KB por token em BF16, ou aproximadamente 266 GB de cache só para preencher o milhão de tokens inteiro. Usar a janela cheia de contexto multiplica a conta de memória do servidor, independente do tamanho do modelo em si.

Rodar esse modelo tem preço de hardware, não só de token

Modelos fechados cobram por chamada ou por token processado. O Muse Spark Open não tem preço de API porque não é um serviço, é um arquivo para baixar, e o preço vira a infraestrutura que o desenvolvedor precisa montar. Segundo a Hugging Face, o checkpoint em BF16 ocupa cerca de 1,5 TB em disco e precisa de 4 nós com 8 GPUs H200 cada (32 GPUs no total, com paralelismo de tensor TP=32) para rodar via transformers. A versão NVFP4, com os parâmetros em 4 bits e "perda de precisão desprezível" segundo o fabricante, roda num único nó com GPUs B200 da NVIDIA.

Para quem não tem acesso a um cluster desses, o caminho é a quantização via llama.cpp. A equipe da Hugging Face testou o modelo quantizado em 2 bits (com calibração por imatrix) rodando num Mac M3 Ultra com 512 GB de memória unificada: o resultado medido foi 18 tokens por segundo, usando 304 GB de memória só para os pesos, sobrando espaço para o cache de atenção.

É um número relevante, medido por quem escreveu o post e não pela Meta, porque mostra que dá para ter esse modelo numa estação de trabalho em vez de um data center inteiro, desde que se aceite a perda de qualidade da quantização agressiva.

Para subir o servidor localmente:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q2_K

O comando baixa o checkpoint quantizado em 2 bits e sobe um servidor compatível com a API da OpenAI em localhost:8080, com interface web em localhost:9931 para testar texto, imagem e áudio.

Como chamar o modelo com transformers

A integração oficial usa duas classes novas: MuseSparkForConditionalGeneration para gerar texto a partir de entradas multimodais, e MuseSparkProcessor para preparar tokenizador, processador de imagem e vídeo, extrator de áudio e o template de chat, tudo junto. Para rodar em múltiplas GPUs, o DistributedConfig define quantos dispositivos ficam responsáveis pelas camadas densas (tp_size) e quantos ficam responsáveis por distribuir os especialistas do MoE (ep_size):

import os
from transformers import AutoModelForMultimodalLM, AutoTokenizer, DistributedConfig

distributed_config = DistributedConfig(
    tp_size=int(os.environ["WORLD_SIZE"]),
    ep_size=int(os.environ["WORLD_SIZE"]),
)

tokenizer = AutoTokenizer.from_pretrained("meta-models/Muse-Spark-Open-816B-A42B")
model = AutoModelForMultimodalLM.from_pretrained(
    "meta-models/Muse-Spark-Open-816B-A42B",
    distributed_config=distributed_config,
)

Um detalhe que muda o custo em tokens de cada chamada: o modelo tem um controle de "esforço de raciocínio" (reasoning_effort), com quatro níveis (low, medium, high, xhigh), que mapeiam internamente para os valores 16, 64, 256 e 512. Diferente de outros modelos de raciocínio, aqui não dá para desligar o raciocínio completamente: a Hugging Face recomenda manter em low para tarefas simples, justamente para gastar menos tokens e menos tempo de GPU em perguntas fáceis.

Chamada de ferramentas segue o padrão Harmony

O Muse Spark Open usa um template de chat baseado em canais chamado Harmony, o mesmo formato introduzido antes pelo gpt-oss. Na prática isso significa que a resposta do modelo é roteada para destinatários diferentes dentro da conversa: self para o raciocínio interno, commentary para comentários visíveis entre chamadas de ferramenta, e user para a resposta final que o usuário lê.

Quando o modelo decide chamar uma ferramenta, ele marca isso no cabeçalho da mensagem (to=weather.get, por exemplo) e empacota os argumentos num bloco de invocação de função. Isso facilita decidir, no código do agente, o que mostrar ao usuário final e o que é só raciocínio interno que não deveria aparecer na tela.

Quando faz sentido escolher pesos abertos no lugar de uma API

A proposta do Muse Spark Open, segundo a Hugging Face, é ser um modelo otimizado para codificação, treinado em fluxos reais de desenvolvedor: refatorações em múltiplos arquivos, sessões longas de debug e navegação na web com imagens. Para quem já roda infraestrutura de GPU própria ou tem orçamento de nuvem para clusters H200/B200, pesos abertos tiram a dependência de uma API de terceiro e dão controle total sobre dados, versão do modelo e custo marginal por token, que vira custo de eletricidade e depreciação de hardware em vez de fatura por chamada.

Para quem não tem esse orçamento, a conta muda. Rodar a versão completa em BF16 exige 32 GPUs H200, e mesmo a versão quantizada em 2 bits via llama.cpp pede 512 GB de memória unificada e entrega 18 tokens por segundo, velocidade perceptivelmente mais lenta do que a maioria das APIs fechadas entrega hoje.

Nesse caso, pagar por token numa API fechada ainda compensa mais do que montar e manter essa infraestrutura, a menos que o volume de uso e a exigência de manter os dados dentro de casa justifiquem o investimento. O Muse Spark Open mostra para onde os modelos abertos estão indo, mas segue sendo um modelo para quem já tem, ou está disposto a montar, uma operação de infraestrutura séria.

Fonte: Hugging Face Blog