colibri 로컬 LLM: 메모리 대신 디스크로 744B MoE 모델을 돌리는 법과 실제 속도

colibri 로컬 LLM: 메모리 대신 디스크로 744B MoE 모델을 돌리는 법과 실제 속도

744B짜리 모델을 통째로 RAM에 올리는 대신, 자주 쓰는 부분만 남기고 나머지는 디스크에 두는 MoE 추론 엔진 colibri의 구조와 실측 속도, 국내 기종별 판단 기준을 정리했어요.

이 정도 규모의 모델은 개인 PC에서 못 돌린다는 게 상식이었죠. colibri라는 오픈소스 프로젝트가 그 상식에 예외를 하나 만들었습니다. HN 런치 스레드에서 walrus01이라는 참가자는 이런 질문을 남겼어요. "실사용에서 초당 토큰으로 측정되는가, 분당 1토큰에 가까운가. 1 tok/s짜리도 밤새 돌리는 용도로는 유용했지만 0.05~0.1 tok/s는 다른 얘기다." 되는 것과 쓸만한 것은 다르죠. 이 글은 colibri의 작동 방식과 실제 속도, 감수할 만한 상황을 짚어봅니다.

메모리에 안 들어가는 모델을 다루는 발상

colibri는 개발자 JustVugg(Vincenzo Fornaro)가 만든 순수 C 추론 엔진이에요. GLM-5.2·5.3, Kimi K3, DeepSeek V4 같은 대형 MoE(Mixture of Experts) 모델을 다룹니다. README가 드는 비유는 컴파일러의 JIT이에요. 프로그램 전체를 미리 컴파일하지 않고 실행 경로만 그때그때 컴파일하듯, colibri도 744B 파라미터 전부를 상주시키지 않고 필요한 순간에만 불러 씁니다.

구조는 두 부분입니다. 어텐션·공유 전문가·임베딩 같은 dense 파트(약 17B)는 int4로 양자화해 RAM에 상주시키며 약 9.9GB를 차지해요. 라우팅되는 전문가는 75개 레이어에 총 19,456개(레이어당 256개), 하나가 약 19MB로 디스크에 두고 필요할 때만 읽어옵니다(전부 합치면 약 370GB). 744B 모델이 토큰 하나를 처리할 때 실제로 활성화하는 양은 약 40B, 그중 매번 바뀌는 부분은 약 11GB뿐이라는 게 이 구조의 근거예요.

개인 PC에서 대형 모델을 돌리겠다는 목표를 이렇게 풀었다는 점이 colibri를 다른 로컬 추론 도구와 구분 짓습니다.

mmap과는 무엇이 다른가

디스크에서 가중치를 불러오는 방식 자체는 새롭지 않아요. llama.cpp도 mmap으로 모델 파일을 매핑합니다. 다만 mmap은 레이아웃을 모르는 페이지 폴트에 가깝고, 다음에 필요한 전문가가 무엇인지는 몰라요.

colibri는 여기에 학습을 얹었습니다. 매 턴 실제 라우팅 이력을 .coli_usage 파일에 기록하고, 자주 불리는 전문가를 자동으로 고정해요. 레이어별 LRU 캐시와 학습된 핫스토어가 함께 작동하고, 라우터 선행 스레드가 다음 레이어의 전문가를 미리 읽어 둡니다. README는 라우팅이 한 레이어 앞에서 71.6% 예측 가능하다고 제시해요. 쓸수록 캐시가 데워지고 빨라지는 구조죠.

AirLLM류의 레이어 단위 분할과도 다릅니다. 분할 단위가 레이어가 아니라 개별 전문가이고, 전문가 선택은 라우터가 토큰마다 새로 내리는 결정이라 그 예측 정확도가 성능을 좌우합니다.

colibri란: JustVugg가 만든 오픈소스(Apache-2.0) 순수 C 추론 엔진이다. 대형 MoE 모델의 자주 쓰이지 않는 전문가 가중치를 디스크에 두고, 실제 라우팅 이력을 학습해 필요한 순간에만 읽어 오는 방식으로 개인 PC의 메모리 한계를 우회한다.

속도의 진실: 빠르게 하는 기술이 아니다

