Home / Prompt Caching / Prompt Caching
Note

Prompt Caching

Bedrock Prompt Caching 원리와 적용

⏱ 30분 18 / 189

Prompt Caching

Bedrock Prompt Caching 원리와 적용

무엇을 넣느냐가 성능을 결정한다

프롬프트 기법을 넘어 — 모델에 보여줄 컨텍스트를 설계하는 엔지니어링

Prompt Caching

반복 컨텍스트 비용 90% 절감 — 컨텍스트 최적화의 마지막 단계

PART 5 · Prompt Caching

Prompt Caching

반복 컨텍스트의 재계산을 생략하는 비용 최적화

반복 컨텍스트는 한 번만 계산

고정 프리픽스를 캐시에 저장해 재계산을 생략합니다 — 컨텍스트 최적화의 마지막 단계입니다.

  • 원리 — 첫 호출 기록, 이후 참조
  • 요율 — 읽기 0.1× · 기록 1.25×
  • 구조 — 정적 우선 프롬프트 배치
  • 적용 — Converse API cachePoint
takeaway

에이전트는 같은 시스템 프롬프트를 수백 번 재전송합니다 — 캐싱만으로 반복 구간 입력 비용이 90% 줄어듭니다.

PART 5 · Prompt Caching

캐시 있음 vs 없음

반복되는 시스템 프롬프트와 고정 문서를 캐시 — 비용을 극적으로 절감

캐시 없음

매번 전체 전송

  • 모든 호출에 System Prompt 전체 전송
  • 고정 문서(RAG 결과)도 매번 토큰 소비
  • 에이전트: 100회 호출 × 전체 비용
  • 장문 시스템 프롬프트일수록 비용 폭증

에이전트가 100번 모델을 호출하면, System Prompt 4,000 토큰 × 100회 = 40만 토큰을 동일 내용에 소비합니다.

캐시 있음

첫 회만 전송, 이후 90% 할인

  • 첫 호출에 캐시 생성 (cache_write 비용)
  • 이후 호출은 캐시 참조 (cache_read = 90% 할인)
  • 에이전트: 1회 전체 + 99회 캐시
  • TTL 기본 5분 (1시간은 일부 모델 한정) 내 재사용

Claude Prompt Caching: cache_read는 input 대비 90% 저렴. 모델별 최소 토큰(Sonnet 4.6=1,024, Sonnet 4.5·Haiku 4.5·Opus 4.5+=4,096 — Bedrock 기준) 이상이면 적용됩니다.

takeaway

2회 이상 호출하면 이득입니다 — 호출 빈도가 높을수록 절감 폭이 커집니다.

PART 5 · Prompt Caching

캐시 요율과 제약

캐시는 공짜가 아님 — 기록 비용·TTL·격리 범위까지 알아야 설계 가능

항목값비고
캐시 읽기 (read)입력 요율의 0.1×반복 구간 90% 절감
캐시 기록 (write)입력 요율의 1.25×5분 TTL 기준 — 1시간 TTL 기록은 2×
TTL기본 5분캐시 적중 시 무료 갱신 — 1시간 TTL은 4.5 세대 + Sonnet 4.6 · Opus 4.6 · Opus 4.8 · Sonnet 5 · Opus 5 지원 (기록 2×)
체크포인트최대 4개system · toolConfig · messages 어디든 배치
최소 토큰모델별 1,024~4,096Sonnet 4.6=1,024 · Sonnet 4.5/Haiku 4.5/Opus 4.5+=4,096 (Bedrock 기준)
캐시 격리Bedrock: AWS 계정 단위Anthropic API: workspace 단위 — 조직 간 공유 없음
takeaway

기록은 1.25배 비싸지만 읽기가 0.1배입니다 — 두 번째 호출부터 이득이고, 적중이 이어지는 한 TTL은 무료로 갱신됩니다.

PART 5 · Prompt Caching

정적 우선 프롬프트 구조

고정 레이어를 상단에 쌓아 캐시하고, 가변 레이어만 하단에서 교체하는 구조

System Prompt (고정)

역할·규칙·형식 — 모든 호출에 동일 → 항상 캐시 대상

Tool Definitions (고정)

도구 스키마 목록 — 에이전트 수명 동안 변하지 않음

Reference Documents (준고정)

RAG 결과, 가이드 문서 — 세션 내 고정. cachePoint 지정

Conversation History (가변)

이전 대화 — 턴마다 증가. 캐시 어려움 → Compress 전략 적용

User Message (가변)

현재 질문 — 매번 다름. 캐시 불가

PART 5 · Prompt Caching

Prompt Caching 적용

Bedrock Converse API에서 캐시를 활성화하는 방법

python
import boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    system=[
        {'text': '당신은 AWS Solutions Architect입니다. ...(긴 시스템 프롬프트)...'},
        # ① 캐시 체크포인트 — text와 같은 dict가 아니라 별도 블록 (단일 멤버 유니온)
        {'cachePoint': {'type': 'default'}},
    ],
    messages=[
        {'role': 'user', 'content': [{'text': '질문'}]}
    ],
)

# ② 응답의 usage에서 캐시 히트 확인
usage = response['usage']
# cacheReadInputTokens > 0이면 캐시 적중
  • cachePoint — 여기까지의 프리픽스를 캐시하라는 표시. system · toolConfig · messages.content에 배치, 최대 4개
  • 고정 레이어 바로 뒤에 삽입 — 긴 시스템 프롬프트 끝이 캐시 경계가 됨
  • usage로 검증 — cacheWriteInputTokens는 첫 호출의 기록량, cacheReadInputTokens > 0이면 적중(90% 할인 구간)
PART 5 · Prompt Caching

다음 단계: 하네스 엔지니어링

컨텍스트도 결국 하네스의 일부 — 모델을 감싸는 전체 실행 환경을 설계

컨텍스트는 하네스의 한 레이어

프롬프트 → 컨텍스트를 마스터했다면, 이제 오케스트레이션·도구·메모리·가드레일·평가까지 포함하는 하네스 엔지니어링입니다.

  • 오케스트레이션
  • 도구
  • 메모리
  • 가드레일
  • 평가
  • AgentCore
takeaway

"무엇을 보여줄까"의 다음 질문은 "어떤 환경에서 실행할까"입니다 — 모델을 감싸는 실행 환경 전체의 설계로 이어집니다.

컨텍스트를 설계하면, 모델이 달라집니다.

다음은 모델을 감싸는 실행 환경 전체를 설계하는 하네스 엔지니어링.