Rodar Meta Muse Glimmer 30B numa VPS

Requisitos do Muse Glimmer numa VPS

O Muse Glimmer é executado numa VPS Linux comum, sem GPU, e a tag que descarregar determina se cabe na memória. A Meta Superintelligence Labs publicou o modelo em 10 August 2026 sob a licença Apache 2.0: 30 billion parameters, uma janela de contexto de 128K e um encoder de perceção dedicado com 1.8B parâmetros, para poder interpretar imagens e texto. A Meta posiciona-o para agentes locais sempre ativos, não para chat, com uma capacidade de raciocínio definida por pedido.

As tags publicadas do Ollama, consultadas em 16 August 2026, vão de 17 GB a 59 GB. Esse intervalo define todo o problema de dimensionamento. A tag predefinida aparece listada com cerca de 18 GB, pelo que a menor máquina razoável precisa claramente de mais de 18 GB de RAM livre. O espaço em disco para a transferência e a memória para a janela de contexto são adicionais.

Qual tag muse-glimmer você deve baixar?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama listou 11 tags para este modelo que não são builds para Apple. Elas contêm os mesmos 30 billion weights armazenados com diferentes precisões numéricas. O tamanho indicado é o que você baixa e também corresponde aproximadamente ao que precisa manter na memória antes de adicionar qualquer contexto.

Os dois builds de 4-bit são os menores: 30b-nvfp4, com 17 GB, e 30b-q4_K_M, com 18 GB. A tag padrão 30b aparece com o mesmo tamanho do build q4_K_M. Os builds de 8-bit, 30b-q8_0 e 30b-mxfp8, ficam perto de 31 GB. 30b-bf16 é o release de 16-bit sem quantização, com 57 GB. Isso exige mais RAM do que a maioria dos servidores alugados oferece a um preço aceitável para um projeto paralelo.

As tags -dflash correspondem aos mesmos builds com suporte a DFlash, e cada uma aparece com tamanho maior que o respetivo build normal. O Ollama descreve o DFlash como um recurso de velocidade e demonstra-o em Apple Silicon e em GPUs de desktop. Numa VPS com apenas CPU, você pagaria esse tamanho adicional em memória real por um recurso medido em outro hardware. Por isso, comece com a tag normal e altere uma coisa de cada vez.

Comece com 4-bit, a menos que tenha um motivo específico para não o fazer. Passar de 4-bit para 8-bit aproximadamente duplica os bytes que a CPU precisa de ler para cada token gerado. O throughput cai e o uso de memória aumenta. Essa troca é explicada em o custo real da quantização q4, q8 e fp16 e, num servidor com CPU, a resposta curta é que o build de 4-bit é o único ponto de partida recomendado.

Por que as tags MLX não fazem nada num servidor Linux

MLX é o framework de arrays da Apple, e o mecanismo MLX do Ollama é o backend para Apple Silicon. Qualquer tag que contenha mlx no nome foi criada para esse mecanismo e para esse hardware. Num VPS Linux x86, trata-se de dezenas de gigabytes de downloads que não pode executar e que ficarão no disco sem fazer nada. Os valores de velocidade do anúncio, medidos num Mac, aplicam-se a essas tags e também não descrevem o seu servidor. Ao consultar a lista de tags na página do modelo, filtre primeiro todos os nomes mlx e só depois avalie o tamanho das restantes.

De quanta RAM e espaço em disco precisa realmente?

Duas coisas consomem memória, e apenas uma delas corresponde ao tamanho da tag. Os pesos são fixos de acordo com a tag que obtém. A cache KV, o estado por token que o modelo mantém para a conversa, aumenta com o tamanho do contexto configurado. A documentação do Ollama indica que servir pedidos em paralelo multiplica o contexto pelo número de pedidos em processamento. Assim, um servidor que responde a dois agentes em simultâneo precisa de mais memória do que o mesmo servidor a responder a um só.

Não use um valor de RAM de nenhum guia, incluindo este. Obtenha a tag, envie-lhe um prompt e, enquanto o modelo ainda estiver residente, execute estes dois comandos.

ollama ps
free -h

