2.78조 파라미터 Kimi K3를 맥북에서 돌린 C 추론 엔진 WASTE

2.78조 파라미터 모델을 노트북에서 돌린다는 말

• WASTE는 Kimi K3 2.78조 파라미터 모델을 소비자용 노트북에서 돌리기 위해 만든 C 추론 엔진임

  • 런타임 의존성은 libc와 pthreads 정도고, BLAS·CUDA·ONNX·Python 없이 돌아감
  • 현재 데모는 64GB 맥북 프로에서 Kimi K3 전체 open-weights 모델을 실행한 것
  • 속도는 0.45-0.62 토큰/초라 빠르진 않음. 그래도 2.78조 파라미터 모델을 로컬에서 실제로 굴렸다는 게 포인트임

• 모델 크기부터 정신이 아득함

  • Kimi K3는 원본 공개 가중치가 1.42TB이고, WASTE 컨테이너로 변환하면 982GiB가 됨
  • 디스크 제조사식 표기로는 약 1.05TB라서, 사실상 1TB급 내부 저장소를 모델 하나에 바치는 셈임
  • 최소 램 요구치는 4K 컨텍스트 기준 29.05GiB지만, 글쓴이는 32GB 머신은 페이지 스와핑 때문에 실사용으로 보지 말고 64GB를 현실적인 요구사항으로 봐야 한다고 함

왜 전체 모델을 램에 안 올려도 되나

• Kimi K3는 MoE(Mixture of Experts) 모델이라 매 토큰마다 전체 가중치를 다 쓰지 않음

  • 글에서는 토큰당 약 4%만 활성화된다고 설명함
  • 그래서 WASTE는 반복 사용되는 trunk는 메모리에 상주시키고, expert 가중치는 디스크에서 필요한 것만 읽음
  • “안 쓰는 가중치는 램에 있을 필요가 없고, 제때 도착하기만 하면 된다”는 설계임

• 토큰 하나를 만들 때 expert 가중치만 17GB를 읽음

  • K3는 92개 layer에서 각각 16개 expert를 건드림
  • 내부 SSD는 12.78GB/s로 측정됐고, 이 환경에서는 모델이 스트리밍됨
  • 외장 USB 인클로저는 0.94GB/s라 같은 토큰이 13초 걸린다고 함. 여기서 저장장치는 세부사항이 아니라 생명줄임

• 컨테이너 포맷도 I/O 중심으로 설계됨

  • 각 expert record는 4KiB 정렬이고, gate/up/down 행렬이 붙어 있어서 expert 하나가 정확히 pread 한 번으로 읽힘
  • macOS에서는 F_NOCACHE, 리눅스에서는 O_DIRECT, 윈도우에서는 FILE_FLAG_NO_BUFFERING으로 페이지 캐시를 우회함
  • 페이지 캐시에 기대면 작은 모델에서는 좋아 보이지만, 982GB 모델에서는 측정값이 현실을 속인다고 판단한 것

속도는 어디서 나왔나

• 제일 큰 최적화는 “덜 읽기”가 아니라 “언제 읽을지”였음

  • expert 읽기와 계산을 겹치게 만든 것만으로 K3에서 약 1.6배 이득을 봤다고 함
  • 각 layer의 router가 expert 16개를 고르면, 별도 스레드가 읽기를 시작하고 계산은 도착한 expert부터 소비함
  • 같은 일을 하되 기다리는 시간을 줄인 구조라 cache 통계와 logits는 그대로 유지됨

• Router lookahead도 꽤 영리함

  • 다음 layer의 실제 router 입력은 아직 없지만, 현재 layer의 hidden state로 다음 layer router를 한 residual 일찍 돌려봄
  • 이 추측의 rank 1 정확도는 92%, 처음 6개 기준으로는 81%라고 함
  • 이 방식으로 demand hit rate가 14%에서 38%로 올라갔고, 총 읽는 바이트 수는 늘지 않음

sequenceDiagram
    participant 현재계층 as 현재 계층
    participant 라우터 as 다음 계층 라우터
    participant 캐시 as Expert 캐시
    participant 저장소 as 내부 NVMe
    participant 계산 as MoE 계산
    현재계층->>라우터: 이전 hidden state로 expert 미리 추측
    라우터->>저장소: 다음 expert 읽기 시작
    저장소->>캐시: expert record 적재
    현재계층->>계산: 현재 계층 계산 진행
    계산->>라우터: 실제 hidden state 생성
    라우터->>캐시: 실제 expert 요청
    캐시->>계산: 이미 읽힌 expert 즉시 사용

• 메모리 예산은 더 많이 잡는다고 무조건 좋아지지 않았음
  • 32GB 예산에서는 expert cache가 3.32GB이고 hit rate는 0%, decode는 0.50 tok/s
  • 46GB 예산에서는 expert cache가 17.32GB이고 hit rate는 17%, decode는 0.53-0.55 tok/s
  • 52GB 예산부터는 0.04-0.15 tok/s처럼 재현성이 깨지고, 58GB는 0.02-0.03 tok/s로 더 망가짐
  • 이유는 엔진 예산 안에서는 맞아도 OS가 메모리를 회수하기 시작하면 “캐시 hit”가 page fault가 되어버리기 때문임

정확성 검증과 양자화

