LLM 토큰 사용량: 4토큰 답변에 217토큰이 청구되는 이유

GPT-5.6에 한 줄짜리 수학 문제를 물으면 출력 비용의 88%가 사용자가 볼 수 없는 reasoning에 쓰인다. 화면에 보이는 답은 10 tokens이지만 실제 청구량은 81 tokens이다. 그나마 GPT-5.6은 양호한 편이다. 같은 문제에 GLM 5.2는 4-token 답변을 내놓고 completion tokens 217개를 청구했으며, Qwen3.7-max는 똑같은 답에 1,104개를 청구했다. 이는 예외가 아니라 reasoning 모델의 기본 과금 방식이다. 대부분의 비용 대시보드가 구분하지 않는 여러 token 클래스 중 첫 번째이기도 하다. 이 글에서는 실제 usage 객체를 클래스별로 나누고 측정값과 함께 살펴본다.

TL;DR

• GPT-5.6 기본 설정은 10-token 답변에 81 tokens을 청구했으며, 그중 reasoning 비중은 88%였다. GLM 5.2는 98%, Qwen3.7-max는 99.3%였다.
• Claude Sonnet 5는 thinking parameter를 보내지 않았는데도 5-token 답변에 thinking tokens 114개를 청구했다.
• thinking을 사용하지 않으면 5개 제품군이 오답을 냈다(399, 400, 427, 466, 467). GPT-5.6만 reasoning 없이 정답을 맞혔고, reasoning을 사용한 모든 실행은 401이라고 답했다.
• Claude cache에 1,181 tokens을 쓴 뒤 읽은 비용은 각각 $0.01246와 $0.00566였으며, 정가 계산과 정확히 일치했다.

테스트 조건

이 글의 모든 측정에는 동일한 single-turn prompt를 사용했다. 별도 표기가 없는 한 각 모델의 기본 설정으로 요청했다.

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

정답은 401이다. 3의 배수 333개와 5의 배수 200개를 더하고 중복으로 센 66개를 빼면 467개다. 여기서 15의 배수 66개를 제외하면 401개가 남는다. 이 문제는 의도적으로 골랐다. 화면에 보이는 답은 매우 짧고 tokenizer에 관계없이 3-4 tokens으로 고정된다. 정답이 하나뿐이라 “thinking에 들인 비용이 효과가 있었는지” 확인할 수 있다. 동시에 모델이 thinking을 사용하려 할 만큼은 어렵기 때문에, 점검하려는 동작을 제대로 드러낸다.

청구서에 잡히는 5가지 token 클래스

최신 completion 하나에는 최대 5가지 token 클래스가 4가지 요율로 청구된다. 단일 “사용 token 수”만 보면 이 구분이 모두 사라진다.

위 필드명은 OpenAI-compatible 형식이다. Claude도 같은 5가지 클래스를 다른 이름으로 제공한다. input_tokens와 output_tokens를 사용하고, thinking은 output_tokens_details.thinking_tokens에 기록해 output으로 청구한다. Cache write는 cache_creation 객체에서 TTL별로 다시 나뉜다. ephemeral_5m_input_tokens에는 1.25x, ephemeral_1h_input_tokens에는 2x가 적용된다. 구조는 같고 이름만 다르다. 이 parsing 문제는 뒤에서 다시 다룬다.

5가지 클래스와 각각의 가격 배수. OpenAI-compatible 및 Anthropic 필드명을 함께 표시했다. 88%는 앞의 예제에서 측정한 GPT-5.6의 reasoning 비중이다.

제목에 사용한 실제 객체다. GPT-5.6이 기본 설정으로 테스트 문제에 답한 결과다.

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

