작성자 Kimi K3 자체 호스팅 방법 및 하드웨어 요구 사항
2.8조 파라미터 규모의 Kimi K3 모델을 구동하기 위한 VRAM 산술 연산과 KV 캐시 계산법을 정리했습니다. 32개 GPU 클러스터 없이 현실적으로 모델을 실행할 수 있는 세 가지 방법과 인프라 구축 시 반드시 고려해야 할 메모리 비용 문제를 상세히 다룹니다.
Kimi K3를 직접 호스팅하려면
Kimi K3를 직접 호스팅하려면 2.8조 개의 파라미터를 저장할 공간이 필요하다. Moonshot은 MXFP4 형식의 오픈 웨이트를 공개했으며, 이는 웨이트당 약 0.5바이트다. 따라서 캐시에 토큰을 하나도 할당하기 전에 웨이트만으로 대략 1.4 TB가 필요하다. 현재 판매되는 어떤 accelerator도 이 용량을 단독으로 수용하지 못한다. GPU 1개로는 불가능하다. 서버 1대로는 2가지 형태에서 가능하다. 첫 번째는 accelerator 8개가 각각 288 GB인 노드다. 가장 작은 규모로 공개된 다중 사용자 serving 레시피가 이 구성을 사용한다. 두 번째는 총 RAM과 VRAM이 약 1.6 TB인 한 대의 머신에서 Unsloth의 무손실 Q8 GGUF를 llama.cpp로 실행하는 방식이다. GPU 없이도 가능하며, 한 번에 한 사용자만 serving한다.
이것이 결론이다. 아래 내용은 이 결론을 뒷받침하는 계산이다. 다음 릴리스에서도 재사용할 수 있는 부분은 계산이다. 2026년 7월 16일 발표 후 몇 주 동안 여러 인프라 공급업체가 K3 배포 가이드를 공개했으며, 각 가이드는 이미 클러스터를 보유하고 있다고 가정했다. 이 문서는 반대쪽에서 시작한다. 비용이 얼마인지, 대신 무엇을 실행할 수 있는지, 그리고 두 경우 중 어느 쪽에 해당하는지 확인하는 방법을 설명한다.
전체 파라미터 수와 활성 파라미터 수가 일치하지 않는 이유
K3는 MoE(Mixture of Experts) 모델입니다. MoE는 네트워크를 여러 하위 네트워크로 분할하고, 라우터가 토큰마다 그중 일부를 선택하게 합니다. 모델 카드에는 총 2.8T 파라미터, 토큰당 104B 활성 파라미터가 명시되어 있으며, 이는 93개 레이어에 걸쳐 있는 896개의 라우팅된 전문가 중 16개가 토큰마다 작동함을 의미합니다.
이 두 파라미터 수치는 서로 다른 질문에 대한 답을 제공하며, 이를 혼동하는 것은 "이 모델을 실행할 수 있는가"를 묻는 모든 스레드에서 가장 흔히 발생하는 실수입니다.
활성 파라미터는 연산 비용을 결정합니다. 토큰 하나가 약 104B개의 파라미터를 통과하며 연산되므로, 기대할 수 있는 처리량은 2.8T 모델이 아닌 104B 밀집(dense) 모델과 유사합니다. 이것이 바로 MoE를 구축하는 근본적인 이유입니다.
전체 파라미터는 메모리 비용을 결정합니다. 라우터는 어떤 토큰에 대해서든 임의의 전문가를 선택할 수 있으므로, 첫 번째 요청이 도착하기 전에 모든 전문가를 빠른 저장 공간에 적재해야 합니다. 활성 전문가만 VRAM에 유지하고 나머지는 필요할 때 불러오는 방식도 존재합니다. llama.cpp의 --moe-cache-mib은 GPU에 전문가 캐시를 유지하고, 시스템 RAM에 있는 나머지 전문가 중 라우터가 선택한 것을 필요할 때 업로드합니다. 하지만 이 방식도 전체 크기를 줄이지는 못합니다. 나머지 전문가는 여전히 RAM에 상주해야 하며, PCIe 링크는 HBM의 초당 테라바이트 단위 대역폭에 비해 초당 수십 기가바이트 수준의 속도만 제공하므로 캐시 미스가 발생할 때마다 지연 시간이 발생합니다. 모델이 RAM에도 들어가지 않아 NVMe에서 전문가를 스트리밍하는 방식은 훨씬 더 느리며, Unsloth의 K3 가이드는 디스크 오프로딩 시 실행 속도가 매우 저하된다고 경고합니다.
결론적으로, 연산은 저렴하지만 저장에는 큰 비용이 듭니다. 하드웨어 사양은 2.8T를 기준으로 산정하고, 속도 기대치는 104B를 기준으로 설정하십시오.
가중치당 바이트 수와 테라바이트가 발생하는 이유
파라미터 수에 가중치당 바이트 수를 곱한다. 가중치의 경우 이것이 전체 공식이다.
이 차트의 데이터
[
{
"label": "bf16",
"bytes_per_weight": 2,
"weights_tb": 5.6
},
{
"label": "fp8",
"bytes_per_weight": 1,
"weights_tb": 2.8
},
{
"label": "4-bit (MXFP4, as shipped)",
"bytes_per_weight": 0.5,
"weights_tb": 1.4
},
{
"label": "2-bit",
"bytes_per_weight": 0.25,
"weights_tb": 0.7
}
]K3는 양자화 인식 방식으로 학습되었고 MXFP4 가중치와 MXFP8 활성값으로 릴리스되었으므로, 4비트 행이 실제 구성이다. 그보다 위의 행은 비교를 위한 것이다. 동일한 모델을 bf16으로 저장하면 5.6 TB가 필요하다. MXFP4는 가중치 32개로 구성된 각 블록마다 공유 8비트 스케일 하나도 저장하므로 약 6 percent가 추가된다. 또한 Moonshot의 구성에서는 attention, 공유 experts, vision tower가 4비트 형식에서 제외된다. 따라서 Unsloth의 계산으로 전체 checkpoint는 단순히 1.4 TB가 아니라 약 1.56 TB가 된다.
이로 인해 일반적인 용량 절감 방법의 여지는 줄어들지만 완전히 사라지지는 않는다. 릴리스된 checkpoint가 이미 4비트이므로 쉽게 얻을 수 있는 절감 효과는 이미 반영되었다. 그래도 더 낮은 비트 수를 사용하면 용량은 계속 줄어든다. 27 October 2026 기준으로 Unsloth가 측정한 K3의 동적 GGUF 양자화 버전은 2비트 UD-Q2_K_XL의 861.3 GB부터 1비트 UD-IQ1_S의 594 GB까지다. Unsloth는 그에 따른 비용도 공개한다. 전체 모델과 비교한 top-1 token 일치율은 UD-Q2_K_XL에서 90.390 percent, 711.1 GB인 UD-IQ2_XXS에서 84.127 percent, UD-IQ1_S에서 78.875 percent다. Hugging Face repo에는 더 작은 1비트 파일도 있으며, UD-Q1_0은 466 GB까지 줄어든다. 다만 해당 파일과 함께 공개된 일치율 수치는 없다. 이는 측정된 정확도 손실이다. 가장 작은 파일도 여전히 단일 카드 중 가장 큰 카드의 약 1.6배다.
Kimi K3에는 GPU가 몇 개 필요한가
이 차트의 데이터
[
{
"config": "H100 80GB",
"hbm_per_gpu_gb": 80,
"gpus_for_weights": 18
},
{
"config": "H200 141GB",
"hbm_per_gpu_gb": 141,
"gpus_for_weights": 10
},
{
"config": "B200 192GB",
"hbm_per_gpu_gb": 192,
"gpus_for_weights": 8
},
{
"config": "GB300 288GB",
"hbm_per_gpu_gb": 288,
"gpus_for_weights": 5
}
]이 수치는 목표가 아니라 최저선으로 보아야 합니다. 가중치만 계산한 값이므로 KV cache, activation buffer, allocator fragmentation, 두 번째 동시 요청을 처리할 여유 공간은 포함하지 않습니다. 분할 결과가 균등해야 하는 것도 아닙니다. vLLM의 pipeline parallelism은 모델을 레이어 단위로 분할하며 불균등한 분할을 지원합니다. SGLang의 K3 prefill 레시피는 93개 레이어에 대해 8개와 16개의 pipeline stage를 사용합니다.
공개된 권장 구성은 이 최저선보다 큽니다. Moonshot의 출시 권장 사항은 64개 이상의 accelerator로 구성된 supernode를 제안했습니다. 27 October 2026 기준으로 SGLang cookbook에는 8-GPU 노드 4개로 구성된 H100 설정이 포함되어 있습니다. 이 설정은 GPU 32개와 총 2,560 GB의 메모리를 사용하며, 18개의 카드만 필요한 최저선보다 큽니다. 또한 단일 노드 레시피로 8-GPU B300 노드 1개와 8-GPU MI350X 또는 MI355X 노드 1개도 제시합니다. 이 구성은 카드당 288 GB, 총 2,304 GB입니다. 최저선보다 구성이 큰 것은 낭비가 아닙니다. KV cache와 activation memory를 저장하고, 서버가 여러 요청을 동시에 batch 처리할 수 있도록 여유 공간을 확보하기 위한 것입니다. 가장 요구 사항이 낮은 5 GB300급 카드 구성도 실제로는 정확히 이러한 8-GPU 노드로 올림합니다. 이 노드는 여러 사용자를 대상으로 K3를 serving하는 레시피가 공개된 구성 중 가장 작은 시스템입니다.
KV 캐시는 사람들을 놀라게 하는 부분입니다
가중치는 고정 비용입니다. 하지만 KV(key value) 캐시는 그렇지 않습니다. 컨텍스트 길이가 길어질수록, 그리고 동시 접속자가 늘어날수록 함께 증가합니다. 일반적인 어텐션(ordinary attention)의 공식은 bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element이며, 여기에 컨텍스트 길이와 동시 접속자 수를 곱해야 합니다.
예를 들어 보겠습니다. 이는 단지 예시일 뿐입니다: 64개 레이어, 8개 KV 헤드, 헤드 차원 128, fp8. 이 경우 2 64 8 128 1 = 131,072 바이트, 즉 토큰당 128 KiB가 소요됩니다.
이 차트의 데이터
[
{
"label": "8k context",
"kv_gib_per_user": 1
},
{
"label": "32k context",
"kv_gib_per_user": 4
},
{
"label": "128k context",
"kv_gib_per_user": 16
},
{
"label": "1M context",
"kv_gib_per_user": 128
}
]128k 컨텍스트를 사용하는 사용자 1명당 비용은 16 GiB입니다. 100만 토큰 전체를 사용하는 사용자 1명당 비용은 128 GiB로, 가중치를 하나도 로드하기 전에 288 GB 카드 용량의 거의 절반을 대화 하나가 차지하게 됩니다.
K3가 일반적인 어텐션을 사용하지 않는 이유는 바로 마지막 수치 때문입니다. K3의 93개 레이어는 69개의 KDA(Kimi Delta Attention) 레이어와 24개의 Gated MLA(multi-head latent attention) 레이어로 구성됩니다. KDA는 토큰마다 커지는 캐시 대신 고정된 크기의 순환 상태(recurrent state)를 유지하며, MLA는 키와 값을 하나의 저차원 잠재 벡터(low rank latent vector)로 압축합니다. 따라서 실제 토큰당 비용은 위 예시보다 훨씬 낮아집니다. Moonshot이 공개한 config.json에 따르면 해당 잠재 벡터의 크기는 512의 kv_lora_rank와 64 너비의 로터리 키(qk_rope_head_dim)를 합쳐, MLA 레이어당 토큰당 576개의 값이 필요합니다. 24개 레이어에 걸쳐 레이어당 2바이트씩 계산하면 27,648 바이트, 즉 토큰당 약 27 KiB가 되며, 1,048,576 토큰의 전체 대화에 대해 고정된 KDA 상태를 포함하여 약 27 GiB가 소요됩니다. 이는 측정값이 아닌 추정치로 간주하십시오. 엔진마다 캐시를 배치하고 구성하는 방식이 다르며, 8비트 캐시를 사용하면 대략 절반으로 줄어듭니다.
자신의 배포 환경에서 어느 정도의 용량을 점유하는지 확인하려면, --max-model-len를 높이면서 nvidia-smi를 모니터링하지 마십시오. vLLM은 --gpu-memory-utilization(현재 문서 기준 기본값 0.92) 또는 명시적인 GPU별 캐시 예산에 따라 KV 캐시 풀을 미리 할당합니다. 따라서 전체 GPU 메모리 사용량은 단일 대화가 아닌 전체 풀의 크기를 보여줍니다. 대신 시작 로그를 확인하십시오. vLLM은 해당 로그에서 토큰 단위의 KV 캐시 크기와 현재 컨텍스트 길이에서의 최대 동시 접속자 수를 보고합니다.
추론의 형태는 다음 릴리스에서도 유지됩니다. 모델이 100만 토큰 컨텍스트를 지원한다고 광고하면서 어텐션 설계에 대해 언급이 없다면, 반대 증거가 나오기 전까지는 캐시가 제약 사항이라고 가정하십시오.
Tier 1: 시간 단위로 클러스터 임대
이 계층은 여러 사용자에게 동시에 K3를 배포된 정밀도로 제공한다. RAM이 충분한 한 대의 시스템은 Unsloth의 Q8 GGUF를 사용해 Unsloth가 완전 정밀도 무손실이라고 표시한 수준으로 K3를 실행할 수도 있다. 그러나 이 방식은 한 번에 한 명의 사용자만 처리하며 tier 2에서 다룬다. 여기서는 하드웨어를 구매하지 않는다. 필요한 시간만큼 임대한 뒤 사용이 끝나면 중지한다.
이 차트의 데이터
[
{
"label": "1 GPU, always on",
"gpu_hours": 720,
"usd_cost": "1,800"
},
{
"label": "8 GPUs, 4 hours a day",
"gpu_hours": 960,
"usd_cost": "2,400"
},
{
"label": "8 GPUs, always on",
"gpu_hours": 5760,
"usd_cost": "14,400"
},
{
"label": "32 GPUs, always on",
"gpu_hours": 23040,
"usd_cost": "57,600"
}
]요금은 견적이 아니라 가정값이다. 온디맨드 요금은 공급자와 GPU 세대에 따라 크게 다르다. 단일 노드 레시피에 필요한 288 GB 부품은 H100보다 시간당 비용이 높고, 예약 용량은 더 저렴하다. 공급자의 실제 값을 사용해 곱셈을 다시 계산한다. GPU 수 × 시간 × 요금이다. 차트의 목적은 비율을 보여 주는 데 있다. 8 GPU 노드를 하루 4시간 동안 버스트로 사용하면 한 달에 2,400 USD가 들지만, SGLang에 맞춘 32 GPU H100 구성을 계속 실행하면 57,600 USD가 든다.
주요 서버는 모두 모델 카드에 실행 명령을 게시한다.
pip install vllm
vllm serve "moonshotai/Kimi-K3"pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000실제 클러스터에서는 두 기본 명령을 그대로 실행하지 않는다. 하드웨어에 맞는 병렬 처리 플래그를 추가한다. SGLang에서는 텐서 병렬 처리에 --tp-size, 파이프라인 병렬 처리에 --pp-size, 전문가 병렬 처리에 --ep-size을 사용한다. 텐서 병렬 처리 수와 파이프라인 병렬 처리 수의 곱은 실제로 보유한 GPU 수와 같아야 한다. 전문가 병렬 처리는 해당 그룹 안에서 전문가를 분할하므로, 32 GPU H100 레시피에서는 --tp-size 32와 --ep-size 32를 모두 설정한다.
실제 트래픽을 보내기 전에 서버가 정상적으로 시작했는지 확인한다.
curl http://127.0.0.1:30000/v1/models정상 서버는 모델 ID를 나열하는 JSON 객체로 응답한다. Connection refused이면 프로세스가 아직 가중치를 로드 중이거나 이미 종료된 상태이므로, 다시 시도하기 전에 서버 로그를 확인한다.
초기 몇 주 동안 흔한 장애 원인은 모델보다 오래된 런타임이었다. K3는 KDA와 새로운 MoE 계층을 포함한 상태로 출시되었지만, 안정 버전의 vLLM과 SGLang에는 출시 시점에 해당 기능이 없었다. 그 결과 서버가 시작 중 Model architectures [...] are not supported for now 형식의 행을 출력하고 종료된다. 빌드에 해당 계층을 실행하는 코드가 없으므로 설정을 변경해도 해결되지 않는다. 이후 상황은 바뀌었다. 27 October 2026 기준으로 SGLang은 v0.5.17부터 릴리스에 K3 지원을 포함했으며, 최신 버전은 v0.5.22이다. 또한 vLLM의 v0.28.0부터 v0.32.0까지 릴리스 노트에도 모두 K3 관련 작업이 포함되어 있다. 최신 릴리스를 설치한다. 일부 하드웨어별 경로에는 전용 이미지가 여전히 필요하다. 예를 들어 Blackwell에서는 SGLang의 NVFP4 빌드가 필요할 수 있으므로, 사용하는 카드에 맞는 레시피를 확인한다.
비용과 관련해 자주 놓치는 사항이 있다. 과금은 모델이 준비된 시점이 아니라 인스턴스가 시작된 시점부터 시작된다. 1 GB/s 속도로 1.56 TB를 다운로드하면 첫 토큰을 생성하기 전에 클러스터 사용 시간이 약 26분 소요된다. 인스턴스보다 오래 유지되는 볼륨에 가중치를 미리 저장한다. 그러면 두 번째 실행은 몇 분 안에 시작된다.
Tier 2: accelerator 1개에서 더 작은 모델 실행
이 Tier에서는 K3를 실행하지 않는다. 시작하기 전에 이 사실을 분명히 해야 한다. 대부분의 "K3를 로컬에서 실행"하는 논의는 이를 인정하지 않은 채 결국 이 단계에 도달한다.
적합성 규칙은 축소한 동일한 공식이다. 파라미터 수에 웨이트당 바이트 수를 곱하고, 여기에 KV cache와 약 2 GB의 runtime overhead를 더한 값이 VRAM보다 작아야 한다. 4-bit에서는 파라미터당 대략 0.5바이트이므로 다음과 같이 여유 있게 조합할 수 있다.
- 16 GB card: 긴 context를 위한 여유를 두고 4-bit 7B 모델
- 24 GB card: 4-bit 14B 모델
- 48 GB card: 4-bit 32B 모델
- 80 GB card: 4-bit 70B 모델 또는 8-bit 30B급 MoE
위의 모든 조합은 한 번에 하나의 request를 처리한다고 가정한다. 두 번째 사용자가 prompt를 보내는 순간 각 concurrent slot에는 자체 KV cache가 필요하다. 이는 Ollama의 NUM_PARALLEL 및 MAX_QUEUE 설정이 병렬 slot, 대기 중인 request, 남은 VRAM 사이에서 대신 조정하는 trade-off다.
대형 단일 머신에서 K3 자체를 실행하는 방법도 하나 있으며, 이 방법은 이 Tier와 마지막 Tier의 중간에 해당한다. Unsloth는 llama.cpp에서 1-bit 및 2-bit quantisation부터 UD-Q8_K_XL까지 K3의 GGUF 빌드를 문서화한다. UD-Q8_K_XL은 full precision lossless로 표시되어 있다. 또한 이러한 빌드를 실행할 수 있는 하드웨어로 NVIDIA DGX Station을 명시한다. 경험칙에 따르면 RAM과 VRAM의 합계는 quant size와 대략 같아야 한다. 1-bit UD-IQ1_S 빌드는 약 610 GB, Q8 빌드는 약 1.6 TB가 필요하다. 이보다 적으면 모델이 disk로 fallback되어 속도가 크게 느려진다. GPU는 선택 사항이다. Unsloth의 빌드 지침에는 "GPU가 없거나 CPU inference를 사용하려는 경우" CUDA를 끄도록 되어 있다. 1-bit 및 2-bit 빌드는 K3를 크게 quantise한 것이며, 위에서 측정한 정확도 저하를 감수해야 한다. Q8 빌드는 릴리스된 정밀도의 K3를 RAM 속도로 serving한다. 어느 쪽도 더 작은 모델은 아니다.
Ollama는 GPU가 연결된 VPS에서 작동하는 서버를 구축하는 가장 짧은 경로다.
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14bollama run은 처음 사용할 때 모델을 다운로드한 다음 prompt를 표시한다. 존재하지 않는 tag를 지정하면 Error: model "..." not found를 반환하므로, 기억에 의존해 입력하지 말고 library page에서 tag를 복사해야 한다. systemd unit과 remote access를 포함한 전체 walkthrough는 VPS에서 Ollama 실행에 있다.
llama.cpp를 사용하면 quantisation과 offload를 더 세밀하게 제어할 수 있다.
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080-ngl 99는 모든 layer를 GPU에서 처리하도록 요청한다. load log를 확인해야 한다. 이 로그에는 offload된 layer 수가 표시된다. system RAM으로 넘어간 layer는 HBM bandwidth가 아니라 RAM bandwidth로 실행된다. 따라서 모델이 수용 한도를 초과하는 순간 generation speed가 대략 10배 떨어진다. 두 도구의 trade-off는 Ollama와 llama.cpp 비교에서 설명한다.
호스팅 API, 자체 호스팅 오케스트레이션
이 차트의 데이터
[
{
"label": "Input, cache hit",
"usd_per_million_tokens": "0.30"
},
{
"label": "Input, cache miss",
"usd_per_million_tokens": "3.00"
},
{
"label": "Output",
"usd_per_million_tokens": "15.00"
}
]엔드포인트가 OpenAI 호환이므로 기본 URL만 변경하면 기존 클라이언트를 사용할 수 있다.
curl https://api.moonshot.ai/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $MOONSHOT_API_KEY" \
-d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'정상적인 key를 사용하면 choices 배열이 포함된 JSON 객체가 반환된다. 401가 반환되면 인증에 실패한 것이므로 key가 올바르고 만료되거나 비활성화되지 않았는지 확인해야 한다. 헤더가 Authorization: Bearer 뒤에 key를 이어 붙인 형식인지도 확인해야 한다. 모델을 찾을 수 없다는 오류는 일반적으로 id가 변경되었다는 뜻이다. 공급자는 checkpoint 사이에 id를 폐기하기도 한다.
이제 위에서 가정한 임대 요금을 기준으로 손익분기점을 계산해 보자. 항상 실행되는 8 GPU 노드의 월 비용은 14,400 USD다. 출력 토큰 1 million개당 15.00 USD를 지불하면 같은 비용으로 API에서 약 960 million개의 출력 토큰을 사용할 수 있다. 비용 측면에서 유리해지려면 한 달에 1 billion개에 가까운 출력 토큰을 생성해야 한다. 이는 하루 약 30 million개에 해당하며, 그동안 클러스터를 계속 사용해야 한다. 유휴 GPU에도 사용 중인 GPU와 같은 요금이 부과되기 때문이다. 프롬프트 비중이 큰 에이전트 워크로드에서는 이 기준이 더 멀어진다. 반복되는 컨텍스트에는 cache-miss 요금인 3.00 USD가 아니라 cache-hit 요금인 0.30 USD가 million tokens당 부과된다.
이 계층에서 자체 호스팅하는 대상은 모델을 제외한 주변 구성 요소 전체다. 여기에는 API key를 보관하여 client에 전달되지 않게 하는 gateway, request 및 response log, 재시도, rate limit, 사용자별 budget이 포함된다. 이러한 구성 요소는 GPU가 전혀 없는 소형 VPS에서 실행할 수 있다. 폐쇄형 weight에도 같은 분리가 적용된다. 모델 수준에서 Claude 자체 호스팅은 불가능하며, 직접 관리할 수 있는 부분은 orchestration뿐이다.
어떤 서비스 스택이 어떤 계층에 속하는가
vLLM과 SGLang 계열 서버는 tier 1에 속한다. 이 서버는 continuous batching과 paged KV cache를 사용해 많은 요청을 동시에 처리하도록 설계되었다. 또한 여러 노드에 tensor parallelism과 expert parallelism을 분산할 수 있다. datacentre 가속기와 가속기 사이의 빠른 interconnect를 전제로 한다. 단일 consumer card에서는 설치가 더 복잡하고, 체감할 수 있는 이점도 거의 없다.
llama.cpp와 Ollama는 tier 2에 속한다. 이 도구는 단일 머신, GGUF quantisation, 모델이 메모리에 들어가지 않을 때의 CPU offload, 낮은 동시성을 대상으로 한다. llama.cpp는 expert weight를 system RAM(--cpu-moe 또는 --n-cpu-moe)에 유지하여 매우 큰 MoE를 로드할 수 있다. 또한 --moe-cache-mib을 사용하면 GPU에서 사용하는 expert를 캐시할 수 있다. 이것이 Unsloth의 K3 GGUF 빌드가 단일 머신에서 실행되는 방식이다. 이때 속도는 RAM bandwidth와 router가 cache를 놓치는 빈도에 좌우된다. 파일이 RAM과 VRAM을 합한 용량보다 크면 disk로 내려간다. 사용자 1명이 사용하는 환경에서는 실용적인 구성이다. 그러나 여러 사용자가 사용할 서비스로 운영할 수는 없다. 전체 비교는 Ollama와 vLLM 비교에 있다. 모델이 바뀌어도 결론은 달라지지 않는다. 항상 shared hardware에서 여러 사용자를 서비스하는지, 아니면 자신의 장비에서 사용자 1명만 사용하는지가 핵심이다.
이 체크포인트 이후에도 유효한 4가지 수치
- 총 파라미터 수에 가중치당 바이트 수를 곱하면 메모리 하한이 나온다. 제공된 정밀도에서는 이보다 적은 메모리로 실행할 수 없다. 4-bit 릴리스보다 더 낮게 양자화하면 정확도를 낮추는 대신 최대 약 70 percent를 절약할 수 있지만, 메모리가 10배 줄어드는 것은 아니다.
- 활성 파라미터 수가 처리량 등급을 결정한다. 활성 파라미터가 104B인 2.8T MoE는 104B 모델과 같은 수준의 연산을 수행한다.
- 토큰당 KV cache에 컨텍스트 길이와 동시성을 곱한 값이 가중치 메모리를 확보한 뒤에도 계속 증가하는 비용이다.
- 달러당 초당 토큰 수가 어떤 등급을 선택할지 결정하는 유일한 수치다. 위의 모든 값은 이 수치를 계산하기 위한 입력이다.
이 4가지를 어떤 릴리스에든 적용하면 공급업체 가이드를 열어 보기 전에 올바른 답을 얻을 수 있다. 다음 릴리스도 이미 발표되었다. Moonshot은 23 October 2026에 Kimi Code에서 추가 post-training을 적용한 K3 기반 K3.1 Pro를 출시했으며, API quickstart에는 전체 가중치를 4 November까지 릴리스한다고 나와 있다. 그런 다음 기록하는 모든 수치에 날짜를 붙여야 한다. K3 출시 후 2주 안에 가격과 지원 아키텍처 목록이 모두 변경되었다. 이 페이지의 출시 수치는 July 2026에 게시되었으며, serving recipe, runtime 릴리스와 양자화 수치는 27 October 2026에 다시 확인했다.
FAQ
Kimi K3를 단일 GPU에서 실행할 수 있습니까?
아니요. Moonshot이 제공하는 MXFP4 정밀도에서 가중치는 약 1.4 TB이며, K3에 대해 공개된 가장 작은 양자화 파일인 Unsloth의 466 GB UD-Q1_0 파일도 널리 사용할 수 있는 가장 큰 가속기의 288 GB보다 약 1.6배 큽니다. llama.cpp는 전문가 가중치를 시스템 RAM에 두고 활성 전문가를 GPU에 캐시할 수 있지만, 이 경우에도 대략 양자화 파일 크기만큼의 RAM과 VRAM이 필요합니다. 그보다 메모리가 부족하면 모델이 디스크로 내려가 실행 속도가 크게 느려집니다. 공개된 가장 작은 서빙 구성은 B300 또는 MI350X/MI355X 카드 8개가 장착된 GPU 노드 1대이며, H100 구성에는 32개가 필요합니다.
Kimi K3에는 VRAM이 얼마나 필요합니까?
가중치만으로 1.4 TB부터 계산해야 합니다. 이는 H100 80GB 카드 18개 또는 GB300급 카드 5 GB에 해당합니다. 여기에 KV cache와 활성화 메모리를 추가해야 합니다. Moonshot의 출시 지침에서는 가속기 64개 이상을 권장했습니다. 2026년 10월 27일 기준으로 SGLang cookbook은 B300 또는 MI350X/MI355X 카드 8개를 사용하는 단일 노드 구성과 H100 GPU 32개 및 총 2,560 GB 메모리를 사용하는 구성을 공개하고 있습니다. 전자의 총 메모리는 2,304 GB입니다. 따라서 가중치 용량은 필수 용량이 아니라 최소 기준으로 보아야 합니다.
양자화하면 Kimi K3를 노드 1대에 탑재할 수 있습니까?
제공되는 4비트 체크포인트는 해당 노드에 288 GB 카드 8개가 있을 때 이미 노드 1대에 들어갑니다. SGLang의 B300 및 MI355X 구성도 이 방식을 사용합니다. Unsloth의 무손실 Q8 GGUF를 사용하면 RAM 약 1.6 TB와 VRAM을 갖춘 시스템 1대에도 탑재할 수 있습니다. 더 낮은 비트 수를 사용하면 더 작은 시스템에서도 실행할 수 있습니다. Unsloth가 측정한 동적 GGUF 빌드는 2비트에서 861.3 GB, 1비트에서 594 GB이며, 저장소에는 466 GB까지 줄인 1비트 파일도 있습니다. 무손실 구성은 약 1.56 TB입니다. 정확도 저하도 측정되었습니다. 전체 모델과의 top-1 일치율은 UD-Q2_K_XL에서 90.390 percent, UD-IQ1_S에서 78.875 percent로 떨어집니다. 어느 구성도 단일 카드에는 들어가지 않습니다.
Kimi K3 API보다 GPU를 임대하는 편이 저렴합니까?
사용량이 많고 일정할 때만 그렇습니다. GPU 1시간당 2.50 USD라고 가정하면 GPU 8개로 구성된 노드를 항상 실행하는 비용은 월 14,400 USD입니다. 같은 비용으로 공개된 15.00 USD/백만 토큰 요금 기준 약 960 million output tokens를 사용할 수 있습니다. 유휴 시간, 가중치 다운로드 비용, 클러스터를 계속 운영할 담당자 비용도 발생합니다. 사용량이 급증하는 경우에는 시간 단위로 임대하고, 추정치가 아니라 직접 측정한 토큰 사용량을 기준으로 비교해야 합니다.
활성 파라미터 104B는 속도 측면에서 무엇을 의미합니까?
토큰 1개를 처리하는 연산량이 104B 모델과 같다는 뜻입니다. 따라서 처리량은 2.8T 모델이 아니라 104B 모델급에 해당합니다. 그러나 메모리 사용량을 의미하지는 않습니다. 라우터가 어떤 토큰에서든 모든 전문가를 호출할 수 있으므로 2.8T 파라미터 전체가 메모리에 상주합니다. 초당 토큰 수를 예측할 때는 활성 파라미터 수를 사용하고, VRAM 용량을 산정할 때는 전체 파라미터 수를 사용해야 합니다.