요청 한 번에 $0.06.. LLM 비용을 줄이기 전에 먼저 봐야 할 것

ppogeul 2026. 5. 20. 11:54

2026. 5. 20. 11:54

반복되는 기준 문서는 캐시에 두고, 사료별 입력만 새로 처리하는 Prompt Caching 구조를 표현한 AI 생성 이미지!

이번 프로젝트의 첫 글이니 배경을 간단히 적자면, 해당 프로젝트는 사료 라벨과 성분 정보를 바탕으로 보호자에게 보여줄 사료 성적표를 만든다. 성적표의 핵심 판단은 규칙 기반 파이프라인이 담당한다. LLM은 등급이나 사실을 새로 판단하지 않고 이미 계산된 결과를 보호자가 읽기 쉬운 문장으로 다듬는 역할만 맡는다.

그런데 이 문장 다듬기 한 번에 약 `$0.06`이 나왔다..

처음에는 모델 단가부터 의심했다.. 문장 몇 개를 다듬는 일인데 한 번에 `$0.06`이면 운영 비용으로 부담이 크다고 느꼈다.

다만 바로 모델을 낮추거나 프롬프트를 줄이기 전에, 먼저 실제 usage부터 확인했다. 비용이 정말 이상하게 나온 것인지, 아니면 내가 요청의 크기를 작게 착각하고 있었는지부터 분리해서 봐야 했다.

확인해보니 과금 자체는 이상하지 않았다.

input_tokens: 14,448
output_tokens: 1,034
model: claude-sonnet-4-20250514
cache_creation_input_tokens: 0
cache_read_input_tokens: 0

Anthropic 공식 가격표 기준으로 Claude Sonnet 4 계열은 입력 `$3 / 1M tokens`, 출력 `$15 / 1M tokens`다.

계산은 단순했다.

입력: 14,448 * $3 / 1,000,000 = 약 $0.043
출력: 1,034 * $15 / 1,000,000 = 약 $0.015
합계: 약 $0.058

이걸 보니.. `$0.06`은 당연한 과금이었다 🥲

(해당 문단은 읽지 않아도 괜찮아요!)

이 과정에서 하나 더 발견한 것도 있었다. 당시 프로젝트에서 쓰던 `claude-sonnet-4-20250514`는 2026년 5월 기준 Anthropic 문서에서 deprecated 상태로 표시되어 있었다. deprecated는 아직 동작하지만 더 이상 권장되지 않는 상태인데, retirement 이후에는 실패할 수 있다. 문서에 적힌 retirement 예정일은 2026년 6월 15일 이었고 바로 `claude-sonnet-4-6`으로 변경했다 😎

그래서 이 문제는 두 갈래였다.

하나는 `$0.06`이 왜 나왔는지 이해하는 것!

다른 하나는 deprecated 모델을 계속 쓰지 않도록 기본 모델을 바꾸는 것!

둘은 관련은 있지만 같은 문제는 아니었다. 모델을 바꾼다고 이 요청이 갑자기 싸지는 것이 아니었기 때문이다.. Sonnet 4와 Sonnet 4.6의 기본 입력/출력 단가는 같은 구간이었고 그렇기에 비용 문제는 요청 구조를 봐야 했다.

다만 바로 프롬프트를 줄이기엔 불안했다. 이 1.4만 토큰 안에는 무의미한 문장이 아니라, 사료 성적표의 품질을 맞추기 위한 기준 문서와 모범 예시가 들어 있었다. 과금이 정상이라는 것과, 그 프롬프트 양이 최적이라는 것은 다른 문제였기에.. 비용이 왜 발생했는지 확인하고 나서 무엇을 유지하고 무엇을 줄일 수 있는지 나눠서 봐야 했다.

여기서부터 읽기 편하게 주제를 나눠보겠다

문제는 모델이 아니라 요청 구조였다

사료 성적표를 만들 때 LLM 호출에는 사료마다 달라지는 정보만 들어가지 않았다. 예를 들어 특정 제품의 원재료, 보증성분, 칼슘/인 표기 여부, 처방식 여부처럼 제품 라벨에서 추출한 사실 데이터가 들어간다. 그런데 여기에 더해, 문장 품질을 맞추기 위한 고정 문서도 함께 들어갔다.

예를 들면 이런 것들이다.

- 2026년 사료 성적표 작성 가이드
- 보호자용 문장 톤앤매너
- 내부 채점 용어를 노출하지 말라는 규칙
- 칼슘/인 누락, 처방식 등 필수 고지 문구
- 참고를 위한 모범 성적표 예시

