Nokka

Posted on Jul 12

Colibri — รัน GLM-5.2 (744B MoE) บนเครื่อง 25GB RAM ด้วย Pure C ไฟล์เดียว

#ai #opensource #engineering #programming

Colibri — รัน GLM-5.2 (744B MoE) บนเครื่อง 25GB RAM ด้วย Pure C ไฟล์เดียว

โดย Nokka (นก-กา) | 11 กรกฎาคม 2026

บทความนี้เขียนโดย AI (DeepSeek V4 Pro) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ — Nokka (นก-กา)

TL;DR

Colibri คือ inference engine ที่เขียนด้วย Pure C ไฟล์เดียว (~2,400 บรรทัด) — zero dependencies — ไม่ต้องใช้ GPU — รัน GLM-5.2 โมเดล 744B พารามิเตอร์ บนเครื่อง consumer ที่มี RAM แค่ 25 GB ได้ [1]

เทคนิคหลัก: แยกโมเดลเป็นสองส่วน — dense part (~9.9 GB) อยู่ใน RAM ตลอดเวลา ส่วน routed experts 21,504 ตัว (~370 GB) อยู่บน NVMe และถูก stream เข้ามาเฉพาะตอนที่ router เลือกใช้ — เหลือ RAM ว่าง ~15 GB สำหรับ LRU cache และ OS page cache [1]

ความเร็ว: 0.05-0.1 tok/s บน dev machine (WSL2, 12 cores, 25 GB RAM) — ไม่เร็ว แต่มันคือ 744B frontier model ที่ตอบถูกต้องบนเครื่องที่ราคาถูกกว่า H100 หนึ่งใบ [1]

Highlight — "Tiny engine, immense model"

$ ./coli chat
  🐦 colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU
  ✓ pronto in 32s · residente 9.9 GB
  › ciao!
  ◆ Ciao! 😊 Come posso aiutarti oggi?

32 วินาทีในการโหลด — 9.9 GB resident — แล้ว GLM-5.2 ก็พร้อมตอบบนเครื่อง 25 GB RAM [1]

GLM-5.2 คืออะไร — ทำความเข้าใจโมเดลก่อน

GLM-5.2 คือ Mixture-of-Experts (MoE) โมเดล 744B พารามิเตอร์ จาก Z.ai — เปิดตัว 13 มิถุนายน 2026 — MIT license — หนึ่งใน open-weight model ที่แข็งแกร่งที่สุดในปัจจุบัน [5][6]

สเปค	ค่า
Total parameters	744B
Active per token	~40B
MoE layers	75
Experts per layer	256 (8 active + 1 shared)
Context window	1M tokens
Attention	MLA (Multi-head Latent Attention) + DSA (DeepSeek Sparse Attention)
Router	DeepSeek-V3-style sigmoid (noaux_tc)
License	MIT

MoE ทำงานยังไง: แทนที่จะใช้ทั้ง 744B พารามิเตอร์ทุก token — GLM-5.2 ใช้ router เลือกแค่ 8 experts จาก 256 ตัวต่อ layer — รวมแล้ว activate แค่ ~40B พารามิเตอร์ต่อ token — ที่เหลือ ~700B นอนเฉยๆ [1][5]

นี่คือกุญแจที่ทำให้ Colibri ทำงานได้: เพราะแต่ละ token ใช้แค่ ~11 GB ของ expert weights — Colibri เลยเก็บ experts ไว้บน disk แล้ว stream เฉพาะตัวที่ถูกเลือกเข้ามา [1]

Colibri ทำงานยังไง — สถาปัตยกรรมเชิงลึก

1. แยกโมเดลเป็นสองส่วน

┌─────────────────────────────────────────┐
│ RAM (Resident — ~9.9 GB int4)           │
│  • Dense layers (attention, shared      │
│    experts, embeddings) — ~17B params   │
│  • LRU Expert Cache (auto-sized)        │
│  • Pinned Hot Experts (learning cache)  │
│  • Compressed MLA KV-cache              │
├─────────────────────────────────────────┤
│ NVMe (Streamed — ~370 GB int4)          │
│  • 21,504 routed experts               │
│  • 75 MoE layers × 256 experts          │
│  • ~19 MB per expert at int4            │
│  • Streamed on-demand per token         │
└─────────────────────────────────────────┘

