Kimi K3 API 요금 실측: '항상 켜지는' reasoning 끄기

Kimi K3 문서에는 thinking을 끌 수 없고, reasoning_effort에는 "max"만 지정할 수 있다고 되어 있다. 하지만 실제로 측정해 보니 API는 "none"도 허용하며 제대로 동작했다. 같은 간단한 질문의 비용이 기본 reasoning에서는 $0.00179였지만, reasoning을 끄면 $0.000285로 줄었다. 6.3배 차이다. K3는 2026-07-16에 input token 100만 개당 $3, output token 100만 개당 $15로 출시됐다. 중국 연구소가 내놓은 모델 중 가장 비싼 정가이며 Claude Sonnet 5와 같은 가격이다. 이 정도 output 단가에서는 모델이 기본으로 사용하는 reasoning token 자체가 비용의 대부분을 차지한다. 따라서 문서에 없는 비활성화 옵션이 정확히 어떻게 동작하는지 알아둘 필요가 있다.

TL;DR

• Kimi K3는 기본 설정에서 output token의 69-93%를 reasoning에 사용한다. 120단어 문단 하나에 output token 2,289개가 청구됐고 비용은 $0.0346이었다.
• 문서 내용과 달리 reasoning_effort: "none"이 허용됐으며, 단순 질의 비용을 6분의 1로 줄였다. 다만 여러 단계의 산술 문제 정답률은 3/3에서 0/6으로 떨어졌다.
• Kimi K3의 prompt cache는 약 256 token의 prefix부터 적중하며, 256-token block 단위로 동작한다. cache read 요금은 $0.30/M이다.
• CJK 중에서는 중국어가 K3에서 가장 저렴하다. 100자당 순수 token 수가 52개로, 58개인 GLM-5.2와 DeepSeek보다 적다.

아래 결과는 모두 2026-07-20에 kimi-k3를 대상으로 측정했다. 이 모델은 Synthorai gateway에서 Moonshot 정가로 제공되고 있다. 반복 prompt에는 salt를 추가해 response cache를 우회했고, 동작 관련 결과는 별도의 독립적인 요청 경로에서도 재확인했다. 모든 수치는 원본 usage 기록으로 검증할 수 있다.

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

reasoning이 전혀 필요 없는 작업을 포함해, 테스트한 모든 작업 유형에서 비용의 대부분은 reasoning이 차지했다. 기본 설정에서 답변 하나당 결과는 다음과 같다.

이 차트의 핵심은 모델별 차이다. GPT-5.6은 필요에 따라 reasoning을 조절한다. 간단한 질문과 사실 확인 질문에는 thinking token을 사용하지 않았고, 수학과 글쓰기에는 65-70%를 사용했다. Claude Sonnet 5는 thinking이 꺼진 상태로 제공되며, GLM-5.2는 비율상 K3보다도 reasoning을 더 많이 한다. 하지만 GLM의 output 요금은 $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이 청구됐다. output이 길어지면 격차는 더 커진다. 동일한 120단어 문단의 비용은 K3가 $0.0346, GLM-5.2가 $0.0186, GPT-5.6이 $0.0072, Sonnet 5가 $0.0024였다. 테스트 중 가장 평범한 작업에서 15배 차이가 났다. reasoning token의 비율은 다른 중국 reasoning 모델과 비슷하지만, 실제 청구액은 그렇지 않다.

기본 모드에서 예산에 반영해야 할 사실이 두 가지 더 있다. 첫째, thinking mode는 모든 요청에 약 67 token의 숨겨진 preamble을 넣는다. 동일한 한 단어 메시지에 reasoning을 켰을 때는 prompt token 86개, 껐을 때는 19개가 청구됐다. 초기 테스터들이 발견한 “hidden system prompt”가 이것이며, reasoning을 끄면 함께 사라진다. 둘째, 현재 K3는 느리다. 출시 첫 주의 serving 상태를 포함해, 간단한 질문도 reasoning을 켜면 요청부터 완료까지 약 19-24초, 끄면 3-8초가 걸렸다. 비용뿐 아니라 latency도 예산에 넣어야 한다.

