Datadog LLM 프롬프트 캐시 미스 추적과 비용 절감 방법

비용을 요청 단위로 따라간 과정

Datadog은 먼저 Cloud Cost Management에서 제공사 지출을 확인했어요. 그다음 Agent Observability로 특정 애플리케이션과 모델에 닿는 API 경로를 들여다봤습니다. 에이전트는 작업 하나를 끝내려고 모델을 여러 번 호출하기 때문에 첫 호출과 같은 작업의 이후 호출을 비교했어요.

본 것은 요청별 토큰 수, 추정 비용, 모델이 응답을 시작하기까지 걸린 시간이에요. 캐시 쓰기는 캐시를 채우는 데 쓰인 입력이고 캐시 읽기는 캐시에서 가져온 입력입니다. 캐시 적중이 하나도 기록되지 않은 사례는 요청마다 입력 토큰이 18만 개를 넘었고 입력 비용 추정치가 요청당 $0.74-$0.82였어요. 캐시가 작동한 사례는 총비용 추정치가 요청당 $0.02-$0.14였고, 캐시가 없던 사례는 총 $0.74-$0.86이었습니다.

결론을 내리기 전에 트레이스 자체도 검증했어요. 애플리케이션과 게이트웨이가 같은 모델 호출을 각각 기록하면 비용이 두 번 잡히고, 캐시 필드가 빠진 기록은 캐시가 안 쓰인 것처럼 보이게 만듭니다. 그래서 기록된 사용량을 제공사 응답과 대조하고 요청 내용이 온전한지 확인했어요. 일부 기록은 시스템 지시문이나 도구가 빠져 있어서 왜 재사용이 안 됐는지 설명할 수 없었다고 해요.

캐시 미스를 만든 원인 네 가지

프롬프트 캐시는 요청의 앞부분(prefix)이 이전에 처리한 입력과 일치해야 작동해요. 앞쪽에서 값이 달라지면 뒤따르는 동일한 내용까지 재사용되지 못합니다. Datadog이 코드에서 찾은 원인은 이렇습니다.

• 변하는 값이 앞에 섞인 지시문: 한 채팅 서비스는 시스템 지시문에 현재 시각, 조직 정보, 기능 플래그, 인시던트 맥락을 합쳤어요. 시각이 10:00에서 10:05로 바뀌면 그 뒤의 지시문이 같아도 제공사가 재사용하지 못합니다. 제안한 수정은 고정된 지시문을 앞에 두고 요청별 세부 정보를 뒤에 두는 것이고, 지원되는 곳에서는 캐시 경계로 재사용 구간의 끝을 표시하는 방식이에요.
• Go 맵 순회로 뒤섞이는 도구 순서: 도구 목록을 맵 순회로 만들면 순서가 보장되지 않아 A, B, C로 보냈다가 B, A, C로 보낼 수 있어요. 도구 설명이 캐시 prefix에 들어가므로 순서가 바뀌면 재사용이 막힙니다. 패치는 도구 이름을 정렬한 뒤 목록을 만들게 했고, 테스트는 같은 도구를 다른 순서로 맵에 넣어도 결과 목록이 같은지 확인해요. 소스 코드로 프롬프트를 만드는 서비스도 파일을 맵에서 나열하다 같은 문제가 있어서 파일 경로를 정렬했습니다.
• 켰지만 전달되지 않은 캐시 옵션: 한 채팅 서비스는 WithPromptCaching 옵션을 켰는데도 Anthropic 요청에서 캐시 활동이 없었어요. 옵션이 beta 헤더만 추가하고, 제공사에 무엇을 캐시할지 알려주는 요청 본문의 제어값은 빠뜨렸기 때문입니다. 다른 애플리케이션은 SDK의 캐시 옵션을 제공사 요청을 만드는 컴포넌트에 넘기지 않았어요.
• 캐시를 지원하지 않는 호환 엔드포인트: 게이트웨이는 Anthropic 네이티브 Messages API나, OpenAI API 형식을 받는 호환 엔드포인트로 요청을 보낼 수 있어요. 네이티브 경로에서는 캐시 읽기가 관측됐고 호환 경로에서는 캐시 활동이 없었으며, Anthropic 문서로 호환 경로가 프롬프트 캐싱을 지원하지 않는다는 것을 확인했어요.