ollama ps mostra o que está carregado neste momento e como o trabalho está dividido entre a CPU e a GPU. free -h mostra o que ainda está disponível. Estes dois resultados no seu próprio servidor são mais úteis do que qualquer tabela publicada, porque já incluem a configuração do contexto, a quantização e tudo o que o servidor está a executar.

O disco é a parte mais simples. O Ollama armazena os modelos em /usr/share/ollama/.ollama/models no Linux, normalmente no sistema de ficheiros raiz da maioria das imagens de VPS. Um volume raiz de 40GB não terá espaço para a compilação bf16 com 57 GB, nem para duas tags de 8 bits lado a lado. Se nunca verificou o que um pull realmente grava, onde o Ollama armazena os modelos e como mover esse diretório explica esse diretório. Mova o armazenamento para um volume montado antes de obter qualquer modelo.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

O utilizador ollama deve ser o proprietário desse diretório, porque o serviço é executado como ollama e grava os blobs nesse local com essa própria conta. Se um pull falhar por causa de permissões, journalctl -u ollama -n 50 mostra o motivo.

É necessário deixar uma afirmação clara sobre a swap: a swap não permite executar uma tag maior. A geração acede aos pesos para cada token produzido. Por isso, os pesos armazenados na swap são lidos repetidamente do disco, vmstat 1 mostra as colunas si e so ocupadas, e a saída abranda para segundos por token. Mantenha um ficheiro de swap pequeno como proteção contra o OOM killer. Dimensione a RAM para a tag que pretende realmente utilizar.

Instalar o Ollama e fixar uma tag nominal

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

O script de instalação configura um serviço systemd, por isso o servidor volta a iniciar depois de um reboot. Se preferir não executar o Ollama como um serviço de sistema gerido pelo root, executar o Ollama sem root com Podman descreve esse procedimento. Em seguida, faça pull de uma tag explícita.

ollama pull muse-glimmer:30b
ollama list

Leia a coluna de tamanho em ollama list e compare-a com a lista atual de tags na página do modelo. As tags publicadas são adicionadas, renomeadas e removidas, e o tamanho indicado num guia é apenas um retrato de um dia.

Nunca escreva ollama pull muse-glimmer num servidor do qual dependa. Um nome de modelo sem tag resolve para a tag latest, e latest é um ponteiro que o publicador pode mover para uma build diferente. Um pull de rotina substitui então o modelo usado pelo seu agente, com necessidades de memória e comportamento diferentes, sem que nada nos logs anuncie essa alteração. Escreva a tag nos seus scripts, nos ficheiros de unidade e na configuração do agente. Alojar um LLM no próprio servidor com Ollama numa VPS descreve o restante da configuração do servidor.

É possível executar o Muse Glimmer sem uma GPU?

Sim, mas é importante deixar claro o limite. Gerar um token significa ler os pesos do modelo a partir da memória. Por isso, a velocidade depende mais da largura de banda da memória do que do número de vCPUs anunciado pelo plano. Depois de alguns cores, adicionar mais cores traz poucos benefícios. Num VPS partilhado, essa largura de banda é partilhada com todos os outros tenants no host. Por isso, um modelo 30B a 4-bit produz um número reduzido de tokens por segundo.

Não aceite o número de outra pessoa para isso, incluindo o meu. Meça os tokens por segundo no seu próprio servidor e decida com base no resultado.

Isto cria uma diferença clara no tipo de tarefas para as quais o modelo é adequado. O chat interativo é penoso, porque lê mais depressa do que o servidor escreve e cada resposta começa com uma espera longa. O trabalho de agentes em background funciona bem, porque uma tarefa executada sem supervisão durante dez minutos não é afetada pela lentidão. Essa segunda carga de trabalho corresponde exatamente ao uso que a Meta descreve para este modelo.

Se precisa de velocidade interativa, há duas respostas honestas: uma GPU ou uma API alojada. Calcule o ponto de equilíbrio entre um VPS com GPU e os tokens da API antes de alugar qualquer recurso, e o que um VPS com GPU oferece realmente explica o que está a comprar. Para a questão mais ampla sobre o que um determinado servidor consegue suportar, comece por quais modelos pode alojar localmente, e executar um modelo Qwen de tamanho semelhante num VPS é a comparação mais próxima nesta classe de tamanho. Se os valores medidos forem demasiado lentos para serem aceitáveis, Nemotron 3.5 Lightning num VPS coloca as mesmas questões sobre RAM e tokens por segundo para um modelo criado para dar prioridade à velocidade em vez do tamanho.

