비용 최적화: 프롬프트 캐싱

이득:

• 프롬프트 캐싱의 접두사 일치 논리 설명
• 고정 컨텍스트를 먼저 배치하고 가변 컨텍스트를 뒤에 배치하여 캐시 적중을 늘립니다.
• 캐시 쓰기/읽기 경제성과 손익분기점을 계산할 수 있습니다.

LLM 제품은 프로토타입에서 저렴해 보입니다. 체중계에 올라가면 계산서가 깜짝 놀라게 됩니다. 대부분의 워크로드에서 청구서의 대부분은 각 요청과 함께 계속해서 전송되는 동일한 고정 컨텍스트(긴 시스템 프롬프트, 규칙서, 참조 문서)에서 나옵니다. 신속한 캐싱은 이러한 낭비를 정확하게 제거합니다. 이번 단원에서는 캐시가 어떻게 작동하는지, 적중하라는 메시지를 배열하는 방법, 캐시 경제의 손익분기점을 계산하는 방법을 배우게 됩니다. 올바르게 설치하면 비용을 절반 또는 그 이하로 줄일 수 있습니다.

캐시는 어떻게 작동하나요? 불변의 법칙

프롬프트 캐싱은 접두사 일치입니다. 공급자는 프롬프트가 시작된 이후 처리한 토큰을 임시로 저장합니다. 다음 요청에서 프롬프트가 동일한 접두사로 시작하면 이 공통 부분은 다시 계산되지 않습니다. 캐시보다 읽는 것이 훨씬 저렴합니다.

다음은 변경할 수 없는 규칙 중 하나입니다. 단일 바이트가 접두사 어디에서나 변경되면 해당 지점부터 전체 캐시가 유효하지 않게 됩니다. 즉, 고정 내용은 시작 부분에 있어야 하고 가변 내용은 끝 부분에 있어야 합니다. "오늘 날짜: 2026년 7월 18일"과 같이 각 요청에 따라 변경되는 시스템 프롬프트 시작 부분에 줄을 넣으면 그 뒤에 있는 모든 내용이 캐시에 들어갈 수 없습니다.

처리 순서는 일반적으로 도구 → 시스템 프롬프트 → 메시지입니다. 고정 섹션의 끝에 캐시 포인트(중단점)를 놓습니다.

캐시 경제

캐시에는 세 가지 가격 등급이 있습니다.

• 캐시 쓰기: 처음으로 저장합니다. ~1.25x 일반 입력 가격(5분 저장 기준).
• 캐시 읽기: 후속 요청에 대한 읽기입니다. 정상 투입 가격의 ~0.1배, 즉 1/10입니다.
• 일반 입력 : 캐시에 들어가지 않고 매번 전액 비용으로 처리되는 부분.

손익분기점: 첫 번째 요청에는 쓰기 프리미엄(1.25×)이 지불됩니다. 두 번째 요청부터 판독값(0.1×)이 적용됩니다. 대략적으로 두 가지 요청에 대해 목과 목이 될 것입니다. 그 이후에는 순 절감액입니다. 고정 컨텍스트가 더 크고 재사용되는 요청이 많을수록 이득은 더 커집니다.

대본

캐시가 작동하나요?

대규모 고정 시스템 프롬프트, 수천 건의 요청

예 — 최고 수입

동일한 참조 문서에 대한 많은 질문

예

각 요청마다 완전히 다른 짧은 텍스트

아니요 - 쓰기 보너스가 낭비됩니다.

일회성 요청

아니요 - 전혀 읽지 않습니다.

시스템 프롬프트에서 각 요청에 따라 날짜/ID가 변경됩니다.

아니요 — 접두사가 깨져서 적중률이 0입니다.

단계별: 히트 프롬프트를 설정하는 방법은 무엇입니까?

1. 상수와 변수를 분리합니다. 변경되지 않는 내용(시스템 프롬프트, 규칙서, 문서)은 무엇입니까? 각 요청(사용자 질문, 날짜, ID)에 따라 어떤 변경사항이 있나요?
2. 상수를 처음에 넣으세요. 가공 중에 가장 먼저 나오는 부품(도구, 시스템)이 안정적이어야 합니다.
3. 변수를 맨 마지막에 넣으세요. 사용자의 현재 질문, 마지막입니다.
4. 국경 끝에 표지판을 놓습니다. 고정부분의 마지막 블록에 캐시포인트를 넣습니다.
5. 적중을 확인합니다. 응답의 사용량 필드에서 캐시_read_input_tokens가 0보다 큰지 확인하세요. 0이면 접두사에 숨겨진 방해 요소가 있는 것입니다.

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