이 문서들은 사료가 바뀌어도 거의 동일하다. 로얄캐닌을 분석할 때도 들어가고, 다른 브랜드를 분석할 때도 들어간다. 그런데 캐싱이 없으면 매 요청마다 같은 문서를 새 입력 토큰으로 결제한다.

그렇게 정리한 요청 구조 문제는 이렇다.

사료별로 달라지는 정보는 일부인데, 사료별로 달라지지 않는 긴 기준 문서가 매번 새로 읽히고 있었다.

하지만 이 기준 문서를 얼마나 줄일 수 있는지는 별도라 생각한다. 무작정 줄이면 비용은 내려가겠지만, 성적표 문장이 모범 성적표 예시에서 멀어질 수 있다. 그래서 첫 번째 선택지는 프롬프트 축소가 아니라 캐싱이었다. 같은 기준 문서를 유지하되, 반복 입력 비용부터 줄이는 쪽이 품질 리스크가 가장 작았다.

Prompt Caching은 답변 캐시가 아니다

Prompt Caching은 완성된 성적표를 저장해두는 기능이 아니다. LLM 모델이 반복되는 프롬프트 앞부분을 다시 처리하지 않도록 재사용하는 기능이다.

이때 반복되는 앞부분을 캐시 대상이 되는 고정 프롬프트라고 부르겠다.

내가 생각하는 좋은 구조는 이렇다.

[고정 시스템 지침]
[사료 성적표 작성 가이드]
[모범 성적표 예시]
[필수 고지 규칙]
------------------------- 여기까지를 cache 대상으로 봤다
[사료별로 달라지는 원재료·성분표·급여 정보]
[룰 엔진이 이미 계산한 등급 결과]
[룰 엔진이 만든 기본 사료 등급표]
[이번 요청의 사용자 조건]

위쪽의 고정 지침과 예시는 사료가 바뀌어도 거의 같다. 그래서 cache 대상이 된다.

하지만 구분선 아래의 내용은 요청마다 달라진다. 이 값들은 cache 대상이 아니다. 특히 `룰 엔진이 이미 계산한 등급 결과`는 LLM이 새로 만드는 결과가 아니라, 룰 엔진이 계산한 결과를 LLM에게 넘겨주는 값이다. LLM은 이 값을 보고 문장을 맞출 뿐, 등급 자체를 바꾸면 안 된다.

그래서 나쁜 구조는 아래와 같다고 본다.

[사료 이름]
[사용자 조건]
[현재 시간]
[고정 가이드]
[모범 성적표]

매번 바뀌는 값이 앞에 섞이면 cache hit가 깨진다. Prompt Caching은 동일한 prefix가 다시 들어왔을 때 효과가 나기 때문이다.

Claude에서는 어떻게 확인하나

Anthropic Claude API에서는 Prompt Caching을 쓰려면 요청에 `cache_control`을 넣어야 한다.

(Anthropic은 block별 지정 없이 top-level cache_control로 breakpoint를 자동 배치하는 방식도 지원하니 이 부분 링크도 첨부해 두겠다!)

그리고 캐싱이 실제로 됐는지는 응답의 `usage`필드를 보면 된다.

top-level 또는 content block 단위의 cache_control을 넣는다.

핵심 필드는 세 개다.

{
  "usage": {
    "input_tokens": 500,
    "cache_creation_input_tokens": 12095,
    "cache_read_input_tokens": 0,
    "output_tokens": 800
  }
}

의미는 이렇다.

cache_creation_input_tokens
이번 요청에서 캐시에 새로 쓴 토큰 수

cache_read_input_tokens
이번 요청에서 이미 캐시된 prefix를 읽은 토큰 수

input_tokens
캐시되지 않은 일반 입력 토큰 수

이 부분은 실제로 두 번 연속 호출해서 확인했다. 첫 번째 요청에서는 고정 프롬프트가 cache write로 잡히는지 보고, 같은 고정 프롬프트로 두 번째 요청을 보내 cache read가 잡히는지 봤다. 비용 그래프를 눈으로 보는 것보다 응답 usage에 찍히는 숫자를 확인하는 편이 훨씬 명확했다. (usage는 API 응답 JSON body 안의 필드다)

정상적으로 캐시가 잡히면 첫 요청과 두 번째 요청의 usage가 다르게 나온다.