Por que ele esquece informações muito antes de atingir 128K tokens?

Isso acontece porque o tamanho padrão da janela de contexto do Ollama é de 4096 tokens, independentemente do que o modelo suporta. Esse valor padrão aparece na própria FAQ do Ollama em agosto de 2026. A tag anuncia 128K, mas o servidor fornece 4096 ao modelo até que você defina outro valor. Por isso, uma transcrição longa de um agente perde as primeiras interações, e o modelo parece ter amnésia.

Aumente esse valor no servidor para todos os pedidos:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Dentro de uma sessão interativa, /set parameter num_ctx 32768 altera o valor apenas para essa sessão. Pela API, envie num_ctx nas opções do pedido.

Cada token adicional de contexto consome memória além da memória ocupada pelos pesos. Se você solicitar os 128K completos num servidor dimensionado apenas para os pesos, o carregamento poderá falhar ou usar uma alternativa mais lenta. Aumente o valor em etapas e execute ollama ps depois de cada etapa. Como funcionam num_ctx e o tamanho do contexto no Ollama explica os cálculos.

Intensidade do raciocínio: baixa, média, alta e xhigh

A documentação da Meta define quatro intensidades de raciocínio para o Muse Glimmer, de baixa a xhigh, e recomenda as duas mais altas para tarefas complexas de programação e de agentes. No Ollama, isto é controlado pelo parâmetro think. Use --think= na linha de comandos ou envie think no corpo da API.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

Numa sessão interativa, /set think e /set nothink alternam esta opção. A documentação do Ollama indica que a maioria dos modelos aceita um booleano ou um nível, como low, medium ou high, e que alguns aceitam max para o nível mais alto disponível. As strings exatas aceites por este modelo estão na respetiva página do modelo. Consulte essa página em vez de adivinhar e teste manualmente uma opção antes de a integrar num agente.

Num sistema apenas com CPU, esta definição tem um impacto significativo. Uma intensidade mais alta gera mais tokens de raciocínio antes de aparecer a primeira palavra da resposta, e cada token de raciocínio consome o mesmo tempo de relógio que um token da resposta. Deixe o trabalho rotineiro na definição low. O comprimento da resposta também requer atenção. Por isso, limite a resposta com num_predict em vez de deixar uma resposta demasiado longa manter um sistema lento ocupado durante vários minutos.

Mantenha o modelo carregado para um agente sempre ativo

Por padrão, o Ollama descarrega um modelo inativo após cinco minutos. Para um agente executado a cada dez minutos, isso significa carregar novamente 18 GB do disco em cada execução. Numa VPS com armazenamento ligado pela rede, esse carregamento não é rápido. Mantenha o modelo na memória.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Um valor negativo mantém o modelo residente até que algo o descarregue, e keep_alive num pedido à API substitui o valor predefinido do servidor apenas nessa chamada. O custo é direto: a RAM permanece ocupada enquanto nada acontece. Por isso, esta opção deve ser usada num sistema dedicado ao agente. Manter um modelo Ollama carregado explica as variações.

Aponte um agente de programação para ele

Ollama disponibiliza uma API compatível com OpenAI em http://127.0.0.1:11434/v1, por isso a maioria das ferramentas de agentes liga-se usando um URL base e qualquer chave de API não vazia. A página Muse Glimmer do Ollama também documenta um atalho de inicialização que liga um agente compatível a um modelo local com um único comando. Nesse comando, fixe também a tag.

ollama launch claude --model muse-glimmer:30b

Os agentes enviam prompts grandes. O conteúdo dos ficheiros, a saída das ferramentas e uma transcrição que cresce chegam todos como tokens de entrada. Num sistema com CPU, o processamento do prompt é a parte mais pesada, antes de a geração sequer começar. Mantenha a definição de contexto tão pequena quanto a tarefa permitir. Apontar um agente de programação para Ollama aborda o lado do cliente, executar um agente de programação numa VPS aborda o sistema onde ele é executado e controlar os custos de um agente numa VPS aborda o que acontece quando ele funciona o dia inteiro.