미스의 원인으로 지목하기 전에 값이 얼마나 자주 바뀌는지도 따졌어요. 어떤 시스템 프롬프트에 들어간 UTC 날짜는 날짜가 바뀌는 시점의 미스는 설명하지만 하루 종일 반복되는 미스는 설명하지 못합니다. 앞쪽 타임스탬프처럼 보인 값이 기록된 사용자 콘텐츠에서 온 경우도 있었는데, 이때는 시스템 지시문을 고쳐도 해결되지 않아요.

고친 뒤 효과를 확인하는 체크리스트

수정 후보는 도구 정렬, 지시문과 변하는 맥락의 분리, 캐시 제어값의 제공사 전달이에요. 요청이 성공했는지만 봐서는 안 됩니다. 답변은 계속 정상이어도 재사용될 수 있었던 입력을 매번 새로 처리하며 비용을 내고 있을 수 있어요. 전후 비교는 같은 애플리케이션 경로와 같은 작업 유형으로 하고, 다음을 확인합니다.

• 에이전트가 도구를 호출한 뒤에도 이후 요청이 앞선 요청이 캐시한 입력을 읽었는지
• 출력 토큰, 재시도, 폴백 모델 호출까지 포함해 작업 하나의 비용이 줄었는지
• 모델의 응답 시작 시간과 작업 전체 소요 시간
• 답변 정확도와 도구 사용 성공 여부

호환 경로에서 네이티브 API로 옮기는 것도 후보지만 먼저 확인할 게 있어요. 메시지 역할과 내용이 올바른지, 도구 호출과 결과 수신이 정상인지, 응답 스트리밍이 기대대로 되는지입니다. 경로 비교는 조사할 기회를 알려줄 뿐 얼마를 아낄 수 있는지는 알려주지 않아요. 일부 제공사는 캐시 쓰기에 추가 요금을 받아서, 거의 재사용되지 않는 내용을 계속 쓰면 오히려 비용이 늘 수 있습니다. 대화 기록을 길게 유지하면 캐시되는 비율이 올라가도 전송하는 입력량 자체가 늘어요.

토큰 집계와 쿼리에서 주의할 점

제공사마다 캐시된 입력을 보고하는 방식이 달라서 각 토큰 수에 무엇이 포함되는지 확인했어요. Agent Observability의 정규화된 입력 토큰 합계에는 캐시 읽기와 쓰기가 이미 들어 있습니다. 이 항목을 다시 더하면 같은 입력이 두 번 잡혀 추정 비용이 틀어져요.

DDSQL은 모델 호출을 애플리케이션, 제공사, 모델, 시간 구간별로 묶어 변경 후 비교를 반복하는 데 쓸 수 있어요. 다만 어떤 레코드가 측정하려는 제공사 호출인지는 직접 가려내야 합니다.

자주 묻는 질문

캐시 옵션을 켰는데 비용이 안 줄어드는 이유가 뭔가요

옵션이 켜져 있어도 제공사가 필요로 하는 제어값이 요청 본문에 빠지면 캐시가 작동하지 않아요. Datadog 사례에서는 옵션이 beta 헤더만 붙이고 무엇을 캐시할지 알려주는 본문 제어값을 빠뜨렸습니다. 다른 애플리케이션은 SDK의 캐시 옵션을 요청을 만드는 컴포넌트에 넘기지 않았어요.

프롬프트 캐시 효과는 어떻게 검증하나요

같은 애플리케이션 경로와 작업 유형을 전후로 비교하세요. 이후 요청이 캐시된 입력을 읽는지, 작업 단위 비용이 줄었는지, 응답 지연시간과 정확도가 유지되는지를 봅니다.