Qwen 3.8 Max API 料金：思考オフより 16 token が有利

Qwen 3.8 Max の料金は入力 100 万 token あたり $2、出力 100 万 token あたり $6 だ。しかし、API が示す設定のうち、最も安く安定するものは思考オフではない。2 段階の算術タスクで reasoning_effort: "none" を指定すると、正解率は 4/4 から 1/6 に落ちた。一方、思考 token の上限をわずか 16 に設定すると 6/6 に戻り、出力 token もデフォルトより平均で 2 割少なかった。リリース週には性能をうたう声が目立ったが、検証材料はほとんどなかった。model card も公開 benchmark 表もなく、eval は社内限定であり、Hacker News でもすぐに問題視された。一方、課金の挙動は API key があれば誰でも測定できる。そこでリリース初日に Synthorai gateway 経由で qwen3.8-max を計測した。API が受け付ける全思考制御、各設定で増える reasoning token、暗黙的 cache の最小サイズと構築時間、1M context の実態、そして Qwen 3.7 から引き継がれた点を調べた。

TL;DR

• qwen3.8-max が受け付ける 7 種類の reasoning_effort は、実測上はオフ、上限 4,096 token、上限 16,384 token、無制限の 4 挙動に集約される。
• thinking_budget は厳密に適用される。16 token を指定すれば計測値も 16 になり、上限は 262,144 だ。
• 思考オフでは 2-hop 算術の正解率が 1/6 まで落ちた。16-token budget なら、より安く 6/6 を達成した。
• 暗黙的 cache は 0.3 秒未満で構築され、読み取り料金は $0.25/1M だ。ただし、prompt が約 4,300 token 未満だと cache されない。
• 入力上限は厳密で、超過時は明示的に失敗する。思考オフでは 991,808、思考オンでは 983,616 だ。

Qwen 3.8 Max の思考制御は実際に何をするのか？

有効な parameter は 3 つあるが、ドキュメントに記載された 3 つとは異なる。サードパーティーのドキュメントでは、reasoning_effort に low、medium、xhigh の 3 値があり、デフォルトは xhigh とされている。実測した API は none、minimal、low、medium、high、xhigh、max の 7 値を受け付けた。不正な値を渡すと、この allowlist がそのまま示されて拒否される。さらに、provider 固有の thinking_budget と enable_thinking もそのまま渡される。thinking_budget は 262,144 以下の正の整数、enable_thinking は boolean であり、provider 側で検証される。budget に 0 または 262,145 を指定すると、範囲を示す 400 が返る。

通常のタスクでは effort level の違いは見分けられない。単純な Q&A、2-hop 算術、中程度の組合せ問題では、low、medium、high、xhigh、デフォルトのいずれも、ばらつきはあるものの同程度の reasoning token を消費し、差は出なかった。違いが表れたのは、数万 token の思考を必要とするタスクだけだ。制限なしでは reasoning token を 45,129 消費した素数カウント問題で、初めて各 level の上限が効いた。

すべての観測結果に合う理解は、各 effort level が思考 budget のプリセット上限であり、7 つの名前が 4 種類の挙動に集約されるというものだ。オフが 1 種類で、none と enable_thinking: false は同じ挙動をする。Minimal と low は上限 4,096 token を共有する。Medium はその 4 倍の 16,384 だ。High、xhigh、max、デフォルトが 4 段階目を構成する。このタスクではどれも上限に達せず、実行ごとに 35K から 45K token を消費した。この深さでは通常のばらつきだ。上位 3 段階に違いがあるとしても、その境界は思考 token 45K より上にあり、大半の本番 traffic が到達しない領域だ。デフォルトが xhigh というドキュメントの記述は、今回の全測定結果と矛盾しない。差は明確だった。上限に達した実行はすべて不正解で、上限に達しなかった実行はすべて正解した。上限未満では各 level の挙動が同じなので、日常的な traffic では dial が機能していないように見える。上限を超えると、タスク途中で思考が打ち切られる。特定の上限が必要なら preset は使わず、thinking_budget を直接指定すればよい。次の節で、この parameter の挙動を詳しく見る。

thinking_budget は実際にどう動くのか？

thinking_budget は token 単位で厳密に適用される。quota ではなく上限であり、中程度の上限を設定すると、上限なしより高くつく場合がある。thinking_budget は DashScope 固有の整数 parameter であり、1 から 262,144 までを指定できる。ドキュメント上のデフォルトは 131,072 で、open-weight の Qwen3 family から引き継がれている。0 または 262,145 を指定すると、許容範囲を示す 400 で拒否される。上限に達しなければ挙動は変わらない。自然に数百 token しか考えないタスクへ 8,192 の budget を指定すると、消費量は 331 と 485 で、budget 未指定時と同じだった。上限に達する場合は token 単位で厳密に止まる。16、64、256 の budget は、すべての実行でそれぞれ正確に 16、64、256 token で reasoning を終了した。

興味深いのは、上限に達した後の挙動だ。モデルは処理を諦めるのではない。reasoning を止め、ユーザーに見える回答内で作業を続ける。中程度の組合せ問題である 2x12 grid の domino tiling 数を求めるタスクでは、どの budget でも正解した。しかし、合計 token は直感どおりにならなかった。