A entrada de imagens funciona da mesma forma. A API do Ollama recebe imagens no campo images de uma mensagem. Por isso, um cliente que aceite apenas texto nunca enviará uma imagem, por mais competente que seja o codificador de perceção.

Não abra a porta 11434

A API do Ollama não tem autenticação. Definir OLLAMA_HOST=0.0.0.0:11434 para lhe permitir aceder a partir do seu portátil coloca um executor de modelos sem autenticação na Internet pública. Qualquer pessoa que o encontre pode carregar modelos para o seu disco e ler tudo o que o seu agente lhe enviar. Mantenha-o associado a localhost e use um túnel.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Proteção do endpoint da API do Ollama apresenta as opções adequadas, incluindo um reverse proxy que solicita credenciais.

O que falha e o que verá

A transferência para a meio. Problema de disco. Execute df -h no diretório do modelo. Uma compilação bf16 de 57 GB não cabe num volume root de 40GB. Duas tags de 8 bits lado a lado também não cabem.

O modelo carrega e o processo termina. Falta de memória. dmesg -T regista o OOM killer do kernel a escolher um processo, e journalctl -u ollama -n 100 mostra o mesmo evento no serviço. A correção é usar uma tag menor ou um num_ctx menor. Aumentar o swap não resolve.

O serviço funciona a segundos por token. Execute vmstat 1 e observe as colunas si e so. Atividade contínua de swap significa que os pesos não cabem na RAM. O sistema está a lê-los novamente do disco enquanto trabalha.

Uma tag que funcionava na semana passada desapareceu. As listas de tags mudam. Consulte novamente a página do modelo, fixe a tag atual e registe o nome num local que voltará a consultar.

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

Quanta RAM o Muse Glimmer precisa numa VPS?

Comece pelo tamanho da tag e acrescente a janela de contexto. A tag predefinida está listada com cerca de 18 GB em 16 August 2026, pelo que uma máquina com 16GB não a consegue alojar e uma máquina com 24GB fica com pouco espaço para o contexto. Considere isto um ponto de partida, não uma resposta definitiva. Faça pull da tag, carregue-a uma vez e execute ollama ps e free -h na sua própria máquina para consultar os seus valores. Um contexto mais longo e pedidos paralelos também acrescentam consumo de memória aos pesos.

Posso executar o Muse Glimmer sem uma GPU?

Sim. O modelo carrega e responde apenas com CPU numa VPS. A velocidade de geração é limitada pela largura de banda da memória, não pelo número de cores. Num host partilhado, essa largura de banda é partilhada, pelo que deve esperar poucos tokens por segundo em 4-bit. Isto é utilizável para trabalho de agentes em segundo plano que executa sem supervisão, mas é lento para conversação interativa. Execute ollama ps durante um pedido e consulte a coluna do processador para confirmar onde o trabalho está a ser executado.

As tags MLX são úteis numa VPS Linux?

Não. Todas as tags que contêm mlx no nome foram compiladas para o motor MLX do Ollama, que é o seu backend para Apple Silicon. Num servidor Linux x86, essas tags são um download grande que não pode ser executado. Use a tag 30b simples ou uma das outras tags que não sejam MLX. Ignore os benchmarks do hardware Apple associados às compilações MLX.

Porque é que o modelo se esquece de informações muito antes dos 128K tokens?

Porque a janela de contexto predefinida do Ollama é de 4096 tokens, independentemente do que o modelo suporta. Assim, o servidor trunca as conversações longas antes de o modelo as receber. Defina OLLAMA_CONTEXT_LENGTH no servidor, /set parameter num_ctx para uma sessão ou envie num_ctx nas opções do pedido à API. O consumo de memória aumenta com esse valor. Aumente-o gradualmente e verifique ollama ps de cada vez.

Devo fixar a tag ou usar simplesmente latest?

Fixe-a. muse-glimmer sem uma tag resolve para latest. Este é um ponteiro que o publisher pode mover para outra compilação a qualquer momento. Por isso, um pull normal pode alterar o modelo executado pelo seu agente. Escreva muse-glimmer:30b nos scripts, ficheiros de unidade e configuração do agente. Consulte a lista de tags na página do modelo antes de fixar uma tag, porque as tags publicadas podem mudar.