청구액 계산에 필요한 정보가 모두 여기에 있다. 한 번 직접 계산해 보자. 실제로 받은 답변은 completion_tokens에서 reasoning_tokens를 뺀 값이다. 81 − 71 = 10 tokens으로, “401”이라는 단어와 서식에 해당한다. 나머지 71 tokens은 chain-of-thought이며, 전액 output 요율로 청구된다. 전체 output 비용의 88%다. GPT-5.6에서는 이 내용 중 단 한 token도 읽을 수 없다. 이 글의 모든 “사용자에게 보이는 답변” 수치는 같은 방식으로 계산했다. 다른 모델에서는 비율이 더 극단적이다. GLM 5.2는 같은 문제에서 4-token 답변을 내놓고 completion tokens 217개를 청구했다. completion_tokens를 “모델이 말한 내용”으로 간주하는 비용 모델은 여기서는 8배, GLM에서는 54배 틀리게 된다.

Reasoning이 곧 예산이며, 조절할 수 있다

조절 기능을 제공하는 3개 제품군에서 지원하는 모든 thinking 설정으로 같은 한 줄짜리 문제를 실행했다. 하나의 gateway를 사용해 2026-07-13/14에 측정했다. 각 제품군 안에서는 reasoning이 적은 순서로 정렬했으며, 나머지 제품군의 flagship 기본값은 다음 섹션에서 다룬다.

이 표에서 확인할 핵심은 4가지다.

• 효과가 있는 모델에서는 조절 폭이 크다. reasoning_effort: none은 $0.000062로 정답을 냈다. luna 기본값보다 8.5배 저렴하다. 더 어려운 작업에서는 GLM 5.2에서 20배 차이도 측정했다. Tier 선택도 같은 조절 수단이다. GPT-5.6 flagship은 이 문제에 기본적으로 reasoning을 전혀 사용하지 않았다. 더 큰 모델이 thinking 없이 해결할 수 있다면, thinking이 필요한 작은 모델보다 비용이 낮을 수 있다.
• 효과가 없는 모델에서는 거의 달라지지 않는다. 설정에 따른 변화 폭은 제품군의 특성이다. Sonnet 5는 단조롭게 증가하며 84에서 249까지 비용이 5배 차이 났다. GPT-5.6은 변화가 작고 순서도 일정하지 않았다. Qwen3.7-max는 low에서도 974 reasoning tokens을 사용해 기본값 1,096개와 큰 차이가 없었다. DeepSeek V4 Pro도 267개와 269개로 사실상 차이가 없었다.
• Label은 단조롭지 않으며 기본값도 결정적이지 않다. 이번 테스트에서 GPT-5.6의 high는 medium보다 적은 tokens을 사용했다. 이전 글에서는 GLM의 low가 high보다 더 많이 사용했다. Sonnet 5는 thinking parameter를 전혀 보내지 않은 요청에서도 114 tokens 동안 thinking했다. 똑같은 GLM 기본 요청도 한 번은 reasoning tokens 213개, 다른 한 번은 1,312개를 사용해 6배 차이가 났다. Label만 보고 판단하지 말고 실제 workload에서 설정의 효과를 측정해야 한다.
• 저렴하지만 틀리는 상황이 반복된다. 여기서 thinking 없이 실행한 두 제품군은 모두 오답을 냈다. GLM은 399, Sonnet 5는 467이라고 답했다. 5개 제품군 전체 결과는 다음 섹션에 있다. Reasoning은 정답률을 위한 예산이다. 이를 줄여도 되는지는 모델이 아니라 task에 따라 결정해야 한다.

실무 원칙은 간단하다. reasoning_tokens를 독립된 핵심 비용 항목으로 다뤄야 한다. Output 요율로 청구되고, 사용자에게 보이는 답변보다 훨씬 큰 경우가 흔하다. 또한 parameter로 조절할 수 있지만, 실제 효과는 직접 측정해야 한다. GPT-5.6은 가격 규칙도 바뀌었다. Write 할증과 cache-key 요구 사항은 GPT-5.6 비용 가이드에서 설명한다.

비용을 낸 내용을 실제로 읽을 수 있는가?

