LLM API 비용이 급증하는 3가지 원인과 토큰 비용 절감 방법

LLM(대규모 언어 모델) API 비용은 서버 대여료처럼 시간 단위로 계산하지 않습니다. 모델이 텍스트를 처리하는 단위인 ‘토큰’을 얼마나 주고받았는지에 따라 계산합니다. 그래서 챗봇이나 요약 기능을 붙여 두면 사용자가 질문 하나를 보낼 때마다 요금이 쌓입니다.

사용자 수는 지난달과 비슷하고 애플리케이션에서 집계한 호출 건수도 크게 늘지 않았는데, 비용만 두 배가 되기도 합니다. 이때 늘어난 것은 호출 하나에 담긴 토큰 수입니다. 재시도로 인한 추가 전송이 원인일 때도 있습니다. 이런 전송은 애플리케이션에서 집계하는 호출 건수에 잡히지 않을 수 있습니다. 재시도로 늘어나는 전송은 세 번째 원인인 ‘중복 재시도와 에이전트 반복 루프’에서 따로 다룹니다.

LLM API의 기본 요금은 입력 토큰과 출력 토큰에 각각 단가를 곱해 계산합니다. 캐시에 쓰고 읽은 토큰, 이미지·음성 입력, 도구 사용처럼 별도 단가가 적용되는 항목도 있습니다. 다만 텍스트 기반 서비스에서는 입력 토큰과 출력 토큰을 나누어 살펴보는 것이 출발점입니다. 별다른 배포나 트래픽 변화 없이 비용이 뛰었다면, 호출 횟수보다 호출당 입력 토큰 수를 먼저 확인하는 편이 빠릅니다.

‍

LLM API 비용이 급증하는 3가지 원인과 절감 방법

LLM API 비용이 급증하는 원인은 세 가지입니다. 대화 이력 누적과 캐시 적중률 하락은 호출 하나에 담긴 토큰을 늘리고, 재시도와 에이전트 루프는 사용자 요청 하나를 여러 번의 API 호출로 번지게 합니다.

‍

1. 대화 이력 누적으로 늘어나는 입력 토큰 (컨텍스트 윈도우 크리프)

일반적인 LLM API 호출은 이전 대화를 자동으로 기억하지 않습니다. 대화를 이어 가려면 애플리케이션이 지난 이력을 다시 보내거나, 제공사가 지원하는 대화 상태 관리 기능을 써야 합니다. 어느 방식을 쓰더라도 모델이 다시 읽는 대화 이력은 입력 토큰에 포함될 수 있습니다.

대화가 길어질수록 호출마다 다시 보내는 이력이 늘고, 그만큼 입력 토큰도 많아집니다. 모델이 한 번에 처리할 수 있는 최대 입력 범위를 컨텍스트 윈도우(context window, 컨텍스트 창)라고 하는데, 누적된 대화 이력이 이 범위를 점점 더 많이 차지합니다.

클라우드 비용 관리 표준을 만드는 리눅스 재단 산하 조직인 FinOps Foundation은 2026년 5월 GenAI 토큰 가격 구조를 다룬 글에서 대화가 이어지며 입력이 조금씩 불어나는 현상을 컨텍스트 윈도우 크리프(context window creep)라고 불렀습니다. FinOps Foundation은 컨텍스트 윈도우 크리프를 "대부분의 프로덕션 AI 애플리케이션에서 가장 큰 숨은 비용"이라고 밝히고, 대화가 길어지면 이력을 다시 보내는 비용이 실제로 생성한 답변의 비용을 넘어설 수 있다고 덧붙였습니다.

증가 폭은 계산으로 추정할 수 있습니다. 시스템 프롬프트(모델에 역할과 말투를 지정해 두는 고정 지시문)가 1,000 토큰, 사용자 질문 하나가 200 토큰이고, 한 턴이 끝날 때마다 대화 이력이 400 토큰씩 늘어나는 챗봇을 가정한 계산 예시입니다.

구분	이력 토큰	입력 토큰
첫 번째 호출	0	1,200
10번째 호출	3,600	4,800
20번째 호출	7,600	8,800
20턴 합계	76,000	100,000

‍

