7440억 파라미터 GLM-5.2를 25GB 램짜리 노트북에서 돌린 오픈소스 엔진

744B 모델을 통째로 올리지 않고, 필요한 조각만 읽어 온다는 발상

• colibrì는 GLM-5.2라는 7440억 파라미터급 혼합 전문가 모델(MoE)을 소비자용 머신에서 돌리려는 순수 C 추론 엔진임

  • 런타임에는 Python도, BLAS도, GPU도 필수로 쓰지 않음
  • 핵심 엔진은 c/glm.c 단일 C 파일 약 1300줄과 작은 헤더들로 구성됨
  • 목표는 빠른 추론이라기보다, 거대한 frontier급 모델을 25GB 램짜리 머신에서도 실제로 움직이게 만드는 쪽에 가까움

• 이게 가능한 이유는 GLM-5.2가 MoE라서 전체 744B를 매 토큰마다 다 쓰지 않기 때문임

  • 토큰 하나를 만들 때 실제 활성화되는 파라미터는 약 40B 수준
  • 그중 토큰마다 바뀌는 routed expert 부분은 약 11GB 정도라고 설명함
  • attention, shared expert, embedding 같은 dense 부분 약 17B 파라미터는 int4로 램에 상주시키면 약 9.9GB로 들어감

• 나머지 전문가 가중치는 디스크에 두고 필요할 때만 읽음

  • routed expert는 75개 MoE layer × 256개 expert에 MTP head까지 합쳐 21504개
  • int4 기준 expert 하나가 약 19MB이고, 전체 expert 저장 공간은 약 370GB
  • 각 layer마다 LRU cache를 두고, 자주 쓰는 expert는 pinned hot-store에 고정하며, 운영체제 page cache도 사실상 무료 L2 캐시처럼 활용함

병목은 연산보다 디스크, 그리고 램 캐시

• 차가운 캐시 상태에서는 토큰 하나를 만들 때 약 11GB의 디스크 read가 발생함

  • 계산식은 대략 75개 layer × 8개 expert 로드
  • 개발 환경의 WSL2 VHDX 랜덤 read 한계가 약 1GB/s라서 cold decode는 0.05~0.1 tok/s 수준
  • 말 그대로 토큰 하나 뽑는 데 수십 초가 걸릴 수 있는 구조임

• 그래도 SSD read 중심이라 디스크 수명 측면에서는 write-heavy 작업보다 덜 위험하다고 봄

  • 진짜 위험은 램이 부족해서 swap이 발생하는 경우임
  • swap write는 SSD에 부담을 주고, 성능도 바로 박살남
  • 그래서 엔진이 시작 시점에 MemAvailable을 보고 expert cache 크기를 자동 조절함

• 실제 측정값을 보면 램 용량이 꽤 결정적임

  • Intel Core Ultra 7 270K Plus, WSL2, 24GB 램 환경에서는 기본 설정 기준 0.07 tok/s, expert hit 3~4%, RSS 14.1GB
  • 같은 환경에서 --topp 0.7을 주면 0.11 tok/s로 약 1.6배 개선됨
  • Apple M5 Max, 128GB unified memory, 14.2GB/s SSD에서는 MTP off 기준 1.06 tok/s, expert hit 23%, RSS 21.8GB
  • Ryzen AI 9 HX 370, 128GB 램, WD SN850X 환경에서는 auto-learned PIN 46.7GB로 expert hit 66%, MTP acceptance 52%, 0.37 tok/s를 기록함

• 2026년 7월 10일 이후 cache cap auto-raise가 들어가면서 벤치마크 해석도 바뀜

  • 이전에는 128GB 머신도 16GB 머신과 같은 8 experts/layer 캐시로 도는 문제가 있었음
  • 이제는 --ram budget에 맞춰 LRU cap을 올리므로, 예전 수치는 캐시가 억지로 눌린 상태였을 수 있음