“답변과 별도”라고 해서 항상 숨겨지는 것은 아니다. 이 차이는 정확히 구분해야 한다. usage뿐 아니라 response body까지 확인했다.

• GLM 5.2, DeepSeek, Qwen3.7-max, MiniMax는 전체 reasoning text를 답변 옆의 reasoning_content 필드로 반환한다. 여기서는 각각 3,987, 1,604, 2,509, 581자였다. 개발자는 청구된 모든 token을 읽을 수 있다. 다만 대부분의 애플리케이션처럼 이를 렌더링하지 않으면 최종 사용자에게는 보이지 않는다.
• GPT-5.6은 원본 chain of thought를 공개하지 않으며, 받을 수 있는 것은 summary뿐이다. Response에는 모델이 작성한 reasoning.summary가 포함될 수 있다. 이번에는 359자였다. 하지만 청구된 91 tokens은 summary가 아니라 숨겨진 원문이다. 이 원문에 가장 가까운 것은 reasoning.encrypted_content다. Multi-turn 연속성을 유지하기 위해 다시 전달할 수 있는 암호화된 blob이지만, 직접 복호화할 수는 없다. 비용을 낸 token이 response body 안에 들어 있어도 읽을 수 없는 셈이다.
• Claude는 요청 방식에 따라 달라진다. Adaptive-thinking으로 호출한 Sonnet 5는 텍스트가 비어 있는 thinking block을 반환했지만 thinking_tokens 114개를 청구했다. Thinking했다는 증거만 있고 내용은 읽을 수 없다. Always-on 기본값을 사용한 Fable 5도 같았다. 59개가 청구됐고 block은 비어 있었다. 반면 같은 Sonnet 5를 명시적인 reasoning budget으로 호출하면 실제 thinking text가 반환됐다. 73 tokens이 청구됐으며 텍스트도 존재했다. 요청 방식에 따라 확인 가능한 내용이 달라진다.

따라서 과금 원칙은 공통이지만 가시성은 다르다. 모든 제품군이 reasoning에 output 요율을 청구한다. 구매한 텍스트를 검토할 수 있는 범위는 “전체 공개”부터 “summary만 제공”, “서명된 빈 block만 제공”까지 제각각이다.

텍스트가 반환되면 기계적으로 평가할 수 있다. 이 문제에는 5개의 고정된 중간 결과(333, 200, 66, 467, 401)가 있다. 반환된 모든 reasoning text에는 이 값이 전부 포함돼 있었다. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code, MiniMax M3는 각각 완전한 풀이 과정을 반환했고, low-effort variant는 각각 한 단계씩 빠뜨렸다. 결과뿐 아니라 과정까지 필요한 경우에는 이 차이가 중요하다. reasoning_content가 있으면 비용을 낸 내용을 검증할 수 있지만, summary나 빈 block만 있으면 모델을 신뢰하는 수밖에 없다. 보이지 않는 토큰과 눈에 보이는 청구액은 이 책임성 격차를 형식화하고, PALACE는 외부에서 숨겨진 reasoning을 추정한다.

각 제품군의 최고 모델로 같은 문제 풀기

앞 표에서는 조절 기능을 보여 주기 위해 특정 tier를 사용했다. 이번에는 각 제품군의 최신 flagship을 기본 설정으로 실행했다.

같은 문제에서 flagship별로 청구된 output tokens이다. 빗금 친 주황색은 reasoning 비중, 초록색은 사용자에게 보이는 답변이다. MiniMax의 별표는 usage에 reasoning count가 없어 차감 방식으로 비중을 재구성했다는 뜻이며, 반환된 reasoning text와 대조해 검증했다. GPT-5.6 sol의 체크 표시는 reasoning 없이 정답을 낸 유일한 실행, Gemini 3.5 Flash의 X 표시는 flagship 중 유일한 오답(466)을 뜻한다.

