GLM-5.2를 느린 PC에서 돌리는 Colibri, Local AI의 병목은 GPU만이 아닌 이유
Original: Show HN: Getting GLM 5.2 running on my slow computer View original →
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 같은 낮은 층의 엔지니어링일 가능성이 크다.
Related Articles
KV 캐시 전체를 HBM에 두지 않는 OasisKV가 장문 LLM 서빙의 메모리 병목을 겨냥했다. 요청당 KV 요구량을 6.5~9.7배 줄이면서 다중 GPU 처리량을 최대 2.1배 높였다.
지식 저장과 추론 연산을 분리한 Mobius가 7B Transformer와 비슷한 성능을 학습 데이터 62.6%로 달성했다. Qwen3.5-35B에서 이어 학습한 버전은 종단 간 추론 속도를 약 4배 높였다.
17GB짜리 로컬 모델이 코딩과 비전 작업을 해내자 관심은 성능표보다 ‘얼마나 오래 생각하게 둘 것인가’에 모였다. Qwen 3.8 27B는 소비자 하드웨어에서 강한 결과를 내지만 기본 xhigh 추론 설정이 간단한 요청에도 수만 개 토큰을 쓰는 운영 문제를 드러낸다.