Kimi K3 직접 호스팅을 위한 하드웨어 요구 사항 및 계산법

Kimi K3를 직접 호스팅하기 위한 조건

Kimi K3를 직접 호스팅하려면 2.8조 개의 파라미터를 수용할 공간을 확보해야 합니다. Moonshot은 MXFP4 형식으로 오픈 웨이트를 공개했는데, 이는 파라미터당 약 0.5바이트에 해당합니다. 따라서 캐시 토큰을 전혀 할당하지 않더라도 웨이트 용량만 1.4 TB에 달합니다. 현재 시판되는 가속기 중 단독으로 이를 수용할 수 있는 제품은 없습니다. K3는 멀티 노드 모델이므로, 단일 서버에서의 구동은 불가능합니다.

이것이 결론입니다. 아래 내용은 그 근거가 되는 산술적 계산입니다. 이 계산 방식은 향후 다음 릴리스에서도 동일하게 적용되기 때문입니다. 2026년 7월 17일 발표 이후 여러 인프라 벤더가 K3 배포 가이드를 공개했지만, 각 가이드는 이미 클러스터를 보유하고 있다는 전제하에 작성되었습니다. 이 페이지는 반대 지점에서 시작합니다. 즉, 필요한 비용, 대신 실행할 수 있는 대안, 그리고 본인이 두 상황 중 어디에 해당하는지 판단하는 방법입니다.

전체 파라미터 수와 활성 파라미터 수가 일치하지 않는 이유

K3는 Mixture of Experts(MoE) 모델입니다. MoE는 네트워크를 여러 하위 네트워크로 분할하고, 라우터가 토큰마다 그중 일부를 선택하게 합니다. 모델 카드에는 전체 파라미터가 2.8T, 토큰당 활성 파라미터가 104B라고 명시되어 있습니다. 이는 93개 레이어에 걸쳐 총 896개의 라우팅된 전문가가 존재하며, 각 토큰마다 16개가 활성화됨을 의미합니다.

이 두 가지 파라미터 수치는 서로 다른 질문에 대한 답이며, 이 둘을 혼동하는 것은 "이 모델을 실행할 수 있을까"라는 질문이 올라오는 모든 스레드에서 가장 흔히 발생하는 실수입니다.

활성 파라미터는 연산 비용을 결정합니다. 토큰 하나가 약 104B개의 파라미터를 거쳐 연산되므로, 기대할 수 있는 처리량은 2.8T 모델이 아닌 104B 밀집(dense) 모델과 유사합니다. 이것이 바로 MoE 모델을 구축하는 근본적인 이유입니다.

전체 파라미터는 메모리 비용을 결정합니다. 라우터는 어떤 토큰에 대해서든 모든 전문가 중 하나를 선택할 수 있으므로, 첫 번째 요청이 도착하기 전에 모든 전문가가 메모리에 상주해야 합니다. 104B만 VRAM에 올리고 나머지를 필요할 때마다 불러오는 방식은 불가능합니다. 데이터를 불러오는 작업은 마이크로초 단위로 완료되어야 하지만, PCIe 링크의 전송 속도는 초당 수십 기가바이트에 불과하기 때문입니다. 이를 시도하는 사람들이 있지만, NVMe에서 전문가 데이터를 스트리밍하면 초당 수십 개의 토큰을 생성해야 할 모델이 몇 초에 토큰 하나를 생성하는 수준으로 느려집니다.

결론적으로, 연산은 저렴하지만 저장에는 큰 비용이 듭니다. 하드웨어 규모는 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는 양자화 인식(quantisation aware) 방식으로 학습되었으며 MXFP4 가중치와 MXFP8 활성화 함수로 릴리스되었습니다. 따라서 4비트 행이 실제 사양입니다. 그 위의 행들은 비교를 위한 것입니다. bf16 형식이라면 동일한 모델에 5.6 TB가 필요합니다. MXFP4는 32개 가중치 블록마다 8비트 공유 스케일을 하나씩 저장하는데, 이는 약 6퍼센트의 용량을 추가합니다. 따라서 공개된 저장소의 용량은 순수한 1.4 TB보다는 1.5 TB에 더 가깝습니다.

