Run GLM 5.2 on a VPS with Ollama

Can you run GLM 5.2 on a VPS?

No, and the reason is worth knowing before you rent anything. As of 18 August 2026, GLM 5.2 in Ollama's library carries exactly one tag, glm-5.2:cloud. A :cloud tag runs on Ollama's servers. Your box sends the prompt and receives the tokens, so the weights never touch your disk. The model is 756 billion parameters. Four bits per parameter across 756 billion parameters is roughly 378 GB of weights, and that is plain arithmetic before context, activations or the operating system. No standard VPS plan sells that much memory.

The GLM model that does fit a server you rent is glm-4.7-flash. It is published with downloadable weights in 4 tags. It is a mixture-of-experts model, meaning only a small part of the network runs for each token, and Z.ai describes it as 30B-A3B: 30 billion parameters in total, about 3 billion active per token. So this guide answers the question you can act on. Pin a tag, size the box, measure your own speed, and keep the endpoint private.

Verify the tag before you copy any command, including the ones here. Ollama's library changes without notice. Open the glm-4.7-flash tag list and confirm the tag still exists. If a newer GLM release has appeared with local weights, prefer it, and record which tag you actually tested.

If you want GLM 5.2 itself anyway, ollama run glm-5.2:cloud works after ollama signin, and from the client's side it behaves like any other Ollama model. Understand what you are agreeing to: the prompt leaves your server. If your reason for self-hosting is that data must stay on your machine, a :cloud tag does not meet that reason.

Which GLM tags exist, and which one to pin

Three official GLM entries matter here. glm-5.2 and glm-5.1 are cloud only. glm-4.7-flash is the local one, and these are its published tags with the download size Ollama lists for each.

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

Those are published figures from the library page, not measurements. latest and q4_K_M are both listed at 19 GB, so latest currently resolves to the Q4 build. That can change on any republish, which is why you should never write a bare ollama pull glm-4.7-flash into a script or a Dockerfile. Name the quantisation. The largest tag, bf16, is a 60 GB download holding the unquantised bfloat16 weights.

A search on the library also returns namespaced uploads with a slash in the name, such as someuser/glm-5.2. A slash means a user account published it, so it is a community re-upload rather than the official entry. Nobody guarantees which weights are inside. Treat one the way you would treat any unsigned binary you found online.

Install Ollama and pull the exact tag

Ollama's Linux installer is one command.

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

The installer creates a systemd service that runs as the ollama user. Confirm it started before you pull anything.

systemctl status ollama --no-pager

Active: active (running) means the API is listening on port 11434. If the unit does not exist, the installer fell back to a plain binary install, and the Ollama Linux documentation gives the service file to create by hand.

The glm-4.7-flash page lists a minimum Ollama version. An older binary does not run the model slowly, it refuses it: the pull fails with a message that the model requires a newer version of Ollama. Rerun the install script to upgrade. As of 18 August 2026 the current release is 0.32.14, which is well past that minimum.

Now pull one tag by name.

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls should list glm-4.7-flash:q4_K_M with a size close to the published 19 GB. A pull that dies partway leaves nothing runnable, so rerun the same command. The most common cause of a failed pull on a small plan is a full disk rather than a network problem, because the model is written to /usr/share/ollama/.ollama/models on the root filesystem. Check with df -h /usr/share/ollama before you start.

How much RAM does each quantisation need?

Start with the download size as a floor, then add to it. The weights must be resident in memory. On top of them sits the KV cache (key/value cache), which is the memory the runtime uses to remember the tokens already in the conversation, plus compute buffers and whatever the operating system is using. A box with exactly 19 GB of RAM will not run the 19 GB tag.

There is no single multiplier that is correct for everyone, because the KV cache grows with the context length you allow and the rest moves between runtime versions. So measure rather than guess. Load the model with a trivial prompt, then read what the server reserved.

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

ollama ps prints the loaded model with a SIZE column and a PROCESSOR column. SIZE is what the runtime actually reserved, and that is the number to compare against your plan. PROCESSOR tells you where the work happens, so 100% CPU means no GPU was involved at all.

