kimi-k3-in-c

kimi-k3-in-c
2.78조 파라미터 모델. CPU 하나. 8 GB RAM.
포터블 C99로 구현한 Kimi K3 추론.
BLAS 없음. 프레임워크 없음. GPU 없음.

2.78T
파라미터
1.56 TB
디스크 상의 체크포인트
8.24 GB
측정된 최대 RSS
176 KB
엔진 전체
0
GPU

동일한 2.78조 파라미터 모델, 동일한 답변, 당신이 가진 어떤 기계에서든.
메모리를 더 쓰면 오직 속도만 좋아진다:

당신이 가진 기계
RAM
토큰당 시간
무슨 일이 일어나는가

일반 노트북
8 GB
26.5 s
매 스텝마다 모델 전체가 디스크에서 스트리밍된다

고급 노트북
32 GB
24.2 s
모델의 일부가 이제 메모리에 상주한다

데스크톱
64 GB
19.8 s
더 많은 부분이 메모리에 상주한다

고성능 워크스테이션
128 GB+
5.6 s
모델 전체가 메모리에 들어가고, 디스크 대기가 사라진다

모든 크기에서 동일한 짧은 프롬프트를 사용하며, 출력은 가장 작은 기계에서 가장 큰 기계까지 바이트 단위로 동일하다; 오직 시계만 달라진다. 한 기계, 124 코어, 빠른 NVMe 드라이브: 처음 세 행은 여전히 매 스텝마다 모델을 디스크에서 읽으므로 느린 드라이브에서는 더 느리고, 128 GB+ 행은 모든 것을 메모리에 유지하여 더 이상 디스크를 기다리지 않는다. 같은 기계에서 v1.0.0은 토큰당 연산을 약 8배 가볍게 만들었고, 채팅에서의 후속 질문은 3.9배 빨라졌으며, 긴 프롬프트는 비용이 약 절반으로 줄었다. (토큰은 대략 짧은 단어 조각이다; 아래의 두 실행 가능한 데모는 더 느린 드라이브에서의 원본 캡처이므로 시계가 조금 더 높게 읽힌다.) 전체 데이터는 docs/data/ 에 있다.

나는 AI 연구 직무와 박사 과정 자리에 열려 있다. CV .

macOS, Windows 및 NEON 포팅, 채팅 모드, 울트라 프리셋, 더 빠른 MXFP4 커널, 그리고 긴 파서 수정 목록은 아래 사람들에게서 나왔다. 누가 무엇을 했는가 .

$ ./bin/k3 ~ /k3model --trunk ~ /k3trunk --preset laptop \
--tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental

--- generated text ---
Paris.",
+ "The Eiffel
----------------------
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB
느리지만 정확하게 답하며, 1.56 TB 체크포인트에서 8.24 GB로. 이 특정 배치 명령은 의도적으로 원시 이어쓰기를 요청한다. 공식 Kimi K3 체크포인트는 채팅도 가능하다; 답변과 다중 턴 히스토리를 원할 때는 아래의 XTML REPL을 사용하라.
같은 배치 요청에 더 많은 메모리를 주어도 답은 변하지 않고, 오직 시계만 변한다:

$ ./bin/k3 ~ /k3model --trunk ~ /k3trunk --preset server \
--tok ~/k3model --prompt "def fibonacci(n):" --gen 28 --incremental

--- generated text ---
if n <= 1:
return n
else:
return fibonacci(n-1) + fibonacci
----------------------
28 tokens in 299.3 s, 10.69 s/token average
PEAK RSS for the whole run: 127.92 GB
이 문서의 모든 수치는 docs/data/ 의 측정 출력에서 나온다.

덴스 트렁크는 당신이 선택한 깊이까지 메모리에 상주하고 나머지는 스트리밍한다; 1.45 TB의 라우팅된 전문가들은 절대 상주하지 않으며, 패킹된 4비트 형태에서 곧바로 곱해진다. 그 결과 동일한 모델이 8 GB와 224 GB에서 실행되며 그 사이 모든 예산에서 바이트 단위로 동일한 출력을 생성한다.

