glm.c, 약 2,500줄)로 구현했다. 빠르지는 않다(초당 0.05~1토큰). 하지만 "H100 팬 값보다 싼 컴퓨터에서 프론티어급 모델이 정확히 답하는" 것 자체가 목적이다.
(저장소: JustVugg/colibri · 제작자 1인 · 순수 C + 소량 Python 툴 · Apache 2.0 · 대상 Linux/WSL2 + AVX2 CPU · TrendShift 오늘 Daily 1위 · New 2026)
이 저장소가 대체 무엇인가.
colibrì는 거대한 언어 모델(GLM-5.2, 744B 파라미터)을 값싼 개인 컴퓨터에서 실행하기 위한 추론 엔진이다. 보통 이만한 모델은 수십만 달러짜리 GPU 서버 여러 대가 있어야 돌아간다. colibrì는 이걸 램 25GB짜리 노트북 한 대 + 넉넉한 디스크로 해낸다. 핵심 아이디어 한 줄: "모델의 대부분(전문가들)은 디스크에 두고, 지금 이 토큰에 실제로 필요한 조각만 그때그때 읽어 온다."
744B 모델을 통째로 램에 올리는 것은, 도서관의 모든 책을 두 팔에 다 안고 다니려는 것과 같다 — 불가능하다. colibrì는 사서처럼 일한다: 자주 쓰는 참고서(뼈대, dense part)만 책상에 펼쳐 두고(램 상주), 나머지 21,504권의 전문서(routed experts)는 서가(디스크)에 두었다가 질문이 들어올 때마다 해당 책만 후다닥 꺼내 온다.
단점은 명확하다 — 서가까지 왕복하는 시간(디스크 읽기)이 병목이다. 그래서 colibrì는 "자주 꺼내는 책은 책상 근처에 미리 쌓아 두고(핫 캐시·PIN), 다음에 꺼낼 책을 예측해 미리 걸어가는(프리페치)" 온갖 사서의 지혜를 코드로 구현했다.
라이선스는 관대한 Apache 2.0이며(GLM-5.2 가중치 자체는 Z.ai가 MIT로 공개), 이탈리아어 인터페이스가 인상적인 1인 개발 프로젝트다. 실제 저장소 구성은 순수 C 엔진(c/glm.c 약 2,547줄) + 헤더 몇 개 + 일회성 변환·벤치마크용 Python 툴 + 커뮤니티가 만든 웹 UI(React)로 이뤄져 있다. TrendShift에 "New 2026"으로 오늘 Daily 1위에 올라 있다.
"노트북에서 744B 모델이 돈다"는 건 겉모습이다. 이 레포의 진짜 가치는 MoE 라우팅과 전문가 스트리밍 · int4/int8/int2 양자화 커널(AVX2 정수 내적) · MLA 압축 KV 캐시 · 투기적 디코딩(MTP) · LRU 캐시와 프리페치로 디스크 병목 숨기기 · OS 페이지 캐시를 공짜 L2로 쓰기 · 램 예산 자동 산정을 2,500줄짜리 읽을 수 있는 단일 C 파일에서 통째로 볼 수 있다는 점이다. "추론 엔진이 실제로 어떻게 동작하는가"를 밑바닥부터 배우기에 이보다 밀도 높은 교재는 드물다.
공식 수치조차 25GB 램 개발 PC에서 콜드 상태 초당 0.05~0.1토큰이다(한 문장에 수십 초~수 분). 저자 스스로 "This is not fast"라고 못 박는다. 디스크가 빠르고(PCIe5 NVMe) 램이 크면(128GB+) 초당 2~15토큰까지 오르지만, 이는 대부분 추정치다. 커뮤니티 측정으로 M5 Max 128GB에서 ~1.06 tok/s가 나온 정도. int4 양자화가 정확도를 얼마나 깎는지도 아직 측정되지 않았다(벤치 하네스는 있으나 느린 디스크로 하루가 걸려 미완). 즉 "학습·실험용 걸작"이지 "실사용 서빙 솔루션"은 아니다.
트렌딩 이유와, 기존 로컬 추론 도구(llama.cpp·ollama)와의 결정적 차이.
지금까지 로컬 LLM의 상식은 "모델이 램/VRAM에 다 들어가야 한다"였다. 70B 모델도 양자화해서 겨우 48GB, 700B급은 사실상 개인은 손도 못 댔다. colibrì는 "MoE 모델은 한 토큰에 전체의 일부만 쓴다"는 구조적 성질을 파고들어, 모델 크기(370GB) ≫ 램(25GB)이라는 이제껏 불가능해 보이던 조합을 성립시켰다. "디스크가 곧 확장 램"이라는 발상의 전환이다.
744B MoE 모델 = 거대하지만 대부분이 "잠들어 있는" 뇌. 토큰 하나를 만들 때 실제로 깨어나는 뉴런(활성 파라미터)은 ~40B, 그중에서도 매번 바뀌는 부분은 ~11GB어치뿐이다. 나머지는 그 순간 안 쓰인다 → 굳이 램에 있을 이유가 없다. colibrì는 이 "안 쓰이는 대다수"를 디스크로 추방했다.
llama.cpp/ollama도 CPU 추론·양자화·GGUF 스트리밍(mmap)을 한다. 하지만 그들은 기본적으로 "모델이 (양자화 후) 메모리에 들어간다"를 전제로 최적화돼 있다. colibrì는 처음부터 "모델이 램보다 30배 크다"를 전제로 설계됐다 — 그래서 전문가 단위 LRU 캐시, 라우터 예측 프리페치, 핫 전문가 PIN, MoE 배치 유니온 같은 스트리밍 특화 machinery가 엔진의 중심에 있다. 또 llama.cpp가 범용 다중 모델·다중 백엔드를 지향하는 반면, colibrì는 GLM-5.2 한 모델에만 충실(faithful)하게 맞춰져 있다(MLA·DSA·MTP 등 GLM 고유 구조를 그대로 구현).
| 측면 | llama.cpp / ollama | colibrì |
|---|---|---|
| 전제 | 모델이 메모리에 들어감 | 모델 ≫ 메모리 (30배) |
| 대상 | 범용(수백 종 모델) | GLM-5.2 단일, 구조 충실 구현 |
| 전문가 | 대개 상주(mmap 포함) | 디스크 스트리밍 + LRU + PIN |
| 의존성 | 다수 백엔드/BLAS 선택 | 순수 C, 무의존(런타임 Python 0) |
| 속도 | 빠름(수십 tok/s) | 느림(0.05~수 tok/s, 디스크 바운드) |
| 코드 규모 | 수십만 줄 | 핵심 ~2,500줄 단일 파일 |
README가 이례적으로 솔직하다. 속도가 느리다는 것, MTP 투기가 콜드 캐시에서는 오히려 손해일 수 있다는 것, int4 정확도 손실을 아직 못 쟀다는 것을 전부 명시하고, 커뮤니티 측정치를 issue 번호까지 달아 인용한다. "help wanted — 더 좋은 하드웨어로 벤치 돌려 달라"고 공개적으로 요청한다. 과장 없는 엔지니어링 문서가 오히려 기술 커뮤니티의 강한 반응을 이끌어냈다.
744B급 오픈 웨이트 MoE가 등장하면서 "이걸 개인이 어떻게든 돌려 보고 싶다"는 수요가 생겼다. colibrì는 그 수요에 "디스크만 넉넉하면 된다"는 가장 접근성 높은 답을 내놨다. FP8 체크포인트(756GB)를 한 번에 다 받지 않고 샤드 하나씩 받아 int4로 변환·삭제하는 변환기까지 붙여, 진입 장벽을 실질적으로 낮췄다.
순수 C 엔진을 중심으로, 주변 툴이 어떻게 배치돼 있는가.
| 구성 | 파일 | 역할 |
|---|---|---|
| 추론 엔진 | c/glm.c (~2,547줄) | GLM-5.2 forward 전체 · 양자화 커널 · MoE 스트리밍 · KV 캐시 · 샘플링 · MTP |
| 텐서 로더 | c/st.h | safetensors 파싱(헤더만 읽어 메모리 매핑) |
| 토크나이저 | c/tok.h, tok_unicode.h | 바이트 단위 BPE(GPT-2식), 320k 병합, 유니코드 정규식 |
| JSON | c/json.h | 설정·API용 최소 JSON 파서(라이브러리 없이 손수) |
| 메모리 계층 | c/tier.h | Disk / RAM / VRAM 저장 계층 계획(resource plan) |
| CUDA 백엔드(선택) | c/backend_cuda.cu/.h | 상주 텐서용 int8/int4/int2/f32 커스텀 커널(opt-in) |
| 호환 계층 | c/compat.h | OS/컴파일러 차이 흡수(Linux/WSL2/macOS) |
./setup.sh 한 번이면 빌드된다. 파이썬은 일회성 모델 변환에만 쓰이고, 추론 경로엔 전혀 없다.| 도구 | 역할 |
|---|---|
coli (CLI, Python) | 사용자 진입점. chat/serve/run/plan/convert/bench/build 서브커맨드를 C 엔진(glm)에 위임하는 래퍼 |
tools/convert_fp8_to_int4.py | FP8 원본을 샤드 단위로 받아 int4 컨테이너로 재양자화 후 원본 삭제(756GB를 한 번에 두지 않음, 재개 가능) |
tools/download_glm52.py | HuggingFace에서 GLM-5.2 체크포인트 내려받기 |
tools/convert_fp8_to_int4.py + MTP | 투기적 디코딩용 MTP 헤드를 int8로 변환(int4면 draft 채택률 붕괴) |
openai_server.py | 표준 라이브러리만으로 만든 OpenAI 호환 HTTP 게이트웨이(추론은 여전히 C 엔진) |
resource_plan.py / eval_glm.py / make_glm_oracle.py | 저장 계층 계획 · 품질 벤치(MMLU/HellaSwag/ARC) · transformers 대조용 오라클 생성 |
iobench.c | "내 디스크가 엔진이 쓰는 방식(19MB 병렬 랜덤 읽기)으로 얼마나 빠른가" 측정 |
web/는 React + TypeScript + Vite로 만든 브라우저 채팅 UI(~390줄). 엔진을 직접 건드리지 않고 순수 OpenAI Chat Completions 클라이언트로만 동작한다 — coli serve가 띄운 서버(또는 다른 호환 엔드포인트)에 SSE 스트리밍으로 붙는다. shadcn/ui 스타일 컴포넌트(button/input/badge/textarea)를 쓴다. 저자는 "터미널 coli chat이 여전히 1급 인터페이스"라고 명시한다.
C 엔진(glm.c)이 심장이고, coli(Python CLI)는 그 심장을 편하게 부르는 리모컨, openai_server.py는 표준 프로토콜 어댑터, web/는 그 프로토콜에 붙는 껍데기다. 심장만 있으면 나머지는 전부 옵션 — 이 계층 분리가 colibrì 설계의 뼈대다.
"디스크가 램보다 30배 큰 모델을 어떻게 돌리는가"의 실제 메커니즘.
colibrì 설계의 출발점은 GLM-5.2를 두 덩어리로 쪼개는 것이다.
매 토큰마다 라우터가 각 층에서 256명 중 8명의 전문가를 고른다. colibrì는 그 8명의 가중치만 디스크에서 읽어 계산하고, 안 쓰인 나머지는 건드리지 않는다. 그래서 "콜드"(캐시 비었을 때) 한 토큰의 비용이 약 11.4GB의 디스크 읽기다 — 이게 속도의 근본 병목이다.
.coli_usage)엔진이 "당신의 사용 패턴이 실제로 어떤 전문가를 부르는지"를 매 턴 기록한다. 재시작 시 그 가장 자주 쓰인 전문가들을 남는 램에 자동 PIN한다. 문자 그대로 쓸수록 빨라진다. Framework 13(128GB)에서 이 학습 PIN으로 전문가 히트율 28%→66%까지 올라 속도가 붙었다(측정치).
PILOT=1)놀랍게도 다음 층의 라우팅은 미리 71.6% 예측 가능하다(층 L의 어텐션 후 상태에 층 L+1의 라우터를 적용하면 실제 top-8의 71.6%를 맞춘다 — "직전 토큰과 같은 전문가"의 41.3%보다 훨씬 높다). 이를 이용해 현재 층을 계산하는 동안 별도 I/O 스레드가 다음 층 전문가를 미리 디스크에서 읽어 둔다.
GLM-5.2 자체의 MTP 헤드(78층)가 다음 토큰들을 미리 초안(draft)으로 뽑고, 본 모델이 한 번의 배치 forward로 검증한다. 채택되면 여러 토큰을 한 번에 확정 → forward당 2.2~2.8토큰. 단 헤드는 반드시 int8이어야 한다(int4면 채택률 0~4%로 붕괴). 무손실(rejection sampling으로 샘플링에서도 손실 없음)이지만, 콜드 캐시에선 오히려 전문가 로드가 늘어 시간상 손해일 수 있어 적응형 가드로 켜고 끈다.
GLM-5.2는 64헤드에 GQA가 없어 KV 캐시가 원래 거대하다(토큰당 32,768 float). MLA(q/kv-LoRA)로 이를 토큰당 576 float로 압축(57배 작게). 게다가 디코드 시 DeepSeek식 "가중치 흡수"로 토큰마다 k/v를 재구성하지 않는다 — 쿼리가 kv_b를 흡수하고 문맥은 어텐션 후 투영. 정확도는 token-exact로 검증됨.
프리필(그리고 MTP 검증)에서 배치의 각 고유 전문가를 디스크에서 딱 한 번만 읽어 그 전문가로 라우팅된 모든 위치에 적용한다(같은 책을 여러 번 안 꺼냄). 동시에 한 블록의 전문가를 곱하는 동안 커널이 이미 WILLNEED로 다음 블록을 읽고 있다(비동기 선読).
colibrì는 가중치를 int8 / packed int4 / packed int2로 저장하고, 활성값도 int8로 양자화해(Q8_0식) 정수 내적(AVX2 maddubs)으로 곱한다. 측정상 int8 matmul이 1.4~2.5배(119 GFLOP/s), int4가 배치에서 1.8배 빠르다. 재밌는 디테일: 어떤 커널을 쓸지 모양(shape)별로 실측으로 결정한다 — int4 단일 행(디코드)은 오히려 f32가 빨라서 그렇게 둔다.
원본 GLM-5.2는 FP8로 756GB다. 이걸 한 번에 디스크에 두는 건 부담이다. 변환기는 샤드 하나(~5GB)만 받아 → 역양자화(128×128 블록 스케일) → 엔진 컨테이너로 재양자화 → 그 샤드 삭제를 반복한다. 그래서 756GB가 동시에 존재할 필요가 없다. 중단 후 재개도 된다. 결과물은 int4로 ~370GB.
coli serve는 744B 모델을 한 프로세스에 한 번만 올려 두고 OpenAI 호환 HTTP를 연다. 동시 요청은 병렬로 "척"하지 않고 경계형 FIFO 큐에 넣는다(--max-queue 8). 엔진이 가변 KV 컨텍스트 하나를 소유하기 때문이다. 포화·타임아웃 요청엔 OpenAI 형식 HTTP 429를 반환하고, --kv-slots N으로 최대 16개 독립 시퀀스 컨텍스트를 둘 수 있다(각 슬롯이 자기 KV·MTP·.coli_kv 소유). "스레드로 돌리니 연속 배치인 척"하지 않는 정직한 설계다.
런타임 경로는 일부러 평평하고 읽기 쉽게, 도구는 따로.
① README.md로 설계 철학과 수치를 잡고 → ② c/coli(Python CLI)로 사용자가 무엇을 부를 수 있는지 보고 → ③ c/glm.c 상단의 typedef struct들(텐서 QT, 전문가 slab, Model 구조체)로 데이터 모델을 파악한 뒤 → ④ matmul_i4_idot/dot_i4i8 같은 양자화 커널과 MoE 라우팅 부분을 정독하는 순서가 가장 빠르다. 테스트(c/tests/)가 무의존이라 각 부품을 독립 실행해 보며 이해하기 좋다.
이 레포에서 무엇을, 어떻게 배울 수 있는가.
이론으로만 듣던 "라우터가 전문가를 고른다"를 실제 C 코드로 본다: DeepSeek-V3식 sigmoid 라우터(noaux_tc, routed_scaling_factor), 공유 전문가, 앞 3개 dense층, top-k 선택. 왜 MoE가 "크지만 활성은 작다"인지, 왜 이게 스트리밍을 가능하게 하는지 몸으로 익힌다.
STATS=stats.txt ./coli chat로 실제 어떤 전문가가 얼마나 불리는지 기록하고, 분포를 시각화해 보라. "몇몇 전문가가 압도적으로 자주 쓰인다"는 걸 눈으로 확인하면 PIN/학습 캐시가 왜 효과적인지 이해된다.dot_i8i8, dot_i4i8, matmul_i4_idot를 읽으면 AVX2 _mm256_maddubs_epi16로 int8×int8을 어떻게 누산하는지, 왜 활성값도 양자화(per-row scale)하는지, packed int4를 어떻게 언패킹하며 곱하는지가 보인다. "양자화 = 정확도 손실"만 알던 사람이 "양자화 = 정수 SIMD로 CPU에서 몇 배 빠르게"라는 반대 면을 배운다.
LRU 캐시, PIN(핫 세트), OS 페이지 캐시를 L2로 재활용, 램 예산에서 캐시 cap 자동 산정 — 이건 사실상 운영체제 캐싱 이론의 응용 사례다. CS 교과서의 "캐시 계층·지역성(locality)"이 실제 성능을 어떻게 좌우하는지 살아 있는 코드로 확인할 수 있다.
MTP 헤드로 초안을 뽑고 본 모델이 검증하는 흐름, rejection sampling으로 무손실을 유지하는 법, "콜드 캐시에선 오히려 손해"라는 현실적 트레이드오프까지. 논문에서만 보던 speculative decoding이 왜 항상 이득이 아닌지 체감한다.
JSON 파서·BPE 토크나이저·safetensors 로더·SSE 스트리밍을 외부 의존성 0으로 구현한 코드를 본다. 무엇이 정말로 "필수 의존성"이고 무엇이 습관적으로 끌어다 쓰는 것인지 판단하는 감각이 길러진다.
| 기술 | 이 레포에서 배우는 것 |
|---|---|
| MoE | 라우터·전문가·활성 파라미터, 스트리밍이 가능한 이유 |
| 양자화 | int8/int4/int2 패킹, AVX2 정수 내적, shape별 커널 선택 |
| 캐싱 | LRU·PIN·페이지 캐시·예산 기반 자동 cap |
| KV 캐시 | MLA 압축(57배), 가중치 흡수, 디스크 영속화(warm 재개) |
| 디코딩 | MTP 투기, rejection sampling 무손실, 적응형 가드 |
| I/O | WILLNEED 선読, O_DIRECT, 병렬 랜덤 읽기 벤치(iobench) |
| 서빙 | OpenAI 호환 API, FIFO 큐, KV 슬롯 격리 |
"돌리려면" 최소 무엇이, "쓸 만하려면" 무엇이 필요한가.
| 항목 | 요구 |
|---|---|
| OS | Linux 또는 WSL2 (macOS도 커뮤니티 검증됨) |
| 컴파일러 | gcc + OpenMP |
| CPU | AVX2 지원 (정수 커널 필수) |
| RAM | ≥16GB (dense int4 ~9.9GB 상주 + 여유) |
| 디스크 | 로컬 NVMe에 int4 모델 ~370GB (ext4 권장, 네트워크/9p 마운트 불가) |
| 변환 시(1회) | python + torch·safetensors·huggingface_hub·numpy, ~400GB 여유 |
콜드 디코드는 토큰당 ~11GB 랜덤 읽기 → 디스크 대역폭이 곧 속도 상한. 램이 작으면(24GB) 전문가 캐시가 층당 2슬롯으로 자동 축소돼, 디스크가 아무리 빨라도 캐시 미스로 콜드에 머문다(램이 binding 제약). 반대로 램이 크면 콜드 읽기가 공짜 캐시 히트로 바뀐다. SSD 수명 주의: 스트리밍은 읽기 전용이라 마모는 적으나, 램 부족 시 swap 쓰기와 장시간 발열이 진짜 위험이다 — 합리적 --ram 예산을 지켜라.
| 머신 | 기대 속도 |
|---|---|
| 개발 PC (WSL2 VHDX ~1GB/s, 25GB RAM) | ~0.05~0.1 tok/s 콜드 (검증된 기준선) |
| 네이티브 리눅스, PCIe4 NVMe(~3~5GB/s), 32GB | ~0.5~1 tok/s (추정) |
| PCIe5 NVMe/2×NVMe RAID0(~8~12GB/s), 64GB + PIN 40GB | ~2~4 tok/s (추정) |
| 128~256GB RAM, 12코어 (핫 전문가 캐시) | ~2~4 tok/s, matmul 바운드 (추정) |
| + 24~32코어 또는 AVX-512/VNNI 커널 | ~5~15 tok/s, 대화형 (추정) |
실측 커뮤니티 수치: Apple M5 Max(128GB unified, 14.2GB/s SSD)에서 ~1.06 tok/s(전문가 히트 23%), Framework 13 Ryzen AI 9(128GB, 학습 PIN 46.7GB)에서 0.37 tok/s(히트 66%, MTP 채택 52%). 램이 클수록 병목이 디스크에서 커널로 넘어간다.
모델 없이도 할 수 있는 것부터, 전체를 돌리는 것까지.
cd c && ./setup.sh로 gcc/OpenMP 확인·빌드·자가검증(32/32)을 돌린다. 그다음 c/tests/의 test_json.c, test_tok.c를 직접 컴파일·실행해 JSON 파서와 BPE 토크나이저가 어떻게 동작하는지 입력을 바꿔 가며 관찰한다. 모델 가중치가 전혀 필요 없다.
gcc -O2 -fopenmp iobench.c -o iobench 후 아무 큰 파일에 대해 ./iobench <file> 19 64 8 0(버퍼드)과 ... 8 1(O_DIRECT)을 돌려, 엔진이 실제로 쓰는 방식(19MB 병렬 랜덤 읽기)으로 내 SSD가 몇 GB/s인지 잰다. 이 숫자로 위 성능표의 어느 행에 내 머신이 앉는지 예측할 수 있다.
python tools/make_glm_bench_model.py --output ... 로 실제 언어모델은 아니지만 MLA/MoE/스트리밍 shape를 똑같이 보존한 313M 랜덤 가중치 모델을 만든다. 그다음 benchmark_cuda_fixture.py로 CPU 스트리밍 vs CUDA 상주 vs 핫 전문가 실행을 같은 토큰으로 비교한다. 744GB 체크포인트 없이 아키텍처를 실험하는 정석 루트.
HuggingFace의 사전 변환된 jlnsrk/GLM-5.2-colibri-int4를 받아(변환 단계 생략) COLI_MODEL=... ./coli chat으로 대화한다. 한 턴 뒤 stats 라인(tok/s·전문가 히트율·RSS)을 읽고, --topp 0.7을 켜 디스크 읽기 30~40% 절감 효과를 직접 측정해 본다. (MTP 헤드는 int8 버전을 써야 투기가 동작.)
./coli bench로 MMLU/HellaSwag/ARC를 돌린다. int4 양자화가 정확도를 얼마나 깎는지는 아직 아무도 못 쟀다 — 저자가 공개적으로 "help wanted"로 요청한 그 측정이다. 빠른 디스크가 있다면 이 한 번의 실행이 프로젝트에 가장 큰 기여가 된다(풀 정밀도 GLM-5.2는 이 태스크들에서 85~95%대).
colibrì를 완전히 소화하기 위한 4주 코스.
어텐션·KV 캐시의 개념을 잡고, MoE가 "왜 크지만 활성은 작은가"를 이해한다. GLM-5.2의 MLA(다중 헤드 잠재 어텐션)와 DeepSeek식 sigmoid 라우터 논문을 훑는다. 목표: glm.c의 forward 흐름을 위→아래로 따라 읽을 수 있게 되기.
int8/int4/int2 양자화(per-row scale, 블록 스케일), Q8_0 포맷, AVX2 정수 명령(maddubs, madd)을 공부한다. dot_i8i8/dot_i4i8를 손으로 따라 계산해 본다. 목표: "왜 정수 내적이 f32보다 빠른가"를 수치로 설명하기.
가상 메모리·페이지 캐시·madvise(WILLNEED)·O_DIRECT·mmap을 익힌다. LRU/캐시 지역성 이론과 colibrì의 PIN·학습 캐시를 연결한다. iobench.c로 버퍼드 vs O_DIRECT 차이를 실측한다. 목표: "디스크가 램의 확장이 되는" 조건을 설명하기.
투기적 디코딩(draft-verify, rejection sampling), nucleus/temperature 샘플링, KV 압축·영속화를 파고든다. openai_server.py로 OpenAI 호환 API·SSE 스트리밍·FIFO 큐를 이해한다. 목표: colibrì의 성능 트레이드오프(콜드/웜, MTP on/off)를 스스로 튜닝하기.
colibrì를 이해하면 llama.cpp / vLLM / DeepSeek·GLM 계열 논문이 훨씬 잘 읽힌다. 이 레포는 그 큰 세계로 들어가는 "작지만 완결된" 관문이다. 반대로 각 부품(양자화·KV 압축·투기 디코딩)은 독립적으로도 깊은 주제라, 관심 가는 하나를 골라 논문→구현으로 파고들기 좋다.
문서에 나온 용어를 한자리에.
.coli_kv)해 재시작 후에도 대화를 warm하게 이어간다..coli_usage)을 기록해 가장 자주 쓰는 전문가를 자동 PIN → "쓸수록 빨라짐".DSA=0으로 끌 수 있다.madvise로 "곧 필요"를 알려 선読. 페이지 캐시=이미 읽은 파일을 램에 캐싱하는 OS 기능 → colibrì가 공짜 L2로 활용.coli plan), 텐서는 필요할 때 매핑한다.더 깊이 파고들 곳.