Colibri: 25GB RAM을 탑재한 노트북에서 744B AI 모델 실행하기
요약
Colibri는 25GB RAM을 탑재한 일반 노트북에서 744B 규모의 대형 MoE 모델을 실행할 수 있게 해주는 오픈 소스 프로젝트입니다. 레이어별 LRU 캐시와 3단계 메모리 계층 구조를 활용하여 디스크와 RAM을 효율적으로 관리함으로써 고가의 GPU 없이도 모델 구동을 가능하게 합니다.
핵심 포인트
- MoE 모델의 특성을 이용해 필요한 전문가 가중치만 스트리밍 방식으로 로드
- VRAM, RAM, 디스크를 통합 메모리 계층으로 관리하는 3단계 전략 사용
- 순수 C 언어로 구현되어 Python이나 외부 라이브러리 의존성 없음
- 저사양 하드웨어에서도 744B 모델의 정확한 출력을 구현 가능
7,440억 개의 파라미터를 가진 AI 모델은 데이터 센터가 필요할 것으로 예상됩니다. Z.ai에서 출시한 GLM-5.2는 총 744B 파라미터를 가진 Mixture-of-Experts (MoE) 모델입니다. 이를 실행하려면 일반적으로 여러 개의 H100 GPU나 수백 기가바이트의 VRAM이 필요합니다.
JustVugg의 오픈 소스 프로젝트인 Colibri는 GPU 없이 25GB RAM을 가진 노트북에서 이와 동일한 모델을 실행합니다. 빠르지는 않지만, 정확합니다.
MoE 모델의 작동 방식 (그리고 Colibri가 가능한 이유)
전통적인 (dense) 모델은 모든 토큰에 대해 모든 파라미터를 활성화합니다. 744B dense 모델은 생성되는 모든 단어마다 744B 파라미터 전체를 메모리에 유지해야 합니다.
GLM-5.2는 다릅니다. 이 모델은 19,456개의 전문가(expert) 서브 네트워크를 가진 Mixture-of-Experts 모델입니다. 각 토큰에 대해 라우터(router)는 75개의 레이어 전체에서 레이어당 단 8개의 전문가만을 선택합니다. 모델은 토큰당 전체의 약 5.4%에 불과한 약 40B 파라미터만을 활성화합니다.
이는 토큰마다 실제로 변하는 전문가 가중치(expert weights)가 약 11GB에 불과하다는 것을 의미합니다. 나머지는 유휴 상태로 머뭅니다.
Colibri의 통찰은 간단합니다. 특정 토큰에 전문가의 94.6%가 필요하지 않다면, 왜 그들을 모두 메모리에 유지해야 할까요?
3단계 메모리 전략
Colibri는 VRAM, RAM, 디스크를 하나의 통합된 메모리 계층 구조로 취급합니다:
- Dense 부분 (attention, shared experts, embeddings, 약 17B 파라미터): int4 정밀도로 RAM에 상주하며 약 9.9 GB를 소비합니다.
- 19,456개의 라우팅된 전문가 (int4 기준 각각 약 19 MB, 디스크에 총 370 GB): 레이어별 LRU 캐시(LRU cache)를 통해 필요할 때마다 스트리밍됩니다.
- 선택적 VRAM 계층: GPU가 있는 경우, 더 빠른 액세스를 위해 자주 사용되는 전문가(hot experts)를 VRAM에 둘 수 있습니다.
엔진은 학습 캐시를 유지합니다. 사용자의 특정 워크로드가 어떤 전문가로 라우팅되는지 기록하고(.coli_usage 파일에 저장), 가장 자주 사용되는 전문가들을 사용 가능한 RAM에 고정(pin)합니다. 사용하면 할수록 더 빨라집니다.
실제 벤치마크 수치
아래의 모든 수치는 추정치가 아니라 커뮤니티에 의해 측정된 것입니다. 하드웨어 구성이 포함된 전체 표는 project benchmarks page에서 확인할 수 있습니다.
| Machine | Speed |
|---|---|
| 6x RTX 5090, 251 GB RAM (full residency) | 5.8 to 6.8 tok/s |
| ... | |
| 기준점(Baseline) (25 GB RAM, GPU 없음)은 초당 0.05에서 0.1 토큰(tokens per second)입니다. 이는 대략 10초에서 20초마다 한 단어를 생성하는 속도입니다. 느리긴 하지만, 단일 H100 GPU 팬 하나보다 저렴한 하드웨어에서 744B 프론티어(frontier) 모델로부터 정확한 출력을 만들어냅니다. |
Colibri가 다른 점
순수 C 언어, 의존성 제로 (Zero Dependencies)
런타임 엔진은 단일 C 파일(c/glm.c)과 작은 헤더 파일들로 구성되어 있습니다. BLAS도 필요 없고, 런타임 시 Python도 필요 없으며, GPU도 요구하지 않습니다. Python은 일회성 모델 컨버터(model converter)와 선택 사항인 API 게이트웨이(API gateway)에서만 사용됩니다.
품질을 조용히 저하시키지 않음
README에는 이 점이 명시되어 있습니다: "빠른 메모리가 부족하면 속도는 느려질 수 있지만, 기본 정책은 모델의 정밀도(precision)나 라우터(router)의 의미론(semantics)을 조용히 변경하지 않습니다." 라우터는 전문가(expert)가 VRAM, RAM 또는 디스크에서 답변하든 상관없이 동일한 결정을 내립니다. 가중치(weights)는 동일한 정밀도를 가집니다. 출력은 동일합니다.
정직하게 구현된 투기적 디코딩 (Speculative Decoding)
GLM-5.2는 메인 모델이 검증할 수 있는 토큰을 초안(draft)으로 작성할 수 있는 네이티브 멀티 토큰 예측 (Multi-Token Prediction, MTP) 헤드를 가지고 있습니다. Colibri는 고된 경험을 통해 학습된 두 가지 규칙과 함께 이를 제공합니다:
- MTP 헤드는 반드시 int8이어야 합니다 (int4 헤드는 초안 수락률이 거의 0으로 수렴합니다).
- 초안 작성(Draft)과 검증(Verify)은 동일한 함수를 계산해야 합니다.
투기적 디코딩이 효과를 발휘할 때, 결과는 순전파(forward pass)당 2.2에서 2.8 토큰이 됩니다.
토큰 단위의 정확한 검증 (Token-Exact Validation)
순전파는 transformers 오라클(oracle)과 비교하여 토큰 단위로 정확하게 검증됩니다. 32개의 테스트 토큰 중 32개가 정확히 일치합니다. MLA 어텐션(attention)은 압축된 KV 상태를 저장하며(토큰당 32,768개가 아닌 576개의 부동 소수점, 즉 57배 더 작음), 재시작 시에도 이를 유지합니다. 대화는 재전처리(re-prefill) 없이 즉시(warm) 다시 열립니다.
OpenAI 호환 API
Colibri는 OpenAI 호환 API 서버(coli serve)를 포함하고 있습니다. OpenAI API를 사용하는 기존의 어떤 도구든 로컬의 744B 모델로 연결할 수 있습니다.
실행 방법
1단계: 엔진 가져오기
cd c && ./setup.sh
이 과정은 gcc/OpenMP를 확인하고, 엔진을 빌드하며, 자체 테스트를 실행합니다.
2단계: 모델 가져오기
사전 변환된 GLM-5.2 int4 컨테이너를 HuggingFace에서 사용할 수 있습니다:
반드시 int8 MTP 헤드(heads)가 포함된 버전을 받으십시오. 원본 미러(mirror)는 초안 수락률(draft acceptance)이 거의 0에 가까운 int4 MTP 헤드를 제공합니다.
3단계: 실행
# 대화형 채팅
COLI_MODEL=/path/to/glm52_i4 ./coli chat
...
웹 대시보드 표시 내용
coli web 명령어를 실행하면 다음과 같은 항목이 포함된 대시보드가 열립니다:
- 실시간 토큰 지표 (Live token metrics): 초당 토큰 수 (tokens per second), 첫 번째 토큰 생성 시간 (time to first token), 턴별 상세 내역
- VRAM/RAM/디스크 계층 바 (VRAM/RAM/disk tier bar): 각 계층에 얼마나 많은 전문가(experts)가 있는지 표시
- 브레인 페이지 (Brain page): 19,456개의 모든 전문가를 시각 피질(visual cortex) 형태로 표시합니다. 색상은 저장 계층을 나타내고, 밝기는 라우팅 열기(routing heat)를 나타냅니다. 라우팅되는 모든 전문가는 흰색으로 깜빡입니다.
- 아틀라스 페이지 (Atlas page): 측정된 전문가 친화도(expert affinity)를 3D 은하계 형태로 보여줍니다. 전문가들은 학습된 임베딩(embeddings)이 아닌 실제 라우팅 데이터를 기반으로 주제(시, 법률, SQL, 중국어 등)에 따라 클러스터링됩니다.
Colibri는 언제 실용적인가?
실용적인 경우:
- 소비자용 하드웨어에서 프런티어 모델(frontier model) 실험
- 개인정보 보호가 중요한 사용 사례 (100% 로컬 실행, API 호출 없음)
- MoE (Mixture of Experts) 아키텍처에 대한 연구 및 교육
- 속도보다 정확성이 더 중요한 사용 사례
실용적이지 않은 경우:
- 프로덕션 서비스 (초당 1토큰 미만의 속도는 대부분의 실시간 사용에 너무 느림)
- CI 파이프라인 (370 GB 모델 다운로드에 수 시간이 소요됨)
- 빠른 응답 시간이 필요한 모든 작업
int4 양자화 (Quantization)의 품질 비용
README는 품질에 대해 솔직하게 기술하고 있습니다. int4 컨테이너는 hellaswag, arc, mmlu 벤치마크에서 평균 62.5%의 정확도를 기록했습니다. fp16 대 int4 A/B 테스트 측정 결과, 순수 양자화 비용은 가장 어려운 작업에 집중되어 마이너스 8.2 퍼센트 포인트로 나타났습니다. 그룹화된 스케일 (Grouped scales)을 통해 해당 손실의 약 63%를 회복할 수 있습니다.
이는 전체 정밀도 (full-precision) 모델을 실행하는 것과 동일한 품질은 아닙니다. 이는 트레이드오프 (tradeoff)입니다. 즉, 어려운 추론 (reasoning) 작업에서 측정 가능한 수준의 품질 저하를 감수하는 대신, 엄청난 크기 감소 (744B 파라미터에 각각 2바이트를 곱한 fp16 기준 추정치인 약 1.5 TB 대신 디스크 상에서 370 GB)를 얻는 것입니다.
더 큰 그림 (The Bigger Picture)
Colibri는 중요한 사실을 증명합니다. 프런티어 모델 (frontier models)을 실행하는 장벽은 GPU 벤더들이 시사하는 것만큼 높지 않습니다. 토큰 생성 (token generation) 속도가 느린 것을 수용한다면, 744B 모델은 데이터 센터를 필요로 하지 않습니다. 핵심 통찰은 MoE (Mixture of Experts) 모델은 본질적으로 희소성 (sparsity)을 가지고 있으며, 저장 장치를 메모리 계층 (memory tier)으로 취급함으로써 이 희소성을 활용할 수 있다는 점입니다.
MoE 모델이 표준 아키텍처가 됨에 따라 (DeepSeek, GLM, Mixtral 등이 모두 MoE를 사용함), 소비자용 하드웨어를 위해 이러한 희소성을 활용하는 Colibri와 같은 도구들이 더 많이 등장할 것으로 기대됩니다.
이 프로젝트는 16,800개 이상의 GitHub 스타를 보유하고 있으며 활발한 커뮤니티 벤치마킹이 이루어지고 있습니다. Apache 2.0 라이선스로 제공되며, GLM-5.2 모델 가중치 (weights)는 MIT 라이선스입니다.
출처 (Sources):
- Colibri GitHub: https://github.com/JustVugg/colibri (16,884 stars, Apache 2.0)
- 벤치마크 데이터: https://github.com/JustVugg/colibri/blob/main/docs/benchmarks.md
- HuggingFace의 GLM-5.2 모델: https://huggingface.co/mateogrgic/GLM-5.2-colibri-int4-with-int8-mtp
- Z.ai의 GLM-5.2 (MIT 라이선스 가중치)
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기