키미 케이쓰 컨텍스트 캐싱, 2026 비용 추정

매번 같은 시스템 지침과 참고 문서를 보내는데도 키미 케이쓰 API 비용이 줄지 않는다면, 반복량만 보고 캐시 절약을 기대한 것이 문제일 수 있습니다.

이번 주에는 요청 로그에서 반복 입력 토큰과 캐시 적중 토큰을 분리해 계산하십시오. 안정적인 접두부가 여러 요청에서 반복될 때만 키미 케이쓰 컨텍스트 캐싱을 유지하고, 그렇지 않으면 프롬프트를 재구성하거나 현재 구조를 유지하는 편이 낫습니다.

이 글은 매 요청마다 큰 시스템 지침을 보내는 에이전트 개발자를 위한 글입니다. 고정 문서와 코드 규칙을 사용하는 팀, 여러 사용자를 동시에 처리하는 인공지능 서비스 책임자도 대상입니다. 모델 비용과 재시도 비용, 실행 환경 비용을 따로 계산하고 싶다면 아래 기준을 적용하십시오.

마지막 업데이트: 2026년 8월 3일. 캐시 동작과 사용량 필드는 공식 대화 API 문서, 공식 문맥 캐시 안내, 공식 가격 설명, 공식 오류 안내를 기준으로 확인했습니다.

먼저 확인할 캐시의 작동 범위

키미 케이쓰 컨텍스트 캐싱은 개발자가 별도의 캐시 아이디나 만료 시간을 직접 관리하는 방식으로만 이해하면 안 됩니다. 공식 문서에는 반복되는 요청의 적중률을 높이기 위한 prompt_cache_key가 설명되어 있으며, 코딩 에이전트에서는 세션 아이디나 작업 아이디를 같은 값으로 유지하는 설계가 권장됩니다. 키미 케이쓰 요청 결과에는 prompt_tokens, completion_tokens, total_tokens, cached_tokens 같은 사용량 필드도 포함될 수 있습니다. (platform.kimi.ai)

따라서 “문서가 같다”와 “캐시가 적중됐다”는 같은 뜻이 아닙니다. 다음 조건을 먼저 분리해야 합니다.

공식 가격 문서는 입력과 출력을 사용량에 따라 각각 청구한다고 설명합니다. 문서를 올리고 추출하는 단계와, 추출된 내용을 모델 입력으로 다시 보내는 단계도 구분해야 합니다. 공식 입력·출력 청구 설명을 먼저 확인하십시오.

첫 번째 단계: 고정 시스템 지침부터 분리하기

가장 먼저 절약 가능성이 큰 구조는 여러 요청이 동일한 초기 문맥을 공유하는 형태입니다.

예를 들어 다음 요소가 매번 같다면 후보가 됩니다.

• 에이전트의 역할과 금지 규칙
• 도구 이름과 매개변수 설명
• 출력 형식과 검증 규칙
• 제품별 공통 지식
• 특정 코드 저장소의 고정 규칙

반대로 아래 내용은 매번 바뀌므로 고정 문맥에 섞으면 재사용 범위를 좁힐 수 있습니다.

• 현재 시각
• 사용자별 권한
• 요청별 추적 번호
• 새로 검색한 문서
• 직전 도구 호출 결과
• 임시 오류 메시지

프롬프트를 아래처럼 나누는 것이 안전합니다.

고정 영역:
에이전트 역할
공통 규칙
도구 설명
문서 버전

변경 영역:
사용자 질문
현재 권한
이번 요청의 도구 결과
작업별 상태

공식 문서의 대화 방식은 상태를 서버가 자동으로 보존하는 구조가 아닙니다. 여러 차례 대화를 이어 가려면 이전 메시지와 도구 결과를 다음 요청에 다시 넣어야 합니다. 대화가 길어질수록 오래된 내용을 요약하거나 최근 메시지만 남겨야 한다는 안내도 있습니다. (platform.kimi.ai)

두 번째 단계: 고정 문서와 지식 자료의 경계를 측정하기

지식 기반 질의응답에서는 문서 전체가 아니라 “항상 같은 앞부분”이 중요합니다. 문서를 같은 내용으로 저장했더라도 다음 변경이 있으면 캐시 적중이 달라질 수 있습니다.

1. 문서 조각을 붙이는 순서가 달라집니다.
2. 문서 제목이나 버전 표시가 앞쪽에서 바뀝니다.
3. 검색 결과 개수가 요청마다 달라집니다.
4. 접근 권한에 따라 문서 목록이 달라집니다.
5. 사용자 질문을 문서보다 앞에 배치합니다.

문서를 한 번에 모두 넣는 방식과 안정적인 조각을 먼저 넣는 방식을 비교하면 다음과 같습니다.

