Show HN: 느린 컴퓨터에서 GLM 5.2 실행하기

• colibrì는 GLM-5.2 744B MoE를 소비자용 머신의 약 25GB RAM에서 실행하도록 만든 순수 C 엔진이며, 라우팅된 expert를 디스크에서 스트리밍해 GPU 없이 동작함
• 핵심 구조는 dense 부분 약 17B 파라미터를 int4로 RAM에 상주시켜 9.9GB를 쓰고, 21,504개 라우팅 expert는 약 370GB 디스크에 두고 필요할 때 읽는 방식임
• 구현에는 GLM-5.2 forward, MLA attention과 압축 KV-cache, DeepSeek-V3 스타일 router, MTP speculative decoding, int8/int4/int2 양자화 커널, byte-level BPE tokenizer가 포함됨
• WSL2 12코어·25GB RAM·NVMe VHDX 환경에서 로드 시간은 약 30초, 채팅 중 peak RSS는 약 20GB, cold decode는 토큰당 약 11GB 디스크 읽기로 0.05~0.1 tok/s 수준임
• 빠른 NVMe와 더 큰 RAM에서는 캐시와 pinning이 중요하며, 실제 커뮤니티 측정에서 Apple M5 Max 128GB 환경은 MTP off 기준 1.06 tok/s를 기록함

colibrì가 해결하려는 문제

• colibrì는 “Tiny engine, immense model”을 표방하며, GLM-5.2 744B-parameter MoE 모델을 약 25GB RAM의 소비자용 머신에서 실행하는 엔진임
• 런타임은 순수 C이며 Python, BLAS, GPU 의존성이 없음
• 엔진은 c/glm.c 단일 C 파일 약 1,300줄과 작은 헤더들로 구성됨
• 예시 실행은 ./coli chat이며, 출력 예시는 colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU와 약 32초 준비 시간, 9.9GB resident 메모리를 보여줌

디스크 스트리밍 기반 MoE 실행 방식

• GLM-5.2의 744B Mixture-of-Experts 모델은 토큰당 약 40B 파라미터만 활성화됨
• 토큰마다 바뀌는 라우팅 expert는 약 11GB에 해당함
• dense 부분은 RAM에 상주함
  • attention, shared experts, embeddings를 포함
  • 약 17B 파라미터
  • int4 기준 약 9.9GB RAM 사용
• 라우팅 expert는 디스크에 저장됨
  • 75개 MoE layer × 256 experts와 MTP head 포함
  • 총 21,504개 routed experts
  • expert당 int4 기준 약 19MB
  • 전체 디스크 사용량은 약 370GB
• expert 로딩은 per-layer LRU cache, optional pinned hot-store, OS page cache를 사용함

구현된 주요 기능

• GLM-5.2 forward는 glm_moe_dsa 구조에 맞춰 구현됐고, transformers oracle 기준으로 token-exact 검증됨
  • tiny-random 모델에서 teacher-forcing 32/32
  • greedy generation 20/20
• MLA attention은 q/kv-LoRA와 interleaved partial RoPE를 포함함
  • 압축 KV-cache는 토큰당 576 floats 사용
  • 기존 32,768 floats/token 대비 57배 작음
  • GLM-5.2는 64 heads이며 GQA가 없음
• DeepSeek-V3 스타일 sigmoid router를 구현함
  • noaux_tc
  • routed_scaling_factor
  • shared expert
  • first-3-dense layers
• Native MTP speculative decoding은 GLM-5.2의 multi-token-prediction head(layer 78)가 draft token을 만들고 main model이 batched forward로 검증함
  • MTP head는 int8이어야 함
  • int4에서는 draft acceptance가 0~4%로 떨어져 speculation이 동작하지 않음
  • int8에서는 acceptance가 39~59%, 2.2~2.8 tokens/forward로 측정됨
  • rejection sampling을 통해 sampling 중에도 lossless로 유지됨
  • cold cache에서는 verified draft가 추가 expert를 라우팅해 expert-loads/token이 약 660에서 약 1100으로 늘 수 있음
  • 이 경우 cache와 pin이 warm-up되기 전에는 시간이 더 걸릴 수 있어 adaptive guard와 DRAFT=0 옵션이 있음
• True sampling은 temperature와 nucleus를 지원함
  • 기본값은 0.7 / 0.90
  • 공식 1.0 / 0.95 설정은 int4 환경에서 tail의 양자화 노이즈를 샘플링한다고 설명함