sequenceDiagram
    participant 사용자
    participant 추론엔진
    participant 라우터
    participant 램캐시
    participant 로컬SSD
    사용자->>추론엔진: 프롬프트 입력
    추론엔진->>라우터: 각 레이어에서 필요한 전문가 선택
    라우터->>램캐시: 선택된 전문가 확인
    램캐시-->>추론엔진: 캐시 hit이면 즉시 사용
    램캐시->>로컬SSD: miss이면 int4 전문가 가중치 읽기
    로컬SSD-->>추론엔진: 필요한 expert 스트리밍
    추론엔진-->>사용자: 다음 토큰 생성

MTP speculative decoding은 꽤 예민함

• GLM-5.2 자체의 MTP head를 이용해 native speculative decoding도 구현돼 있음

  • MTP head가 draft token을 제안하고, main model이 batched forward 한 번으로 검증하는 방식
  • lossless 방식이고, sampling 상황에서도 rejection sampling으로 손실 없이 유지된다고 설명함

• 그런데 MTP head 정밀도가 중요함

  • int4 head를 쓰면 draft acceptance가 0~4%로 무너져 speculation이 사실상 작동하지 않음
  • int8 head에서는 acceptance가 3959%까지 올라가고, 1회 forward당 2.22.8 토큰 수준이 커뮤니티 측정으로 나옴
  • 그래서 pre-converted 모델을 받을 때도 MTP 파일이 int4라면 int8 MTP head를 따로 가져오라고 안내함

• 단, speculative decoding이 항상 이득은 아님

  • cold cache에서는 검증된 draft마다 추가 expert 로드가 붙어서 expert-loads/token이 약 660에서 1100까지 늘 수 있음
  • 캐시와 pinned expert가 충분히 예열되기 전에는 오히려 순손실이 날 수 있음
  • 그래서 adaptive guard와 DRAFT=0 옵션을 둠

attention과 커널 쪽도 그냥 장난감 수준은 아님

• MLA attention 구현으로 KV cache를 크게 줄임

  • GLM-5.2는 64 heads에 GQA가 없어서 일반 KV cache가 부담이 큼
  • 이 엔진은 compressed KV-cache로 토큰당 32768 float 대신 576 float만 저장함
  • 수치상 57배 감소라, 램 예산이 빡빡한 환경에서는 꽤 큰 차이임

• DeepSeek 계열 트릭도 꽤 들어가 있음

  • DeepSeek-V3 스타일 sigmoid router, shared expert, first-3-dense layers를 구현함
  • MLA weight absorption을 써서 decode 시 매 토큰마다 k/v reconstruction을 하지 않음
  • query가 kv_b를 흡수하고, attention 이후 context를 projection하는 방식으로 검증했다고 함

• 정수 행렬곱 커널도 직접 구현돼 있음

  • Q8_0 스타일 int8 activation과 AVX2 maddubs를 사용함
  • int8 matmul은 1.4~2.5배 빠르고, 측정치로 119 GFLOP/s가 나왔다고 함
  • int4는 batch에서 1.8배 빨랐지만, single-row에서는 f32보다 느려서 shape별 측정으로 경로를 고름

• DSA sparse attention은 아직 진행 중임

  • lightning-indexer weight 약 108GB를 FP8 repo에서 추출하는 작업이 진행 중이라고 설명함
  • 현재는 context 2048 토큰 이하에서 dense attention으로 정확하게 동작함

CUDA도 붙었지만, GPU 만능론은 일부러 피함

• CUDA backend는 opt-in으로 들어갔고, model-resident tensor에 제한적으로 사용됨

  • streaming expert는 기본적으로 CPU path를 유지함
  • expert를 매번 NVMe에서 GPU로 복사하면 디스크 병목이 PCIe 병목으로 바뀔 뿐이라는 판단임
  • resident quantized tensor는 lazy upload 후 재사용하는 방향임

• 기본 CUDA 설정은 expert-only accelerator에 가까움

  • dense와 attention tensor는 fixture 측정상 GPU로 옮겨도 도움이 크지 않아서 CPU에 둠
  • CUDA_DENSE=1을 켜면 이전의 all-resident 실험 경로를 쓸 수 있음
  • hot expert를 VRAM에 persistent tier로 올리는 PIN profile도 지원함

