O Muse Spark Open da Meta precisa de cerca de um terabyte de memória. Baixar os pesos é a parte fácil

O showcase da Meta para seu novo modelo de pesos abertos são dois Apple M5 Ultra Mac Studios, cada um com até 512 GB de memória unificada, conectados para funcionar como uma única máquina com cerca de um terabyte. Nessa configuração, o agente de codificação da Meta fez alterações no iOS em um cliente Mastodon de código aberto e comandou um editor de vídeo quadro a quadro. É uma boa demonstração, e uma dica honesta sobre escala: a menor coisa que a Meta escolheu para mostrar o modelo rodando é um terabyte de memória rápida.

O Muse Spark Open, lançado em 15 de outubro, é um modelo multimodal de mistura de especialistas com 816 bilhões de parâmetros totais, 42 bilhões ativos por token e uma janela de contexto de até um milhão de tokens. A Meta o construiu para codificação, uso de ferramentas e trabalho de agente de longa duração. Os pesos estão no Hugging Face e nos catálogos de modelos do Amazon SageMaker AI, Google Cloud Model Garden e Microsoft Foundry. Inferência hospedada é oferecida por Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter e Together AI, e o modelo roda nos motores de inferência comuns, de vLLM e SGLang a MLX e llama.cpp.

Para uma empresa, o lançamento adiciona uma opção séria. Também adiciona uma decisão que é fácil de tomar pelo motivo errado.

Esparso não é pequeno

A mistura de especialistas torna cada token mais barato de computar, porque apenas 42 bilhões de parâmetros estão ativos. Isso não torna o modelo pequeno para armazenar. Todos os 816 bilhões de parâmetros precisam ficar na memória de qualquer coisa que o sirva, e um contexto longo aumenta isso. A página da Meta não informa hardware mínimo ou formatos quantizados oficiais, então a primeira tarefa de engenharia é estabelecer o que realmente é necessário para servir o modelo na latência e concorrência que você precisa, em hardware que você consegue obter.

As alegações de desempenho da Meta são dela. A página chama o Muse Spark Open de modelo de pesos abertos mais capaz dos EUA até hoje; os números quantificados que ela fornece são ganhos de velocidade em nível de kernel, não resultados de tarefas como as suas. Uma janela de um milhão de tokens é uma capacidade, não evidência de que o raciocínio se mantém ao longo dela.

Quatro perguntas antes de executá-lo

1. A licença se encaixa no seu uso? O Muse Spark Open é distribuído sob a Muse Model License, que a Meta descreve como tendo “termos comerciais limitados, que permitem que muitos desenvolvedores usem o modelo gratuitamente.” Pesos abertos não são código aberto. Antes que um engenheiro baixe qualquer coisa, o jurídico deve ler os termos para limites comerciais, redistribuição, uso dentro de um serviço que você oferece a clientes, atribuição e usos restritos.

2. Que problema os pesos resolvem? As boas razões para manter pesos são custódia (código e prompts nunca saem da infraestrutura que você controla), customização (fine-tuning na sua própria base de código e convenções) e custo previsível em alto volume constante. “Evitar lock-in de fornecedor” sozinho é fraco, porque os provedores hospedados acima já lhe dão isso com o mesmo modelo.

3. Você consegue mantê-lo ocupado? Auto-hospedagem compensa quando o hardware é usado. Vimos um H100 alugado render quatro vezes seu custo em uma manhã movimentada e perder dinheiro ao longo da semana. Um modelo desse tamanho aumenta as apostas: capacidade ociosa é capacidade cara. Precifique por tarefa concluída ao longo das horas que você paga, não por token no pico.

4. Quem o opera? Rodar um modelo em escala de fronteira significa aplicar patches na stack de serving, monitorar desvio de qualidade, lidar com incidentes de capacidade e avaliar cada novo lançamento antes que ele substitua o antigo. Como escrevemos quando a Reflection lançou o Beam, com pesos abertos o dever de operação passa para você. Esse dever é o preço real da custódia.

Três maneiras de mantê-lo

Os mesmos pesos agora vêm com três modelos de operação, e eles não são equivalentes:

• Uma API hospedada de um dos provedores de inferência: sem hardware, mas seus prompts e código vão para esse provedor, sob seus termos e suas regiões.
• Um deploy gerenciado na sua nuvem, através do SageMaker AI, Model Garden ou Foundry: sua conta, seu limite de rede, sua conta de capacidade, com a nuvem cuidando de grande parte do serving.
• Seu próprio hardware: custódia máxima, ônus operacional máximo.

Muitas empresas começarão com a primeira para avaliar a qualidade em seus próprios repositórios, e só migrarão para a segunda ou terceira se a avaliação e o volume justificarem. Essa é a sequência que sugerimos para o Mistral Large 4, e ela vale aqui.

O que o lançamento muda

A mudança prática está na negociação e na arquitetura, não em qualquer deploy único. Um modelo de codificação classe fronteira com pesos abertos dá às empresas uma alternativa crível às APIs fechadas para agentes de codificação, o que importa na renovação de contrato mesmo que você nunca faça auto-hospedagem. Também torna a camada de modelo mais substituível, o que aumenta o valor das partes que não são: seus conjuntos de avaliação, sua política de roteamento e o contexto a partir do qual seus agentes trabalham.

Comece pela avaliação. Rode o Muse Spark Open contra as tarefas que seus agentes de codificação já fazem, através de um endpoint hospedado, e compare o custo por mudança aceita com o que você usa hoje. Se ele não vencer aí, a pergunta sobre hardware nunca precisa de resposta.