Moonshot API 가격과 과금 (2026): 모델, 캐시와 장문 컨텍스트 비용

Moonshot API는 Moonshot AI 개방 플랫폼이 제공하는 모델 인터페이스이며 Kimi의 개발자 플랫폼입니다. 토큰 사용량으로 과금하고 구독 요금제는 없습니다. 많은 팀이 예산을 세울 때 두 곳에서 실수합니다. 하나는 이미 종료된 moonshot-v1 모델을 계속 호출하는 것이고, 다른 하나는 입력, 캐시 쓰기, 출력, 재시도를 하나의 평균 단가로 섞는 것입니다. 이 글은 2026년 10월 공개 문서를 기준으로 과금 구조를 분석하며, 구체적인 가격은 사이트의 모델 가격과 공식 문서를 기준으로 합니다.

안내: Moonshot, Kimi는 권리자의 상표입니다. 본 문서는 기술 설명 목적이며 권리자와 소속 또는 대리 관계가 있음을 뜻하지 않습니다. 모델 목록, 컨텍스트 길이, 과금 규칙은 조정될 수 있으므로 구매 전 공식 페이지를 다시 확인하십시오.

1. 먼저 "현재 모델"과 "종료된 모델"을 구분하기

2026년 10월 기준 개방 플랫폼 문서에 나온 주력 모델은 kimi-k3, kimi-k2.6, kimi-k2.7-code, kimi-k2.7-code-highspeed입니다. 구형 moonshot-v1 시리즈는 이미 퇴역했습니다. moonshot-v1-8k, -32k, -128k, -auto 및 대응 비전 프리뷰 버전은 2026년 8월 31일 종료되었고 같은 날 kimi-k2.5도 종료되었습니다. 더 이른 kimi-k2 프리뷰와 kimi-latest 등도 서비스가 중단되었습니다.

모델	컨텍스트	과금 구조	상태와 주의
`kimi-k3`	1,048,576	입력, 캐시 적중, 캐시 쓰기, 출력	현재 플래그십, 공식 마이그레이션 권장 대상
`kimi-k2.6`	262,144	입력, 캐시 적중, 출력	범용과 멀티모달, 비용 민감 장면에서 자주 사용
`kimi-k2.7-code`	262,144	입력, 캐시 적중, 출력	코드 생성, 저장소 질의응답, 에이전트
`kimi-k2.7-code-highspeed`	262,144	입력, 캐시 적중, 출력	저지연 코드 작업
`moonshot-v1-8k/32k/128k`	모델명 기준	구버전 길이 구간 과금	2026-08-31 종료

오래된 튜토리얼의 모델명을 그대로 복사해서는 안 됩니다. moonshot-v1-8k의 "8k" 자체가 컨텍스트 등급이므로 호출 실패는 Key 문제가 아니라 모델이 더 이상 존재하지 않기 때문입니다. 마이그레이션할 때는 모델명을 바꾼 뒤 컨텍스트와 과금 항목을 다시 확인하고 문자열 치환만 하지 마십시오.

2. 과금 단위: 요청 하나를 네 항목으로 나누기

현재 청구서는 보통 네 종류의 토큰으로 구성됩니다. 캐시 미적중 입력, 캐시 적중 입력, 캐시 쓰기, 출력입니다. K3의 캐시 쓰기는 5분과 1시간 두 가지 TTL로 별도 과금하며 K2 시리즈 가격 페이지에는 캐시 쓰기 항목이 따로 없습니다. 요청 하나를 공식으로 쓰면 다음과 같습니다.

요청 1회 비용 =
  미적중 입력 Tokens × 미적중 단가
+ 캐시 적중 입력 Tokens × 적중 단가
+ 캐시 쓰기 Tokens × 해당 TTL 단가 (K3만)
+ 출력 Tokens × 출력 단가

공식 문서에는 유용한 환산이 있습니다. 표준 중국어 텍스트는 대략 1.5~2자가 1토큰에 해당합니다. 글자 수에 단가를 바로 곱하면 입력량을 과소평가하므로 정식 산정에는 POST /v1/tokenizers/estimate-token-count 추정 인터페이스를 쓰거나 응답의 usage를 직접 읽으십시오.

Chat Completions의 사용량 필드는 usage.prompt_tokens, usage.completion_tokens이고 캐시 세부 정보는 usage.prompt_tokens_details.cached_tokens와 cache_write_tokens에 있습니다. Messages API의 input_tokens에는 캐시 부분이 포함되지 않으므로 총 입력은 input_tokens, cache_read_input_tokens, cache_creation_input_tokens를 더해야 합니다. 스트리밍 호출은 stream_options.include_usage=true를 설정해야 합니다.

3. 캐시는 어떻게 과금되고 왜 적중하지 않는가