Kimi K3의 reasoning을 끌 수 있나?

문서와 달리 끌 수 있다. 공식 API 레퍼런스에는 K3가 “항상 thinking을 활성화”하며 reasoning_effort에는 "max"만 지정할 수 있다고 적혀 있다. 실제 endpoint는 "none", "low", "medium", "high"를 모두 오류 없이 허용했고, 설정도 반영했다. 별도의 독립적인 요청 경로에서도 같은 동작을 확인했다. 여러 단계의 문장형 문제에서 이 설정은 실제로 동작했지만 단계 구분은 거칠었다.

두 가지가 눈에 띈다. 먼저 중간 설정끼리는 결과가 비슷하다. low부터 max까지 사용한 token 수가 비슷했고 이 작업의 정확도도 같았다. 실질적으로 의미 있는 선택지는 켜기와 끄기다. 그리고 none에서는 성능이 급격히 떨어졌다. K3에 여러 단계의 산술 문제를 짧게 답하도록 강제하자 6번 모두 틀렸다. 오답도 한 가지 유형으로 일관되지 않고 제각각이었다. 짧은 형식을 강제하지 않으면 모델이 간결성 지시를 무시하고 답변에 풀이 단계를 직접 쓰기도 했다. 이 경우 정답은 맞았지만, token이 사라진 것이 아니라 reasoning field에서 text field로 옮겨갔다.

latency 차이는 token 수만큼 크지 않다. 같은 문제를 effort 단계별로 streaming했을 때 첫 byte까지 걸린 시간은 6-24초였고, 각 단계의 범위가 상당 부분 겹쳤다. 생각할 내용이 없는 none조차 12-13초를 기다렸다. 이 정도 작업에서는 serving이 첫 token 도착 시간에 더 큰 영향을 준다. 이 설정이 실제로 바꾸는 것은 첫 byte와 첫 answer token 사이의 시간이다. 사용자가 기다리는 thinking 단계에 해당한다.

실무에서는 retrieval, formatting, 단일 단계 작업에 none을 적용하면 비용을 확실히 줄일 수 있다. 중간 단계가 필요한 작업에는 위험한 설정이다. 이 parameter가 계속 동작한다는 문서상의 보장은 없다. 현재 실측된 동작으로만 보고, 자체 usage field에서 검증해야 한다. 문서가 실제 동작을 따라잡는 과정에서 정식 기능이 되거나 제거될 수 있다.

Agent workload에서는 언제 reasoning을 켜 둬야 하나?

agent 형태의 시나리오 5개를 K3로 각각 두 번 실행했다. 기본 설정과 reasoning_effort: "none"을 비교했으며, 두 설정 모두 동일한 단순 작업을 전부 통과했다.

첫 번째 행은 예상 밖이었다. tool-call loop에서는 기본 설정에서도 K3가 reasoning을 거의 하지 않아 비중이 8%에 불과했다. 따라서 절감할 부분도 적다. 모델은 tool 선택을 숙고가 아니라 즉각적인 판단으로 처리한다. 절감 효과는 thinking 비중이 높으면서 기계적인 작업인 RAG lookup과 batch extraction에 집중됐다. 고정된 항상 켜짐 비용이 가장 불필요한 영역이다. 실제로 여러 단계의 계획이 필요한 agent에서는 앞 절의 정확도 급락이 그대로 적용된다. reasoning을 켜고 필요한 token을 쓰는 편이 낫다.

개별 호출에서는 편차가 크지만, 규모가 커지면 latency 차이가 분명해진다. 이 시나리오들에서 기본 설정은 첫 token이 도착하기까지 10-19초, none은 8-13초가 걸렸다. 유의미한 길이의 output에서는 생성 속도의 중앙값이 초당 35 token이었다. 출시 첫 주의 serving 상태까지 감안하면, 현재 이 수치는 대화형 서비스보다 asynchronous 작업과 batch 작업에 더 적합하다.