팁: 캐시 적중을 추측하지 말고 측정하세요. 연속 요청에서 Usage.cache_read_input_tokens가 여전히 0인 경우 자동 차단기(시스템 프롬프트의 datetime.now(), 순서가 지정되지 않은 JSON, 각 요청에 따라 변경되는 도구 목록)가 실행 중입니다. 두 요청의 원시 프롬프트를 바이트 단위로 비교하고 차이점을 찾으세요.

조용한 방해자

자신도 모르게 캐시를 손상시키는 일반적인 패턴:

# 차단기: 각 요청에 따라 변경되는 시스템 프롬프트에 정보 삽입 "오늘 날짜: {{지금}}. 당신은 어시스턴트입니다..." ← 각 요청에 따라 접두사가 변경되고 히트는 0입니다.# TRUE: 변수를 메시지 시스템으로 이동합니다: "당신은 어시스턴트입니다..." ← 상수가 캐시에 입력됩니다. 메시지: [{role: user, content: "오늘은 {{지금}}입니다. 질문: ..."}] ← 끝에 변수

기타 차단기: JSON은 각 요청마다 다르게 정렬됩니다(키를 고정된 순서로 유지), 사용자에 따라 다양한 도구 목록(도구가 먼저 처리되고 변경되면 캐시에 아무것도 들어가지 않음), 대화 도중 모델 변경(캐시는 모델마다 다릅니다).

약한 프롬프트 / 강한 프롬프트(캐시 친화적인 구조)

# WEAK (캐시 무효화 빌드) 시스템: "날짜: 18.07.2026 14:32. 사용자: Ahmet (id 8842). 당신은 지원 봇입니다. 규칙: ...(2000 토큰)..."

# STRONG(캐시 친화적 구조)시스템: "귀하는 지원 봇입니다. 규칙: ...(2000개 토큰, 변경되지 않음)..." [캐시 서명]messages: [ { role: user, content: "날짜: 18.07.2026 14:32. 사용자 ID: 8842. 질문: 환불을 시작하려면 어떻게 해야 하나요?" }]

약한 버전에서는 2000개 토큰의 규칙 블록이 각 요청마다 전액 비용으로 처리됩니다. 강력한 버전에서는 동일한 블록이 한 번 작성되고 이후의 모든 요청에서 가격의 10분의 1로 읽혀집니다.

미니 케이스 3개

사례 1 - 규칙집 캐싱. 회계 자동화는 각 송장에 12,000개의 토큰 규칙서를 추가했습니다. 하루 5,000건의 요청. 캐시 없는 입력 비용은 하루 최대 $180입니다. 그들은 규칙서를 일정하게 유지하고 이를 캐시했습니다. 첫 번째 요청에는 쓰기 프리미엄을 지불하고 후속 읽기에는 0.1×를 지불했습니다. 입력 비용은 하루에 ~90% 감소하여 ~$18로 떨어졌습니다.

사례 2 — 숨겨진 날짜 변경선의 비용. 한 팀은 캐시를 설정했지만 히트가 없었습니다. 캐시_read_input_tokens는 항상 0이었습니다. 이유: 시스템 프롬프트의 첫 번째 줄에 datetime.now()가 있었고 접두사는 요청마다 변경되었습니다. 날짜를 사용자 메시지로 옮기자 적중률이 갑자기 0%에서 94%로 높아졌습니다.

사례 3 - 캐시가 잘못 배치되었습니다. 검색 애플리케이션은 각 요청마다 완전히 다른 짧은 쿼리를 보내고 있었습니다. 그들은 열심히 캐시 사인을 추가했습니다. 공통 접두사 없이 각 요청은 쓰기 프리미엄만 지불하고 읽기는 하지 않아 비용이 증가했습니다. 그들은 표지판을 제거했습니다. 교훈: 캐시는 재사용되는 크고 일정한 접두사가 있는 경우에만 비용을 지불합니다.

일반적인 실수

