# 프롬프트 캐싱은 언제 코딩 에이전트 비용을 실제로 줄이나요? > 프롬프트 캐싱은 많은 요청이 크고 바이트 단위로 안정된 prefix를 재사용하고 cache read 절감액이 쓰기, miss, 추가 복잡성 비용보다 클 때 비용을 줄입니다. 프롬프트 캐싱은 사람이 보기에 비슷한 프롬프트가 아니라 에이전트가 완전히 같은 큰 시작 부분을 반복 전송할 때 가치가 있습니다. 앞쪽의 timestamp, 재정렬된 도구 목록, 바뀐 workspace summary 또는 생성된 request ID는 이후 모든 재사용을 깨뜨릴 수 있습니다. 프롬프트를 재설계하기 전에 실제 요청의 usage metadata를 살펴보세요. 적격 input token 수, 보고된 cache read 수, prefix 변경 빈도, 선택 모델과 프로토콜의 실제 cache 이점을 확인합니다. ## 캐시 없는 기준 비용을 모델링하세요 캐싱은 output token이나 도구 실행을 줄이지 않으므로 입력 비용부터 계산합니다. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` 단위를 통일하세요. 보통 백만 token당 비용입니다. 기억에 의존한 할인율을 넣지 말고 정확한 모델의 현재 가격과 usage field를 사용합니다. | 구성 요소 | 요청 간 안정적인가요? | 권장 위치 | |---|---|---| | 시스템 정책 | 대개 | 맨 앞 | | 도구 스키마 | 대개 | 앞부분 | | Repository 규칙 | 자주 | 앞부분 | | 작업 checkpoint | 때때로 | 중간 | | 사용자 요청 | 드물게 | 뒤쪽 | | 최신 도구 출력 | 아니요 | 마지막 | ## 기호로 손익분기점을 계산하세요 `P`를 안정된 prefix token, `R`을 총 요청 수, `W`를 cache write 요율, `H`를 cache read 요율, `U`를 일반 입력 요율로 둡니다. ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` 이 이상적 계산은 첫 요청 뒤 모두 hit라고 가정합니다. 측정된 hit 비율 `h`가 있다면 이후 요청 항을 `H`와 `U`의 가중 혼합으로 바꾸세요. Prefix 밖 token은 양쪽에 일반 요율로 더합니다. Miss와 엔지니어링 오버헤드 뒤에도 절감액이 양수일 때만 재정적으로 유효합니다. ## 안정된 콘텐츠를 먼저 배치하세요 안정된 것부터 변동성이 큰 순서로 구성합니다. * 시스템 및 안전 지침. * 결정론적 순서의 도구 정의. * Repository 규칙과 지속적인 참고 텍스트. * 간결한 작업 checkpoint. * 현재 사용자 요청. * 최신 도구 출력. 스키마를 결정론적으로 직렬화하세요. Prefix에 임의 순서, whitespace 변경, timestamp, 요청별 주석을 넣지 마세요. 안정된 bundle은 의도적으로 versioning합니다. ## Prefix를 크기보다 유용성 중심으로 유지하세요 부풀려진 prefix는 cache read 수는 높이지만 총 token을 늘리고 모델을 방해할 수 있습니다. 오래된 도구, 중복 정책, 관련 없는 참고 파일을 제거하세요. Cache hit 비율만 보지 말고 수락된 코드 변경당 비용을 측정하세요. 더 짧은 비캐시 프롬프트가 더 적은 턴으로 문제를 풀면 더 효율적일 수 있습니다. ## 요청과 결과를 계측하세요 모델, 프로토콜, prefix 버전, 전체 input token, 가능한 경우 cached input token, output token, latency, 도구 호출 수, retry, 작업 결과를 기록합니다. 없는 field는 0이 아니라 unavailable로 표시하세요. | 지표 | 중요한 이유 | |---|---| | 캐시 token 비율 | 실제 재사용 발생 확인 | | Miss 이유 | 의도치 않은 prefix 변동 발견 | | 작업당 요청 수 | 절감을 지우는 루프 노출 | | 수락된 변경당 비용 | Token을 유용한 결과와 연결 | | Retry 비율 | 캐싱 밖의 신뢰성 비용 발견 | 대표 작업 일주일치가 합성 프롬프트 하나를 백 번 반복한 결과보다 유용합니다. ## Routing과 세션 경계를 관찰하세요 Cache 동작은 모델, 공급자, 지역, retention window, routing에 따라 달라질 수 있습니다. Gateway나 fallback이 동일한 따뜻한 prefix가 없는 경로로 요청을 옮길 수 있습니다. Atlas Cloud는 하나의 API로 여러 LLM 형식을 제공하지만 보편적인 prompt-cache 할인을 약속하지 않습니다. 현재 모델과 콘솔을 확인하세요. 호환 요청 형식은 [LLM 프로토콜](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)에서, 최신 모델 정보는 [모델 카탈로그](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs)에서 확인할 수 있습니다. ## 거짓 절감을 피하세요 낮은 입력 비용 항목이 추가 턴, 실패한 tool call, 반복적인 context 재구성을 숨길 수 있습니다. Cache read는 애플리케이션 저장소와 retrieval과도 다릅니다. 캐시 가능하다는 이유로 secret을 포함하지 마세요. 캐싱 아키텍처는 접근 제어나 retention 요구사항을 대체하지 않습니다. ## 실용적인 도입 gate를 사용하세요 다음 조건에서 프롬프트 캐싱을 도입합니다. * 안정된 prefix가 의미 있고 자주 재사용됩니다. * 실제 usage가 cache read를 보고합니다. * 관찰된 miss 비율 뒤에도 절감이 남습니다. * Prefix versioning이 단순하고 결정론적입니다. * 작업 품질과 턴 수가 나빠지지 않습니다. 그렇지 않다면 먼저 프롬프트를 줄이고 관련 파일만 가져오며 에이전트 루프를 단축하세요. ## 결론 크고 유용하며 바이트 단위로 안정된 prefix가 더 저렴한 cached input을 보고하는 경로에서 충분히 재사용될 때 프롬프트 캐싱이 코딩 에이전트 비용을 줄입니다. 안정된 자료를 앞에 두고 현재 요율로 손익분기점을 계산하며 수락된 변경당 비용을 측정하세요. 프롬프트가 불필요하게 크거나 더 많은 턴이 필요하다면 높은 hit 비율은 성공이 아닙니다. ## FAQ ### 프롬프트 캐싱에 가장 적합한 콘텐츠는 무엇인가요? 안정된 시스템 지침, 도구 스키마, repository 규칙, 거의 바뀌지 않는 참고 자료가 실시간 로그나 최신 사용자 메시지보다 적합합니다. ### 변동 콘텐츠를 안정된 prefix 뒤에 둬야 하는 이유는 무엇인가요? Prefix cache는 대개 시작 부분의 정확한 일치에 의존합니다. 앞쪽의 timestamp, request ID, 변동 context가 이후 안정된 콘텐츠 전체를 miss로 만들 수 있습니다. ### 프롬프트 캐싱은 항상 latency를 줄이나요? 아닙니다. 효과는 공급자 구현, cache 상태, routing, 모델, 요청 크기, 부하에 따라 달라집니다. latency는 비용과 별도로 측정하세요. ### 손익분기점은 어떻게 계산하나요? 캐시 없는 입력 비용과 예상 재사용 횟수의 cache write 및 read 비용을 비교하고 엔지니어링 비용과 miss 비율을 포함하세요. ### 도구 정의도 캐시할 수 있나요? 공급자와 선택한 프로토콜이 캐싱 대상으로 포함한다면 반복 prefix의 일부가 될 수 있습니다. 가정하지 말고 usage metadata를 확인하세요. ### 전체 코딩 transcript를 캐시해야 하나요? 대개 그렇지 않습니다. Transcript는 매 턴 바뀝니다. 안정된 지침과 스키마를 먼저 두고 간결한 checkpoint와 현재 요청을 뒤에 둡니다.