-
AI 캐시 토큰 비용을 일반 입력 토큰과 따로 계산해야 할 때AI Agent 2026. 9. 25. 10:03728x90반응형

비용 항목을 나누어 계산하는 방식을 비유한 AI 생성 개념 이미지입니다. AI 비용을 합산할 때는 캐시 토큰이 입력 합계에 포함되는지부터 확인하고 각 범주의 단가를 같은 단위로 맞추세요.
사용량 응답에 입력 토큰과 캐시 읽기 토큰이 따로 보입니다. 두 값에 각각 가격을 곱해 더하면 될 것 같지만, 입력 토큰 안에 캐시 토큰이 이미 포함돼 있다면 일부를 두 번 계산할 수 있습니다.
반대로 캐시 사용량이 별도 집계인데 입력 합계에서 무조건 빼도 틀립니다. 숫자보다 먼저 포함 관계를 확인해야 합니다. 이 글은 2026년 9월 13일 Cloudflare AI Gateway 문서를 기준으로 설명하며, 예제 단가는 계산을 위한 가정입니다. 특정 모델의 실제 판매 가격이나 청구 내역이 아닙니다.
캐시라는 말이 가리키는 위치부터 나눕니다
모델 공급자의 프롬프트 캐시는 입력 일부를 재사용하고 그 사용량을 캐시 토큰으로 보고할 수 있습니다. 이때 캐시 읽기나 쓰기에 별도 단가가 적용되는지와 사용량이 어떤 필드에 포함되는지 확인해야 합니다.
AI Gateway의 응답 캐시는 다른 층입니다. 같은 요청에 대해 저장한 응답을 반환해 모델 공급자까지 요청하지 않을 수 있습니다. 공급자가 입력 캐시를 읽는 경우와 게이트웨이가 응답 전체를 재사용하는 경우는 비용을 따로 구분해야 합니다. AI Gateway의 응답 캐시
따라서 로그에 HIT라는 표시가 있을 때도 어떤 캐시의 적중인지 먼저 봅니다. 공급자 캐시 토큰 수와 게이트웨이 응답 캐시 상태를 하나의 비율로 합치면 절감 효과의 기준이 어긋납니다.
이 글의 첫 계산은 모델 공급자까지 요청이 도달했고, 입력 합계 안에 캐시 읽기 토큰이 포함된 경우를 가정합니다. 캐시 쓰기 토큰은 없는 단순 예시입니다.
포함형 입력에서는 캐시를 빼고 일반 입력을 계산합니다
가상의 사용량이 입력 합계 10000토큰, 그중 캐시 읽기 6000토큰, 출력 1000토큰이라고 하겠습니다. 일반 입력은 10000−6000=4000토큰입니다. 캐시 6000이 입력 합계의 일부라는 조건이 이 식의 핵심입니다.
일반 입력은 100만 토큰당 3달러, 캐시 읽기는 0.30달러, 출력은 12달러라고 가정하겠습니다. 실제 요금표에서 가져온 가격이 아니라 서로 다른 단가를 적용하는 방법을 보여 주기 위한 수치입니다.
계산은 일반 입력 4000×3÷1000000=0.012달러, 캐시 읽기 6000×0.30÷1000000=0.0018달러, 출력 1000×12÷1000000=0.012달러입니다. 합계는 0.0258달러입니다.
입력 합계 10000 전체에 일반 단가를 곱한 뒤 캐시 6000 비용을 더하면 캐시 부분을 중복 계산합니다. 반대로 모든 입력에 캐시 단가를 적용하면 실제로 새로 처리한 4000토큰의 가격이 빠집니다.
Cloudflare의 custom costs 문서도 공급자·모델에 따라 캐시가 입력에 포함되는 경우와 별도 보고되는 경우를 구분해 처리한다고 설명합니다. 필드 이름이 input이라고 같아 보여도 수집한 API의 정의를 확인해야 합니다. 캐시 토큰의 포함 관계
작은 계산 함수에도 포함 관계를 드러냅니다
다음은 앞의 포함형·캐시 읽기 전용 가정을 코드로 옮긴 예시입니다. 일반적인 모든 공급자 사용량을 자동으로 해석하는 함수가 아닙니다. 금액은 십진수 계산으로 표시합니다.
from decimal import Decimal def cost_with_inclusive_cache_read(total_input, cache_read, output): counts = (total_input, cache_read, output) if any(type(value) is not int or value < 0 for value in counts): raise ValueError("확인된 음이 아닌 정수 사용량이 필요합니다.") if cache_read > total_input: raise ValueError("포함형 입력에서 캐시 읽기가 입력 합계를 넘었습니다.") fresh_input = total_input - cache_read million = Decimal("1000000") return ( Decimal(fresh_input) * Decimal("3") + Decimal(cache_read) * Decimal("0.30") + Decimal(output) * Decimal("12") ) / million example_cost = cost_with_inclusive_cache_read(10000, 6000, 1000) assert example_cost == Decimal("0.0258")함수 이름에 inclusive와 cache_read를 넣은 것은 적용 범위를 드러내기 위해서입니다. 캐시 쓰기가 있거나 입력이 별도 보고되는 API에 같은 함수를 그대로 쓰지 않습니다.
누락된 값도 0으로 대신하지 않습니다. 이 예시에서는 None이나 음수, 캐시 읽기가 입력 합계를 넘는 값을 오류로 처리합니다. 데이터가 이상할 때도 그럴듯한 금액을 반환하게 만들면 집계 오류를 발견하기 어려워집니다.
실제 구현에서는 공급자 원본 사용량과 정규화한 범주를 둘 다 남겨 두는 편이 좋습니다. 어떤 정의로 일반 입력을 계산했는지 추적할 수 있어야 요금표나 응답 형식이 바뀔 때 다시 검증할 수 있습니다.
캐시 쓰기와 세부 토큰은 무조건 모두 더하지 않습니다
캐시 읽기는 이미 저장한 입력을 사용하는 범주이고 캐시 쓰기는 캐시에 새 내용을 만드는 범주로 보고될 수 있습니다. 단가와 입력 합계에 포함되는 방식은 공급자 계약에 따라 확인해야 합니다. 쓰기도 읽기와 같은 가격이라고 가정하지 않습니다.
포함형 API가 서로 겹치지 않는 일반 입력·캐시 읽기·캐시 쓰기를 합쳐 입력 합계로 보고한다면 일반 입력은 합계에서 두 캐시 범주를 빼는 방식이 될 수 있습니다. 별도 보고형이라면 이미 일반 입력인 필드에 캐시 비용을 추가하는 방식이 됩니다.
이때 모든 세부 필드가 서로 겹치지 않는 것은 아닙니다. 예를 들어 전체 캐시 읽기 안에 이미지 캐시 읽기 같은 세부 범주가 들어 있을 수 있습니다. 전체와 하위 범주를 모두 독립 사용량처럼 더하면 다시 중복됩니다.
OpenTelemetry의 고정 GenAI 문서도 상세 사용량을 합계의 부분집합으로 설명합니다. 관측 시스템에서 정규화된 값이라면 공급자의 원래 응답과 정규화 규칙을 함께 확인해야 합니다. GenAI 사용량의 합계·부분집합
집계 표에 열이 많다는 이유로 모든 열을 합산하지 않습니다. 각 열에 “합계”, “합계에 포함되는 부분”, “별도 추가” 중 어떤 관계가 있는지 먼저 적으면 계산식을 검토하기 쉬워집니다.
AI Gateway custom cost에는 토큰 한 개당 단가를 넣습니다
Cloudflare는 2026년 9월 9일 custom costs에 캐시 읽기·쓰기 단가 지원을 추가했다고 안내했습니다. cf-aig-custom-cost 헤더의 per_token_in, per_token_out, per_cache_read_token, per_cache_write_token으로 범주별 값을 지정합니다. 변경 안내
이 값은 100만 토큰당 가격이 아니라 토큰 하나당 단가입니다. 앞의 가상 가격을 쓰고 캐시 쓰기는 별도로 100만 토큰당 3.75달러라고 가정하면 헤더의 JSON 값은 다음처럼 환산됩니다. 실제 요청을 전송한 설정이 아닙니다.
{ "per_token_in": 0.000003, "per_token_out": 0.000012, "per_cache_read_token": 0.0000003, "per_cache_write_token": 0.00000375 }일반 입력 가격 3을 그대로 per_token_in에 넣으면 예시에서 의도한 단위와 백만 배 차이가 납니다. 소수점이 많아 보인다는 이유로 임의로 반올림하기 전에 단위를 맞춰야 합니다.
캐시 단가 중 하나만 지정하면 빠진 다른 캐시 단가는 per_token_in을 기본값으로 사용합니다. 둘 다 생략하면 기존 입력·출력 계산을 유지합니다. 하나를 생략했다고 단가가 0이 되거나 공급자의 별도 캐시 단가가 자동으로 들어간다고 가정하지 않습니다. 캐시 단가의 활성화와 기본값
이 헤더는 게이트웨이의 비용 기록에 사용할 custom rate를 전달하는 기능입니다. 공급자와 맺은 계약이나 청구 가격 자체를 바꾸는 할인 요청으로 이해해서는 안 됩니다. 실제 적용 결과는 해당 요청의 비용 기록에서 확인해야 합니다.
사용량이 없으면 계산하지 못한 비용으로 남깁니다
AI Gateway 문서는 응답에 토큰 정보가 없는 요청은 custom cost를 계산하지 않는다고 설명합니다. 호출이 있었지만 금액을 계산할 자료가 없는 상황과, 사용량이 실제 0인 상황은 다릅니다. 사용량이 필요한 비용 계산
내부 집계에서도 사용량 누락 건수를 따로 남기는 편이 좋습니다. 금액이 비어 있는 요청을 0원으로 바꾸면 총비용이 작아 보이고, 특정 공급자나 실패 응답에서 정보가 빠지는 문제를 놓칠 수 있습니다.
한편 게이트웨이 응답 캐시에서 바로 반환한 요청은 custom cost 문서상 비용이 0으로 기록됩니다. 이는 공급자에 새 요청이 가지 않은 경우의 모델 비용 기록입니다. 시스템의 저장·네트워크·게이트웨이 운영 비용까지 모두 없다는 뜻은 아닙니다.
그래서 집계에는 최소한 공급자 요청 여부, 게이트웨이 캐시 상태, 원본 토큰 정보의 존재와 적용한 단가 출처가 구분돼야 합니다. 같은 숫자 0도 어떤 근거로 나온 값인지 확인할 수 있어야 합니다.
청구서와 맞출 때는 기간과 가격 버전도 필요합니다
사용량 계산이 맞더라도 청구서와 차이가 날 수 있습니다. 비교 기간과 시간대, 가격 적용 시점, 통화와 반올림 단위, 별도 부가 비용이나 계약 조건을 같은 기준으로 확인해야 합니다. 이 글의 가상 계산은 그런 항목을 포함한 실제 청구 예측이 아닙니다.
모델의 이름이나 단가가 바뀌었다면 과거 요청에 현재 가격을 일괄 적용할지, 요청 당시 가격을 적용할지 정해야 합니다. 어느 방식을 썼는지 기록하지 않으면 같은 원본으로도 보고서 금액이 달라질 수 있습니다.
검증용 사례에는 캐시 없는 요청, 전부 또는 일부 캐시 읽기인 요청, 캐시 쓰기가 있는 요청, 사용량 없는 요청과 게이트웨이 응답 캐시 적중을 나눠 넣습니다. 공급자별로 포함형·별도형이 다르면 각각의 원본 사용량으로 계산을 대조합니다.
최종 합계만 비교하기보다 일반 입력·캐시 읽기·캐시 쓰기·출력의 부분 금액을 확인하면 어디서 어긋났는지 찾기 쉽습니다. 값을 맞추려고 근거 없는 보정 계수를 추가하기 전에 포함 관계와 단위를 다시 봅니다.
비용 계산은 토큰 이름보다 정의가 먼저입니다
캐시 토큰을 별도 단가로 계산하는 것은 유용하지만, 열 하나를 더해 곱셈을 추가하는 일로 끝나지는 않습니다. 입력 합계의 포함 범위와 캐시 계층, 단가 단위와 누락 처리까지 맞아야 합니다.
먼저 원본 사용량에서 중복 없이 범주를 나누고, 각 단가를 같은 단위로 환산한 뒤, 계산한 값과 계산하지 못한 요청을 구분합니다. 그 과정이 남아 있어야 캐시가 실제로 얼마를 줄였는지, 비용 차이가 어디서 생겼는지 설명할 수 있습니다.
728x90반응형'AI Agent' 카테고리의 다른 글
모델을 INT8로 줄였는데 결과가 달라진 이유 (0) 2026.09.28 model.eval()과 inference_mode()는 왜 둘 다 필요할까 (0) 2026.09.28 확장자 없는 R2 파일을 AI Search가 읽게 하려면 (0) 2026.09.23 max_new_tokens를 늘리면 긴 문서를 더 많이 읽을까 (0) 2026.09.23 맥에서 Ollama를 Docker로 돌리면 GPU도 사용할 수 있을까 (0) 2026.09.23