# 29GB RAM에서 Kimi K3를 0.50 tok/s로 실행하기 > Clean Markdown view of GeekNews topic #32035. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=32035](https://news.hada.io/topic?id=32035) - GeekNews Markdown: [https://news.hada.io/topic/32035.md](https://news.hada.io/topic/32035.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-08-01T23:32:11+09:00 - Updated: 2026-08-01T23:32:11+09:00 - Original source: [github.com/sqliteai](https://github.com/sqliteai/waste) - Points: 1 - Comments: 1 ## Topic Body - **WASTE**는 2.78조 파라미터의 완전한 Kimi K3 오픈 가중치 모델을 축소 없이 982GiB 컨테이너로 변환해 소비자용 노트북에서 실행하는 C 기반 추론 엔진임 - 모델의 상주 트렁크만 메모리에 두고 토큰마다 활성화되는 약 **4%의 전문가 가중치**를 NVMe에서 읽으며, 남은 RAM은 크기가 제한된 전문가 캐시로 사용함 - Kimi K3는 4K 컨텍스트에서 최소 29.05GB RAM으로 열리지만 실용적인 구성은 64GB MacBook Pro의 46GB 예산이며, 여기서 **0.45~0.62 tok/s**를 기록함 - 전문가 읽기와 연산을 겹쳐 약 1.6배 개선하고 다음 계층 라우터를 한 residual 앞서 실행해 캐시 적중률을 14%에서 **38%** 로 높이면서도 총 읽기량과 로짓은 바꾸지 않음 - 인터넷 연결·토큰별 비용·외부 데이터 전송 없이 초대형 모델을 로컬에서 실행할 수 있지만, 내부 NVMe와 약 1TB 저장공간이 필요하고 RAM 예산이 52GB 이상이면 운영체제 페이징으로 오히려 급격히 느려질 수 있음 --- ### WASTE의 목표와 구현 형태 - **WASTE(Weight-Aware Streaming Tensor Engine)** 는 런타임 외부 의존성이 없는 임베드 가능한 C 추론 엔진임 - `libwaste.a`와 `waste` 실행 파일만 사용하며 libc와 pthreads 외에 BLAS, CUDA, ONNX, Python이 필요하지 않음 - Python은 모델 변환과 PyTorch 기준 검증에만 사용되고 추론 경로에는 들어가지 않음 - 공개 API는 26개 함수로 구성되며 모델 열기, RAM 상한 설정, 생성, 세션 저장, 종료를 지원함 - 현재 검증 대상은 **Kimi K3 2.78T** 전체 모델임 - 공개 원본은 1.42TB이며 변환 후 컨테이너는 982GiB임 - 증류·가지치기·축소 버전이 아님 - Kimi-Linear 48B도 같은 엔진과 포맷으로 19GiB 컨테이너, 최소 1.87GB RAM, 10.7 tok/s를 기록함 - 프로젝트 이름은 데스크 위 하드웨어에서 실행할 수 있는 모델을 클라우드 데이터센터에서 돌리며 토큰 비용과 전력을 함께 소비하는 상황을 줄이려는 목표에서 나옴 ### 디스크 스트리밍 구조 - Mixture of Experts 구조인 K3는 토큰당 모델의 약 **4%만 활성화**하므로, 비활성 가중치를 RAM에 상주시킬 필요 없이 필요한 시간에 접근 가능하게 배치함 - `.waste` 컨테이너는 JSON 매니페스트, 상주 트렁크, 계층별 전문가 뱅크로 구성됨 - 각 전문가 레코드는 4KiB 정렬됨 - gate·up·down 행렬을 인접 배치해 전문가 하나를 정확히 한 번의 `pread`로 읽음 - 페이지 캐시는 macOS의 `F_NOCACHE`, Linux의 `O_DIRECT`, Windows의 `FILE_FLAG_NO_BUFFERING`으로 우회함 - 페이지 캐시를 우회하지 않으면 RAM보다 작은 테스트 컨테이너가 운영체제 캐시에 들어가 982GiB 모델에서는 재현되지 않는 적중률을 만들 수 있음 - 레코드를 읽을 때 magic, 전문가 ID, 오프셋 범위를 항상 확인해 잘리거나 잘못 결합된 뱅크가 틀린 가중치로 답하지 않게 함 - payload의 `crc32` 검사는 `--verify`로 활성화함 - 검증 비용은 Kimi-Linear에서 약 5%, K3에서 약 1%이며 기본값은 꺼짐 - 복사·다운로드했거나 신뢰할 수 없는 디스크에 둔 컨테이너는 한 번 검증하는 것을 권장함 - 트렁크와 코드북에는 체크섬이 없음 ### 읽기 선행과 라우터 예측 - 한 계층의 라우터가 16개 전문가 ID를 결정하면 각 읽기를 별도 스레드로 요청하고, 연산은 도착한 데이터부터 소비함 - 읽기와 연산의 중첩은 K3에서 약 **1.6배** 개선됨 - 수행 작업과 캐시 통계는 기능 활성화 전후에 같음 - 다음 계층의 실제 hidden state가 만들어지기 전에 상주 중인 다음 라우터를 현재 hidden state로 실행해 전문가 6개를 미리 가져옴 - 한 residual 앞선 예측은 rank 1에서 92%, 상위 6개에서 81% 정확함 - 실제 라우터가 최종 전문가를 결정하므로 출력은 정확히 유지됨 - demand hit rate는 14%에서 38%로 올라가며 **총 읽기 바이트는 변하지 않음** - `WASTE_LOOKAHEAD=0`으로 비활성화할 수 있음 - prefill에 같은 기법을 적용한 구현은 제거됨 - decode 계층은 캐시 슬롯 16개를 점유하지만 chunk 계층은 약 550개를 점유함 - 미리 읽은 레코드가 사용 전에 퇴출되어 읽기량이 6.9% 증가하고 시간은 줄지 않았음 ### 양자화와 정확성 - 전문가 가중치는 8차원 벡터에 대한 256개 항목 코드북 3단계의 **잔차 벡터 양자화**로 저장하며 가중치당 3.00비트를 사용함 - 전체 행렬을 복원하지 않고 부분 내적 표를 만든 뒤 각 행을 표 조회 3회와 덧셈 2회로 처리함 - 트렁크는 4비트와 8비트를 유지함 - 모델이 전문가에 대해서만 양자화 인지 학습됐기 때문에 3비트 트렁크에서는 출력이 붕괴함 - 캐시 예측은 맞았지만 처리량도 개선되지 않아 제거됨 - 모든 계층은 PyTorch 기준 구현과 비교됨 - 최종 로짓 차이는 `3.6e-06` - 비전 타워는 자체 기준과 `2.3e-06` - latent KV 캐시 변환은 `1.2e-05` 수준에서 동일한 로짓을 유지함 ### RAM 예산과 좁은 성능 구간 - K3는 92개 계층에서 각각 전문가 16개를 사용해 토큰당 **17.0GB의 작업 집합**을 만듦 - 캐시가 이 크기보다 작으면 한 토큰에서 저장한 전문가가 다음 토큰 전에 퇴출돼 적중률이 0%가 됨 - 64GB 시스템에서 측정한 결과 RAM을 더 할당한다고 항상 빨라지지는 않음 - 32GB 예산·3.32GB 캐시: 적중률 0%, 0.50 tok/s - 46GB 예산·17.32GB 캐시: 기존 적중률 17%, 0.53~0.55 tok/s - 52GB 예산·23.32GB 캐시: 0.04~0.15 tok/s로 재현되지 않음 - 58GB 예산·29.32GB 캐시: 0.02~0.03 tok/s - 라우터 lookahead는 46GB에서 적중률을 약 14%에서 38%로 높이지만, 52GB 이상에서의 붕괴는 캐시 미스가 아니라 **운영체제 페이징** 때문임 - 58GB에서는 적중률이 더 높아도 46GB보다 약 20배 느림 - 큰 예산으로 시스템을 페이징 상태에 빠뜨린 뒤에는 46GB 측정도 0.02 tok/s까지 떨어질 수 있음 - 기본 예산은 물리 RAM의 7/8 아래에서 토큰 작업 집합 단위로 낮춰 선택함 - 64GB MacBook Pro에서는 46.24GB를 사용하고 17.56GB를 전문가 캐시에 배정함 - 명시한 예산이 최소치보다 작으면 스와핑으로 진행하지 않고 시작을 거부함 - 128GB 시스템에서는 트렁크와 작업 집합 3배에 해당하는 전체 권장 예산을 사용할 수 있음 ### K3 성능과 하드웨어 요구사항 - 측정 시스템은 **64GB MacBook Pro M5 Pro**와 내부 SSD임 - 4K 컨텍스트 최소 RAM: 29.05GB - 32K: 30.54GB, 128K: 35.63GB, 1M: 83.21GB - 상주 트렁크: 27.28GB - 모델 로드: 20초 - decode: 기본 예산에서 0.45~0.62 tok/s - prefill: chunked 0.47 tok/s, 순차 0.29 tok/s - 최소 29.05GB로 모델을 열 수 있지만 32GB 시스템은 심하게 페이지될 수 있어 **64GB가 실제 권장 사양**임 - 토큰당 cold 상태에서 전문가 17.0GB를 읽으며 lookahead의 38% 적중률에서는 10.5GB를 읽음 - 내부 SSD는 12.78GB/s, 외장 USB 인클로저는 0.94GB/s로 측정됨 - 토큰 하나가 전문가 17GB를 읽으므로 외장 저장장치에서는 같은 처리가 약 13초 걸림 - 원본 다운로드는 외장 디스크에 둘 수 있지만 변환된 컨테이너는 내부 NVMe에 두어야 함 - 변환 컨테이너용 982GiB와 원본 shard staging용 1.42TB가 필요하며, staging 공간은 변환 후 해제할 수 있음 ### Attention과 멀티모달 처리 - K3 attention은 **Kimi Delta Attention**과 gated multi-head latent attention을 3:1로 조합함 - KDA는 증가하는 KV 캐시 대신 고정 크기 recurrent state를 유지함 - MLA는 head별 key/value를 확장하지 않고 폭 512의 latent를 캐시함 - `kv_b_proj`를 query와 output에 흡수해 4K 컨텍스트 캐시를 11.25GB에서 0.21GB로 줄임 - 기존 대비 **53배 감소**함 - 128K에서는 확장 레이아웃이 360GB, latent 레이아웃이 7.2GB를 요구함 - 멀티모달 경로는 401M 파라미터, 27계층, patch 14의 ViT를 지원함 - 1024 patch 이미지 인코딩은 15.7초임 - 896×896 이미지는 기본 설정에서 256개 시퀀스 위치를 차지함 - 이미지 임베딩도 92개 MoE 계층을 통과하므로 비용 대부분은 비전 타워보다 text prefill과 같음 - `vision.json`의 `max_patches`를 절반으로 줄이면 프롬프트 위치 수도 절반으로 줄어듦 - PNG, JPEG, GIF, BMP, TGA, PSD를 지원하며 `run`, `chat`, `eval`에서 이미지를 사용할 수 있음 - 대화 중 인코딩된 이미지 위치는 attention state에 남아 다음 턴에서 재인코딩하지 않음 - 비전 타워는 이미지가 있을 때만 로드되며 가중치 434MB와 전체 예약 메모리 1.12GB를 사용함 ### 변환, 실행과 서버 - 빌드는 C11 컴파일러와 `make`만 필요함 - `make check`는 실제 모델 없이 합성 컨테이너로 23개 검사를 통과하고 11개를 건너뜀 - 두 실제 컨테이너가 있으면 전체 검사는 36개임 - K3 변환은 공개된 [moonshotai/Kimi-K3](https://huggingface.co/moonshotai/Kimi-K3)의 safetensors shard 96개를 그대로 사용함 - 3개 프로세스 기준 M5 Pro에서 약 4.7시간이 걸림 - 순수 PyTorch encoder는 23.7시간이 걸림 - 계층 단위로 재개할 수 있어 중단 시 진행 중이던 계층만 다시 처리함 - downloader는 부분 파일 재개, 지수 백오프와 jitter, `Content-Length` 확인, 완료 shard 상태 기록을 지원함 - CLI는 `run`, `chat`, `eval`, `plan` 등을 제공하며 `--json`으로 `eval`, `tokenize`, `plan`, `info`, `bench` 결과를 기계 판독 가능하게 출력함 - `serve/`는 공개 C API를 ctypes로 호출하는 **OpenAI 호환 HTTP 서버**임 - `/v1/chat/completions`, `/v1/completions`, `/v1/models`, `/health`를 제공함 - 스트리밍, 도구 정의·결과, typed call arguments, JSON 응답 스키마, `tool_choice`, think channel, `thinking_effort`, 이미지를 처리함 - 프롬프트 renderer는 K3 릴리스의 `encoding_k3.py`를 이식했으며 가중치 디렉터리가 있으면 38개 대화를 segment 단위로 비교함 ### 플랫폼과 현재 제약 - macOS arm64, Linux arm64, Linux x86_64는 같은 모델 비의존 테스트에서 23 pass·11 skip을 기록하며 sanitizer와 fuzz 400건도 통과함 - Windows x86_64는 MinGW-w64로 교차 컴파일해 합성 컨테이너, CLI, forward pass를 검증했지만 실제 모델 컨테이너에서는 실행하지 않음 - MSVC와 Windows ARM64는 지원하지 않음 - Windows의 page-cache 우회는 CI 파일시스템에서만 확인됐고 RAM보다 큰 실제 컨테이너 부하에서는 검증되지 않음 - x86 SIMD는 CPUID에 따라 AVX-512 또는 AVX2를 선택하지만 AVX-512 경로는 실제 지원 CPU에서 아직 실행되지 않음 - Metal backend는 정확하지만 작은 종속 matvec가 수백 번 발생하는 작업 형태 때문에 CPU보다 **22% 느려 기본 비활성화**됨 - API는 아직 고정되지 않았으며 chat format 자동 변환은 현재 K3만 지원함 - Kimi-Linear는 템플릿을 추측하지 않고 raw 모드로 실행함 - 전문가별 비균일 비트 할당은 도입하지 않을 예정임 - 세 번째 비트의 가치는 계층 내 전문가 사이에서 최대 1.15배, 계층 사이에서 1.01배만 달라 최적 할당의 이득이 없었음 - routing frequency 기반 할당도 저장공간은 줄이지만 병목인 I/O는 거의 줄이지 못함 - 라이선스는 **Apache 2.0**임 ## Comments ### Comment 62714 - Author: neo - Created: 2026-08-01T23:32:13+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49123386) * 정말 멋짐. 지금 당장 클라우드 사업자보다 실용적이려는 프로젝트가 아니라, **가능성의 경계**를 보여주는 프로젝트임 모델 효율 개선과 로컬 장비 성능 향상이 맞물리면 언젠가 고품질 로컬 모델도 경제적으로 운용 가능해질 수 있음 * **초당 0.5토큰**은 긴 작업에도 쓸모없다고 봄. 차라리 돈을 들여 16GB 4060 Ti 2장에 텐서 병렬화를 적용하겠음 20년 뒤라면 태양광으로 작동하며 잔디를 깎거나 보도를 닦는 사이버펑크풍 저속 로봇, 혹은 정원에서 분재의 성장 속도만 간신히 따라가며 가지를 치는 로봇에 어울릴 듯함 * 지금은 거의 쓸 수 없지만, 이런 프로젝트가 계속 개선돼야 결국 **실용적인 버전**에 도달하므로 반가움 * 토큰 비용을 지불하고 추론 사업자가 전기료를 내는 게 낭비라는데, 오이를 사면 농부가 물과 비료 비용을 내는 것과 무엇이 다른지 모르겠음. LLM이 나중에 끼워 맞춘 논리이길 바람 아이디어 자체는 흥미로우며 더 작은 모델로 시험해 보고 싶음. 초당 0.5토큰을 생성하면서 SSD에서 매초 수 GB를 읽는다면, 일반 소비자 노트북에는 여전히 너무 크지만 **250~500GiB 모델**을 대상으로 할 때 오히려 실용적일 수도 있음 * 직접 토마토를 기르면 공짜 토마토를 얻을 수 있음. BLT를 만들기엔 부족해도 슈퍼마켓산이 아니니 세상을 조금 구한 셈임 /s * 42W를 지속적으로 쓰고 전기료가 kWh당 20센트라고 가정하면 **토큰 100만 개당 약 5달러**이며, 하드웨어를 비롯한 다른 비용은 제외한 값임 * 한 달은 약 260만 초이고 초당 0.5토큰이면 월 130만 토큰을 생성함. 부대 비용까지 감안하면 **월간 장비 운영비가 토큰 100만 개당 비용**이라고 잡아도 대략 맞음 * **태양광 발전**이 있다면 계산이 어떻게 달라지는지 궁금함 * 표준 llama.cpp도 GGUF를 `mmap`할 수 있어 메모리에 들어가지 않는 부분은 디스크에 남고, 커널 페이지 캐시가 자주 쓰는 부분인 **상주 트렁크**를 유지해 줌. 굳이 자체 구현할 이점이 무엇인지 궁금함 * 며칠 전 비슷한 프로젝트에서도 같은 질문이 나왔는데, 먼저 `mmap`을 시도한 뒤 직접 구현해 **10배 빨라졌다**고 했음 데이터베이스 엔진이 자체 캐시를 구현하는 이유와 같음. 커널 페이징은 범용·요청 기반이지만 실제 접근 패턴을 알면 필요한 데이터를 미리 읽고 파이프라인화할 수 있음 * 이 정도 규모에서 SSD를 스왑 공간으로 쓰면 불과 몇 달 만에 **누적 쓰기 내구성**을 소진하기 쉬움. 단기 시험 이상으로 돌렸을 때 SMART의 누적 쓰기량과 마모 통계를 보고 싶음 전부 RAM에 들어가는 모델이라면 llama-server는 `--no-mmap`으로 실행하는 편이 나았음. 물론 전체 Kimi K3와 100만 토큰 문맥을 올리려면 2TB 서버가 필요함 * README가 LLM 작성물이라는 느낌을 강하게 주는데, 코드베이스도 LLM이 작성했는지 궁금함 * 피상적으로 깎아내리고 싶지는 않지만, 문서가 모델을 정말 **원래 정밀도**로 실행하는지 스스로 모순됨. 주장하는 3비트 양자화는 흥미로울 수 있으나, K3는 원래 정밀도의 밀집 매개변수만 약 115GB이고 토큰당 활성 희소 전문가가 약 25GB이며 KV 캐시도 추가되므로 **RAM 29GB에서 토큰당 2초**라는 주장은 이해하기 어려움 * 소프트웨어를 많이 직접 작성했고 프로그래밍 언어도 만들었음: [https://github.com/marcobambini/gravity]() 이제는 LLM과 에이전트를 조율하는 데 내 기술을 활용해 더 나은 코드를 훨씬 빠르게 작성함. 개발자는 새 기술에 적응하거나 도태되는 길 중 하나를 택해야 함 * 작성자들이 최소한 LLM이 생성한 README를 **직접 읽어보기**라도 했으면 함. LLM은 독자 관점에 대한 이해가 부족해 외부 독자도 프로젝트의 전체 맥락과 의사결정 과정을 안다고 가정함 사용자에게는 중요하지만 완성품을 보는 독자에게는 무관한 내부 결정과 Claude 특유의 난해한 용어가 그대로 들어감. LLM을 자주 사용하고 복잡한 코드 작성에 매우 유용하다는 점은 인정하지만, 글의 초안 품질은 형편없음 * 기여자 목록에 `claude`가 있으니 추측할 필요도 없음. Claude에게 커밋까지 맡길 정도라면 코드를 **직접 검토했을 가능성**도 낮아 보임 * README에서 Claude 특유의 문체가 가장 짙게 느껴짐. 사람별 글쓰기 방식을 인식하듯, 이제는 Claude가 기본으로 생성하는 **짧고 단속적이며 운율만 과한 문체**도 별도 유형으로 머릿속에 자리 잡는 느낌 * 작업에 맞는 모델을 정확히 고를 수 있을 만큼 기술이 발전하면 가치가 커질 수 있음. 자동 탐색 과정에서 하루 30분 정도만 큰 모델을 가동하고 나머지 시간에는 **소형 모델**을 사용하는 미래를 상상할 수 있음 * 그런 미래는 오지 않을 듯함. 백로그 항목조차 끝낸 뒤에야 소요 시간을 알 수 있는데, 실제로 수행하지 않고는 **작업 복잡도**를 미리 알 방법이 없음