Moonshot AI는 7월 27일 Kimi K3의 오픈 웨이트를 공개했습니다. Hugging Face 다운로드 수는 이미 10만 건에 육박하며, Moonshot이 공개한 벤치마크에서는 Claude Opus 4.8을 능가했다고 보고되었습니다. 총 2.8조 파라미터 모델을 직접 호스팅할 수 있다는 점은 강력하지만, 실제 배포 전에 저장 공간·메모리·처리량 요구 사항을 먼저 계산해야 합니다.
풀 정밀도 추론에는 약 1.57TB의 디스크 공간이 필요하며, 공개된 MXFP4 웨이트도 594GB 다운로드가 필요합니다. K3는 직접 소유할 수 있는 모델이지만, 8B Llama처럼 개인 노트북에서 가볍게 실행하는 모델은 아닙니다.
이 글에서는 다음을 단계별로 다룹니다.
- K3 웨이트와 모델 구조
- vLLM 또는 SGLang을 사용하는 데이터센터급 배포
- GGUF 양자화를 사용하는 대형 워크스테이션 실행
- 소비자 기기에서의 실제 성능 한계
- 자체 호스팅 K3 엔드포인트를 API 워크플로우에 연결하고 테스트하는 방법
다운로드하는 내용
먼저 다운로드할 모델의 형태를 확인하세요. 배경 정보는 Kimi K3란 무엇인가?에서 확인할 수 있습니다.
핵심 사양은 다음과 같습니다.
총 2.8T 파라미터, 토큰당 104B 활성화
K3는 896개 전문가를 사용하는 MoE(Mixture-of-Experts) 모델입니다. 각 토큰은 선택된 전문가 16개와 공유 전문가 2개를 통과합니다. 전체 파라미터 수보다 토큰당 계산량은 낮지만, 모델 웨이트 자체는 매우 큽니다.93개 레이어
69개의 Kimi Delta Attention(KDA) 레이어와 24개의 Gated MLA 레이어로 구성됩니다. KDA 설계는 최대 100만 토큰 컨텍스트 창 활용을 목표로 합니다.네이티브 비전 지원
401M 파라미터 MoonViT-V2 인코더를 사용하며, 공개 웨이트는 텍스트·이미지·비디오 입력을 처리합니다.MXFP4 웨이트와 MXFP8 활성화
Moonshot은 양자화 인식 학습을 적용했습니다. 따라서 4비트 릴리스는 사후 압축본이 아니라 의도된 서비스 형식입니다. 추가 저비트 양자화로 줄일 수 있는 여유는 제한적입니다.사고 전용(Thinking-only)
K3는 답변 전에 추론을 수행하며, 낮음·중간·최대 노력 수준을 제공합니다. 즉시 응답 모드는 없습니다.
웨이트는 Hugging Face 리포지토리에서 Kimi K3 라이선스 동의 후 받을 수 있습니다.
huggingface-cli download moonshotai/Kimi-K3
1Gbps 연결에서는 594GB 다운로드에 약 80~90분이 걸릴 수 있습니다. 배포 전에 디스크 여유 공간, 네트워크 대역폭, 모델 캐시 경로를 확인하세요.
옵션 1: vLLM 또는 SGLang으로 데이터센터급 서비스 배포
Moonshot은 vLLM, SGLang, TokenSpeed를 권장합니다. KDA 프리필 캐시 관련 기여가 웨이트와 함께 vLLM에 포함되어 있으므로, 시작점으로는 vLLM이 가장 단순합니다.
1. vLLM 서버 시작
8-way 텐서 병렬 처리와 131K 컨텍스트로 시작하려면 다음 명령을 사용합니다.
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--max-model-len 131072
처음부터 100만 토큰 컨텍스트를 설정하지 마세요. 전체 컨텍스트의 KV 캐시만 약 27GB가 필요합니다. 우선 131072로 시작한 뒤, 실제 워크로드에서 긴 컨텍스트가 필요한지 측정하세요.
2. 하드웨어 요구 사항 확인
실제 운영을 위한 기준은 다음과 같습니다.
- 최소 구성: 텐서 병렬 처리가 가능한 8-GPU 노드
- 평가 환경: Moonshot은 H20 클러스터에서 평가
- 처리량 참고: B200급 하드웨어에서는 초당 100토큰 이상을 달성할 수 있음
이 경로에서 “로컬”은 노트북에서 실행한다는 의미가 아닙니다. 데이터 주권 관점에서 모델, 로그, 규정 준수 데이터를 자체 인프라에 유지한다는 의미입니다.
3. 샘플링 파라미터 설정
Moonshot의 기본 샘플링 값은 다음과 같습니다.
{
"temperature": 1.0,
"top_p": 0.95
}
에이전트 워크로드에서는 다음 설정을 기준으로 테스트할 수 있습니다.
{
"temperature": 1.0,
"top_p": 1.0
}
변경 전후의 출력 구조, 응답 지연 시간, 토큰 사용량을 함께 기록해야 양자화나 엔진 변경의 영향을 비교할 수 있습니다.
옵션 2: 대형 워크스테이션에서 GGUF 양자화 사용
Unsloth는 llama.cpp 사용자를 위한 GGUF 변환을 공개했습니다. 현재 K3 크기를 공식 MXFP4 릴리스보다 더 낮추는 현실적인 방법은 이 동적 양자화 경로입니다.
| 양자화 | 크기 | 의미 |
|---|---|---|
| UD-IQ1_M | 약 345GB | 최소 사양. 공격적인 1비트 동적 양자화 |
| UD-IQ1_S | 약 650GB | Unsloth가 권장하는 균형점 |
| UD-Q4_K_XL | 약 1.55TB | 거의 풀 정밀도 |
| UD-Q8_K_XL | 약 1.6TB | 실질적으로 손실 없음 |
메모리 계산 규칙
실행 전에는 다음 규칙을 적용하세요.
RAM + VRAM 합계가 선택한 GGUF 양자화 파일 크기와 대략 같아야 합니다.
메모리가 부족해도 llama.cpp의 오프로딩으로 실행 자체는 가능할 수 있습니다. 하지만 부족한 용량이 늘어날수록 SSD나 다른 메모리 계층에서 웨이트를 가져와야 하므로 속도가 크게 떨어집니다.
현실적인 최소 구성은 다음과 같습니다.
- 128GB 이상 메모리를 갖춘 시스템
- 대용량 통합 메모리를 제공하는 Mac Studio
- DGX Station급 워크스테이션
llama.cpp 실행 예시
비전 프로젝터를 포함해 실행하는 최소 예시는 다음과 같습니다.
./llama.cpp/llama-cli \
--model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
--mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
--temp 1.0 \
--top-p 0.95
하드웨어가 이 기준보다 낮다면 K3를 억지로 실행하기보다 다른 모델을 선택하는 편이 낫습니다. 2026년 최고의 로컬 LLM 목록에는 24~128GB 환경에서 더 실용적인 속도로 동작하는 오픈 모델이 포함되어 있습니다.
M1 Max 실험: 가능하지만 토큰당 16초
Hacker News 스레드에서는 64GB M1 Max에서 K3를 실행한 사례가 공유되었습니다. 이 구성은 메모리에 모든 웨이트를 올리는 대신 2TB SSD에서 일부 웨이트를 스트리밍합니다.
이 실험에서 확인할 수 있는 점은 명확합니다.
- K3에는 약 115GB의 밀집 파라미터가 있으며, 모든 토큰이 이 부분을 사용합니다.
- 여기에 토큰당 약 25GB의 라우팅된 전문가 웨이트가 추가됩니다.
- 밀집 파라미터만으로도 64GB RAM을 넘기므로 SSD가 느린 메모리처럼 동작하게 됩니다.
- 결과는 약 토큰당 16초이며, 일부 구성에서는 토큰당 1분 이상도 보고되었습니다.
MoE 희소성과 mmap을 사용하면 2.8T 모델을 노트북에서도 실행할 수 있다는 점은 흥미롭습니다. 그러나 실제 개발이나 제품 사용을 위한 방식은 아닙니다.
MacBook에서 K3 응답이 필요하다면 무료 계층 또는 호스팅 API가 더 적합합니다.
로컬 K3를 API 워크플로우에 연결하기
vLLM 또는 llama.cpp 서버 모드로 K3를 제공하면 일반적으로 OpenAI 호환 HTTP 엔드포인트를 얻습니다. 이후에는 다른 API와 동일하게 요청, 스트리밍, 스키마, 지연 시간을 테스트할 수 있습니다.
API로 로컬 LLM 테스트에서 사용하는 워크플로우를 K3에도 그대로 적용할 수 있습니다.
1. 환경 변수로 백엔드 전환
vLLM 기본 주소를 환경으로 등록합니다.
base_url = http://localhost:8000/v1
호스팅된 Moonshot 엔드포인트를 사용할 때도 같은 요청 형식을 유지하고 base_url만 전환하세요.
같은 요청
+ 같은 테스트
+ 다른 base_url
= 로컬과 호스팅 환경을 일관되게 검증
2. OpenAI 호환 요청 보내기
예를 들어 채팅 완료 요청은 다음과 같은 형태로 테스트할 수 있습니다.
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "moonshotai/Kimi-K3",
"messages": [
{
"role": "user",
"content": "다음 API 응답 구조를 설명해 주세요."
}
],
"temperature": 1.0,
"top_p": 0.95,
"stream": true
}'
3. 사고 스트림 검사
K3는 사고 전용 모델이므로, 응답이 최종 답변 전에 추론 내용을 포함할 수 있습니다. Apidog의 SSE 디버깅 뷰를 사용하면 청크가 도착하는 순서대로 스트림을 확인할 수 있습니다.
다음 항목을 확인하세요.
- 스트림이 정상적으로 종료되는지
- 추론과 최종 답변 필드가 예상한 구조인지
- 노력 수준 변경 시 첫 토큰 지연 시간이 어떻게 달라지는지
- 프록시 또는 클라이언트가 SSE 청크를 버퍼링하지 않는지
4. 출력 구조를 자동 테스트로 검증
모델 품질을 사람이 매번 읽고 판단하지 않도록 테스트를 작성하세요.
검증 대상 예시:
- 응답 JSON 스키마
- 필수 필드 존재 여부
- 허용 가능한 지연 시간
- 입력·출력 토큰 사용량
- 스트리밍 종료 이벤트
- 도구 호출 또는 구조화된 출력 형식
예를 들어 다음과 같은 기준을 둘 수 있습니다.
응답 시간: 30초 이하
응답 본문: 비어 있지 않음
필수 필드: id, model, choices, usage
choices[0].message: 존재해야 함
이렇게 하면 양자화 파일을 교체하거나 vLLM 엔진을 업그레이드했을 때 출력 품질 저하가 사용자 보고가 아니라 실패한 테스트로 먼저 드러납니다.
5. GPU가 사용 중일 때는 응답을 모의 처리
594GB 모델은 로드와 초기화에 시간이 걸립니다. 프론트엔드나 API 클라이언트 개발 중에는 실제 K3 응답을 한 번 저장한 뒤 모의 서버에서 반환하도록 구성할 수 있습니다.
이 방식은 다음 상황에서 유용합니다.
- GPU가 다른 추론 작업을 처리 중인 경우
- 모델 재시작 또는 웨이트 로딩 중인 경우
- UI 개발에서 스트리밍 응답 구조만 검증하려는 경우
- 회귀 테스트를 빠르게 실행해야 하는 경우
Apidog를 다운로드하면 OpenAI 호환 서버에 대해 모의, 테스트, 문서화 워크플로우를 구성할 수 있습니다.
요청 형식은 Kimi K3 API 가이드에서 다루는 호스팅 API 요청과 일치합니다. 즉, 호스팅 환경용으로 작성한 테스트를 로컬 배포 환경으로 직접 전송할 수 있습니다.
그래서 로컬에서 실행해야 할까요?
빠르게 결정하려면 다음 표를 참고하세요.
| 상황 | 권장 사항 |
|---|---|
| 8개 이상 GPU 노드가 있고 데이터 주권 또는 규정 준수가 필요함 | 권장. MXFP4 웨이트와 텐서 병렬 처리를 사용하는 vLLM 배포 |
| RAM/VRAM 합계가 350GB 이상인 워크스테이션 | 실행 가능. Unsloth 1비트 GGUF를 사용하되 처리량 기대치를 낮출 것 |
| 64~128GB Mac 또는 PC | 비권장. 초당 몇 토큰이 아니라 토큰당 몇 초가 걸릴 수 있음 |
| 제품에서 K3를 사용하고 싶은 경우 | 호스팅 API 권장. OpenAI 및 Anthropic 호환 환경 사용 |
정리
K3 오픈 웨이트의 핵심 가치는 모든 개발자가 개인 장비에서 실행할 수 있다는 데 있지 않습니다. 프론티어급 모델을 감사하고, 미세 조정하고, 자체 인프라에서 운영할 수 있다는 데 있습니다.
하드웨어를 갖춘 팀이라면 현재는 vLLM 경로가 가장 실용적입니다.
- 8-GPU 텐서 병렬 환경을 준비합니다.
- MXFP4 웨이트를 다운로드합니다.
-
--max-model-len 131072으로 시작합니다. - OpenAI 호환 엔드포인트를 노출합니다.
- 스트리밍, 스키마, 지연 시간, 토큰 사용량을 자동 테스트합니다.
대부분의 개발자에게는 호스팅 API가 더 현실적인 선택입니다. 어느 방식을 선택하든 모델이 코드와 만나는 지점은 엔드포인트입니다. 모델이 추론하는 동안에도 개발을 멈추지 않도록 스키마 검증, 스트리밍 검사, 모의 테스트를 워크플로우에 포함하세요.
Top comments (0)