<첫 번째 요청>
cache_creation_input_tokens = 12095
cache_read_input_tokens = 0

<두 번째 요청>
cache_creation_input_tokens = 0
cache_read_input_tokens = 12095

이 결과는 고정 프롬프트 12,095토큰이 첫 요청에서 캐시에 쓰였고, 두 번째 요청에서 재사용됐다는 뜻이다.

반대로 아래처럼 나오면 캐싱이 안 된 것이다.

cache_creation_input_tokens = 0
cache_read_input_tokens = 0

이때는 `cache_control`이 빠졌는지, 고정 프롬프트가 요청마다 달라지는지, 제품별 데이터가 캐시 구간 안에 섞였는지, 캐시 유효시간이 지났는지 확인해야 한다.

Claude에서 전체 입력 토큰을 볼 때도 주의가 필요하다. `input_tokens`만 보면 전체 입력이 아니다.

const total_input_tokens =
    input_tokens
    + cache_creation_input_tokens
    + cache_read_input_tokens

한 번의 테스트 호출에서는 usage를 직접 보면 된다. 하지만 운영 환경에서는 요청이 계속 들어옴으로 매번 응답 JSON을 사람이 확인하긴 힘들다고 생각한다. 그래서 문장 다듬기 호출마다 최소한 아래 값은 로그나 메트릭으로 남겨두려 한다.

provider
model
input_tokens
output_tokens
cache_creation_input_tokens
cache_read_input_tokens
copy_source report_reused
estimated_cost

캐싱을 적용한 뒤에는 단순히 청구 금액이 줄었는지만 보면 부족하다. Claude 응답의 `cache_read_input_tokens`가 0보다 크게 나오는지 확인해야 한다. 이 값이 있어야 고정 프롬프트를 매번 새로 읽는 것이 아니라, 실제로 캐시에서 재사용했다는 뜻이 된다!

캐시는 얼마나 유지되나

다만 당연하게도 캐시는 영구 저장소가 아니다!

유효시간이 지나면 다음 요청은 다시 cache miss가 나고, 그 순간 입력 비용이 다시 튄다 🥲

Anthropic 공식 문서 기준으로 Claude의 `ephemeral` cache는 기본적으로 5분 lifetime을 가진다. 1시간 TTL도 선택할 수 있지만.. write 비용이 더 비싸다..! (그러니 무작정 선택하지 말자!)

가격 구조는 이렇다.

5분 cache write: 일반 input 가격의 1.25배
1시간 cache write: 일반 input 가격의 2배
cache read: 일반 input 가격의 0.1배

따라서 트래픽이 꾸준히 들어오는 서비스라면 5분 캐시가 효율적이라 생각한다. 5분 안에 같은 고정 프롬프트가 반복해서 사용되면 cache read가 발생하고, 공식 문서 기준으로 5분 캐시는 계속 refresh될 수 있다.

반대로 요청 간격이 5분을 자주 넘는다면 첫 요청마다 다시 cache write가 발생한다. 이 경우 비용이 다시 튄다..

이런 워크로드에서는 1시간 TTL을 검토할 수 있다. 다만 1시간 cache write는 2배 가격이므로, 요청 빈도와 cache hit 가능성을 보고 결정해야 한다.

요약 정리하자면 이렇다.

짧은 시간 안에 반복 호출이 많다 → 5분 cache가 유리할 가능성이 큼
요청 간격이 5분을 자주 넘지만 1시간 안에는 반복 → 1시간 TTL 검토
요청이 하루에 몇 번 수준 → Prompt Caching보다 DB 재사용, 배치, 프롬프트 축소가 더 중요할 수 있음

그래서 캐싱을 적용했다고 끝이 아니라 cache hit 비율을 봐야 한다!

const cache_hit_ratio =
	cache_read_input_tokens / total_input_tokens

위의 코드에 아래 내용을 대입해보자.

input_tokens = 500
cache_creation_input_tokens = 0
cache_read_input_tokens = 12095

그럼 결과는 아래처럼 나온다.

total_input_tokens = 12595
cache_hit_ratio = 약 96%

이 정도면 고정 프롬프트 캐싱이 잘 먹고 있다고 본다.

반대로 트래픽이 드문 시간대마다 아래처럼 나온다면 캐시가 만료되고 있는 것이다.

cache_creation_input_tokens = 12095
cache_read_input_tokens = 0

이건 실패가 아니라 cache miss다. 다만 비용은 다시 오른다 😱

