Qwen 3.8 Max API 요금: thinking을 끄는 것보다 나은 16 token

Qwen 3.8 Max의 요금은 input token 100만 개당 $2, output token 100만 개당 $6다. 하지만 API가 제시하는 설정 중 가장 저렴해 보이는 옵션이 실제로도 가장 저렴하고 안정적인 것은 아니다. reasoning_effort: "none"으로 thinking을 끄자 2단계 산술 문제의 정답률이 4/4에서 1/6로 떨어졌다. 반면 thinking token 예산을 16으로 제한하자 6/6으로 회복했고, 평균 output token은 기본 설정보다 20% 적었다. 출시 주간에는 성능에 관한 주장이 쏟아졌지만 검증할 자료는 거의 없었다. model card도, 공개 benchmark 표도 없었고 eval은 내부 결과뿐이었다. Hacker News에서도 곧바로 이 점을 지적했다. 반면 과금 동작은 API key만 있으면 누구나 측정할 수 있다. 출시 첫날 Synthorai gateway를 통해 qwen3.8-max를 측정했다. API가 받는 모든 thinking 제어값, 설정별 reasoning 비용, implicit cache의 최소 크기와 생성 지연, 1M context 주장, Qwen 3.7에서 이어진 특성을 확인했다.

TL;DR

• qwen3.8-max의 reasoning_effort 값 7개는 실제 측정상 네 가지 동작으로 나뉜다. off, 4,096 token 상한, 16,384 token 상한, 무제한이다.
• thinking_budget은 정확히 적용된다. 16 token을 요청하면 측정값도 16이며, 최대치는 262,144다.
• thinking을 끄자 2단계 수학 문제 정답률이 1/6로 떨어졌다. 16 token 예산은 더 적은 비용으로 6/6을 기록했다.
• implicit cache는 0.3초 안에 생성되고 read 요금은 $0.25/1M이다. 다만 prompt가 약 4,300 token보다 짧으면 cache되지 않는다.
• input 상한은 정확하며 초과 시 명시적으로 실패한다. thinking off는 991,808, thinking on은 983,616이다.

Qwen 3.8 Max의 thinking 제어 옵션은 실제로 어떻게 동작하나?

실제로 작동하는 parameter는 세 가지지만, 문서에 나온 세 가지와는 다르다. 서드파티 문서에는 reasoning_effort 값이 low, medium, xhigh 세 가지이며 기본값은 xhigh라고 되어 있다. 측정한 API surface는 none, minimal, low, medium, high, xhigh, max까지 7개를 받는다. 잘못된 값을 보내면 이 allowlist가 그대로 포함된 오류를 반환한다. 이와 함께 native parameter인 thinking_budget과 enable_thinking도 provider까지 전달된다. thinking_budget은 262,144 이하의 양의 정수이고, enable_thinking은 boolean이다. provider가 직접 값을 검증하므로 예산을 0이나 262,145로 지정하면 허용 범위가 표시된 400 응답이 돌아온다.

일반적인 작업에서는 effort level별 차이를 구분할 수 없었다. 간단한 Q&A, 2단계 수학 문제, 중간 난도의 조합론 문제에서 low, medium, high, xhigh와 기본값은 모두 비슷한 범위의 reasoning token을 소모했다. 뚜렷한 차이는 없었다. 수만 token의 thinking이 필요한 작업에서야 차이가 나타났다. 제한 없이 실행했을 때 reasoning token 45,129개를 쓴 소수 개수 계산 문제에서 각 level의 상한이 드러났다.

모든 관측 결과에 맞는 해석은 하나다. 각 effort level은 미리 정해진 thinking 예산 상한이며, 이름 7개는 실제로 네 가지 동작으로 나뉜다. 첫 번째는 off다. none과 enable_thinking: false는 동일하게 동작한다. Minimal과 low는 모두 4,096 token 상한이다. Medium은 그 4배인 16,384다. High, xhigh, max, 기본값은 네 번째 tier다. 이 작업에서는 어느 것도 상한에 걸리지 않았고 실행별로 35K에서 45K token을 사용했다. 이 정도 깊이에서는 일반적인 편차다. 상위 세 level에 차이가 있더라도 경계는 thinking token 45K보다 높다. 대부분의 production traffic이 도달하지 않는 깊이다. 기본값이 xhigh라는 문서의 설명은 측정 결과와도 일치한다. 결과는 명확했다. 상한에 걸린 실행은 모두 오답이었고, 걸리지 않은 실행은 모두 정답이었다. 상한에 도달하기 전에는 level별 동작이 동일하므로 일상적인 traffic에서는 dial이 아무 효과도 없는 것처럼 보인다. 상한을 넘으면 작업 도중 thinking이 잘린다. 특정 상한이 필요하다면 preset 대신 thinking_budget을 직접 지정하는 편이 낫다. 다음 절에서 이 parameter의 동작을 자세히 살펴본다.