대화 이력을 매번 전송하면 20턴 기준 입력 토큰이 4배 넘게 불어납니다. 2만 4천 토큰이 10만 토큰이 됩니다.

20턴을 주고받은 대화 하나의 입력 토큰 합계는 10만 토큰입니다. 이력을 빼고 시스템 프롬프트와 질문만 보냈다면 2만 4천 토큰입니다. 이력을 함께 보내면 같은 대화의 입력 토큰 합계가 4배 넘게 커집니다.

보내는 이력을 줄이면 입력 토큰 비용을 줄일 수 있습니다. 방법은 2개입니다.

슬라이딩 윈도우: 최근 몇 턴만 보내고 그보다 앞선 대화는 제외합니다. 구현이 단순하고 효과가 바로 나타납니다.
요약 압축: 오래된 대화는 원문 대신 짧은 요약으로 바꿔 보냅니다. 요약을 만들 때도 호출이 한 번 들어가므로 대화가 충분히 길 때만 이득입니다.

슬라이딩 윈도우와 요약 압축 모두 앞선 대화를 잘라 내므로 답변 품질과 맞바꾸는 선택입니다. 몇 턴까지 남길지는 문의 유형별 실제 대화 길이를 확인한 뒤 정합니다. 앞선 대화를 잘라 내면 프롬프트 앞부분이 바뀌어 캐시 적중에도 영향을 줍니다. 프롬프트 캐싱을 쓰는 서비스라면 대화를 잘라 낸 뒤 캐시 적중률이 떨어지지 않는지 함께 확인합니다.

‍

2. 프롬프트 변경으로 떨어지는 캐시 적중률

반복되는 프롬프트에 캐싱을 적용한 서비스에서도 배포나 프롬프트 변경 뒤 비용이 갑자기 오를 수 있습니다. 캐시는 요청 앞부분이 이전 요청과 같은지를 기준으로 재사용됩니다. 시스템 프롬프트 앞부분에 시각, 사용자 정보, 요청 번호처럼 매번 달라지는 값이 들어가면 제공사가 이전과 같은 앞부분으로 인식하지 못해 캐시 적중률(캐시 히트율)이 떨어집니다.

호출마다 앞부분에 반복되는 내용이 있습니다. 역할과 말투를 정한 시스템 프롬프트, 출력 형식 예시, 모든 요청에 공통으로 붙이는 정책 문서입니다. 검색 증강 생성(RAG)으로 찾은 문서도 여러 요청에서 같은 순서로 반복된다면 캐싱 대상이 될 수 있습니다.

프롬프트 캐싱(prompt caching)은 요청 앞부분이 이전 요청과 똑같을 때 제공사가 앞부분을 다시 계산하지 않고 낮은 단가로 청구하는 기능입니다. 제공사는 캐시에서 읽은 토큰을 대개 기본 입력 단가의 0.1배로 청구하고, 2026년 9월에는 0.05배와 0.025배까지 낮춘 모델도 나왔습니다. 반대로 앞부분을 캐시에 처음 써 넣을 때는 기본 단가보다 높은 1.25배를 받기도 합니다. Anthropic은 이전부터 쓰기 요금을 받았고, OpenAI도 2026년 7월 공개한 GPT-5.6부터 쓰기 요금을 매깁니다.

캐시 읽기 단가가 내려갈수록 캐시 적중과 미적중의 요금 차이가 커집니다. 쓰기 1.25배, 읽기 0.025배인 모델에서 같은 앞부분이 캐시에 적중하면 기본 단가의 2.5%를 내고, 적중하지 못해 캐시에 새로 쓰면 125%를 냅니다. 같은 앞부분을 캐시에서 읽을 때와 캐시에 새로 쓸 때의 요금이 호출 하나 기준으로 50배 차이 납니다. 그래서 캐시 단가가 낮은 모델일수록 프롬프트 한 줄을 바꾼 배포의 영향이 청구 금액에 크게 드러납니다.