민감한 자료는 적중률보다 격리가 우선입니다. 사용자별 권한과 개인정보를 공유 접두부에 넣지 마십시오. 공통 제품 설명은 공유할 수 있어도, 고객의 계약 내용이나 내부 문서는 사용자 단위로 분리해야 합니다.

세 번째 단계: 긴 대화가 항상 유리하지 않은 이유

긴 대화는 이전 내용이 누적되기 때문에 캐시 절약이 커 보입니다. 그러나 실제 비용은 다음 네 묶음으로 나눠야 합니다.

• 캐시 적중 입력 토큰
• 캐시 미적중 입력 토큰
• 출력 토큰
• 실패 및 재시도 요청의 입력과 출력

기본 계산식은 다음과 같습니다.

총 비용 =
적중 입력 토큰 × 적중 입력 단가
+ 미적중 입력 토큰 × 미적중 입력 단가
+ 출력 토큰 × 출력 단가
+ 재시도 비용

실제 단가는 작성 시점의 공식 가격표에서 가져와야 합니다. 가격표가 바뀌면 식의 변수만 교체하십시오. 확인되지 않은 고정 금액이나 임의의 절약률을 이 글의 결론으로 사용해서는 안 됩니다.

긴 세션에서 새 메시지가 계속 늘어나면, 최초 시스템 지침만 캐시되고 이후 대화와 도구 결과는 새 입력으로 남을 수 있습니다. 따라서 세션 길이와 캐시 적중률은 같은 지표가 아닙니다. 성공 작업 하나에 평균 몇 번의 요청이 발생했는지까지 기록해야 합니다.

주의: 캐시 적중률은 입력 비용의 분포입니다. 작업 성공률은 결과 품질의 지표입니다. 두 수치를 하나의 절약률로 합치면 잘못된 의사결정을 하게 됩니다.

네 번째 단계: 다중 사용자 서비스의 공유 범위 정하기

다중 사용자 인공지능 서비스에서는 공통 접두부와 사용자 전용 영역을 분리하십시오.

권장 구조는 다음과 같습니다.

• 공유 영역: 제품 설명, 공통 안전 규칙, 도구 형식
• 조직 영역: 팀별 업무 규칙과 승인 절차
• 사용자 영역: 권한, 개인 문서, 대화 기록
• 요청 영역: 현재 질문, 최신 검색 결과, 임시 도구 결과

조직 영역까지 공유할 수 있는지는 권한 모델에 달려 있습니다. 같은 조직이라도 역할이 다르면 자료를 하나의 캐시 영역에 묶지 않는 편이 안전합니다. 특히 사용자 식별자를 캐시 키처럼 사용하더라도, 실제 문맥에 포함된 민감 정보가 다른 요청으로 섞이지 않는지 별도로 검사해야 합니다.

키미 케이쓰 API는 요청 실패 시 오류 유형과 메시지를 반환하며, 공식 오류 안내에는 인증 실패, 요청 제한, 계정 한도 초과 같은 구분이 설명되어 있습니다. 실패 요청을 성공 작업과 분리하지 않으면 캐시 절약을 실제 운영 비용보다 크게 보게 됩니다. (platform.kimi.ai)

다섯 번째 단계: 도구 반복과 재시도 비용을 따로 기록하기

에이전트는 한 번의 사용자 요청으로 끝나지 않습니다. 모델 호출, 도구 실행, 도구 결과 전달, 추가 모델 호출이 이어집니다. 도구가 실패하면 같은 문맥을 다시 보내는 요청도 발생합니다.

성공 작업 단위로 다음 값을 기록하십시오.

작업 아이디
전체 요청 수
성공 요청 수
실패 요청 수
전체 입력 토큰
캐시 적중 입력 토큰
전체 출력 토큰
도구 호출 수
최종 결과까지 걸린 시간

공식 문서의 도구 호출 흐름도 모델이 도구 호출을 반환한 뒤 실행 결과를 다시 메시지로 넣는 구조를 설명합니다. 검색 도구를 사용할 때 검색 결과 토큰도 다음 입력에 포함될 수 있으므로, 단순한 사용자 질문 길이만으로 비용을 계산하면 안 됩니다. (platform.kimi.ai)

실패율이 높은 에이전트는 캐시 구조를 고치기 전에 다음을 점검해야 합니다.

• 동일 도구를 무한 반복하지 않는가
• 도구 결과가 비어도 재호출하는가
• 최대 재시도 횟수가 정해져 있는가
• 실패한 요청을 새 작업으로 잘못 기록하는가
• 모델의 출력 형식 오류를 애플리케이션에서 즉시 차단하는가

여섯 번째 단계: 로그로 절약 가능성을 추정하기