한 차트에 모든 보고 방식이 나타난다.

• 8개 flagship 중 7개가 정답을 냈지만, 같은 401의 비용은 크게 달랐다. Qwen3.7-max는 reasoning tokens 1,096개와 22초, $0.0084를 사용했다. GPT-5.6 flagship은 reasoning tokens을 전혀 사용하지 않았고 비용은 $0.00031였다. 같은 정답인데 비용은 27배, latency는 7배 차이 났다. Reasoning budget 차이가 그대로 드러난다.
• MiniMax는 reasoning text를 반환하지만 count는 제공하지 않는다. 사용자에게 보이는 답변은 3 tokens인데 completion tokens은 260개다. Response의 reasoning_content에는 전체 풀이가 들어 있지만, completion_tokens_details에는 reasoning 항목이 없다. Count가 없으면 차감 방식으로 재구성하면 된다. Completion tokens에서 화면에 보이는 tokens을 빼면 숨겨진 output count가 나온다.
• Gemini 3.5 Flash만 예외였다. Flagship 중 유일하게 오답(466)을 냈으며, completion tokens은 3개이고 reasoning count는 어디에도 없었다. 같은 제품군의 2.5 Flash는 이전 실행에서 12.5초 동안 3-token 답변 401을 생성했지만, 청구 내역에는 지연 이유가 전혀 표시되지 않았다. 반복 실행에서는 427이라고 답했다.
• 오답은 주로 작은 tier와 thinking을 비활성화한 실행에서 나왔다. Thinking을 끈 GLM은 399, 비활성화한 Sonnet 5는 467이라고 답했다. 구형 qwen3-max는 thinking 없이 3 tokens으로 400이라고 답했다. Reasoning channel이 없는 Kimi K2.5는 풀이 과정을 사용자에게 보이는 144 billed tokens으로 출력했다. 자신의 설명 안에서는 401을 도출하고도 최종 답을 400이라고 결론 내렸다. 5개 제품군에서 399, 400, 427, 466, 467이라는 서로 다른 오답이 나왔다. GPT-5.6만 reasoning 없이 정답을 맞혔다.

Cache tokens: 두 방향의 요율 차이는 12배

Prompt caching은 input을 두 클래스로 더 나눈다. 이 구분이 필요한 이유는 둘의 가격 차이가 크기 때문이다. Claude에서 write는 input 요율의 1.25x가 청구되며, 1-hour TTL에는 2x가 적용된다. Read는 0.1x다. 1,181-token cached system prompt를 사용한 Opus 4.8 요청 두 건을 측정했다. Write에는 $0.01246, 다음 read에는 $0.00566가 들었다. 두 금액 모두 정가 계산과 소수점 여섯째 자리까지 일치했으며, 두 번째 호출의 input 측 비용은 약 11배 줄었다. 여기서 핵심은 회계 처리다. cache_creation_input_tokens와 cache_read_input_tokens를 “input tokens” 하나로 합치면 할인 적용 여부를 검증할 수 없고, caching이 조용히 중단돼도 알아차릴 수 없다. 이런 중단은 문서가 암시하는 것보다 자주 발생한다. Cache 측정 결과에서는 실제 threshold가 문서상 최솟값보다 1.4배에서 2.4배 높았다. Provider별 동작 방식은 Prompt caching 가이드에서 자세히 다룬다.

로컬 추정치와 청구액이 일치하지 않는 이유

클라이언트에서 tokenizer library로 비용을 추정하고 나중에 청구액과 대조하는 경우가 많다. 두 값이 일치하지 않는 이유는 3가지다.

