SSD Nodes Learn 🎉 VPS desde $5.50/mês
Guias Matt ConnorPor Matt Connor · Atualizado 2026-08-21

Como rodar GLM 5.2 em um VPS com Ollama

O GLM 5.2 é apenas cloud na biblioteca do Ollama. Veja qual modelo GLM cabe em um VPS e quanta RAM cada quantização exige no seu servidor.

Você pode executar o GLM 5.2 em um VPS?

Não, e vale entender o motivo antes de alugar qualquer recurso. 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. Isso é apenas a aritmética básica, antes de considerar o contexto, as ativações e o sistema operativo. Nenhum plano de VPS padrão oferece tanta memória.

O modelo GLM que cabe num servidor alugado é glm-4.7-flash. Ele é publicado com pesos disponíveis para download em 4 tags. É um modelo mixture-of-experts, ou seja, apenas uma pequena parte da rede é executada para cada token. A Z.ai descreve-o como 30B-A3B: 30 billion parameters no total, com cerca de 3 billion active per token. Portanto, este guia responde à pergunta que pode colocar em prática. Fixe uma tag, dimensione o servidor, meça a sua própria velocidade e mantenha o endpoint privado.

Verifique a tag antes de copiar qualquer comando, incluindo os que aparecem aqui. A biblioteca do Ollama pode mudar sem aviso. Abra a lista de tags do glm-4.7-flash e confirme se a tag ainda existe. Se tiver sido lançada uma versão mais recente do GLM com pesos locais, prefira-a e registe qual tag testou efetivamente.

Se quiser utilizar o próprio GLM 5.2 mesmo assim, ollama run glm-5.2:cloud funciona depois de ollama signin e, do lado do cliente, comporta-se como qualquer outro modelo do Ollama. Entenda 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.

Quais tags do GLM existem e qual fixar

Há três entradas oficiais do GLM relevantes aqui. glm-5.2 e glm-5.1 estão disponíveis apenas na cloud. glm-4.7-flash é a entrada local, e estas são as tags publicadas, com o tamanho de download que o Ollama lista para cada uma.

