Kimi K3는 셀프 호스팅 (Self-hosting)이 가능하지만, 공개된 체크포인트 (checkpoint) 크기가 약 1.56 TB이며 현재 vLLM 레시피 (recipe)는 8개의 하이엔드 GPU부터 시작합니다. 대부분의 팀에게 유용한 비교 대상은 토큰 가격 대 GPU 대여 비용이 아닙니다. 그것은 수락된 작업당 API 비용 대 신뢰할 수 있는 분산 배포 (distributed deployment)의 전체 비용입니다.

예/아니오 답변보다 계산기가 더 유용한 이유

Kimi K3는 오픈 웨이트 (open-weight), 2.8조 파라미터 규모의 전문가 혼합 (Mixture-of-Experts, MoE) 모델입니다. 토큰당 1,040억 개의 파라미터를 활성화하며, 896개의 라우팅된 전문가 중 16개를 선택하고, 최대 1,048,576 토큰의 컨텍스트 윈도우 (context window)를 지원합니다.

이러한 수치들은 셀프 호스팅을 가능하게 만들지만, 단순하지는 않습니다.

현재 vLLM 레시피는 8개의 NVIDIA GB300 GPU 또는 8개의 AMD MI355X/MI350X급 GPU로 시작하는 토폴로지 (topology)를 나열하고 있습니다. 실제 운영 트래픽을 위해서는 멀티 노드 (multi-node) 인프라를 권장합니다. Moonshot의 출시 자료는 더 높은 추론 효율성을 위해 64개 이상의 가속기 (accelerators)를 권장합니다.

이로 인해 대부분의 팀에게는 두 가지 현실적인 선택지가 남습니다:

1. 호스팅된 API로 시작하여 사용량에 따라 비용을 지불합니다.
2. 분산 GPU 클러스터 (distributed GPU cluster)를 운영하며, 사용 여부와 관계없이 용량에 대해 비용을 지불합니다.

올바른 선택은 트래픽, 캐시 재사용 (cache reuse), 출력 길이, 작업 수락률, 엔지니어링 비용 및 활용도에 따라 달라집니다. 아래의 Python 스크립트는 이러한 가정들을 명시적으로 유지합니다.

비용 모델에 포함되는 항목

호스팅 측에는 다음이 포함됩니다:

• 캐시 히트 (cache-hit) 입력 토큰;
• 캐시 미스 (cache-miss) 입력 토큰;
• 출력 토큰;
• 비용은 청구되었으나 애플리케이션에서 수락되지 않은 요청;
• 월간 요청 수.

셀프 호스팅 측에는 다음이 포함됩니다:

• 시간당 클러스터 비용;
• 월간 730개의 프로비저닝된 (provisioned) 시간;
• 플랫폼 및 추론 엔지니어링 (inference engineering);
• 네트워킹 및 스토리지;
• 관측성 (observability) 및 보안;
• 중복성 (redundancy) 및 유휴 헤드룸 (idle headroom).

출력 결과는 총 월간 비용과 수락된 작업당 비용을 모두 보고합니다.

전체 Python 계산기

이 예제는 Python 3.11 이상을 필요로 하며, 별도의 서드파티 패키지(third-party packages)가 필요하지 않습니다.

from dataclasses import dataclass

HOURS_PER_MONTH = 730
...

다음 명령어로 실행하세요:

python3 kimi_k3_tco.py

제공된 시나리오에 대해, 스크립트는 대략 다음과 같은 결과를 생성합니다:

Kimi K3 monthly cost model

Moonshot official API:
...

캐시 동작에 따라 더 저렴한 API가 달라지는 이유

2026년 7월 Moonshot이 발표한 Kimi K3 가격은 다음과 같습니다:

소스 패키지에 따르면 2026년 7월 28일 기준 CometAPI는 입력 토큰 100만 개당 $2.40, 출력 토큰 100만 개당 $12.00로 기록되어 있습니다.

이 스냅샷에서 CometAPI는 공식적인 캐시 미스 (cache-miss) 입력 및 출력 요율보다 낮습니다. 하지만 워크로드에 강력한 접두사 캐시 재사용 (prefix-cache reuse)이 있다고 해서 자동으로 더 저렴해지는 것은 아닙니다. Moonshot의 공식 캐시 히트 (cache-hit) 입력 요율이 훨씬 더 낮기 때문입니다.

