Amazon Bedrock은 이제 개발자가 프롬프트의 일부를 캐싱할 수 있도록 하여, 정적 프롬프트 접두사(prefix)를 재사용하는 애플리케이션의 토큰 사용 비용을 최대 90%까지 줄이고 응답 지연 시간을 최대 85%까지 단축할 수 있게 합니다.
이번 변화가 중요한 이유
대규모 언어 모델(LLM)을 온디맨드로 실행하면 토큰이 모델로 전송될 때마다 비용이 발생합니다. 챗봇, 코드 어시스턴트, 문서 검색 도구는 종종 동일한 시스템 지침이나 참조 자료를 다시 전송하므로, 비용이 증가하고 응답 속도가 느려집니다.
프롬프트 캐싱 작동 방식
Bedrock은 개발자가 프롬프트의 특정 세그먼트에 추가할 수 있는 “cacheable” 플래그를 도입했습니다. 이 세그먼트는 일반적으로 세션 동안 변경되지 않는 시스템 수준의 지침, 긴 배경 문서 또는 도구 정의입니다. 요청이 들어오면 Bedrock은 플래그가 지정된 세그먼트가 저장된 항목과 일치하는지 확인합니다. 일치하는 경우, 서비스는 해당 부분을 다시 인코딩하거나 모델을 통해 다시 실행하는 과정을 건너뛰고 대신 캐시에서 미리 계산된 표현(representation)을 가져옵니다.
수치로 보는 효과
- 입력 토큰 비용: 캐싱된 접두사가 매 호출마다 토큰을 소비하지 않으므로 최대 90%까지 절감됩니다.
- 지연 시간(Latency): 정적 부분에 대한 모델의 과도한 연산을 피할 수 있어 최대 85%까지 빨라집니다.
가장 적합한 시나리오
이 기능은 프롬프트에 크고 변하지 않는 블록이 포함되어 있고, 그 뒤에 짧고 가변적인 사용자 쿼리가 이어지는 경우에 빛을 발합니다. 일반적인 패턴은 다음과 같습니다.
- 모든 쿼리에 검색된 문서를 앞에 붙이는 검색 증강 생성(RAG) 파이프라인.
- 항상 동일한 정책 성명이나 톤 설정 텍스트로 시작하는 고객 지원 봇.
- 개발자의 코드 스니펫 앞에 고정된 언어 도구 정의를 로드하는 코딩 어시스턴트.
개발자가 변경해야 할 사항
개발자는 정적 콘텐츠가 프롬프트의 맨 처음에 위치하고, 호출 간에 바이트 단위로 완전히 동일하게 유지되도록 프롬프트 순서를 재조정해야 합니다. 가변적인 사용자 입력은 캐싱된 접두사 뒤에 옵니다. 모델을 전환할 필요는 없으며, 동일한 Bedrock 엔드포인트가 요청을 처리합니다.
수혜 대상 및 주의 사항
이 이점은 접두사가 실제로 정적으로 유지되는 워크로드에만 적용됩니다. 사용자별로 시스템 지침을 개인화하거나 컨텍스트를 자주 변경하는 애플리케이션은 이점이 거의 없으므로, 추가되는 프롬프트 복잡성과 미미한 이득 사이에서 신중히 따져봐야 합니다.
요약: 애플리케이션이 재사용 가능한 프롬프트 접두사를 분리할 수 있다면, 프롬프트 캐싱은 Bedrock 사용자에게 AI 운영 비용을 절감하고 응답 시간을 개선할 수 있는 직관적인 수단을 제공합니다.