Kimi K3 2.78조 모델을 64GB 맥북에서 돌린 WASTE

Kimi K3 2.78조 모델을 64GB 맥북에서 돌린 WASTE

Kimi K3 로컬 추론 썸네일

2.78조 파라미터 규모의 Kimi K3를 64GB MacBook Pro에서 실행한 오픈소스 프로젝트가 나왔어요. WASTE는 모델 전체를 메모리에 올리는 대신, 토큰 생성에 필요한 전문가 가중치만 NVMe에서 읽어요. 속도는 빠르지 않지만 초대형 MoE 모델을 개인용 하드웨어에서 구동하는 방법을 구체적인 수치로 보여줘요. 1

핵심 요약

구분	내용	실제 의미
모델	Kimi K3 2.78조 파라미터 전체 모델	증류하거나 가지치기한 축소판이 아니에요
저장공간	변환된 컨테이너 982GiB	내부 NVMe에 약 1TB 여유 공간이 필요해요
메모리	4K 컨텍스트 최소 29.05GiB, 권장 구성 64GB	최소치로 열 수는 있어도 운영체제 페이징 때문에 실사용 속도가 크게 떨어질 수 있어요
측정 속도	64GB MacBook Pro에서 0.45~0.62 tok/s	대화형 서비스보다 실험, 검증, 장시간 배치 작업에 가까워요
실행 방식	상주 트렁크와 디스크 기반 전문가 스트리밍	토큰마다 활성화되는 약 4%의 전문가 가중치만 불러와요

1. 1TB 모델 파일을 전부 RAM에 올리지 않는 방법

WASTE는 Weight-Aware Streaming Tensor Engine의 약자예요. C로 작성된 추론 엔진이며, 실행 경로에서 Python이나 CUDA, ONNX, BLAS를 요구하지 않아요. 현재 공개된 대표 사례는 1.42TB 원본 Kimi K3를 982GiB 컨테이너로 바꾼 뒤 64GB MacBook Pro에서 실행한 결과예요. 프로젝트가 공개한 측정값은 초당 0.45~0.62 토큰이에요. 2

이 구성이 가능한 이유는 Kimi K3가 Mixture of Experts 구조를 쓰기 때문이에요. 모델 전체 파라미터는 2.78조 개지만 토큰 하나를 처리할 때 활성화되는 전문가는 약 4%예요. WASTE는 공통으로 쓰는 모델 트렁크만 RAM에 두고, 각 계층에서 선택된 전문가 가중치를 내부 NVMe에서 직접 읽어요. 남은 메모리는 자주 다시 쓰는 전문가를 담는 제한형 캐시로 사용해요.

728x90

디스크 읽기가 계산을 계속 막으면 이 구조는 실용성이 없어요. WASTE는 전문가 데이터를 읽는 작업과 이미 도착한 데이터의 연산을 겹쳐 처리해요. 프로젝트 설명에 따르면 이 방식으로 처리 속도가 약 1.6배 올랐어요. 다음 계층의 라우터를 한 단계 먼저 실행하는 선행 읽기도 더했어요. 그 결과 전문가 캐시 적중률이 14%에서 38%로 높아졌고, 실제 라우터가 최종 선택을 맡아 출력 계산은 바뀌지 않아요. 2

가중치 저장 방식도 메모리와 디스크 요구량을 줄여요. 전문가 가중치는 8차원 벡터용 3단계 잔차 벡터 양자화를 사용해 가중치당 3비트로 저장해요. 다만 공통 트렁크까지 무리하게 3비트로 줄이지는 않았어요. 프로젝트의 검증에서는 트렁크 정밀도를 지나치게 낮추면 출력이 무너졌기 때문이에요. 모든 계층 출력과 최종 로짓은 PyTorch 기준 구현과 비교해 확인했다고 밝혔어요.