프롬프트 캐싱을 적용하려면 앞부분이 최소 길이를 넘어야 합니다. OpenAI는 GPT-5.6 이후 모델에서 1,024 토큰, Anthropic은 모델에 따라 512 토큰에서 4,096 토큰, Google은 Gemini 3 계열에서 4,096 토큰을 최소 길이로 안내합니다. Anthropic 문서에 따르면 최소 길이보다 짧은 앞부분에 캐싱을 지정해도 오류 없이 일반 요청으로 처리합니다. 캐싱 설정을 켰다는 사실만으로는 할인 적용을 확인할 수 없습니다.

캐싱 할인을 실제로 받으려면 네 가지를 손봅니다. 프롬프트 순서부터 바꿉니다.

고정 내용을 앞으로: 지침과 예시, 참고 문서처럼 변하지 않는 내용을 프롬프트 맨 앞에 모으고, 사용자 이름이나 시각처럼 매번 달라지는 내용을 뒤로 보냅니다. OpenAI와 Google 문서가 모두 권하는 순서입니다.
앞부분 고정: 시스템 프롬프트에 현재 시각이나 요청 번호를 끼워 넣지 않습니다. 쓰기 요금을 받는 제공사에서는 앞부분이 매번 달라지면 호출마다 쓰기 요금만 내고 할인은 받지 못합니다.
캐시 수명과 호출 간격 맞추기: 캐시 수명은 Anthropic이 기본 5분(1시간 선택 가능), OpenAI GPT-5.6 이후 모델이 30분(마지막 쓰기나 재사용 기준)입니다. 같은 앞부분을 쓰는 호출 간격이 캐시 수명보다 길면 캐시가 만료돼 다시 쓰기 요금을 냅니다.
적중 여부 확인: 응답에 함께 오는 캐시 읽기 토큰과 캐시 쓰기 토큰을 둘 다 기록합니다. 쓰기 토큰만 계속 늘고 읽기 토큰이 늘지 않으면 캐시가 재사용되지 않고 있습니다.

‍

3. 중복 재시도와 에이전트 반복 루프

재시도와 에이전트 루프(에이전트가 같은 동작을 되풀이하는 구간)는 호출 횟수 자체를 늘립니다.

재시도가 있으면 애플리케이션이 세는 호출 건수와 LLM API로 실제 전송된 횟수가 달라질 수 있습니다. 재시도는 대개 라이브러리 안에서 자동으로 일어나기 때문입니다. OpenAI 파이썬 SDK는 연결 오류, 408 요청 시간 초과, 409 충돌, 429 요청 한도 초과, 500 이상 서버 오류를 기본 2회까지 자동으로 다시 보냅니다. 재시도 2회는 최초 시도와 별개이므로, SDK 호출 하나가 실제로 보내는 전송은 최대 3회입니다. 애플리케이션 코드에서 같은 호출을 최초 시도까지 합쳐 3회 시도하도록 감싸 두었다면 요청 하나가 최대 9회 전송으로 늘어납니다. 재시도할 때마다 같은 프롬프트가 새 요청으로 전송됩니다. 제공사가 요청을 처리한 뒤 응답 전달 단계에서 실패했다면 해당 호출과 재시도 호출이 모두 사용량에 잡힐 수 있습니다. 그래서 전송 횟수와 실제 사용량을 함께 확인해야 합니다.

요청 1건이 최대 9회 전송으로 늘어나는 흐름을 왼쪽에서 오른쪽으로 그린 도식. 왼쪽은 실패 시 최대 3회 시도하는 애플리케이션으로 1차 시도, 2차 시도, 3차 시도가 놓여 있다. 가운데는 SDK 자동 재시도로, 각 시도마다 SDK 1, SDK 2, SDK 3까지 최대 3회를 전송한다. 오른쪽은 같은 요청을 반복해서 받는 LLM API이고 3 곱하기 3으로 최대 9회 전송이 된다. 애플리케이션 시도 3회는 가정한 값이다

재시도를 SDK와 애플리케이션 두 곳에서 하면 전송 횟수가 곱으로 늘어납니다. SDK 재시도 2회는 기본값, 애플리케이션 시도 3회(최초 포함)는 가정한 값입니다.

