
LLM 토큰 사용량: 왜 4개 토큰의 답변이 217개 토큰으로 청구되는가
요약
추론 모델(Reasoning Models) 사용 시 발생하는 숨겨진 토큰 비용과 청구 구조를 분석합니다. 실제 답변 토큰보다 훨씬 많은 추론(Reasoning/Thinking) 토큰이 비용의 대부분을 차지하는 현상을 모델별 사례로 설명합니다.
핵심 포인트
- 추론 모델은 가시적인 답변보다 훨씬 많은 '사고 토큰'을 생성하여 비용을 청구함
- GPT-5.6, GLM 5.2, Qwen3.7-max 등 주요 모델의 추론 비용 비중 분석
- Claude의 경우 thinking_tokens가 output_tokens 요율로 청구됨을 확인
- 캐시 쓰기 및 읽기에 따른 세분화된 비용 구조 파악 필요
GPT-5.6에게 한 줄짜리 수학 질문을 던지면, 출력 비용의 88%는 당신이 결코 보지 못할 추론 (reasoning) 비용입니다: 가시적인 토큰은 10개지만, 청구된 토큰은 81개입니다. 그리고 GPT-5.6은 완만한 사례일 뿐입니다. 동일한 질문이 GLM 5.2에서는 4개 토큰의 답변에 대해 217개의 완료 (completion) 토큰을 청구했고, Qwen3.7-max에서는 동일한 답변에 대해 1,104개를 청구했습니다. 이것은 이상 현상이 아닙니다. 추론 모델 (reasoning models)이 설계된 방식대로 청구하는 것이며, 대부분의 비용 대시보드에서 분류하지 않는 여러 토큰 클래스 중 첫 번째입니다. 이 포스트는 실제 usage 객체를 측정된 수치와 함께 클래스별로 해부합니다.
요약 (TL;DR)
- GPT-5.6은 10개 토큰의 답변에 대해 기본적으로 81개 토큰을 청구했으며, 이는 88%의 추론 (reasoning) 비용입니다. GLM 5.2는 98%, Qwen3.7-max는 99.3%를 기록했습니다.
- Claude Sonnet 5는 추론 파라미터 (thinking parameter)를 보내지 않았음에도 5개 토큰의 답변에 대해 114개의 사고 (thinking) 토큰을 청구했습니다.
- 5개의 모델 제품군이 추론 없이 오답을 냈습니다 (399, 400, 427, 466, 467). GPT-5.6만이 추론 없이도 정답을 맞혔으며, 모든 추론 실행 결과는 401이었습니다.
- 1,181개 토큰의 Claude 캐시 쓰기 후 읽기 비용은 각각 $0.01246와 $0.00566였으며, 이는 목록 가격과 정확히 일치합니다.
테스트 내용
이 포스트의 모든 측정값은 동일한 단일 턴 프롬프트 (single-turn prompt)를 사용하며, 별도의 언급이 없는 한 각 모델의 기본 설정으로 전송되었습니다:
1000 이하의 양의 정수 n 중에서 3 또는 5의 배수이지만 15의 배수는 아닌 숫자는 몇 개인가? 다른 설명 없이 숫자만 답하시오.
정답은 401입니다 (3의 배수 333개, 5의 배수 200개, 중복 계산된 66개를 빼면 467개; 여기서 15의 배수인 66개를 제외하면 401개가 남습니다). 우리는 이를 의도적으로 선택했습니다. 가시적인 답변은 매우 작고 모든 토크나이저 (tokenizer)에서 3~4개 토큰으로 고정되어 있으며, 정답이 단 하나뿐이라
| 클래스 (Class) | 나타나는 위치 | 청구 기준 |
|---|---|---|
| 프롬프트 (캐시 미적용) (Prompt (uncached)) | prompt_tokens | 입력 요율 (input rate) |
| ... |
위 필드 이름들은 OpenAI 호환 형태입니다. Claude는 자체적인 이름을 사용하여 동일한 5가지 클래스를 제공합니다: input_tokens와 output_tokens가 있으며, 사고 과정 (thinking)은 output_tokens_details.thinking_tokens에 보고되고 출력 (output) 요율로 청구됩니다. 또한 캐시 쓰기 (cache write)는 cache_creation 객체 내에서 TTL에 따라 더 세분화됩니다 (ephemeral_5m_input_tokens는 1.25배, ephemeral_1h_input_tokens는 2배). 구조는 동일하지만 라벨이 다를 뿐입니다. 이러한 파싱 (parsing) 문제는 이후 섹션에서 다시 다룹니다.
OpenAI 호환 및 Anthropic 필드 이름으로 표시된 5가지 클래스와 가격 배수. 88% 수치는 위 예시에서 측정된 GPT-5.6의 추론 (reasoning) 점유율입니다.
다음은 제목 뒤에 숨겨진 실제 객체로, 기본 설정 상태에서 테스트 질문에 답하는 GPT-5.6의 모습입니다:
{
"prompt_tokens": 38,
"completion_tokens": 81,
...
여기에 청구 산식 (billing arithmetic)이 들어 있으며, 한 번은 명시적으로 계산해 볼 가치가 있습니다. 당신이 받은 답변은 completion_tokens에서 reasoning_tokens를 뺀 값입니다: 81 − 71 = 10 토큰이며, 이는 단어 "401"과 그 형식입니다. 나머지 71개 토큰은 사고 사슬 (chain-of-thought)으로, 전체 출력 요율로 청구되며 출력 비용의 88%를 차지합니다. 그리고 GPT-5.6에서는 이 토큰 중 단 하나도 읽을 수 없습니다. 이 포스트에 등장하는 모든 "가시적인 답변" 수치는 동일한 방식으로 계산됩니다. 다른 곳에서는 이 비율이 훨씬 더 가팔라집니다. GLM 5.2는 동일한 질문에 대해 4개 토큰의 답변을 내놓으면서 217개의 completion 토큰을 사용했습니다. 따라서 completion_tokens를 "모델이 말한 것"으로 해석하는 비용 모델은 여기서는 8배, 저기서는 54배나 차이가 나게 됩니다.
추론 (Reasoning)은 예산이며, 조절 가능하다
세 가지 조절 가능한 제품군(steerable families)이 수용하는 모든 사고 설정(thinking setting)에 대해 동일한 한 줄짜리 질문을 던졌을 때의 결과입니다. 하나의 게이트웨이, 2026-07-13/14 (각 제품군 내에서 추론량이 적은 것부터 많은 순으로 정렬됨; 나머지 제품군의 플래그십 기본값은 다음 섹션에 있음):
| 설정 (Configuration) | 답변 (Answer) | 추론 토큰 (Reasoning tokens) | 비용 (Cost) |
|---|---|---|---|
GPT-5.6 mini (luna), none / low / medium / high | 401 (모두 정답) | 0 / 52 / 85 / 74 | $0.000062 / 0.000410 / 0.000608 / 0.000542 |
| ... | |||
| 해당 표에서 솔직하게 읽어낼 가치가 있는 네 가지 사항은 다음과 같습니다: |
- 효과가 있는 곳에서는 레버(lever)의 폭이 매우 큽니다.
reasoning_effort: none설정은 $0.000062로 정답을 맞혔는데, 이는 luna의 기본값보다 8.5배 저렴하며, 우리가 측정한 더 어려운 작업에서는 GLM 5.2에서 20배까지 차이가 났습니다. 티어(Tier) 선택 또한 동일한 레버의 일부입니다. GPT-5.6의 플래그십 모델은 기본적으로 추론 없이 이 질문에 답했으므로(다음 섹션 참조), 생각할 필요가 없는 더 큰 모델이 생각해야 하는 더 작은 모델보다 비용을 더 아낄 수 있습니다. - 효과가 없는 곳에서는 거의 무력합니다. 다이얼(dial)이 얼마나 돌아가는지는 제품군(family)의 특성입니다. Sonnet 5에서는 5배의 비용 변동(84에서 249로)과 함께 단조 증가(monotonic)하는 양상을 보였고, GPT-5.6에서는 완만하고 순서가 없었으며, Qwen3.7-max에서는 거의 무력했습니다(
low설정이 기본값인 1,096개에 비해 여전히 974개의 추론 토큰을 사용함). DeepSeek V4 Pro에서는 사실상 무의미했습니다(269개 대비 267개). - 라벨(Labels)은 단조적이지 않으며 기본값(defaults)은 결정론적이지 않습니다. GPT-5.6의
high설정은 여기서medium설정보다 토큰을 적게 사용했습니다. GLM의low는 이전 포스트에서high보다 더 많은 비용을 썼습니다. Sonnet 5는 사고 파라미터(thinking parameter)를 전혀 보내지 않은 요청에 대해 114개의 토큰 동안 추론했습니다. 또한 동일한 GLM 기본 요청이 한 번의 실행에서는 213개의 추론 토큰을 사용하고, 다른 실행에서는 1,312개를 사용하여 6배의 차이를 보였습니다. 라벨만 보고 판단하지 말고, 당신의 워크로드(workload)에 미치는 다이얼의 실제 효과를 측정하십시오. - '싸지만 틀리는 것(Cheap-and-wrong)'이 반복되는 실패 패턴입니다. 여기서 사고 없이 답변한 두 제품군 모두 오답을 냈습니다 (GLM 399, Sonnet 5 467). 다섯 개 제품군 전체의 명단은 다음 섹션에 있습니다.
추론 (Reasoning)은 정확도를 위한 비용 예산이며, 이를 줄이는 것이 이득인지 여부는 모델이 아닌 작업 (task)에 달려 있습니다.
실질적인 규칙: reasoning_tokens를 하나의 독립된 항목으로 취급하십시오. 이는 출력 (output) 요율로 청구되며, 통상적으로 눈에 보이는 답변보다 훨씬 더 많은 양을 차지하며, 실제 효과를 반드시 측정해야 하는 파라미터 (parameters)의 영향을 받습니다. GPT-5.6의 경우 가격 책정 규칙도 변경되었음을 유의하십시오. GPT-5.6 비용 가이드에서 쓰기 프리미엄 (write premium)과 캐시 키 (cache-key) 요구 사항을 확인할 수 있습니다.
실제로 지불한 내용을 읽을 수 있는가?
"답변과 별개"라는 말이 항상 숨겨져 있다는 뜻은 아니며, 이 차이를 정확히 파악하는 것은 가치가 있습니다. 저희는 단순히 사용량 (usage)뿐만 아니라 응답 본문 (response bodies)을 확인했습니다:
- GLM 5.2, DeepSeek, Qwen3.7-max, 그리고 MiniMax는 답변 옆의
reasoning_content필드에 전체 추론 텍스트를 반환합니다 (여기서는 각각 3,987, 1,604, 2,509, 581자). 개발자는 청구된 모든 토큰을 읽을 수 있습니다. 최종 사용자 (end users)는 개발자가 이를 렌더링 (render)해야만 볼 수 있으며, 대부분의 애플리케이션은 그렇게 하지 않습니다. - GPT-5.6은 가공되지 않은 사고의 흐름 (raw chain of thought)을 숨깁니다. 요약본이 얻을 수 있는 최선입니다. 응답에는 모델이 작성한
reasoning.summary(여기서는 359자)가 포함될 수 있지만, 청구된 91개 토큰은 요약본이 아닌 숨겨진 가공되지 않은 텍스트입니다. 이 텍스트와 가장 유사한 것은reasoning.encrypted_content입니다. 이는 멀티 턴 (multi-turn) 연속성을 위해 다시 전달할 수는 있지만 절대 복호화할 수 없는 암호화된 블롭 (blob)입니다. 여러분이 지불한 토큰은 여러분의 응답 본문 안에 있지만, 읽을 수 없는 상태로 존재합니다. - Claude는 질문 방식에 따라 달라집니다. 저희의 적응형 사고 (adaptive-thinking) Sonnet 5 호출은
thinking_tokens가 114개 청구되었음에도 텍스트가 비어 있는thinking블록을 반환했습니다. 즉, 생각은 했지만 읽을 내용은 없다는 증거입니다. Fable 5 역시 항상 켜져 있는 기본 설정에서 동일하게 동작했습니다 (59개 청구, 빈 블록). 하지만 명시적인 추론 예산 (reasoning budget)을 설정하여 호출한 동일한 Sonnet 5는 실제 사고 텍스트를 반환했습니다 (73개 토큰 청구, 텍스트 존재). 어떻게 질문하느냐에 따라 무엇을 볼 수 있는지가 결정됩니다.
따라서 청구 내역은 보편적이지만, 가시성(visibility)은 그렇지 않습니다. 모든 모델 제품군(family)은 추론(reasoning)에 대해 출력 요율(output rate)을 부과하지만, 구매한 텍스트를 감사(audit)할 수 있는지 여부는 "전체 공개"부터 "요약만 제공", 그리고 "서명된 빈 블록"에 이르기까지 다양합니다.
텍스트가 반환될 때, 이를 기계적으로 등급을 매길 수 있습니다. 우리의 질문에는 5개의 고정된 중간 결과값(333, 200, 66, 467, 401)이 있으며, 반환된 모든 추론 텍스트는 이 값들을 모두 포함하고 있었습니다. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code, MiniMax M3는 각각 완전한 유도 과정(derivation)을 제공한 반면, 저비용 변형 모델(low-effort variants)들은 각각 한 단계씩 누락되었습니다. 정답뿐만 아니라 과정이 필요한 사람들에게 이것이 바로 차이점입니다. reasoning_content를 사용하면 지불한 대가에 대해 검증할 수 있지만, 요약이나 빈 블록을 받게 되면 신념에 의존해야 합니다. Invisible Tokens, Visible Bills는 이러한 책임의 격차(accountability gap)를 공식화하며, PALACE는 외부에서 숨겨진 추론을 추정합니다.
모든 모델 제품군의 최상위 모델을 대상으로 한 동일한 질문
조정 테이블(steering table)은 조절 가능한 요소(knobs)를 보여주기 위해 특정 계층을 사용했습니다. 다음은 동일한 질문에 대해 기본 설정으로 테스트한 각 제품군별 최신 플래그십(flagship) 모델 결과입니다:
| 모델 | 답변 | 완료 토큰 (Completion tokens) | 보고된 추론 (Reported reasoning) | 비용 |
|---|---|---|---|---|
| Qwen3.7-max | 401 (정답) | 1,104 | 1,096 (99.3%) | $0.008393 |
| ... | ||||
![]() |
동일한 질문에 대해 플래그십 모델별로 청구된 출력 토큰 (빗금 친 주황색 = 추론 비중; 녹색 = 가시적인 답변). MiniMax의 별표(*): 이 모델의 사용량에는 추론 카운트가 포함되지 않으므로, 비중은 뺄셈을 통해 재구성되었으며 반환된 추론 텍스트를 통해 검증되었습니다. GPT-5.6 sol의 체크 표시는 유일하게 추론이 0인 올바른 실행을 나타내며, Gemini 3.5 Flash의 엑스(X) 표시는 유일하게 틀린 플래그십 답변(466)을 나타냅니다.
하나의 차트에 담긴 모든 보고 방식:
- 8개의 플래그십 모델 중 7개가 동일한 401에 대해 매우 다른 가격으로 정답을 맞혔습니다. Qwen3.7-max는 1,096개의 추론 토큰 (reasoning tokens)을 사용하며 22초와 $0.0084를 소모했습니다. 반면 GPT-5.6의 플래그십은 추론 토큰을 전혀 사용하지 않고 $0.00031를 소모했습니다. 동일한 정답에 대해 27배의 비용 차이와 7배의 지연 시간 (latency) 차이가 발생하는 것은 가시화된 추론 예산 (reasoning budget)을 보여줍니다.
- MiniMax는 추론 텍스트는 반환하지만 개수는 제공하지 않습니다. 3개의 가시적 답변 토큰에 대해 260개의 완료 토큰 (completion tokens)이 발생했습니다. 응답은
reasoning_content에 전체 유도 과정을 포함하고 있지만,completion_tokens_details에는 추론 관련 항목이 없습니다. 개수가 누락된 경우, 뺄셈을 통해 재구성할 수 있습니다. 즉, 완료 토큰에서 가시적 토큰을 빼면 숨겨진 출력 (hidden-output) 개수가 됩니다. - Gemini 3.5 Flash는 예외적인 사례입니다. 유일하게 오답(466)을 낸 플래그십 모델로, 3개의 완료 토큰을 사용했으며 어디에도 추론 개수가 표시되지 않았습니다. 그 형제 모델인 2.5 Flash는 과거에 3개의 토큰으로 401을 생성하는 데 12.5초를 소모했으나 청구 내역에는 이유가 명시되지 않았으며, 재실행 시에는 427이라고 답했습니다.
- 오답은 주로 하위 티어 모델이나 사고 기능(thinking)이 비활성화된 모델에서 나타납니다. 사고 기능이 꺼진 GLM은 399라고 답했고, 비활성화된 Sonnet 5는 467이라고 답했습니다. 구형 qwen3-max는 전혀 사고하지 않았으며(3개 토큰) 400이라고 답했습니다. 추론 채널이 없는 Kimi K2.5는 144개의 가시적인 청구 토큰을 통해 소리 내어 추론하며 자체 문장 안에서 401을 도출한 뒤, 결론적으로 400이라고 답했습니다. 다섯 개의 모델군이 다섯 개의 서로 다른 오답(399, 400, 427, 466, 467)을 내놓은 반면, GPT-5.6만이 추론 없이 단독으로 정답을 맞혔습니다.
캐시 토큰 (Cache tokens): 두 가지 방향, 12배의 차이
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기