Dense part (~17B params → ~9.9 GB int4): attention weights, shared experts, embeddings — ใช้ทุก token → อยู่ใน RAM ตลอด

Routed experts (21,504 ตัว → ~370 GB int4): ถูก router เลือกใช้แค่ 8 ตัวต่อ layer ต่อ token — อยู่บน NVMe — stream เข้ามาเฉพาะตอนถูกเลือก [1]

2. MLA Attention — บีบ KV-cache 57 เท่า

GLM-5.2 ใช้ Multi-head Latent Attention (MLA) — เทคนิคจาก DeepSeek-V3 — แทนที่จะเก็บ full KV-cache (32,768 floats/token สำหรับ 64 heads) — MLA ใช้ low-rank projection บีบเหลือแค่ 576 floats/token — เล็กลง 57 เท่า [1]

Colibri ยัง implement MLA weight absorption (DeepSeek trick) — query ดูดซับ kv_b projection — ไม่ต้อง reconstruct k/v ต่อ token — validated token-exact เทียบกับ transformers oracle [1]

KV-cache persistence: Colibri เซฟ compressed MLA KV-cache ลงดิสก์หลังทุก turn (~182 KB/token, crash-safe) — ปิดแชทแล้วเปิดใหม่พรุ่งนี้ — โมเดลยังจำบทสนทนาทั้งหมด — validated byte-identical กับ session ที่ไม่เคยถูกขัดจังหวะ [1]

3. DSA Sparse Attention — เลือก attend แค่ 2,048 tokens

GLM-5.2 ใช้ DeepSeek Sparse Attention (DSA) — แทนที่จะ attend ทุก token ใน context — DSA ใช้ learned indexer เลือก top-2,048 keys ต่อ layer — ลด compute จาก O(n²) เป็น O(n × 2048) [1][5]

Colibri implement DSA แบบ faithful — auto-detect จาก out-idx weights — validated: forcing ให้ keep ทุก key reproduce dense attention token-for-token [1]

4. MTP Speculative Decoding — 2.2-2.8 tokens/forward

GLM-5.2 มี Multi-Token Prediction (MTP) head ที่ layer 78 — มัน draft tokens ล่วงหน้า แล้ว main model verify ใน batched forward ครั้งเดียว [1]

MTP head precision	Draft acceptance	Tokens/forward
int4	0-4%	~1.0 (ไม่เวิร์ค)
int8	39-59%	2.2-2.8

สำคัญ: MTP head ต้องเป็น int8 — ที่ int4 draft acceptance ตกเหลือ 0-4% — speculation ไม่เกิด — converter ทำ int8 ให้อัตโนมัติ [1]

ข้อควรระวัง: cold cache — แต่ละ verified draft route ไปหา experts เพิ่ม (~660 → ~1,100 expert-loads/token) — speculation อาจช้าลงจนกว่า cache/pin จะอุ่น — adaptive guard และ DRAFT=0 มีไว้สำหรับกรณีนี้ [1]

5. Integer-Dot Kernels — 119 GFLOP/s บน AVX2

Colibri ใช้ hand-tuned integer matmul kernels:

Kernel	Speed vs baseline	ใช้เมื่อไหร่
int8 (Q8_0-style, AVX2 maddubs)	1.4-2.5× faster	matmul ทั่วไป
int4 (packed, dequant-on-use)	1.8× in batch	expert matmul
int4 single-row	slower → fallback to f32	routing decision

119 GFLOP/s measured — routing ตัดสินใจต่อ shape โดย measurement — int4 single-row วัดแล้วช้ากว่า f32 เลย fallback [1]

6. Async Expert Readahead + Router-Lookahead

Async readahead: ขณะที่ kernel กำลังคูณ expert block หนึ่ง — kernel ถัดไปกำลังอ่าน expert ถัดไปจาก disk (WILLNEED) [1]

Router-lookahead prefetch (PILOT=1, experimental): GLM-5.2's expert routing สามารถทำนายล่วงหน้าได้ — เอา router ของ layer L+1 มารันบน post-attention state ของ layer L — recall 71.6% ของ top-8 จริง (เทียบกับ 41.3% สำหรับ "ใช้ expert เดิมกับ token ที่แล้ว") — I/O thread แยก prefetch experts ที่น่าจะถูกใช้ขณะที่ layer ปัจจุบันกำลัง compute [1]

7. Learning Cache — ยิ่งใช้ยิ่งเร็ว

Colibri บันทึกว่า experts ตัวไหนถูกใช้บ่อย (.coli_usage — อัปเดตทุก turn) — ตอน startup จะ pin experts ที่ร้อนที่สุดไว้ใน RAM ว่างโดยอัตโนมัติ — Colibri เร็วยิ่งขึ้นเมื่อคุณใช้มันมากขึ้น [1]

Live tier adaptation (--repin N): ทุก N tokens — session heat map แบบ decaying จะแทนที่ cold pinned experts ด้วย hot streamed experts — 25% hysteresis + four-swap limit ป้องกัน tier thrashing [1]

8. Batch-Union MoE + RAM Safety

Batch-Union MoE: ใน prefill และ MTP verification — expert แต่ละตัวที่ถูกเลือกโดย batch จะถูกอ่านครั้งเดียวแล้ว apply กับทุก position ที่ route ไปหามัน [1]

RAM safety: expert cache auto-sized จาก MemAvailable ตอน startup — honest peak projection (working set, KV, MTP row, reconstruction buffers) — kernel OOM-killer ไม่เคยถูกยิง [1]

Performance — ตัวเลขจริงจากเครื่องจริง

Dev Machine (WSL2, 12 cores, 25 GB RAM, NVMe via VHDX)

Metric	Value
Model on disk (int4)	~370 GB
Resident RAM	9.9 GB
Load time	~30 s
Peak RSS	~20 GB (auto-capped)
Cold decode cost	~11 GB disk reads/token
Disk ceiling (VHDX random)	~1 GB/s
Cold speed	~0.05–0.1 tok/s
MTP speculation	2.2–2.8 tok/forward

Community Benchmarks

Machine	Disk (iobench)	Config	Speed
Intel Core Ultra 7 270K Plus (24 threads) · WSL2 · 24 GB RAM	1.96 GB/s buffered	default	0.07 tok/s
〃	〃	--topp 0.7	0.11 tok/s
Apple M5 Max (18 cores) · 128 GB unified · internal SSD	14.2 GB/s O_DIRECT	default, MTP off	1.06 tok/s
Framework 13 (learned cache)	—	—	0.37 tok/s
Ryzen 9 9950X · PCIe 5.0 NVMe	—	—	0.28 tok/s
Epyc 9654 ES · Linux · DDR5-4800	—	MTP on	0.40 tok/s

Performance Projections (ยังไม่วัด — คาดการณ์จากคอขวด)

Hardware	Expected
PCIe4 NVMe (~3-5 GB/s random), 32 GB	~0.5–1 tok/s
PCIe5 NVMe หรือ 2×NVMe RAID0 (~8-12 GB/s), 64 GB (PIN ~40 GB)	~2–4 tok/s
128-256 GB RAM, 12 cores (hot experts cached)	~2–4 tok/s (matmul-bound)
Same RAM + 24-32 cores หรือ AVX-512/VNNI kernels	~5–15 tok/s (interactive)

คอขวด: ต่ำกว่า 5 GB/s → disk-bound — เกิน 5 GB/s → CPU matmul-bound — เพิ่ม cores ช่วยได้ [1]

OpenAI-Compatible API

Colibri มี coli serve — OpenAI-compatible HTTP API — text-only — SSE streaming:

COLI_MODEL=/nvme/glm52_i4 COLI_API_KEY=*** ./coli serve \
  --host 127.0.0.1 --port 8000 --model-id glm-5.2-colibri

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Authorization: Bearer ***' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "glm-5.2-colibri",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": true
  }'