고정 프롬프트를 바꿔야 할 때

캐시 대상 고정 프롬프트는 바꿔도 될까? 당연히 된다!

작성 가이드가 개선되거나, 모범 성적표가 바뀌거나, 필수 고지 문구가 바뀌면 당연히 업데이트해야 한다!

다만 고정 프롬프트가 바뀌면 기존 캐시와 prefix가 달라진다. 그러면 첫 요청은 cache miss가 나고, 새 버전의 고정 프롬프트가 다시 cache write된다. 이후 같은 새 버전이 반복되면 다시 cache hit가 난다.

즉 배포 직후에는 비용이 잠깐 튈 수 있다.

이때 고정 프롬프트가 변경된 걸 모르는 다른 팀원 입장에선 당황스러울 수 있다.

그러니 운영에서는 고정 프롬프트를 버전으로 관리하는 편이 좋다고 생각한다.

feed_report_copy_prompt_version = 2605.1
feed_report_copy_prompt_version = 2605.2

이렇게 해두면 어떤 성적표가 어떤 기준 문서로 문장 다듬기를 거쳤는지 추적할 수 있다.

변경의 성격도 나눠야 한다고 본다.

문제가 조금 바뀐 경우
-> 기존 발행 성적표를 반드시 폐기할 필요는 없음

필수 고지, 안전 문구, 정책 판단이 바뀐 경우
-> 기존 성적표 재사용 기준을 다시 봐야 함

채점 규칙이나 사료별로 달라지는 정보들의 해석이 바뀐 경우 (사료별로 달라지는 정보들을 앞으로 facts 라고 하겠다!)
-> ruleset version 또는 report publication 기준까지 같이 봐야 함

우리 서비스에서는 이미 발행된 성적표를 재사용하는 구조가 있다. 이때 고정 프롬프트가 바뀌었다고 무조건 기존 성적표를 버릴 필요는 없다. 하지만 법적 고지, 안전 문구, 리포트 정책이 바뀐 경우라면 같은 facts여도 사용자에게 보여줄 문장이 달라질 수 있다. 그런 변경은 prompt version이나 ruleset version으로 분리해야 한다.

그리고 배포 직후 첫 사용자에게 cache miss 비용과 latency를 넘기고 싶지 않다면 pre-warming도 가능하다. Anthropic 공식 문서에서는 `max_tokens: 0`을 사용해 system prompt나 tool definition을 미리 캐시에 올리는 방식이 안내되어 있다. 다만 이 경우에도 cache write 비용은 발생한다.

A 사용자의 캐시를 B 사용자가 쓸 수 있나

가능하다! 단, 같은 Anthropic workspace 안에서 동일한 프롬프트 prefix가 다시 들어와야 한다.

Anthropic 문서 기준으로 2026년 2월 5일부터 Claude API의 prompt cache는 workspace 단위로 격리된다. 다른 조직과는 공유되지 않고, 같은 조직 안에서도 workspace가 다르면 분리된다.

즉 우리 서버가 같은 Anthropic workspace로 호출하고, 고정 사료 성적표 가이드가 100% 동일하다면 A 사용자의 요청에서 만들어진 캐시를 B 사용자의 요청이 재사용할 수 있다.

하지만 사용자 조건이나 사료 facts가 cache 대상 prefix 안에 들어가면 안 된다. 그 값들은 뒤로 빼야 한다.

OpenAI로 바꾸면 어떻게 되나

회의에서 OpenAI로 변경은 어떤가? 라는 이야기가 계속 나오고 있는 중이라 알아본 김에 적어본다 😎

결론부터 말하자면 OpenAI는 방식이 다르다.

OpenAI 공식 문서 기준으로 Prompt Caching은 지원 모델에서 자동 적용된다. Claude처럼 `cache_control`을 직접 붙이는 방식이 아니다. 확인은 `usage.prompt_tokens_details.cached_tokens`로 한다.

예시는 아래와 같은 형태다.

{
  "usage": {
    "prompt_tokens": 2006,
    "completion_tokens": 300,
    "total_tokens": 2306,
    "prompt_tokens_details": {
      "cached_tokens": 1920
    }
  }
}

OpenAI도 캐시 유지시간이 있다. 2026년 5월 기준 공식 문서에는 in-memory cache가 보통 5~10분의 비활성 시간 동안 유지되고, 최대 1시간까지 갈 수 있다고 되어 있다. 일부 모델에서는 extended retention을 통해 최대 24시간 정책을 사용할 수 있다. 특히 최신 모델들에서는 `prompt_cache_retention` 설정을 지원한다.