When the model does not fit, the failure is quiet and it takes two shapes. With swap enabled the load appears to succeed and then generation crawls, because pages move between disk and RAM for every token. With no swap the process is killed outright, and journalctl -k | grep -i "out of memory" shows the kernel's Out of memory: Killed process line naming ollama. Check both, because neither prints a helpful message in the terminal where you were typing.

The step from the 19 GB Q4 tag to the 32 GB Q8 tag is the main lever you have over that number. Q4 costs you some output quality, and how much depends on the task, with structured output and long chains of reasoning suffering more than casual chat. How Q4, Q8 and FP16 differ in practice is worth reading before you commit, because on a CPU-only VPS the quantisation choice usually decides whether the model runs at all.

What happens on a CPU-only VPS

Most VPS plans ship no GPU, and Ollama will run the model on the CPU without warning you. Whether the result is usable depends on the workload and on your patience.

The mixture-of-experts design helps with speed. Only about 3 billion of the 30 billion parameters are used for any given token, so the arithmetic per token is far smaller than a dense 30B model would need. What does not shrink is memory. Every expert must stay resident, because the router can pick any of them for the next token. So a CPU-only box still needs the full 19 GB or more for the Q4 tag, and its throughput is governed mostly by memory bandwidth rather than by clock speed.

That has a practical consequence: two plans with the same core count and the same RAM can generate at noticeably different speeds because their memory subsystems differ. A shared plan adds a second variable, since CPU steal time from a noisy neighbour shows up as a tokens-per-second figure that changes hour to hour. This is the reason nobody else's published number predicts yours, and the reason the next section is a measurement recipe instead of a table of results.

Measure your own tokens per second

Ollama's generate endpoint returns timing fields in its final JSON object. Divide the generated token count by the generation duration and you have your number, on your plan, on your 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 is how many tokens were generated and eval_duration is the nanoseconds spent generating them, so eval_count / eval_duration * 1e9 is tokens per second. prompt_eval_duration covers reading your prompt, which is what a person experiences as the wait before the first token appears. load_duration is time spent loading the model from disk, so it is large on the first call after a restart and near zero on the next one.

Run it three times and keep the second and third results, because the first includes that load. Then run it again with a much longer prompt, since prompt processing scales with input length while generation speed does not. Write the numbers next to your plan name and your quantisation. That record is worth more than any benchmark you read, because it was measured on the hardware you are paying for.

How context length multiplies memory

Ollama defaults to a 4096-token context. The model advertises far more, 198K tokens for glm-4.7-flash, but you do not get that by default, and turning it on is not free.

The KV cache holds one key vector and one value vector for every token, in every layer. Its size grows linearly with the number of tokens you allow. Going from 4096 to 32768 tokens is eight times the context, so it is roughly eight times the KV cache. On a box sized to just fit the weights, that extra allocation is exactly what pushes you into swap, which is why a machine that answered short prompts fine suddenly crawls when someone pastes a long document.

Set it per request with num_ctx in the options object, as in the curl command above, or change the server default.

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

The last command should print your OLLAMA_CONTEXT_LENGTH value. If it prints an empty Environment=, the override file is in the wrong directory or the reload was skipped. After the next model load, ollama ps should show a visibly larger SIZE than it did at 4096. Raise the value in steps and watch that number each time. Setting Ollama's context length with num_ctx covers how this interacts with keep-alive and with parallel requests, both of which multiply the same cost.

When the API is cheaper than the box

Self-hosting is not automatically cheaper, and for this family the published list prices make the point unusually clearly.

[
  {
    "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
  }
]

As of 18 August 2026, Z.ai lists GLM-5.2 at $1.4 per million input tokens and $4.4 per million output tokens. It lists GLM-4.7-Flash, the model this guide runs locally, at $0 in both directions. Those are published prices and they move, so check the current page before you plan a budget around either one.

So the money argument for self-hosting glm-4.7-flash is weak right now. A VPS with enough RAM costs real money every month, and the publisher serves the same model for nothing. What you buy by running it yourself is different: your prompts stay on a machine you control, and the model version never changes unless you change it. Those are good reasons to self-host. Cost is not one of them, for this model, at these prices.

