에이전트가 같은 지침과 도구 정의를 반복 전송합니다. 프롬프트 캐시를 쓰면 비용·지연·정확성은 어떻게 달라지나요?

프롬프트 캐시는 반복되는 입력 부분의 처리를 재사용해 비용과 지연을 줄이는 기능이며, 최종 답변을 그대로 재사용하는 응답 캐시와는 다릅니다. 보통 안정적인 지침·도구 정의·자료 접두부가 재사용 후보지만 실제 적중 조건·최소 길이·수명·가격은 제공자와 API에 따라 확인해야 합니다. 캐시가 적중했다고 새 질문의 결과가 정확하거나 결정적이 되는 것은 아닙니다.

안정적인 부분과 동적인 부분

매 요청 바뀌는 시간·사용자 ID·검색 결과를 긴 공통 지침 앞에 넣으면 공통 접두부가 달라져 적중을 방해할 수 있습니다. 지침과 안정적인 도구 정의를 먼저 두고 요청별 데이터를 뒤에 배치하는 방식을 검토하되, API가 요구하는 캐시 구간과 실제 사용량 메트릭을 확인합니다. 도구 목록 순서가 매번 달라지는 것도 영향을 줄 수 있으므로 의미가 같다면 결정적인 순서를 유지합니다.

캐시 비용에는 저장·작성·재사용·만료 후 재처리 조건이 있을 수 있습니다. 반복 빈도가 낮거나 공통 입력이 짧으면 관리 비용이 이득보다 클 수 있습니다. 적중률뿐 아니라 총 입력량·실제 청구·응답 시간과 캐시 miss의 지연을 측정하겠습니다. 제공자별 구현을 하나의 TTL이나 할인율로 일반화하지 않습니다.

최신성과 기밀성

프롬프트 캐시는 모델 입력 처리의 재사용이며 애플리케이션이 낡은 정책을 계속 보내는 문제를 자동 해결하지 않습니다. 규정·도구 스키마·사용자 권한이 바뀌면 최신 버전의 입력을 구성해야 합니다. 사용자별 비공개 자료와 자격 증명을 공통 캐시 설계에 무심코 포함하지 않고 제공자의 격리·보존 계약과 조직 정책을 확인합니다. 캐시 식별자 자체를 접근권한으로 취급하지 않습니다.

응답 캐시는 별도 문제입니다. 같은 질문 문자열이라도 사용자·문서 권한·데이터 버전·작업 상태가 다르면 같은 답을 재사용할 수 없습니다. 특히 에이전트의 행동 결과를 캐시해 '예약 완료'를 돌려주면 실제 현재 상태와 어긋날 수 있습니다. 프롬프트 처리 절약과 실행 결과 재사용의 경계를 분명히 합니다. 시험은 입력 순서·정의 변경·만료·권한 철회·사용자 전환을 포함하고 품질 검증을 유지한 채 비용을 비교하겠습니다.

실행 사례로 확인합니다

캐시를 위해 프롬프트를 정렬하다 지시의 우선순위나 자료의 신뢰 표시를 바꾸면 의미가 달라질 수 있습니다. 안정적인 접두부는 같은 정책을 재사용하는 범위에서 만들고, 사용자별 예외와 권한은 누락하지 않습니다. 도구 정의를 캐시한 뒤 서버가 삭제되거나 권한을 철회하면 실제 실행기는 현재 상태를 다시 검사해야 합니다. 캐시가 오래된 설명을 모델에 보여 주더라도 금지된 행동을 허용하는 근거가 될 수 없습니다. 관측에서는 캐시 read·write 토큰과 일반 입력 토큰, 실제 청구를 구분하고, 동일 과제에서 cold·warm 조건을 따로 측정합니다. 평균 적중률이 높아도 드문 큰 miss가 p99를 지배할 수 있습니다.