디스크 스트리밍은 속도를 끌어올리는 트릭처럼 들리지만, 실제로는 정반대에 가깝습니다.

저자가 2026-07-12에 남긴 실험 로그가 답을 줍니다. 6×RTX 5090에 듀얼 Xeon Silver 4510을 얹은 자신의 장비에서, 전문가를 디스크에 둔 부분 상주 모드는 0.12 tok/s였어요. 같은 기계에서 vLLM-Moet은 2.32.7 tok/s를 기록했습니다. 그런데 전문가 전체를 GPU와 RAM에 올려 디스크를 decode 경로에서 빼자, 같은 colibri가 6.286.84 tok/s로 올랐어요.

디스크에서 전문가를 꺼내 쓰는 이 기법은 속도가 아니라, 메모리 부족으로 안 돌아가던 모델을 돌아가게 만드는 기술입니다. 메모리가 충분하면 택할 이유가 적습니다.

국내에서 흔한 기종, 실측은 어디까지 왔나

benchmarks.md의 GLM-5.2(int4) 실측치 중 국내에서 흔한 구성만 추려 봤어요.

이 표에 RTX 4060·4070·4080·4090 행은 없어요. colibri 공식 벤치마크 문서가 해당 GPU를 아예 다루지 않았다는 뜻입니다. 이 수치를 추정해 인용하는 2차 블로그도 있지만, 1차 문서와 어긋나는 경우가 많아 이 글에서는 채택하지 않았어요.

실무 판단은 RAM에서 시작한다

benchmarks.md 결론을 국내 실무 기준으로 옮기면 세 가지로 좁혀져요.

첫째, RAM 용량이 GPU보다 먼저 발목을 잡습니다. 24GB 이하면 전문가 캐시가 레이어당 2슬롯으로 자동 제한돼, 아무리 빠른 디스크를 붙여도 decode가 콜드 상태에 머물러요. GPU 예산이 있다면 RAM에 쓰는 편이 낫습니다.

둘째, 디스크 여유는 380GB 이상 필요해요. GLM-5.2 int4 컨테이너 하나가 약 372GB라, 노트북 내장 1TB 드라이브는 모델 하나만 받아도 여유가 거의 없습니다.

셋째, 맥에서는 설정이 하드웨어보다 크게 작용해요. 같은 M5 Max가 설정만으로 0.4에서 2.0 tok/s까지 움직였습니다. ./coli tune을 먼저 돌려 프로파일을 재는 편이 장비를 바꾸는 것보다 쌉니다. 특히 M1 계열은 --ram 값을 키우면 오히려 속도가 떨어진 사례가 있어, 직관대로 올렸다가 손해를 볼 수 있어요.

설치 전에 알아둘 것: "zero deps"의 실제 범위

colibri는 종속성이 없다는 점을 내세우지만, 이 주장은 런타임 엔진에 한정됩니다. c/colibri.c와 모델별 C 파일로 이뤄진 엔진 본체는 BLAS도, Python도, GPU도 필요 없어요. 다만 모델을 실행할 때 쓰는 coli 런처와 OpenAI 호환 API 게이트웨이는 Python 스크립트라, 프리빌트 릴리스를 받아도 Python 3 설치가 필요합니다. 소스 빌드는 OpenMP 지원 gcc나 clang이 있어야 해요. "설치할 게 하나도 없다"고 기대하면 첫 단계부터 어긋나는 셈입니다.

언제 쓰고 언제 쓰지 말아야 하나

쓰기 유리한 경우

• 데이터 외부 반출이 안 되는 업무예요. 의료·법무·인사·미공개 재무처럼 API 전송 자체가 리스크인 경우죠.
• 오프라인이나 망분리 환경입니다. 폐쇄망에서 프런티어급 모델을 돌릴 다른 방법이 사실상 없어요.
• 밤새 돌려도 되는 배치 작업입니다. 문서 일괄 분류나 대량 요약처럼 지연에 둔감하면 1 tok/s도 충분히 쓸모 있어요.
• 이미 128GB 통합메모리 맥을 갖고 있는 경우죠. 추가 지출 없이 744B 모델에 손이 닿습니다.

쓰기 불리한 경우

