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

들어가며 — 25GB 램 노트북에 744B 모델을?
핵심 트릭 — MoE 희소성 + 디스크 스트리밍
견딜 만하게 만드는 장치들
정직한 부분 — 그래서 얼마나 빠른가
마치며 — 되는 것과 쓸 만한 것 사이
참고 자료

들어가며 — 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ì가 지금 어디쯤인지는 위 숫자들이 정직하게 말해 줍니다. 그래도 문단당 몇 분이 문장당 몇 초가 되는 날을 상상하는 건 그리 어렵지 않습니다.