Kimi K3 API 가격 실측: '상시 켜짐' 추론을 꺼보자

Kimi K3 문서에는 추론을 끌 수 없고 reasoning_effort는 "max"만 받는다고 적혀 있다. 하지만 실측해 보니 API는 "none"도 받아들이고, 실제로 동작한다. 기본 추론으로 $0.00179 드는 똑같은 사소한 질문이 추론을 끄면 $0.000285로 줄어든다. 6.3배 차이다. K3는 2026-07-16에 입력 100만 토큰당 $3、출력 100만 토큰당 $15로 출시됐다. 중국 연구소가 내놓은 가장 비싼 정가이자 Claude Sonnet 5 와 같은 값이다. 이 출력 단가에서는 모델이 기본값으로 소모하는 추론 토큰이 곧 청구액이 된다. 그러니 문서에 없는 이 off 스위치를 정확히 이해할 가치가 있다.

TL;DR

• Kimi K3 는 기본 설정에서 출력 토큰의 69~93%를 추론에 쓴다. 120 단어짜리 문단 하나에 출력 토큰 2,289 개、$0.0346 가 청구됐다.
• 문서와 달리 reasoning_effort: "none"이 받아들여지고, 단순 질의 비용을 6.3배 줄였다. 다만 다단계 산술 문제는 정답률이 3/3 에서 0/6 으로 떨어졌다.
• Kimi K3 의 prompt cache 는 대략 prefix 256 토큰부터 히트하며, 256 토큰 단위로 끊고, 읽기 요율은 $0.30/M 이다.
• 중국어는 K3 의 CJK 언어 중 가장 저렴하다. 100 자당 순 52 토큰으로, GLM-5.2 와 DeepSeek 의 58 보다 낮다.

아래 내용은 모두 2026-07-20 에 kimi-k3 를 대상으로 실측했다. 이 모델은 Synthorai 게이트웨이에서 Moonshot 정가로 서비스되고 있다. 응답 캐시를 피하려고 프롬프트마다 salt 를 넣어 반복 요청했고, 동작 관련 주장은 별도의 독립된 요청 경로에서 교차 확인했다. 모든 수치는 실제 usage 기록으로 뒷받침된다.

Kimi K3 는 기본 설정에서 답변 하나당 얼마가 드나?

우리가 보낸 모든 형태의 작업에서 reasoning 이 비용의 대부분을 차지했다. reasoning 이 전혀 필요 없는 작업도 마찬가지였다. 기본 설정 기준으로 답변 하나당 비용은 다음과 같다.

이 차트의 핵심은 모델 간 대비다. GPT-5.6 은 상황에 맞춰 reasoning 을 조절한다 (간단한 질문과 사실 질문에서는 thinking token 이 0, 수학과 글쓰기에서는 65-70%). Claude Sonnet 5 는 thinking 이 꺼진 상태로 출시됐다. GLM-5.2 는 상대적으로 K3 보다도 더 많이 reasoning 한다. 하지만 GLM 의 출력 가격은 $4.40/M, K3 는 $15/M 이다. 그래서 똑같은 17×23 답변이 GLM-5.2 에서는 $0.00078, GPT-5.6 에서는 $0.00027, Sonnet 5 에서는 $0.0001, K3 에서는 $0.0018 로 청구됐다. 출력 길이가 길어질수록 격차는 벌어진다. 동일한 120 단어 문단이 K3 에서는 $0.0346 인데 GLM-5.2 에서는 $0.0186, GPT-5.6 에서는 $0.0072, Sonnet 5 에서는 $0.0024 였다. 이 세트에서 가장 평범한 작업에서 15 배 차이가 난다. 세율은 다른 중국 reasoning 모델과 비슷하지만, 실제 세금 액수는 그렇지 않다.

기본 모드에서 예산에 넣어둘 만한 사실이 두 가지 더 있다. 첫째, thinking 모드는 모든 요청에 약 67 token 짜리 숨은 preamble 을 끼워 넣는다. 한 단어짜리 동일한 메시지가 reasoning 을 켜면 86 prompt token, 끄면 19 token 으로 청구됐다. 초기 테스터들이 발견한 “숨은 system prompt” 가 이것이며, reasoning 이 사라지면 함께 사라진다. 둘째, 현재 K3 는 느리다. 간단한 질문 호출이 reasoning 을 켜면 처음부터 끝까지 대략 19-24 초, 끄면 3-8 초 걸렸다. 출시 주간의 서빙 상황이 포함된 수치다. 비용뿐 아니라 지연 시간도 예산에 반영하라.

