적응형 사고와 비용 예측
업데이트 September 1, 2026 · 최초 게시 September 1, 2026
추론 예산은 예전에는 직접 설정하는 숫자였습니다. thinking: {type: "enabled", budget_tokens: N}처럼 넘기면 N은 제어 수단인 동시에 예측값이었습니다. 최악의 경우 요청마다 N개의 추론 토큰이 들었고, 재무팀은 이 값에 요청 수를 곱하면 됐습니다.
이 파라미터는 Opus 4.6과 Sonnet 4.6에서 지원이 중단되었고, Fable 5와 5.1, Sonnet 5, Opus 5, 4.8, 4.7 같은 최신 모델에서는 보내면 400이 반환됩니다. 대체재는 thinking: {type: "adaptive"}이며, 모델이 요청의 난이도를 보고 얼마나 생각할지 스스로 정합니다.
평균적으로는 달러당 얻는 결과물이 더 좋아집니다. 하지만 이것은 상한선이 사라졌다는 뜻이기도 합니다. 예측이 그 상한선을 기준으로 세워졌다면, 그 예측은 월말이 되어서야 드러나는 방식으로 틀려 있게 됩니다.
숫자에서 무엇이 바뀌는가
요청당 평균 비용은 보통 내려갑니다. 쉬운 요청이 필요 없었던 추론 비용을 더 이상 내지 않기 때문입니다. 하지만 분산은 올라갑니다. 어려운 요청이 더 이상 상한선에서 잘리지 않기 때문입니다. 두 값은 서로 반대 방향으로 움직이며, 요청당 최대값으로 표현된 예산은 붙잡을 것이 남지 않습니다.
실제로 문제가 되는 것은 평균이 아니라 꼬리 부분입니다. 프롬프트 변경, 새로운 문서 유형, 더 어려운 질문을 하기 시작한 사용자 한 명이 트래픽의 일부를 더 깊은 추론으로 밀어 넣어도, 설정 어디에도 이를 막는 장치는 없습니다.
상한선이 아니라 분포를 예측하십시오
효과가 큰 순서대로 세 가지 변경이 있습니다.
추론 토큰을 별도의 시계열로 추적하십시오. 이 값은 이미 모든 응답의 usage 객체에 들어 있습니다. 텔레메트리에서 입력 토큰, 출력 토큰과 분리해 두면, 월말이 아니라 변화가 생긴 날 그 이동을 볼 수 있습니다.
백분위수로 예산을 세우십시오. "요청당 N 토큰"이라는 표현 대신 라우트별 p50과 p99를 쓰십시오. p50은 워크로드가 얼마나 드는지 알려 주고, p50과 p99의 차이는 나쁜 한 주에 얼마나 노출되어 있는지 알려 줍니다.
총액이 아니라 비율에 대해 경고를 설정하십시오. 라우트별로 전체 토큰 중 추론 토큰이 차지하는 비율은, 프롬프트 변경으로 모델이 더 힘들게 일하기 시작할 때 가장 먼저 움직이는 단일 지표입니다. 총지출 경고는 볼륨이 쌓인 뒤 며칠이 지나서야 울립니다.
상한선이 여전히 필요한 곳
요청별 조절 장치를 없앤다고 모든 제한을 없애는 것은 아닙니다. 라우트 단위와 테넌트 단위의 지출 한도는 여전히 작동하고, 여전히 폭주하는 루프를 잡아냅니다. 가드레일이 있어야 할 곳은 이제 바로 그 자리, 즉 여러분이 소유한 경계입니다. 더 이상 존재하지 않는 요청 파라미터 안이 아닙니다. 깊은 추론이 결코 가치가 없는 지연 민감 경로에서는, 지렛대는 토큰 예산이 아니라 모델 선택입니다.
관련 글
관련 글
이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →