프롬프트 캐싱 (Prompt Caching)

멀티턴 대화를 이어가거나 RAG를 쓸 때 같은 프롬프트 앞부분을 응답마다 처음부터 다시 처리한다면 느리고 비싸요. Cerebras 프롬프트 캐싱은 이전에 처리한 프롬프트를 저장해 재사용해서, 유사하거나 반복되는 요청의 지연을 줄이고 응답 속도를 높여줘요.

출처: Cerebras Inference - Prompt Caching

무엇이 좋아지나요

프롬프트 캐싱은 Time to First Token(TTFT)을 줄이고, 멀티턴 대화·RAG(검색 증강 생성)·에이전틱 워크플로 같은 긴 컨텍스트 작업의 응답성을 높여줘요.

다른 프로바이더처럼 수동 캐시 중단점(breakpoint)을 설정하거나 헤더를 바꿀 필요 없이, Cerebras 프롬프트 캐싱은 지원되는 모든 API 요청에서 자동으로 동작해요. 코드 변경이 필요 없어요.

어떻게 동작하나요

프리픽스 매칭 — 요청을 보내면 시스템이 프롬프트의 시작 부분(프리픽스)을 분석해요. 여기에는 시스템 프롬프트, 도구 정의, few-shot 예시가 포함돼요.
블록 기반 캐싱 — 시스템이 프롬프트를 128-토큰 블록 단위로 처리해요.

각 턴에서 시스템은 이전 요청으로부터 가장 긴 일치하는 프리픽스를 자동으로 캐시해요. 예를 들어 온라인 쇼핑 어시스턴트가 주문 상태 확인과 주문 취소라는 두 도구(get_order_status, cancel_order)를 쓰는 시나리오를 보면:

시스템 메시지 — 쇼핑 어시스턴트 지시는 모든 턴에서 동일하게 유지돼요.
도구 정의 — 두 주문 관리 도구의 스키마(파라미터·설명 포함)는 고정돼요.
대화 이력 — 이전 사용자 메시지, 어시스턴트 응답, 도구 결과가 대화가 길어짐에 따라 모두 캐시돼요.

요청 끝에 있는 새 내용만 새로 처리하면 돼요:

새 사용자 메시지(가장 최근 질문)
새 도구 실행 결과
현재 턴의 모델 리즈닝과 판단

대화가 길어질수록 캐시 히트율이 크게 올라가요. 고정 프리픽스(시스템 + 도구)는 계속 캐시된 채 유지되고, 늘어나는 대화 이력도 함께 캐시되므로, 가장 최근 사용자 메시지와 모델의 새 응답만 전체 처리하면 돼요.

캐시를 위해 프롬프트 구성하기

시스템은 메시지 시작부터 프롬프트를 캐시해요. 프롬프트 맨 앞에 타임스탬프나 고유 User ID 같은 동적 콘텐츠를 넣으면 요청마다 프리픽스가 달라져 캐시가 절대 동작하지 않아요.

정적 콘텐츠를 앞에 둬요:

시스템 지시("You are a helpful assistant...")
도구 정의와 스키마
Few-shot 예시
큰 컨텍스트 문서(예: 법률 계약서나 코드베이스)

동적 콘텐츠를 뒤에 둬요:

사용자별 질문
세션 변수
타임스탬프

예를 들어 "You are a coding assistant..." 지시 블록이 정적이면 이후 요청에서 캐시돼요. 짧은 타임스탬프와 사용자 질문만 새로 처리하면 돼요. 시스템 프롬프트의 정적 부분이 캐시되고, 이후 요청은 캐시를 재사용하며 타임스탬프와 사용자 질문만 처리해요.

캐시 사용량 추적하기

요청이 캐시에 적중하는지 확인하려면 응답 객체의 usage.prompt_token_details 안에 있는 cached_tokens 필드를 보면 돼요. 이 값은 캐시에서 찾은 프롬프트 토큰 수를 나타내요.

"usage": {
  "prompt_tokens": 3000,
  "completion_tokens": 150,
  "total_tokens": 3150,
  "prompt_tokens_details": {
    "cached_tokens": 2800
  }
}

이 예시에서 캐시가 3,000개의 프롬프트 토큰 중 2,800개를 제공했고, 그만큼 처리가 빨라졌어요.

자주 묻는 질문

프롬프트 캐싱은 안전한가요? 네, 완전히 ZDR(제로 데이터 보존)을 준수해요. 캐시된 모든 컨텍스트는 메모리에만 일시적으로 남고 영구 저장되지 않아요. 캐시된 토큰은 트래픽을 서빙하는 모델 인스턴스와 같은 데이터 센터에 함께 위치한 키-값 스토어에 저장돼요.

프롬프트 캐싱 (Prompt Caching)