Kimi K3 의 reasoning 을 끌 수 있나?

문서와 다르게, 가능하다. 공식 API 레퍼런스에는 K3 가 “항상 thinking 을 활성화”하며 reasoning_effort 는 "max" 만 받는다고 나와 있다. 하지만 실제로는 "none", "low", "medium", "high" 를 모두 오류 없이 받아들였고, 그 값대로 동작했다. 별도의 요청 경로에서도 같은 동작을 확인했다. 여러 단계로 이뤄진 문장제 문제로 테스트해 보니 이 조절 값은 실제로 작동하지만 세밀하지는 않다.

눈에 띄는 점이 두 가지 있다. 중간 설정값들은 서로 비슷하게 뭉친다. 이 작업에서는 low 부터 max 까지 토큰 수가 비슷했고 정확도도 똑같았다. 결국 의미 있는 스위치는 켜냐 끄냐, 둘뿐이다. 그리고 none 에는 확실한 절벽이 있다. 여러 단계가 필요한 산술 문제를 짧게 답하도록 강제하니 K3 는 여섯 번 모두 틀렸는데, 하나의 체계적 오류가 아니라 답이 제각각 흩어진 형태였다. 짧게 답하도록 강제하지 않으면 모델이 간결함을 무시하고 눈에 보이는 답 안에서 단계를 하나하나 풀어내기도 했다. 답은 맞았지만 토큰이 사라진 게 아니라 reasoning 필드에서 text 필드로 옮겨간 것뿐이다.

지연 시간은 토큰 수가 시사하는 것만큼 크게 달라지지 않는다. 같은 문제를 모든 effort 레벨에서 streaming 으로 돌려 보니 first-byte 시간은 6-24 초였고, 레벨별 범위가 서로 크게 겹쳤다. 생각할 게 전혀 없는 none 조차 12-13 초를 기다렸다. 이 정도 크기의 작업에서는 first token 까지의 시간을 서빙이 좌우한다는 뜻이다. 이 조절 값이 실제로 바꾸는 것은 first byte 와 첫 답변 토큰 사이의 간격, 즉 사용자가 앉아서 기다리는 thinking 단계다.

실용적으로 정리하면 이렇다. none 은 검색, 포매팅, 단일 단계 작업에서는 진짜 비용 절감 수단이지만, 중간 단계가 필요한 작업에서는 자기 발등을 찍는 도구다. 이 파라미터가 계속 동작한다는 보장은 문서 어디에도 없다. 측정된 동작으로만 취급하고, 자기 usage 필드에서 직접 검증하고, 문서가 현실을 따라잡을 때 이 동작이 정식 지원되거나 제거될 수 있다는 점을 염두에 두자.

에이전트 워크로드에서 reasoning 은 언제 켜 둬야 하나?

K3 를 에이전트 형태의 시나리오 다섯 개에서 두 번씩 돌렸다. 기본값과 reasoning_effort: "none" 을 비교했고, 두 설정 모두 온전히 통과한 동일한 단순 작업을 사용했다.

의외인 건 첫 번째 행이다. 도구 호출 루프에서는 K3 가 기본 설정에서도 거의 생각을 안 한다 (비중 8%). 그러니 절약할 게 거의 없다. 모델은 도구 선택을 숙고가 아니라 반사 행동처럼 처리한다. 절감 효과는 thinking 비중이 높고 작업이 기계적인 곳(RAG 조회, 배치 추출)에 몰린다. 정작 항상 켜져 있는 고정 세금이 가장 어울리지 않는 곳이 바로 여기다. 진짜로 여러 단계를 거치는 에이전트 계획이라면 앞 절의 정확도 절벽이 그대로 적용된다. reasoning 을 켜 두고 토큰을 쓰자.