컨텍스트 캐시는 접두사 기준으로 매칭하며 전체 대화 기준이 아닙니다. 접두사 어느 한 곳이라도 바뀌면 그 위치 이후 내용은 재사용할 수 없습니다. 접두사를 깨는 흔한 행동은 system prompt에 타임스탬프나 무작위 ID를 넣는 것, 매번 도구 정의 순서를 바꾸는 것, 지식 베이스 조각을 동적으로 결합하는 것, TTL 등급을 바꾸는 것입니다. 캐시는 조직 단위로 격리되며 조직 간에 공유되지 않습니다.

K3의 캐시 쓰기는 최초 쓰기 시 과금하고 TTL은 5분 또는 1시간으로 고정되며 쓰기 후 중간에 등급을 바꿀 수 없습니다. 적중하면 원래 TTL로 무료 연장되고 쓰기 비용을 다시 받지 않습니다. 두 등급의 캐시는 서로 통하지 않습니다. 접두사 끝부분이 완전한 캐시 블록 하나에 못 미치면 보통 미적중으로 처리됩니다.

캐시는 "켜면 절약되는" 스위치가 아니라 접두사 엔지니어링입니다. system prompt, 도구 정의, 고정 예시, 지식 베이스 공통 부분을 맨 앞에 두고 변수는 뒤에 두며 cached_tokens로 적중률을 검증하십시오.

4. 장문 컨텍스트 비용: 반복 전송에서 비싸진다

K3는 1,048,576 토큰 컨텍스트를 지원하고 K2 시리즈는 262,144 토큰입니다. K3는 통일된 종량 과금을 적용하고 구형 moonshot-v1처럼 8k, 32k, 128k로 길이 구간을 나누지 않으므로 구버전 구간 가격표로 K3를 추산할 수 없습니다.

장문 컨텍스트 자체가 문제가 아니라 같은 자료를 매 턴 다시 보내는 것이 문제입니다. 20만 토큰 문서 질의응답에서 열 번 연속 질문하며 매번 전문을 붙이면 입력 비용이 턴 수에 따라 빠르게 누적됩니다. 도구 로그, 웹 페이지 본문, 코드 결과도 이력에 남아 계속 과금됩니다. 더 흔한 방식은 관련 조각을 먼저 검색한 뒤 모델에 읽히고, 다중 턴 대화는 롤링 요약을 쓰고, 안정적인 부분은 캐시 접두사로 만들고, 반드시 보존해야 하는 원문에만 장문 컨텍스트를 쓰는 것입니다.

장문 컨텍스트는 지연과 실패율도 키웁니다. 비스트리밍 장문 요청은 게이트웨이 시간 초과를 만나기 쉽고 재시도는 새로운 입력 사용량을 만듭니다. 장문 작업은 스트리밍 출력을 우선 사용하고 합리적인 읽기 타임아웃을 설정해야 합니다.

5. 재시도와 실패 요청은 어떻게 계산되나

공식 오류 코드는 429를 세 가지로 나눕니다. rate_limit_reached_error는 조직 수준 동시성, RPM, TPM 또는 TPD 도달이고, exceeded_current_quota_error는 잔액이나 할당량 부족이며, engine_overloaded_error는 서버 용량 과부하입니다. 잔액 문제만 충전으로 해결할 수 있고 용량 과부하는 충전해도 바로 사라지지 않습니다. 500, 503은 보통 잠시 후 재시도를 권장하며 장문 요청의 게이트웨이 시간 초과는 그대로 재전송하기보다 스트리밍으로 바꾸는 것이 낫습니다.

실패 요청이 과금되는지에 대해 공식 문서는 "실패는 무료"라는 약속을 하지 않습니다. 안전한 방법은 재시도에 비용이 없다고 가정하지 않고 요청 로그와 usage로 대조하며 재시도 횟수를 별도로 집계하는 것입니다. 재시도 전략은 다음 순서로 적용할 수 있습니다.

먼저 오류 코드로 분류하고 연체, 파라미터 오류, 콘텐츠 검수 실패는 재시도하지 않습니다.
429 속도 제한, 500, 503, 네트워크 중단에만 제한적으로 재시도합니다.
지수 백오프에 무작위 지터를 더하고 Retry-After를 존중합니다.
재시도에 상한과 총 시간을 두어 동시성을 계속 점유하지 않게 합니다.
도구 호출에는 멱등 키나 중복 제거 테이블을 두어 중복 주문과 중복 메시지를 막습니다.
request_id, 모델명, 토큰 사용량, 재시도 횟수를 기록해 대조에 대비합니다.

6. 예산 산정: 토큰에서 월 상한까지

예산은 "백만 토큰당 얼마"에서 거꾸로 계산하지 말고 실제 작업에서 거꾸로 계산하십시오. 간단, 중간, 복잡 세 등급을 포함한 대표 작업 20~50개를 고르고 검수 기준을 명확히 적습니다. 그다음 추정 인터페이스로 입력을 재고 실제 호출의 usage를 읽어 "합격 작업 하나를 완료하는 총비용"으로 모델을 비교하십시오.

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "이 계약을 JSON으로 추출하세요: ..."}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