이전 reasoning을 다시 보내면 input으로 재청구되나?

token 단위로 그대로 재청구된다. Kimi 문서는 assistant turn마다 받은 reasoning_content를 수정하지 않고 message history에 유지하라고 안내한다. 그 비용을 측정해 봤다. 첫 turn의 chain of thought를 포함해 두 번째 turn을 보내자 prompt token 599개가 청구됐다. 이를 제외한 동일 요청은 198개였다. 401-token 차이는 첫 turn의 reasoning token 402개와 거의 정확히 일치한다. 유지한 thinking은 이후 모든 요청에서 $3/M의 전체 input 요금으로 다시 들어간다. 대화가 길어질수록 누적된 reasoning 비용을 매 turn마다 다시 지불하게 된다.

그렇다고 reasoning을 빼는 편이 항상 저렴하지는 않다. 이전 chain of thought가 없으면 K3가 후속 질문을 처음부터 다시 추론했다. 두 번째 turn의 reasoning token은 343개에서 449개로 31% 늘었다. input은 $3/M, output은 $15/M이므로 이번 측정에서는 CoT를 유지하는 편이 총비용이 더 낮았다. 문서의 권장 방식은 품질뿐 아니라 비용 면에서도 타당하다. 여기서 실질적인 절감 효과를 내는 수단은 다음 절의 prompt cache다. 유지되는 history는 안정적인 prefix이며, 안정적인 prefix에는 더 이상 전체 요금이 청구되지 않는다.

Kimi K3는 prompt를 cache하나? 최소 token 수는 얼마인가?

K3의 prompt cache는 자동으로 동작하며 하한선도 낮다. 공유 prefix가 약 256 token일 때부터 cache hit가 발생했고, 256-token block 단위로 늘어났다. 303-token prompt에서는 256개가 cache됐지만, 153-token prompt는 반복 요청에서도 한 번도 cache되지 않았다. cached input 요금은 $0.30/M으로, $3/M인 fresh input보다 정확히 90% 저렴하다. 테스트한 어떤 호출에서도 cache write 추가 요금은 없었다. 최초 hit까지 동일한 호출을 2-5번 보내야 했다. 한 번의 재시도만으로 cache 동작 여부를 판단할 수 없으며, 여러 번 측정해야 한다.

비교하면 이 하한선은 OpenAI가 공개한 최소 1,024 token의 4분의 1이다. block 크기는 다른 환경에서 측정한 64-token 단위보다 거칠다. 수명은 고정 TTL이 아니라 best-effort 방식이다. 측정 중 cache entry는 4분과 15분의 idle gap 이후에도 유지됐지만, 8분 후에는 miss가 발생한 경우도 있었다. 만료는 부하에 따른 eviction으로 보고, 호출마다 cached token 구성을 확인해야 한다. 가격과 관련해 한 가지 더 계산할 부분이 있다. 1M-token context window에는 별도의 long-context 요금 구간이 없고 정액 단가가 적용된다. context window를 모두 채우면 호출당 fresh input 비용은 $3.00이고, prefix가 warm 상태가 되면 $0.30이다. large-context workload의 경제성은 표시된 정가보다 cache에 훨씬 크게 좌우된다. 수백 token 규모의 system prompt만 재사용해도 K3의 cache가 동작한다. 다른 provider라면 아직 cache가 시작되지 않을 크기다. 동작 방식과 usage에서 hit를 확인하는 방법은 prompt caching 가이드와 실측한 cache 최소 크기에서 다룬다.

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

아니다. K3 tokenizer는 다른 모델과 비교했을 때 중국어 처리 효율이 가장 높다. 출시 첫 주부터 반복해서 제기된 질문에 대한 답이기도 하다. 의미가 동일하도록 맞춘 문장에서 envelope overhead를 뺀 100자당 순수 token 수는 다음과 같다.

K3의 중국어는 100자당 52 token이 청구된다. GLM-5.2와 DeepSeek보다 11% 적고, Sonnet 5의 절반에도 미치지 않는다. 취약한 언어는 일본어다. 다른 open-weight 모델보다 16-24% 더 많은 token을 사용한다. 같은 계열에서는 tokenizer가 바뀌지 않았다는 점도 확인했다. K3, K2.7-code, K2.5는 의미를 맞춘 샘플 23개 모두에서 동일한 token 수가 나왔다. 따라서 K2 기준으로 잡은 언어별 예산을 그대로 적용할 수 있다. 언어 9개를 기준으로 tokenizer 밀도와 token당 가격이 결합되는 방식은 언어별 가장 저렴한 LLM 분석에서 다룬다.

FAQ

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

Moonshot는 2026년 7월 27일까지 Modified MIT license로 전체 weight를 공개하겠다고 약속했다. 이 글을 게시하는 시점에는 K3를 API로만 사용할 수 있다. “역대 가장 큰 open-weight model”이라는 설명은 현재로서는 약속일 뿐, 아직 download link는 없다. 이 weight가 합류할 open-weight 생태계의 caching 동작은 open-weight LLM의 prompt caching에서 정리했다.

K2 계열과 비교해 K3에서 실제로 달라진 점은 무엇인가?

청구 측면에서 실측한 차이는 세 가지다. 첫째는 가격이다. K3의 $3/$15는 K2.7-code의 $0.95/$4보다 3.2-3.75배 높다. 둘째는 항상 켜지는 thinking이다. K2.5는 reasoning을 전혀 하지 않고, K2.7-code에는 toggle이 있다. 셋째, 그 외에는 달라진 것이 없다. 정렬된 샘플 23개 모두에서 K3, K2.7-code, K2.5의 tokenizer 결과가 byte 단위까지 동일했다. K2 시절의 token 예산을 그대로 적용할 수 있다. 사양표상 Moonshot가 밝힌 내용은 Kimi Delta Attention을 사용하는 새로운 2.8T-parameter MoE, expert 896개 중 token당 16개 활성화, K2.7-code의 256K보다 커진 1M-token context window, native image input이다. 여기서는 청구 관련 주장만 측정했으며 architecture 관련 주장은 검증하지 않았다.

Kimi K3는 structured output을 지원하나?

지원한다. json_schema를 지정한 response_format은 측정에서 schema를 준수하는 유효한 object를 반환했다. 단, 내부에서는 reasoning이 계속 동작한다. 해당 extraction 호출의 output token 97개 중 66개가 reasoning이었다. 따라서 schema-constrained 호출도 다른 호출과 마찬가지로 thinking 비용을 지불한다. 이를 피하려면 reasoning_effort: "none"도 함께 설정해야 한다.

reasoning을 끄면 확인할 수 있는 내용도 달라지나?

그렇다. 기본 설정에서 K3는 전체 chain of thought를 reasoning_content로 반환하며, 문서는 multi-turn history에 이를 수정하지 않고 다시 넣으라고 안내한다. reasoning_effort: "none"을 사용하면 해당 field 자체가 사라지고, 약 67-token의 thinking preamble도 prompt 청구량에서 함께 빠진다.

2026-07-20에 kimi-k3를 출시 첫 주 정가인 input $3/M, cached $0.30/M, output $15/M 조건으로 측정했다. 반복 prompt에는 salt를 추가해 response-level cache를 피했다. 정확도 횟수는 정답을 하나로 판별할 수 있는 작업을 사용했다. 동작 관련 결과는 별도의 독립적인 요청 경로에서도 재현했다. 출시가 안정화되면서 가격과 동작은 바뀔 수 있다. 이 글의 수치에 의존하기 전에 자체 usage 기록으로 확인해야 한다.

← 블로그로 돌아가기