이 사실은 흔히 사용하는 탈출구를 차단합니다. 릴리스된 체크포인트가 이미 4비트이므로 "그냥 양자화하면 된다"는 해결책은 통하지 않습니다. 2비트로 낮추면 가중치 용량은 0.7 TB가 되겠지만, 이 체크포인트에서 아무도 측정해 본 적 없는 정확도 손실이 발생합니다. 여전히 단일 카드로는 감당할 수 없는 수준입니다.

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 캐시, 활성화 버퍼, 할당자 파편화, 그리고 두 번째 동시 요청을 위한 여유 공간은 포함하지 않습니다. 또한 93개의 레이어와 896개의 전문가 모델이 항상 균등하게 나누어지지 않는다는 점을 고려하지 않은 병렬 분할을 가정합니다.

공개된 지침은 이 최소 사양보다 훨씬 높은 수준을 권장합니다. 2026년 8월 기준으로 Moonshot은 64개 이상의 가속기로 구성된 슈퍼노드를 권장하며, SGLang 쿡북은 8개 GPU 노드 4개, 총 32개의 GPU와 2,560 GB의 총 메모리로 구성된 H100 설정을 제공합니다. 이는 18 카드의 최소 사양과 대비됩니다. 이 격차는 낭비가 아닙니다. 이는 KV 캐시, 활성화 메모리, 그리고 서버가 한 번에 많은 요청을 처리할 수 있게 하는 여유 공간입니다. 가장 사양이 낮은 5 GB300급 카드조차도 대부분의 제공업체가 단일 SKU로 대여하지 않는 수준의 장비를 요구합니다.

KV 캐시는 사람들을 놀라게 하는 부분입니다

가중치는 고정 비용입니다. 하지만 KV(key value) 캐시는 그렇지 않습니다. 컨텍스트 길이에 따라 증가하며, 동시 접속 사용자가 늘어날 때마다 다시 증가합니다. 일반적인 어텐션의 공식은 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이며, 이는 단일 대화 하나를 위해 단일 카드가 수용할 수 있는 용량을 초과합니다.

K3는 일반적인 어텐션을 사용하지 않으며, 마지막 수치가 바로 그 이유입니다. K3의 93개 레이어는 69개의 KDA(Kimi Delta Attention) 레이어와 24개의 Gated MLA(multi-head latent attention) 레이어로 구성됩니다. KDA는 토큰마다 증가하는 캐시 대신 고정된 크기의 순환 상태를 유지하며, MLA는 키와 값을 하나의 낮은 랭크의 잠재 벡터로 압축합니다. 따라서 실제 토큰당 비용은 위 계산 예시보다 훨씬 낮아집니다. Moonshot은 잠재 차원을 공개하지 않았으므로, K3 자체에 대한 사용자당 수치는 기재하지 않겠습니다. 대신 직접 측정하십시오. 작은 --max-model-len으로 서버를 시작하고, nvidia-smi로 메모리를 모니터링한 다음, 할당이 실패할 때까지 제한을 높여보십시오.

추론의 형태는 다음 릴리스에서도 유지됩니다. 모델이 100만 토큰 컨텍스트를 광고하면서 어텐션 설계에 대해 아무런 언급이 없다면, 누군가 반증하기 전까지는 캐시가 제약 조건이라고 가정하십시오.

Tier 1: 시간 단위 클러스터 임대

이 티어는 K3를 직접 실행하는 유일한 방식입니다. 하드웨어를 구매하는 것이 아니라 필요한 시간만큼 임대하고 작업이 끝나면 중단합니다.

[
  {
    "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"
  }
]