따라서 OpenAI로 바꾼다고 캐시가 영구적으로 알아서 유지된다고 보면 안 된다. OpenAI도 반복 prefix가 안정적으로 유지되어야 하고, cache hit 여부는 `cached_tokens` 로 확인해야 한다.

회의를 진행할수록 provider가 자주 변경될 것이 예상됐다 🤔

그래서 나는 provider별 client를 아래처럼 분리해두었다.

LLM_PROVIDER=anthropic
-> Anthropic client
-> cache_control 포함
-> cache_creation_input_tokens / cache_read_input_tokens 확인

LLM_PROVIDER=openai
-> OpenAI client
-> cache_control 없음
-> prompt_tokens_details.cached_tokens 확인

이렇게 되어 있으면 나중에 OpenAI로 바꿔도 캐싱 구조를 뜯어고칠 필요는 없다. provider별 usage 필드만 공통 로그 형식으로 정리하면 된다.

OpenAI도 캐시가 조직 간 공유되지는 않는다. 그리고 Claude와 마찬가지로 output token 생성에는 영향을 주지 않는다.

Prompt Caching은 반복 입력 비용과 지연 시간을 줄이는 기능이지, 답변 생성을 생략하는 기능이 아니다.

더 싼 호출은 호출하지 않는 것

사실 캐싱보다 더 근본적인 최적화가 있다..!

이미 같은 사료에 대해 발행된 성적표가 DB에 있다면 LLM을 다시 부르면 안 된다.

하지만 단순히 사료 이름이 같다고 재사용하면 위험하다. 재사용 기준은 명확해야 한다.

(아래는 우리 프로젝트에서 사용하는 용어가 섞여있으니 용어 이해보단 느낌만 챙기자!)

- 같은 product revision인가
- 같은 resolved facts인가
- 같은 ruleset version인가
- 같은 life stage / size / health issues context인가
- 이미 done 상태로 발행된 성적표인가

이 조건이 같다면 기존 성적표를 반환하는 게 맞다. 비용도 줄고, 결과도 더 일관적이다.

이건 단순 캐시가 아니라 제품 정책을 통한 판단이다. 이미 검증된 공식 성적표가 있다면 다시 LLM에게 문장을 맡길 이유가 없다.

그렇기에 가장 싼 LLM 호출은 호출하지 않는 것이다!

출력 길이를 줄이다는 말

처음에는 출력 길이도 비용 최적화 후보로 봤다. 하지만 잘 생각해보니 아니었다.. 😱

사료 성적표가 원래 summary와 10개의 카드로 구성되어 있다면, 카드 수를 줄이는 것은 비용 최적화가 아니다. 제품 요구사항을 바꾸는 것이다.

만약 그럼에도 무언가를 줄인다면, 줄일 수 있는 것은 구조가 아니라 군더더기다.

- JSON 밖의 설명
- 반복되는 문장
- 불필요하게 긴 line1 / line2
- 모델이 덧붙이는 사족