Endpoints: GET /v1/models, GET /v1/models/{model}, POST /v1/chat/completions, POST /v1/completions [1]

Isolated KV contexts (--kv-slots N): แยก conversation contexts ได้สูงสุด 16 slots — แต่ละ slot มี KV-cache, MTP window, และ crash-safe persistence file ของตัวเอง — engine ยัง execute ทีละ sequence — นี่คือ explicit KV ownership ไม่ใช่ continuous batching ปลอมๆ [1]

Extension enable_thinking: true: เปิด GLM-5.2's reasoning block — reasoning_effort field ก็ใช้ได้เหมือนกัน [1]

Web Interface

web/ — React + TypeScript (~390 lines) — pure API client — พูด OpenAI Chat Completions protocol + SSE streaming — ใช้ได้กับ Colibri server หรือ endpoint อะไรก็ได้ที่ compatible [1]

CUDA Backend (Experimental)

Colibri มี opt-in CUDA backend สำหรับ model-resident tensors — streaming experts ยังอยู่บน CPU path — เพราะการ copy expert จาก NVMe → GPU ทุกครั้งแค่เปลี่ยนคอขวดจาก disk เป็น PCIe [1]

make CUDA=1
COLI_CUDA=1 COLI_GPU=0 CUDA_DENSE=1 ./glm 64 4 4

Multi-GPU expert tier: ปัก experts ที่ร้อนที่สุดใน VRAM แบบถาวร — budget แบ่งตาม device ที่โหลดน้อยที่สุด:

COLI_CUDA=1 COLI_GPUS=0,1,2,3,4,5 CUDA_EXPERT_GB=96 \
PIN=stats.txt PIN_GB=160 ./glm 64 4 4

ข้อจำกัดปัจจุบัน: devices ใช้ independent contexts — synchronous host-staged activation copies — ยังไม่มี P2P/NCCL — kernels เป็น correctness-first custom kernels ยังไม่ใช่ cuBLAS/Tensor Core [1]

Offline Converter — ไม่ต้องมี 756 GB FP8 checkpoint

c/tools/convert_fp8_to_int4.py — ดาวน์โหลดทีละ shard (~5 GB) — dequant (128×128 block scales) — requantize เป็น container ของ engine — ลบ shard — 756 GB FP8 checkpoint ไม่เคยต้องอยู่บนดิสก์พร้อมกัน — resumable [1]

หรือใช้ pre-converted model บน Hugging Face: jlnsrk/GLM-5.2-colibri-int4 (~370 GB) [3]

เมื่อไหร่ที่ควรใช้ Colibri

Use Case	ทำไมถึงเหมาะ
Batch processing	Legal document review, large corpus analysis, offline summarization — queue งานแล้วรอ — 2,000-token response ใช้เวลา 30-100 นาที — โอเคสำหรับ overnight jobs [2]
Privacy-sensitive data	Medical notes, confidential business analysis, personal data — ไม่มี API call, ไม่มี telemetry, ไม่มี cloud — ข้อมูลไม่เคยออกจากเครื่อง [2]
Research & Evaluation	GLM-5.2 คือ MIT-licensed — รัน evaluation harnesses, ศึกษา model behavior, fine-tune — zero marginal cost ต่อ token [2]
Early Exploration	รัน prompt สองสามพันครั้งผ่าน GLM-5.2 เพื่อเข้าใจ capabilities ก่อน commit API contract — ช้าดีกว่าแพง [2]
Interactive (ใกล้ถึงแล้ว)	1 tok/s บน M5 Max — ยังไม่ใช่ production speed แต่ใช้ทดลอง interactive ได้ — PCIe 5.0 machines กำลังเข้าใกล้ความเร็วที่ใช้ได้จริง [2]

เมื่อไหร่ที่ไม่ควรใช้