모델이 도구를 직접 골라 쓰며 여러 단계를 스스로 진행하는 AI 에이전트에서는 증가 폭이 더 큽니다. 에이전트는 도구를 부르고 결과를 읽고 다음 행동을 정하는 동작을 반복합니다. 이 한 단위를 스텝이라고 부릅니다. 스텝마다 LLM을 새로 호출하고, 지금까지의 도구 호출 기록도 다음 스텝의 입력에 쌓입니다. 컨텍스트 윈도우 누적과 겹치므로 에이전트 루프에서는 호출 횟수와 호출당 입력 토큰이 함께 늘어날 수 있습니다. 종료 조건을 잘못 정하면 같은 도구를 계속 부르며 멈추지 않습니다.

에이전트 실행 단위로 호출 수와 누적 토큰에 상한을 둡니다. 상한을 정해 두면 반복이 멈추지 않아 비용이 끝없이 늘어나는 경우를 막을 수 있습니다.

스텝 상한: 에이전트 프레임워크는 대개 반복 횟수 상한을 제공합니다. OpenAI Agents SDK에서는 반복 횟수가 max_turns 값을 넘으면 MaxTurnsExceeded 예외가 발생하고 실행이 멈춥니다. 상한을 끄는 옵션도 있으므로 운영 환경에서 켜 둔 상태인지 확인합니다.
요청당 토큰 상한: 요청 하나가 쓸 수 있는 누적 토큰 수를 정하고 넘으면 중단합니다. 멈추지 않는 반복을 그대로 두는 것보다 요청 몇 건을 중단시키는 편이 손실이 작습니다.
재시도 규칙 정리: 재시도는 SDK와 애플리케이션 가운데 한 곳에서만 합니다. 400, 401, 404처럼 요청 자체가 잘못돼 다시 보내도 결과가 같은 실패는 재시도 대상에서 제외합니다. 429 응답을 받았을 때 대기 시간을 정하는 방법은 429 Too Many Requests 원인과 해결 방법에서 지수 백오프와 지터로 나눠 설명합니다.

‍

프롬프트 캐싱 가격 비교와 캐시 쓰기 비용 계산 (2026년 9월 기준)

프롬프트 캐싱 가격은 2026년 들어 제공사마다 여러 번 바뀌었습니다. 각 제공사의 공식 가격 페이지와 변경 기록에서 확인했습니다.

Anthropic: 2026년 9월 1일 공개한 Claude Fable 5.1과 Claude Mythos 5.1(한정 제공)의 캐시 읽기 단가를 기본 입력 단가의 0.025배(100만 토큰당 0.25달러)로 정했습니다. 직전 모델 Claude Fable 5는 0.1배(100만 토큰당 1달러)입니다. 9월 22일 공개한 Claude Opus 5.5는 가격 페이지에 캐시 읽기 0.05배로 나와 있고, 나머지 모델은 0.1배입니다. Fable 5.1을 공개하면서 캐시 쓰기 단가는 바꾸지 않았습니다.
OpenAI: 2026년 7월 9일 공개한 GPT-5.6과 이후 모델의 캐시 읽기는 대부분 0.1배입니다. 9월 29일 공개한 GPT-6.1 Sol은 0.05배입니다(100만 토큰당 입력 2달러, 캐시 입력 0.1달러). 캐시 쓰기는 GPT-5.6부터 기본 입력 단가의 1.25배를 받습니다. 그 이전 모델은 쓰기 요금이 없고 읽기 단가가 모델마다 다릅니다. 보관 조건도 바뀌었습니다. 2026년 5월 29일에는 캐시 보관 설정(prompt_cache_retention)의 기본값을 메모리 보관(in_memory)에서 최대 24시간 보관(24h)으로 바꿨습니다(데이터 무보관 설정을 쓰지 않는 조직 대상). 현재 가이드는 이 설정을 GPT-5.6 이전 모델용으로 설명합니다.
Google Gemini: Gemini 2.5 이후 모델에는 암시적 캐싱(별도 설정 없이 자동으로 적용되는 캐싱)이 기본으로 켜져 있습니다. Gemini 3.8 Flash의 캐시 단가는 입력 단가의 0.1배(100만 토큰당 0.075달러)입니다. 명시적으로 만든 캐시에는 저장 시간당 요금을 따로 받습니다. Gemini 3.8 Flash의 입력, 캐시, 저장 단가는 2026년 12월 31일까지 적용하는 값이며 2027년 1월 1일부터 두 배로 오릅니다.

