Skip to content
←

Split View: 느린 컴퓨터에서 GLM-5.2 돌리기 — colibrì가 744B 모델을 디스크에서 스트리밍하는 법

|

느린 컴퓨터에서 GLM-5.2 돌리기 — colibrì가 744B 모델을 디스크에서 스트리밍하는 법

들어가며 — 25GB 램 노트북에 744B 모델을?

colibrì는 GLM-5.2를 평범한 소비자용 PC에서 돌리는 것을 목표로 하는 추론 엔진입니다. GLM-5.2는 colibrì 기준 총 744B(7,440억) 파라미터의 MoE 모델. 보통 이 규모는 GPU 여러 장과 수백 GB의 VRAM을 요구합니다. colibrì는 이걸 12코어 CPU와 25GB 램을 가진 기계에서 돌립니다. 순수 C로 작성된 약 1,300줄, 런타임 의존성 제로 — BLAS도 파이썬도 없습니다.

당연히 공짜는 아닙니다. 프로젝트가 내건 목표부터가 속도가 아닙니다. 요약하면 "12코어 노트북에서 25GB 램으로 GLM-5.2가 올바르게 답하게 하는 것, 설령 속도가 문단당 몇 분이 걸리더라도"입니다. 이 글은 colibrì가 실제로 무엇을 하는지, 어떤 트릭으로 그게 가능한지, 그리고 그게 실제로 얼마나 쓸 만한지를 정직하게 봅니다.

핵심 트릭 — MoE 희소성 + 디스크 스트리밍

두 가지 사실이 맞물립니다.

첫째, GLM-5.2는 MoE입니다. 토큰 하나를 만들 때 744B 전부가 아니라 약 40B만 활성화됩니다. 파라미터는 "전문가(expert)"로 잘게 나뉘어 있고, 매 토큰마다 라우터가 입력에 맞는 소수만 골라 씁니다. colibrì 기준 라우팅 전문가는 21,504개(75개 MoE 레이어 × 256개), int4로 각각 약 19MB입니다.

둘째, 그래서 전부를 램에 올릴 필요가 없습니다. colibrì는 모델을 둘로 쪼갭니다.

  • 밀집(dense) 부분 — 어텐션·공유 전문가·임베딩 약 17B. int4로 압축해 9.9GB만 램에 상주시킵니다.
  • 라우팅 전문가 — 약 370GB(int4 컨테이너). NVMe SSD에 두고, 토큰마다 필요한 것만 읽어 옵니다.

즉 "거대한 모델, 작은 엔진"입니다. 매 토큰의 병목은 계산이 아니라 디스크 읽기입니다 — 콜드 상태에서 토큰 하나당 약 11GB를 SSD에서 읽습니다(75 레이어 × 8 전문가). 이 디스크 대역폭이 속도의 상한을 정합니다.

견딜 만하게 만드는 장치들

디스크 스트리밍은 본질적으로 느립니다. colibrì에서 흥미로운 건 그 느림을 갉아먹는 방법들입니다.

  • 학습 캐시(learning cache) — 실제 사용에서 어떤 전문가가 자주 불리는지 .coli_usage에 매 턴 기록하고, 다음 시작 때 그 "뜨거운" 전문가들을 남는 램에 미리 고정(pin)합니다. 쓸수록 빨라진다는 뜻이며, --repin으로 세션 중 실시간 재배치도 됩니다.
  • MTP 추측 디코딩 — GLM-5.2의 multi-token prediction 헤드로 여러 토큰을 미리 던지고 한 번에 검증합니다. int8 헤드 기준 forward당 2.2–2.8 토큰, 수용률 39–59% 실측. 헤드를 int4로 낮추면 수용률이 0–4%로 붕괴하기 때문에 헤드만 int8로 유지합니다.
  • 압축 KV 캐시 — 토큰당 576 float로, 원래의 32,768 대비 57배 작습니다. 대화는 엔진을 재시작해도 warm하게 이어집니다.
  • 비동기 선읽기·배치 통합 — 한 블록을 곱하는 동안 다음 블록을 미리 읽고, 한 배치 안에서 같은 전문가는 한 번만 읽습니다.