요청 1회 입력을 추정한 뒤 네 가지를 더해야 합니다. 이전 메시지, 도구 반환, 캐시 미적중 비율, 재시도로 인한 추가 호출입니다. 오프라인 배치 처리는 Batch API를 평가할 수 있으며 공식 문서에 따르면 동기 호출보다 약 40% 저렴하지만 현재 kimi-k2.7-code와 kimi-k2.6만 지원하고 kimi-k3는 아직 지원하지 않습니다.

예산 관리는 세 계층으로 나누는 것이 좋습니다. 프로젝트별 일·월 예산을 설정하면 콘솔이 상한 도달 후 해당 프로젝트 요청을 거부하지만 실행에 약 10분 지연이 있을 수 있습니다. Key나 구성원별로 나누어 한 업무가 조직 전체 할당량을 다 쓰지 않게 합니다. 모델과 장면별로 주간 대조를 해 가장 빠르게 증가하는 호출을 찾습니다. 잔액 경보는 갑작스러운 공급 중단만 막을 수 있고 예산을 대체하지 못합니다.

7. 비용 절감 순서와 대조 습관

비용 절감 순서를 거꾸로 하지 마십시오. 먼저 캐시와 입력 관리를 하고, 다음으로 출력을 제한하고, 마지막에 모델 교체를 고려합니다. 그렇지 않으면 잘못된 답변을 더 저렴하게 만드는 것에 불과합니다.

system prompt, 도구 정의, 지식 베이스 접두사를 고정하고 cached_tokens를 검증합니다.
검색과 요약으로 매번 전송하는 원문을 줄이고 이전 메시지는 롤링 요약합니다.
max_completion_tokens를 설정하고 JSON 또는 고정 필드를 요구해 개방형 장문 출력을 줄입니다.
작업별로 모델을 라우팅합니다. 범용 작업은 kimi-k2.6, 코드 작업은 K2.7 코드 버전, 초장문 자료만 K3를 사용합니다.
장문 요청은 스트리밍으로 바꿔 시간 초과와 단절로 인한 재시도를 줄입니다.
오프라인 작업은 Batch API로 보내고 실시간 작업은 동기 인터페이스를 유지합니다.
매월 프로젝트, 모델, 장면 세 차원으로 대조하고 캐시 적중률, 재시도 횟수, 평균 출력 길이를 별도로 기록합니다.

대조표에는 최소한 호출 시간, 프로젝트, 모델, 입력 토큰, 캐시 적중 토큰, 캐시 쓰기 토큰, 출력 토큰, 재시도 횟수, request_id가 있어야 합니다. 이 필드가 없으면 청구서 차이가 생겼을 때 추측만 할 수 있습니다.

자주 묻는 질문

moonshot-v1-8k를 계속 호출할 수 있나요?

아니요. moonshot-v1 전 라인이 2026년 8월 31일 종료되었고 공식적으로 kimi-k3로 마이그레이션을 권장합니다. 마이그레이션할 때 모델명만 바꾸지 말고 컨텍스트 길이, 과금 항목, 출력 파라미터를 다시 확인하십시오.

캐시 적중이 왜 적용되지 않나요?

먼저 접두사가 타임스탬프, 무작위 ID, 동적 정렬, 도구 재정렬로 깨지지 않았는지 확인합니다. 다음으로 요청 간격이 TTL을 넘지 않았는지, 캐시 쓰기와 읽기가 같은 조직과 같은 TTL 등급인지 확인합니다. 판단은 감이 아니라 cached_tokens로 하십시오.

장문 컨텍스트는 항상 더 비싼가요?

항상 그렇지는 않지만 긴 자료를 반복 전송하면 보통 더 비쌉니다. 비용은 입력이 반복되는 횟수, 캐시 적중률, 출력 길이에 달려 있습니다. 먼저 검색으로 범위를 줄이고 나서 백만 단위 컨텍스트 사용 여부를 결정하십시오.

실패한 요청도 과금되나요?

공식 문서는 실패가 무료라고 약속하지 않습니다. 재시도 비용이 0이라고 가정하지 말고 요청 로그와 usage로 확인하며 재시도 횟수를 작업당 비용에 포함하십시오.

최신 가격은 어디에서 보나요?

사이트의 모델 가격과 Moonshot/Kimi 공식 문서를 기준으로 합니다. 가격, 모델 목록, 캐시 규칙이 모두 조정될 수 있으므로 오래된 캡처를 사용하지 마십시오.

다음 단계

먼저 ZSQH AI Gateway에서 테스트 Key를 만들고 kimi-k2.6과 kimi-k3로 각각 실제 작업 묶음을 실행해 입력, 출력, 캐시 적중, 재시도를 기록한 뒤 주력 모델과 월 예산을 결정하십시오. 구체적인 가격과 사용 가능 모델은 모델 가격을 기준으로 합니다.