3. 작동 원리 심층: Colibri는 어떻게 한계를 넘었는가?
이 엔진이 실제로 어떻게 구동되는지 기술의 밑바닥까지 깊게 파헤쳐 보겠습니다. 단순히 데이터를 디스크에서 읽어오는 것을 넘어, MoE 아키텍처의 구조적 빈틈을 완벽하게 찔러넣은 결과물입니다.
3.1. MoE 아키텍처의 특성 활용
GLM-5.2 모델은 7440억 개의 파라미터를 가지고 있지만, 재미있게도 하나의 토큰을 생성할 때 이 모든 파라미터가 사용되지는 않습니다. 혼합 전문가(MoE) 구조의 특성상 텍스트를 생성할 때 토큰당 약 400억 개(40B)의 파라미터만 선별적으로 활성화됩니다. 더욱 중요한 사실은 토큰이 바뀔 때마다 변경되는 데이터는 약 11GB 수준에 불과하다는 점입니다.
Colibri는 전체 모델을 크게 두 부분으로 엄격하게 분리합니다.
- Dense 파트 (상주 영역): 어텐션 레이어, 임베딩, 그리고 모든 과정에서 공유되는 전문가 영역입니다. 약 170억 개(17B)의 파라미터로 구성되며 INT4 양자화 시 약 9.9GB의 용량을 차지합니다. 이 부분은 한순간도 빠짐없이 메모리에 고정(Resident)됩니다.
- Sparse 파트 (스트리밍 영역): 75개의 MoE 레이어에 각각 256개씩 흩어져 있는 21,504개의 라우팅 전문가들입니다. 각 전문가 모듈은 INT4 기준 약 19MB의 크기를 가지며 총합 370GB에 달합니다. 이들은 오로지 NVMe 디스크에 저장됩니다.
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
erDiagram
E_MODEL_WEIGHTS {
string dense_weights
string routed_experts
}
E_DENSE_PART {
int4 attention_layers
int4 shared_experts
int4 embeddings
}
E_SPARSE_PART {
int4 expert_block_1
int4 expert_block_n
}
E_MODEL_WEIGHTS ||--o{ E_DENSE_PART : includes
E_MODEL_WEIGHTS ||--o{ E_SPARSE_PART : includes
3.2. INT4 양자화와 독자적인 메모리 매핑
Colibri는 기존의 널리 쓰이는 GGUF나 AWQ 같은 범용 양자화 포맷을 과감히 버리고, 자신만의 독자적인 INT4 양자화 컨테이너를 사용합니다. 이는 C 커널 레벨에서 발생하는 수학적 연산 오차를 극한으로 통제하기 위함입니다. FP8(e4m3) 기반의 원본 가중치를 F32로 변환한 뒤, 비트 단위의 정확성을 맞추기 위해 엔진의 lrintf 함수와 완벽히 동일하게 토큰 단위 매칭을 수행하는 U8 패킹 및 F32 스케일링을 적용했습니다. 이 최적화 덕분에 CPU만으로도 데이터 병목을 줄이면서 연산 정밀도를 유지할 수 있었습니다.
3.3. 3단계 캐싱과 디스크 스트리밍 병목 극복
SSD에서 데이터를 매번 읽어오는 작업은 엄청난 지연(Latency)을 발생시킵니다. 이를 극복하기 위해 Colibri는 정교한 3단계 메모리 캐시 전략을 취합니다.
- LRU 캐시 (최근 최소 사용 캐시): 각 MoE 레이어마다 방금 전까지 사용했던 전문가를 RAM의 한구석에 남겨둡니다. 비슷한 주제의 텍스트가 연속해서 생성될 때 같은 전문가가 다시 호출될 확률이 높기 때문입니다.
- Pinned Hot-Store: 사용자가 설정한 여유 RAM 용량만큼을 완전히 고정된 캐시 풀로 만들어, 가장 빈번하게 호출되는 소수의 전문가를 절대로 디스크로 쫓아내지 않게 만듭니다.
- OS Page Cache (운영체제 무료 L2 캐시): 엔진이 명시적으로 코딩하지 않아도, 리눅스 운영체제는 디스크에서 읽은 데이터를 남는 램 영역에 몰래 보관해 둡니다. Colibri는 이 운영체제의 기본 동작을 공짜 L2 캐시처럼 활용합니다.
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
stateDiagram-v2
[*] --> State_OnDisk
State_OnDisk --> State_Streaming : 라우터 요청
State_Streaming --> State_InCache_Hot : 스트리밍 완료 및 램 적재
State_InCache_Hot --> State_InCache_Hot : 반복 접근으로 캐시 유지
State_InCache_Hot --> State_LRU_Queue : 다른 전문가에 밀려남
State_LRU_Queue --> State_Evicted : 설정 캐시 용량 초과
State_Evicted --> State_OnDisk : 램에서 메모리 해제
이러한 정교한 파이프라인의 데이터 흐름은 다음과 같이 이루어집니다.
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
flowchart TD
A["사용자 입력 텍스트"] --> B["공통 파라미터 연산"]
B --> C["전문가 라우팅 계산"]
C --> D["필요한 전문가 디스크 요청"]
D --> E["메모리 내부 LRU 캐시 확인"]
E --> G["캐시에 있으면 바로 읽기"]
E --> F["캐시에 없으면 디스크 스트리밍"]
F --> H["스트리밍 완료 후 RAM 캐시에 등록"]
G --> I["MoE 레이어 최종 연산"]
H --> I
I --> J["결과 취합 및 다음 토큰 생성"]
3.4. MTP를 통한 투기적 해독과 I/O 비용 절감
가장 흥미로운 최적화 중 하나는 GLM-5.2 모델의 78번째 레이어에 위치한 MTP(Multi-Token Prediction) 헤드를 적극적으로 활용한 점입니다. 이는 한 번에 하나의 토큰만 예측하는 것이 아니라 여러 토큰을 추측한 뒤 이를 검증하는 네이티브 투기적 해독(Speculative Decoding) 기능입니다. 디스크 읽기 속도가 가장 큰 병목인 시스템에서, 한 번 무거운 전문가 데이터를 읽어왔을 때 토큰을 하나만 만들고 버리는 것이 아니라 여러 개의 토큰을 동시에 뽑아낼 수 있어 효율이 크게 상승합니다.
3.5. 순수 C 언어 기반의 제로 의존성
이 모든 복잡한 시스템이 놀랍게도 외부 의존성이 전혀 없는 약 1,300줄짜리 단일 C 언어 파일(glm.c)로 구현되어 있습니다. Python의 무거운 가상 환경이나 PyTorch, 심지어 선형대수학 처리를 위한 BLAS 라이브러리조차 사용하지 않았습니다. 오직 GCC 컴파일러와 OpenMP, 그리고 AVX2 명령어 셋만으로 완벽하게 구동되는 구조는 리소스가 극도로 제한된 환경에서 빛을 발합니다.
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
classDiagram
class C_Engine {
+start_inference()
+load_weights()
}
class C_MemoryManager {
+allocate_dense()
+stream_expert_chunk()
}
class C_ExpertRouter {
+compute_routing_weights()
+get_top_k_experts()
}
class C_LRUCache {
+get_entry()
+evict_oldest()
}
C_Engine --> C_MemoryManager
C_Engine --> C_ExpertRouter
C_MemoryManager --> C_LRUCache