• integer-dot kernel은 Q8_0-style int8 activations와 AVX2 maddubs를 사용함
  • int8 matmul은 1.4~2.5배 빠름
  • 측정 성능은 119 GFLOP/s
  • int4는 batch에서 1.8배 빠름
  • int4 single-row는 측정상 더 느려 f32로 유지됨
• MLA weight absorption은 decode에서 per-token k/v reconstruction을 피함
  • query가 kv_b를 흡수하고, context는 attention 이후 projection됨
  • forced absorption 환경에서도 TF 32/32와 generation 20/20으로 검증됨
• expert readahead는 한 expert block을 곱하는 동안 다음 block을 WILLNEED로 읽음
• 양자화 커널은 int8, packed int4, packed int2, per-row scales, AVX2, dequant-on-use를 지원함
• DSA sparse attention은 진행 중임
  • lightning-indexer weights는 FP8 repo에서 약 108GB를 추출하는 형태
  • indexer forward는 다음 단계로 예정됨
  • 그 전까지 attention은 context ≤ 2048 tokens에서 dense이고 exact임
• prefill과 MTP verification에서는 Batch-union MoE가 batch의 unique expert를 한 번만 읽고, 해당 expert로 라우팅된 모든 position에 적용함
• tokenizer는 C로 구현된 byte-level BPE tokenizer이며 GPT-2 스타일 Unicode-property regex와 320k merges를 사용함
• RAM 안전 장치는 시작 시 MemAvailable을 기준으로 expert cache를 자동 크기 조정함
  • working set, KV, MTP row, reconstruction buffer의 peak projection을 반영함
  • kernel OOM-killer가 동작하지 않도록 설계됨
• offline converter는 c/convert_fp8_to_int4.py로 제공됨
  • GLM-5.2 FP8 shard를 한 번에 하나씩 다운로드함
  • 128×128 block scales로 dequant 후 엔진 container로 requantize함
  • shard를 삭제하며 진행하므로 756GB FP8 checkpoint 전체가 동시에 디스크에 존재할 필요가 없음
  • 변환은 재개 가능함

측정된 기본 성능과 제약

• 개발 환경은 WSL2, 12코어, 25GB RAM, NVMe via VHDX임
• 측정값은 다음과 같음
  • int4 container 모델 크기: 약 370GB
  • resident RAM: 9.9GB
  • load time: 약 30초
  • 채팅 중 peak RSS: 약 20GB, auto-capped
  • cold decode cost: 토큰당 약 11GB disk reads
  • VHDX random disk ceiling: 약 1GB/s
  • cold decode 속도: 약 0.05~0.1 tok/s
  • MTP speculation: int8 head 기준 2.2~2.8 tok/forward
• 빠른 시스템이 아니라는 점을 명시하며, warm cache, pinned hot experts, MTP가 useful-response latency를 줄인다고 설명함
• SSD 관련 주의점은 두 가지임
  • colibrì streaming은 read-only라 읽기 자체는 SSD 마모에 의미 있는 영향을 주지 않음
  • RAM 부족으로 swap traffic이 생기면 write가 발생해 드라이브를 마모시킬 수 있음
  • 장시간 full read duty cycle은 저가형 드라이브를 가열할 수 있어 온도와 health monitoring이 필요함

모델 다운로드와 실행

• 사전 변환된 GLM-5.2 int4 모델은 Hugging Face에 제공됨
  • GLM-5.2-colibri-int4
• 사전 변환 모델을 받으면 FP8 → int4 변환 단계를 건너뛸 수 있음
• 실행은 COLI_MODEL을 모델 디렉터리로 지정함

• quick start는 c 디렉터리에서 ./setup.sh로 gcc/OpenMP 확인, 빌드, self-test를 수행함
• 직접 변환하려면 ./coli convert --model /nvme/glm52_i4를 사용함
  • 약 400GB 여유 공간이 있는 ext4/NVMe 경로가 필요함
  • 변환에는 Python과 torch, safetensors, huggingface_hub, numpy가 필요함
  • 런타임 엔진 자체는 순수 C이며 Python은 1회성 converter에만 쓰임
• 유용한 옵션은 다음과 같음
  • --temp T: sampling temperature, 기본 0.7과 nucleus 0.90, 0은 greedy
  • --topp 0.7: adaptive expert top-p, disk 사용 30~40% 감소
  • --ngen N: 답변당 최대 토큰 수
  • AUTOPIN=0: learning cache auto-pin 비활성화
  • THINK=1: GLM-5.2 reasoning block 활성화
  • DRAFT=n: MTP draft depth
  • TF=1: teacher-forcing validation

Learning cache와 하드웨어별 기대치