thinking_budget은 실제로 어떻게 동작하나?

thinking_budget은 token 단위로 정확히 적용되는 상한이지 할당량이 아니다. 중간 크기의 상한을 지정하면 상한을 두지 않았을 때보다 오히려 비용이 늘 수 있다. thinking_budget은 호출당 최대 reasoning token을 지정하는 DashScope native 정수 parameter다. 범위는 1에서 262,144이고 문서상 기본값은 131,072이며, open-weight Qwen3 family에서 이어진 기능이다. 0이나 262,145를 요청하면 허용 범위가 표시된 400 응답으로 거부된다. 상한에 닿지 않으면 동작은 바뀌지 않는다. 자연스럽게 수백 token만 thinking하는 작업에 8,192 예산을 지정했을 때 각각 331, 485 token을 사용했다. 예산을 지정하지 않았을 때와 같았다. 상한에 도달하면 token 단위로 정확히 잘린다. 16, 64, 256 예산은 모든 실행에서 정확히 16, 64, 256에 reasoning을 멈췄다.

흥미로운 부분은 상한에 도달한 뒤의 동작이다. 모델은 작업을 포기하지 않는다. reasoning을 중단하고 visible answer에서 나머지를 처리한다. 중간 난도의 조합론 문제인 2x12 grid의 domino tiling 개수 계산에서는 모든 예산이 정답을 냈지만, 전체 token 수는 예상과 달랐다.

비용 곡선은 단조 증가나 감소가 아니다. 256 token 예산은 예산을 지정하지 않았을 때보다 2.5배 비쌌다. 모델이 할당된 예산으로 reasoning chain을 시작했다가 중간에 잘렸고, visible channel에서 정답을 단계별로 다시 계산했기 때문이다. 가장 작은 예산은 중간 크기 예산보다 효율적이었다. 16 token은 무언가를 시작하기에도 부족해 모델이 곧바로 간결한 visible work를 수행한다. 여기서 세 가지 규칙을 얻을 수 있다. 첫째, 작은 예산은 얕거나 중간 깊이의 작업에서 효과적인 조절 수단이다. 2단계 수학 문제 batch에서 16 token은 6/6을 기록했고 전체 token은 98-161이었다. 기본값은 126-207이었다. 둘째, 작업 깊이를 알 수 없는 traffic에 중간 크기 상한을 적용하면 안 된다. 실제 reasoning이 진행되던 중 상한에 걸려 같은 작업에 두 번 비용을 내는 구간이 생긴다. 앞의 복잡한 작업에서 4,096과 16,384를 쓴 행도 같은 문제가 대규모로 발생한 경우이며, 결과까지 틀렸다. 셋째, 예산 상한에 걸리면 output 형태가 바뀐다. 제한된 실행은 풀이 과정을 답변에 노출한다. parser가 결과값만 기대한다면 문제가 될 수 있다.

출시 첫날 문서를 직접 측정하면 얼마나 맞나?

절반 정도다. 아직 출시와 관련된 다른 주장을 독립적으로 검증할 수 없으므로 이 차이는 공개할 가치가 있다. 아래 수치는 모두 자체 meter와 probe로 측정했다.

과금 영역은 신뢰할 수 있었다. 결제 금액을 결정하는 요소는 모두 정확하고 명시적으로 적용됐다. 반면 parameter 문서는 실제 API surface의 동작을 따라가지 못했다.

thinking을 끄면 비용이 줄어드나?

Token은 줄지만 정확도도 떨어진다. 바로 옆에 더 나은 선택지가 있다. 인용 가능한 2단계 산술 문제 batch를 사용했다. 문제는 crate 1850개에 각각 part 24개가 있고, 75%가 발송됐으며, 그중 3,120개가 도착했다는 내용이었다. 기본 설정은 호출당 completion token 126-207개를 사용해 4/4를 기록했다. reasoning_effort: "none"은 4-5 token짜리 답을 내고 1/6에 그쳤다. 같은 prompt에 thinking_budget: 16을 지정하자 completion token 98-161개로 6/6을 기록했다. 이 작업 유형에서는 기본값보다 저렴하면서 정확도도 유지했다. 1단계 산술은 none에서도 3/3이었으므로 off는 조회나 단일 단계 변환에 안전하다. 무너지는 쪽은 여러 단계를 거치는 작업이다. 이는 3.8의 regression이 아니다. qwen3.7-max도 thinking을 끄면 같은 batch에서 3/6을 기록했다.