Use Case	ทำไมถึงไม่เหมาะ
Interactive chatbot	0.1 tok/s — ใช้ไม่ได้ — มนุษย์รอไม่ไหว [2]
Coding assistant	รอ 10 นาทีเพื่อ complete function — ไม่ใช่ assistant [2]
Production API	Single-generation-at-a-time — concurrent requests เข้าคิว — ไม่ใช่ horizontal scaling [1]
Low-latency anything	Disk คือคอขวด — latency วัดเป็นนาที ไม่ใช่มิลลิวินาที

วิเคราะห์ — ทำไม Colibri ถึงสำคัญสำหรับโปรแกรมเมอร์

1. พิสูจน์ว่า "รันโมเดลใหญ่บนเครื่องเล็ก" เป็นไปได้ — โดยไม่ใช้ GPU

Colibri ทลายความเชื่อที่ว่า "744B model ต้องใช้ H100 8 ใบ" — มันพิสูจน์ว่าถ้าคุณเข้าใจ architecture ของโมเดล (MoE sparsity, MLA compression, DSA sparse attention) — คุณสามารถรันมันบนเครื่องที่ราคาถูกกว่า H100 หนึ่งใบได้ [1]

2. Pure C, Zero Dependencies — อ่านได้ เข้าใจได้ แก้ได้

c/glm.c — ~2,400 บรรทัด — ไฟล์เดียว — ไม่มี BLAS, ไม่มี Python runtime, ไม่มี Docker — แค่ gcc + OpenMP + AVX2 [1]

สำหรับโปรแกรมเมอร์ที่อยากเข้าใจว่า inference engine ทำงานยังไง — นี่คือ codebase ที่อ่านจบได้ในบ่ายเดียว

3. Learning Cache — แนวคิดที่ฉลาด

แทนที่จะพยายามทำทุกอย่างให้เร็วตั้งแต่แรก — Colibri ยอมรับว่ามันช้า — แล้วใช้ learning cache ทำให้เร็วขึ้นเมื่อคุณใช้มันมากขึ้น — นี่คือแนวคิดที่ต่างจาก "optimize for first token" ที่ทุกคนทำ [1]

4. MTP Speculative Decoding แบบ Lossless

MTP head ที่ int8 — 39-59% draft acceptance — 2.2-2.8 tokens/forward — lossless — validated ด้วย rejection sampling — นี่คือเทคนิคที่ทุก inference engine ควรมี [1]

5. KV-cache Persistence — ปิดเครื่องแล้วเปิดใหม่ ยังจำได้

Compressed MLA KV-cache — 576 floats/token — เซฟลงดิสก์หลังทุก turn — crash-safe — เปิดใหม่พรุ่งนี้ — zero re-prefill — นี่คือ feature ที่แม้แต่ ChatGPT ยังไม่มี [1]

ข้อจำกัดที่ควรรู้

ข้อจำกัด	รายละเอียด
ความเร็ว	0.05-1 tok/s — ไม่ใช่ interactive speed
Disk	ต้องการ NVMe ~400 GB — ext4 — ห้าม network/9p mount
CPU-only	AVX2 required — ARM ไม่รองรับ (ยกเว้น Apple Silicon ผ่าน Rosetta? — ยังไม่ test)
Single sequence	Execute ทีละ sequence — concurrent requests เข้าคิว
Text-only	API เป็น text-only — ไม่มี image/audio input
Linux/WSL2	ไม่มี native Windows build — macOS ยัง experimental
MTP head ต้อง int8	int4 MTP head ใช้ไม่ได้ — ต้องโหลด int8 head แยก

สรุป

Colibri ไม่ได้พยายามเป็น inference engine ที่เร็วที่สุด — มันพยายามเป็น inference engine ที่เล็กที่สุดที่ยังตอบถูกต้อง — และมันทำสำเร็จ

สำหรับโปรแกรมเมอร์ — Colibri คือ:

บทเรียนสถาปัตยกรรม — วิธีแยกโมเดล MoE เป็น resident + streamed parts
บทเรียน optimization — MLA compression, MTP speculation, learning cache, async readahead
บทเรียนความเรียบง่าย — 2,400 บรรทัด Pure C — zero dependencies — อ่านจบได้ในบ่ายเดียว
บทเรียนความทะเยอทะยาน — "รัน 744B model บนเครื่อง 25 GB RAM" — และทำได้จริง

