--- title: "2.78조 파라미터 Kimi K3를 맥북에서 돌린 C 추론 엔진 WASTE" published: 2026-07-31T14:12:38.000Z canonical: https://jeff.news/article/5317 --- # 2.78조 파라미터 Kimi K3를 맥북에서 돌린 C 추론 엔진 WASTE WASTE는 2.78조 파라미터짜리 Kimi K3를 64GB 맥북 프로에서 돌리기 위해 만든 C 기반 임베디드 추론 엔진임. 모델 전체를 램에 올리지 않고, 반복되는 trunk만 메모리에 두고 전문가(expert) 가중치는 NVMe에서 스트리밍해서 0.45-0.62 토큰/초를 냈다고 함. ## 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를 현실적인 요구사항으로 봐야 한다고 함 > [!IMPORTANT] > 핵심 숫자는 2.78조 파라미터, 982GiB 컨테이너, 최소 29.05GiB 램, 64GB 맥북 프로에서 0.45-0.62 토큰/초임. “빠른 로컬 LLM”이 아니라 “이 크기의 모델도 로컬 실행 가능권에 들어왔다”는 증명에 가까움. ## 왜 전체 모델을 램에 안 올려도 되나 - 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%로 올라갔고, 총 읽는 바이트 수는 늘지 않음 ```mermaid 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가 되어버리기 때문임 > [!WARNING] > 64GB 머신에서 예산을 크게 잡는다고 더 빨라지는 구조가 아님. 46GB 근처가 실사용 가능한 창이고, 52GB 이상은 OS 페이징 때문에 hit rate가 올라가도 속도는 박살남. ## 정확성 검증과 양자화 - 글쓴이는 “느리지만 맞는다”를 꽤 집요하게 증명하려고 함 - 모든 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가 감당 가능한 선”을 찾는 쪽을 택해요. ## 핵심 포인트 - Kimi K3 2.78조 파라미터 모델을 982GiB 컨테이너로 변환해 소비자용 노트북에서 실행함 - 최소 실행 램은 29.05GiB지만 실사용 기준은 64GB 머신의 46GB 예산이라고 설명함 - 토큰당 expert 가중치 17GB를 읽고, internal NVMe 12.78GB/s 대역폭에 거의 기대서 동작함 - router lookahead로 캐시 히트율을 14%에서 38%로 끌어올렸고, 전체 바이트 수는 늘리지 않았음 - 런타임은 libc와 pthreads 외 의존성이 없고, OpenAI 호환 HTTP 서버도 포함됨 ## 인사이트 이 프로젝트의 재미는 ‘빠르다’가 아니라 ‘불가능해 보이던 실행 경로를 엔지니어링 문제로 바꿨다’는 데 있음. 반 토큰/초는 느리지만, 2.78조 파라미터 모델을 네트워크 없이 책상 위 하드웨어에서 돌린다는 건 온디바이스 AI의 경계선을 꽤 세게 밀어낸 사례임.