DeepSeek V4 컨텍스트 캐싱: 반복 프롬프트 비용 90% 절감

안녕하세요, 저는 Dora입니다. 지난주에 사소한 일 때문에 당황했습니다. 최신 초안을 어디에 두었는지 기억이 나지 않아서 같은 프롬프트를 세 번이나 실행했거든요. 출력 결과는 거의 달라지지 않았지만, 레이트 리밋은 줄어들었습니다. 그게 DeepSeek v4 캐시에 대해 생각하게 된 계기였습니다. 기적을 바라는 게 아닙니다. 그저 불필요한 API 호출을 줄이고, 더 안정적인 레이턴시를 확보하고, 레이트 리밋 아래에서 조금 여유를 갖고 싶을 뿐입니다. v4에 대한 공식 문서가 아직 충분하지 않아서, v3 및 유사한 API에서 실제로 확인한 내용을 바탕으로 삼아 실용적인 클라이언트 측 패턴을 몇 가지 만들었습니다. DeepSeek이 v4 공식 캐시를 출시한다면, 기존 워크플로를 뒤집지 않고도 바로 연결할 수 있도록 준비해두고 싶습니다.

DeepSeek v4 캐시 문제에 접근하는 방식은 이렇습니다. 제한을 전제하고, 반복 가능한 것은 캐시하고, 차분하게 재시도하고, 적절한 지표를 모니터링합니다.

예상 레이트 리밋

v4에 대한 깔끔한 공개 표를 아직 찾지 못했기 때문에, 공항 환승처럼 접근했습니다. 빡빡한 일정을 가정하고 지연에 대비하는 것입니다.

DeepSeek v3와 유사한 공급자들과 작업하면서 알게 된 내용은 간단합니다.

일반적으로 일상적으로 중요한 두 가지 한도가 있습니다. 분당 요청 수(RPM)와 분당 토큰 수(TPM)입니다. 배치 처리나 백그라운드 작업 실행 시 429 오류가 빠르게 나타납니다.
버스트는 잠깐은 통과하다가 갑자기 막히기도 합니다. 스파이크성 부하가 잠깐 작동하다가 다음 순간 잠겨버릴 수 있습니다.
리밋은 키, 계정 등급, 때로는 IP에 따라 다를 수 있습니다. 그래서 로컬 테스트에서는 여유롭게 느껴지지만 프로덕션은 더 가혹합니다.

따라서 DeepSeek v4 캐시를 생각할 때 보수적인 레이트 핸들링과 함께 사용하고 있습니다. 목표는 모든 호출을 끝까지 쥐어짜는 게 아니라, 오후 내내 429 오류를 쫓아다니지 않도록 곡선을 평탄하게 만드는 것입니다.

현재 V3 리밋 기반

2026년 1월에 v3 엔드포인트에서 생성 호출과 리랭킹 호출을 혼합하여 가벼운 테스트를 몇 차례 진행했습니다. 과학적인 실험은 아니고, 그저 한계를 느끼기에 충분한 정도였습니다. 몇 가지 메모를 남겨두었습니다.

토큰이 많은 프롬프트(긴 컨텍스트 윈도우)는 RPM보다 TPM에 먼저 걸립니다. 이는 출력이 바뀌더라도 무거운 부분을 캐시하는 게 효과적이라는 뜻입니다.
짧고 반복적인 프롬프트(헬스 체크, 템플릿 실행)는 RPM에 먼저 걸립니다. 짧은 TTL의 응답 캐시에 이상적인 후보입니다.
백오프는 효과가 있지만, 지수 백오프만으로는 계획이 되지 않습니다. “정중하게 기다리는” 동안 동시성이 폭발하지 않도록 큐가 필요합니다.

이 모든 것을 종합하면, v4가 v3 티어를 따른다면 대용량 컨텍스트에서는 빡빡한 TPM, 인터랙티브 사용에서는 적절한 RPM, 버스트성 워크로드에 대한 빠른 페널티를 예상합니다. 저의 설정은 바쁜 시간대에 429와 5xx 스파이크가 발생한다고 가정하며, 이를 예외가 아닌 정상으로 취급합니다.

클라이언트 측 패턴

공식 DeepSeek v4 캐시 기능이 나올 때까지 기다리지 않고 제 쪽을 정리해두었습니다. 이 패턴들은 API 앞에 배치해두어서 나중에 공급자 캐시로 교체하더라도 작업 방식을 바꾸지 않아도 됩니다.

지수 백오프

처음에는 단순한 지수 백오프(200ms, 400ms, 800ms, 최대 5~8초)를 사용했습니다. 동작은 했지만 부하 상황에서 불안정하게 느껴졌습니다. 도움이 된 것들은 다음과 같습니다.

