GLM 5.2 local: run 744B on a 24 GB PC, no GPU

GLM-5.2 will run on a machine with 24 GB of RAM. That contradicts every hardware guide out there, because those guides assume all 744B parameters have to sit in memory at once, and on that premise the honest answer is 223 GB at least, followed by a shopping list. But the premise is the part worth checking: only about 11 GB of the model changes from one token to the next, so the weights don't have to be loaded — they have to be placed.

Why Ollama cannot run GLM-5.2 on your machine

Most people try Ollama first, and a search of its library for GLM-5.2 does turn up a result. That result is not a local model, and the page says so in a column that is easy to overlook.

What the Ollama listing actually offers

Only one model is listed under GLM-5.2 on the page: glm-5.2:cloud. Its size column is blank, because there is no file to download.

Every code sample on the page — CLI, cURL, Python and JavaScript — uses that same cloud tag, and the page gives a price of $1.40 input, $0.26 cached and $4.40 output per million tokens. It also shows 756B parameters and a 976K context window, which are the model's own specs, not requirements for your machine.

The command runs and an answer comes back, but none of the work happens on your hardware. It is a hosted API reached through Ollama, and the cloud tag in the run command gives it away.

How other GLM models differ on Ollama

The library listing makes the difference visible. glm-4.7-flash has four tags with parameter sizes and no cloud badge, which is how a model you can actually run locally appears there. By contrast, glm-5.2, glm-5.3 and glm-5.1 each have a single tag and a cloud badge.

Keep this in mind before judging a model by whether it appears in a library. Being listed is not the same as being downloadable, and the tag tells you which you have.

What GLM-5.2 actually needs to run locally

GLM-5.2's published requirements look nothing like the ones passed around in buying guides. They describe a different way of running the model, streaming the weights instead of holding them all, which shifts the load from memory to the drive.

The official GLM 5.2 requirements table

The repository's table gives one row per model. For GLM-5.2, disk is "~372 GB", memory is "16 GB min, 24 GB comfortable", and the GPU column says "not needed".

GLM-5.2 hardware needs in the repository

The note above the “GLM-5.2 hardware needs in the repository” table answers a mix-up readers had already made: "They do not — they are different models." Different model families in the same engine need very different amounts, and reading two rows as one model creates a contradiction that isn't there. One line covers the whole table: "None of them needs a GPU."

Why other guides quote 223 to 420 GB

Those figures are correct. They answer another question, how much memory it takes to hold every weight at once, which is what llama.cpp and vLLM-style deployments require. Quantized to one bit, that comes to about 223 GB; at four bits, about 420 GB.

The usual recommendations follow from that: a 256 GB Mac Studio, four RTX 3090s, or rented H100s. If holding all the weights were the only way to run them, no consumer machine would qualify, which is why the guides all reach the same conclusion.

GLM 5.2 VRAM: a GPU changes speed, not feasibility

A GPU only changes speed. The engine treats VRAM as one more place an expert can sit, along with RAM and the disk, and the answer is the same wherever the expert was read from.

How a 744B model fits on a 24 GB machine

GLM-5.2 is a mixture-of-experts model, split into many specialist sub-networks of which only a few are used for each token. About 40B of its 744B parameters are active per token, and only about 11 GB of those change from one token to the next.

What stays in RAM and what stays on disk

Memory is divided along those lines. Everything every token needs, attention, the shared experts and the embeddings, roughly 17B parameters, is compressed to int4 and kept in memory at a cost of about 9.9 GB. The routed experts stay on the drive and are read only when needed.

The whole design depends on each expert being about 19 MB. Reading 19 MB from an NVMe drive is a small job, and a token needs a few hundred of them, not all 19,456.

Why streaming works: routing is predictable

Reading from disk on demand would fail if the requests were random, but they are not. The engine measures which expert the router chooses and reports that "routing is measurably 71.6% predictable one layer ahead", so a lookahead thread can load most of the next layer's experts while the current layer is still computing.

It also notes which experts your own prompts use most and keeps those in memory, so a machine gets faster the longer you use it for the same kind of work. That is the difference between this placement scheme and ordinary swapping.

What speed to expect from a local GLM-5.2

Speed is the real weakness, and the repository gives a number for each machine instead of one headline figure. The slowest and fastest setups are about a hundredfold apart.

Measured decode speed by where the experts live (tokens per second)

Same engine and same int4 weights in all four rows — only the placement changes. The 25 GB box is the published floor, not a failure case.

5.8–6.86× RTX 5090, every expert resident

1.8128 GB desktop, CPU only, warm

1.07Single RTX 5070 Ti, GPU-resident

0.05–0.125 GB dev box, cold cache

0246

The four measured points, from 0.05 to 6.8 tok/s

At the top end, six RTX 5090s holding every expert reach "5.8–6.8 tok/s decode, TTFT ~13 s", with the disk no longer involved in decoding at all. A 128 GB CPU-only desktop gets about 1.8 tokens per second once the cache is warm, and a single RTX 5070 Ti in a laptop-class machine gets 1.07 through the GPU-resident pipeline.

The low end comes from a 25 GB dev box, close to the 24 GB that the requirements table calls comfortable. The repository presents it as a baseline instead of hiding it in a footnote, which is rare enough to quote in full.

What this speed is and is not good for

At a tenth of a token per second, a few hundred words take more than ten minutes. That is nowhere near conversational, and treating it as a chat replacement will only frustrate you.

It fits a different kind of work, where you ask a question and come back later to an answer that a frontier-class model produced on your own hardware, with nothing leaving the machine. For interactive coding at a workable pace, a smaller model on the same machine is the better choice, as Local LLM Coding Now Hits 75% of Cloud AI shows.

Set up GLM-5.2 locally with Colibrì

Colibrì is the engine behind this, a single C file with a few small headers: "No BLAS, no Python at runtime, no GPU required." As of September 2026 it is at v1.10.1 and runs eight model families from 744B to 2.8T, GLM-5.2 among them.

The three steps to a first run

A first answer takes three steps: get the machine ready, put the weights on the drive, then build and start the engine. No step needs a GPU, and the figure lists what each involves.

./coli serve also gives the engine an OpenAI-compatible endpoint, so existing tools can connect without knowing what runs behind it. The model itself is part of Z.ai's GLM family, covered in GLM 5.2 benchmarks, pricing, and Claude Code setup.

What to check before you start

Nothing in the setup matters more than the drive. It must be connected directly, because every routed expert is a disk read. A network share or slow external disk turns a borderline speed into an unusable one.

Licensing is not a concern here. Neither the engine nor the weights cost anything, so you pay only in storage and patience.

Summary: GLM-5.2 runs on 24 GB by streaming its weights

Whether GLM-5.2 runs locally depends on a question buying guides skip: must the weights be held in memory, or can they just be placed on disk? Held, they need 223 GB and a new machine; placed across an NVMe drive and 24 GB of RAM, they run today, slowly but correctly.

Ollama will not get you there, since its only GLM-5.2 is a cloud tag billed per token. The disk sets the speed, and 0.05 tokens per second on a 25 GB machine is the published floor, not a sign of a broken setup. The trade makes sense if keeping the answer on your own hardware matters more than getting it quickly.