32GB RAM PC에서 거대 LLM(GLM 5.2)을 C 엔진으로 구동하는 기술

본 프로젝트는 744B 파라미터의 MoE 모델을 일반 PC에서 구동하기 위해 데이터 격리 아키텍처(Data Isolation Architecture)를 적용했습니다. 약 9.9GB의 핵심 파라미터는 RAM에 상주시키고, 나머지 약 370GB의 라우팅된 전문가(routed experts)는 디스크에 저장 후 필요에 따라 스트리밍하는 방식입니다. 이를 통해 메모리 부족(Out-of-Memory, OOM) 문제를 해결하고, LRU 캐시 및 OS 페이지 캐시를 활용하여 디스크 I/O 성능을 최적화합니다. 이는 LLM의 로컬 구동 가능성을 크게 확장하는 접근 방식입니다.

추론 엔진 'Colibrì'는 GPU나 Python, BLAS 라이브러리 없이 순수 C 언어로 구현되었습니다. 약 1,300줄의 코드로 구성된 단일 파일 엔진은 AVX2 명령어셋을 활용한 정수 연산 커널(int8, int4)을 통해 성능을 확보합니다. 이는 시스템 리소스 제약이 있는 환경에서도 LLM을 실행할 수 있게 하는 핵심 요소이며, 개발자는 하드웨어 제약 없이 모델을 테스트할 수 있습니다. 커뮤니티에서는 이러한 엔진의 단순성과 이식성에 주목하고 있습니다.

콜드 스타트 시 0.05~0.1 tok/s의 낮은 처리 속도에 대한 우려가 제기되었습니다. 특히 SSD 마모에 대한 경고도 언급되었는데, 콜드 스타트 시 발생하는 무작위 읽기 작업이 SSD 수명에 영향을 줄 수 있다는 지적입니다. 이에 대해 개발자는 읽기 전용 파티션이나 별도 파티션 사용을 제안하며, 페이지 캐시 동작 방식에 대한 논의도 이어졌습니다. 데이터 미저장 정책(Zero-Retention Policy)과는 별개로, 하드웨어 수명 관리 측면에서의 고려가 필요함을 시사합니다.

커뮤니티에서는 llama.cpp 기반의 Medusa나 Apple Silicon의 통합 메모리 활용 등 유사한 접근 방식들이 논의되었습니다. 특히 MTP(Multi-Token Prediction) 스펙큘레이티브 디코딩과 KV 캐시 압축 기술이 성능 향상에 기여할 수 있다는 의견이 많습니다. 또한, RAID0 구성이나 Intel Optane 메모리와 같은 스토리지 최적화 방안도 제안되었으며, MPI를 활용한 클러스터 분산 처리 가능성도 언급되었습니다. 이는 LLM 추론 성능 향상을 위한 다양한 기술적 탐색이 진행 중임을 보여줍니다.

int4 양자화(Quantization)가 모델의 정확도(Accuracy)에 미치는 영향에 대한 벤치마킹이 부족하다는 점이 지적되었습니다. 개발자는 Hugging Face에서 제공하는 GLM-5.2 int4 모델을 사용했지만, 정량적 품질 평가는 아직 이루어지지 않았습니다. 커뮤니티에서는 MMLU, HellaSwag, ARC와 같은 표준 벤치마크를 통해 int4 양자화의 성능 저하를 측정하는 것이 프로젝트의 다음 단계에서 가장 중요하다고 강조합니다. 이는 모델의 실질적인 유용성을 검증하는 데 필수적입니다.