• 글쓴이는 “느리지만 맞는다”를 꽤 집요하게 증명하려고 함

  • 모든 layer를 PyTorch reference와 검증했고, 최종 logits 차이는 3.6e-06이라고 밝힘
  • vision tower도 자체 oracle과 2.3e-06 차이로 맞췄다고 함
  • 컨테이너 record header는 읽을 때마다 magic, expert id, offset 범위를 확인해서 잘못된 바이트로 답하지 않게 함

• expert 가중치는 residual vector quantization으로 3.00비트/weight까지 압축함

  • 8차원 벡터마다 256-entry codebook 3단계를 쓰는 방식임
  • 행렬을 완전히 materialize하지 않고, 토큰마다 codebook entry별 partial dot product table을 만들어 계산함
  • trunk는 4비트와 8비트로 남김. 3비트 trunk도 실험했지만 출력이 무너졌다고 함

• checksum은 현실적인 타협을 택함

  • expert payload에는 crc32가 있지만 기본값으로는 검사하지 않음
  • --verify를 켜면 Kimi-Linear에서는 약 5%, K3에서는 약 1% throughput 비용이 든다고 함
  • 복사·다운로드한 컨테이너라면 한 번은 켜서 확인하고, 직접 변환해서 계속 읽는 컨테이너라면 매 토큰마다 켜둘 필요는 없다는 입장임

Kimi-Linear 48B와 서버 모드

• 같은 엔진은 더 작은 Kimi-Linear 48B도 돌림

  • 컨테이너는 19GB, 최소 램은 1.87GB
  • 8GB 예산에서 10.7 tok/s, cache hit rate는 78%라고 함
  • 글쓴이는 WASTE를 처음 시험하려면 K3 말고 이쪽이 좋은 경로라고 설명함

• 라이브러리로도 넣을 수 있게 설계됨

  • public API는 src/waste.h의 26개 함수로, 모델 열기·생성·세션 저장·닫기 같은 기능을 제공함
  • CLI도 이 public API의 클라이언트라서, CLI가 하는 일은 임베딩 호스트도 할 수 있다는 구조임
  • OpenAI 호환 HTTP 서버도 있고 /v1/chat/completions, /v1/completions, /v1/models, /health를 지원함

• K3의 멀티모달도 지원함

  • vision tower는 401M ViT, 27 layers, patch 14 구조라고 함
  • 1024-patch 이미지를 인코딩하는 데 15.7초가 걸리고, 이후 생성에서는 이미지 embedding이 일반 토큰처럼 92개 MoE layer를 통과함
  • 896x896 이미지는 기본 설정에서 256 positions를 차지하므로, 이미지는 “한 토큰짜리 첨부”가 아니라 같은 길이의 텍스트처럼 비용이 듦

이 프로젝트가 재미있는 이유

• WASTE는 “클라우드 모델을 로컬에서 더 빠르게”가 아니라 “클라우드로 못 보내는 데이터를 로컬에서 처리할 수 있나”를 겨냥함

  • 네트워크 없음, per-token 과금 없음, 데이터가 머신 밖으로 나가지 않음
  • 민감한 데이터라 API로 못 보내는 상황에서는 느려도 로컬 실행 가능성이 중요해짐
  • 반 토큰/초는 답답하지만, feasibility가 아니라 engineering problem으로 바뀐 게 핵심임

• 문서가 실패한 최적화까지 남겨둔 점도 좋음

  • 3비트 trunk, GPU offload, per-expert bit allocation, index-layout blocking 같은 시도가 숫자로 반박됐다고 함
  • Metal backend도 정확하긴 하지만 22% 느려서 기본 비활성화 상태임
  • CPU path가 이미 메모리 대역폭 근처에서 돌고 있고, 수백 개의 작은 의존 matvec은 accelerator에 최악의 모양이라는 결론임

기술 맥락

• WASTE의 핵심 선택은 모델 전체를 램에 올리지 않고 expert를 디스크에서 스트리밍하는 거예요. Kimi K3가 2.78조 파라미터라서 일반적인 로컬 추론처럼 “가중치를 메모리에 올리고 시작”이 애초에 불가능하거든요.

• 이 방식이 가능한 이유는 Kimi K3가 MoE 구조이기 때문이에요. 매 토큰마다 전체 모델을 쓰는 게 아니라 일부 expert만 활성화되니까, 안 쓰는 expert는 램에 없어도 되고 필요한 순간 NVMe에서 읽어오면 돼요.

• 성능 병목은 연산보다 I/O에 가까워요. 토큰 하나에 expert 데이터 17GB를 읽어야 하니, 외장 SSD 0.94GB/s와 내부 NVMe 12.78GB/s의 차이가 그대로 체감 속도로 이어져요. 그래서 이 프로젝트에서는 저장장치가 사실상 가속기 역할을 해요.

• Router lookahead는 꽤 실용적인 트릭이에요. 다음 layer의 expert를 미리 정확히 확정하는 건 불가능하지만, 한 단계 이른 hidden state로 추측해서 읽기를 시작하면 디스크 대기 시간을 숨길 수 있어요. 실제 router 결정은 그대로 쓰기 때문에 결과값은 안 바뀌고, 바뀌는 건 바이트가 움직이는 타이밍이에요.

• 메모리 예산을 무작정 키우지 않는 것도 중요한 설계예요. OS가 페이지를 회수하기 시작하면 엔진 입장에서는 cache hit인데 실제로는 page fault가 나서 더 느려져요. 그래서 WASTE는 64GB 머신에서 46GB 근처처럼 “OS가 감당 가능한 선”을 찾는 쪽을 택해요.