GLM 5.2 no Ollama cabe em uma VPS?

É possível executar o GLM 5.2 numa VPS?

Não. Vale a pena conhecer o motivo antes de contratar qualquer serviço. Em 18 August 2026, o GLM 5.2 na biblioteca do Ollama tem exatamente uma tag, glm-5.2:cloud. Uma tag :cloud é executada nos servidores do Ollama. O seu servidor envia o prompt e recebe os tokens, portanto os pesos nunca são gravados no disco. O modelo tem 756 billion parameters. Quatro bits por parâmetro em 756 billion parameters correspondem a aproximadamente 378 GB de pesos. Isto é apenas a aritmética básica, sem contar o contexto, as ativações ou o sistema operativo. Nenhum plano normal de VPS disponibiliza tanta memória.

O modelo GLM que cabe num servidor contratado é glm-4.7-flash. É publicado com pesos transferíveis em 4 tags. É um modelo mixture-of-experts. Isso significa que apenas uma pequena parte da rede é executada para cada token. A Z.ai descreve-o como 30B-A3B: 30 billion parameters no total e cerca de 3 billion ativos por token. Por isso, este guia responde à pergunta que pode aplicar na prática. Fixe uma tag, dimensione o servidor, meça a velocidade no seu próprio ambiente e mantenha o endpoint privado.

Verifique a tag antes de copiar qualquer comando, incluindo os deste guia. A biblioteca do Ollama muda sem aviso. Abra a lista de tags do glm-4.7-flash e confirme que a tag ainda existe. Se tiver surgido uma versão mais recente do GLM com pesos locais, prefira-a e registe qual tag testou.

Se ainda quiser utilizar o próprio GLM 5.2, ollama run glm-5.2:cloud funciona depois de ollama signin e, do lado do cliente, comporta-se como qualquer outro modelo do Ollama. Tenha em conta o que está a aceitar: o prompt sai do seu servidor. Se o motivo para alojar o modelo por conta própria é manter os dados na sua máquina, uma tag :cloud não cumpre esse objetivo.

Que tags do GLM existem e qual deve fixar

Há três entradas oficiais do GLM relevantes neste caso. glm-5.2 e glm-5.1 são apenas para a cloud. glm-4.7-flash é a versão local, e estes são os respetivos tags publicados, com o tamanho de download indicado pelo Ollama para cada um.

[
  {
    "label": "q4_K_M",
    "download_gb": 19
  },
  {
    "label": "latest",
    "download_gb": 19
  },
  {
    "label": "q8_0",
    "download_gb": 32
  },
  {
    "label": "bf16",
    "download_gb": 60
  }
]

Estes são valores publicados na página da biblioteca, não medições. latest e q4_K_M aparecem ambos listados com 19 GB, pelo que latest resolve atualmente para a compilação Q4. Isto pode mudar a qualquer nova publicação. Por isso, nunca escreva um ollama pull glm-4.7-flash sem quantização especificada num script ou Dockerfile. Indique a quantização. O maior tag, bf16, é um download de 60 GB que contém os pesos bfloat16 não quantizados.

Uma pesquisa na biblioteca também devolve uploads com namespace e uma barra no nome, como someuser/glm-5.2. Uma barra indica que foi publicado por uma conta de utilizador. Portanto, trata-se de um reupload da comunidade, não da entrada oficial. Ninguém garante quais são os pesos incluídos. Trate-o como trataria qualquer binário não assinado encontrado online.

Instale o Ollama e descarregue a tag exata

O instalador Linux do Ollama é executado com um comando.

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

O instalador cria um serviço systemd executado pelo utilizador ollama. Confirme que o serviço arrancou antes de descarregar qualquer conteúdo.

systemctl status ollama --no-pager

Active: active (running) significa que a API está a escutar na porta 11434. Se a unidade não existir, o instalador recorreu a uma instalação simples do binário. A documentação do Ollama para Linux fornece o ficheiro de serviço para criar manualmente.

A página glm-4.7-flash indica uma versão mínima do Ollama. Um binário antigo não executa o modelo mais lentamente. Recusa-o. O pull falha com uma mensagem a indicar que o modelo requer uma versão mais recente do Ollama. Execute novamente o script de instalação para atualizar. Em 18 August 2026, a versão atual é 0.32.14, que está muito acima desse mínimo.

Agora descarregue uma tag pelo nome.

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls deve listar glm-4.7-flash:q4_K_M com um tamanho próximo dos 19 GB publicados. Um pull que falha a meio não deixa nada executável. Execute novamente o mesmo comando. A causa mais comum de um pull falhado num plano pequeno é o disco cheio, não um problema de rede, porque o modelo é gravado em /usr/share/ollama/.ollama/models no sistema de ficheiros raiz. Verifique com df -h /usr/share/ollama antes de começar.