단일 호출은 노이즈가 크지만 규모가 커지면 지연 시간 효과는 실제로 나타난다. 이 시나리오들 전체에서 first token 은 기본 설정일 때 10-19 초, none 일 때 8-13 초에 도착했고, 의미 있는 출력에서는 생성 속도가 중앙값 초당 35 토큰이었다. 출시 첫 주의 서빙까지 포함한 이 수치는 오늘날 어떤 대화형 용도보다 비동기와 배치 형태에 더 잘 맞는다.

되돌려 보낸 reasoning 이 다시 input 으로 과금되나요?

그렇습니다. token 단위 그대로 다시 과금됩니다. Kimi 문서는 모든 assistant turn 의 reasoning_content 를 수정하지 않고 메시지 히스토리에 그대로 유지하라고 안내합니다. 이게 비용에 어떻게 반영되는지 측정해 봤습니다. 첫 turn 의 chain of thought 를 포함해 두 번째 turn 을 보내니 prompt token 이 599개 과금됐고, 이걸 뺀 동일한 요청은 198개가 과금됐습니다. 401 token 의 차이는 첫 turn 의 reasoning token 402개와 거의 정확히 일치합니다. 즉 유지된 thinking 은 이후 모든 요청에 $3/M 의 full input rate 로 다시 들어가고, 긴 대화에서는 매 turn 마다 누적된 reasoning 을 다시 지불하게 됩니다.

그렇다고 이걸 버리는 게 무조건 더 싼 건 아닙니다. 이전 chain of thought 가 없으면 K3 는 후속 turn 을 처음부터 다시 추론했습니다. 두 번째 turn 의 reasoning token 이 31% 증가했습니다 (343 → 449). input $3/M 대 output $15/M 라는 요율에서, 우리 실험에서는 CoT 를 유지하는 쪽이 결과적으로 더 저렴했습니다. 즉 문서의 조언은 품질뿐 아니라 비용 측면에서도 맞습니다. 여기서 실제로 이득을 주는 지렛대는 다음 절에서 다룰 prompt cache 입니다. 유지된 히스토리는 안정적인 prefix 이고, 안정적인 prefix 는 full price 로 과금되지 않기 때문입니다.

Kimi K3 는 prompt 를 캐싱하나요? 몇 token 부터인가요?

K3 의 prompt cache 는 자동이고, 시작 기준이 낮습니다. hit 은 공유 prefix 가 약 256 token 부터 발생했고 256 token 블록 단위로 늘어났습니다 (303 token prompt 는 256개가 캐싱됐고, 153 token prompt 는 반복 시도에도 한 번도 캐싱되지 않았습니다). 캐싱된 input 은 $0.30/M 로 과금되어 $3/M 의 fresh rate 대비 정확히 90% 할인이며, 우리가 보낸 어떤 호출에도 cache-write 추가 요금은 없었습니다. warm-up 은 첫 hit 이 나오기까지 동일한 호출이 2~5회 필요했으니, 재시도 한 번으로는 어느 쪽도 증명되지 않습니다. 여러 번에 걸쳐 측정하세요.

참고로 이 기준값은 OpenAI 가 문서에 명시한 1,024 token 최소치의 4분의 1이고, 블록 크기는 다른 곳에서 측정한 64 token 단위보다 거칩니다. 수명은 고정된 TTL 이 아니라 best-effort 방식입니다. 우리 실험에서 캐싱된 항목은 4분, 15분의 유휴 간격은 살아남았지만 8분 간격 하나는 miss 났습니다. 만료를 부하에 따른 eviction 으로 보고, 매 호출마다 캐시 분할을 확인하세요. 계산해 볼 만한 가격 사실이 하나 더 있습니다. 1M token context window 는 정액제로, 가격표에 long-context 등급이 따로 없습니다. window 를 꽉 채우면 호출당 fresh input 이 $3.00이고, prefix 가 warm 상태면 $0.30입니다. 그래서 대용량 context 워크로드의 성패는 정가표보다 캐시에 훨씬 크게 좌우됩니다. 트래픽이 몇백 token짜리 system prompt 라도 재사용한다면, 대부분의 provider 라면 아직 시작도 못 했을 지점에서 K3 의 캐시가 작동합니다. 동작 방식과 usage 에서 hit 을 확인하는 방법은 prompt caching 가이드 와 측정한 캐시 최소치 연구에서 다룹니다.

Kimi K3 에서 중국어가 실제로 더 비싼가？