양자화가 이 모든 것의 바닥입니다. int4 컨테이너에 per-row 스케일, AVX2 커널에서 dequant-on-use. 양자화 정리 글에서 다룬 "비트를 줄여 메모리·대역폭을 산다"는 싸움이, 여기서는 "디스크에서 읽어야 할 바이트 수를 줄인다"로 그대로 이어집니다.

실제로 돌리려면 하한은 이렇고, 진입 모드는 네 가지입니다.

# 하드웨어 하한 (README 기준)
OS:    Linux 또는 WSL2       CPU: AVX2, 12코어 이상
RAM:   16GB 이상 (캐시 자동 상한, 피크 약 20GB)
Disk:  약 370GB 로컬 NVMe (ext4) — 네트워크 마운트는 불가

# 실행 모드
./coli chat     # 대화형 CLI
./coli serve    # OpenAI 호환 API (텍스트 전용)
./coli bench    # MMLU / HellaSwag / ARC
./coli plan     # 헤더만 읽는 드라이런, 할당 제로

정직한 부분 — 그래서 얼마나 빠른가

느립니다. 콜드 상태 약 0.05–0.1 tok/s — 사실상 10~20초에 한 단어입니다. 로드에만 약 30초. 커뮤니티가 올린 실측은 하드웨어에 따라 갈립니다: M5 Max(128GB) 1.06 tok/s, Framework 13(128GB + 학습 핀) 0.37 tok/s, PCIe5 NVMe를 단 9950X 0.28 tok/s. 가장 좋은 경우도 초당 한 토큰 남짓입니다.

이건 대화형 도구가 아닙니다. 한 문단에 몇 분이 걸립니다. 그러면 언제 쓰나?

  • 클라우드가 불가능하거나 금지된 곳 — 오프라인, 에어갭, 규제 환경.
  • 프라이버시가 절대 조건일 때 — 데이터가 기계를 떠나면 안 되는 경우.
  • 하드웨어를 안 사고 그냥 실험할 때 — 낡은 데스크톱에서 744B 모델의 출력을 눈으로 확인하고 싶을 때.

프로덕션 처리량이 필요하다면 답은 명확합니다: GPU를 제대로 할당하세요. colibrì도 그걸 대체하려는 게 아닙니다 — ./coli serve로 OpenAI 호환 API를 열 수는 있지만, 그 속도로 서비스를 태울 수는 없습니다.

마치며 — 되는 것과 쓸 만한 것 사이

colibrì에서 진짜 흥미로운 건 속도가 아니라 성립 그 자체입니다. "GPU 없이는 불가능"이라 여겨지던 규모가, MoE 희소성 + 디스크 스트리밍 + 영리한 캐싱으로 25GB 램 기계에서 어쨌든 답을 냅니다. 되는 것과 쓸 만한 것은 분명 다르지만, 되는 것이 먼저 증명되어야 쓸 만한 것도 뒤따라옵니다.

로컬 추론의 민주화는 대개 이 순서로 왔습니다 — 먼저 "미친 짓인데 되네", 그다음 몇 년에 걸쳐 "이제 실용적이네". llama.cpp도 그렇게 시작했습니다. colibrì가 지금 어디쯤인지는 위 숫자들이 정직하게 말해 줍니다. 그래도 문단당 몇 분이 문장당 몇 초가 되는 날을 상상하는 건 그리 어렵지 않습니다.

참고 자료

Running GLM-5.2 on a slow computer — how colibrì streams a 744B model from disk

Introduction — a 744B model on a 25GB-RAM laptop?

colibrì is an inference engine built to run GLM-5.2 on an ordinary consumer PC. As colibrì describes it, GLM-5.2 is a Mixture-of-Experts model with 744B total parameters. A model this size normally demands several GPUs and hundreds of gigabytes of VRAM. colibrì runs it on a 12-core CPU with 25GB of RAM — from roughly 1,300 lines of pure C, with zero runtime dependencies: no BLAS, no Python.

It is not free, of course. The project's stated goal is not speed at all. Paraphrased: make GLM-5.2 answer correctly on a 12-core laptop with 25GB of RAM, "even if speed is measured in minutes per paragraph." This post looks honestly at what colibrì actually does, the tricks that make it possible, and how usable the result really is.