The arithmetic flips when the model you want is not free, or when your data legally cannot leave your own network. The break-even point between a GPU VPS and API tokens works through that calculation with each variable named. If you are still choosing the machine, what a VPS actually costs per month is the other half of the sum.

Keep the endpoint on localhost

This is the step people skip, and it is the one that matters most.

Ollama binds to 127.0.0.1 on port 11434 by default, so it is reachable only from the server itself. Confirm that on your box rather than assuming it.

ss -ltnp | grep 11434

You want to see 127.0.0.1:11434. Seeing 0.0.0.0:11434 or *:11434 means the API is listening on every interface, including the public one.

That matters because Ollama's API has no authentication. There is no password, no token, no allowlist. Anyone who can reach port 11434 can list your models, run generation on hardware you are paying for, pull new models onto your disk until it fills, and delete the ones you have. Port 11434 is fixed and well known, so scanners find open ones quickly.

Do not set OLLAMA_HOST=0.0.0.0. Plenty of tutorials suggest it as the fix when a client on your laptop cannot connect, and it is the wrong fix. Forward the port instead.

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

That maps port 11434 on your laptop to the server's loopback address through SSH, so any client configured for http://localhost:11434 works unchanged and nothing new is exposed. For several people or several machines, put the server on a private tunnel network and bind Ollama to the tunnel address, never to 0.0.0.0.

Verify from somewhere other than the server. From your laptop, with the SSH tunnel closed:

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

curl: (28) Connection timed out or curl: (7) Failed to connect is the correct result. A JSON list of your models means the port is open to the internet, and it needs fixing now. Your provider's network firewall is a separate control from the one running on the box, so check both. The wider question of whether VPS hosting is safe covers the rest of the baseline for a machine you leave running.

If glm-4.7-flash is still too big

When the Q4 tag does not fit your plan, the fix is a smaller model, not a smaller context. Cutting context to squeeze a model in gives you something that loads and then fails at the first long prompt. Qwen 3 at 8B and 27B on a VPS walks the same install path at sizes that suit modest boxes, and the general guide to self-hosting an LLM with Ollama on a VPS covers the parts that stay the same whichever model you pick. Whatever you land on, pin the tag, measure on your own plan, and leave the endpoint on loopback.

FAQ

Can GLM 5.2 run locally on a VPS?

No. As of 18 August 2026, GLM 5.2 exists in Ollama's library only as glm-5.2:cloud, a tag that runs on Ollama's own infrastructure and needs ollama signin before it will work. The model is 756 billion parameters, so even at four bits per parameter the weights alone come to hundreds of gigabytes, far past what any standard VPS plan offers. The GLM model with downloadable weights that fits a rented server is glm-4.7-flash.

How much RAM does glm-4.7-flash need?

Treat the tag's download size as a floor and add room for the KV cache and the operating system on top. Ollama lists the Q4 tag at 19 GB, Q8 at 32 GB, and the bfloat16 tag at 60 GB. No fixed multiplier is right for everyone, because the KV cache grows with the context length you set. Load the model, run ollama ps, and read the SIZE column for the real figure on your own box.

How do I measure tokens per second on my own VPS?

Send one request to http://localhost:11434/api/generate with "stream": false, then read eval_count and eval_duration from the response. Tokens per second is eval_count / eval_duration * 1e9, because eval_duration is reported in nanoseconds. Discard the first run, since load_duration on that one includes reading the weights from disk. Repeat with a long prompt as well, because prompt_eval_duration grows with input length while generation speed does not.

Why should I not set OLLAMA_HOST to 0.0.0.0?

Because Ollama's API has no authentication, so binding it to 0.0.0.0 places an unauthenticated endpoint on the public internet. Anyone who reaches port 11434 can generate on your hardware and change which models are installed. Keep the default 127.0.0.1 bind, check it with ss -ltnp | grep 11434, and reach the API from your laptop over an SSH tunnel such as ssh -N -L 11434:127.0.0.1:11434 you@your-server.