• Vendor마다 tokenizer가 다르다. Claude로 보낼 텍스트를 OpenAI tokenizer로 세는 것은 잘못된 자로 측정하는 것과 같다. 같은 문자열도 제품군마다 token 수가 다르다.
• 청구 대상은 message만이 아니다. System prompt와 tool schema도 요청에 포함될 때마다 input tokens으로 청구된다. 로컬 추정에서는 빠뜨리기 쉽다.
• Response를 받기 전에는 reasoning을 예측할 수 없다. 모델이 thinking tokens을 얼마나 사용할지는 클라이언트에서 계산할 수 없다. 반환된 usage를 봐야 알 수 있다.

반환된 usage 객체는 upstream의 실제 청구 기록이다. 정확한 수치를 가장 적은 비용으로 얻으려면 추정을 중단하고 이 값을 읽으면 된다. 문제는 provider마다 형식이 다르다는 점이다. Cached tokens만 해도 제품군에 따라 cached_tokens, prompt_cache_hit_tokens, total_cached_tokens, cache_read_input_tokens로 나타난다.

Detail 객체 역시 고정된 schema가 아니다. OpenAI reference에는 completion 측 필드 4개가 문서화돼 있다. reasoning_tokens, audio_tokens, 그리고 Predicted Outputs의 accepted_prediction_tokens / rejected_prediction_tokens다. Rejected prediction tokens은 output에 나타나지 않지만 completion tokens으로 청구된다. Prompt 측에서는 동일한 형식에 cached_tokens와 함께 text_tokens, audio_tokens, image_tokens가 들어간다. GPT-5.6에는 cache_write_tokens가 추가되며, 실제 응답에서 video_tokens도 확인했다. Vendor는 필드를 자유롭게 확장한다. Kimi K2.7은 문서화되지 않은 completion_tokens_details.text_tokens를 반환했고, Gemini는 thinking과 tool-use tokens을 별도 집계한다. 각자 다른 필드명을 쓴다. Parser는 방어적으로 작성해야 한다. 알 수 없는 detail 필드는 정상적인 상황으로 처리하고, 필드가 없다고 해서 값이 0이라고 가정해서는 안 된다. Audio 필드는 별도의 비용 구조를 갖는다. 전용 ASR 모델 7개를 대상으로 청구된 audio-minute당 음성 인식 비용을 별도로 측정했다.

Gateway가 필요한 이유도 여기에 있다. Synthorai는 이 모든 형식을 하나의 객체로 정규화한다. OpenAI, Anthropic, Gemini, open-weight 제품군 전체에서 reasoning_tokens와 cache의 두 방향을 채워 주므로, 하나의 parser로 routing 대상인 모든 모델을 처리할 수 있다.

확인에서 차단으로

비용 내역을 읽는 것은 절반에 불과하다. 나머지 절반은 초과 비용을 확인하는 데 그치지 않고 애초에 발생하지 못하게 막는 것이다. 월말 dashboard는 이미 돈이 나간 뒤에야 이상 비용을 알려 준다. Retry loop에 빠진 agent는 dashboard를 확인하지 않는다. Gateway에서는 각 key에 quota가 있고 used_quota와 RPM 상한을 추적해 요청 시점에 강제한다. 예산을 모두 쓴 key는 3주 뒤 더 큰 청구서를 만드는 대신 다음 요청에서 명시적인 error를 받는다. 요청별 attribution 정보도 같은 response envelope에 반환된다. 어떤 key와 모델을 사용했는지, BYOK인지 platform billing인지 확인할 수 있다. 따라서 기능별 비용은 복잡한 재구성 작업이 아니라 group-by 한 번이면 계산된다.

측정 결과에 따른 작업 순서는 다음과 같다. 다른 최적화에 앞서 reasoning_tokens와 cache 필드를 확인하고, task별로 reasoning 설정을 조정한다. 실패하면 loop에 빠질 수 있는 모든 key에는 hard quota를 둔다. 특정 모델 조합과 token 클래스가 현재 사용량에서 얼마인지 계산하려면 비용 최적화 도구를 사용하면 된다. 위에서 사용한 것과 동일한 token당 요율로 계산한다.

← 블로그로 돌아가기