• 상수와 변수 혼합: 변수 내용이 접두사에 있으면 조회가 재설정됩니다.
• 시스템 프롬프트에 날짜/ID 삽입: 가장 일반적인 조용한 방해 요소입니다.
• 적중을 측정하지 않음: 캐시_read_input_tokens를 확인하지 않으면 낭비가 감지되지 않습니다.
• 공개 접두사가 없을 때 캐시 추가: 쓰기 프리미엄만 지불하면 비용이 증가합니다.
• 차량 목록 또는 모델 변경: 접두어가 처음부터 깨져 있습니다. 모든 것이 다시 작성되었습니다.
• 최소 캐시 크기를 잊어버린 경우: 매우 짧은 캐시(모델에 따라 ~1~4,000개 토큰 미만)는 캐시에 자동으로 입력되지 않습니다.

Deeper: 워크로드 유형별 캐시 설계

캐싱의 실제 결과는 워크로드의 성격에 따라 다릅니다. 그러니 먼저 교통 상황을 알아보세요. 세 가지 일반적인 패턴과 올바른 설치:

일반적인 시스템 프롬프트, 다양한 질문. 가장 일반적인 기업 패턴: 수백 가지의 다양한 사용자 질문이 포함된 대규모 시스템 프롬프트(역할, 규칙, 참조 문서 등)입니다. 여기서 고정 부분(시스템)은 처음에 캐시됩니다. 각각의 새로운 질문은 그 자체의 작은 부분에 대해서만 정가를 지불합니다. 큰 부분을 10분의 1 가격으로 반복해서 낭독하기 때문에 이득이 매우 크다.

멀티 라운드 독백. 대화가 계속 진행됨에 따라 각각의 새로운 라운드는 이전의 모든 기록 위에 구축됩니다. 마지막 라운드가 끝날 때 캐시 플래그를 넣으면 각 요청은 이전 대화 접두사를 재사용합니다. 대화가 늘어남에 따라 조회수가 누적됩니다. 이는 긴 보조 세션 비용을 극적으로 줄여줍니다.

공유 접두사는 변경할 마지막 비트입니다. 여러 요청은 고정된 사전 설정(샘플 세트, 지침)의 대규모 세트를 공유하지만 마지막에는 단일 질문으로 구분됩니다. 공유 부분의 끝에 캐시 포인터를 놓습니다. 그렇지 않으면 각 요청이 별도의 캐시를 작성하고 그 중 어느 것도 읽히지 않습니다.

한 가지 주의 사항: 캐시는 모델과 특정 최소 크기에 따라 다릅니다. 매우 작은 접두사(모델에 따라 수천 개의 토큰 미만)는 플래그를 지정하더라도 자동으로 캐시에 입력되지 않습니다. 캐시_생성_input_tokens는 0으로 유지됩니다. 또한 대화 중에 모델을 변경하면 전체 캐시가 무효화됩니다. 다른 작업에 저렴한 모델이 필요한 경우 기본 흐름을 하나의 모델에 유지하고 부업을 별도의 호출에 넣으세요.

요약하면

프롬프트 캐싱은 접두사 일치입니다. 고정 콘텐츠는 시작 부분에 있어야 하고 가변 콘텐츠는 끝에 있어야 합니다. 대규모 재사용 컨텍스트의 경우 읽기 비용은 전체 가격의 10분의 1에 불과하며 대략 두 번의 요청으로도 손익분기점에 도달합니다. 가장 흔한 실수는 시스템 프롬프트에 변수 데이터를 삽입하여 접두어를 손상시키는 것입니다. 사용량 필드에서 히트를 측정하여 히트를 확인합니다.

응용과제

워크로드를 선택하세요. (1) 내용을 "변경되지 않음"과 "요청할 때마다 변경됨"이라는 두 개의 열로 나눕니다. (2) 상수 부분을 시작 부분에, 변수 부분을 끝 부분에 배치하여 프롬프트 구조를 다시 그립니다. (3) 고정 부분의 토큰 크기를 추정하고 캐시 유무에 따른 월별 비용을 비교합니다. (4) 적중을 확인할 필드(cache_read_input_tokens)를 기록해 두십시오.

체크리스트

• [ ] 캐시는 접두사 일치이며 유일한 불변 규칙이라고 설명할 수 있습니다.
• [ ] 고정 내용을 처음에 넣고 변수를 끝에 넣어 정확도를 높일 수 있습니다.
• [ ] 나는 쓰기/읽기 경제학과 두 요청으로 인한 손익분기점을 알고 있습니다.
• [ ] 조용한 방해 요소(날짜, 정렬되지 않은 JSON, 차량 목록 변경)를 인식할 수 있습니다.
• [ ] Usage.cache_read_input_tokens를 사용하여 적중을 확인할 수 있습니다.