8GB 메모리에서 Kimi K3를 돌린 방법, kimi-k3-in-c가 보여준 설계의 핵심 | DAKER 커뮤니티

2조7,800억 파라미터 모델과 8GB 메모리라는 조합은 얼핏 성립하기 어려워 보입니다. 그런데 kimi-k3-in-c는 이 간극을 정면으로 다룹니다. 성능을 과장하는 데모라기보다, 거대한 모델에서 어떤 가중치를 언제 메모리에 올릴지 끝까지 밀어붙인 시스템 실험에 가깝습니다.

지금 이 사례를 읽을 만한 이유도 여기에 있습니다. 대형 모델 최적화가 단순한 양자화 경쟁을 넘어, 모델 구조와 운영체제 I/O를 함께 다루는 문제라는 점을 구체적으로 보여주기 때문입니다.

2.78조 파라미터 모델과 8GB 메모리를 대비한 자극적인 유튜브형 썸네일 — 거대한 모델 저장공간과 작은 메모리 모듈의 대비를 강조해 재구성한 에디토리얼 썸네일입니다.

핵심은 무엇이 달라졌나

Kimi K3는 2조7,800억 파라미터와 1.56TB 체크포인트를 가진 모델입니다. kimi-k3-in-c는 GPU, 프레임워크, BLAS 없이 C99로 추론을 구현했고, 896개 전문가 중 토큰마다 16개만 사용하는 MoE 구조를 활용했습니다.

kimi-k3-in-c는 Kimi K3의 MoE 구조를 이용해 필요한 전문가만 디스크에서 읽고, 덴스 트렁크를 스트리밍해 최대 상주 메모리를 8.24GB까지 낮췄습니다.

이 프로젝트는 메모리를 줄이기 위해 가중치를 무작정 덜어낸 것이 아니라, 실제로 필요한 부분만 그때그때 읽는 방식으로 접근했습니다. 그 결과 8GB부터 224GB까지 12개 메모리 예산에서도 같은 프롬프트의 생성 토큰 ID가 같았다는 검증 결과를 제시합니다.

왜 중요한가

이 사례의 가치는 실용 속도보다 메모리 설계에 있습니다. 전체 가중치를 한꺼번에 상주시킬 수 없는 상황에서, 어떤 바이트를 메모리에 남기고 어떤 레이어를 순서대로 스트리밍할지 결정하는 방식이 핵심입니다.

가중치를 더 깎아 넣는 대신 어떤 바이트를 상주시킬지, 어떤 레이어를 순서대로 스트리밍할지 결정한 실험입니다.

대형 모델 최적화를 공부하는 개발자에게는 모델 구조와 시스템 레벨 I/O가 만나는 지점을 보여주는 사례로 읽을 만합니다. 특히 MoE 모델에서 항상 쓰는 부분과 조건부로 쓰는 부분을 분리해 생각하는 관점이 분명하게 드러납니다.

수치로 보면 더 분명한 변화

항목	확인 내용	판단 기준
전체 bf16 상주	5,560GB	출발점
배포 체크포인트	1,560GB	전문가 가중치 4비트
전문가 스트리밍	113.49GB	사용 전문가만 읽기
트렁크 스트리밍	8.24GB	상주 레이어 예산화

이 표가 보여주듯, 메모리 절감은 한 번의 압축으로 이뤄진 것이 아닙니다. 전체 bf16 상주 상태에서 시작해, 배포 체크포인트 구성과 전문가 선택적 로딩, 마지막으로 트렁크 스트리밍까지 단계적으로 줄여 나간 결과입니다.

실무에서 참고할 지점

이 프로젝트를 바로 서비스에 적용하기보다, 메모리 병목을 해부하는 기준으로 보는 것이 좋습니다. 특히 체크포인트에서 실제 용량을 많이 차지하는 텐서가 무엇인지 먼저 확인하고, 토큰마다 항상 필요한 가중치와 조건부로 필요한 가중치를 나누는 접근은 다른 모델에도 응용할 수 있습니다.

또한 LRU가 순환 스캔에서 실패하는지 접근 순서를 재현해 보는 일, 속도 개선 전에 레퍼런스 출력과 토큰 단위 일치 테스트를 먼저 잡아두는 일도 이 사례가 주는 실질적인 포인트입니다.

함께 봐야 할 한계

8GB 구성은 가능하더라도 대화형 서비스용이라고 보기는 어렵습니다. 토큰 하나에 약 26.5초가 걸리기 때문입니다. 여기에 체크포인트 다운로드에는 1.56TB와 약 1.7TB 여유 공간이 필요합니다.

이 프로젝트의 가치는 서비스 성능보다 MoE와 스트리밍 추론 구조를 학습하는 데 가깝습니다.

따라서 메모리 절감 수치를 볼 때는 양자화로 품질을 희생한 결과와 혼동하지 않는 것이 중요합니다. 또한 특정 워크스테이션의 디스크 I/O 결과를 모든 장비에 그대로 일반화하기는 어렵습니다.

자주 나오는 질문

정말 8GB 램에서 실행되나요?

최대 상주 메모리를 8.24GB까지 낮춘 구성은 가능하지만 매우 느리고 대용량 저장공간이 필요합니다.

출력이 유지되는 이유는 무엇인가요?

가중치를 버리기보다 저장 위치와 적재 시점을 바꾸는 방식이기 때문입니다.

실무 서비스에 쓸 수 있나요?

현재 가치는 서비스 성능보다 MoE와 스트리밍 추론 구조를 학습하는 데 가깝습니다.

더 읽어볼 곳

DAKER 리서치, DAKER 학습, DACON 대회에서 이 기준을 실제 프로젝트와 연결해 볼 수 있습니다.

참고 자료

이 사례를 본 뒤, 비슷한 방식으로 먼저 실험해 보고 싶은 메모리 최적화 지점은 어디인가요?