4.5토큰과 지연시간, 비용 최적화

"비용이 많이 든다"는 진술로는 아무것도 할 수 없습니다. 최적화는 분해에서 시작합니다.

요청 하나의 비용은 대략 이렇게 갈라집니다.

• 입력 토큰 — 시스템 프롬프트, 도구 정의, 대화 이력, 검색된 근거, 사용자 입력
• 출력 토큰 — 모델이 생성한 응답. 일반적으로 입력보다 단가가 높습니다.
• 호출 횟수 — 에이전트 루프의 반복, 재시도, 다단계 파이프라인의 단계 수

지연시간도 마찬가지로 갈라집니다.

• 첫 토큰까지의 시간 — 입력 길이와 캐시 적중 여부에 크게 좌우됩니다.
• 생성 시간 — 출력 토큰 수에 비례합니다.
• 주변 대기 — 검색, 도구 실행, 외부 API 호출

분해하면 어디를 손대야 하는지가 대개 자명해집니다. 에이전트 시스템에서 비용이 크다면 원인은 보통 호출 횟수이지 프롬프트 몇 글자가 아닙니다. 반대로 단발 요청형 서비스에서 비용이 크다면 매 요청 반복되는 고정 접두부가 범인인 경우가 많습니다.

# 최적화 전에 먼저 잰다. usage를 요청마다 누적한다.
totals = {"input": 0, "output": 0, "cache_read": 0, "calls": 0}

def record(usage):
    totals["input"] += usage.input_tokens
    totals["output"] += usage.output_tokens
    totals["cache_read"] += getattr(usage, "cache_read_input_tokens", 0)
    totals["calls"] += 1

측정 없이 하는 최적화는 대개 체감되지 않는 곳을 줄이고 끝납니다. 시험에서도 "가장 먼저 할 일"을 묻는 문항의 정답은 자주 측정과 분해입니다.

프롬프트 캐싱은 반복되는 접두부(prefix) 를 재사용해 입력 처리 비용과 첫 토큰까지의 시간을 함께 줄입니다. 다만 조건이 있고, 그 조건을 아는지가 프로 시험의 단골 주제입니다.

캐싱이 효과를 내려면 다음이 성립해야 합니다.

• 접두부가 바이트 단위로 동일해야 합니다. 앞부분이 조금이라도 다르면 그 지점부터는 캐시가 적용되지 않습니다.
• 변하지 않는 내용이 앞에, 변하는 내용이 뒤에 배치되어야 합니다. 순서가 반대면 재사용할 접두부가 존재하지 않습니다.
• 재사용이 실제로 일어나야 합니다. 캐시 기록에는 비용이 더 들기 때문에, 한 번만 쓰이고 마는 내용을 캐싱하면 오히려 손해입니다.

가장 흔한 실수는 요청마다 달라지는 값을 시스템 프롬프트 앞쪽에 넣는 것입니다. 타임스탬프, 사용자 이름, 세션 ID 같은 것이 앞에 있으면 캐시는 사실상 무용지물이 됩니다.

# 나쁜 배치: 요청마다 달라지는 값이 앞에 있어 접두부가 매번 깨진다
system = f"현재 시각: {now}\n사용자: {user_name}\n\n{policy_document}"

# 좋은 배치: 고정 내용이 앞, 가변 내용이 뒤
system = f"{policy_document}\n\n현재 시각: {now}\n사용자: {user_name}"

도구 정의도 접두부의 일부입니다. 도구 목록이 요청마다 바뀌면 캐시가 깨지므로, 도구 구성을 요청별로 동적으로 바꾸는 설계는 캐싱과 상충합니다. 캐시 적중 여부는 응답의 사용량 정보에서 확인할 수 있으므로, 적용했다고 믿지 말고 적중률을 지표로 관리해야 합니다.

캐싱 다음으로 큰 지렛대는 세 가지입니다.

모델 등급 조정. 모든 단계에 최상위 모델을 쓸 필요는 없습니다. 분류나 라우팅처럼 판단이 단순한 단계는 작은 모델로 내리고, 최종 생성처럼 품질이 결정적인 단계만 상위 모델을 씁니다. 단, 등급을 내리면 정확도가 어떻게 변하는지 평가 데이터셋으로 먼저 확인해야 합니다. 확인 없이 내리는 것은 비용을 품질과 맞바꾸면서 그 환율을 모르는 상태입니다.

배치 처리. 즉시 응답이 필요 없는 작업은 배치로 돌리면 상당한 비용 절감이 가능합니다. 평가 실행, 대량 분류, 야간 요약 생성이 전형적인 대상입니다. 반대로 사용자가 화면 앞에서 기다리는 경로에는 쓸 수 없습니다. 배치는 지연시간을 비용과 맞바꾸는 수단입니다.

출력 길이 관리. 출력 토큰은 대체로 입력보다 비싸고 생성 시간에 직접 비례합니다. 필요 이상으로 장황한 응답을 요구하고 있지 않은지 확인하고, 구조화된 출력으로 필요한 필드만 받으면 길이와 파싱 문제를 동시에 줄일 수 있습니다.

스트리밍은 총비용이나 총 생성 시간을 줄이지 않습니다. 체감 지연을 줄이는 수단입니다. 시험에서 "스트리밍을 켜면 비용이 준다"는 선택지가 오답으로 나옵니다. 다만 사용자가 첫 글자를 빨리 보는 것 자체가 요구사항이라면 정당한 선택입니다.

손대는 순서에도 원칙이 있습니다. 위험이 낮고 효과가 큰 것부터입니다.

1. 측정과 분해 — 어디에 몫이 쏠려 있는지 먼저 확인한다.
2. 품질에 영향 없는 조치 — 캐싱 적용, 접두부 재배치, 불필요한 재시도 제거, 즉시성이 없는 작업의 배치 전환.
3. 구조 변경 — 단계 수 축소, 검색 결과 개수 조정, 도구 정의 정리.
4. 품질과 맞바꾸는 조치 — 모델 등급 하향, 컨텍스트 축소.

4번은 반드시 평가와 함께 갑니다. 비용은 즉시 눈에 보이지만 품질 하락은 서서히 드러나므로, 평가 없이 등급을 내리면 몇 주 뒤에 원인을 알 수 없는 품질 문제로 돌아옵니다.

회귀 방지 장치도 함께 만듭니다.

• 비용 지표를 평가 파이프라인에 포함 — 정확도와 함께 요청당 토큰과 캐시 적중률을 기록합니다.
• 가드레일 임계 — 요청당 토큰이 어느 선을 넘으면 경보가 울리게 합니다.
• 변경 단위 분리 — 최적화 변경을 품질 변경과 같은 배포에 섞지 않습니다. 섞으면 어느 쪽 때문에 지표가 움직였는지 알 수 없습니다.

비용 최적화의 성공 기준은 비용이 줄었다가 아니라, 품질을 유지한 채 비용이 줄었다입니다. 두 지표를 함께 보고하지 않는 최적화 보고서는 절반만 말하고 있는 것입니다.