바이트가 어디에 사는지에 대한 네 가지 결정이 그것을 클러스터에서 노트북으로 가져오며, 맨 아래의 답은 맨 위의 답과 같다:

Part II는 두 다이어그램의 모든 박스를 처음부터, 한 컴포넌트씩 만든다.

목차
Part I: 시작하기

요구 사항
빠른 시작 : 모델 없이 약 1분 만에 클론, 빌드, 검증
전체 설정 : 생성된 텍스트까지의 전체 경로
사용법

개요
프롬프트 옵션
메모리 옵션
생성 옵션
진단 옵션
종료 코드
환경 변수
예제 모음

프리셋 선택
실행 보고서 읽기
자주 묻는 질문

Part II: 작동 방식

문제: 들어가지 않는 모델
네 가지 축소
기계, 그리고 그것이 가정하는 것
코드베이스
세 가지 불변식
1. 헤더에서 1.56 TB 체크포인트 읽기
2. 추측을 거부하는 설정 리더
3. 토크나이저, 바이트 단위로
4. 축소 하나: 전문가들은 이미 반 바이트로 배송된다
5. 부동 소수점 계약을 가진 커널
6. 축소 둘: KDA, 절대 늘지 않는 메모리를 가진 어텐션
7. 축소 셋: MLA, 96개 헤드 대신 하나의 잠재
8. 어텐션 잔차: 뒤를 돌아보는 레이어
9. 896개 중 16개 전문가 선택
10. 트렁크 패킹: 93개 레이어, 각각 한 번의 읽기
11. 축소 넷: 트렁크 스트리밍이 바닥을 다이얼로 바꾼다
12. 전문가용 LRU 캐시
13. 그 캐시는 얼마나 커야 하는가? 트레이스에 물어보라

Part III: 검증

게이트 사다리
먼저 작은 오라클
전체 체크포인트에서 증명하기
첫 토큰들
지속 생성: 텍스트 입력, 텍스트 출력

Part IV: 측정

메모리 사다리: 8 GB에서 224 GB까지
참여하지 않던 캐시
할당이 용량을 이긴다
측정의 측정
스토리지가 전부다
트렁크가 양자화되지 않는 이유

Part V: 참조

범위
원장 마감
문서
개발
스타 히스토리
라이선스

Part I: 시작하기
요구 사항
관문은 스토리지다: 체크포인트는 1.56 TB다. 나머지는 평범하다.

OS
Linux, x86-64 (레퍼런스); macOS/arm64와 Windows/x86-64도 빌드되고 모든 게이트를 통과한다
O_DIRECT , posix_memalign , getrusage 사용 -- Windows용으로는 MSYS2의 MinGW-w64를 통해 포팅됨 ( src/io/k3_portable_io.h 참조)

CPU
x86-64에서 AVX2 + FMA, arm64에서 NEON
AVX-512 불필요. make portable 은 x86-64에서 일반 AVX2를 타깃으로 한다

RAM
8 GB 이상
모든 프리셋이 작동한다; 메모리가 많을수록 빠를 뿐, 결코 다르지 않다

스토리지
~1.7 TB 여유
1.56 TB 체크포인트 + 109 GB 패킹된 트렁크, 이상적으로는 빠른 로컬 디스크에

툴체인
GCC ≥ 9 또는 Clang ≥ 10
GNU make, 또는 CMake

Python
3.9+
다운로드, 패킹, 분석 도구용; make test 용은 아님

토크나이저와 설정 리더는 포터블 C99이며 어디서든 빌드된다. 체크포인트 없이도 빠른 시작 의 모든 것을 할 수 있다.

빠른 시작
클론, 빌드, 전체 테스트 스위트 실행. 체크포인트 없음, 네트워크 없음, Python 없음 . 전체에 약 1분이 걸린다.

git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

