- 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%이며 기본값은 꺼짐
- 복사·다운로드했거나 신뢰할 수 없는 디스크에 둔 컨테이너는 한 번 검증하는 것을 권장함
- 트렁크와 코드북에는 체크섬이 없음
- payload의
읽기 선행과 라우터 예측
- 한 계층의 라우터가 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의 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임