몇 주 전 직장에서 32개의 H100으로 K3를 배포했는데, 내 개인 컴퓨터에서 직접 만져볼 방법이 없어서 짜증이 났습니다. 그래서 C99로 이를 위한 추론 엔진 (inference engine)을 직접 작성했습니다. 특별히 똑똑한 기술이 들어간 것은 아닙니다. 1.56 TB 체크포인트 (checkpoint)의 93%는 라우티드 전문가 (routed experts)이며, 토큰당 896개 중 16개만 활성화되므로 전문가 모델들이 메모리에 상주할 필요가 전혀 없습니다. 이들은 필요할 때마다 NVMe에서 읽혀지며, 별도의 역양자화 (dequantization) 단계 없이 압축된 4-bit 형태 그대로 즉시 곱해집니다. 밀집 트렁크 (dense trunk)는 레이어 L이 알려진 오프셋에 위치하도록 하나의 파일로 재압축되어 한 번에 한 레이어씩 스트리밍됩니다. RAM에 유지할 용량은 사용자가 직접 조절할 수 있습니다.

제 컴퓨터(2x EPYC 7763, NVMe, 4개의 GPU는 내내 유휴 상태)에서의 수치입니다: 가장 작은 설정에서 피크 RSS (peak RSS) 8.24 GB, 토큰당 약 33초. ~128 GB를 할당하면 ~20 s/token이 나오는데, 이는 가능한 가장 빠른 속도입니다. 출력값은 그 사이의 어떤 예산 설정에서도 바이트 단위로 동일합니다.

이 방식이 K3를 사용하는 실용적인 방법이 아니라는 점은 알고 있습니다. 토큰당 30초가 걸리고, 체크포인트와 압축된 트렁크를 위해 1.7 TB의 여유 디스크 공간이 필요합니다. 제가 이것을 만든 이유는 구현을 통해 아키텍처를 이해하기 위함이지, 이것으로 무언가를 서비스하라는 뜻이 아닙니다. BLAS도, 프레임워크도, GPU 경로도 없습니다. 6개의 C 파일, libm, 그리고 OpenMP만 사용한 176 KB 크기의 바이너리입니다.

1.56 TB를 다운로드하기 전에 무결성을 확인하고 싶다면: 클론(clone) 후 make && make test를 실행하세요. 가중치(weights)나 네트워크 연결 없이 약 1분 정도 소요됩니다. 동일한 텐서 그래프 (tensor graph)를 가진 13개 레이어 모델을 빌드하고, Greedy decode 및 KV 캐시(KV cache)와 유지되는 KDA 상태를 포함한 증분 경로 (incremental path)를 포함하여 커밋된 고정값(fixtures)으로부터 PyTorch 레퍼런스와 비교 검증합니다.

Repo: https://github.com/FareedKhan-dev/kimi-k3-in-c/