• Learning cache는 실제 사용에서 라우팅된 expert를 모델 옆 .coli_usage에 기록함
• 시작 시 spare RAM에 가장 hot한 expert를 자동 pin함
• 프로젝트 설명은 사용량이 쌓일수록 colibrì가 더 빨라진다고 밝힘
• 요구 환경은 Linux 또는 WSL2, OpenMP 지원 gcc, AVX2, 최소 16GB RAM, 약 370GB int4 모델이 있는 local NVMe임
  • ext4 경로를 권장함
  • network/9p mount는 사용하지 말라고 안내함
• 테스트 순서는 빌드와 self-test, iobench로 디스크 측정, chat에서 tok/s·expert hit-rate·RSS 확인, expert usage 기록 후 pinning, 품질 benchmark 실행임
• 하드웨어별 예상치는 측정이 아닌 추정값임
  • 개발 머신 WSL2 VHDX, 약 1GB/s, 25GB RAM: 0.05~0.1 tok/s cold
  • native Linux, PCIe4 NVMe 3~5GB/s random, 32GB: 0.5~1 tok/s
  • PCIe5 NVMe 또는 2×NVMe RAID0 8~12GB/s, 64GB, PIN 약 40GB: 2~4 tok/s
  • 128~256GB RAM, 12코어, hot experts cached: 2~4 tok/s
  • 같은 RAM에 24~32코어 또는 AVX-512/VNNI kernels: 5~15 tok/s

커뮤니티 벤치마크

• Intel Core Ultra 7 270K Plus, 24 threads, WSL2, 24GB RAM, NVMe VHDX 환경에서 기본 설정은 0.07 tok/s를 기록함
  • disk iobench: 1.96GB/s buffered, 2.74GB/s O_DIRECT
  • expert hit: 3~4%
  • RSS: 14.1GB
• 같은 환경에서 --topp 0.7은 0.11 tok/s를 기록함
  • expert hit: 11%
  • RSS: 14.7GB
  • end-to-end 속도는 1.6배 증가함
• Apple M5 Max, 18 cores, macOS, 128GB unified memory, internal SSD 환경은 1.06 tok/s를 기록함
  • disk iobench: 14.2GB/s O_DIRECT
  • default, MTP off
  • expert hit: 23%
  • RSS: 21.8GB
• 24GB RAM 머신에서는 expert cache가 layer당 2 slot으로 auto-cap되어, 개발 머신보다 디스크가 2~2.7배 빨라도 decode가 cold 상태에 머묾
• 작은 RAM 머신에서는 디스크보다 RAM cap이 병목이 됨
• M5 Max 측정값은 744B 모델이 laptop SSD에서 약 1 tok/s를 내는 사례이며, 14GB/s 디스크는 병목을 다시 RAM budget과 kernel로 이동시킴

품질 벤치마크와 남은 측정

• int4 양자화가 정확도에 미치는 비용은 아직 측정되지 않음
• benchmark harness는 구현됐지만, 개발 머신의 약 1GB/s 디스크에서는 전체 실행에 하루의 상당 부분이 걸림
• 제공되는 benchmark 명령은 hellaswag, arc_challenge, mmlu를 실행함

• 출력은 task별 accuracy이며, log-likelihood scoring과 EleutherAI-harness 스타일을 사용함
• full-precision GLM-5.2의 공개 점수는 해당 task들에서 약 85~95%라고 적혀 있음
• int4 container가 몇 점 차이 안에 들어오면 양자화가 검증되고, 그렇지 않으면 mixed 또는 grouped-scale quantization에 투자할 근거가 됨

저장소 구성과 라이선스

• 주요 파일 구성은 다음과 같음
  • c/glm.c: GLM-5.2 forward, streaming MoE, MTP, serve mode를 포함한 엔진
  • c/st.h: pread와 fadvise 기반 safetensors reader, mmap 미사용
  • c/tok.h: C byte-level BPE tokenizer
  • c/coli: chat, run, bench, convert, info CLI
  • c/iobench.c: 엔진이 체감하는 parallel disk microbenchmark
  • c/convert_fp8_to_int4.py: disk-safe FP8 → int4 converter
  • c/make_glm_oracle.py: validation용 tiny-random oracle generator
  • c/olmoe.c: Stage-A engine이며 첫 validation target
• 이름 colibrì는 벌새가 적은 무게로 제자리 비행하고 하루에 많은 꽃을 방문하는 점에서 유래함
• 프로젝트 라이선스는 Apache 2.0이며, GLM-5.2 weights는 Z.ai가 MIT로 공개함