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

Amazon Bedrock의 프롬프트 캐싱은 같은 컨텍스트를 반복해서 파운데이션 모델에 보낼 때 캐시 적중 기준으로 입력 토큰 비용을 최대 90퍼센트 줄입니다. 캐싱 없이 1만 토큰짜리 계약서를 사용자 질문 50개와 함께 보내면, 모델이 이미 처리한 내용을 50만 토큰만큼 정가로 청구받습니다. 매달 Bedrock 청구서에서 입력 토큰이 큰 비중을 차지하는데 같은 문서나 지시문을 요청마다 다시 넣고 있다면, 이 반복분을 깎을 수 있습니다.

프롬프트를 짧게 줄이거나 컨텍스트 창을 좁히면 비용은 내려가지만 모델이 참고할 정보도 함께 줄어듭니다. 동일한 질문을 저장하는 응답 캐싱은 같은 질문에만 효과가 있고, 같은 문서에 다른 질문을 붙이면 소용이 없습니다. 프롬프트 캐싱은 모델이나 프롬프트 품질을 그대로 두고 인프라 단계에서 반복 처리를 건너뜁니다.

cachePoint 마커와 캐시 적중

요청에 cachePoint 마커를 넣으면 Amazon Bedrock이 그 앞 내용을 기존 캐시 항목과 대조합니다. 일치하면(캐시 적중) 해당 토큰을 다시 처리하지 않고 캐시된 상태에서 생성을 시작합니다. 일치하는 항목이 없으면(캐시 미스) 전체 내용을 처리한 뒤 결과를 캐시에 기록합니다.

캐시 항목은 계정·리전 단위로 격리됩니다. 각 체크포인트는 최소 토큰 기준을 넘어야 캐시가 활성화되는데, Claude Sonnet 4.5와 4.6은 체크포인트당 1,024토큰, Opus 계열은 4,096토큰이 필요합니다. 캐시 항목은 요청에 지정한 TTL에 따라 만료되며, 기본값은 5분, 일부 모델은 최대 1시간까지 지원합니다. Converse API의 cachePoint 문법은 Claude와 Amazon Nova 등 지원 모델 계열에서 동일합니다.

Claude 모델은 단순 캐시 관리를 지원해서, cachePoint 하나만 두어도 그 앞의 약 20개 콘텐츠 블록까지 자동으로 캐시 적중을 확인합니다. 여러 체크포인트를 수동으로 배치하지 않아도 됩니다. 반대로 세밀하게 나누고 싶으면 섹션마다 마커를 두어 부분 적중을 활용할 수 있습니다. 앞 두 섹션만 일치하면 그 부분은 재사용하고 나머지만 처리합니다.

청구되는 토큰 종류와 절감 폭

표준 입력·출력 토큰 외에 두 종류가 추가됩니다. 첫 요청에서 캐시에 기록되는 cacheWriteInputTokens는 표준 입력보다 25퍼센트 비쌉니다. 이후 요청에서 캐시를 읽는 cacheReadInputTokens는 표준 입력보다 90퍼센트 쌉니다. 1시간 TTL로 캐시를 쓰면 쓰기 비용이 표준 입력의 2배가 됩니다.

반복 컨텍스트에서는 입력 토큰 비용의 순절감이 약 75퍼센트에 이릅니다. 1만 토큰 문서에 서로 다른 질문 10개를 보내면, 첫 요청은 쓰기 비용을 부담하고 나머지 9개는 90퍼센트 싼 읽기 비용으로 처리됩니다. 단 모든 후속 요청이 TTL 창 안에서 일어나야 하고, 만료 후 요청은 새 쓰기를 유발해 순절감이 줄어듭니다.

실제 측정에서 1,024토큰을 넘는 문서를 Claude Sonnet 4.5로 보내면 첫 응답에 1,898토큰의 캐시 쓰기가 잡히고, 같은 문서 접두부로 보낸 다음 요청에서는 1,898토큰이 캐시 읽기로 잡힙니다. 질문 자체인 28토큰만 표준 입력으로 처리됩니다. 요금 세부는 Amazon Bedrock 요금 페이지에서 확인할 수 있습니다.

상황별로 고르는 캐싱 패턴

같은 문서에 여러 질문을 보내는 RAG 애플리케이션이나 큰 코드베이스를 참조하는 코딩 어시스턴트라면 문서를 정적 블록으로 두고 그 뒤에 마커를 넣는 메시지 콘텐츠 캐싱을 씁니다. 페르소나 정의나 공통 지시문을 여러 대화에 반복해 넣는다면 시스템 프롬프트 캐싱으로 그 부분을 재사용합니다. 에이전트 워크플로에서 도구 스키마를 매번 함께 보낸다면 도구 정의 캐싱이 그 스키마를 캐시합니다.

콘텐츠 계층마다 갱신 주기가 다르면 혼합 TTL 캐싱으로 계층별 수명을 다르게 지정합니다. 이 기능은 boto3 1.43.0 이상이 있어야 cachePoint의 ttl 파라미터를 쓸 수 있습니다. 여러 고객을 한 애플리케이션에서 처리한다면 테넌트 격리로 테넌트별 캐시를 분리합니다. LangChain을 쓰고 있으면 프레임워크와 통합해 캐싱을 적용합니다. 각 시나리오의 코드는 원문에서 확인할 수 있습니다.

예제는 us-west-2에서 Claude Sonnet 4.5의 교차 리전 추론 프로파일을 씁니다. 이 경우 요청이 여러 리전으로 자동 분산되면서 캐시 쓰기 빈도가 이따금 늘 수 있습니다. 최신 모델과 리전 지원은 Amazon Bedrock 프롬프트 캐싱 문서에서 확인합니다.

도입 검토 의견

원문 발표가 아닌 솔트웨어의 의견입니다

같은 문서나 긴 시스템 프롬프트를 요청마다 다시 넣고 있고 그 요청들이 몇 분 안에 몰려 들어온다면 지금 시험해 볼 만합니다. 코드 수정은 정적 콘텐츠와 동적 질문 사이에 cachePoint 한 줄을 넣는 정도라 전담 인력 없이도 반나절이면 붙여 보고 usage 응답의 캐시 읽기·쓰기 토큰으로 효과를 바로 확인할 수 있습니다. 문서 하나에 질문 열 개 수준의 반복이라면 입력 토큰 비용이 약 75퍼센트 내려가므로, Bedrock 입력 토큰이 청구서에서 큰 비중이면 그만큼 매달 청구액이 줄어듭니다.

반대로 요청마다 컨텍스트가 매번 다르거나 호출량이 적어 같은 접두부가 5분 안에 다시 오지 않는다면 캐시 적중이 거의 없어 이번에는 넘겨도 됩니다. 쓰기 비용이 25퍼센트 비싸고 1시간 TTL은 2배이기 때문에, 적중률이 낮으면 오히려 청구액이 오릅니다. 적용 전에 실제 트래픽에서 같은 접두부가 TTL 안에 얼마나 자주 반복되는지부터 로그로 확인하세요. 교차 리전 추론 프로파일을 쓰면 캐시 쓰기가 늘 수 있으니, 캐싱 효과를 정확히 재려면 단일 리전에서 먼저 측정하는 편이 낫습니다.

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