캐시 할인에는 바닥이 있다

우리 추출 파이프라인 중 하나는 같은 시스템 프롬프트를 세 언어로 돌린다. 6월에 언어별 비용 리포트가 갑자기 말이 안 되기 시작했다. 같은 내용을 같은 모델에 보내는데 한국어와 베트남어 호출이 영어 호출의 10분의 1 수준으로 찍혔다. 고장 난 곳은 없었다. 영어만 캐시가 안 걸렸고 나머지 둘은 걸렸다.

아무도 안 읽는 조항

프리픽스 캐시에는 관문이 있다. 프리픽스가 최소 토큰 수를 넘겨야만 캐시 요금이 적용되고, 그 바닥 아래에서는 똑같은 바이트를 몇 번을 보내든 할인이 영영 없다. 이 바닥값은 공개돼 있고, 셋 다 토큰 수로 매겨져 있다.

블록 크기가 조항의 나머지 절반이다. 캐시는 128 토큰짜리 블록 단위로만 움직여서, 나머지는 매 호출마다 정가로 다시 청구된다.

eligible = prompt_tokens >= FLOOR          // 1024 on our models
cached   = Math.floor(prompt_tokens / 128) * 128
full     = prompt_tokens - cached + tail   // paid every call, forever

토큰은 언어 중립이 아니다

같은 뜻이라도 언어마다 드는 토큰 수가 다르고, 영어가 거의 항상 가장 싸다. 이 사실은 보통 다른 언어에 불리한 공정성 문제로 인용되고, 프롬프트가 길어진 구간에서는 실제로 그렇다. 그런데 여기에 바닥을 얹으면 부호가 뒤집힌다. 영어는 가장 덜 부푸는 언어니까 바닥에 가장 늦게 도달한다. 내 프롬프트의 번역본은 전부 캐시되는데 원문만 안 되는 프롬프트 길이 구간이 존재한다는 뜻이다.

계산만 믿지 않고 실제 청구로 확인했다. 같은 내용을 번역해서 길이를 늘려가며 보내고, 응답에서 usage.prompt_tokens_details.cached_tokens를 그대로 받아 적었다.

청구된 금액이 아니라 캐시된 토큰 수라서 해석할 여지가 없다. D=24와 D=28에서 표 안의 언어 중 정가를 내는 건 영어뿐이다. 바닥값 자체도 정확했다. 971 토큰짜리 한국어 프리픽스는 캐시가 안 걸리고, 같은 프리픽스가 1,157 토큰이 되면 걸린다. 그리고 캐시된 칸은 전부 floor(p / 128) * 128과 오차 없이 일치했다. 블록 규칙이 대충 반올림하는 추정치가 아니라 청구 그 자체라는 얘기다.

그날 오후에 바꾼 것

• 캐시 적중률을 언어별로 쪼갰다. 그 전까지 합산 수치는 계속 건강해 보였다. 세 언어 중 둘이 끌어올리고 있었으니까. 언어를 평균 내면 그 평균이 잡아내야 할 바로 그 실패가 가려진다.
• 프로덕션 프롬프트마다 길이를 바닥값과 함께 기록한다. 길이만이 아니라 바닥까지 남은 거리를 부호까지 붙여서 남긴다.
• 영어 프롬프트가 바닥 아래면 경보를 올린다. 우리가 고쳐본 것 중 제일 싸게 먹힌 버그였고, 청구서로는 절대 안 보였다. 청구서는 총액이 늘었다는 말만 한다.

뻔한 해법은 짧은 프롬프트를 바닥 넘을 때까지 채워 넣는 것이다. 편법 같았고, 편법은 보통 대가를 치른다. 그래서 배포하기 전에 그 대가가 얼마인지 재봤다. 다음 노트가 그 얘기다.