LLM 프롬프트 캐싱 개념 정리 (Prompt Caching)

이 글은 Nikita Parate의 Medium 글 Prompt Caching in LLM Systems(2024-08-31)을 읽고 핵심 내용을 재구성해 정리한 것이다. 원문 전체 번역이 아니라 요약과 재해석이므로 상세한 코드 예시와 설명은 원문을 참고하면 된다.

1. 개념 요약

프롬프트 캐싱(prompt caching)은 LLM에 반복해서 들어오는 프롬프트나 프롬프트의 공통 부분을 저장해 두었다가 재사용하는 기법이다. 시스템 프롬프트, 도구 정의, 긴 참조 문서처럼 매 요청마다 동일하게 붙는 입력을 매번 처음부터 처리하지 않기 때문에 응답 지연과 토큰 비용을 함께 줄일 수 있다.

사내 LLM 게이트웨이를 운영하면서 캐시 히트율이 비용에 직접 영향을 주는 것을 확인했기 때문에 동작 원리를 개념 수준에서 정리해 둔다.

2. 왜 필요한가

LLM API 비용은 입력 토큰 수에 비례한다. 에이전트나 챗봇은 요청마다 시스템 프롬프트, 도구 스키마, 대화 이력을 전부 다시 보내는 구조이기 때문에 대화가 길어질수록 같은 내용을 반복해서 지불하게 된다. 예를 들어 10만 토큰짜리 문서를 놓고 질문을 10번 주고받으면 문서 처리 비용을 10번 내는 셈이다.

프롬프트 캐싱은 이 반복 구간의 처리 결과를 저장해 두고 재사용한다. 반복 비중이 큰 워크로드일수록 절감 폭이 커진다.

3. 캐싱 전략

원문은 두 가지 접근을 소개한다.

임베딩 유사도 방식은 "비슷한 질문에 같은 답을 재사용"하는 시맨틱 캐시에 가깝다. 원문은 의미가 상반된 두 문장이 0.997이라는 높은 유사도 점수를 받는 예시를 들어 이 방식의 한계를 지적한다. 유사도만 믿고 캐시된 응답을 반환하면 틀린 답을 줄 수 있다.

어텐션 상태 기반 방식은 트랜스포머가 프롬프트를 처리하며 만든 내부 상태(KV 캐시)를 저장한다. 인사말, 요청 본문 같은 모듈 단위로 캐시하면 프롬프트 일부만 바뀌어도 공통 접두 부분의 계산을 재사용할 수 있다. Anthropic이나 OpenAI가 제공하는 프롬프트 캐싱 기능이 이 계열이다.

4. 동작 흐름

flowchart TD
    A[새 프롬프트 수신] --> B[해시 또는 유사도 점수로 식별자 생성]
    B --> C{캐시 조회}
    C -->|캐시 히트| D[저장된 결과 반환]
    C -->|캐시 미스| E[LLM이 프롬프트 처리]
    E --> F[결과를 식별자와 함께 캐시에 저장]
    F --> G[응답 반환]
    D --> G

새 프롬프트가 들어오면 먼저 암호화 해시나 유사도 점수로 고유 식별자를 만든다. 이 식별자로 캐시를 조회해서 일치하는 항목이 있으면 저장된 결과를 바로 반환한다. 없으면 LLM이 프롬프트를 처리한 뒤 그 결과를 식별자와 함께 캐시에 저장한다. 다음에 같은 프롬프트가 오면 캐시 히트가 된다.

5. 캐시 가능한 요소

프롬프트에서 캐시할 수 있는 대상은 응답 텍스트만이 아니다. 원문은 다섯 가지를 든다.

에이전트 워크로드에서는 도구 정의와 시스템 메시지가 매 요청 앞부분에 그대로 반복되기 때문에 이 둘만 캐시해도 효과가 크다.

6. 비용 구조

원문 작성 시점(2024년 8월)의 Claude 3.5 Sonnet 기준 가격은 다음과 같다.

캐시에 쓰는 첫 요청은 기본 입력보다 25% 비싸다. 대신 이후 읽기는 10% 가격이므로 같은 접두 부분을 두 번 이상 재사용하면 이득이 시작되고 반복이 많은 워크로드에서는 입력 비용을 최대 90%까지 줄일 수 있다. 가격은 모델과 시점에 따라 달라지므로 적용 전에 제공사의 최신 가격표를 확인해야 한다.

7. 활용 분야

• 시스템 프롬프트와 이력이 길어지는 장시간 대화 시스템
• 코드베이스 전체를 컨텍스트로 유지하는 코드 완성과 질의응답
• 대용량 문서를 올려 두고 반복 질의하는 문서 처리
• 동일한 교육 자료를 여러 학습자에게 제공하는 교육 서비스
• 판례와 조문을 반복 참조하는 법률 문서 조회

공통점은 고정된 큰 컨텍스트에 작은 가변 질의가 반복되는 구조라는 것이다. 이 구조가 아니라면 캐시 쓰기 비용만 내고 히트가 나지 않을 수 있다.

8. 자주 헷갈리는 지점

• 응답 캐시와 접두 캐시는 다르다. 임베딩 유사도 방식은 완성된 응답을 재사용하고 어텐션 상태 방식은 입력 처리 결과를 재사용한다. 전자는 모델 호출 자체를 생략하지만 오답 위험이 있고 후자는 매번 새 응답을 생성하되 입력 비용만 줄인다.
• 캐시 쓰기는 공짜가 아니다. 첫 요청은 오히려 기본 입력보다 비싸다. 한 번 쓰고 재사용하지 않는 프롬프트를 캐시하면 비용이 늘어난다.
• 캐시는 접두(prefix) 단위로 동작한다. 제공사 구현 기준으로 프롬프트 앞부분이 완전히 일치해야 히트가 난다. 시스템 프롬프트에 타임스탬프처럼 매번 바뀌는 값을 넣으면 캐시가 무효화된다.

9. 확인 방법

캐시가 실제로 동작하는지는 API 응답의 usage 필드로 확인한다.

같은 프롬프트를 두 번 호출했을 때 두 번째 응답에서 캐시 읽기 토큰 수가 0보다 크면 캐시가 동작하는 것이다. 계속 0이라면 접두 부분이 요청마다 달라지고 있거나 최소 캐시 토큰 조건을 채우지 못한 경우일 가능성이 있다.

10. 다음에 볼 개념

제공사별 구현 차이를 볼 차례다. Anthropic의 cache_control 브레이크포인트 지정 방식과 TTL 옵션, OpenAI의 자동 프롬프트 캐싱이 접두 일치와 최소 토큰 조건을 어떻게 다루는지 비교하면 게이트웨이에서 캐시 히트율을 높이는 프롬프트 배치 전략으로 이어진다.

출처

• Nikita Parate, Prompt Caching in LLM Systems, Medium, 2024-08-31