この曲線は単調ではない。256-token budget は、budget 未指定時の 2.5 倍の token を消費した。モデルは割り当てられた token で reasoning chain を開始し、途中で打ち切られた後、visible channel で答えを順に導出し直した。最も小さい budget が中程度の budget より良かったのは、16 token では何かを始めるにも足りず、モデルが最初から簡潔な visible work に進むためだ。ここから 3 つのルールが得られる。第 1 に、小さな budget は浅いタスクから中程度のタスクで有効な調整手段になる。2-hop 算術 batch では 16 token が 6/6 を達成し、合計 token は 98-161 だった。デフォルトは 126-207 だ。第 2 に、深さが不明な traffic へ中程度の上限を設定してはいけない。実際の reasoning を途中で切る領域に入り、同じ作業へ二重に支払うことになる。前節の高難度タスクにおける 4,096 と 16,384 の行は、この失敗が大規模に起きた例であり、回答も不正解だった。第 3 に、budget が上限に達すると出力形式も変わる。上限に達した実行では途中の作業が回答に表示されるため、結果だけを想定する parser では問題になる。

リリース初日のドキュメントは実測にどこまで耐えたか？

正しかったのは約半分だ。このリリースには、現時点で他に独立検証できる材料がないため、相違点を公開する意味がある。以下の数値はすべて、独自の meter と probe で測定した。

課金に関わる部分は正確だ。支払額を決める項目はすべて明確に適用される一方、parameter のドキュメントは実際の API に追いついていない。

思考をオフにすると安くなるのか？

token は減るが、正解率も落ちる。わずか 2 行違う設定に、より良い選択肢がある。引用可能な 2-hop 算術 batch では、1850 個の crate に各 24 個の部品があり、75% を発送して 3,120 個が到着するという問題を使った。デフォルト設定は 4/4 で正解し、call あたり 126-207 completion token を消費した。reasoning_effort: "none" では回答が 4-5 token になり、正解率は 1/6 だった。同じ prompt へ thinking_budget: 16 を指定すると、completion token は 98-161 で 6/6 を達成した。このタスク分類ではデフォルトより安く、精度も保てた。1-hop 算術は none でも 3/3 だったため、検索や 1 段階の変換ならオフにしても安全だ。破綻するのは複数 step の処理である。これは 3.8 の regression ではない。qwen3.7-max も思考オフでは同じ batch で 3/6 だった。

budget の節で説明した不利な領域は、高難度タスクでは実際の金額に表れる。高難度の素数カウントでは、low preset が 4,096 thinking token を使い切り、visible channel で候補確認にさらに 13,882 token を消費した。それでも不正解で、誤答に $0.11 かかった。対してデフォルトは $0.27 で正解した。高難度タスクで思考を完全にオフにしても同じ現象が起きる。3.8 と 3.7 はどちらも、visible answer 内で 13-15K token を使って列挙した。各 1 回の実行で、一方は正しい数に到達し、もう一方は素数 1 個分だけ外した。reasoning の途中で budget に達すると、品質が下がる一方で総支出が増える可能性がある。浅いと分かっているタスクだけ思考に上限を設け、高難度タスクには必要なだけ考えさせるべきだ。

1M-token のコンテキストウィンドウは本物か？

実質的には本物で、上限も正確かつ明示的だ。API が受け付ける入力 token の上限は、思考オフで 991,808、思考オンで 983,616 だ。どちらも超過時には明示的に失敗する。大きすぎる request は document を暗黙に切り詰めず、正確な上限を示す 400 で拒否される。161K、677K、919K token の各サイズで needle recall を試したところ、11 秒から 63 秒で埋め込んだ override code をそのまま返した。919K-token request は定価で約 $1.84 かかる。ウィンドウは実在するが、最大まで使う call は明示的な設計判断であり、デフォルトにすべきではない。

暗黙的 cache の性能と最小サイズは？

これまで測定した中で最速の cache 構築だが、最小サイズはかなり大きい。salt を付けた 6,103-token prompt を繰り返すと、わずか 0.3 秒後の次の request で hit した。Gemini では構築に数十秒かかるが、こちらでは warm-up 時間を考慮した設計は不要だ。再 priming なしで +5 分と +15 分後にも hit し、+45 分では entry が消えていた。無通信時の実用的な保持時間は 15 分から 45 分の間だ。読み取り料金は 100 万 token あたり $0.25 で、入力料金の 0.125x となる。書き込み割増はない。割引は自動的に cached_tokens field と計測料金へ反映された。

問題は最小サイズだ。4,221-token prompt は一度も hit せず、4,360-token prompt は hit した。最初の hit はすべて正確に 4,096 token だった。prompt が約 4.3K token 未満なら、この cache は利用できない。Claude の最小 1,024 tokenや、Kimi K3 の小 block 単位の自動 cachingとは大きく異なる。最小サイズを超えると hit は 128-token block 単位になる。実測値は 4,096、8,320、12,544、16,768 だった。ただし、priming した prefix のうち cache された割合は 51% から 96% だった。長い prefix は大半が割引されると見込めるが、全体が対象になるとは限らない。