지터 추가. 각 지연에 약간의 무작위성을 추가합니다(예: 20~30% 분산). 재시도를 분산시키고 많은 호출이 동시에 실패할 때 동기 폭풍을 방지합니다.
재시도 횟수 제한. 멱등성 읽기나 캐시된 프롬프트는 세 번, 명백히 사용자 대면 상호작용은 UI가 스피너를 기대하지 않는 한 한 번만 시도합니다. 10초 이상 걸린다면, 누군가를 붙잡아두기보다 우아하게 실패하는 편이 낫습니다.
429와 5xx 구별. 429는 전체 큐를 늦춰야 한다는 신호입니다. 5xx는 짧은 순간적 오류를 의미합니다. 몇 번 재시도한 후 서킷을 열겠습니다(아래에서 자세히 설명합니다).

작은 관찰: 처음에는 백오프가 시간을 절약해주지 않았습니다. 하지만 몇 번의 실행 후 정신적 노력이 줄었습니다. 터미널을 감시하지 않아도 되었는데, 저에게는 그게 속도만큼 가치 있는 일입니다.

요청 큐잉

동시성은 항상 문제가 생기는 부분입니다. 다음 규칙을 적용한 간단한 클라이언트 측 큐를 추가했습니다.

고정 동시성(백그라운드 작업은 워커 2~~4개, UI 트리거 작업은 1~~2개로 시작). 조용한 시간이 지난 후에만 늘립니다.
토큰 인식 스케줄링. 토큰 수를 예측할 수 있다면 조용한 시간에 무거운 프롬프트를 먼저 처리하고, 가벼운 호출로 채웁니다. TPM을 더 평탄하게 유지합니다.
우선순위 레인. 사용자 액션은 배치 작업을 선점할 수 있습니다. 누군가 기다리고 있다면 시스템이 비켜줍니다.

비싼 부분도 업스트림에서 캐시합니다.

프롬프트 스캐폴드. 시스템 프롬프트와 도구가 거의 변하지 않는다면, 해시를 만들어 캐시 키로 사용합니다. v4에서 서버 측 컨텍스트 캐시가 출시된다면 그 키를 같이 전달할 것입니다. 지금은 그냥 제 자체 태그입니다.
검색된 컨텍스트. RAG 청크를 콘텐츠 지문으로 캐시합니다. 소스가 변경되지 않았다면 매번 다시 가져오고 임베딩하는 대신 동일한 컨텍스트 블록을 재사용합니다.

화려하지는 않지만, 일주일 동안 백그라운드 작업의 429 오류를 약 70% 줄였습니다. 더 빠르지는 않지만, 더 안정적입니다.

서킷 브레이커

이게 필요할 거라고 예상하지 못했습니다. 그런데 어느 날 오후 서비스가 몇 분 동안 5xx를 던지기 시작했고, 재시도 로직이 그걸 기꺼이 증폭시켰습니다. 서킷 브레이커가 그 문제를 해결했습니다.

규칙은 단순합니다.

오류율이 임계값을 초과하면(예: 60~90초 윈도우에서 호출의 30% 이상 실패) 또는 레이턴시가 연속 두 윈도우 동안 P95를 초과하면 서킷을 엽니다.
열려 있는 동안 호출을 단락시키고 폴백합니다. 캐시된 응답이 있으면 제공하고, 기능을 저하시키거나(더 작은 컨텍스트, 더 단순한 프롬프트), 일시 중지를 설명하는 조용한 메시지를 표시합니다.
백오프 기간 후 반열림 상태로 전환합니다. 소량의 요청을 통과시키고 지표를 관찰합니다. 안정적이면 서킷을 닫습니다.

뜻밖에도 UI가 얼마나 차분해졌는지가 인상적이었습니다. 깔끔한 “잠시 멈춥니다” 메시지가 영원히 도는 스피너보다 훨씬 낫습니다.

모니터링과 알림

장님처럼 화재를 진압하는 건 싫습니다. DeepSeek v4 캐시 같은 것에서 유용한 신호는 작고 단순합니다.

관찰하는 항목들:

캐시 히트율. 유형별로 분리합니다. 프롬프트 스캐폴드, 검색된 컨텍스트, 전체 응답 재사용. 워크플로에서 전체 응답 히트가 ~25% 이상 올라가면 TTL을 재확인합니다. 과도하게 캐시하여 새 컨텍스트를 놓치고 있을 수 있습니다.
실효 TPM/RPM. 공급자의 숫자만이 아니라 큐잉 후 실제로 통과되는 것을 봅니다. 입력이 증가하는 동안 실효 RPM이 평탄하게 유지된다면 큐가 제 역할을 하는 것입니다.
재시도 분포. 첫 번째 시도 대 두 번째/세 번째 시도에서 성공하는 호출 수. 나중 재시도로 이동하는 경향이 있다면 어딘가에서 압력이 쌓이고 있다는 뜻입니다.
레이턴시 밴드. P50은 행복한 경로를 알려주고, P95는 나쁜 날 사용자가 느끼는 것을 알려줍니다. P95에 대해 알림을 설정합니다.
오류 분류. 429 대 5xx 대 타임아웃. 각각 다른 레버로 해결합니다.