make -j # 초 단위. 일곱 개의 C 파일, 컴파일러, OpenMP
make test # 1분 이내
이렇게 끝나거나, 실패한다:

GATE 1 teacher forcing : 32/32 positions match tf_pred
generated span : 20/20 <- must be exact
GATE 2 greedy decode : 20/20 generated tokens match full_ids
GATE 3 incremental : 20/20 generated tokens match full_ids <- KV cache + carried KDA state

VERDICT: ENGINE MATCHES THE REFERENCE EXACTLY

ALL WEIGHTLESS TESTS PASSED

그것이 엔진 전체다: 모든 커널, 스트리밍 캐시, safetensors 리더, 설정 리더, 토크나이저, 그리고 릴리스된 것과 동일한 텐서 그래프로 만든 13-레이어 모델에 대한 엔드투엔드 오라클로, 저장소에 커밋된 픽스처의 PyTorch 레퍼런스와 대조 검증된다.

공개된 측정 하나도 즉석에서 재현된다, 전체 93-레이어 실행 중 기록된 트레이스로부터 (이것은 Python 3.9+와 numpy가 필요하다):

python3 tools/sim_cache.py tests/fixtures/expert_trace.bin
100,096 expert requests, reprinting the capacity table in
expert-cache-capacity.txt .

전체 설정
빈 디렉터리에서 생성된 텍스트까지 여섯 단계. 4단계만 느리다.

./scripts/k3-doctor.sh 는 어느 시점에든 실행할 수 있다. 툴체인을 확인하고, RAM을 프리셋에 맞추고, 스토리지를 측정하고, 다음에 실행할 정확한 명령을 출력한다.

Step 0. clone
git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c
약 45 MB, 대부분이 다이어그램과 테스트 픽스처다.

Step 1. check the machine
./scripts/k3-doctor.sh
약 1분 걸리는데, 엔진이 읽는 방식으로 디스크를 측정하기 때문이다. 기계가 모델을 전혀 실행할 수 없으면 0이 아닌 값으로 종료한다.

Step 2. build
make -j
초 단위. 유일한 의존성은 C99 컴파일러, libm, OpenMP다. CMake도 작동한다:

cmake -B build && cmake --build build -j && ctest --test-dir build
Step 3. verify before downloading anything
make test
1.56 TB 다운로드에 착수하기 전에 할 가치가 있다: 동일한 텐서 그래프를 가진 모델에서 엔진이 레퍼런스와 일치함을 증명하며, 저장소 외에는 아무것도 필요로 하지 않는다.

Step 4. fetch the checkpoint
1.56 TB, 분이 아니라 시간 단위. huggingface.co/settings/tokens 에서 토큰을 받아라:

export HF_TOKEN=hf_your_token_here # read from the environment, never echoed
./scripts/download-model.sh ~ /k3model # resumable, re-run to continue
스크립트는 샤드 수, 정확한 바이트 총량, 그리고 공개된 수치에 대한 각 샤드별 크기를 검증하며 끝난다:

verifying…
shards : 96 (expect 96)
bytes : 1560936091448 (expect 1560936091448)
shards : all 96 match their published sizes individually
RESULT : byte-exact match

부분 다운로드는 크게 실패하지 않는다; 잘못된 토큰을 생성한다. 여기서 FAIL은 중단으로 취급하라. 샤드별로 확인하면 "1.56 테라바이트 재다운로드"가 "이 17 기가바이트 파일 하나 재다운로드"로 바뀌고, 총량으로는 잡을 수 없는 한 가지 경우를 잡는다: 두 샤드가 같은 양만큼 반대 방향으로 틀린 경우.

Step 5. pack the trunk
./scripts/pack-trunk.sh ~ /k3model ~ /k3trunk
약 4분, 한 번. 93개의 덴스 레이어를 하나의 109 GB 파일로 다시 쓰는데, 레이어 L이 알려진 오프셋에 위치하여 단일 호출로 읽힐 수 있다. 이것이 메모리 요구 사항을 다이얼로 바꾸는 것이다. 출력을 가장 빠른 디스크에 두라.

