Kimi API는 종량제로 과금하며 구독제를 제공하지 않습니다. 가격을 비교할 때 "백만 토큰당 얼마"만 보면 잘못 선택하기 쉽습니다. 실제로 청구서를 결정하는 것은 모델, 컨텍스트 길이, 캐시 적중률, 출력 길이입니다. K2 시리즈는 262,144 토큰 컨텍스트를 제공하고 K3는 1,048,576까지 확장됩니다. 롱컨텍스트 성능이 뛰어난 만큼 입력 측 비용이 누적되기도 쉽습니다.
이 글은 K2 시리즈의 과금 구조, 롱컨텍스트 비용의 원천, 재현 가능한 측정 방법, 비용 절감 순서를 다루며 단가를 고정해 쓰지 않습니다. 구체적인 가격은 공식 문서와 사이트 내 모델 가격을 기준으로 합니다.
안내: Moonshot과 Kimi는 해당 권리자의 상표입니다. 모델명, 컨텍스트 길이, 과금 규칙은 조정될 수 있습니다. 이 글은 2026년 10월의 일반적인 상황을 기준으로 하며, 구매 전에 공식 페이지를 다시 확인하세요.
1. K2 시리즈의 역할 분담
| 모델 | 포지션 | 컨텍스트 | 적합한 작업 | 비용 관점 |
|---|---|---|---|---|
kimi-k2.6 |
범용 | 262,144 | 대화, 추출, 고객지원, 문서 처리 | 캐시 적중률 |
kimi-k2.7-code |
코드 | 262,144 | 코드 생성, 저장소 질의응답, Agent | 입력이 길고 도구 결과가 많음 |
kimi-k2.7-code-highspeed |
코드 고속 버전 | 262,144 | 저지연 완성, 대화형 코딩 | 단가와 처리량의 균형 |
kimi-k3 |
차세대 | 1,048,576 | 초장문 문서, 복잡한 다단계 작업 | 롱컨텍스트와 캐시 쓰기 |
모델은 계속 갱신되며 K2 시리즈에 이후 새 버전이 추가될 수 있습니다. 구매 시 공식 모델 목록과 사이트 내 모델 가격을 기준으로 하고, 이 글의 모델명을 영구적인 약속으로 받아들이지 마세요.
범용 작업에 기본으로 최대 컨텍스트를 쓸 필요는 없습니다. 전체 자료를 1M 컨텍스트에 넣으면 입력 비용이 턴 수에 따라 빠르게 누적됩니다. 먼저 검색으로 범위를 좁힌 뒤 모델이 핵심 조각을 읽게 하는 편이 보통 더 경제적입니다. 코드 작업은 반대입니다. 저장소 구조와 도구 반환값을 유지해야 하는 경우가 많으므로 안정적인 접두사와 캐시 적중률 향상이 핵심입니다.
2. 청구서를 구성하는 세 가지
K2 시리즈는 "캐시 적중 입력, 캐시 미적중 입력, 출력" 세 항목으로 과금합니다. K3는 캐시 쓰기를 5분과 1시간 두 가지 TTL 등급으로 별도 가격 책정하므로 하나의 평균 단가에 총 토큰을 곱할 수 없습니다.
| 과금 항목 | 발생 시점 | 비용 영향 | 통제 수단 |
|---|---|---|---|
| 캐시 미적중 입력 | 처음 등장하는 프롬프트, 문서, 도구 결과 | 컨텍스트에 비례해 선형 증가 | 검색, 요약, 기록 잘라내기 |
| 캐시 적중 입력 | 반복되는 system prompt, 고정 접두사 | 보통 미적중보다 현저히 낮음 | 접두사 고정, 도구 순서 고정 |
| 출력 토큰 | 모델이 생성한 내용과 사고 | 긴 출력이 청구서를 키움 | max_completion_tokens 제한 |
| 캐시 쓰기(K3) | 캐시 접두사에 기록 | TTL 등급별 가격 책정 | 안정적으로 재사용되는 내용만 캐시 |
한 번의 요청을 나누면 비용 공식은 다음과 같습니다.
단일 요청 비용 =
미적중 입력 Token × 미적중 단가
+ 적중 입력 Token × 적중 단가
+ 출력 Token × 출력 단가
K3는 캐시 쓰기 항목을 더해야 합니다. 응답의 usage는 prompt_tokens, completion_tokens, prompt_tokens_details를 제공합니다. 캐시 적중과 캐시 쓰기는 모두 prompt_tokens에 포함되므로, 캐시되지 않은 부분은 전체에서 이 두 항목을 빼서 계산합니다.
3. 롱컨텍스트가 비싸지기 쉬운 이유
| 시나리오 | 일반적인 토큰 구조 | 주요 비용 | 최적화 방향 |
|---|---|---|---|
| 장문 문서 질의응답 | 입력 큼, 출력 중간 | 문서 반복 전송 | 검색과 캐시 |
| 코드 저장소 Agent | 입력과 출력 모두 큼 | 도구 결과와 기록 | 요약, 잘라내기, 캐시 |
| 멀티턴 고객지원 | 입력이 턴 수에 따라 누적 | 대화 기록 반복 | 롤링 요약 |
| 배치 추출 | 입력 중간, 출력 짧음 | 문서 반복 읽기 | 배치 처리와 소형 모델 |
차이는 보통 다섯 곳에서 발생합니다.
- 입력이 턴 수에 따라 누적: 매 턴마다 전체 텍스트를 다시 보내면 청구서가 턴 수에 비례해 거의 배로 늘어납니다.
- 캐시 적중률: 고정 접두사는 재사용되지만 매번 바뀌는 타임스탬프, 무작위 ID, 동적 정렬은 캐시를 무효화합니다.
- 도구 출력: 검색이나 코드 실행이 긴 로그를 반환하고 다음 턴에 그대로 다시 포함되면 비용이 겹칩니다.
- 출력 길이: 개방형 "상세 분석"은 긴 출력을 만들기 쉽고, 출력은 보통 캐시 적중 입력보다 비쌉니다.
- 모델 불일치: 단순 분류에 대형 모델을 쓰거나 복잡한 작업에 맞지 않는 모델로 반복 재시도하면 비용이 커집니다.
4. 재현 가능한 비용 측정
- 간단, 중간, 복잡 세 등급을 포괄하는 실제 작업 20~50개를 고르고 합격 기준을 명확히 적습니다.
- 먼저 토큰 추정 인터페이스로 입력을 수치화하고 글자 수로 추측하지 않습니다.
- 같은 작업 묶음을
kimi-k2.6과 코드 모델로 각각 실행해 품질, 지연, 재작업 횟수를 기록합니다. - 응답
usage에서 입력, 출력, 캐시 적중, 캐시 쓰기를 읽습니다. - 백만 토큰당 표시 가격이 아니라 "합격 작업 하나를 완료하는 비용"으로 비교합니다.
- 재시도, 실패 요청, 캐시 쓰기도 작업당 비용에 함께 계산합니다.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.cn/v1",
)
resp = client.chat.completions.create(
model="kimi-k2.6",
messages=[{"role": "user", "content": "이 계약서를 JSON으로 추출하세요: ..."}],
max_completion_tokens=1024,
)
u = resp.usage
print("입력", u.prompt_tokens, "출력", u.completion_tokens)
print("캐시 상세", getattr(u, "prompt_tokens_details", None))
스트리밍 호출에는 stream_options={"include_usage": True}를 추가해야 하며, 전체 사용량은 마지막 청크에서만 반환됩니다. 금액은 계약서나 가격 페이지의 실제 단가를 곱해 계산하고, 몇 달 전 스크린샷을 그대로 쓰지 마세요.
5. 비용을 낮추는 순서
- 먼저 캐시: system prompt, 도구 정의, 지식베이스 접두사를 고정하고
cached_tokens로 실제 적중 여부를 확인합니다. - 다음은 입력 감소: 검색은 관련 조각만 회수하고 대화 기록은 요약하며, 전체 라이브러리를 컨텍스트에 넣지 않습니다.
- 출력 제한: 합리적인
max_completion_tokens를 설정하고 JSON이나 고정 필드를 요구해 불필요한 상투적 표현을 줄입니다. - 모델 라우팅: 범용 작업은
kimi-k2.6, 코드 작업은 K2.7 코드 버전, 초장문 자료는 K3를 검토합니다. - 긴 요청은 스트리밍으로: 스트리밍이 단가를 직접 바꾸지는 않지만 시간 초과와 연결 끊김으로 인한 재시도를 줄입니다.
- 모니터링과 알림: 프로젝트, 모델, 시나리오별 사용량을 보고 예산 상한을 설정하며 매주 소비 순위를 검토합니다.
순서를 거꾸로 하지 마세요. 먼저 캐시와 입력 관리를 하고 나서 더 저렴한 모델 전환을 검토해야 합니다. 그렇지 않으면 틀린 답을 더 저렴하게 만드는 셈입니다.
6. 예산과 청구서 관리
- 프로젝트마다 키 하나를 쓰고 프로젝트별 일일 예산을 설정해 한 업무가 전체 할당량을 소진하지 않게 합니다.
- 매월 "프로젝트, 모델, 시나리오" 세 축으로 대조해 가장 빠르게 증가하는 호출을 찾습니다.
- 캐시 적중률, 재시도 횟수, 평균 출력 길이를 별도로 기록해야 최적화 효과를 입증할 수 있습니다.
- 위안화 결제와 인보이스가 필요한 팀은 국내 AI 게이트웨이로 멀티 모델 청구서를 통합할 수 있습니다. 구체적인 가격과 인보이스 규칙은 모델 가격을 기준으로 합니다.
자주 묻는 질문
K2와 K3 중 어느 쪽이 더 경제적인가요?
작업에 따라 다릅니다. K2 시리즈는 컨텍스트가 262,144로 대부분의 문서와 코드 시나리오를 포괄하고, K3는 컨텍스트가 더 커 초장문 자료에 적합합니다. 단가만 보지 말고 "합격 작업 하나를 완료하는 총비용"으로 비교하세요.
캐시로 얼마나 절감할 수 있나요?
접두사 재사용률과 적중률에 따라 다릅니다. 캐시 적중 입력은 보통 미적중보다 현저히 낮고, 적중하면 캐시 유효 기간도 연장됩니다. 다만 접두사가 매번 바뀌거나 너무 짧으면 적중하지 않습니다.
스트리밍 출력이 더 저렴한가요?
단가를 직접 바꾸지는 않습니다. 스트리밍의 가치는 긴 요청의 시간 초과, 연결 중단, 재시도에서 발생하는 숨은 비용을 줄이는 데 있습니다.
청구서가 추정보다 높은 이유는 무엇인가요?
흔히 빠뜨리는 항목은 대화 기록, 도구 반환값, 문서 전문, 재시도, 긴 출력, 캐시 미적중입니다. 요청 로그를 usage와 대조해야 차이를 찾을 수 있습니다.
중국 내 팀은 위안화로 어떻게 정산하나요?
위안화 충전과 인보이스를 제공하는 AI 게이트웨이를 통해 Kimi를 호출하고 멀티 모델 청구서를 통합할 수 있습니다. 구체적인 사용 가능 모델, 가격, 인보이스 규칙은 모델 가격을 기준으로 합니다.
다음 단계
먼저 ZSQH AI Gateway에서 테스트 키를 만들고 kimi-k2.6과 코드 모델로 각각 실제 작업 묶음을 실행해 토큰, 캐시 적중, 품질을 기록한 뒤 주력 모델을 정하세요. 모델 가용성과 가격은 모델 가격을 기준으로 합니다.
관련 읽기:
