Amazon Bedrock 프롬프트 캐싱으로 입력 토큰 비용과 지연 시간 줄이기

같은 문맥을 반복해서 모델에 보내는 워크로드라면 입력 토큰 비용이 빠르게 쌓입니다. 10,000 토큰짜리 계약서 한 건을 50개의 질문과 함께 보내면, 모델이 이미 처리한 내용을 위해 50만 토큰이 매번 정가로 청구됩니다. Amazon Bedrock의 프롬프트 캐싱은 이 반복 처리를 인프라 수준에서 줄입니다. 캐시 적중 시 캐시된 입력 토큰의 비용을 최대 90% 낮추고, 첫 토큰까지의 시간(TTFT)도 줄일 수 있습니다.

프롬프트를 줄이거나 컨텍스트 윈도를 좁히는 방법도 있지만 대가가 따릅니다. 프롬프트를 짧게 만들면 토큰 수는 줄지만 문맥의 품질이 떨어질 수 있습니다. 컨텍스트 윈도를 좁히면 비용은 내려가지만 모델이 전체 정보를 놓고 추론하는 능력이 제약됩니다. 응답 캐싱은 동일한 질의에는 잘 맞지만, 같은 문맥에 서로 다른 질문이 붙으면 이점이 없습니다. 프롬프트 캐싱은 모델이나 프롬프트 품질을 바꾸지 않고도 이 문제를 다룹니다.

캐싱이 동작하는 방식

요청 안에 cachePoint 마커를 넣으면, Amazon Bedrock은 그 마커 앞의 내용이 기존 캐시 항목과 일치하는지 확인합니다. 일치하면(캐시 적중) 모델은 해당 토큰의 재처리를 건너뛰고 캐시된 상태에서 바로 생성을 시작합니다. 일치하는 항목이 없으면(캐시 미스) 모델은 전체 내용을 처리하고 그 결과를 캐시에 기록합니다. 다음 요청이 재사용할 수 있도록 남겨두는 것입니다.

동작을 좌우하는 개념이 네 가지 있습니다.

캐시 범위는 개별 AWS 계정과 AWS 리전 단위로 지정됩니다. 계정과 리전이 다르면 캐시를 공유하지 않습니다.

토큰 임계값은 캐시 체크포인트를 활성화하기 위한 최소 조건입니다. 예를 들어 Anthropic Claude Sonnet 4.5와 Sonnet 4.6은 체크포인트당 최소 1,024 토큰이 필요하고, Opus 계열은 최소 4,096 토큰이 필요합니다. 임계값에 못 미치는 내용에는 캐시가 걸리지 않습니다.

TTL(time-to-live)은 캐시 항목의 만료 시점을 정합니다. 기본값은 5분이고, 일부 모델은 최대 1시간까지 지원합니다.

Converse API의 cachePoint 문법은 지원 모델 계열 전반에서 동일합니다. Anthropic Claude와 Amazon Nova에서 같은 문법을 씁니다. 최신 모델 지원 정보는 Amazon Bedrock 프롬프트 캐싱 문서에서 확인할 수 있습니다.

요금 구조

프롬프트 캐싱은 표준 입력·출력 토큰 외에 두 가지 토큰 유형을 추가합니다.

첫 요청에서는 캐시 기록 비용이 발생하고, 이후 요청은 90% 낮은 요율로 캐시를 읽습니다. 10,000 토큰짜리 문서에 서로 다른 질문 10개를 보내는 경우를 예로 들면, 첫 요청에서 캐시 기록 비용이 들고 나머지 아홉 번은 낮은 요율로 캐시를 읽습니다. 이 문서 문맥에 대한 입력 토큰 비용은 순수하게 약 75% 절감됩니다. 단, 이후 요청이 모두 TTL 창 안에서 일어나야 합니다. 만료 이후의 요청은 새 캐시 기록을 유발하므로 순 절감폭이 줄어듭니다. 자세한 요금은 Amazon Bedrock 요금 페이지에서 확인할 수 있습니다.

여섯 가지 활용 시나리오

이번 글은 Converse API를 사용해 기본에서 고급까지 여섯 가지 패턴을 다룹니다.

메시지 콘텐츠 캐싱은 긴 문서를 캐시해 여러 질문으로 분석할 때 씁니다. 시스템 프롬프트 캐싱은 페르소나 정의와 지시문을 여러 대화에 걸쳐 캐시합니다. 도구 정의 캐싱은 에이전트 워크플로에서 도구 스키마를 캐시합니다. 혼합 TTL 캐싱은 콘텐츠 계층별로 서로 다른 캐시 수명을 부여합니다. 테넌트 격리는 멀티테넌트 애플리케이션에서 테넌트별로 캐시를 분리합니다. LangChain 통합은 LangChain 프레임워크와 함께 프롬프트 캐싱을 사용합니다.