성적표의 형식은 유지해야 했다. 그렇기에 나는 보호자가 기대하는 결과물은 그대로 두고, 모델이 불필요하게 길게 쓰지 않도록 제한하는 방향으로 의견을 냈다. (아직 결론이 나진 않았다!

Haiku로 바꾸면 되나

Claude Haiku 4.5는 Sonnet보다 저렴하다. Anthropic 공식 가격표 기준으로 Haiku 4.5는 입력 `$1 / 1M tokens`, 출력 `$5 / 1M tokens`다. Sonnet 4 계열의 입력 `$3`, 출력 `$15`와 비교하면 같은 토큰 수에서 약 1/3 수준이다.

하지만 상대적으로 저렴하니 Haiku로 바꾸기에는 불안했다 😐

사료 성적표의 LLM은 사실을 판단하지 않지만, 그래도 중요한 역할을 한다. 등급을 바꾸면 안 되고, 내부 채점 용어를 노출하면 안 되고, 칼슘 또는 인 누락이나 처방식 안내 같은 필수 문구를 빠뜨리면 안 된다.

그래서 저렴한 모델을 쓰려면 자동 검증이 먼저 있어야 한다.

1. 일반 케이스는 Haiku 같은 저렴한 모델로 시도한다.
2. 서버가 응답을 검증한다.
3. 통과하면 사용한다.
4. 실패하면 Sonnet으로 승격한다.
5. Sonnet도 실패하면 rule-based copy로 fallback한다.

여기서 실패는 사람이 감으로 문장이 별로네라고 판단하는 것은 아니다.

서버가 최소한 이런 기준을 봐야 한다.

- JSON 파싱 가능 여부
- summary와 카드 문장 존재 여부
- line1 / line2 길이 제한
- 내부 채점 용어 노출 여부
- 필수 고지 문구 유지 여부
- 입력에 없던 사실이나 숫자 추가 여부
- grade, rule_key, title 같은 원래 결과 변경 여부

모델이 스스로 잘 썼다고 말하는 것은 검증이 아니라고 본다. 검증은 우리의 애플리케이션이 해야 한다.

내가 정리한 최적화 순서

이번 비용 문제를 보며 정리한 순서는 이렇다.

1. deprecated 모델은 retirement 전에 교체한다.
2. 이미 발행된 동일 사료 성적표는 DB에서 재사용한다.
3. 새 성적표가 필요하면 고정 가이드와 모범 예시는 Prompt Caching을 적용한다.
4. 캐시 TTL과 cache hit 비율을 로그로 확인한다.
5. 고정 프롬프트 변경은 version으로 관리한다.
6. Claude/OpenAI별 usage 필드를 공통 메트릭으로 정리한다.
7. 검증 규칙을 통과하는 범위에서 저렴한 모델을 테스트한다.
8. 실패하거나 고위험 케이스는 상위 모델로 승격한다.
9. 그래도 실패하면 rule-based copy로 fallback한다.
10. 마지막으로 품질을 해치지 않는 범위에서 프롬프트와 출력 군더더기를 줄인다.

이때 중요한 것은 순서다.

deprecated 모델 교체는 장애 예방에 가깝고, Prompt Caching은 반복 입력 비용을 줄이는 일이다. 둘 다 필요하지만 서로 해결하는 문제가 다르다.

처음부터 가이드를 줄이면 성적표 품질이 흔들릴 수 있다. 처음부터 모델을 낮추면 필수 고지나 문장 안정성이 깨질 수 있다. 반면 Prompt Caching은 프롬프트 내용을 유지한 채 반복 입력 비용을 줄인다.

그래서 첫 번째 안전한 비용 최적화는 캐싱이었다.

다만 캐싱은 영구 보관이 아니다. 5분 TTL이면 요청 간격이 5분을 넘는 순간 cache miss가 날 수 있다. 이때 비용이 다시 튀는 것은 버그가 아니라 캐시의 수명 때문이다. 그래서 운영에서는 캐싱을 켰다가 아니라 cache_read_input_tokens가 꾸준히 잡힌다까지 확인해야 했다.

결론

`$0.06`은 비정상 과금이 아니었다.

사료 성적표의 품질을 맞추기 위해 긴 고정 문서를 매번 넣고 있었고, 그 문서가 캐시되지 않았고, 출력도 1천 토큰 정도 생성됐기 때문에 나온 정상 비용이었다.

동시에 deprecated 모델을 계속 쓰고 있다는 운영 리스크도 발견했다. 이건 비용 최적화와는 별개로 처리해야 할 문제였다. 그래서 기본 모델을 retirement 전에 `claude-sonnet-4-6`으로 바꾸는 것이 맞았다.

이번에 바로 Haiku로 낮추거나 프롬프트를 줄이지 않은 이유도 여기에 있다. 비용은 줄일 수 있어도, 성적표의 신뢰가 흔들리면 제품 입장에서는 더 큰 손해다. 먼저 같은 결과는 재사용하고, 반복되는 기준 문서는 캐시하고, cache read가 실제로 잡히는지 관찰하는 쪽이 더 안전했다.

그러니 LLM 비용 최적화는 더 싼 모델을 고르는 일로 시작하면 안된다! 먼저 무엇이 매번 다시 읽히고 있는지 봐야 한다. 그리고 모델 lifecycle처럼 곧 장애가 될 수 있는 운영 리스크도 함께 봐야 한다. 그다음에 모델 교체, 프롬프트 축소, fallback 전략을 검증 규칙 위에서 다뤄야 한다.

그 순서를 지키면 비용을 줄이면서도 제품 품질을 지킬 수 있다.

참고문서

<공식 문서>

<공식 블로그와 공식 GitHub>

<커뮤니티에서 확인한 흔한 혼동 지점>

Dorong Dorong 💻😴