복잡한 작업에서는 예산 절에서 설명한 비효율 구간이 실제 비용으로 드러난다. 복잡한 소수 개수 계산에서 low preset은 thinking token 4,096개를 모두 쓴 뒤 visible candidate checking에 13,882개를 추가로 사용하고도 오답을 냈다. 오답에 $0.11을 썼고, 기본값은 $0.27로 정답을 냈다. 복잡한 작업에서 off switch도 같은 현상을 보였다. thinking을 완전히 끄자 3.8과 3.7 모두 visible answer에서 13-15K token에 걸쳐 수를 열거했다. 각각 한 번씩 실행했으며 한 모델은 정확한 개수를 냈고 다른 모델은 소수 하나 차이로 틀렸다. reasoning 도중 예산 상한에 걸리면 총비용은 늘고 품질은 낮아질 수 있다. 얕은 작업임을 아는 경우에만 thinking을 제한하고, 복잡한 작업에는 충분한 thinking을 허용해야 한다.

1M token context window는 실제인가?

실질적으로는 그렇고, 한계도 정확하고 명확하다. API는 thinking off에서 input token 991,808개, thinking on에서 983,616개까지 받는다. 두 경계 모두 초과 시 명시적으로 실패한다. 너무 큰 요청은 문서를 조용히 자르는 대신 정확한 한계가 표시된 400 응답으로 거부된다. Needle recall은 측정한 모든 크기인 161K, 677K, 919K token에서 작동했다. 삽입해 둔 override code를 11초에서 63초 사이에 그대로 반환했다. 정가 기준 919K token 요청 한 번은 약 $1.84이므로 window는 실제로 쓸 수 있지만, 전체 window를 채운 호출은 기본값이 아니라 설계 단계에서 결정해야 할 선택이다.

Implicit cache의 성능과 최소 크기는?

지금까지 측정한 cache 중 생성은 가장 빠르지만 최소 크기가 유난히 높다. Salt를 추가한 6,103 token prompt를 반복하자 0.3초 뒤 바로 다음 요청에서 hit가 발생했다. Gemini는 생성에 수십 초가 걸리지만, 여기서는 별도의 warm-up 구간을 고려할 필요가 없다. 다시 prime하지 않아도 +5분과 +15분에 계속 hit가 발생했고, +45분에는 entry가 사라졌다. 따라서 요청이 없는 상태에서 실질적인 수명은 15분에서 45분 사이다. Read 요금은 100만 token당 $0.25로 input 요금의 0.125x이며 write 추가 요금은 없다. 할인은 자동으로 적용됐고 cached_tokens field와 측정 비용에서 확인할 수 있었다.

문제는 최소 크기다. 4,221 token prompt에서는 한 번도 hit가 발생하지 않았고, 4,360 token prompt에서는 발생했다. 최초 hit는 항상 정확히 4,096 token이었다. Prompt가 약 4.3K token보다 짧으면 이 cache를 사용할 수 없다. Claude의 최소 1,024 token이나 Kimi K3의 작은 block 단위 automatic caching과 뚜렷이 대비된다. 최소 크기를 넘으면 hit는 128 token block 단위로 양자화된다. 측정값은 4,096, 8,320, 12,544, 16,768이었다. 다만 prime한 prefix의 적용 범위는 51%에서 96%까지 달랐다. 긴 prefix 전체가 아니라 대부분에 할인이 적용된다고 보고 예산을 잡는 편이 안전하다.

Structured output과 tool call에도 reasoning 비용이 붙나?

기본값에서는 그렇고, 이 두 경우가 reasoning을 줄이기에 가장 안전하다. Strict json_schema output은 정상 작동하며 실제로 형식을 강제한다. 같은 extraction을 schema 없이 실행하면 markdown fence로 감싼 결과가 돌아왔다. 기본 설정에서 field 4개짜리 invoice extraction은 JSON 57 token을 내기 전에 reasoning token 252개를 사용했다. reasoning_effort: "none"에서는 올바르고 유효한 JSON을 전체 54 token만으로 생성해 5.7배 줄었다. thinking_budget: 16은 그 중간이었다. Tool 선택도 같은 양상이었다. thinking을 꺼도 올바른 function을 호출했고 token 사용량은 기본값의 3분의 1이었다. 단일 단계 extraction과 routing은 off switch를 안전하게 쓸 수 있는 대표적인 작업이다. Output 요금이 $6/1M이므로 이 차이는 누적될수록 커진다.

Agent 개발자가 알아둘 과금 사항이 하나 더 있다. API는 전체 chain of thought를 reasoning_content로 반환하며, 문서는 multi-turn client가 이를 수정하지 않고 다시 보내야 한다고 안내한다. 하지만 강제되지는 않는다. Reasoning을 포함하거나, 생략하거나, 의도적으로 변조해 turn을 replay해 봤다. 세 경우 모두 허용됐고 짧은 chain의 정확도에도 영향이 없었다. Replay한 reasoning은 일반 input token으로 과금된다. 품질상 필요하다는 근거가 없다면 multi-turn traffic에서 생략해 실제 비용을 줄일 수 있다.

