← 전체 글

엔지니어링

2.78조 파라미터 모델이 RAM 8GB와 179KB짜리 C 코드로 돌아간다. 정작 중요한 숫자는 1.7테라바이트다

kimi-k3-in-c는 전문가 혼합(MoE) 모델이 실제로는 얼마나 조금만 살아 있는지를 끝까지 파고들어, 문샷의 최대 공개 가중치 모델을 평범한 컴퓨터에 올렸다. 엔지니어링은 진짜고 계산도 맞는다. 다만 제목은 하드웨어 요구사항이 어디로 옮겨갔는지를 가린다.

MAI
GitHub이 자동 생성한 FareedKhan-dev/kimi-k3-in-c 저장소의 소셜 카드. 소유자 아바타, 큰 글씨의 저장소 이름, 한 줄 설명, 스타·포크·이슈 수가 표시돼 있다.

개인 개발자가 만든 프로젝트 kimi-k3-in-c는 문샷 AI의 Kimi K3 — 2.78조 파라미터, 지금까지 공개된 개방 가중치 모델 중 최대 — 추론을 CPU 한 개, 최대 상주 메모리 8.24GB로 돌린다. 엔진은 C99으로 작성돼 BLAS도 파이토치도 GPU 코드 경로도 없이 180KB 미만으로 컴파일된다. 스타 8.1k, 포크 1.3k, 라이선스는 Apache 2.0이다.

말이 안 되는 주장처럼 들린다. 그런데 사실이고, 사실인 방식이 제목보다 흥미롭다.

산수를 따라가 보면

bfloat16 기준 K3의 가중치는 약 5,560GB다. 저장소는 여기서부터의 축소를 네 단계로 보여주는데, 어느 것도 모델에 부린 꼼수가 아니라 모델 자체의 성질이다.

단계크기이유
bf16 가중치5,560GB기준값
공개 체크포인트1,560GB전문가가 이미 MXFP4 — 가중치당 0.53바이트
상주 집합113.49GB라우팅되는 전문가는 상주가 아니라 스트리밍 가능
실측 최대치8.24GB밀집 트렁크를 한 층씩 스트리밍

무게를 지고 있는 건 두 번째 단계이고, 그것은 양자화가 아니다. K3는 각 토큰을 층마다 896개 전문가 중 16개로 라우팅한다. 나머지 880개는 그 토큰에게 비활성이다. 통상의 추론 스택은 가중치를 옮기는 비용이 크기 때문에 전부 메모리에 들고 있지만, 이 프로젝트는 대신 I/O를 지불하며 거의 아무것도 상주시키지 않는다. 문샷 자신의 아키텍처 자료는 2.8조 중 토큰당 활성 파라미터를 약 500억으로 적고 있다. 다시 말해 이 모델은 애초부터 98%가 놀고 있었고, 그걸 문자 그대로 받아들인 엔진을 아무도 만들지 않았던 것이다.

어텐션도 같은 취급을 받는다. 93개 층 중 69개는 Kimi Delta Attention을 쓰는데, 그 재귀 상태는 컨텍스트 길이와 무관하게 고정 217MB다. 전역 어텐션 24개 층은 MLA를 써서 96헤드 × 320차원 대신 위치당 576차원 잠재 표현 하나만 캐시한다. 저장소는 이를 53배 축소로 측정했다. 둘 다 작성자의 발명이 아니다. 모두 K3의 설계 선택이며, GPU를 전제한 스택에는 그 메모리상 함의를 활용할 이유가 딱히 없었을 뿐이다.

여기서 실제로 만들어진 것

작성자 본인의 엔지니어링은 배관에 있고, 그것이 유난히 꼼꼼하다. MXFP4 가중치는 역양자화 없이 패킹된 형태로 곱해지는데, 저장소의 계산으로는 이것이 토큰당 194GB의 메모리 트래픽을 없앤다. 손으로 쓴 JSON 스캐너는 96개 safetensors 샤드에 걸친 497,220개 텐서를 헤더만 읽어 0.27초에 인덱싱한다. BPE 토크나이저는 tiktoken을 바이트 단위로 일치하도록 재구현했고, 유니코드·이모지·코드에 걸친 왕복 검증을 통과한다.

