Qwen 3.8 Max API 定价：16 个思考 token 胜过关闭思考

Qwen 3.8 Max 的价格是每百万输入 token $2、每百万输出 token $6，但最便宜且可靠的配置，并不是 API 表面上提供的那个。用 reasoning_effort: "none" 关闭思考后，我们的两步算术任务从 4/4 正确跌至 1/6；把思考 token 的硬上限设为 16 后，正确率恢复到 6/6，平均输出 token 还比默认配置少五分之一。发布首周充斥着高调的能力宣称，却几乎没有可供核验的资料：没有模型卡，没有公开 benchmark 表，评测仅限内部，Hacker News 很快就指出了这一点。计费行为不同，任何有 API key 的人都能实测。我们在发布首日通过 Synthorai 网关测了 qwen3.8-max：接口接受的所有思考控制项、各档位的推理成本、隐式缓存的最低门槛和构建延迟、号称 1M 的上下文窗口，以及从 Qwen 3.7 延续下来的特性。

TL;DR

• qwen3.8-max 的 7 个 reasoning_effort 值，实测只有 4 种行为：关闭、上限 4,096 个 token、上限 16,384 个 token，以及不设限。
• thinking_budget 精确到 token：请求 16 个，计量结果就是 16；上限为 262,144。
• 关闭思考后，两步数学题的正确率跌至 1/6；设为 16 个 token 后以更低成本拿到 6/6。
• 隐式缓存可在 0.3 秒内构建完成，读取价格为 $0.25/1M，但 prompt 不到约 4,300 个 token 时不会缓存。
• 输入上限精确且超限直接报错：关闭思考时为 991,808，开启时为 983,616。

Qwen 3.8 Max 的思考控制项到底做了什么？

有 3 个参数实际生效，但并不是文档列出的那 3 个。第三方文档称 reasoning_effort 有 3 个值（low、medium、xhigh，默认为 xhigh）。我们实测的接口接受 7 个值：none、minimal、low、medium、high、xhigh 和 max；传入无效值时，错误信息会原样列出这份允许值清单。此外，原生参数 thinking_budget（正整数，最大 262,144）和 enable_thinking（布尔值）也会透传给供应商，由供应商自行校验：预算设为 0 或 262,145 时，接口会返回 400，并在错误信息中注明边界。

普通任务下，各个 effort 档位没有可辨别的差异。无论是简单问答、两步数学题，还是中等难度的组合数学题，low、medium、high、xhigh 和默认档位消耗的推理 token 都落在同一个波动区间，无法区分。只有在需要持续思考数万个 token 的任务上，差异才会显现。某个素数计数问题在不受限时消耗了 45,129 个推理 token，此时各档位的上限终于开始生效：

能解释全部观测结果的模型是：每个 effort 档位都是预设的思考预算上限，7 个名称实际只对应 4 种行为。关闭是一种（none 和 enable_thinking: false 行为相同）。Minimal 和 low 共用 4,096 个 token 的上限。Medium 将上限提高 4 倍，达到 16,384。High、xhigh、max 和默认值组成第 4 档：在这个任务上都没有触及上限，多次运行消耗 35K 到 45K 个 token，属于这种深度下的正常波动。即使最高 3 档确实有差异，分界线也在 45K 个思考 token 以上，已经超过大多数生产流量会达到的深度；文档所称的默认值为 xhigh，与我们的全部测量结果一致。结果非常明确：所有触及上限的运行都答错了，所有未受限的运行都答对了。未达到上限时，各档位行为相同，所以在日常流量中，这个旋钮看起来像是没有作用。超过上限后，思考会在任务中途被截断。如果需要明确的上限，不要使用预设档位，直接设置 thinking_budget；下一节会详细分析这个参数。

thinking_budget 到底如何工作？

它精确执行到单个 token，是上限而不是配额；设置一个中等大小的上限，成本甚至可能高于完全不设上限。thinking_budget 是 DashScope 的原生整数参数（范围 1 到 262,144，文档默认值 131,072，继承自开放权重的 Qwen3 系列），用于设置单次调用最多可用的推理 token。传入 0 或 262,145 会收到 400，错误信息中会注明有效范围。只要没有触及上限，模型行为就不会变化：某个任务自然只需要几百个思考 token，即使预算设为 8,192，实际也只消耗 331 和 485，与未设置预算完全相同。触及上限时，则会精确到 token 执行：预算为 16、64 和 256 时，每次运行都分别在第 16、64 和 256 个推理 token 处停止。

真正值得关注的是截断后会发生什么。模型不会放弃任务，而是停止隐藏推理，转到可见答案中继续完成工作。在一个中等难度的组合数学任务中（计算 2x12 网格的多米诺骨牌铺法数量），所有预算都得出了正确答案，但总 token 数与直觉并不一致：

这条曲线不是单调的。256 个 token 的预算比不设预算贵 2.5 倍：模型先用完配额启动一条推理链，在中途被截断后，又在可见输出中逐步重新推导答案。最小预算反而优于中等预算，因为 16 个 token 根本不足以展开推理，模型会直接给出简洁的可见计算过程。由此可以得到 3 条规则。第一，小预算确实能降低浅层到中等任务的成本：在我们的两步数学题批次中，16 个 token 的预算取得 6/6，completion token 总数为 98-161；默认配置则为 126-207。第二，不要把中等大小的上限用于深度未知的流量；它们正好落在危险区，会截断已经开始的有效推理，导致同一份工作付费两次（上面的深度任务中，4,096 和 16,384 两行就是同一问题的放大版，而且最终答案也是错的）。第三，触及预算上限会改变输出形态：受限运行会在答案中展示计算过程。如果解析器只接受单独的结果，这一点会造成影响。

首日文档中有多少内容经得起实测？

大约一半。由于这次发布的其他信息目前都无法独立核验，这个差异值得公开。下表中的每个数字都来自我们的计量和探测：

规律很明显：涉及计费的部分最可靠。所有决定费用的规则都精确且如实执行，但参数文档落后于接口的实际行为。

关闭思考能省钱吗？

能节省 token，但会牺牲正确率，而只需再改两行配置就有更好的取舍。在我们的可复现两步算术批次中（1850 箱，每箱 24 个零件，发出 75% 后又新到 3,120 个零件），默认配置的正确率为 4/4，每次调用消耗 126-207 个 completion token。reasoning_effort: "none" 只输出 4-5 个 token，但正确率降至 1/6。同一 prompt 使用 thinking_budget: 16 后取得 6/6，completion token 为 98-161；对这类任务而言，它比默认配置更便宜，准确率也相当。一步算术即使设为 none 仍能取得 3/3，因此关闭思考适用于查找和单步转换；一旦涉及多步处理，质量就会崩溃。这并不是 3.8 的退步：qwen3.7-max 关闭思考后，在完全相同的批次上也只有 3/6。

在困难任务上，预算章节所述的危险区可以直接换算成费用。在深度素数计数任务中，low 预设先耗尽 4,096 个思考 token，又在可见输出中多写了 13,882 个 token 来逐个检查候选数，最终仍然答错：错误答案花费 $0.11，而默认配置的正确答案花费 $0.27。困难任务上，关闭思考也呈现同样的规律：完全禁用思考后，3.8 和 3.7 都在可见答案中输出了 13-15K 个 token 的枚举过程；各自只运行一次，一个算对了，另一个漏掉了一个素数。预算如果在推理中途生效，可能同时增加总费用并降低质量。已知任务较浅时再限制思考；深度任务则应允许模型充分思考。

1M token 的上下文窗口是真的吗？

实际可用，而且上限精确、透明。关闭思考时，API 最多接受 991,808 个输入 token；开启思考时最多接受 983,616 个。两个边界都采用明确报错的方式执行：请求超限后会返回 400，并注明精确上限，不会悄悄截断文档。在我们测试的所有长度下,「大海捞针」召回全部成功，包括 161K、677K 和 919K 个 token；模型在 11 到 63 秒内原样返回了预埋的覆盖码。按标价计算，一次 919K token 的请求成本约为 $1.84。因此，这个窗口确实存在，但是否使用完整窗口需要明确的架构决策，不应作为默认选择。

隐式缓存效果如何，最低门槛是多少？

这是我们测过构建最快的缓存，但最低门槛异常高。重复发送一个加盐的 6,103 token prompt，紧接着在 0.3 秒后发送下一次请求就能命中；与 Gemini 需要数十秒构建缓存 不同，无需专门处理预热窗口。在 +5 分钟和 +15 分钟时，无需重新写入仍可命中；到了 +45 分钟，缓存条目已经消失。因此，静默状态下的有效期在 15 到 45 分钟之间。读取价格为每百万 token $0.25，是输入价格的 0.125 倍，且没有写入溢价；折扣会自动反映在 cached_tokens 字段和计量费用中。

问题在于最低门槛。4,221 token 的 prompt 从未命中，而 4,360 token 的 prompt 可以命中；每次首次命中都恰好为 4,096 个 token。prompt 低于约 4.3K 个 token 时，缓存对你完全不起作用。这与 Claude 最低 1,024 个 token 以及 Kimi K3 的小块自动缓存形成鲜明对比。超过门槛后，命中量以 128 token 为单位量化（我们观测到 4,096、8,320、12,544 和 16,768），但已预热前缀的覆盖率在 51% 到 96% 之间。因此，成本规划应按长前缀的大部分获得折扣计算，而不是全部。

结构化输出和工具调用也要承担推理成本吗？