• 대화형 사용입니다. 0.32 tok/s는 한 문단에 수십 초수 분이 걸린다는 뜻이라, 사람이 기다리는 인터페이스엔 맞지 않아요.
• 동시 요청 처리입니다. 공개된 수치는 전부 단일 요청 기준이라 팀 단위 서빙과는 비교 대상이 아니에요.
• 비용만 보고 들어가는 경우죠. 24GB+ RAM에 380GB+ NVMe를 새로 마련하는 비용이 들고, 6×RTX 5090을 갖춘 저자 장비에서도 부분 상주 모드는 vLLM보다 느렸습니다.
• 출력 정합성이 계약 조건인 업무예요. CUDA에서 speculative verify 결과가 CPU와 어긋나는 이슈 #689, glm53 Vulkan 커널이 swiglu 클램프를 건너뛰어 전문가에 따라 출력이 달라지는 이슈 #1520처럼 남은 정합성 버그가 있어요.

완성도는 어디까지 왔나

수치만 보면 활발한 프로젝트예요. 라이선스는 Apache-2.0, 컨트리뷰터는 138명입니다. v1.6.2부터 v1.11.0까지 약 한 달 사이 릴리스가 8개 나왔고, 오픈 [Bug] 라벨 이슈는 4건뿐이에요. OpenAI 호환 게이트웨이, 웹 대시보드, Docker 이미지, CI의 transformers 오라클 대조까지 갖췄습니다.

그런데 README는 "속도에 대한 SLA는 없다(no SLA on speed)"고 적어 뒀습니다. 의미론적 정확성은 강하게 보증하지만 속도는 보증하지 않는다는 뜻이에요. int4 양자화가 어려운 과제에서 정확도를 약 8.2%p 깎는다는 측정치도 있고 DeepSeek V4의 드래프트 기능은 기본 꺼짐인데 켰다가 14토큰 답변 하나에 495초가 걸린 사례가 그 근거입니다.

저장소 생성일은 2026-07-01입니다. 약 2.5개월 만에 이만큼 쌓였다는 뜻이에요. 활발히 개발되는 연구 플랫폼이고 조건이 맞으면 실사용도 가능하지만, 범용 프로덕션 서빙을 대체할 물건은 아닙니다.

자주 묻는 질문

Q: 실사용에서 초당 몇 토큰이나 나오나요, 채팅처럼 대화가 되나요?

공개된 기종 대부분이 0.31.2 tok/s 구간이고, 128GB급 대형 통합메모리 맥에서만 1.52 tok/s가 나와요. 저자의 6×RTX 5090 장비도 디스크를 쓰는 부분 상주 모드에서는 0.12 tok/s에 그쳤습니다. 대화형 채팅보다는 밤새 돌리는 배치 작업에 맞는 속도예요.

Q: 디스크를 계속 읽으면 SSD 수명에 문제가 생기지 않나요?

HN 런치 스레드에서 같은 질문이 나왔고, 저자는 읽기 위주라 문제가 덜하다고 답했어요. 다른 참가자는 KV 캐시를 통합 RAM에 두면 SSD 쓰기를 아예 피할 수 있다고 제안했습니다. 다만 2026-09-15 기준 README에는 SSD 수명을 다룬 섹션이 없어서, 저자의 커뮤니티 답변이 근거의 전부이고 공식 문서가 수명을 보증하는 건 아니에요.

Q: RAM과 디스크는 각각 얼마나 있어야 시작할 수 있나요?

quickstart 문서 기준 최소 RAM은 약 16GB지만 권장은 24GB 이상이에요. 24GB 이하에서는 전문가 캐시가 레이어당 2슬롯으로 자동 제한돼 속도가 콜드 상태에 머뭅니다. 디스크 여유는 GLM-5.2 int4 컨테이너 기준 약 380GB를 확보해야 해요.

마무리

colibri 로컬 LLM이 지금 당장 필요한지는 데이터 반출 여부와 디스크 여유부터 따져보면 답이 나와요. 오늘 정리한 기종별 기준을 판단의 출발점으로 삼아 보시면 좋겠습니다.

참고 자료

• JustVugg/colibri (GitHub)
• colibri README
• colibri benchmarks.md
• colibri quickstart.md
• 6×RTX 5090 실험 로그 (2026-07-12)
• Show HN: Getting GLM 5.2 running on my slow computer