29.05GiB는 4K 컨텍스트에서 모델을 열기 위한 최소 RAM이에요. 쾌적한 권장 사양을 뜻하지는 않아요. 공개 측정은 64GB MacBook Pro에서 46.24GB를 엔진에 배정하고, 그중 17.56GB를 전문가 캐시로 쓴 구성이에요. 52GB나 58GB처럼 예산을 더 크게 잡았을 때는 macOS 페이징이 발생해 오히려 속도가 크게 떨어졌어요. RAM을 많이 배정하는 것보다 운영체제가 안정적으로 유지할 여유를 남기는 편이 더 빨랐어요. 1

저장장치 조건은 더 까다로워요. 변환된 모델 컨테이너만 982GiB예요. 직접 변환하려면 공개 원본 샤드를 위한 1.42TB 임시 공간도 따로 필요해요. 토큰마다 콜드 상태에서 약 17GB의 전문가 데이터를 읽고, 캐시 적중률 38%일 때도 약 10.5GB를 읽어요. 프로젝트 측정에서 내부 SSD는 12.78GB/s였지만 외장 USB 인클로저는 0.94GB/s였어요. 외장 저장장치에 컨테이너를 두면 병목이 훨씬 커져요. 2

누구에게 현실적인가요

일반적인 챗봇 응답 속도를 기대한다면 0.5 tok/s는 답답해요. 100토큰을 만드는 데 단순 계산으로 3분 넘게 걸릴 수 있어요. 대신 모델 가중치를 외부 서버로 보내지 않고 전체 모델의 동작을 확인해야 하는 연구자에게는 선택지가 생겨요. API 호출 비용 없이 긴 시간 돌리는 평가 작업이나 로컬 재현 실험에도 맞을 수 있어요.

설치 전에 하드웨어 조건부터 봐야 해요. 64GB 통합 메모리, 빠른 내부 NVMe, 모델용 약 1TB 공간이 사실상 출발점이에요. 모델 변환까지 직접 할 계획이라면 임시 저장공간을 더 확보해야 해요. 최소 RAM 숫자만 보고 32GB 노트북에서 같은 결과를 기대하기는 어려워요.

왜 중요한가요

초대형 오픈 가중치 모델의 로컬 실행은 보통 모델 전체가 RAM이나 VRAM에 들어가는지를 먼저 따져요. WASTE는 MoE 모델에서 실제로 활성화되는 가중치가 일부라는 점을 이용해 메모리 문제를 저장장치 대역폭과 캐시 문제로 바꿨어요. 2.78조 파라미터 모델이 개인용 노트북에서 빠르게 동작한다는 뜻은 아니지만, 실행 자체가 불가능했던 구성을 느리더라도 재현 가능한 구성으로 만들었어요. 2

개발자가 확인할 지점도 분명해요. 모델 크기만 줄이는 양자화와 달리, 어떤 가중치를 언제 읽을지 결정하는 런타임 설계가 성능을 좌우해요. 읽기와 연산의 중첩, 다음 라우터 예측, 제한형 캐시, 운영체제 페이징 회피가 한 묶음으로 작동해요. 앞으로 더 빠른 NVMe와 전문가 선택의 지역성을 잘 활용하는 모델이 나오면 같은 접근의 속도도 달라질 수 있어요. 현재 공개 수치는 특정 64GB MacBook Pro와 내부 SSD에서 나온 결과라 다른 기기에서는 직접 측정해야 해요.

WASTE는 Apache 2.0 라이선스로 공개돼 있어 구현과 측정 방법을 직접 확인할 수 있어요. 코드와 문서에는 Kimi K3뿐 아니라 48B 모델에서의 메모리와 속도 결과도 함께 담겨 있어요. 거대한 MoE 모델을 로컬에서 다뤄야 한다면, 단순한 데모보다 저장 형식과 캐시 정책을 살펴볼 만한 사례예요. 2

참고 자료

1. 29GB RAM에서 Kimi K3를 0.50 tok/s로 실행하기 — GeekNews
2. WASTE — Weight-Aware Streaming Tensor Engine — GitHub, sqliteai