제시된 요금은 추정치이며 확정된 견적이 아닙니다. 2026년 기준 데이터센터 가속기의 온디맨드 정가는 GPU 시간당 대략 2에서 5 USD 사이이며, 예약 용량은 더 저렴합니다. 제공업체의 실제 단가를 확인하여 GPU 개수, 시간, 단가를 곱해 계산하십시오. 이 차트의 핵심은 비율입니다. 8 GPU 노드를 하루 4시간씩 버스팅하면 월 2,400 USD가 소요되지만, SGLang 규모의 32 GPU 구성을 상시 가동하면 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를, 전문가 병렬 처리에 --ep-size을 사용하며, 이 두 값의 곱은 실제 보유한 GPU 개수와 일치해야 합니다.

실제 트래픽을 보내기 전에 서버가 정상적으로 올라왔는지 확인하십시오.

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 형태의 메시지를 출력하며 종료됩니다. 해당 레이어를 실행할 코드가 빌드에 포함되어 있지 않으므로 설정 변경으로는 해결할 수 없습니다. 모델 카드에 명시된 nightly 버전을 설치하거나 해당 기능이 포함된 릴리스를 기다리십시오.

비용과 관련하여 주의할 점이 있습니다. 인스턴스가 시작되는 순간부터 요금이 부과되며, 모델이 준비된 시점부터가 아닙니다. 1 GB/s 속도로 1.5 TB를 다운로드하면 첫 토큰이 생성되기까지 약 25분의 클러스터 시간이 소요됩니다. 인스턴스가 종료되어도 데이터가 유지되는 볼륨에 가중치를 저장해 두면, 두 번째 실행부터는 몇 분 내에 시작할 수 있습니다.

Tier 2: 단일 가속기에서 소형 모델 실행하기

이 단계에서는 K3를 실행하지 않습니다. 시작하기 전에 이 사실을 명확히 하십시오. "K3를 로컬에서 실행"하는 대부분의 논의는 이 사실을 인정하지 않은 채 끝납니다.

적합성 규칙은 축소된 형태에서도 동일한 공식을 따릅니다. 파라미터 수에 가중치당 바이트 수를 곱하고, KV 캐시와 약 2 GB의 런타임 오버헤드를 더한 값이 VRAM 용량보다 작아야 합니다. 4-bit 양자화 시 파라미터당 대략 0.5 바이트가 소요되므로 다음과 같은 조합이 적절합니다.

• 16 GB 카드: 4-bit 7B 모델 (긴 컨텍스트를 위한 여유 공간 포함)
• 24 GB 카드: 4-bit 14B 모델
• 48 GB 카드: 4-bit 32B 모델
• 80 GB 카드: 4-bit 70B 모델 또는 8-bit 30B급 MoE 모델

Ollama는 GPU가 장착된 VPS에서 서버를 가장 빠르게 구축하는 방법입니다.

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run는 처음 실행 시 모델을 다운로드한 뒤 프롬프트로 진입합니다. 존재하지 않는 태그를 입력하면 Error: model "..." not found 오류가 발생하므로, 기억에 의존해 입력하기보다 라이브러리 페이지에서 태그를 복사하십시오. systemd 유닛 설정과 원격 접속을 포함한 전체 과정은 Ollama를 VPS에서 실행하기에서 확인할 수 있습니다.

llama.cpp를 사용하면 양자화와 오프로드에 대해 더 많은 제어권을 가질 수 있습니다.

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은 모든 레이어를 GPU에 할당하도록 요청합니다. 로드 로그를 확인하여 실제로 몇 개의 레이어가 오프로드되었는지 확인하십시오. 시스템 RAM으로 넘어간 레이어는 HBM 대역폭이 아닌 RAM 대역폭으로 동작하므로, 모델이 VRAM을 초과하는 순간 생성 속도가 10배 이상 급격히 떨어집니다. 두 도구 간의 장단점은 Ollama와 llama.cpp 비교에서 다룹니다.

Tier 3: 호스팅된 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와 호환되므로, 기존 클라이언트의 base 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."}]}'

정상적인 키를 사용하면 choices 배열을 포함한 JSON 객체가 반환됩니다. 401 오류는 키가 잘못되었거나 Bearer 접두사가 누락되었음을 의미합니다. 모델을 찾을 수 없다는 오류는 보통 모델 ID가 변경되었을 때 발생하는데, 이는 제공업체가 체크포인트 사이에 ID를 폐기하기 때문입니다.

