On July 10, 2026, Colibrì hit 453 points on Hacker News — Show HN: Getting GLM 5.2 running on my slow computer. Author vforno (JustVugg) set a deliberately modest goal: make GLM-5.2 — Z.ai's 744B MoE frontier open model — answer correctly on a 12-core laptop with 25 GB RAM, even if speed is measured in minutes per paragraph, not tokens per second.
The result is not a faster llama.cpp fork. It is a disk-streaming MoE runtime: ~9.9 GB dense weights stay in RAM; ~370 GB of routed experts live on NVMe and load on demand. Pure C, zero runtime deps, token-exact against a transformers oracle.
GLM-5.2 activates ~40B parameters per token, but MoE routing means only ~11 GB of expert weights are new each decode step — the rest is shared dense stack (attention, embeddings, shared experts).
Colibrì splits the model physically:
Component
Params (order of magnitude)
Where it lives
Size (int4)
Dense stack
~17B effective resident
RAM
~9.9 GB
Routed experts
75 layers × 256 + MTP head
Disk
~370 GB total (~19 MB/expert)
Per-token churn
8 experts/layer typical
Streamed + LRU cache
~11 GB reads/token cold
The engine (c/glm.c, ~1,300 lines) implements faithful glm_moe_dsa forward — validated 32/32 teacher-forcing and 20/20 greedy against a tiny-random oracle with the real architecture.
MLA attention with compressed KV: 576 floats/token vs 32,768 naive — critical for long sessions on RAM-starved boxes (GLM-5.2 specs).
Community benchmarks (stock setup.sh, greedy, --ngen 32)
Machine
Disk (iobench)
Config
Measured
Core Ultra 7 270K, 24 GB, WSL2 (#2)
1.96 GB/s buf / 2.74 O_DIRECT
default
0.07 tok/s, hit 3–4%
Same
Same
--topp 0.7
0.11 tok/s, hit 11%
M5 Max, 128 GB unified (#4/#5)
14.2 GB/s O_DIRECT
MTP off
1.06 tok/s, hit 23%, RSS 21.8 GB
HN consensus:0.05–0.1 tok/s is a proof-of-life demo, not a daily driver. ~1 tok/s on Apple Silicon with fast SSD starts to resemble "walk away overnight" agent workflows walrus01 noted on HN. 5–15 tok/s remains a back-of-envelope target for 128–256 GB RAM + many cores + warm pin — not yet measured at scale.
SSD, swap, and the corrected wear story
Early README drafts worried about SSD wear from page cache writes. The July 10 README clarifies:
Expert streaming = read-only — does not wear NAND meaningfully
Swap under memory pressure does write — colibrì sizes expert cache from MemAvailable to stay out of swap
Thermals — hours at full read duty cycle heat cheaper drives; monitor health
For soldered-SSD laptops, HN commenters treat this as an experiment, not default daily tooling — external NVMe or a desktop with replaceable storage is saner for multi-hour runs.
The project has not published int4 accuracy loss yet — the harness exists; a full run on the dev box disk is ~a day. That benchmark is the highest-value community contribution right now.
Ticket / async interface — several commenters argued chat UI is wrong for 0.1 tok/s models; queue a task, check back in hours (loop engineering mindset without cloud).
RAM is the hidden cap on 24 GB machines — even with 2.7× faster disk, expert cache auto-caps to 2 slots/layer, so decode stays cold. More RAM → more pin → fewer reads.
OpenCode integration — in-flight PR per OP; until merge, wire agents manually or wait.
Related experiments — flash-moe reported 5+ tok/s on M3 Max (different approach); hypura for general SSD streaming — same design space, different targets.
Who should try Colibrì — and who should not
Try it if:
You have ≥25 GB RAM, ≥400 GB NVMe, Linux or WSL2, AVX2
You want to validate int4 GLM-5.2 quality on hardware faster than the author's laptop
Benchmarks and README details reflect the July 10, 2026 colibrì launch and community issues #2, #4, #5, #8. Tok/s varies enormously by NVMe, RAM pin budget, and MTP settings — run coli bench and iobench on your hardware before assuming interactive speed.