Quanto de RAM cada quantização precisa?

Comece pelo tamanho do download como limite mínimo e acrescente o restante. Os pesos precisam permanecer na memória. Sobre eles fica o cache KV (cache de chave/valor), que é a memória usada pelo runtime para guardar os tokens já presentes na conversa, além dos buffers de computação e do que o sistema operativo estiver a utilizar. Uma máquina com exatamente 19 GB de RAM não executará a tag de 19 GB.

Não existe um multiplicador único que seja correto para todos, porque o cache KV cresce com o tamanho de contexto permitido e o restante varia entre versões do runtime. Por isso, faça medições em vez de estimativas. Carregue o modelo com um prompt trivial e leia o que o servidor reservou.

ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama ps

ollama ps imprime o modelo carregado com uma coluna SIZE e uma coluna PROCESSOR. SIZE é o que o runtime reservou efetivamente, e esse é o valor que deve comparar com o seu plano. PROCESSOR informa onde o trabalho é executado, portanto 100% CPU significa que nenhuma GPU foi utilizada.

Quando o modelo não cabe, a falha é silenciosa e ocorre de duas formas. Com o swap ativado, o carregamento parece ser concluído, mas a geração fica extremamente lenta, porque as páginas são movidas entre o disco e a RAM a cada token. Sem swap, o processo é encerrado imediatamente, e journalctl -k | grep -i "out of memory" mostra a linha Out of memory: Killed process do kernel que identifica ollama. Verifique ambos, porque nenhum deles exibe uma mensagem útil no terminal onde estava a escrever.

A passagem da tag Q4 de 19 GB para a tag Q8 de 32 GB é o principal fator que pode controlar esse valor. Q4 reduz um pouco a qualidade da saída, e o impacto depende da tarefa: a saída estruturada e as cadeias longas de raciocínio sofrem mais do que uma conversa casual. Vale a pena ler Como Q4, Q8 e FP16 diferem na prática antes de decidir, porque, num VPS apenas com CPU, a escolha da quantização normalmente determina se o modelo será executado.

O que acontece numa VPS apenas com CPU

A maioria dos planos de VPS não inclui GPU, e o Ollama executa o modelo na CPU sem apresentar um aviso. A utilidade do resultado depende da carga de trabalho e da sua paciência.

A arquitetura de mistura de especialistas ajuda na velocidade. Apenas cerca de 3 bilhões dos 30 bilhões de parâmetros são usados para cada token, portanto, a quantidade de cálculos por token é muito menor do que a necessária para um modelo denso de 30B. O que não diminui é a memória. Todos os especialistas precisam permanecer residentes, porque o roteador pode selecionar qualquer um deles para o token seguinte. Por isso, uma máquina apenas com CPU ainda precisa de todos os 19 GB ou mais da tag Q4, e o throughput é determinado principalmente pela largura de banda da memória, não pela velocidade do clock.

Isso tem uma consequência prática: dois planos com a mesma quantidade de cores e a mesma RAM podem gerar tokens a velocidades significativamente diferentes porque os subsistemas de memória são diferentes. Um plano partilhado acrescenta uma segunda variável, pois o tempo de espera da CPU causado por um vizinho ruidoso aparece como uma taxa de tokens por segundo que muda de hora para hora. É por isso que o número publicado por outra pessoa não prevê o seu resultado e que a secção seguinte apresenta um procedimento de medição, não uma tabela de resultados.

Meça os seus próprios tokens por segundo

O endpoint generate do Ollama devolve campos de temporização no objeto JSON final. Divida a quantidade de tokens gerados pela duração da geração para obter o seu valor, no seu plano e com o seu prompt.

sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash:q4_K_M",
  "prompt": "Write a 200 word explanation of how TCP congestion control works.",
  "stream": false,
  "options": {"num_ctx": 8192}
}' | jq '{
  tokens: .eval_count,
  tokens_per_second: (.eval_count / .eval_duration * 1e9),
  prompt_seconds: (.prompt_eval_duration / 1e9),
  load_seconds: (.load_duration / 1e9)
}'

eval_count indica quantos tokens foram gerados e eval_duration indica quantos nanossegundos foram gastos a gerá-los; por isso, eval_count / eval_duration * 1e9 corresponde a tokens por segundo. prompt_eval_duration contabiliza a leitura do seu prompt, que é o tempo de espera percecionado antes de aparecer o primeiro token. load_duration corresponde ao tempo gasto a carregar o modelo do disco, por isso é elevado na primeira chamada depois de um reinício e quase nulo na seguinte.

