LLM 비용의 80%는 숨겨진 추론 토큰입니다. 하나의 파라미터가 해결책을 제시합니다.
요약
LLM 비용의 상당 부분(최대 91%)이 사용자에게 보이지 않는 '추론 토큰'에서 발생합니다. 이 숨겨진 사고 과정은 API 파라미터 조정을 통해 크게 줄일 수 있으며, 이를 통해 비용을 69~91% 절감하고 레이턴시를 대폭 단축할 수 있습니다.
핵심 포인트
- LLM 비용의 80~91%가 눈에 보이지 않는 추론 토큰에서 발생합니다.
- API 파라미터 조정만으로 비용과 지연 시간을 크게 줄일 수 있습니다.
- 추론 과정은 복잡한 계획이나 계산이 필요할 때 유용합니다.
- 단순 분류나 JSON 추출 같은 작업에서는 숨겨진 사고 과정을 제거하는 것이 효율적입니다.
저는 세 가지 저렴하고 인기 있는 모델에 동일한 간단한 질문을 했습니다: "주니어 개발자를 위해 HTTP 캐싱 헤더가 어떻게 작동하는지 150단어 분량으로 설명해 주세요."
각 모델은 약 150단어로 답변했습니다. 하지만 각각 800개에서 2,500개의 출력 토큰에 대해 비용을 청구했습니다.
차이는 추론 토큰(reasoning tokens)입니다. 즉, 모델이 답변하기 전에 수행하는 '사고' 과정입니다. 이 모든 토큰은 출력 요율로 지불되지만, 응답에는 절대 나타나지 않으며 대부분의 대시보드에서는 이를 분리하여 보여주지 않습니다. 이와 같은 작업의 경우, 이는 순수한 낭비입니다.
여기에 직접 앱에서 측정하는 방법과 저에게서 이것을 제거해 준 하나의 파라미터가 있습니다.
측정 방법
모든 OpenAI 호환 API는 usage.completion_tokens_details.reasoning_tokens에 숨겨진 토큰을 보고합니다. 이 스크립트는 각 모델을 기본 설정으로 세 번 호출한 다음, reasoning_effort를 낮춘 상태로 다시 호출하여 중앙값을 출력합니다.
"""hidden_tokens.py: 출력 비용 중 얼마나 많은 부분이 숨겨진 사고 과정일까요?"""
import os, statistics, time
from openai import OpenAI
...
base_url과 키를 수정하여 모든 OpenAI 호환 엔드포인트를 가리키도록 하세요. 위에 나열된 모델 이름은 제가 테스트한 것입니다.
결과 (2026년 10월 11일, 3회 실행의 중앙값)
| Model | Setting | Billed output tokens | Hidden | Words shown | Time | Cost per 1k calls |
|---|---|---|---|---|---|---|
| GLM 5.3 Flash | default | 2,483 | 2,256 | 152 | 39.6s | $0.1058 |
| ... | ||||||
| 동일한 답변을 83–91% 저렴하고 3–5배 빠르게 얻었습니다. 단지 하나의 파라미터만 바꿨을 뿐입니다. |
숨겨진 토큰 수는 실행마다 크게 달라지기 때문에, 저는 전체 스크립트를 다시 실행했습니다. 두 번째 실행에서는 기본 설정이 74–90%가 숨겨져 있었고, 이 설정으로도 비용을 69–91% 절감할 수 있었습니다. 정확한 숫자는 변하지만, 방향성은 결코 바뀌지 않았습니다.
기본 설정으로는, 해당 실행에서 제가 지불한 금액의 82–91%가 제가 본 적 없는 텍스트였습니다. 레이턴시(Latency)도 청구서에 따라 움직입니다: GLM 5.3 Flash는 실제 답변을 쓰기 전에 숨겨진 에세이를 쓰는 것을 멈추면서 40초에서 8초로 줄어들었습니다.
저를 놀라게 한 두 가지
1. 값은 이식성이 떨어집니다. DeepSeek는 "none"을 허용하며 숨겨진 토큰(hidden tokens)을 0으로 만듭니다. GLM의 경우, 이미 "low"에서 0이 나왔습니다. 같은 모델에서도 "minimal"은 때때로 수백 개의 숨겨진 토큰을 유지했습니다. 각 모델별로 측정해야 하며, 가정해서는 안 됩니다.
2. 일부 모델은 이를 무시합니다. 별도의 테스트에서 GPT-5.5는 제가 어떤 값을 보내든 400~600개의 숨겨진 토큰을 유지했습니다. 만약 모델이 이 설정(노브)에 반응하지 않는다면, 해결책은 조정하는 것이 아니라 해당 작업에 다른 모델을 선택하는 것입니다.
추론 사고를 계속해야 하는 경우 (When to keep thinking on)
숨겨진 추론 과정(Hidden reasoning)이 항상 낭비는 아닙니다. 이는 다단계 수학 계산, 까다로운 리팩토링, 플래닝 에이전트, 그리고 잘못된 답변의 비용이 큰 모든 영역에서 그 가치를 얻습니다. 반면, 다음과 같은 경우에는 낭비입니다:
- 분류 및 라우팅("이 티켓은 어느 대기열로 가야 할까요?")
- JSON으로 추출하기(extraction to JSON)
- 요약, 재작성, 번역
- 짧은 채팅 답변 및 UI 카피
효과적인 간단한 규칙: 애플리케이션 전체가 아닌 호출 지점(call site)별로 reasoning_effort를 설정하세요. "이 이메일을 요약해 줘"라는 도우미와 "데이터베이스 마이그레이션을 계획해 줘"라는 에이전트가 동일한 설정을 공유해서는 안 됩니다.
FAST = {"reasoning_effort": "low"} # 추출, 레이블링, 요약
DEEP = {} # 플래닝, 수학, 복잡한 코드
자체 트래픽 확인하기 (Check your own traffic)
하루 동안 completion_tokens_details.reasoning_tokens를 completion_tokens 옆에 기록하세요. 만약 간단한 작업을 수행하는 엔드포인트에서 숨겨진 토큰이 출력 토큰의 절반을 초과한다면, 당신은 올해 가장 저렴하게 최적화할 수 있는 방법을 찾아낸 것입니다.
저는 이 테스트들을 Qubax를 통해 실행했습니다. Qubax는 400개 이상의 모델(OpenAI와 호환되는 API이며 OpenRouter 가격보다 훨씬 낮은 경우가 많음)을 제공하며, 문자열 하나만 변경하여 모델을 전환할 수 있어 스크립트가 모든 모델에서 변함없이 실행됩니다. 표의 가격은 2026년 10월 11일 기준 토큰당 요율이며, 실시간 요율은 price index를 참고하세요.
FAQ
추론 토큰(reasoning tokens)이란 무엇인가요?
모델이 보이는 답변을 작성하기 전에 '사고'하는 동안 생성하는 토큰입니다. 이 토큰은 출력 토큰 가격(output-token price)으로 청구되지만, 응답 텍스트에는 포함되지 않습니다. 이 개수는 usage.completion_tokens_details.reasoning_tokens에서 확인할 수 있습니다.
reasoning_effort를 낮추면 답변 품질이 떨어지나요?
요약, 추출 및 레이블링과 같은 간단한 작업에서는 제 테스트에서 눈에 띄는 차이가 없었습니다. 다단계 수학(multi-step math), 계획(planning) 또는 복잡한 코딩(hard code)의 경우, reasoning을 활성화 상태로 유지하고 비활성화하기 전에 측정해 보십시오.
어떤 reasoning_effort 값을 사용해야 하나요?
모델에 따라 다릅니다. 이 테스트에서 DeepSeek V4.1 Flash는 "none"으로 숨겨진 토큰이 0이었고, GLM 5.3 Flash와 Claude Haiku 5.5는 "low"였습니다. 사용하는 각 모델을 테스트해 보세요.
참고 자료 (References)
- OpenAI API reference,
reasoning_effort및completion_tokens_details: https://platform.openai.com/docs/api-reference/chat/create - Anthropic extended thinking docs: https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
- DeepSeek API docs: https://api-docs.deepseek.com/
운영 환경에서 발견한 최악의 숨겨진 토큰 비율은 무엇인가요? 다른 스택의 수치를 보고 싶습니다.
원래 발행처는 qubax.ai입니다. Qubax는 모든 주요 AI 모델을 하나의 API 키로 제공하며, OpenRouter보다 저렴합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기