默认需要，但这两类任务最适合关闭思考。严格的 json_schema 输出可以正常工作，而且确实会强制约束格式：同样的提取任务不使用 schema 时，返回结果会被包在 Markdown 代码围栏中。使用默认配置提取 4 个发票字段时，模型先消耗了 252 个推理 token，才输出 57 个 JSON token。设置 reasoning_effort: "none" 后，它用 54 个总 token 就生成了合法且正确的 JSON，成本缩减 5.7 倍；thinking_budget: 16 的结果介于两者之间。工具选择也是如此：关闭思考后，模型仍然调用了正确的函数，而 token 消耗只有默认配置的三分之一。单步提取和路由正是适合关闭思考的任务类型；按 $6/1M 的输出价格计算，长期节省会非常可观。

面向 agent 开发者还有一项计费细节：API 会在 reasoning_content 中返回完整思维链，文档要求多轮客户端原样发回。这个要求并未强制执行。我们分别测试了包含推理内容、省略推理内容和故意篡改推理内容的历史记录，3 种请求都被接受，短推理链的准确率也未受影响。回传的推理内容会按普通输入 token 计费。因此，在确认长链任务不会损失质量前，多轮流量中省略这部分内容确实可以节省成本。

Qwen 3.7 的哪些特性延续了下来，哪些发生了变化？

tokenizer 没有变化，现有 token 预算可以直接沿用。相同的英文、中文、日文和代码语料，在 qwen3.8-max、qwen3.7-max、qwen3.7-plus、qwen3.6-flash 和 qwen3.5-flash 上得到的 token 数完全一致。因此，我们在按语言比较 tokenizer 的研究中得出的各语言成本规划结论可以原样沿用。

有两点发生了变化。第一，3.8-max 带有其他同系列模型没有的固定 prompt 开销：同一个仅含 1 个字符的消息，在 3.8-max 上计为 49 个 prompt token，而我们测试的其他所有 Qwen 都是 11 个，即每次调用固定增加 38 个 token。对长 prompt 而言可以忽略，但对于短小、高频的请求，占比会很明显。第二，思考能力始终可用，不再是模式切换，而是通过上述 7 档旋钮和精确预算参数控制；3.7 的控制方式更粗。一项定价说明：预览期间曾流传两套方案。Token Plan 订阅（月费 $6 到 $68，非高峰时段有大幅折扣）适用于 Alibaba 自有应用，不适用于 API。API 按 $2/$6 的标价计费，本次研究中，网关计量结果在每次调用上都精确匹配到小数点后 4 位。

常见问题

Qwen 3.8 Max 可以关闭思考吗？

可以彻底关闭：reasoning_effort: "none"（或 enable_thinking: false）能完全消除推理 token。只应将其用于单步任务。在我们的两步算术批次中，关闭思考的正确率为 1/6，而 16 token 的 thinking_budget 在相近或更低的 token 消耗下取得 6/6。因此，多步流量的最低配置应当是小额预算，而不是直接关闭思考。

Qwen 3.8 Max 缓存要求的最低 prompt 大小是多少？

我们的探测结果约为 4,300 个 token：4,221 token 的 prompt 从未命中，4,360 token 的 prompt 可以命中，而且首次命中始终恰好为 4,096 个 token。低于门槛时没有任何折扣；超过门槛后，读取价格为 $0.25/1M，没有写入溢价，预热后 0.3 秒即可读取缓存条目。

Qwen 3.8 Max 支持 reasoning_effort 吗？

接受 7 个值（none、minimal、low、medium、high、xhigh、max），但各档位本质上是思考预算上限，只有任务的思考量超过相应边界时才会表现出差异。如需确定性控制，直接设置 thinking_budget：它精确执行到单个 token，不接受 0，最大值为 262,144。目前不同客户端工具对可用档位的看法并不一致；以上清单是发布首日接口实际接受的值。

多轮对话必须回传 reasoning_content 吗？

文档称必须回传，但 API 不会检查。在我们的探测中，省略甚至篡改推理历史都不会报错，也没有降低短推理链的准确率；回传的推理内容则按普通输入计费。在你自己的评测证明长链任务存在质量损失之前，不回传是合理的降本手段。

测量时间为 2026-08-03，通过 Synthorai 网关测试 qwen3.8-max（对照组使用 qwen3.7-max、qwen3.7-plus、qwen3.6-flash、qwen3.5-flash）：测试内容包括档位接受情况、无效值和 max_tokens 边界探测；使用自然消耗 45K token 的深度任务触发 effort 上限；用固定、可复现的加盐批次测量准确率断崖（每组 n=4-6）；以 2-3 秒节奏发送加盐缓存请求对，并逐步拉长间隔；在 161K-919K token 下进行「大海捞针」召回和超窗溢出探测；以及对 4 组相同语料进行 tokenizer 计数。金额来自网关按标价（每 1M token $2/$6）记录的实际计费数据。预览期的折扣、费率和行为可能变化；请结合自己的使用记录核验。

← 返回博客