Chartglm-4.7-flash tags in Ollama's library, checked 2026-08-18
The data behind this chart
[
  {
    "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, por isso latest resolve atualmente para a build Q4. Isto pode mudar em qualquer republicação. Por esse motivo, nunca escreva um ollama pull glm-4.7-flash sem quantização num script ou num Dockerfile. Especifique a quantização. A 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 significa que o upload foi publicado por uma conta de utilizador. Portanto, trata-se de uma republicação da comunidade, e não da entrada oficial. Ninguém garante quais pesos estão incluídos. Trate-a como trataria qualquer binário não assinado encontrado online.

Instalar o Ollama e obter a tag exata

O instalador do Ollama para Linux é 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 obter qualquer modelo.

systemctl status ollama --no-pager

Active: active (running) indica que a API está a escutar na porta 11434. Se a unidade não existir, o instalador recorreu a uma instalação apenas com o binário. A documentação do Ollama para Linux fornece o ficheiro de serviço que pode 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 lentamente; recusa-o. O comando 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 o Ollama. Em 18 August 2026, a versão atual é 0.32.14, muito acima desse mínimo.

Agora obtenha 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 interrompido 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, e 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.

De quanta RAM precisa cada quantização?

Comece pelo tamanho do download como valor mínimo e acrescente o restante. Os pesos têm de permanecer na memória. Além deles, existe a cache KV (cache de key/value), que é a memória usada pelo runtime para guardar os tokens que já estão na conversa, bem como buffers de computação e a memória utilizada pelo sistema operativo. Uma máquina com exatamente 19 GB de RAM não executará a tag de 19 GB.

Não existe um multiplicador único correto para todos os casos, porque a cache KV aumenta com o comprimento de contexto permitido e o restante varia entre versões do runtime. Por isso, faça medições em vez de adivinhar. Carregue o modelo com um prompt trivial e leia a quantidade de memória reservada pelo servidor.

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

ollama ps mostra o modelo carregado com uma coluna SIZE e uma coluna PROCESSOR. SIZE é a quantidade que o runtime reservou efetivamente. É esse o número que deve comparar com o seu planeamento. PROCESSOR indica onde ocorre o processamento, por isso 100% CPU significa que não foi utilizada qualquer GPU.

Quando o modelo não cabe na memória, a falha é silenciosa e ocorre de duas formas. Com swap ativada, o carregamento parece ser bem-sucedido, mas a geração fica extremamente lenta, porque as páginas são movidas entre o disco e a RAM para cada token. Sem swap, o processo é terminado 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 apresenta 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 nesse valor. Q4 reduz um pouco a qualidade da saída. A redução depende da tarefa, e 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 emitir um aviso. A utilidade do resultado depende da carga de trabalho e da sua paciência.

A arquitetura de mixture-of-experts 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 num modelo denso de 30B. O que não diminui é a memória. Todos os experts precisam permanecer residentes, porque o router pode selecionar qualquer um deles para o token seguinte. Assim, uma máquina apenas com CPU ainda precisa de 19 GB completos ou mais para a tag Q4, e a taxa de processamento é determinada principalmente pela largura de banda da memória, não pela velocidade do clock.

Isto 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 respetivos subsistemas de memória são diferentes. Um plano partilhado acrescenta uma segunda variável, porque o tempo de CPU roubado 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, em vez de uma tabela de resultados.

Medir 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; portanto, eval_count / eval_duration * 1e9 corresponde a tokens por segundo. prompt_eval_duration abrange a leitura do seu prompt, que é o que uma pessoa experiencia como a espera 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-o três vezes e mantenha os resultados da segunda e da terceira execução, porque a primeira inclui esse carregamento. Depois, execute-o novamente com um prompt muito mais longo, porque o processamento do prompt aumenta com o tamanho da entrada, enquanto a velocidade de geração não aumenta. Registe os números junto ao nome do seu plano e à sua quantização. Esse registo vale mais do que qualquer benchmark que leia, porque foi medido no hardware pelo qual está a pagar.

Como o comprimento do contexto multiplica o uso de memória

O Ollama usa por predefinição um contexto de 4096 tokens. O modelo anuncia muito mais, 198K tokens para glm-4.7-flash, mas esse valor não é usado 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 fica aproximadamente oito vezes maior. Num servidor dimensionado para comportar apenas os pesos, essa alocação adicional é suficiente para começar a usar swap. Por isso, uma máquina que processava prompts curtos sem problemas pode ficar subitamente muito 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 o reload foi ignorado. Depois do carregamento seguinte do modelo, ollama ps deve mostrar um SIZE visivelmente maior do que o valor apresentado com 4096. Aumente o valor gradualmente e monitorize esse número a cada alteração. Definir o comprimento do contexto do Ollama com num_ctx explica como isto interage com keep-alive e com pedidos paralelos, que multiplicam ambos o mesmo custo.

Quando a API custa menos do que o servidor

A auto-hospedagem não é automaticamente mais barata, e os preços de tabela publicados para esta família deixam isso particularmente claro.

ChartZ.ai published list prices per million tokens, checked 2026-08-18
The data behind this chart
[
  {
    "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 indica 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 indica 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, por isso 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 auto-hospedagem glm-4.7-flash é atualmente fraco. Um VPS com RAM suficiente custa dinheiro todos os meses, e o editor disponibiliza o mesmo modelo gratuitamente. O que obtém ao executá-lo por sua conta é 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 optar pela auto-hospedagem. O custo não é uma delas para este modelo e a estes preços.

A comparação 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 está a escolher a máquina, quanto custa realmente um VPS por mês é a outra metade da soma.

Mantenha o endpoint em localhost

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

Por padrão, o Ollama faz bind em 127.0.0.1 na porta 11434, por isso só pode ser acedido a partir do 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 ou allowlist. Qualquer pessoa que consiga aceder à porta 11434 pode listar os seus modelos, executar geração no hardware que está a pagar, transferir novos modelos para o disco até o encher 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. Em vez disso, encaminhe a porta.

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

Isto mapeia a porta 11434 no portátil para o endereço de loopback do servidor através de SSH. Assim, 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únel e faça o bind do Ollama ao endereço do túnel, nunca a 0.0.0.0.

Verifique a partir de outro local que não seja 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 para a Internet e precisa de ser corrigida imediatamente. A firewall de rede do seu fornecedor é um controlo separado da firewall em execução no servidor, por isso verifique ambas. A questão mais abrangente sobre a segurança do alojamento VPS aborda o restante da configuração de base de uma máquina que fica 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 em 8B e 27B numa VPS segue o mesmo processo de instalação com tamanhos adequados para servidores modestos, e o guia geral para alojar um LLM numa VPS com Ollama 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 no 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 antes de funcionar. O modelo tem 756 billion parameters, por isso, mesmo com quatro bits por parâmetro, só os pesos ocupam centenas de gigabytes, muito além do que qualquer plano VPS comum oferece. O modelo GLM com pesos descarregáveis que cabe num servidor alugado é glm-4.7-flash.

Quanta RAM é necessária para o glm-4.7-flash?

Considere o tamanho de download da tag como o mínimo e reserve espaço adicional para a cache KV e para o sistema operativo. O Ollama lista a tag Q4 com 19 GB, a Q8 com 32 GB e a tag bfloat16 com 60 GB. Não existe um multiplicador fixo adequado para todos os casos, porque a cache KV cresce com o comprimento de contexto definido. Carregue o modelo, execute ollama ps e leia a coluna SIZE para obter o valor real no seu servidor.

Como meço os 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. Os tokens por segundo correspondem a eval_count / eval_duration * 1e9, porque eval_duration é indicado em nanossegundos. Descarte 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 cresce com o comprimento da entrada, enquanto a velocidade de geração não cresce.

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.