가장 많은 것을 말해주는 건, 틀리면 그럴듯해 보이는 쓰레기를 조용히 내놓는 다섯 개 불변식을 나열한 절이다. A_log는 채널이 아니라 헤드 단위로 색인해야 한다는 것. UT 변환 역행렬의 부호. KDA의 두 행렬 중 어느 쪽이 대각 성분을 유지하는가. MLA가 캐시하지만 결코 회전시키지 않는 64개 rope 차원. 그리고 라우터 편향은 전문가 선택만 유도하고, 가중은 편향 없는 시그모이드 점수가 한다는 것. 이 목록은 각 항목에서 한 번씩 데어본 사람이 아니면 쓰지 못한다. 테스트 스위트는 파이토치 참조 구현에 대한 세 개의 적합성 게이트 — 티처 포싱, 그리디 디코드, 캐시를 쓴 증분 디코드 — 를 통과할 때까지 생성을 막고, 커널과 토크나이저 계층은 가중치를 1바이트도 내려받기 전에 검증할 수 있다.

그 대가

프리셋최대 RSS처리량
Laptop8.24GB약 32초/토큰
Desktop31.9GB약 28~31초/토큰
Workstation95.5GB약 24초/토큰
Server약 128GB약 19~21초/토큰

토큰당 32초는 분당 두 토큰쯤이다. 300토큰 답변이면 오후가 통째로 간다. 그리고 작은 구성에서는 실행 시간의 71%가 연산이 아니라 저장장치 읽기에 쓰인다. 엔진은 디스크를 기다리고 있는 것이다. 메모리를 I/O와 맞바꾸는 설계라면 정확히 예상되는 결과다.

이 표에는 두 가지 주의가 필요하다. 수치는 124코어 2소켓 AMD EPYC 7763에서 측정됐고, 프리셋은 기계를 바꾸는 게 아니라 메모리 예산에 상한을 씌운다. 실제 8GB 노트북에는 124코어도 그런 메모리 대역폭도 없으니, Laptop 행은 '노트북에서의 결과'가 아니라 '메모리 예산을 조인 결과'다. 그리고 충실도 주장 — 모든 프리셋에서 바이트 단위로 동일한 출력 — 은 프로젝트 자신의 테스트 스위트에 근거한다. 그 스위트는 잘 만들어진 것으로 보이지만, 독립적인 재현 보고는 공개되지 않았다.

요구사항은 어디로 갔나

제목이 빼놓은 한 줄이 여기 있다. 이 프로젝트는 약 1.7TB의 여유 저장 공간을 요구한다. 체크포인트 1.56TB에, 첫 실행 전에 생성하는 109GB 패킹 트렁크 파일을 더한 값이다.

메모리 요구는 사라지지 않았다. 계층을 한 칸 내려가 DRAM에서 디스크로 옮겨갔고, 그 과정에서 세 자릿수만큼 느려졌다. 디스크는 싸고 DRAM은 비싸니 이는 정당하고 잘 고른 거래다. 다만 그것은 "RAM 8GB로 돌아간다"가 작업 집합을 말한 것일 뿐, 진입 장벽을 말한 게 아니라는 뜻이다. 장벽은 1.7TB 다운로드다.

그러므로 실용적 가치는 남는 데스크톱으로 K3를 서비스할 수 있게 된다는 데 있지 않다. 가치는 이 엔진이 K3 추론이 실제로 무엇으로 이루어져 있는지를, 의존성 없이 처음부터 끝까지 읽을 수 있는 형태로 완전히 진술한다는 데 있다. 카르파티의 llama2.c 계보이며, 끝까지 읽을 수 있고 몇 초 만에 컴파일되는 물건이다. K3를 특이한 하드웨어로 이식하려는 사람에게, 또는 조 단위 파라미터 MoE가 실제로 어디에 바이트를 쓰는지 이해하려는 사람에게, '조용히 틀리는 다섯 가지 방법' 목록이 붙은 179KB C 프로그램은 그 모든 것을 감추는 프레임워크보다 훨씬 값지다.

출처: kimi-k3-in-c (GitHub) · Kimi K3 모델 개요 (Hugging Face) · 문샷 AI, Kimi K3 공개 (CNBC)

이어서 읽기