지난 글의 비교표에서 정확도 옆에 비용과 지연을 나란히 두라고 했는데, 그 두 숫자가 추론 모델에서 어떻게 만들어지는지를 제대로 알아야 표를 채울 수 있다. 일반 모델의 감으로 예측하면 대체로 크게 빗나간다. 사고 토큰은 입력도 출력도 아닌 제3의 항목처럼 굴고, 그 양이 요청마다 다르며, 사용자에게는 아무것도 보이지 않는 침묵으로 나타나기 때문이다.
요청 하나의 단가
일반 모델의 요청 단가는 단순하다. 입력 토큰과 출력 토큰에 각각 단가를 곱해 더한다. 추론 모델에서는 여기에 항이 하나 붙는다.
사고 토큰 $n_{\text{think}}$는 출력 단가로 계산된다. 그리고 대개 이 항이 나머지를 압도한다. 답변이 300토큰인데 사고가 3,000토큰이면 출력 비용의 90%가 사용자가 볼 수 없는 부분에서 나온다.
문제는 $n_{\text{think}}$가 요청마다 다르다는 것이다. 예산을 4,000으로 잡아도 쉬운 요청에서는 400에서 끝나고 어려운 요청에서는 예산을 다 쓴다. 그래서 평균으로 예산을 세우면 반드시 틀린다. 분포를 봐야 한다.
실무에서 유용한 형태는 이렇다. 요청 유형별로 사고 토큰의 중앙값과 p95를 각각 기록해 둔다. 월 비용 추정은 중앙값으로 하고, 예산 상한과 타임아웃은 p95로 잡는다. 이 둘을 같은 숫자로 쓰면 어느 한쪽이 반드시 어긋난다.
지연은 어디서 늘어나는가
비용보다 체감이 큰 쪽이 지연이다.
프리필과 답변 생성은 일반 모델과 같다. 통째로 추가되는 것이 사고 구간이고, 이 구간은 대개 전체 지연의 절반을 훌쩍 넘는다. 위 예시에서는 74%다.
여기서 진짜 문제는 총 지연이 아니라 **첫 답변 토큰까지의 시간(TTFT)**이다. 일반 모델은 0.4초쯤에 첫 글자가 나오기 시작해서 사용자가 읽으면서 기다린다. 추론 모델은 사고가 끝날 때까지 아무것도 안 나온다. 7초 동안 화면이 비어 있는 것과, 7초 동안 글이 흘러나오는 것은 완전히 다른 경험이다.
스트리밍을 켠다고 해결되지 않는다. 사고 구간은 스트리밍할 것이 없거나, 있어도 사용자에게 보여 주기 부적절한 경우가 많다.
침묵 구간을 다루는 세 가지
첫째, 사고 중임을 명시적으로 보여 준다. "생각하는 중"이라는 상태 표시와 경과 시간이면 충분하다. 아무 피드백 없는 7초는 장애로 읽히고, 표시가 있는 7초는 기다림으로 읽힌다.
둘째, 사고 요약을 흘려보낸다. 제공자에 따라 사고 구간의 요약본을 스트리밍으로 받을 수 있다. 원문 그대로는 아니어도 "조건을 정리하는 중", "대안을 비교하는 중" 수준의 신호는 체감을 크게 바꾼다.
셋째, 즉시 응답과 분리한다. 사용자에게 바로 줄 수 있는 부분(입력 확인, 검색 결과, 중간 요약)은 일반 모델로 먼저 내보내고, 추론 결과는 뒤이어 채워 넣는다. 구조는 복잡해지지만 체감 지연이 가장 크게 준다.
꼬리 지연이 평균보다 나쁘다
추론 모델의 지연 분포는 오른쪽 꼬리가 길다. 대부분의 요청은 2~3초에 끝나는데 일부가 30초를 넘긴다. 그리고 그 일부는 대개 가장 중요한 요청이다. 어려우니까 오래 걸린 것이고, 어려운 요청은 사용자가 더 신경 쓰는 요청이다.
평균 지연으로 SLO를 잡으면 이 구간이 통째로 안 보인다. 최소한 p95를 보고, 가능하면 p99까지 본다.
꼬리를 자르는 방법은 두 가지다.
예산 상한. 사고 토큰 예산을 낮추면 꼬리가 잘린다. 대신 어려운 요청의 정답률이 떨어진다. 트레이드오프가 명확하므로 정답률 로그를 보고 정한다.
타임아웃 후 강등. 정해진 시간 안에 안 끝나면 요청을 취소하고 일반 모델로 다시 던진다. 총 지연은 오히려 늘어날 수 있지만 상한이 생긴다.
import asyncio
import anthropic
client = anthropic.AsyncAnthropic()
async def answer(prompt: str, deadline: float = 12.0) -> tuple[str, str]:
"""추론 모델을 먼저 시도하고, 기한을 넘기면 일반 모델로 강등한다."""
try:
resp = await asyncio.wait_for(
client.messages.create(
model="claude-opus-5",
max_tokens=6000,
thinking={"type": "enabled", "budget_tokens": 3000},
messages=[{"role": "user", "content": prompt}],
),
timeout=deadline,
)
return "reasoning", text_of(resp)
except asyncio.TimeoutError:
resp = await client.messages.create(
model="claude-sonnet-5",
max_tokens=1500,
messages=[{"role": "user", "content": prompt}],
)
return "fallback", text_of(resp)
def text_of(resp) -> str:
return "".join(b.text for b in resp.content if b.type == "text")강등 비율은 반드시 지표로 남긴다. 이 값이 5%를 넘어가면 예산 설정이 트래픽과 안 맞는다는 뜻이다.
캐시가 덜 듣는다
일반 모델에서 프롬프트 캐싱은 비용 절감의 큰 축이다. 긴 시스템 프롬프트와 문서를 캐시에 올려 두면 재사용할 때 입력 비용이 크게 준다.
추론 모델에서는 이 효과가 상대적으로 작아진다. 이유가 두 가지다.
첫째, 비용의 무게중심이 입력에서 출력으로 옮겨 갔다. 입력 10,000토큰을 캐시로 아껴도 사고 토큰 3,000개의 출력 비용이 그대로면 절감폭이 작다.
둘째, 사고 구간은 캐시되지 않는다. 같은 질문을 다시 던져도 모델은 다시 생각한다. 캐시는 입력 프리픽스에 대한 것이지 생성 결과에 대한 것이 아니다.
그래서 추론 모델에서는 응답 캐시가 프롬프트 캐시보다 유효한 경우가 많다. 질문을 정규화해서 키로 삼고 최종 답변을 저장한다. 반복 질문이 많은 도메인이면 이쪽 효과가 훨씬 크다. 단, 캐시 히트를 노리려면 온도를 낮추고 시스템 프롬프트를 안정적으로 유지해야 한다.
비용 구조를 바꾸는 순서
같은 작업을 더 싸게 만드는 방법에는 순서가 있다. 위에서부터 시도하는 것이 효율적이다.
| 순서 | 방법 | 절감폭 | 품질 위험 |
|---|---|---|---|
| 1 | 사고가 필요 없는 요청을 골라내 일반 모델로 | 가장 큼 | 낮음 |
| 2 | 요청 유형별로 예산 등급 분리 | 큼 | 낮음 |
| 3 | 응답 캐시 도입 | 중간 | 낮음 |
| 4 | 입력 컨텍스트 다이어트 | 중간 | 중간 |
| 5 | 사고 예산 전체 하향 | 중간 | 큼 |
| 6 | 더 작은 추론 모델로 교체 | 큼 | 큼 |
1번이 압도적으로 효과가 크다. 실제 트래픽을 열어 보면 추론이 전혀 필요 없는 요청이 절반을 넘는 경우가 흔하다. 인사말, 단순 조회, 형식 변환 같은 것들이다. 이걸 걸러내지 않은 채로 5번이나 6번을 만지면 힘든 방식으로 조금 아끼면서 품질을 잃는다.
무엇을 계측해 둘 것인가
운영을 시작하면 다음 다섯 개는 요청마다 남긴다. 나중에 어떤 결정을 하든 이 다섯이 근거가 된다.
- 사고 토큰 수 — 요청 유형별로 나눠 분포를 본다
- 예산 소진 여부 — 예산을 다 쓰고 끝난 요청의 비율
- TTFT와 총 지연 — 둘을 따로 본다
- 강등·재시도 횟수 — 상한 설정이 맞는지의 신호
- 요청 유형 태그 — 위 넷을 유형별로 갈라 보기 위한 축
마지막 항목이 빠지면 나머지 넷이 전부 뭉뚱그려진 평균이 되어 아무것도 못 고친다. 유형 태그는 처음부터 넣어 두는 것이 좋다. 나중에 붙이려면 로그를 다시 파싱해야 한다.
추론 모델의 비용은 다루기 어려운 대신 예측 가능하다. 사고 토큰이 어디서 얼마나 나오는지만 알면 대부분의 결정이 계산으로 풀린다. 감으로 예산을 조이는 대신 분포를 보고 등급을 나누는 쪽이 언제나 낫다.
지난 글: 추론 벤치마크 읽는 법
다음 글: 추론 모델을 언제 쓸 것인가
읽어주셔서 감사합니다. 😊