OpenAI와 Anthropic API를 사용해보신 분들은 알겠지만, 캐시된 입력 토큰은 일반 토큰보다 10배 저렴합니다. Anthropic은 긴 프롬프트의 응답 속도를 최대 85%까지 단축할 수 있다고 주장하죠. 그런데 여기서 의문이 생깁니다. 같은 프롬프트를 보내도 매번 다른 답변이 나오는데, 대체 뭘 캐시하길래 이런 마법이 가능한 걸까요?

네트워킹 플랫폼 ngrok의 개발자 교육 담당자 Sam Rose가 작성한 이 글은 공식 문서가 설명하지 않는 프롬프트 캐싱의 작동 원리를 파헤칩니다. LLM 아키텍처 깊숙이 들어가 정확히 어떤 데이터가 캐시되는지, 그것이 왜 비용과 속도를 개선하는지를 밝혀냅니다.

출처: Prompt caching: 10x cheaper LLM tokens, but how? – ngrok 블로그

답변이 아닌 중간 계산 결과를 저장한다

프롬프트 캐싱은 답변 자체를 저장하는 것이 아닙니다. LLM 내부의 attention 메커니즘에서 생성되는 K(Key)와 V(Value) 행렬을 저장하죠.

LLM은 텍스트를 생성할 때 각 토큰이 서로에게 얼마나 중요한지 계산합니다. “Mary had a little lamb”이라는 문장에서 다음 단어를 예측하려면 “Mary”가 63%, “little”이 9% 같은 식으로 각 단어의 중요도를 가중치로 매깁니다. 이 과정에서 각 토큰의 임베딩(고차원 공간의 좌표)을 특별한 행렬(WK, WV)과 곱해 K와 V를 만들어내는데, 이게 바로 캐싱의 핵심입니다.

문제는 새로운 토큰이 추가될 때마다 전체 프롬프트를 처음부터 다시 처리해야 한다는 점입니다. “Mary had a little”을 처리한 직후 “lamb”을 추가하면, 앞의 네 단어에 대한 계산을 또 반복하죠. 이미 계산한 것인데 말이죠.

캐싱은 바로 이 중복 계산을 제거합니다. 각 토큰의 K와 V 행렬을 저장해두고, 새 토큰이 들어오면 새 토큰의 K와 V만 계산해서 기존 행렬에 붙이기만 하면 됩니다. 마치 레고 블록처럼 이전 계산 결과 위에 새로운 조각만 쌓는 거죠.

OpenAI와 Anthropic의 다른 전략

두 회사의 캐싱 방식은 흥미롭게 다릅니다.

OpenAI는 자동으로 캐싱을 처리합니다. 사용자가 신경 쓸 필요 없이 비슷한 요청을 같은 서버로 라우팅하려 하죠. 저자의 테스트에서는 캐시 적중률이 약 50%였습니다. 편리하지만 긴 프롬프트를 다룰 때 응답 시간이 들쭉날쭉할 수 있습니다.

Anthropic은 개발자에게 제어권을 줍니다. 언제 캐싱할지, 얼마나 유지할지 직접 지정하고, 그에 대한 비용을 지불합니다. 대신 캐시 적중률은 거의 100%에 달했습니다. 예측 가능한 지연시간이 중요한 프로덕션 환경에서는 Anthropic 방식이 더 적합할 수 있습니다.

알아두면 좋은 것들

캐싱된 프롬프트는 보통 5-10분간 유지됩니다. 같은 프롬프트로 시작하는 새 요청이 들어오면 일치하는 부분까지의 K, V 행렬을 재사용하고, 새로운 부분만 계산합니다. 부분 일치도 가능하다는 점이 실용적이죠.

흥미로운 건 temperature나 top_p 같은 랜덤성 파라미터를 바꿔도 캐시가 무효화되지 않는다는 점입니다. 이런 파라미터들은 attention 메커니즘 이후에 작동하기 때문에 K, V 행렬 계산에는 영향을 주지 않습니다.

프롬프트 캐싱은 긴 컨텍스트를 반복적으로 사용하는 애플리케이션—문서 분석, 코드베이스 검토, 대화형 에이전트—에서 특히 강력합니다. 비용을 10분의 1로 줄이면서 응답 속도까지 빨라지니까요.

참고자료:

• Build a Large Language Model (From Scratch) – Sebastian Raschka
• Transformer Explainer – Aeree Cho et al.