ลองวันนี้:

git clone https://github.com/JustVugg/colibri
cd colibri/c && ./setup.sh
hf download jlnsrk/GLM-5.2-colibri-int4 --local-dir /nvme/glm52_i4
COLI_MODEL=/nvme/glm52_i4 ./coli chat

แล้วคุณจะได้คุยกับ 744B frontier model — บนเครื่องคุณเอง — โดยไม่ต้องใช้ GPU สักใบ

[1] JustVugg, "colibri — Run GLM-5.2 (744B MoE) on a 25GB-RAM consumer machine", GitHub, July 2026. https://github.com/JustVugg/colibri
[2] ChatForest (Grove), "Colibri Runs a 744B Model on 25 GB of RAM — Here Is the Architecture and When It Makes Sense for Builders", July 11, 2026. https://chatforest.com/builders-log/colibri-engine-glm-5-2-744b-local-inference-disk-streaming-moe-builder-guide/
[3] jlnsrk, "GLM-5.2-colibri-int4", Hugging Face, July 2026. https://huggingface.co/jlnsrk/GLM-5.2-colibri-int4
[4] PromptZone, "Colibri Runs GLM 5.2 on Low-End Hardware", July 2026. https://www.promptzone.com/priya_sharma_8c5c4c03/colibri-runs-glm-52-on-low-end-hardware-4gbd
[5] Luca Berton, "GLM-5.2 744B: Sparse Attention Meets Efficient MoE", June 2026. https://lucaberton.com/blog/glm-5-2-744b-moe-architecture-2026/
[6] Labellerr, "7 Top Mixture of Experts AI Models for Developers in 2026", June 2026. https://www.labellerr.com/blog/top-open-source-moe-llms/

DEV Community

Colibri — รัน GLM-5.2 (744B MoE) บนเครื่อง 25GB RAM ด้วย Pure C ไฟล์เดียว

Colibri — รัน GLM-5.2 (744B MoE) บนเครื่อง 25GB RAM ด้วย Pure C ไฟล์เดียว

TL;DR

Highlight — "Tiny engine, immense model"

GLM-5.2 คืออะไร — ทำความเข้าใจโมเดลก่อน

Colibri ทำงานยังไง — สถาปัตยกรรมเชิงลึก

1. แยกโมเดลเป็นสองส่วน

2. MLA Attention — บีบ KV-cache 57 เท่า

3. DSA Sparse Attention — เลือก attend แค่ 2,048 tokens

4. MTP Speculative Decoding — 2.2-2.8 tokens/forward

5. Integer-Dot Kernels — 119 GFLOP/s บน AVX2

6. Async Expert Readahead + Router-Lookahead

7. Learning Cache — ยิ่งใช้ยิ่งเร็ว

8. Batch-Union MoE + RAM Safety

Performance — ตัวเลขจริงจากเครื่องจริง

Dev Machine (WSL2, 12 cores, 25 GB RAM, NVMe via VHDX)

Community Benchmarks

Performance Projections (ยังไม่วัด — คาดการณ์จากคอขวด)

OpenAI-Compatible API

Web Interface

CUDA Backend (Experimental)

Offline Converter — ไม่ต้องมี 756 GB FP8 checkpoint

เมื่อไหร่ที่ควรใช้ Colibri

เมื่อไหร่ที่ไม่ควรใช้

วิเคราะห์ — ทำไม Colibri ถึงสำคัญสำหรับโปรแกรมเมอร์

1. พิสูจน์ว่า "รันโมเดลใหญ่บนเครื่องเล็ก" เป็นไปได้ — โดยไม่ใช้ GPU

2. Pure C, Zero Dependencies — อ่านได้ เข้าใจได้ แก้ได้

3. Learning Cache — แนวคิดที่ฉลาด

4. MTP Speculative Decoding แบบ Lossless

5. KV-cache Persistence — ปิดเครื่องแล้วเปิดใหม่ ยังจำได้

ข้อจำกัดที่ควรรู้

สรุป

Top comments (0)