앞서 가정한 대여 비용을 기준으로 손익분기점을 계산해 보겠습니다. 8개의 GPU를 탑재한 노드를 상시 가동할 경우 월 14,400 USD가 소요됩니다. 출력 토큰 100만 개당 15.00 USD인 API 가격을 적용하면, 같은 비용으로 약 9억 6천만 개의 출력 토큰을 얻을 수 있습니다. 비용 효율을 높이려면 한 달에 거의 10억 개의 출력 토큰, 즉 하루에 약 3천만 개를 생성해야 합니다. 또한 GPU는 유휴 상태일 때도 동일한 비용이 청구되므로 클러스터를 쉬지 않고 가동해야 합니다. 프롬프트 비중이 높은 에이전트 워크로드는 손익분기점을 더욱 멀어지게 합니다. 반복되는 컨텍스트는 캐시 미스 시 발생하는 3.00 USD가 아닌, 캐시 히트 시의 0.30 USD 요금이 적용되기 때문입니다.

이 계층에서 직접 호스팅하는 것은 모델을 둘러싼 모든 요소입니다. API 키를 보관하여 클라이언트에 노출되지 않게 하는 게이트웨이, 요청 및 응답 로그, 재시도, 속도 제한, 사용자별 예산 관리 등이 포함됩니다. 이는 GPU가 없는 소형 VPS에서 실행할 수 있습니다. 이러한 분리 방식은 폐쇄형 가중치 모델에도 동일하게 적용됩니다. Claude 자체 호스팅은 모델 수준에서는 불가능하므로, 오케스트레이션 계층만 직접 관리할 수 있습니다.

어떤 서빙 스택이 어떤 계층에 속하는가

vLLM 및 SGLang 클래스 서버는 계층 1에 속합니다. 이들은 연속 배치(continuous batching)와 페이징된 KV 캐시, 그리고 여러 노드에 걸친 텐서 및 전문가 병렬 처리를 통해 한 번에 많은 요청을 처리하기 위해 존재합니다. 이들은 데이터 센터용 가속기와 노드 간의 빠른 인터커넥트를 전제로 합니다. 단일 소비자용 그래픽 카드에서는 설치가 더 복잡하며, 얻을 수 있는 이점도 거의 체감하기 어렵습니다.

llama.cpp 및 Ollama는 계층 2에 속합니다. 이들은 단일 머신, GGUF 양자화, 모델이 메모리에 맞지 않을 경우의 CPU 오프로드, 그리고 낮은 동시성을 목표로 합니다. 기술적으로 llama.cpp는 대부분의 레이어를 시스템 RAM에 유지함으로써 거대한 MoE 모델을 로드할 수 있지만, 2.8T 모델의 경우 토큰당 처리 시간은 초 단위로 측정됩니다. 이는 파일이 파싱됨을 증명할 뿐, 실제 사용자를 수용할 수 있는 서비스는 아닙니다. 전체 비교는 Ollama와 vLLM 비교에 나와 있으며, 모델이 바뀌어도 이 기준은 변하지 않습니다. 핵심은 공유 하드웨어에서 다수의 사용자를 서비스하는지, 아니면 개인용 하드웨어에서 한 명의 사용자를 서비스하는지 여부입니다.

이 체크포인트를 넘어서는 네 가지 수치

1. 전체 파라미터 수에 가중치당 바이트 수를 곱하면 메모리 하한선이 결정됩니다. 이보다 적은 메모리로는 아무것도 실행할 수 없으며, 이미 4-bit로 릴리스된 모델의 경우 양자화 기법을 써도 이 수치를 크게 낮출 수 없습니다.
2. 활성 파라미터 수는 처리량 등급을 결정합니다. 104B가 활성화되는 2.8T MoE 모델은 104B 모델과 동일한 연산 성능을 보입니다.
3. 토큰당 KV 캐시 크기에 컨텍스트 길이와 동시성(concurrency)을 곱한 값은 가중치 비용을 지불한 이후에도 계속 증가하는 비용입니다.
4. 달러당 초당 토큰 처리량(Tokens per second per dollar)은 등급을 결정하는 유일한 수치입니다. 위의 모든 항목은 이 수치를 산출하기 위한 입력값입니다.

