2.78조 파라미터 모델의 체크포인트는 디스크에서 1.56테라바이트를 차지합니다. 이걸 램 8.24기가바이트만 쓰고 돌린 사람이 있죠. GPU도, BLAS도, 프레임워크도 없이 C99로만 짠 176KB짜리 엔진으로 말입니다.

kimi-k3-in-c는 개발자 Fareed Khan이 공개한 Kimi K3 추론 구현입니다. 8GB 노트북에서 토큰 하나에 26.5초, 128GB 워크스테이션에서 5.6초가 걸렸습니다. 눈길이 가는 대목은 속도가 아니라 출력이죠. 메모리 크기가 달라져도 결과는 바이트 단위로 동일했습니다.

출처: kimi-k3-in-c – GitHub

메모리는 성능이 아니라 시간을 산다

보통 로컬 추론에서 램 용량은 “돌아가느냐 마느냐”의 문턱입니다. 이 프로젝트에서는 램이 문턱이 아니라 다이얼이죠. 8GB에서는 매 스텝마다 모델 전체가 디스크에서 흘러나오고, 128GB에서는 모델이 통째로 메모리에 앉아 디스크 대기가 사라집니다.

측정 조건은 밝혀두는 편이 낫겠죠. 124코어에 빠른 NVMe 드라이브를 단 한 대의 기계에서, 같은 짧은 프롬프트로 메모리 예산만 바꿔가며 잰 수치입니다. 드라이브가 느리면 앞쪽 구간은 더 느려집니다. 그리고 이 모델은 베이스 모델이라 채팅 템플릿이 없어서, “프랑스의 수도는”에 대한 출력은 답변이 아니라 이어쓰기로 나옵니다.

왜 이런 일이 가능한가

Kimi K3는 전문가 혼합(MoE) 모델입니다. 파라미터는 2.78조지만 토큰 하나를 만드는 데 실제로 쓰이는 건 4% 남짓이죠. 나머지는 그 순간 놀고 있는 겁니다.

kimi-k3-in-c는 이 구조를 그대로 이용합니다. 조밀한 트렁크만 원하는 깊이까지 메모리에 두고 나머지는 흘려보내며, 1.45TB에 달하는 라우팅 전문가는 상주시키지 않고 4비트로 압축된 형태 그대로 곱해버리죠. 여기에 메모리가 자라지 않는 어텐션(KDA)과 96개 헤드 대신 잠재 표현 하나를 쓰는 MLA가 더해집니다.

같은 문제, 다른 해법

sqliteai/warp는 같은 모델을 다른 각도에서 공략합니다. 트렁크를 메모리에 두는 것까지는 같지만, 선택된 전문가를 NVMe에서 직접 스트리밍하고 남는 램 전부를 전문가 캐시로 씁니다. 라우터가 다음 계층에서 필요할 전문가를 미리 예측해 읽기를 앞당기는데, 실제 선택은 원래 라우터가 하므로 결과는 바뀌지 않고 타이밍만 달라집니다.

64GB 맥북 프로(M5 Pro)에서 측정한 속도는 초당 0.45~0.62토큰. 컨테이너는 982GB이고 모델을 여는 데만 29.19GB가 필요합니다. 증류하거나 가지치기한 축소판이 아니라 전체 모델이라는 점은 프로젝트가 분명히 밝히고 있죠. 참고로 이 저장소의 코드는 LLM이 작성하고 사람이 설계와 판단을 맡는 방식으로 개발되고 있습니다.

캐시를 키웠더니 여덟 배 느려졌다

WARP 문서에서 가장 눈에 띄는 건 실패 사례입니다. 전문가 캐시를 3.32GB에서 17.32GB로 키우자 적중률과 속도가 함께 올라갔죠. 그런데 23.32GB로 더 키우자 적중률은 계속 오르는데 처리량이 여덟 배 가까이 떨어졌습니다.

이유는 계층이 하나 더 있다는 데 있죠. 프로세스는 자기 예산 안에 있지만 기계 전체는 그렇지 않아서, 캐시 적중이 페이지 폴트로 바뀐 겁니다. 메모리를 더 주는 게 항상 빠른 건 아니라는 것.

로컬 추론의 상한선이 옮겨간 자리

두 프로젝트 모두 실용적인 속도와는 거리가 멉니다. 토큰 하나에 26초가 걸리는 도구로 할 수 있는 일은 많지 않죠. 대형 모델을 쓰고 싶다면 API가 여전히 압도적으로 합리적입니다.

그래도 이 실험들이 건드린 지점은 분명합니다. “모델 크기는 램 용량이 정한다”는 전제가 MoE 구조 앞에서는 성립하지 않는다는 것. 활성 파라미터만 제때 읽어올 수 있다면 램은 상한이 아니라 속도 조절기가 되고, 그 조절기의 다른 끝에는 저장장치 속도라는 새 변수가 놓입니다. 로컬에서 무엇까지 가능한지를 다시 재보는 중이라고 보는 편이 정확하겠죠.

참고자료:

• sqliteai/warp