Optimizing cost and latency with Amazon Bedrock prompt caching
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Amazon Bedrock 프롬프트 캐싱은 반복되는 입력 문맥을 재사용해 캐시 적중 시 해당 입력 토큰 비용을 최대 90% 줄이고 첫 토큰 도착 시간(TTFT)을 단축할 수 있지만, 실제 효과는 최소 토큰 수, TTL, 재사용 빈도와 리전 라우팅에 달려 있다.
📌 핵심 요약
- 10,000토큰 계약서를 50개 질문과 함께 반복 전송하면 캐싱 없이 문서에만 500,000개 입력 토큰의 정가가 청구된다. Amazon Bedrock 프롬프트 캐싱은 모델이나 프롬프트 품질을 바꾸지 않고 반복 문맥의 처리 비용과 TTFT를 줄일 수 있다.
- Converse API의 cachePoint 앞에 있는 접두부가 기존 캐시와 일치하면 처리 상태를 재사용하고, 일치하지 않으면 전체 내용을 처리해 캐시에 기록한다. 캐시는 AWS 계정과 AWS 리전별로 범위가 구분된다.
- 체크포인트별 최소 토큰 수는 Anthropic Claude Sonnet 4.5와 Sonnet 4.6이 1,024개, Opus 모델이 4,096개다. 기본 TTL은 5분이며 일부 모델은 최대 1시간을 지원한다.
- 원문 요금표에서 캐시 쓰기는 일반 입력보다 25% 비싸고, 1시간 TTL 쓰기는 100% 비싸며, 캐시 읽기는 90% 저렴하다. 원문은 10,000토큰 문서에 서로 다른 질문 10개를 TTL 안에 보내는 사례의 문서 입력 비용 절감률을 약 75%로 제시한다.
- 글은 메시지 내용, 시스템 프롬프트, 도구 정의, 혼합 TTL, 테넌트 격리, LangChain 통합의 여섯 시나리오를 예고하지만, 제공 본문은 첫 시나리오의 예시 문서 중간에서 끝난다. 예제는 Anthropic Claude Sonnet 4.5의 교차 리전 추론 프로파일을 사용하며, 리전 간 자동 라우팅으로 캐시 쓰기 빈도가 증가할 수 있다고 설명한다.
🧩 주요 포인트
- 반복 문맥과 가변 질문의 분리 → 동일 질문에만 효과적인 응답 캐싱의 한계를 보완하며, cachePoint 배치가 재사용 대상의 경계를 결정한다.
- 캐시 쓰기 할증과 읽기 할인, TTL 만료의 결합 → 최대 90% 읽기 할인과 전체 입력 비용 절감률은 구분해야 하며, TTL 안의 재사용 빈도가 경제성을 좌우한다.
- 최소 토큰 수와 AWS 리전별 캐시 범위 → 문서 길이와 교차 리전 추론 라우팅이 캐시 활성화 및 재사용에 영향을 주며, 제공 본문만으로 나머지 다섯 시나리오의 구현은 확인할 수 없다.
🧠 상세 정리
1. 반복 입력 비용과 기존 대응의 한계
글은 같은 문맥을 여러 질문과 함께 반복해서 보내면 이미 처리한 내용에도 입력 토큰 비용이 계속 발생한다는 문제에서 출발한다. 10,000토큰 계약서를 50개 사용자 질문과 함께 전송하는 예에서는 계약서 내용에만 총 500,000개 입력 토큰의 정가가 청구된다. 프롬프트를 줄이면 토큰 수는 감소하지만 문맥 품질이 낮아질 수 있고, 문맥 창을 축소하면 완전한 정보를 바탕으로 추론하는 능력이 제한될 수 있다. 애플리케이션 수준의 응답 캐싱은 동일한 질문을 반복할 때 유용하지만, 같은 문서에 서로 다른 질문을 붙이는 경우에는 이점이 없다. Amazon Bedrock 프롬프트 캐싱은 이러한 반복 문맥을 인프라 수준에서 재사용해 모델이나 프롬프트 품질을 바꾸지 않고 비용과 지연 시간을 줄이는 방법으로 제시된다.
2. cachePoint를 통한 처리 상태 재사용
프롬프트 캐싱은 입력을 부분적으로 처리한 상태의 스냅샷을 저장하고, 같은 접두부를 가진 후속 요청에서 중복 계산을 건너뛰는 방식이다. 요청에 cachePoint 표시를 넣으면 Amazon Bedrock은 그 표시 앞의 내용이 기존 캐시 항목과 일치하는지 평가한다. 일치하는 캐시 적중에서는 해당 토큰을 다시 처리하지 않고 저장된 상태에서 생성을 시작할 수 있으며, 이를 통해 첫 토큰 도착 시간인 TTFT를 줄일 수 있다. 일치하는 항목이 없는 캐시 미스에서는 전체 내용을 처리하고 그 결과를 이후 요청에서 사용할 수 있도록 캐시에 기록한다. 원문은 첫 요청이 캐시를 쓰고 두 번째 요청이 이를 읽는 흐름을 설명하며, 캐시 적중 시 캐시된 입력 토큰의 비용을 최대 90% 낮출 수 있다고 밝힌다.
3. 캐시 범위와 모델별 활성화 조건
캐시 동작을 결정하는 핵심 조건은 적용 범위, 최소 토큰 수, 유효기간인 TTL, 그리고 API 문법이다. 캐시 항목의 범위는 개별 AWS 계정과 AWS 리전으로 구분되며, 각 캐시 체크포인트는 최소 토큰 수를 충족해야 활성화된다. 예를 들어 Anthropic Claude Sonnet 4.5와 Sonnet 4.6은 체크포인트당 최소 1,024토큰이 필요하고, Opus 모델은 최소 4,096토큰이 필요하다고 설명한다. TTL은 요청에 지정된 값에 따라 적용되며 기본값은 5분이고, 일부 모델은 최대 1시간까지 지원한다. Converse API의 cachePoint 문법은 Anthropic Claude와 Amazon Nova를 비롯한 지원 모델 계열에서 동일하지만, 실제 최신 지원 모델 정보는 Amazon Bedrock 프롬프트 캐싱 문서를 참조하도록 안내한다.
4. 쓰기 할증과 읽기 할인으로 구성된 비용
프롬프트 캐싱은 일반 입력 및 출력 토큰 외에 캐시에 기록한 토큰과 캐시에서 읽은 토큰이라는 두 요금 범주를 추가한다. 원문 요금표에서 cacheWriteInputTokens는 일반 입력보다 25% 비싸고, cacheReadInputTokens는 일반 입력보다 90% 저렴하며, 1시간 TTL의 캐시 쓰기는 일반 입력의 두 배인 100% 할증으로 제시된다. 따라서 후속 요청의 읽기 할인만으로 전체 절감률을 판단할 수 없고, 최초 쓰기 비용도 함께 고려해야 한다. 원문은 10,000토큰 문서에 서로 다른 질문 10개를 보내 첫 요청에서 쓰기를 수행하고 나머지 아홉 요청에서 캐시를 읽으면, 해당 문서 문맥의 입력 비용이 약 75% 절감된다고 설명한다. 이 설명은 모든 후속 요청이 TTL 안에 발생한다는 전제이며, 만료 이후의 요청은 새로운 캐시 쓰기를 유발해 순절감 효과를 낮춘다.
5. 여섯 가지 적용 패턴의 범위
글은 Converse API를 사용하는 여섯 가지 실용적인 시나리오를 기본 패턴에서 고급 패턴으로 이어지는 순서로 소개하겠다고 예고한다. 메시지 내용 캐싱은 긴 문서를 대상으로 여러 질문을 처리하는 용도이고, 시스템 프롬프트 캐싱은 페르소나 정의와 지침을 여러 대화에서 재사용하는 용도다. 도구 정의 캐싱은 에이전트 워크플로의 도구 스키마를 저장하며, 혼합 TTL 캐싱은 서로 다른 콘텐츠 계층에 각각 다른 캐시 유효기간을 부여하는 방식으로 설명된다. 테넌트 격리는 다중 테넌트 애플리케이션에서 테넌트별 캐시를 분리하는 주제이고, LangChain 통합은 해당 프레임워크에서 프롬프트 캐싱을 사용하는 주제다. 다만 제공된 본문은 첫 시나리오의 예시 문서 중간에서 끝나므로, 나머지 다섯 시나리오는 소개된 목적까지만 확인할 수 있고 구체적인 구현이나 결과는 확인되지 않는다.
6. 실행 환경과 교차 리전 추론의 주의점
실행 전제는 Amazon Bedrock을 사용할 수 있는 AWS 계정, us-west-2 같은 지원 AWS 리전, 대상 모델 접근 권한, 그리고 구성된 AWS 자격 증명이다. 예제 모델은 Anthropic Claude Sonnet 4.5이며, 모델 식별자로 global.anthropic.claude-sonnet-4-5-20250929-v1:0을 사용한다. 이 식별자는 교차 리전 추론 프로파일이므로 요청이 리전 사이에서 자동 라우팅되고, 그 결과 캐시 쓰기 빈도가 간혹 증가할 수 있다고 원문은 설명한다. Python은 3.10 이상을 요구하며 의존성으로 boto3>=1.43.0, langchain-aws>=0.2.12, matplotlib, pandas를 제시한다. 특히 네 번째 혼합 TTL 시나리오에서 cachePoint의 ttl 매개변수를 사용하려면 Boto3 1.43.0 이상이 필요하고, 자격 증명은 기본 프로파일이나 환경변수를 통해 구성하도록 안내한다.
7. 메시지 내용 캐싱의 경계 배치
첫 시나리오는 긴 문서나 참조 내용을 반복해서 질의하는 경우로, RAG 애플리케이션에서 같은 문서에 여러 질문을 하거나 코딩 도우미가 큰 코드베이스를 참조하는 상황을 예로 든다. 구현의 핵심은 정적인 문서와 동적으로 바뀌는 질문 사이에 cachePoint 콘텐츠 블록을 배치하는 것이다. 제시된 content 배열은 정적 문서를 담은 text 블록, type이 default인 cachePoint 블록, 사용자 질문을 담은 text 블록의 순서로 구성된다. Amazon Bedrock은 체크포인트 앞의 내용을 첫 호출에서 캐시하고 이후 호출에서 재사용할 수 있으므로, 질문이 바뀌어도 정적 문서를 재사용 대상으로 유지할 수 있다. 원문은 이 패턴을 실제 코드로 이어가며, 운영 환경의 문서로 PDF나 지식 기반 문서처럼 해당 모델의 최소 토큰 기준을 충족하는 콘텐츠를 사용할 수 있다고 설명한다.
8. 예제 코드와 제공 자료의 종료 지점
구현 예시는 boto3, json, time을 가져오고 모델 식별자와 AWS_REGION을 정의한 뒤, us-west-2에서 bedrock-runtime 클라이언트를 생성하는 부분으로 시작한다. 이어 Claude Sonnet 4.5의 캐시 활성화에 필요한 1,024토큰 기준을 넘도록 긴 DOCUMENT 문자열을 제공하며, 그 내용은 우주와 태양계에 대한 설명이다. 이 문서는 지구형 행성, 소행성대, 목성과 토성, 천왕성과 해왕성, 카이퍼 벨트와 오르트 구름 등을 다루지만, 글에서의 역할은 반복 질의에 사용할 정적 입력의 예시다. 제공된 텍스트는 외태양계 탐사와 Voyager 2를 설명한 뒤 문장 중간에서 끊겨, 뒤따를 호출 코드나 실행 결과는 포함하지 않는다. 따라서 이 자료에서 확인 가능한 구현 범위는 클라이언트 설정, 캐시 경계의 기본 구조, 그리고 긴 예시 문서의 일부까지이며 실제 측정된 비용이나 TTFT 개선 수치는 제시되지 않는다.
🧾 핵심 주장 / 시사점
- 프롬프트 캐싱의 적용 가치는 질문 자체의 반복보다 문맥의 반복에 있다. 동일 문서를 유지하면서 질문이 달라지는 요청에서 응답 캐싱이 제공하지 못하는 재사용 효과를 기대할 수 있다.
- 캐시 읽기의 최대 90% 할인은 전체 요청 비용의 90% 절감을 뜻하지 않는다. 최초 쓰기 할증과 TTL 만료에 따른 재기록이 누적 절감률에 영향을 준다.
- Converse API 문법이 모델 계열 간 같아도 캐시 활성화와 재사용 조건까지 동일한 것은 아니다. 최소 토큰 수, 지원 TTL, 리전별 범위와 라우팅을 함께 고려해야 한다.
✅ 액션 아이템
- 반복 문맥과 가변 질문을 구분하고, cachePoint를 두 영역 사이에 배치하는 적용 가능성 검토.
- TTL 안의 재사용 빈도를 기준으로 캐시 쓰기 25% 할증, 1시간 TTL 쓰기 100% 할증, 읽기 90% 할인을 반영한 입력 비용 비교.
- Anthropic Claude Sonnet 4.5의 최소 1,024토큰 충족 여부와 교차 리전 추론 라우팅에 따른 캐시 쓰기 빈도 확인.
❓ 열린 질문
- 반복 문맥을 cachePoint 앞에 유지하면서 가변 질문만 바꿀 수 있는 요청은 얼마나 되는가?
- TTL 안의 재사용 빈도를 고려하면 캐시 쓰기 할증을 포함한 실제 입력 비용 절감률은 얼마인가?
- AWS 리전별 캐시 범위와 교차 리전 추론 라우팅은 캐시 쓰기 빈도에 어느 정도 영향을 주는가?
