LLM 토큰 비용 줄이기 — 프롬프트 캐싱과 모델 라우팅

LLM 서비스를 실제로 운영하기 시작하면, 프로토타입 때는 안 보이던 숫자 하나가 눈에 들어온다 — 토큰 비용이다. 데모에선 몇 푼이던 게, 사용자가 늘고 프롬프트가 길어지면 매달 무시 못 할 청구서로 돌아온다. 그래서 요즘 실무의 관심사 중 하나가 "품질을 지키면서 토큰 비용을 어떻게 줄이느냐"다.

비용의 정체를 먼저 봐야 한다. LLM 과금은 대개 입력 토큰과 출력 토큰으로 나뉜다. 그런데 많은 서비스에서 진짜 비용을 잡아먹는 건 출력이 아니라 입력이다. 매 요청마다 긴 시스템 프롬프트, 예시 뭉치, 검색해온 문서, 대화 내역을 통째로 다시 보내기 때문이다. 같은 내용을 수천 번 재전송하고 있는 셈이다.

프롬프트 캐싱 — 가장 큰 지렛대

프롬프트 캐싱은 여러 요청에 공통으로 들어가는 앞부분을 캐시해두고 재사용하는 기능이다. 시스템 프롬프트, 도구 정의, 고정된 예시, 참조 문서처럼 요청마다 똑같이 반복되는 부분 말이다. 이걸 캐시하면 그 부분을 매번 처음부터 처리하지 않아 반복 입력 비용이 크게 줄고, 응답도 빨라진다.

핵심 요령은 변하지 않는 걸 앞에, 변하는 걸 뒤에 두는 것이다. 캐시는 프롬프트의 앞부분(접두)이 동일할 때 효과를 보므로, 고정 콘텐츠를 앞에 모으고 사용자별로 바뀌는 질문은 맨 뒤에 붙인다. 나는 프롬프트 구조를 이렇게 정렬하는 것만으로 반복 요청의 입력 비용을 눈에 띄게 줄였다. 코드를 크게 고치지 않고 순서만 바꿔 얻은 이득이라 가성비가 좋았다.

모델 라우팅 — 값비싼 모델을 아낀다

두 번째 지렛대는 라우팅이다. 모든 요청을 가장 크고 비싼 모델에 보낼 필요가 없다. 들어온 요청을 먼저 분류해서, 쉬운 건 작고 싼 모델로, 어려운 것만 큰 모델로 보낸다. 분류·요약·간단한 응답이 다수를 차지하는 서비스라면, 이 다수를 저렴한 모델로 처리하는 것만으로 전체 비용 구조가 달라진다. 품질이 필요한 소수에만 비싼 모델을 쓰는 것이다.

컨텍스트 다이어트

세 번째는 그냥 덜 보내는 것이다. 관행적으로 붙이던 예시가 정말 다 필요한지, 검색 결과를 열 개씩 넣을 필요가 있는지, 대화 내역을 통째로 보내는 대신 요약으로 대체할 수 있는지 점검한다. 토큰을 줄이면 비용만 아니라 지연도 줄고, 군더더기가 빠져 답이 더 또렷해지기도 한다. 다만 무리하게 줄이면 품질이 깎이므로, 줄이면서 품질을 함께 지켜봐야 한다.

측정 없이 최적화 없다

가장 강조하고 싶은 건 순서다. 줄이기 전에 어디에 쓰는지부터 측정하라. 어떤 기능이, 어떤 요청 유형이 토큰을 얼마나 먹는지 모르면 엉뚱한 데를 최적화한다. 나는 비용의 대부분이 소수의 무거운 요청에서 나온다는 걸 측정하고 나서야, 그 몇 개에만 집중해 큰 효과를 봤다. 감으로 최적화하지 말고, 청구서를 요청 유형별로 쪼개 보는 것에서 시작해야 한다.

자주 묻는 질문

프롬프트 캐싱은 왜 그렇게 효과가 큰가요?

많은 서비스에서 매 요청의 입력 대부분이 시스템 프롬프트·도구 정의·예시처럼 반복되는 고정 콘텐츠이기 때문이다. 이걸 매번 처음부터 처리하는 건 낭비인데, 캐싱은 그 공통 앞부분을 재사용해 반복 처리를 없앤다. 효과를 보려면 고정 콘텐츠를 프롬프트 앞쪽에 모으고, 사용자마다 바뀌는 부분을 뒤로 빼는 구조가 중요하다.

싼 모델을 쓰면 품질이 떨어지지 않나요?

모든 요청에 쓰면 그렇지만, 라우팅의 핵심은 "쉬운 요청에만" 싼 모델을 쓰는 것이다. 분류·요약·간단한 응답 같은 정형 작업은 작은 모델로도 충분한 경우가 많고, 복잡한 추론이 필요한 소수만 큰 모델로 보낸다. 관건은 요청을 어려움에 따라 정확히 분류하는 것이라, 이 분류 단계의 신뢰도를 확보하는 게 중요하다.

어디서부터 손대야 하나요?

측정이 먼저다. 어떤 기능과 요청 유형이 토큰을 얼마나 소비하는지 쪼개 보면, 대개 비용이 소수의 무거운 지점에 몰려 있다. 그다음 큰 지렛대부터 당긴다 — 반복 입력이 많으면 프롬프트 캐싱, 쉬운 요청이 다수면 라우팅, 컨텍스트가 비대하면 압축이다. 감이 아니라 데이터로 우선순위를 정하는 게 핵심이다.