# Show HN: 느린 컴퓨터에서 GLM 5.2 실행하기 > Clean Markdown view of GeekNews topic #31297. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31297](https://news.hada.io/topic?id=31297) - GeekNews Markdown: [https://news.hada.io/topic/31297.md](https://news.hada.io/topic/31297.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-10T14:39:25+09:00 - Updated: 2026-07-10T14:39:25+09:00 - Original source: [github.com/JustVugg](https://github.com/JustVugg/colibri) - Points: 2 - Comments: 1 ## Topic Body - 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](https://huggingface.co/jlnsrk/GLM-5.2-colibri-int4) - 사전 변환 모델을 받으면 FP8 → int4 변환 단계를 건너뛸 수 있음 - 실행은 `COLI_MODEL`을 모델 디렉터리로 지정함 ```bash COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat ``` - 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`를 실행함 ```bash cd c ./coli bench ./coli bench hellaswag --limit 200 ./coli bench mmlu arc_challenge --ram 100 ``` - 출력은 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로 공개함 ## Comments ### Comment 61532 - Author: neo - Created: 2026-07-10T14:39:26+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48842459) - 실제로 쓸 때 **토큰/초**로 측정될 수준인지, 아니면 1분에 1토큰에 가까운지가 가장 궁금함 로컬 LLM이 1토큰/초처럼 느려도 밤새 프로젝트를 맡겨두고 6~8시간 뒤 결과를 확인하는 식이면 꽤 유용했음 반면 링크에 나온 최저 사양 하드웨어의 0.05~0.1토큰/초는 쓸 만한 용도가 거의 없어 보임 그래도 전체 개념은 훌륭하고, 일반인이 감당 가능한 하드웨어에서 350B~900B급 모델을 로컬로, 설령 1토큰/초라도 돌릴 수 있게 하는 시도가 더 많아지길 기대함 “빠른 읽기 성능의 NVMe SSD가 있고, 로컬 디스크에 거대한 모델이 있으니 전체를 올리지 말고 필요할 때 11GB/토큰씩 읽자”는 방향이 마음에 듦 - **Claude Cowork** 덕분에 응답 시간을 기다리는 데 익숙해졌다는 게 웃김 이제는 늦어도 2028년쯤이면 로컬에서 돌리고 있을 거라고 봄 예산은 1만 달러 이하로 잡고, 오늘날 최고 수준 모델에 견줄 만한 모델을 돌리고 싶음 - 느린 로컬 모델이나 일부 프로젝트에는 **채팅 인터페이스**가 잘못된 접근일 수 있고, 티켓 시스템 같은 형태가 더 맞을지도 모르겠음 Mac Studio나 GPU에 돈을 쓰기 전에 지금 가진 하드웨어로 이 아이디어를 검증하는 방법을 정했고, 이번 주에 개념 증명 정도는 만들 수 있을 듯함 새로운 아이디어는 아니고, 내 작업 방식에 맞게 돌아가게 만드는 시간이 필요할 뿐임 - README에 여러 하드웨어에서 Colibrì를 돌린 **벤치마크**가 있고, 꽤 좋은 시간을 본 적이 있음 계속 더 개선하려고 하고 있음 - 대부분의 프로젝트에는 **GLM 5.2를 무료로 제공하는 클라우드**를 쓰는 편이 더 실용적임 1분에 1토큰은 무료 사용량 제한과 비교해도 너무 작은 수치임 - 요즘 “일반인”이 **24GB RAM**과 0.5TB NVMe SSD를 감당할 수 있느냐는 생각이 듦 - Apple Silicon의 macOS를 대상으로 비슷한 것을 만들고 있음 **Unsloth split GGUF**, 통합 메모리에서 압축된 부분 상주 방식, 네이티브 Metal 커널, RAM 전용 네이티브 압축 KV를 쓰는 방향임 내 64GB보다는 128GB에서 더 말이 될 것 같고, 준비되면 GitHub에 올릴 생각임 - 128GB MacBook Pro M4가 기다리고 있어서 기꺼이 테스트해보고 싶음 - 이미지/비디오 생성 쪽에서도 [https://github.com/cretz/thinfer]()로 비슷한 전략을 써봤음 video 브랜치에 작업이 많이 들어가 있음 필요한 시점에 가중치를 **LRU 방식**으로 들여오고 내보낼 수 있는 추론 엔진이 계속 필요해서, 결국 `--vram-budget`을 받아 그 안에 머무르는 도구를 바이브 코딩으로 만들었음 mmap된 바이트를 VRAM 안팎으로 옮기는 비용은 계산에 비하면 꽤 싸다는 점이 드러났고, 파이프라이닝과 이중 버퍼링을 섞으면 거의 항상 메모리 병목이 아니라 계산 병목이 됨 물론 훨씬 작은 모델을 쓰고 있긴 함 - krea, wan, hunyan 등 정말 많은 모델을 넣은 것 같음 전부 실행할 수 있는 **공통 하네스**를 만든 건지 궁금함 어떤 모델들이 VRAM 예산 안에 더 일관되게 머무르는지도 궁금함 - **llama.cpp**는 다양한 4비트 이하 양자화를 지원하고 기본적으로 모델을 mmap하므로, 가중치 전체를 메모리에 들고 있을 필요가 없음 운영체제가 필요할 때 저장소에서 가져오게 됨 의존성 없이 아주 적은 코드로 구현한 건 멋지지만, 실제로 성능 이점이 있는지는 궁금함 - 꽤 멋짐 이번 주에 **GLM 5.2**를 다뤄봤는데 마찬가지로 인상적이었음 회사에서는 다음 프로젝트를 시작하기 전에 엄청 비싼 하드웨어에서 로컬 실행을 테스트 중인데, 이 거대한 오픈소스 모델 릴리스를 평균적인 머신에서 돌리는 사람들이 있다는 게 좋음 아직 실용성이 크지는 않더라도 좋은 작업임 - 어떤 하드웨어인지 궁금함 - LLM 내부 구조를 잘 알지는 못하지만, “층”이 있는 다른 모델에도 비슷한 구조를 쓸 수 있는지 궁금함 한 층이 작업을 끝내면 그 층을 RAM에서 제거하고, 다음 층을 디스크에서 로드한 뒤 첫 번째 층의 결과에 대해 활성화하는 식이 가능한지 궁금함 - RAM 64GB와 VRAM 24GB가 있는 머신이라, 이걸 **더 많은 RAM**을 쓰도록 조정할 수 있는지 궁금함 또는 GPU에서 Gemma/Qwen을 돌리고 GLM-5.2가 더 작은 작업을 거기에 위임하게 할 수도 있을 것 같음 GLM-5.2를 어느 정도 재학습해야 할지도 모름 여러 디스크를 병렬로 써서 대역폭을 늘리면 속도를 높일 수 있는지도 궁금함 SSD 마모 경고에는 콜드 스타트가 무작위 읽기 약 11GB/토큰으로 무겁고, 읽기 자체는 안전하지만 운영체제 페이지 캐시가 쓰기를 만들 수 있으며, 과도한 사용이 저가 SSD의 마모를 앞당길 수 있다고 되어 있음 안전한 방법으로는 모델 가중치용 별도 파티션을 만들고 읽기 전용으로 설정하는 게 가능할지도 모르겠음 페이지 캐시가 파티션 단위인지 디스크 단위인지 모르겠지만, 디스크 단위라면 읽기 전용 `data.iso`를 파티션처럼 포맷해 디스크로 마운트하는 방법도 있을 수 있음 - 작은 노트북을 쓰고 있음 디스크가 더 있다면 실제로 테스트를 해볼 수 있을 것임 벤치마크가 나오면 풀 리퀘스트나 이슈로 올려주면 같이 작업해볼 수 있음 - “운영체제 페이지 캐시가 쓰기를 만들 수 있다”는 게 **환각**인지 궁금함 뭘 놓치고 있는 걸까? 왜 대량 읽기가 쓰기를 만들지? - 좋은 아이디어일 수 있고, 같이 작업해볼 수 있음 - 페이지에 **SSD 마모 경고**가 있음 [https://github.com/JustVugg/colibri#ssd-wear-warning]() 직접 부품을 조립한 데스크톱 PC를 쓰면 SSD를 교체할 수 있지만, 납땜된 SSD를 쓰는 사용자는 어떻게 해야 할까? 이런 애플리케이션을 피하거나, 저장장치가 일찍 망가질 가능성을 감수하고 밀어붙여야 하나? 외장 저장장치를 소모품 SSD처럼 써야 할 듯함 - 피하는 게 맞음 납땜 SSD가 들어간 노트북은 사용량을 확실히 모니터링하고 조심해야 함 이 프로젝트는 모두가 돌릴 물건이라기보다는 실험에 가까워 보이지만, 그래도 꽤 멋짐 - 내가 이해한 바로는 경고가 **과도한 메모리 사용 중 스왑 아웃**에 관한 것임 여기서 미신적으로 생각할 필요는 없음 디스크 활동, 특히 쓰기는 측정할 수 있음 예를 들어 Linux에서는 `iostat`나 `vmstat`를 쓰면 됨 - 꽤 보수적인 경고임 애플리케이션은 쓰기를 수행하지 않으므로 실제로 애플리케이션 자체가 SSD를 마모시키지는 않음 나머지는 애플리케이션과 무관한 일반적인 관리 수칙에 가까움 - 그런 용도라면 외장 드라이브를 쓰는 게 맞을 것 같음 - 기술적으로는 인상적인데, 실제로 **실용적으로 쓸 수 있는지**가 궁금함 - 나도 사실 같은 걸 만들고 있었지만, 추가 RAM 사용을 피하려고 모델 전체를 메모리에 mmap하는 방향으로 갔음 또 Claude에게 모델에 **Medusa**[https://arxiv.org/abs/2401.10774]()를 구현하게 해서, 추가 모델을 메모리에 올리지 않고도 다중 토큰 예측의 이점을 얻어보려 했음 방금 집에 와서 덧붙이면, 모든 수정은 llama.cpp에 하고 있고, 최종 목표는 NVMe로 mmap 파일을 처리하는 단일 보드 컴퓨터 같은 곳에 올리는 것임 이전 테스트 기준으로 현재 구성의 이론적 한계는 약 1.8토큰/초로 보이지만, 추가 Medusa 헤드가 완전히 학습된 상태는 아니고 생성된 토큰으로 계산되는지도 솔직히 잘 모르겠음 결국 아이디어는 비슷해 보이지만, 나는 아직 LLM 파서/러너를 처음부터 작성할 줄 몰라서 무엇을 메모리에 남길지 지정하는 대신 Linux 커널에 맡겼음 마지막으로 llama.cpp 사용량을 내 32GB 중 16GB로 제한했으니, 더 낮추는 것도 가능할 수 있음 - Colibrì는 계속 개선이 필요하니 아이디어나 다른 것이 있으면 풀 리퀘스트, 이슈, 벤치마크 모두 환영함 - 내가 궁금해하던 접근 방식이 바로 이쪽이었음