Structured output と tool call にも reasoning の費用はかかるか？

デフォルトではかかる。しかも、ここは reasoning を削るのに最も安全な領域だ。strict な json_schema output は動作し、実際に形式を強制する。同じ抽出を schema なしで実行すると、markdown fence で囲まれた結果が返った。デフォルト設定で 4 field の invoice 抽出を行うと、57 token の JSON を出力する前に 252 reasoning token を消費した。reasoning_effort: "none" では、合計 54 token で有効かつ正しい JSON を出力し、token 数は 5.7 分の 1 になった。thinking_budget: 16 はその中間だった。Tool 選択も同じ傾向を示した。思考オフでも正しい function を呼び出し、消費 token はデフォルトの 3 分の 1 だった。1 step の抽出や routing は、思考オフが安全に使える典型的な処理だ。出力料金が $6/1M なので、継続すれば差は積み上がる。

Agent 開発者向けに、もう 1 点課金上の注意がある。API は chain of thought 全体を reasoning_content として返し、ドキュメントでは multi-turn client に対して変更せず送り返すよう指示している。しかし、この要件は強制されない。reasoning を含めた場合、省略した場合、意図的に改変した場合を試したが、3 通りとも受理され、短い chain では精度にも影響しなかった。再送した reasoning は通常の入力 token として課金される。品質上の必要性が確認されるまでは、multi-turn traffic で省略すれば実際にコストを削減できる。

Qwen 3.7 から引き継がれた点と変わった点は？

tokenizer は変わっておらず、token budget をそのまま移行できる。同一の英語、中国語、日本語、code corpus を qwen3.8-max、qwen3.7-max、qwen3.7-plus、qwen3.6-flash、qwen3.5-flash で token 化したところ、すべて同じ数になった。言語別 tokenizer の調査に基づく言語ごとのコスト計画は、そのまま使える。

変わった点は 2 つある。第 1 に、3.8-max には同系モデルにない固定の prompt overhead がある。同じ 1 文字の message が、他の Qwen ではすべて 11 prompt token だったのに対し、3.8-max では 49 token と数えられた。call あたり固定で +38 token が上乗せされる。長い prompt では誤差だが、短い call を高頻度で実行する場合は無視できない割合になる。第 2 に、思考は mode switch ではなく常時利用可能になり、前述の 7 段階 dial と厳密な budget parameter が追加された。3.7 の制御はもっと粗かった。preview 時には 2 種類の料金体系が出回ったため、補足しておく。月額 $6 から $68 で off-peak 時間帯に大幅な割引がある Token Plan subscription は、Alibaba 自身の app 向けであり、API には適用されない。API の料金は定価の $2/$6 であり、今回の全 call で gateway meter と小数第 4 位まで一致した。

FAQ

Qwen 3.8 Max の思考はオフにできるか？

完全にオフにできる。reasoning_effort: "none" または enable_thinking: false を指定すると、reasoning token はまったく発生しない。ただし、使用は 1-hop の処理に限定すべきだ。2-hop 算術 batch では正解率が 1/6 だった一方、16-token の thinking_budget は同程度以下の token 数で 6/6 を達成した。複数 step の traffic では思考オフではなく、小さな budget を最低設定にすべきだ。

Qwen 3.8 Max の cache に必要な最小 prompt サイズは？

実測では約 4,300 token だ。4,221-token prompt は一度も hit せず、4,360-token prompt は hit した。最初の hit は常に正確に 4,096 token だった。最小サイズ未満では割引されない。最小サイズを超えると、読み取り料金は $0.25/1M で書き込み割増はなく、priming から 0.3 秒後には entry を読み取れる。

Qwen 3.8 Max は reasoning_effort に対応しているか？

none、minimal、low、medium、high、xhigh、max の 7 値を受け付ける。ただし、各 level は思考 budget の上限として動作し、タスクの思考量がその上限を超えた場合にだけ差が出る。決定論的に制御するなら、thinking_budget を直接指定すればよい。token 単位で厳密に適用され、0 は拒否され、上限は 262,144 だ。存在する tier については、client tooling 間で現時点でも見解が一致していない。上記はリリース初日に API が実際に受け付けた値である。

Multi-turn 会話では reasoning_content を送り返す必要があるか？

ドキュメントでは必要とされているが、API は検証しない。probe では reasoning history を省略した場合も、改変した場合さえも error なく受理され、短い chain の精度も落ちなかった。再送した reasoning は通常の入力として課金される。長い chain で品質低下がないことを独自の eval で確認できるまでは、再送を省くことも有効なコスト削減策になる。

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（各条件 n=4-6、salt 付き）、2-3 秒間隔の salt 付き cache pair と時間差 ladder、161K-919K token での needle および overflow probe、同一の 4 corpus に対する tokenizer 数を計測した。金額は定価（1M あたり $2/$6）に基づく gateway meter の課金額である。Preview 期間の割引、料金、挙動は変わる可能性があるため、自身の利用記録でも確認してほしい。

← ブログに戻る