Execute três vezes e guarde os resultados da segunda e da terceira execução, porque a primeira inclui esse carregamento. Depois, execute novamente com um prompt muito mais longo, porque o processamento do prompt aumenta com o comprimento da entrada, enquanto a velocidade de geração não aumenta. Registe os valores junto do nome do seu plano e da sua quantização. Esse registo é mais útil do que qualquer benchmark que leia, porque foi medido no hardware pelo qual está a pagar.

Como o tamanho do contexto multiplica a memória

Ollama usa por predefinição um contexto de 4096 tokens. O modelo anuncia um valor muito superior, 198K tokens para glm-4.7-flash, mas esse valor não é aplicado por predefinição e ativá-lo tem um custo.

A cache KV armazena um vetor de chave e um vetor de valor para cada token, em cada camada. O tamanho aumenta linearmente com o número de tokens permitido. Passar de 4096 para 32768 tokens multiplica o contexto por oito, portanto a cache KV também aumenta aproximadamente oito vezes. Num servidor dimensionado apenas para acomodar os pesos, essa alocação adicional é precisamente o que provoca a utilização de swap. Por isso, uma máquina que respondia bem a pedidos curtos pode ficar subitamente lenta quando alguém cola um documento longo.

Defina esse valor por pedido com num_ctx no objeto de opções, como no comando curl acima, ou altere a predefinição do servidor.

sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

O último comando deve mostrar o valor de OLLAMA_CONTEXT_LENGTH. Se mostrar um Environment= vazio, o ficheiro de substituição está no diretório errado ou a recarga foi ignorada. Depois do carregamento seguinte do modelo, ollama ps deve mostrar um SIZE visivelmente superior ao valor observado com 4096. Aumente o valor gradualmente e monitorize esse número a cada alteração. Definir o tamanho do contexto do Ollama com num_ctx explica como isto interage com keep-alive e com pedidos paralelos, que multiplicam ambos o mesmo custo. Se mais de um cliente utilizar o servidor, defina os limites de concorrência ao mesmo tempo que o contexto, porque cada slot paralelo tem a sua própria cache KV e a configuração da fila determina se um segundo pedido espera ou é recusado imediatamente.

Quando a API custa menos do que o servidor

A hospedagem própria não é automaticamente mais barata, e os preços de tabela publicados para esta família deixam isso especialmente claro.

[
  {
    "label": "GLM-5.2 input",
    "usd_per_million_tokens": 1.4
  },
  {
    "label": "GLM-5.2 output",
    "usd_per_million_tokens": 4.4
  },
  {
    "label": "GLM-4.7-Flash input",
    "usd_per_million_tokens": 0
  },
  {
    "label": "GLM-4.7-Flash output",
    "usd_per_million_tokens": 0
  }
]

Em 18 August 2026, a Z.ai lista o GLM-5.2 a $1.4 por milhão de tokens de entrada e $4.4 por milhão de tokens de saída. A empresa lista o GLM-4.7-Flash, o modelo que este guia executa localmente, a $0 em ambas as direções. Estes são preços publicados e podem mudar, portanto consulte a página atual antes de preparar um orçamento com base em qualquer um deles.

Por isso, o argumento financeiro a favor da hospedagem própria glm-4.7-flash é fraco neste momento. Um VPS com RAM suficiente tem um custo mensal real, enquanto o fornecedor disponibiliza o mesmo modelo gratuitamente. Ao executá-lo por sua conta, obtém algo diferente: os seus prompts permanecem numa máquina que controla, e a versão do modelo nunca muda a menos que a altere. Estas são boas razões para usar hospedagem própria. Para este modelo e com estes preços, o custo não é uma delas.

A conta muda quando o modelo pretendido não é gratuito ou quando os seus dados não podem legalmente sair da sua própria rede. O ponto de equilíbrio entre um VPS com GPU e tokens de API explica esse cálculo com cada variável identificada. Se ainda estiver a escolher a máquina, quanto custa realmente um VPS por mês é a outra parte da soma.

Mantenha o endpoint em localhost

Este é o passo que as pessoas ignoram, mas é o mais importante.

Por predefinição, o Ollama associa-se a 127.0.0.1 na porta 11434, por isso só pode ser acedido pelo próprio servidor. Confirme isso no seu servidor, em vez de assumir que está correto.

ss -ltnp | grep 11434

Deve ver 127.0.0.1:11434. Ver 0.0.0.0:11434 ou *:11434 significa que a API está a escutar em todas as interfaces, incluindo a interface pública.

