Skip to Content
개발 문서고급 기능Gemini 명시적 캐싱

Gemini 명시적 캐싱(cachedContents)

Gemini의 캐싱은 두 종류로 나뉩니다.

  • 암시적 캐싱(자동) — 모델이 반복되는 프롬프트 접두사를 자동으로 감지하여 재사용하며, 별도의 설정이 필요 없습니다. 프롬프트 캐싱 문서에서 다루는 기본 동작으로, 적중은 「최선 노력(best-effort)」 방식이며 접두사가 조금만 바뀌어도 미적중될 수 있습니다.
  • 명시적 캐싱(이 문서) — 대용량 컨텍스트를 직접 캐시 객체로 생성하여 cachedContents/{id} 핸들을 받고, 이후의 generateContent 요청에서 이를 명시적으로 참조합니다. 적중은 확정적입니다. 캐시가 만료되지 않은 한, 참조하면 반드시 적중합니다.

반복 사용되며 내용이 안정적인 대용량 컨텍스트(긴 문서, 코드베이스, 지식 베이스, 고정 system 지시문)가 있고, 적중률을 제어하고 비용을 예측 가능하게 하고 싶을 때 명시적 캐싱을 사용하세요.

OfoxAI는 Gemini 네이티브 cachedContents생성 / 참조 / 조회 / 삭제를 지원하며, Google GenAI SDK와 호환됩니다. 엔드포인트 수준 참조는 cachedContents API를 확인하세요.

명시적 캐싱을 사용할 때

시나리오권장
대용량 고정 컨텍스트에 대한 반복 Q&A(문서 QA, 코드 어시스턴트)✅ 명시적 캐싱
적중을 보장해야 하고 간헐적 미적중을 허용할 수 없음✅ 명시적 캐싱
짧고 빈도가 낮으며 접두사가 자주 바뀌는 요청❌ 암시적 캐싱으로 충분하며, 관리할 캐시 객체가 없음
컨텍스트가 매번 바뀜❌ 캐싱의 의미가 없음

명시적 캐싱은 캐싱할 콘텐츠가 최소 토큰 임계값(모델에 따라 다르며 대략 2048~4096 token부터)을 충족해야 합니다. 콘텐츠가 너무 작으면 생성에 실패하거나 이점이 없습니다.

엔드포인트

OfoxAI는 Gemini 네이티브 프로토콜에서 완전한 cachedContents 엔드포인트를 제공합니다.

POST https://api.ofox.ai/gemini/v1beta/cachedContents # 생성 GET https://api.ofox.ai/gemini/v1beta/cachedContents/{id} # 조회 DELETE https://api.ofox.ai/gemini/v1beta/cachedContents/{id} # 삭제

캐시를 참조하여 콘텐츠를 생성할 때는 표준 generateContent 엔드포인트를 사용하되, 요청 본문에 cachedContent를 추가합니다.

POST https://api.ofox.ai/gemini/v1beta/models/{model}:generateContent

인증

다른 Gemini 엔드포인트와 동일하게 x-goog-api-key Header를 사용합니다.

x-goog-api-key: <당신의 OFOXAI_API_KEY>

전체 흐름

다음은 캐시 생성 → 캐시 참조 생성 → 캐시 삭제의 전체 과정을 보여줍니다.

1. 캐시 생성

재사용할 대용량 컨텍스트를 contents에 넣고, modelttl(존속 시간)을 지정합니다.

create_cache.py
from google import genai from google.genai import types client = genai.Client( api_key="<당신의 OFOXAI_API_KEY>", http_options={"api_version": "v1beta", "base_url": "https://api.ofox.ai/gemini"}, ) # 반복 사용되는 대용량 문서(최소 토큰 임계값을 충족해야 함) LONG_DOCUMENT = open("knowledge_base.txt").read() cache = client.caches.create( model="google/gemini-3.1-pro-preview", config=types.CreateCachedContentConfig( contents=[LONG_DOCUMENT], ttl="600s", # 캐시 존속 10분 ), ) print(cache.name) # cachedContents/xxxxxxxx —— 이후 참조에 사용할 핸들

반환된 name(cachedContents/xxxxxxxx 형태)이 캐시 핸들입니다. 이후 참조와 관리를 위해 저장해 두세요.

2. 캐시 참조 생성

generateContent 요청에서 cachedContent로 캐시 핸들을 참조합니다. contents에는 이번에 새로 추가된 질문만 넣으면 됩니다.