항목	Anthropic	OpenAI	Google Gemini
캐시 읽기	기본 0.1배, 최신 일부 모델 0.05배와 0.025배	0.1배(GPT-5.6 이후), GPT-6.1 Sol 0.05배	0.1배(Gemini 3.8 Flash, 3.1 Pro Preview)
캐시 쓰기	1.25배(5분), 2배(1시간)	1.25배(GPT-5.6 이후)	가격표에 쓰기 단가 항목 없음
캐시 수명	기본 5분, 1시간 선택	30분, 마지막 쓰기나 재사용 기준(GPT-5.6 이후)	명시적 캐시는 저장 시간만큼 과금
최소 길이	모델별 512 ~ 4,096 토큰	1,024 토큰(GPT-5.6 이후)	4,096 토큰(Gemini 3 계열)

배수는 모두 해당 모델의 기본 입력 단가 대비 값입니다. 가격은 2026년 9월 29일 Anthropic 가격 페이지와 Gemini API 가격 페이지, 2026년 9월 30일 OpenAI 프롬프트 캐싱 가이드와 가격 페이지를 조회한 값이며 미국 달러 기준입니다. 제공사가 단가와 조건을 자주 바꾸므로 적용 전에 현재 문서를 다시 확인합니다.

단가가 바뀌면 캐시 적중률이 비용에 주는 영향도 달라집니다. 고정 앞부분이 10,000 토큰이고, 캐시 수명 안에서 같은 앞부분으로 100번 호출하는 기능을 가정한 계산 예시입니다. 값은 기본 입력 단가로 환산한 토큰 수이고, 질문처럼 매번 바뀌는 뒷부분은 네 경우 모두 비용이 같으므로 뺐습니다.

경우	계산	환산 입력 토큰
캐싱 없음	10,000 × 100 × 1	1,000,000
쓰기 1.25배, 읽기 0.1배	12,500 + 990,000 × 0.1	111,500
쓰기 1.25배, 읽기 0.025배	12,500 + 990,000 × 0.025	37,250
앞부분이 매번 바뀜(쓰기 1.25배)	10,000 × 100 × 1.25	1,250,000

캐시 읽기 단가가 0.025배인 모델에서 같은 앞부분이 매번 적중하면 입력 비용이 캐싱 없을 때의 4% 아래로 내려갑니다. 앞부분이 매번 바뀌면 캐싱을 쓰지 않을 때보다 25% 더 나옵니다.

첫 호출은 앞부분 10,000 토큰을 캐시에 쓰므로 1.25배를 적용해 12,500이 됩니다. 나머지 99번은 캐시에서 읽으므로 990,000 토큰에 읽기 배수를 곱합니다. 읽기 단가가 0.1배에서 0.025배로 내려가면 같은 호출 100번의 입력 비용이 111,500에서 37,250으로 3분의 1 수준이 됩니다. 앞부분에 시각을 한 줄 넣어 매번 바뀌게 만들면 100번 모두 쓰기 요금을 내 1,250,000이 됩니다.

캐시 쓰기 요금이 있는 모델에서는 캐싱 설정을 켜 두기만 해서는 비용이 줄지 않습니다. 총액은 쓰기 한 번에 읽기가 몇 번 이어지는지에 따라 달라집니다. Anthropic 가격 페이지는 5분 캐시는 한 번, 1시간 캐시는 두 번 읽으면 쓰기 요금을 회수한다고 설명합니다.

‍

LLM 비용 급증에 대비해 기록해야 할 5가지

청구서만 보면 챗봇과 요약 기능 가운데 어느 쪽이 얼마를 썼는지 구분하기 어렵습니다. 청구서만으로 확인하면 원인 파악 시점도 늦습니다. 호출할 때 직접 남겨 두지 않으면 나중에 확인할 방법이 없습니다. 호출마다 다음 다섯 묶음의 값을 남깁니다.