Qwen 3.7에서 그대로 이어진 것과 달라진 것은?

Tokenizer는 바뀌지 않았으므로 기존 token 예산을 그대로 사용할 수 있다. 동일한 영어, 중국어, 일본어, code corpus를 qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash, qwen3.5-flash에서 token화한 결과가 모두 같았다. 따라서 언어별 tokenizer 분석을 바탕으로 세운 언어별 비용 계획도 그대로 적용된다.

두 가지는 달라졌다. 첫째, 3.8-max에는 sibling model에 없는 고정 prompt overhead가 있다. 한 글자로 된 동일한 message가 다른 모든 Qwen에서는 prompt token 11개였지만 3.8-max에서는 49개였다. 호출마다 +38 token이 고정으로 추가된다. 긴 prompt에서는 무시해도 되지만 짧은 prompt를 자주 호출하면 측정 가능한 비중을 차지한다. 둘째, thinking이 mode switch가 아니라 항상 사용할 수 있는 기능이 됐다. 앞서 설명한 7단계 dial과 정확한 budget parameter를 제공하며, 3.7의 제어 방식은 이보다 거칠었다. Preview 당시 두 가지 요금 체계가 함께 알려졌으므로 한 가지를 분명히 해야 한다. 월 $6에서 $68인 Token Plan 구독과 사용량이 적은 시간대의 큰 할인은 Alibaba 자체 app에 적용되며 API에는 적용되지 않는다. API에서는 $2/$6 정가를 지불한다. 이번 측정의 모든 호출에서 gateway meter는 이 요금과 소수점 넷째 자리까지 일치했다.

FAQ

Qwen 3.8 Max에서 thinking을 끌 수 있나?

완전히 끌 수 있다. reasoning_effort: "none" 또는 enable_thinking: false를 사용하면 reasoning token이 전혀 발생하지 않는다. 단일 단계 작업에만 사용하는 편이 좋다. 2단계 산술 batch에서는 1/6을 기록한 반면, 16 token thinking_budget은 비슷하거나 더 적은 token으로 6/6을 기록했다. 여러 단계를 거치는 traffic에서는 off보다 작은 예산을 최솟값으로 두는 편이 낫다.

Qwen 3.8 Max cache가 동작하는 최소 prompt 크기는?

측정상 약 4,300 token이다. 4,221 token prompt에서는 한 번도 hit가 발생하지 않았고 4,360 token에서는 발생했다. 최초 hit는 항상 정확히 4,096 token이다. 최소 크기 미만에서는 할인이 없다. 이를 넘으면 read 요금은 $0.25/1M이고 write 추가 요금은 없으며, prime 후 0.3초부터 entry를 읽을 수 있다.

Qwen 3.8 Max는 reasoning_effort를 지원하나?

7개 값인 none, minimal, low, medium, high, xhigh, max를 허용한다. 하지만 각 level은 thinking 예산 상한으로 동작하며, 작업이 해당 상한을 넘어서 thinking할 때만 차이가 난다. 동작을 확정적으로 제어하려면 thinking_budget을 직접 지정하면 된다. Token 단위로 정확히 적용되고 0은 거부되며 최대값은 262,144다. 현재 client tooling은 어떤 tier가 존재하는지에 대해 서로 다른 정보를 제공한다. 위 목록은 출시 첫날 API surface가 실제로 허용한 값이다.

Multi-turn 대화에서 reasoning_content를 다시 보내야 하나?

문서에는 보내야 한다고 되어 있지만 API는 검사하지 않는다. 측정에서는 reasoning history를 생략하거나 변조해도 오류 없이 허용됐고 짧은 chain의 정확도도 떨어지지 않았다. Replay한 reasoning은 일반 input으로 과금된다. 긴 chain을 자체 eval한 결과 품질 저하가 없다면 replay를 생략해 비용을 줄일 수 있다.

2026-08-03에 Synthorai gateway를 통해 qwen3.8-max를 측정했다. 비교 대상은 qwen3.7-max, qwen3.7-plus, qwen3.6-flash, qwen3.5-flash였다. Dial 허용값, 잘못된 값, max_tokens 경계 probe, effort 상한을 확인하기 위한 자연 소모량 45K의 복잡한 작업, 정확도 급락을 측정하기 위한 고정 인용 batch, arm별 n=4-6 및 salt 적용, 2-3초 간격의 salted cache pair와 시간 간격 ladder, 161K-919K token의 needle 및 overflow probe, 동일한 corpus 4개의 tokenizer count를 측정했다. 금액은 정가인 1M당 $2/$6을 기준으로 gateway meter에서 읽은 실제 과금 비용이다. Preview 기간의 할인, 요금, 동작은 바뀔 수 있으므로 자체 usage record로 확인해야 한다.

← 블로그로 돌아가기