The core trick — MoE sparsity plus disk streaming

Two facts interlock.

First, GLM-5.2 is MoE. Generating one token activates roughly 40B of the 744B, not all of it. The parameters are split into "experts," and per token a router picks only the few that fit the input. In colibrì's build there are 21,504 routed experts (75 MoE layers × 256), each about 19MB at int4.

Second, that means you do not need all of it in RAM. colibrì splits the model in two.

  • Dense part — attention, shared experts, embeddings, about 17B. Compressed to int4, only 9.9GB stays resident in RAM.
  • Routed experts — about 370GB (int4 container). They live on an NVMe SSD, and only the ones a token needs get read in.

So: a giant model, a tiny engine. The per-token bottleneck is not compute but disk reads — cold, one token costs roughly 11GB read from SSD (75 layers × 8 experts). That disk bandwidth sets the speed ceiling.

The machinery that makes it bearable

Disk streaming is inherently slow. The interesting part of colibrì is how it chips away at that slowness.

  • Learning cache — it records which experts your real usage routes to, into .coli_usage, updated every turn, and at the next startup pins the "hottest" ones into spare RAM. In other words it gets faster the more you use it; --repin even re-tiers live mid-session.
  • MTP speculative decoding — GLM-5.2's multi-token-prediction head drafts several tokens ahead and verifies them in one pass. With an int8 head, colibrì measures 2.2–2.8 tokens per forward at 39–59% acceptance. Drop the head to int4 and acceptance collapses to 0–4%, so only the head is kept at int8.
  • Compressed KV cache — 576 floats per token versus the original 32,768, 57× smaller. Conversations reopen warm even after the engine restarts.
  • Async readahead and batch union — the next block of experts is read while the current one is being multiplied, and within a batch each unique expert is read only once.

Quantization underpins all of it: an int4 container with per-row scales, AVX2 kernels doing dequant-on-use. The fight I covered in the quantization roundup — spend fewer bits to buy memory and bandwidth — carries straight over here as "read fewer bytes off the disk."

The practical floor to run it, and the four entry points:

# hardware floor (from the README)
OS:    Linux or WSL2        CPU: AVX2, 12+ cores
RAM:   >=16 GB (cache auto-capped, ~20 GB peak)
Disk:  ~370 GB local NVMe (ext4) — never a network mount

# run modes
./coli chat     # interactive CLI
./coli serve    # OpenAI-compatible API (text-only)
./coli bench    # MMLU / HellaSwag / ARC
./coli plan     # header-only dry run, zero allocation

The honest part — so how fast is it?

Slow. Cold, about 0.05–0.1 tok/s — effectively one word every 10–20 seconds. Load alone takes about 30s. Community-reported measurements vary by hardware: M5 Max (128GB) 1.06 tok/s, Framework 13 (128GB + learned pin) 0.37 tok/s, a 9950X with PCIe5 NVMe 0.28 tok/s. Even the best case is barely over a token per second.

This is not a conversational tool. A paragraph takes minutes. So when do you reach for it?

  • Where the cloud is impossible or forbidden — offline, air-gapped, regulated environments.
  • Where privacy is non-negotiable — the data must not leave the machine.
  • When you just want to experiment without buying hardware — to see a 744B model's output on an old desktop with your own eyes.

If you need production throughput the answer is clear: allocate proper GPUs. colibrì is not trying to replace that — you can open an OpenAI-compatible API with ./coli serve, but you cannot serve real traffic at that speed.

Closing — between "it works" and "it is usable"

What is genuinely interesting about colibrì is not the speed but the mere fact that it runs. A scale long treated as "impossible without a GPU" nonetheless produces answers on a 25GB-RAM machine, via MoE sparsity plus disk streaming plus clever caching. "It works" and "it is usable" are different things — but "it works" has to be proven first before "it is usable" can follow.

Democratizing local inference has usually arrived in that order — first "this is insane but it runs," then, over years, "this is actually practical." llama.cpp began exactly that way. Where colibrì sits today, the numbers above say honestly enough. Still, it is not hard to imagine the day minutes-per-paragraph becomes seconds-per-sentence.

References