과하게 울리지 않는 알림:

P95 레이턴시가 5분 동안 2배 상승. 지속될 경우에만 알림을 받습니다.
10분 동안 429 비율이 5% 이상. 동시성을 한 단계 자동으로 낮추고 큐 대기 시간을 늘립니다. 발생했음을 알려줍니다.
서킷이 3분 이상 열려 있음. 실제 인시던트입니다. 공급자 상태를 확인하고 리전 전환 또는 배치 작업 중단 여부를 결정합니다. 공식 문서에 대해 한마디: v4 문서가 나오면 서버 측 컨텍스트 캐싱, 캐시 키, 재사용 토큰 등을 찾아볼 것입니다. 일부 공급자는 공유 프리필 세그먼트에 첨부할 수 있는 cache_id를 제공합니다(예: 긴 시스템 프롬프트). DeepSeek이 유사한 것을 제공한다면, 클라이언트 키를 해당 형식에 맞추고 그들이 공개하는 TTL이나 무효화 규칙을 따를 것입니다. 그때까지는 캐시를 권고적인 것으로 취급합니다. 히트하면 도움이 되고, 미스하면 무해합니다.

이 설정이 유용한 사람:

반복 가능한 프롬프트와 느리게 변하는 컨텍스트를 가진 사람(문서, 헬프 센터, 지식 베이스). 캐시가 빛을 발합니다.
야간에 작업을 배치 처리하는 팀. 큐와 서킷 브레이커가 예상치 못한 상황을 줄입니다.
불안정성에 지친 모든 분. 더 빠르지 않지만, 더 차분합니다.

건너뛰어도 되는 사람:

신선함이 재사용보다 중요한 매우 동적인 사용자별 채팅. 스캐폴드는 캐시하되, 전체 응답은 캐시하지 않습니다.
트래픽이 매우 적은 프로젝트. 하루에 몇 번만 호출한다면 오버헤드가 그만한 가치가 없습니다.

메커니즘을 자세히 파고들고 싶다면, 레이트 리밋과 컨텍스트 캐싱 또는 재사용에 대한 공급자 문서부터 시작하는 것을 권장합니다. DeepSeek이 v4 세부 정보를 공개하면 그에 맞게 설정을 업데이트하고 문서를 직접 연결하겠습니다. 지금은 이 시스템이 잘 작동하고 있습니다. 낭비되는 호출이 줄고, 백프레셔가 명확해지고, 언제 멈춰야 할지 아는 것처럼 느껴지는 UI가 생겼습니다.

화면 옆에 작은 메모를 붙여두었습니다. “큐와 싸우지 마라.” 깊은 말은 아니지만, 바쁜 날에는 닫혀가는 창문 사이로 요청 하나를 더 통과시키려는 충동을 막기에 충분합니다.

자주 묻는 질문

서킷 브레이커는 DeepSeek v4 캐시의 신뢰성을 어떻게 향상시키나요?

서킷 브레이커는 오류율이 급등하거나 P95 레이턴시가 급증할 때 열려서 일시적으로 호출을 단락시킵니다. 열려 있는 동안 캐시된 응답을 제공하거나, 기능을 저하시키거나(더 작은 컨텍스트), 우아하게 일시 중지합니다. 냉각 기간 후 소량으로 반열림 상태가 되어 회복을 테스트합니다. 이렇게 하면 재시도가 중단을 증폭시키는 것을 방지하고 UI가 차분해집니다.

DeepSeek v4는 서버 측 컨텍스트 캐싱이나 캐시 키를 제공하나요?

2026년 초 기준으로 DeepSeek v4의 공개 세부 정보는 제한적입니다. 일부 공급자는 cache_id나 재사용 가능한 프리필 세그먼트를 지원합니다. 클라이언트 측에서 안정적인 시스템 프롬프트와 도구를 해싱하여 미리 준비하세요. DeepSeek이 나중에 서버 측 캐시 키를 제공한다면, 해시를 맞추고 그들이 공개하는 TTL/무효화 규칙을 따르세요.

LLM 캐싱에는 어떤 TTL과 무효화 규칙을 사용해야 하나요?

헬스 체크나 템플릿의 전체 응답 재사용에는 짧은 TTL(5~~30분)을 사용하고, 콘텐츠 지문에 연결된 안정적인 스캐폴드와 검색된 컨텍스트에는 더 긴 TTL(시간~~일)을 사용하세요. 소스 업데이트, 모델/버전 변경, 또는 프롬프트 스키마 편집 시 무효화합니다. 히트율을 추적하세요. 전체 응답 히트가 25% 이상이면 과도한 캐싱을 나타낼 수 있습니다.