Isto é importante porque a API do Ollama não tem autenticação. Não existe palavra-passe, token nem lista de permissões. Qualquer pessoa que consiga aceder à porta 11434 pode listar os seus modelos, executar geração no hardware que está a pagar, descarregar novos modelos para o disco até este ficar cheio e eliminar os modelos existentes. A porta 11434 é fixa e conhecida, por isso os scanners encontram rapidamente as portas abertas.

Não defina OLLAMA_HOST=0.0.0.0. Muitos tutoriais sugerem essa opção como solução quando um cliente no portátil não consegue ligar-se, mas é a solução errada. Encaminhe a porta em vez disso.

ssh -N -L 11434:127.0.0.1:11434 you@your-server

Isto associa a porta 11434 do portátil ao endereço de loopback do servidor através de SSH, por isso qualquer cliente configurado para http://localhost:11434 funciona sem alterações e nada de novo fica exposto. Para várias pessoas ou várias máquinas, coloque o servidor numa rede privada de túneis e associe o Ollama ao endereço do túnel, nunca a 0.0.0.0.

Verifique a partir de outro local que não o servidor. No portátil, com o túnel SSH fechado:

curl -m 5 http://your-server-ip:11434/api/tags

curl: (28) Connection timed out ou curl: (7) Failed to connect é o resultado correto. Uma lista JSON dos seus modelos significa que a porta está aberta à Internet e que o problema precisa de ser corrigido agora. A firewall de rede do seu fornecedor é um controlo separado da firewall executada no servidor, por isso verifique ambas. A questão mais ampla sobre a segurança do alojamento VPS aborda o restante nível de segurança de base de uma máquina que permanece em execução.

Se o glm-4.7-flash continuar a ser demasiado grande

Quando a tag Q4 não cabe no seu plano, a solução é usar um modelo menor, não reduzir o contexto. Reduzir o contexto para conseguir carregar um modelo resulta num serviço que inicia, mas falha no primeiro prompt longo. Qwen 3 a 8B e 27B numa VPS segue o mesmo processo de instalação com tamanhos adequados para máquinas modestas, e o guia geral para alojar um LLM localmente com Ollama numa VPS aborda as partes que permanecem iguais, independentemente do modelo escolhido. Seja qual for a sua escolha, fixe a tag, faça medições no seu próprio plano e mantenha o endpoint em loopback.

FAQ

O GLM 5.2 pode ser executado localmente numa VPS?

Não. Em 18 August 2026, o GLM 5.2 existe na biblioteca do Ollama apenas como glm-5.2:cloud, uma tag que é executada na própria infraestrutura do Ollama e precisa de ollama signin para funcionar. O modelo tem 756 billion parameters, por isso, mesmo com quatro bits por parâmetro, só os pesos ocupam centenas de gigabytes, muito acima do que qualquer plano VPS normal oferece. O modelo GLM com pesos transferíveis que cabe num servidor alugado é glm-4.7-flash.

Quanta RAM requer o glm-4.7-flash?

Use o tamanho da transferência da tag como valor mínimo e acrescente espaço para a cache KV e para o sistema operativo. O Ollama indica 19 GB para a tag Q4, 32 GB para Q8 e 60 GB para a tag bfloat16. Não existe um multiplicador fixo adequado para todos os casos, porque a cache KV aumenta com o comprimento de contexto definido. Carregue o modelo, execute ollama ps e consulte a coluna SIZE para obter o valor real no seu sistema.

Como meço tokens por segundo na minha própria VPS?

Envie um pedido para http://localhost:11434/api/generate com "stream": false e leia eval_count e eval_duration na resposta. Tokens por segundo é eval_count / eval_duration * 1e9, porque eval_duration é indicado em nanossegundos. Ignore a primeira execução, porque load_duration inclui nesse caso a leitura dos pesos a partir do disco. Repita também com um prompt longo, porque prompt_eval_duration aumenta com o comprimento da entrada, enquanto a velocidade de geração não aumenta.

Por que não devo definir OLLAMA_HOST como 0.0.0.0?

Porque a API do Ollama não tem autenticação. Associá-la a 0.0.0.0 expõe um endpoint sem autenticação à internet pública. Qualquer pessoa que consiga aceder à porta 11434 pode gerar conteúdo no seu hardware e alterar os modelos instalados. Mantenha a associação predefinida a 127.0.0.1, confirme-a com ss -ltnp | grep 11434 e aceda à API a partir do seu portátil através de um túnel SSH, como ssh -N -L 11434:127.0.0.1:11434 you@your-server.