GLM-5.2를 느린 PC에서 돌리는 Colibri, Local AI의 병목은 GPU만이 아닌 이유

Colibri는 GLM-5.2, 744B 파라미터급 Mixture-of-Experts 모델을 약 25GB RAM의 소비자용 머신에서 돌리는 실험이다. README가 내세우는 방식은 단순하다. 매 토큰에서 실제로 활성화되는 파라미터가 전체가 아니라는 점을 이용해 dense part는 RAM에 두고, 수만 개 routed experts는 디스크에 둔 채 필요한 것만 스트리밍한다.

흥미로운 부분은 “느린 컴퓨터에서 대형 모델”이라는 구호보다 구현의 절충이다. Colibri는 순수 C 기반의 작은 엔진으로, 런타임에서 Python이나 BLAS 없이 GLM-5.2 forward를 맞추는 쪽을 택했다. README에는 dense part 약 17B 파라미터를 int4로 상주시키고, expert 쪽은 LRU cache와 OS page cache를 활용한다는 설명이 나온다. 거대한 MoE를 GPU 메모리 문제로만 보지 않고, 디스크와 메모리 사이의 이동 문제로 다시 쪼갠 셈이다.

댓글의 관심도 여기에 붙었다. 실제 처리량이 초당 토큰인지, 분당 토큰인지가 첫 질문으로 나왔고, mmap, llama.cpp의 양자화, Apple Silicon의 unified memory 같은 비교가 이어졌다. 즉 “가능하다”보다 “어느 정도 느려도 쓸모가 있는가”가 논점이다. overnight job처럼 오래 걸려도 되는 작업이라면 1 tok/s도 가치가 있을 수 있지만, 대화형 사용에서는 병목이 바로 드러난다.

이 프로젝트는 production inference 해답이라기보다 MoE 시대의 로컬 실행 실험에 가깝다. 큰 모델을 작게 만드는 대신, 활성화되는 부분만 좁혀 읽는 설계가 어디까지 버틸 수 있는지 보여준다. Local AI의 다음 병목은 연산량만이 아니라 storage layout, cache policy, compressed KV-cache 같은 낮은 층의 엔지니어링일 가능성이 크다.

HN discussion · Source