아니다。 K3 의 tokenizer 는 경쟁 모델과 비교했을 때 중국어에서 가장 효율적이다。 출시 첫 주 논의에서 반복적으로 나온 질문에 대한 답이 여기 있다。 의미가 대응되는 문단을 기준으로 100 자당 순수 token 수이며，envelope overhead 는 제외했다：

K3 는 중국어를 100 자당 52 token 으로 청구한다。 GLM-5.2 와 DeepSeek 보다 11% 낮고，Sonnet 5 의 절반에도 못 미친다。 약점은 일본어인데，다른 open-weight 모델보다 16~24% 더 낸다。 tokenizer 가 제품군 전체에서 동일하다는 것도 확인했다。 K3、K2.7-code、K2.5 는 23 개의 대응 샘플 전부에서 동일한 token 수를 냈으므로，K2 용으로 만든 언어별 예산을 그대로 쓸 수 있다。 tokenizer 밀도가 9 개 언어에서 token 당 가격과 어떻게 맞물리는지는 언어별 가장 저렴한 LLM 연구에서 다룬다。

FAQ

Kimi K3 의 open weight 는 언제 공개되나？

Moonshot 은 2026 년 7 월 27 일까지 Modified MIT 라이선스로 전체 가중치를 공개하겠다고 약속했다。 이 글을 쓰는 시점에 K3 는 API 로만 제공된다。 “역대 최대 open-weight 모델” 이라는 표현은 아직 다운로드 링크가 아니라 약속일 뿐이다。 이 가중치가 합류할 open-weight 생태계에서 캐싱이 어떻게 동작하는지는 open-weight LLM 을 위한 prompt caching 에 정리되어 있다。

K2 제품군과 비교해 K3 에서 실제로 새로운 것은 무엇인가？

청구서 기준으로 우리가 측정한 것은 세 가지다。 가격（K3 는 $3/$15 로，$0.95/$4 인 K2.7-code 대비 3.2~3.75 배），상시 thinking（K2.5 는 아예 추론하지 않고，K2.7-code 는 토글이 있다），그리고 그 외에는 없다。 tokenizer 는 23 개 대응 샘플 전부에서 K3、K2.7-code、K2.5 가 byte 단위로 동일하므로，K2 시절 token 예산을 그대로 가져올 수 있다。 스펙 시트상 Moonshot 에 따르면，Kimi Delta Attention 을 적용한 새로운 2.8T 파라미터 MoE（896 개 expert，token 당 16 개 활성），K2.7-code 의 256K 에 맞선 1M token context window，그리고 native 이미지 입력이다。 우리는 아키텍처 주장이 아니라 청구 관련 주장을 측정했다。

Kimi K3 는 structured output 을 지원하나？

지원한다。 json_schema 를 넣은 response_format 는 우리 테스트에서 스키마를 준수하는 유효한 객체를 반환했다。 다만 추론은 여전히 밑에서 돌아간다。 해당 추출 호출의 출력 token 97 개 중 66 개가 reasoning 이었다。 그래서 reasoning_effort: "none" 을 함께 설정하지 않는 한，스키마로 제약한 호출도 다른 호출과 마찬가지로 thinking 비용을 낸다。

추론을 끄면 볼 수 있는 것이 달라지나？

달라진다。 기본 설정에서 K3 는 전체 chain of thought 를 reasoning_content 에 반환하며，문서는 멀티턴 히스토리에서 이를 수정 없이 그대로 돌려보내라고 권한다。 reasoning_effort: "none" 을 쓰면 이 필드가 아예 사라지고，약 67 token 짜리 thinking 서두도 함께 prompt 청구에서 빠진다。

2026-07-20 에 출시 첫 주 정가（입력 $3/M，캐시 $0.30/M，출력 $15/M）로 kimi-k3 에서 측정했다。 반복 prompt 는 응답 수준 캐시를 피하려고 salt 를 넣었고，정확도 집계는 확인 가능한 단일 정답이 있는 작업만 사용했으며，동작 관련 주장은 두 번째 독립 요청 경로에서 재현했다。 릴리스가 성숙하면서 가격과 동작은 바뀔 수 있으니，여기 있는 수치에 의존하기 전에 본인의 usage 기록으로 검증하라。

← 블로그로 돌아가기