입력 토큰 수와 출력 토큰 수: 응답에 사용량이 함께 오므로 그대로 남깁니다. 둘을 합치지 않고 나눠 남겨야 어느 쪽이 늘었는지 알 수 있습니다.
캐시에서 읽은 토큰 수와 캐시에 쓴 토큰 수: 할인을 실제로 받고 있는지, 쓰기 요금만 내고 있지는 않은지 확인하는 값입니다.
모델 이름과 기능 구분: 챗봇, 요약, 분류처럼 기능을 태그로 남기면 비용을 기능별로 나눠 볼 수 있습니다. 같은 제공사 안에서도 모델마다 캐시 단가가 다르므로 모델 이름이 있어야 비용을 다시 계산할 수 있습니다.
대화 또는 요청 식별자: 호출 하나가 아니라 대화 하나가 쓴 누적 토큰을 세려면 필요합니다.
재시도 횟수와 에이전트 스텝 수: 호출 수가 늘어난 원인을 구분합니다.

다섯 묶음은 모두 기록하되, 매일 추이로 볼 값은 따로 골라 둡니다.

호출당 입력 토큰 중앙값: 중앙값은 값을 크기 순으로 줄 세웠을 때 가운데 오는 값입니다. 평균은 아주 긴 호출 몇 건에 끌려가므로 중앙값을 씁니다.
대화당 누적 토큰 95번째 백분위수(p95): 대화 100개를 토큰이 적은 순으로 줄 세웠을 때 95번째 대화가 쓴 토큰입니다. 중앙값은 그대로인데 95번째 백분위수만 오르면 긴 대화 몇 건에서 비용이 늘고 있습니다.
캐시 읽기 토큰 비율(캐시 적중률): 전체 입력 토큰 가운데 캐시에서 읽은 토큰의 비율입니다. 캐싱을 적용했는데 비율이 낮으면 프롬프트 앞부분이 매번 달라지고 있습니다. 쓰기 요금을 받는 모델이라면 캐시 쓰기 토큰 대비 읽기 토큰의 배수도 함께 봅니다.

알림 기준을 절대 토큰 수로 고정하면 트래픽이 늘 때마다 울립니다. 호출당 입력 토큰 중앙값과 대화당 누적 토큰 95번째 백분위수를 각각 지난 2주 기준선과 견줍니다. 중앙값이 오르면 전반적인 입력이 길어진 것이고, 95번째 백분위수만 오르면 일부 긴 대화나 에이전트 실행에서 비용이 커진 것입니다. 배포 직후 캐시 읽기 토큰 비율이 떨어지면 프롬프트 앞부분이 바뀌었는지부터 확인합니다.

기록할 값의 이름은 직접 정하지 않아도 됩니다. OpenTelemetry는 관측 데이터의 항목 이름을 표준으로 정해 둔 시맨틱 컨벤션(semantic conventions)을 두고 있고, 여기에 LLM 호출용 토큰 항목이 있습니다. OpenTelemetry는 현재 생성형 AI 규격을 별도 저장소인 OpenTelemetry GenAI semantic conventions에서 관리합니다.

OpenTelemetry에서는 호출 하나의 사용량을 스팬(호출 하나처럼 작업 한 단위를 기록한 데이터)의 속성에 그대로 남기고, 여러 호출을 합친 값은 메트릭으로 집계합니다. 먼저 호출 하나를 기록하는 스팬에는 gen_ai.usage.input_tokens와 gen_ai.usage.output_tokens를 붙입니다. 캐시에서 읽은 토큰은 gen_ai.usage.cache_read.input_tokens, 캐시에 쓴 토큰은 gen_ai.usage.cache_write.input_tokens입니다. 캐시 쓰기 속성은 예전 이름이 gen_ai.usage.cache_creation.input_tokens였으므로 기존 대시보드를 쓰고 있다면 이름을 확인합니다. 규격은 입력 토큰 수에 캐시에서 읽고 쓴 토큰까지 포함해 기록하도록 정합니다.

