프롬프트 캐싱 (Prompt Caching)

같은 프롬프트 앞부분을 계속 반복해서 보내다 보면, 매번 처음부터 다시 처리하는 게 아깝게 느껴질 때가 있죠. 프롬프트 캐싱은 이런 공통 접두사(prefix)를 재사용해 응답을 더 빠르게 만드는 성능 최적화 기능이에요. 상황에 따라 첫 토큰까지의 시간(TTFT)을 최대 80%까지 줄일 수 있고, 모든 Fireworks 모델과 배포에 기본으로 켜져 있어요.

출처: https://docs.fireworks.ai/guides/prompt-caching

비용·성능 이점

서버리스 모델에서는 캐시된 프롬프트 토큰이 일반 프롬프트 토큰보다 저렴해요. 기본 할인율은 50%이고 모델마다 다를 수 있으니 모델 라이브러리에서 확인하세요. 전용 배포에서는 캐싱이 리소스를 비워주기 때문에 같은 하드웨어에서 처리량이 더 높아져요. 캐시된 토큰은 컨텍스트 길이에는 영향을 주지만 추가 처리가 필요 없어 거의 공짜에 가까워요.

언제 효과적인가

LLM 요청은 프롬프트의 큰 부분을 공유하는 경우가 많아요. 예를 들어 긴 시스템 프롬프트, 도구 호출용 도구 설명, 채팅의 누적된 대화 이력, 코딩 어시스턴트의 공유 사용자 컨텍스트 같은 것들이죠. 이럴 때 캐싱이 중복 처리를 피하고 출력 생성을 훨씬 일찍 시작하게 해줘요.

캐싱을 위한 프롬프트 구조화

프롬프트 캐싱은 프롬프트 안의 정확한 접두사 일치에서만 동작해요. 그래서 지침·예시 같은 정적 내용은 프롬프트 앞쪽에, 사용자별 정보 같은 변동 내용은 뒤쪽에 두는 게 좋아요. 함수 호출 모델에서는 도구도 프롬프트의 일부로 간주돼요.

세션 어피니티로 캐시 적중률 높이기

프롬프트 캐싱은 복제본(replica) 1개 안에서만 동작해요. 서버리스나 복제본이 여러 개인 배포를 쓰면, 같은 접두사를 공유할 것으로 예상되는 요청이 같은 복제본에 가도록 힌트를 줘야 캐시 적중률이 올라가요. 사용자나 세션마다 고유 식별자를 요청 본문의 user 필드나 x-session-affinity 헤더에 넣으면 돼요. RL 롤아웃을 수집하고 턴 간 스티키니스가 필요하다면 x-multi-turn-session-id도 함께 설정해요.

from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("FIREWORKS_API_KEY"),
    base_url="https://api.fireworks.ai/inference/v1",
)

response = client.chat.completions.create(
    model="accounts/fireworks/models/<MODEL_ID>",
    messages=[{"role": "user", "content": "Explain quantum computing in simple terms"}],
    extra_headers={"x-session-affinity": "session-id-123"}
)

캐시 적중률을 높이는 프롬프트 최적화

LLM의 자기회귀 특성상 토큰 하나만 달라져도 그 지점부터 캐시가 무효화돼요. 프롬프트 접두사를 안정적으로 유지하는 게 가장 중요해요. 시스템 프롬프트 앞부분에 타임스탬프 같은 동적 내용을 넣으면 1초 차이로도 캐시 전체가 무효화되니 피해야 해요. 정적 내용을 앞에, 동적 내용을 뒤에 두고, 현재 시각이 필요하면 반올림한 시각을 쓰거나, 질의가 시각에 민감할 때만 조건부로 넣거나, 아예 시스템 프롬프트는 고정하고 사용자 메시지에 시각을 넣는 방식을 고려해 보세요.

어떻게 동작하나

Fireworks는 요청에서 캐시에 존재하는 가장 긴 접두사를 자동으로 찾아 재사용하고, 나머지 부분만 일반 처리해요. 전체 프롬프트는 이후 재사용을 위해 캐시에 저장되는데, 보통 최소 몇 분 동안 유지되고 모델·부하·배포 구성에 따라 몇 시간까지 갈 수 있어요. 프롬프트 캐싱은 모델이 생성하는 결과를 바꾸지 않아요. 캐싱을 쓰지 않을 때와 동일한 응답을 받아요.

프라이버시·모니터링

서버리스 배포는 계정별로 별도 캐시를 유지해 데이터 유출과 타이밍 공격을 막아요. 전용 배포는 기본적으로 모든 요청이 단일 캐시를 공유하는데, 타이밍 공격의 소소한 위험이 있을 수 있어요. 완전한 격리가 필요하면 x-prompt-cache-isolation-key 헤더나 prompt_cache_isolation_key 요청 필드로 추가 캐시 키를 지정하면 돼요. 전용 배포의 캐시 정보는 응답 헤더(fireworks-prompt-tokens, fireworks-cached-prompt-tokens)에서 확인할 수 있어요.

더 알아보기

서버리스 서빙 경로: 티어별 서빙
배포: 전용 GPU 배포와 캐싱
API 레퍼런스: prompt_cache_isolation_key 등 파라미터