에이전트 시스템이 캐시 히트 가격 책정(Cache-hit pricing)에 주목해야 하는 이유
요약
에이전트 시스템 운영 시 발생하는 반복적인 컨텍스트 비용을 줄이기 위해 캐시 히트 가격 책정(Cache-hit pricing)의 중요성을 설명합니다. 단순 모델 비용 절감보다 캐시 활용을 통한 '반복세' 감소가 비용 최적화의 핵심임을 강조합니다.
핵심 포인트
- 멀티 스텝 에이전트의 비용은 모델 가격보다 반복되는 컨텍스트 비용에 의해 결정됨
- 캐시 읽기(cached-read) 요율을 활용하면 전체 입력 비용 대비 70% 이상 절감 가능
- 캐시 히트/미스 여부를 추적할 수 있는 관찰 가능성(Observability) 확보가 필수적
- 동일한 시스템 프롬프트와 접두사를 유지하여 캐시 친화성(Cache affinity)을 높여야 함
당신의 에이전트 비용을 조용히 결정하는 지표는 모델의 입력 가격(input price)이 아닙니다. 그것은 이미 보냈던 내용을 다시 읽는 데 얼마를 지불하느냐입니다.
만약 멀티 스텝 에이전트(multi-step agents)를 운영하고 있다면, 아마 이런 순간을 경험했을 것입니다: 단 몇 푼이면 될 것이라고 예상했던 작업이 청구서에서 작은 놀라움으로 돌아오는 순간 말이죠. 모델을 바꾸지도 않았고, 프롬프트를 더 많이 넣지도 않았습니다. 그렇다면 토큰은 어디로 간 걸까요?
대부분의 경우, 동일한 컨텍스트(context)에 대해 반복해서 비용을 지불하는 데 사용되었습니다.
2분짜리 작업이 40개 이상의 과금 대상 호출을 발생시킬 수 있습니다
제가 계속해서 보고 있는 형태가 하나 있습니다. 에이전트가
핵심은 '이 모델이 더 저렴하다'가 아닙니다. 핵심은 다음과 같습니다: 컨텍스트를 재전송하는 모든 루프(loop)에서 캐시 읽기 가격(cached-read price)이 실제 한계 비용(marginal cost)이며, 대부분의 팀들이 잘못된 수치에 최적화하고 있다는 것입니다.
청구서에 실제로 영향을 미치는 수학적 원리
정확한 수치를 따지기보다는 그 형태를 보세요. 만약 루프가 40번 호출되고, 각 호출마다 ~4k 토큰의 반복되는 컨텍스트와 ~200 토큰의 새로운 콘텐츠를 포함한다고 가정해 봅시다.
- 반복되는 모든 토큰에 대해 전체 입력(full input) 비용을 지불할 경우: 실제로 이전 내용이었던 160k 토큰에 대해 4k × 40 = 160k 만큼 '새로운' 토큰으로 청구됩니다.
- 반복되는 접두사(prefix)에 대해 캐시 읽기(cached-read) 비용을 지불할 경우: 그 160k는 분수로 줄어들며, 전체 입력 대신 캐시 읽기 요율이 적용됩니다.
위 두 모델에서 캐시 읽기는 1M당 ¤10–¤20 수준에 머무르는 반면, 전체 입력은 몇 배 더 높습니다. 루프의 비용이 0으로 떨어지지는 않지만, '반복세(repeat tax)'가 급격히 감소합니다. 에이전트 시스템에서 이 반복세가 청구서의 대부분을 차지하므로, 실제 70% 이상의 절감 효과는 단순히 '더 저렴한 모델 선택'에 있는 것이 아니라 바로 여기에 있습니다.
볼 수 없는 것은 최적화할 수 없다
여기에는 함정이 있습니다. 캐시 히트 가격 책정(Cache-hit pricing)은 히트(hits)와 미스(misses)를 모두 확인할 수 있을 때만 도움이 됩니다. 단순히 텍스트만 반환하는 블랙박스 API는 필요한 단 하나의 수치, 즉 이 토큰이 캐시 히트였는지 아니면 새로 청구된 것인지를 숨깁니다.
요청 추적(request trace)을 사용하면 이를 관찰 가능하게 만들 수 있습니다. 모든 호출은 다음 단계들을 노출해야 합니다:
- REQUEST — 입력된 내용
- AUTH — 누가/무엇이 호출했는지
- ROUTE — 어떤 모델이 서비스했는지
- RESPONSE — 반환된 내용
- METER — 캐시 히트/미스를 포함하여 비용이 얼마였는지
모든 호출에서 캐시 히트/미스와 단계별 비용을 확인할 수 있게 되면, 루프는 더 이상 미스터리가 아닙니다. 어떤 단계가 예산을 초과하는지, 그리고 접두사가 실제로 따뜻하게 유지되고 있는지를 볼 수 있습니다.
라우팅 + 캐시 친화성(cache affinity)이 진정한 레버리지다
캐시 히트 가격 책정은 필요하지만 충분하지 않습니다. 나머지 절반은 **캐시를 따뜻하게 유지하는 것(keeping the cache warm)**이며, 이는 라우팅 문제입니다.
80/20 패턴은 여전히 유효합니다. 쉬운 80%의 호출은 소규모/빠른 모델로 라우팅하고, 최전선(frontier)을 어려운 20%에 남겨두세요. 하지만 사람들이 간과하는 부분은 _캐시 친화성(cache affinity)_입니다. 루프 전체에서 동일한 시스템 프롬프트와 안정적인 접두사(stable prefix)를 유지하면 캐시가 따뜻하게 유지되고 저렴한 읽기 작업이 계속 히트됩니다. 매 단계마다 접두사를 변경하면(히스토리 재형식화, 시스템 프롬프트 재작성, 순서 섞기 등) 스스로 캐시를 무효화(evict)시키는 결과를 초래합니다. 그러면 영원히 전체 입력에 대한 비용을 지불하게 됩니다.
하나의 OpenAI 호환 엔드포인트 뒤에서 `model:
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기