이 네 가지를 모든 릴리스에 적용하면 벤더 가이드를 열기 전에 올바른 답을 얻을 수 있습니다. 기록하는 모든 수치에는 날짜를 기입하십시오. 가격과 지원 아키텍처 목록은 K3 출시 후 2주 이내에 모두 변경되었으며, 이 페이지의 모든 수치는 2026년 7월에 게시된 기준입니다.

FAQ

Kimi K3를 단일 GPU에서 실행할 수 있습니까?

아니요. Moonshot이 배포하는 MXFP4 정밀도 기준 가중치 크기는 1.4 TB이며, 현재 판매 중인 가장 큰 단일 가속기의 용량은 288 GB입니다. MoE 모델은 비활성 전문가를 디스크에서 실시간으로 불러올 수 없습니다. 라우터가 토큰마다 임의의 전문가를 선택할 수 있는데, PCIe를 통한 데이터 호출은 토큰 처리 예산보다 훨씬 긴 시간이 소요되기 때문입니다. K3를 합리적으로 배포하려면 최소한 다중 GPU 노드가 필요하며, 공개된 구성 가이드는 32개 이상의 가속기를 사용합니다.

Kimi K3에는 어느 정도의 VRAM이 필요합니까?

가중치만 고려해도 1.4 TB가 필요하며, 이는 H100 80GB 카드 18개 또는 GB300급 카드 5개에 해당합니다. 여기에 KV 캐시와 활성화 메모리를 추가해야 합니다. 2026년 8월 기준 Moonshot은 64개 이상의 가속기를 권장하며, SGLang 쿡북에서는 2,560 GB의 총 메모리를 갖춘 32개 GPU H100 구성을 제시하고 있으므로, 가중치 수치는 최소 사양으로 간주해야 합니다.

양자화를 적용하면 Kimi K3를 단일 노드에 올릴 수 있습니까?

실용적이지 않습니다. 배포된 체크포인트는 이미 양자화 인식 학습(quantization-aware training)이 적용된 4-bit 모델이므로, 쉽게 확보할 수 있는 용량은 이미 최적화된 상태입니다. 2-bit로 다시 절반을 줄여도 가중치는 0.7 TB가 되어 여전히 가장 큰 카드 용량의 두 배가 넘으며, 이 모델에서 2-bit 적용 시 발생하는 정확도 손실은 측정된 바 없습니다.

GPU를 대여하는 것이 Kimi K3 API보다 저렴합니까?

사용량이 많고 일정할 때만 그렇습니다. GPU 시간당 2.50 USD라고 가정할 때, 8개 GPU 노드를 상시 가동하면 월 14,400 USD가 소요됩니다. 같은 비용으로 15.00 USD(백만 토큰당)라는 공개 요금제 기준 약 9억 6천만 토큰을 처리할 수 있습니다. 또한 유휴 시간 비용, 가중치 다운로드 비용, 클러스터 유지 관리 인력 비용도 고려해야 합니다. 일시적인 부하 처리는 시간 단위 대여를 이용하고, 추측이 아닌 실제 측정된 토큰 사용량을 기준으로 비교하십시오.

104B 활성 파라미터는 속도 측면에서 무엇을 의미합니까?

토큰당 연산량이 104B 모델 수준이라는 뜻이며, 따라서 처리량(throughput)도 2.8T급이 아닌 해당 클래스 수준으로 결정됩니다. 이는 메모리와는 무관합니다. 라우터가 토큰마다 어떤 전문가든 호출할 수 있으므로 2.8T 파라미터 전체가 상주해야 합니다. 초당 토큰 처리량(tokens per second)을 예측할 때는 활성 파라미터 수를, VRAM 크기를 산정할 때는 전체 파라미터 수를 사용하십시오.