744B MoE를 내 PC에서 — 오픈소스 엔진 colibrì

LLM이 커질수록 "이건 GPU 여러 장짜리 머신에서나 가능한 일"이라는 벽이 생겨요. colibrì는 그 벽을 다른 각도로 공략해요. 모델을 메모리에 통째로 올리는 대신, 하드웨어에 이미 있는 저장장치(RAM·NVMe)까지 하나의 계층으로 쓰는 방식으로 744B짜리 MoE 모델을 데스크톱에서 돌리는 오픈소스 프로젝트랍니다. 오늘 GitHub 트렌딩에 올랐고 현재 스타 3만 개를 넘겼어요.

MoE는 사실 "잘 배치하면 되는" 모델

핵심부터 짚어볼게요. 744B MoE는 토큰마다 전체 파라미터를 계산하지 않아요. 라우터가 이번 토큰에 필요한 전문가(expert)만 골라서 쓰죠. 활성 파라미터는 약 40B뿐이고, 토큰마다 전문가가 실제로 바꾸는 값은 11GB 안팎이에요.

그래서 관건은 "모델을 메모리에 넣을 수 있느냐"가 아니라 "어디에 두고 언제 불러올 것인가"라는 배치(placement) 문제로 바뀌어요. 모델 전체가 아니라 실사용 경로만 빠른 메모리에 있으면 되는 거예요.

출처: colibrì 공식 GitHub README

전문가를 디스크에서 스트리밍하는 "무게를 위한 JIT"

colibrì는 이 방식을 "JIT지만 컴파일러 대신 weight를 대상으로 하는 것"이라고 설명해요. 컴파일러가 프로그램 전체 대신 실제 실행되는 핫 경로만 컴파일하듯, colibrì는 라우터가 자주 부르는 전문가만 상위 계층으로 끌어올린다는 뜻이에요.

구체적으로는 이렇게 나뉘어요.

• attention·공유 전문가 같은 dense 부분(약 17B 파라미터)은 int4로 RAM에 상주시켜요. 약 9.9GB 수준이에요.
• 19,456개 라우팅 전문가(75개 MoE 레이어 × 256 + MTP 헤드, 개당 int4 약 19MB)는 디스크에 두고(총 약 370GB) 필요할 때만 스트리밍해요.
• per-layer LRU + 학습된 핫스토어 + 선택적 VRAM 티어로 캐시하고, 라우터는 한 레이어 앞을 미리 봐서 prefetch해요. README에 따르면 라우팅은 한 레이어 앞으로 71.6% 정도 예측 가능하다고 해요.

어디에서 나왔든 계산은 똑같은 모델

가장 중요한 설계 원칙은 "배치(placement)가 속도만 결정한다"는 거예요. 전문가가 VRAM에서 왔건 디스크에서 왔건 라우터 결정과 weight 정밀도는 동일해서, 빠른 메모리가 부족하면 속도만 느려지고 모델의 의미가 조용히 바뀌지 않아요.

이걸 실측으로 지키고 있는데, forward pass는 transformers 오라클에 대해 토큰 단위로 검증되고, MLA KV 상태는 57배 압축되어(토큰당 32,768→576 float) 재시작 후에도 이어서 하던 대화가 warm하게 열려요. 스펙추얼 디코딩 역시 MTP 헤드는 int8로, 수용률이 안 나오면 DRAFT=0으로 끄는 정직한 방식이에요.

실행되는 하드웨어 스펙트럼

백엔드는 CPU·CUDA·Metal·Vulkan을 모두 지원해요. Vulkan은 AMD(RADV)를 포함해 벤더 지원이 끊긴 RX 580 같은 그래픽카드에서도 작동하고, Metal은 Apple Silicon의 통합 메모리를 활용해요. GPU가 아예 없어도 되고요.

이중 SSD가 있으면 모델 사본을 두 드라이브에 나눠 둔 뒤 동시에 읽어 대역폭을 합치고, 멀티머신 클러스터 모드로는 토큰 생성·라우팅·KV 상태는 로컬에 두고 디스크 백엔드 전문가 계산을 다른 Mac에 떠넘길 수도 있어요.

출처: colibrì 공식 GitHub README

실제로 얼마나 빠른가요

README가 공개한 측정 예시를 표로 보면 스펙트럼이 명확해요.

마지막 수치는 프로젝트가 처음 시작된 "정직한 바닥"이에요. 속도 보장은 없고 의미 보장은 있다고 명시되어 있는데, 이는 "빠른 메모리가 부족하면 느려질 수는 있되 모델을 조용히 바꾸지는 않는다"가 핵심이에요.

시작해 보고 싶다면

프로그램은 수백 킬로바이트, 모델은 약 372GB(GLM-5.2 int4)예요. 사전 빌드 릴리스(Linux·macOS·Windows)를 받으면 컴파일러 없이 coli chat으로 바로 시작할 수 있고, 소스 빌드는 gcc+OpenMP만 있으면 돼요. 런타임은 순수 C라 의존성이 없고, Python은 1회성 컨버터와 선택적 API 게이트웨이에만 쓰여요.

다만 SQL처럼 익숙한 벤치마크 숫자가 항상 그대로 재현되는 건 아니에요. O_DIRECT는 드라이브마다 이득이 다르고(+34% 사례도, 무관한 사례도 있어요), 디스크 속도가 곧 스트리밍 속도를 좌우하죠. 그럼에도 프론티어급 모델을 "보유 장비에서 갖고 분석·개선하는" 오픈 리서치 플랫폼이라는 점은 매력적이에요. 관심이 생기면 공식 저장소에서 측정 서식과 실험 이슈 가이드를 확인해 직접 데이터를 기여할 수 있어요.

참고 링크

• colibrì GitHub 저장소
• colibrì 공식 사이트
• GLM-5.2 int4 모델 컨테이너 (Hugging Face)