메시지 콘텐츠 캐싱을 예로

RAG 애플리케이션에서 같은 문서에 여러 질문을 던지거나, 코딩 어시스턴트가 큰 코드베이스를 반복 참조하는 상황이 대표적입니다. 정적 문서와 동적 질문 사이에 cachePoint 마커를 놓습니다. Amazon Bedrock은 첫 호출에서 문서를 캐시하고, 이후 호출에서 재사용합니다.

content = [
    {"text": document},
    {"cachePoint": {"type": "default"}},
    {"text": question}
]

response = bedrock.converse(
    modelId=MODEL_ID,
    messages=[{"role": "user", "content": content}],
    inferenceConfig={"maxTokens": 512}
)

응답의 usage 객체에는 캐시 관련 필드가 두 개 들어옵니다. cacheWriteInputTokens는 캐시에 기록된 토큰으로 첫 요청에 나타나고, cacheReadInputTokens는 캐시에서 읽은 토큰으로 이후 요청에 나타납니다.

Anthropic Claude Sonnet 4.5로 1,024 토큰을 넘는 문서를 테스트하면, 첫 응답에 캐시 기록이 잡힙니다.

{
  "inputTokens": 28,
  "outputTokens": 253,
  "cacheWriteInputTokens": 1898,
  "cacheReadInputTokens": 0
}

같은 문서 프리픽스로 다른 질문을 보내면 캐시 읽기가 나타납니다.

{
  "inputTokens": 28,
  "outputTokens": 294,
  "cacheWriteInputTokens": 0,
  "cacheReadInputTokens": 1898
}

문서 프리픽스 1,898 토큰 전체가 재처리 없이 재사용되고, 질문 자체인 28 토큰만 표준 입력으로 처리됩니다. 재사용된 토큰은 표준 입력보다 90% 낮은 캐시 읽기 요율로 청구됩니다.

Amazon Bedrock의 Claude 모델은 단순화된 캐시 관리를 지원합니다. cachePoint를 하나만 두어도 Amazon Bedrock이 그 마커 앞 약 20개 콘텐츠 블록까지 프리픽스 적중을 자동으로 확인합니다. 이전 대화 구간의 캐시 적중을 얻으려고 체크포인트를 여러 개 수동 배치할 필요가 없습니다. 더 세밀한 제어가 필요하면 각 콘텐츠 구간 뒤에 cachePoint를 여러 개 놓을 수 있고, 이때 부분 적중이 가능합니다. 앞의 두 구간만 이전 요청과 일치하면 그 부분은 캐시를 재사용하고 나머지만 처리합니다. 같은 문법은 converse_stream에서도 그대로 동작합니다.

도입 전 확인할 사항

시작하려면 지원 리전에서 Amazon Bedrock에 접근할 수 있는 AWS 계정이 필요합니다. 예시는 us-west-2를 씁니다. 대상 모델에 대한 모델 접근을 활성화해야 하며, 예시는 Anthropic Claude Sonnet 4.5(global.anthropic.claude-sonnet-4-5-20250929-v1:0)를 사용합니다. 이 모델 ID는 교차 리전 추론 프로파일입니다. 요청이 리전을 넘나들며 자동으로 라우팅되므로 캐시 기록 빈도가 이따금 늘어날 수 있습니다.

실행 환경은 Python 3.10 이상이 필요하고, 다음 의존성을 설치합니다.

pip install boto3>=1.43.0 langchain-aws>=0.2.12 matplotlib pandas

혼합 TTL 시나리오에서 쓰는 cachePoint의 ttl 파라미터는 Boto3 1.43.0 이상을 요구합니다. AWS 자격 증명은 기본 프로파일이나 환경 변수로 구성합니다.

최신 모델과 리전 가용성은 Amazon Bedrock의 리전별 지원 모델 문서에서, 요금 세부 사항은 Amazon Bedrock 요금 페이지에서 확인할 수 있습니다. 시스템 프롬프트 캐싱, 도구 정의 캐싱, 혼합 TTL, 테넌트 격리, LangChain 통합을 포함한 나머지 시나리오의 전체 코드는 원문 게시글에 이어집니다.

원문: Optimizing cost and latency with Amazon Bedrock prompt caching · 발행일 2026-09-15