여러 호출의 합계를 집계하는 메트릭은 이름이 바뀌는 중입니다. 새 저장소에는 메트릭 변경이 두 가지 들어가 있습니다. 하나는 기존 gen_ai.client.token.usage 히스토그램과 gen_ai.token.type 속성을 입력용과 출력용 히스토그램(gen_ai.client.inference.operation.input_tokens, gen_ai.client.inference.operation.output_tokens)으로 바꾸는 변경입니다. 다른 하나는 캐시 읽기와 쓰기, 추론 토큰까지 나눈 카운터(gen_ai.client.inference.usage.*)를 새로 두는 변경입니다. 2026년 9월 30일 기준 이 변경은 정식 릴리스 전입니다. 스팬 속성과 메트릭 모두 개발 단계(development) 규격이라 이름이 다시 바뀔 수 있습니다. 호출마다 스팬 속성에 값을 그대로 남겨 두면 메트릭 이름이 바뀌어도 다시 집계할 수 있습니다.

‍

자주 묻는 질문

컨텍스트 윈도우가 큰 모델로 바꾸면 해결되나요?

오히려 늘어날 수 있습니다. 윈도우가 커지면 더 많은 이력과 문서를 넣게 되고, 넣은 만큼 입력 토큰으로 청구됩니다. 윈도우 크기는 넣을 수 있는 상한이고, 얼마를 넣을지는 애플리케이션이 정합니다.

더 저렴한 모델로 바꾸면 비용이 그만큼 줄어드나요?

토큰 단가만 보면 줄어듭니다. 다만 작은 모델이 형식을 틀려 재시도가 늘거나 답을 길게 늘여 출력 토큰이 늘면 총액은 오히려 오를 수 있습니다. FinOps Foundation도 토큰 단가만 보지 말고 성공적으로 끝난 작업을 기준으로 판단하라고 권합니다. 캐시 적중률이 높은 서비스라면 입력 단가보다 캐시 읽기 단가를 비교해야 실제 차이가 드러납니다. 작은 모델로 바꾼 뒤에도 답변 품질이 유지되는지 확인하는 방법은 LLM 답변 품질 평가 방법과 LLM-as-a-Judge 활용법에서 설명합니다.

프롬프트 캐시 수명(TTL)을 1시간으로 늘리면 비용이 줄어드나요?

같은 앞부분을 쓰는 호출 간격이 5분보다 길고 1시간보다 짧을 때 이득입니다. Anthropic 기준 1시간 캐시는 쓰기 단가가 기본 입력 단가의 2배라서, 캐시 수명 안에서 두 번 이상 읽어야 쓰기 요금을 회수합니다. 호출이 5분 안에 계속 이어지는 기능이라면 기본 5분 캐시로도 만료 전에 다시 읽으므로 1시간 캐시로 바꿀 이유가 없습니다.

비동기 배치 할인과 캐시 할인은 함께 받을 수 있나요?

제공사와 모델에 따라 다릅니다. Anthropic 가격 페이지는 캐시 배수가 배치 할인(50%)과 함께 적용된다고 밝히고, OpenAI 가격표도 배치 요청의 캐시 입력 단가를 표준의 절반으로 둡니다. Gemini 3.1 Pro Preview 가격표는 배치 요청의 캐시 단가를 표준과 같게 둡니다. 리포트 생성이나 대량 분류처럼 몇 시간 뒤에 결과를 받아도 되는 작업이라면 두 할인이 겹치는지 모델별 가격표에서 확인한 뒤 배치로 옮깁니다.

‍

마치며

애플리케이션에서 세어 본 호출 건수가 비슷한데 토큰 비용이 올랐다면, 호출 하나에 담긴 입력 토큰이 늘었는지 먼저 확인합니다. 그다음 SDK 재시도 때문에 실제 API 전송 횟수가 따로 늘지 않았는지 봅니다. 대화 이력을 얼마나 보낼지 정하고, 재시도와 에이전트 스텝에 상한을 두면 금액이 갑자기 뛰는 일을 대부분 막을 수 있습니다. 캐시 읽기 단가가 0.025배인 모델에서는 프롬프트 앞부분을 고정했는지에 따라 같은 호출 100번의 입력 비용이 30배 넘게 차이 납니다. 호출마다 캐시에 쓰고 읽은 토큰을 따로 남겨 두어야 배포 뒤 금액이 움직일 때 원인을 바로 찾을 수 있습니다.

토큰이 어느 모델과 애플리케이션에서 늘었는지, 캐시 적중률이 언제 떨어졌는지 함께 보려면 와탭 AI Agent Observability를 참고하실 수 있습니다.

‍