• 아직 end-to-end speedup 주장은 하지 않음

  • 디바이스는 독립 context를 쓰고, host-staged activation copy는 동기식임
  • P2P나 NCCL 의존성도 아직 없음
  • 커널도 cuBLAS나 Tensor Core 최적화가 아니라 correctness-first custom kernel이라고 못박음

실사용보다 더 중요한 건 측정 가능한 실험대라는 점

• 모델 변환도 현실적인 제약을 꽤 신경 썼음

  • FP8 checkpoint 전체 756GB를 한 번에 디스크에 둘 필요 없이 shard 하나씩 받아 변환하고 삭제함
  • 128×128 block scale을 dequant한 뒤 엔진 컨테이너로 requantize함
  • 변환은 재시작 가능하고, 런타임 자체는 순수 C임

• tokenizer도 C로 구현돼 있음

  • GPT-2 스타일 byte-level BPE tokenizer를 사용함
  • Unicode-property regex와 32만 merges를 처리함
  • Python 런타임 의존성을 제거하려는 방향이 명확함

• 정확도 측정은 아직 빈칸이 큼

  • int4 quantization이 실제 정확도를 얼마나 깎는지는 아직 측정하지 못했다고 밝힘
  • harness는 준비됐지만 개발 머신의 약 1GB/s 디스크 환경에서는 전체 평가가 거의 하루 가까이 걸림
  • full-precision GLM-5.2가 해당 task에서 85~95% 수준이면, int4가 몇 점 이내로 따라오는지가 관건임

• 프로젝트가 요구하는 최소 환경도 꽤 구체적임

  • Linux 또는 WSL2, gcc with OpenMP, AVX2, 최소 16GB 램
  • 약 370GB int4 모델을 로컬 NVMe에 둬야 함
  • 네트워크 mount나 9p mount는 피하라고 못박음

• 예상 성능 표도 꽤 솔직함

  • PCIe4 NVMe와 32GB 램이면 대략 0.5~1 tok/s 예상
  • PCIe5 NVMe 또는 2×NVMe RAID0, 64GB 램, 약 40GB hot expert PIN이면 2~4 tok/s 예상
  • 128256GB 램과 12코어에서는 hot expert cache가 먹히면 24 tok/s, 이후는 matmul-bound로 간다고 봄
  • 2432코어 또는 AVX-512/VNNI 커널까지 가면 515 tok/s도 기대하지만, 이건 아직 측정이 더 필요함

기술 맥락

• 이 프로젝트의 선택은 GPU 메모리에 모델을 올리는 대신, MoE의 sparse activation을 믿고 디스크를 모델 저장소처럼 쓰는 쪽이에요. 전체 744B를 매번 계산하지 않는 구조라서 가능해진 선택이고, 그래서 dense 부분만 램에 두고 routed expert는 필요할 때 읽어 오는 설계가 나온 거예요.

• 병목을 디스크 I/O로 옮긴 건 공짜가 아니에요. cold token 하나에 약 11GB read가 필요하니, SSD가 느리거나 램 캐시가 작으면 바로 0.1 tok/s 아래로 떨어져요. 대신 램이 많고 자주 쓰는 expert가 고정되면 같은 모델인데도 체감 속도가 크게 달라지는 구조예요.

• MTP speculative decoding도 단순한 가속 옵션이 아니라 캐시 상태와 정밀도에 묶여 있어요. int4 head에서는 draft acceptance가 무너지고, int8 head에서야 39~59% acceptance가 나와요. 즉, 추론 최적화가 모델 구조, quantization, 캐시 정책을 한꺼번에 봐야 하는 문제라는 걸 잘 보여줘요.

• CUDA를 제한적으로만 붙인 것도 나름 중요한 판단이에요. expert를 매번 NVMe에서 GPU로 옮기면 GPU가 빨라도 PCIe 전송이 새 병목이 되거든요. 그래서 resident tensor와 hot expert처럼 재사용 가능한 것만 GPU에 올리는 방향이 더 현실적인 선택이 된 거예요.