이것이 계산기에서 캐시 히트 비율 (cache-hit ratio)을 입력받는 이유입니다. 특정 가격 행 하나를 정답으로 간주하기보다는, cache_hit_ratio를 0.50에서 귀하의 애플리케이션에서 측정된 값으로 변경하여 사용하십시오.

의사 결정에 CometAPI 가격을 사용하기 전에, Kimi K3 실시간 모델 페이지를 확인하십시오. 가격과 가용성은 시간에 따라 변동될 수 있습니다.

8개 GPU 시나리오에서 여전히 누락된 부분

8개 GPU 추정치는 계획을 위한 최저 기준선(floor)일 뿐, 프로덕션 준비 완료(production readiness)를 증명하는 것은 아닙니다.

Kimi K3는 전문가(experts) 전반에 걸쳐 토큰을 라우팅하며, 이는 올투올(all-to-all) 통신을 생성합니다. 동일한 명목상의 GPU 개수라도 NVLink, RDMA, 네트워크 토폴로지 (network topology), 전문가 병렬화 (expert parallelism), 프리필/디코드 분리 (prefill/decode separation), 그리고 동시성 (concurrency)에 따라 서로 다른 처리량 (throughput)을 낼 수 있습니다.

본격적인 셀프 호스팅 테스트에는 다음 사항도 포함되어야 합니다:

• 모델 다운로드 및 시작 시간 (model download and startup time);
• 스토리지 복제 및 복구 (storage replication and recovery);
• 실제로 사용되는 컨텍스트 길이 (context lengths)를 위한 KV-캐시 (KV-cache) 메모리;
• 배포 롤백 (deployment rollback) 및 가중치 업그레이드 (weight upgrades);
• 노드 장애 (node failure) 및 성능 저하된 클러스터 동작 (degraded-cluster behavior);
• 도구 호출 (tool-call) 검증 및 재시도 (retries);
• 트래픽 급증 (traffic bursts)을 위해 예약된 용량;
• 엔지니어링 온콜 (on-call) 대응 범위.

기본적으로 이론적인 최대 컨텍스트 (theoretical maximum context)를 사용하지 마십시오. 긴 프롬프트 (long prompts)는 프리필 (prefill) 작업, KV-캐시 (KV-cache) 요구량, 지연 시간 (latency), 그리고 동시 요청에 사용할 수 없는 용량을 증가시킵니다.

셀프 호스팅이 신뢰할 만해지는 시점

다음 조건 중 적어도 하나가 충족될 때 셀프 호스팅에 대한 부하 테스트 (load test)를 수행할 가치가 있습니다:

1. 수요가 지속적이고 예측 가능하여 클러스터를 생산적으로 가동할 수 있을 때.
2. 조직이 이미 분산 MoE 추론 (distributed MoE inference) 및 고대역폭 GPU 네트워킹 (high-bandwidth GPU networking)을 운영하고 있을 때.
3. 데이터 경로 제어 (data-path control) 또는 전용 환경이 필수 요구 사항일 때.
4. 팀이 모델 버전, 런타임 구성 (runtime configuration), 또는 미세 조정된 가중치 (fine-tuned weights)에 대해 직접적인 제어가 필요할 때.
5. 측정된 호스팅 비용이 그에 상응하는 신뢰할 수 있는 내부 서비스의 전체 비용에 근접할 때.

새롭거나 가변적인 트래픽의 경우, 일반적으로 API가 더 안전한 기준점 (baseline)이 됩니다. API는 하드웨어 확정 전, 팀에게 실제 토큰 (token), 캐시 (cache), 지연 시간 (latency), 재시도 (retry) 및 수락 (acceptance) 데이터를 제공합니다.

핵심 요약

• Kimi K3의 오픈 웨이트 (open weights)는 배포의 자유를 제공하는 것이지, 저비용 로컬 설정을 의미하는 것이 아닙니다.
• 현재 서빙 하한선 (serving floor)은 8개의 하이엔드 GPU부터 시작됩니다. 효율적인 프로덕션 환경을 위해서는 훨씬 더 큰 토폴로지 (topology)가 필요할 수 있습니다.
• 접두사 캐시 재사용 (Prefix-cache reuse)에 따라 어떤 호스팅 경로가 더 저렴할지가 달라질 수 있습니다.
• 단순한 토큰 가격이나 GPU 임대료가 아닌, 수락된 작업당 비용 (cost per accepted task)을 비교하십시오.
• 프로덕션 형태의 부하 테스트 (load test)를 통해 전체 TCO (총 소유 비용) 사례가 입증된 후에만 인프라를 구매하십시오.