Step 6. run
./bin/k3 ~ /k3model --trunk ~ /k3trunk --preset workstation \
--tok ~ /k3model --prompt " The capital of France is " --gen 8 --incremental
토크나이저는 체크포인트와 함께 배송되므로 --tok 가 모델 디렉터리를 가리킨다.

모든 것이 어디에 놓이는가
kimi-k3-in-c/ ~45 MB 소스, 문서, 이미지, 그리고 bin/k3
~/k3model/ 1.56 TB 96 샤드 · config.json · tiktoken.model · tokenizer_config.json
~/k3trunk/ 109 GB trunk.bin · trunk.json, 가장 빠른 디스크에

모든 실행의 첫 토큰은 모든 고정된 레이어를 디스크에서 로드한다, 서버 프리셋에서 약 108 GB이므로 정상 속도보다 훨씬 오래 걸린다. 그 비용은 토큰당 한 번이 아니라 실행당 한 번 지불된다.

사용법
개요
k3 <model_dir> [prompt] [memory] [generation] [diagnostics]

<model_dir> 는 .safetensors 샤드를 담은 디렉터리다. 모든 실행에 필요하지만, --help , --version , --list-presets 는 없이도 작동한다:

./bin/k3 --help
./bin/k3 --version
./bin/k3 --list-presets
프롬프트 옵션
--chat 밖에서는 이 중 정확히 하나가 필요하다. 아무것도 전달하지 않거나 둘 이상 전달하면 사용법 오류다 (종료 2).

플래그
인자

--prompt
TEXT
TEXT를 토큰화하고 실행한다. --tok 필요.

--prompt-file
PATH
파일의 바이트를 토큰화한다. --tok 필요. 비ASCII에는 이것을 선호하라: 셸은 argv 를 재인코딩하지만, 파일은 그대로 읽힌다

--ids
1,2,3
토큰 id를 직접. 토크나이저가 전혀 로드되지 않으므로 토크나이저 파일이 없는 기계에서도 작동한다. 테스트가 사용하는 재현 가능한 채널

# text in
./bin/k3 ~ /k3model --tok ~ /k3model --prompt " The capital of France is " ...

# text in, from a file. Use this for CJK, emoji, accents
printf ' La capitale de la France est ' > /tmp/p.txt
./bin/k3 ~ /k3model --tok ~ /k3model --prompt-file /tmp/p.txt ...

# ids in, ids out, no tokenizer needed
./bin/k3 ~ /k3model --ids 1008,10484,318,15383,387 ...
메모리 옵션

플래그
인자
기본값

--preset
NAME
없음
laptop · desktop · workstation · server · max . 아래 두 예산을 모두 설정한다

--trunk
DIR
꺼짐
5단계의 패킹된 트렁크 디렉터리. 이것이 스트리밍을 가능하게 한다. 없으면 트렁크가 완전히 상주하여 로드된다, 약 113.5 GB

--trunk-gb
X
16
고정된 레이어와 스트리밍 링을 위한 예산

--cache-gb
X
64
라우팅된 전문가 LRU 캐시를 위한 예산

--trunk-ring
N
2
스트리밍 링 슬롯: 하나는 계산 중인 레이어, 나머지는 읽기 진행 중. 추가 슬롯마다 RAM 슬롯 하나가 들고, 들어가지 않으면 예산이 여전히 이긴다

--threads
N
물리 코어
OpenMP 스레드. Linux에서 기본값은 OpenMP의 논리 CPU당 한 스레드가 아니라 물리 코어 수이며, SMT 부품에서는 이것이 더 느리다. OMP_NUM_THREADS 가 설정되어 있으면 존중된다

--ultra-low-memory
없음
꺼짐
정확한 임베딩 행과 lm_head 청크를 스트리밍한다; 전체 재계산은 또한 하나의 순환 상태 슬롯을 재사용한다. --trunk 필요

울트라 프리셋은 --ultra-low-memory 를 선택한다 …