실제 청구서를 기준으로 다음 변수를 만드십시오.

• N: 전체 요청 수
• I: 요청 하나의 평균 입력 토큰
• C: 캐시 적중 입력 토큰
• O: 평균 출력 토큰
• R: 성공 작업 하나의 평균 재시도 수
• P: 적중 입력 단가
• U: 미적중 입력 단가
• Q: 출력 단가

작업당 추정 비용은 다음처럼 계산할 수 있습니다.

작업당 비용 =
(C × P + (I - C) × U + O × Q) × (1 + R)

이 식은 단순한 추정식입니다. 실제 로그에서는 요청마다 입력과 출력 길이가 다르므로 평균값만 사용하면 오차가 커질 수 있습니다. 최소한 성공 작업과 실패 작업을 나누고, 상위 비용 작업을 따로 확인하십시오.

의사결정 기준은 아래처럼 잡으면 됩니다.

키미 케이쓰의 요청 문서에는 모델별 출력 한도도 설명되어 있습니다. 키미 케이쓰는 기본 최대 출력 토큰이 131072이며, 설정에 따라 최대 1048576까지 지정할 수 있다고 안내됩니다. 이 값은 긴 답변의 출력 비용과 실패 가능성에 직접 영향을 줄 수 있으므로, 필요한 작업보다 큰 한도를 무조건 지정하지 마십시오. (platform.kimi.ai)

일곱 번째 단계: 모델 전환과 실행 환경을 함께 판단하기

캐시 최적화가 먼저인 경우는 분명합니다.

• 같은 시스템 지침을 많은 요청에서 반복합니다.
• 고정 도구 설명이 큽니다.
• 로그에서 cached_tokens가 지속적으로 확인됩니다.
• 성공 작업당 재시도 횟수가 낮습니다.
• 문서 버전과 조각 순서를 통제할 수 있습니다.

반대로 모델이나 실행 구조를 다시 검토해야 하는 경우도 있습니다.

• 사용자별 문맥이 거의 모두 다릅니다.
• 문서 검색 결과가 매번 크게 바뀝니다.
• 실패와 도구 재호출이 많습니다.
• 출력 토큰이 전체 비용의 핵심입니다.
• 캐시 구조를 유지하는 개발 시간이 절약액보다 큽니다.

이때는 모델 단가만 비교하지 마십시오. 큐 대기, 장시간 실행되는 에이전트 노드, 로그 저장, 장애 대응, 재시도 제어까지 포함해야 합니다. VPSSpark 소개에서 실행 환경을 검토할 때도 토큰 비용과 서버 운영 비용을 분리해 기록하는 편이 좋습니다.

현재 서버나 개발용 컴퓨터에서 에이전트를 계속 돌리는 방식은 시작하기 쉽지만, 전원 관리와 네트워크 안정성, 원격 접근, 재부팅 대응을 직접 맡아야 합니다. 특히 장시간 실행되는 작업은 토큰 단가를 낮춰도 실행 노드가 끊기면 재시도 비용이 다시 쌓입니다. 단기 테스트나 임시 에이전트 노드가 필요하다면 한국 리전 맥 렌탈 환경을 비교 대상으로 넣고, 실제 작업당 비용을 같은 방식으로 측정하십시오.

캐시가 안정적으로 적중되고 재시도도 낮다면 현재 키미 케이쓰 구조를 유지하면서 프롬프트를 정리하는 것이 우선입니다. 적중이 낮다면 문서 분리와 세션 식별자 설계를 먼저 바꾸십시오. 그래도 성공 작업 비용이 높다면 모델 전환보다 먼저 실행 환경과 큐 구조를 함께 계산해야 합니다.

자주 묻는 내용

FAQ는 자동 캐시를 켜는 방법보다, 어떤 입력을 고정하고 어떤 입력을 분리할지에 초점을 맞춰야 합니다. 문서가 같다는 이유만으로 적중을 가정하지 말고, 반환된 사용량 필드와 실제 청구 기록을 대조하십시오.

키미 케이쓰 컨텍스트 캐싱은 반복 문맥이 많은 팀에 유효할 수 있습니다. 그러나 자주 바뀌는 프롬프트, 낮은 재사용률, 긴 출력, 반복 실패가 함께 있다면 자동으로 비용이 낮아지지 않습니다.

이번 주에는 먼저 하루치 또는 한 작업 묶음의 요청 로그를 수집하십시오. 그다음 캐시 적중 입력, 미적중 입력, 출력, 재시도를 분리해 성공 작업당 비용을 계산하십시오. 결과가 분명할 때만 프롬프트 구조 변경이나 실행 환경 확장을 진행하는 순서가 안전합니다.