use_cache.py
response = client.models.generate_content( model="google/gemini-3.1-pro-preview", contents="根据上面的文档,总结三条要点", config=types.GenerateContentConfig( cached_content=cache.name, # 캐시 참조 ), ) print(response.text) # 캐시 적중: 캐싱된 부분은 더 낮은 「읽기」 가격으로 과금됨 print(response.usage_metadata.cached_content_token_count)

적중 시, 응답의 usageMetadata.cachedContentTokenCount에 캐시로 처리된 token 수가 표시됩니다. 동일한 캐시는 만료될 때까지 몇 번이든 참조할 수 있으며, 매번 확정적으로 적중합니다.

3. 조회와 삭제

캐시 메타데이터를 조회하거나, 더 이상 필요 없을 때 직접 삭제합니다(TTL 만료를 기다릴 필요 없음).

manage_cache.py
# 조회 info = client.caches.get(name=cache.name) print(info.expire_time) # 삭제 client.caches.delete(name=cache.name)

조회 / 삭제에는 model을 다시 전달할 필요가 없습니다. OfoxAI는 캐시 핸들만으로 해당 캐시를 찾아냅니다.

수명 주기와 TTL

생성 시 ttl로 존속 시간을 지정하며, s로 끝나는 초 단위 문자열 형식입니다(예: "600s").

파라미터
최소 / 기본 TTL600s(10분)
최대 TTL3600s(1시간)
  • 캐시는 TTL 이내에 반복 참조할 수 있으며 확정적으로 적중합니다.
  • TTL이 만료되면 캐시는 자동으로 무효화되며, 다시 참조하면 오류가 발생합니다(캐시가 더 이상 존재하지 않음).
  • 언제든 직접 delete하여 미리 해제할 수 있습니다.

TTL이 만료되었거나 이미 삭제된 캐시를 참조하면 요청이 실패합니다. 클라이언트 측에서 「캐시 무효화」 상황을 처리하세요(오류를 포착한 뒤 캐시를 재생성하거나 일반 요청으로 폴백).

과금

명시적 캐싱은 token 단위로 투명하게 과금되며, 세 부분으로 나뉩니다.

단계과금 공식설명
캐시 생성totalTokenCount × cache_write 단가「캐시 쓰기」 가격으로 과금됩니다. totalTokenCount는 생성 응답의 usageMetadata에서 가져오며, 캐싱된 token 수입니다
참조 적중cachedContentTokenCount × cache_read 단가캐싱된 부분은 「캐시 읽기」 가격으로 과금되며, 표준 입력 가격의 약 0.10x로 전체를 재전송하는 것보다 훨씬 저렴합니다
참조 시 새 콘텐츠이번에 새로 추가된 prompt / 출력은 표준 가격으로 과금즉, 매번 새로 던지는 질문과 모델의 새 답변

수익 모델: 생성 시 「쓰기」 비용을 한 번 지불한 뒤, 이후 캐싱된 콘텐츠를 참조할 때마다 낮은 「읽기」 가격으로 과금되어, 「전체 컨텍스트를 정가로 재전송」하는 비용을 절약합니다. 참조 횟수가 많을수록 더 이득입니다. 각 모델의 cache_write / cache_read 단가는 모델 카탈로그 와 콘솔 사용량 통계를 기준으로 합니다.

OfoxAI에서의 강화: 확정적 라우팅

OfoxAI는 여러 GCP 리전 / 여러 Vertex 프로젝트 간에 부하를 분산합니다. 명시적 캐시는 region-scoped(리전 바인딩) 입니다. 캐시가 생성된 GCP 프로젝트에서 참조해야 하며, 그렇지 않으면 404가 발생합니다.

OfoxAI가 이를 자동으로 처리합니다. 캐시 생성 시 해당 캐시가 바인딩된 업스트림 인스턴스를 기록하고, 이후 캐시 핸들로 역조회하여 동일한 업스트림으로 하드 락(hard-lock)합니다. 참조 요청에 user 식별자가 있든 없든, 부하가 어떻게 스케줄링되든, 참조는 캐시를 생성한 그 프로젝트로 정확히 라우팅되며 드리프트가 전혀 없습니다(zero drift). 하부 리전 분포는 신경 쓰지 않아도 됩니다.

캐시 소유권에는 무단 접근 보호가 적용됩니다. 캐시 핸들은 이를 생성한 API Key(및 동일 소유자)만 참조 / 조회 / 삭제할 수 있으며, 계정 간 접근은 거부됩니다(403).

명시적 캐싱 vs 암시적 캐싱

항목암시적 캐싱(자동)명시적 캐싱(cachedContents)
트리거 방식반복 접두사 자동 감지캐시 객체를 직접 생성하고 참조
적중 확정성최선 노력, 접두사가 조금만 바뀌어도 미적중 가능확정적, 만료되지 않으면 반드시 적중
관리 필요없음핸들 생성 / 참조 / 삭제 필요
적합 대상짧고 접두사가 가끔 반복되는 경우크고 안정적이며 반복 재사용되는 컨텍스트
과금적중 시 읽기 가격 할인생성 시 쓰기 가격 + 참조 시 읽기 가격 할인

둘은 함께 사용할 수 있습니다. 일상적인 요청은 암시적 캐싱이 자동으로 적용되도록 두면 되고, 확실히 반복 재사용할 대용량 컨텍스트에는 명시적 캐싱으로 적중을 고정하세요. 암시적 캐싱의 세부 내용은 프롬프트 캐싱을 참고하세요.

관련 문서

Last updated on