GLM 5.2 Reasoning Effort：实测成本降低 20 倍的关键设置

GLM 5.2 现已接入 Synthorai，每 token 价格约为前沿模型的六分之一。它采用开放权重，基准成绩也确实达到了前沿水平。但只看每 token 价格会得出错误结论。GLM 5.2 完成一项编程任务的实际成本，可能因为一个参数相差十倍以上：reasoning effort。偏偏默认值把这个参数设在了最糟糕的位置。设置得当时，无论任务简单还是困难，GLM 5.2 都能正确完成，而且比前沿模型便宜。使用默认值时，同一个答案的成本会高出 20 倍，还要等上几分钟。以下是我们的实测结果。

TL;DR

• Synthorai 上的 GLM 5.2 输入价格为 $1.40/M，输出价格为 $4.40/M，后者约为 claude-opus-4-8 输出价格的六分之一。
• 对于简单的编程任务，关闭 thinking 后，GLM 5.2 在 5 秒内完成，成本为 $0.0008；使用不设上限的默认值时，生成相同答案需要 $0.0285 和 137 秒。
• 对于困难任务，reasoning_effort: high 能正确完成，成本为 $0.0031，耗时 13 秒。与不设上限的默认值相比，成本约低 20 倍，速度约快 30 倍（$0.062、405 秒）。
• 在两项任务中，GLM 的 low effort 都比 high 生成了更多 reasoning token：effort 名称与 token 数量并不对应。

GLM 5.2 是什么

GLM 5.2 是 Zhipu 于 2026-06-13 发布的开放权重前沿模型。它采用混合专家网络，总参数约 744B，激活参数约 40B；可实际使用的上下文长度为 1M token，并采用 MIT 许可证，支持自行部署。该模型主要面向编程和智能体任务，官方公布的基准成绩很强：SWE-bench Pro 62.1、Terminal-Bench 2.1 81.0、AIME 2026 99.2、GPQA Diamond 91.2。在 Synthorai 上，其模型 ID 为 glm-5.2，每百万输入 token 的价格是 $1.40，每百万输出 token 是 $4.40。

理解后续内容的关键在于：它是一个推理模型，而推理量由你设置。

它的价格处于什么水平

按标价看，GLM 5.2 的每 token 价格远低于欧美前沿模型，在中国模型中也属于较便宜的一档。以下是 Synthorai 上一组代表性模型的价格：

其输出价格 $4.40 约为 gpt-5.5 的七分之一、claude-opus-4-8 的六分之一，不过 deepseek-v4-pro 和 kimi-k2.5 还要更便宜。因此，GLM 5.2 提供的是接近中国模型价位的前沿能力，并不是市场最低价。它没有单独的缓存写入费用：写入缓存按输入价格计费，只有读取缓存时才按上表的折扣价计费。不同供应商的折扣幅度不同。GLM 5.2 的缓存读取价格约为输入价格的五分之一；前沿模型（gpt-5.5、claude-opus-4-8、gemini-3.1-pro）则约为十分之一。

相比前几代产品，它的价格也明显提高。上一代 GLM 价格极低；GLM 5 系列开始涨价，GLM 5.2 的输入价格约为 GLM-4.6 的 3 倍（数据来自 Zhipu 官方价格）：

价格上涨换来了 1M 上下文和前沿水平的基准成绩。但每 token 价格只是表面数字。每项任务实际要花多少钱，取决于 reasoning effort。

reasoning-effort 调节项

GLM 5.2 的推理配置不是简单的开关，而是一个可调参数。你可以关闭推理（enable_thinking: false），将 reasoning_effort 设为 low、medium 或 high，也可以沿用默认值，让推理不设上限。相比模型价格，这项设置对成本和延迟的影响大得多。我们分别选择了一道简单和一道困难的编程题，在不同设置下运行，并用数百组随机用例对照参考实现验证每个答案。

简单任务：推理只会增加成本

加权区间调度，一道中等难度的动态规划题：

这里有两个明显结论。关闭 thinking 后，答案正确，而且是表中成本最低的方案，约为前沿模型的八分之一。继续调高 reasoning effort，只是在相同答案上增加成本。账单主要取决于推理过程，而不是最终答案：GLM 每次返回的代码都在 150 token 左右，但此前的推理量从 0 增加到约 6,300 token，并且同样按 $4.40/M 的输出价格计费。不设上限的默认值花费大量 token 推理，最后得到的答案却与关闭 thinking 时相同；所有成本差距都来自这段推理。前沿模型在这里几乎没有报告推理用量：gpt-5.5 使用了 59 个 reasoning token，claude-opus-4-8 的 usage 则没有记录 reasoning token。

困难任务：推理有用，但默认值没必要

通配符字符串匹配（? 和 *）是一道经典题，很容易在细节上出错。关闭 thinking 后，模型失败了。它返回了一份带记忆化的递归实现：

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

这段代码看起来没问题，甚至用了 memo，说明模型考虑过性能。但 * 分支在调用 match(i + 1, j) 时没有限制 i。字符串耗尽后，如果 pattern 中仍有 *，i 会不断增大，最终导致栈溢出。它又快又便宜，但答案是错的。

提高 reasoning effort 后，模型返回了正确的双指针迭代算法。该算法不会递归，而是回溯到上一个 *：

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

以下是这道题在所有设置下的结果：

所有显式设置的 effort 级别都解出了这道题。reasoning_effort: high 的成本为 $0.0031，耗时 13 秒。答案相同的情况下，它比不设上限的默认值便宜约 20 倍，速度约快 30 倍；成本也低于前沿模型，只慢了几秒。有个反常现象需要留意：在两项任务中，GLM 的 low 都比 high 生成了更多 reasoning token，因此这些名称并不对应 token 数量。medium 和 high 反而是便宜又快的设置。

应该避免的只有不设上限的默认值。它既会为任务可能不需要的推理付费，又要花几分钟才能完成，最后给出的答案却和 reasoning_effort: high 一样，成本则高出 20 倍。

如何选择

真正需要调整的是 reasoning effort，具体设置取决于任务，而不是模型：

• 简单或高吞吐量的任务，且正确性容易判断：关闭 thinking（enable_thinking: false）。答案正确，成本约为前沿模型的八分之一。
• 较难的任务，关闭 thinking 会失败：使用 reasoning_effort: medium 或 high。答案正确，每项任务约 $0.003，成本低于前沿模型，只慢几秒。
• 不要使用不设上限的默认值。 不给 reasoning 设置 effort 上限，会让一个 $0.003 的答案变成耗时 7 分钟、成本 $0.06 的调用。

如果无法提前判断任务是否需要推理，reasoning_effort: high 是比较稳妥的默认选择：它成本低，能解决这两项任务，也没有出现推理失控。

缓存只能降低输入成本，无法减少推理成本

GLM 5.2 支持网关缓存，效果符合预期。我们使用一个 1,494 token 的共享前缀（一份待审查的代码模块），搭配几个不同问题发起请求：

大段前缀使用过一次后便会进入缓存。缓存输入 token 的计费约为正常输入价格的五分之一，让内容基本相同的请求从 $0.0026 降到 $0.0009，降幅约 64%。完全相同的重复请求会直接由语义缓存返回：成本与普通缓存调用相同，但响应时间从约 5 秒缩短到约 1 秒。

限制仍然来自 reasoning effort。缓存只降低输入成本。一旦开启推理，主要成本和延迟都来自 reasoning 输出，而这部分无法缓存。因此，对关闭 thinking 且上下文较长的任务来说，缓存收益明显，例如每次请求都带相同的 system prompt 或代码库。开启推理后，缓存带来的收益就很小。

在 Synthorai 上使用

glm-5.2 已在网关上线。根据我们的测试，实际使用时要注意三点：

• 明确设置 reasoning effort。 简单任务使用 enable_thinking: false，困难任务使用 reasoning_effort: medium 或 high。不要在开启推理时省略 effort 上限，也就是使用不设上限的默认值，否则可能掉进耗时 7 分钟、成本 $0.06 的坑。
• 开启推理时使用 streaming。 推理响应可能持续几分钟。非 streaming 请求会让连接长时间没有返回内容，客户端很可能在答案生成前就超时。使用 stream: true 可以持续接收增量输出，并获得完整结果。
• 复用上下文。 如果每次调用都会发送相同的大段 system prompt 或代码库，前缀缓存可以降低输入成本。再配合关闭 thinking，整个请求会非常便宜。

价格为每百万 token 输入 $1.40、输出 $4.40。网关会在每次调用的响应中返回 cost 字段，便于准确查看该请求的费用。

结论

GLM 5.2 确实是一款便宜且能力出色的编程模型。配置得当时，无论简单还是困难任务，其成本都低于前沿模型。问题在于配置。它的 reasoning 是一个可调参数，而默认值不设上限，结果就是本应只花 $0.003 的任务，变成一次耗时 7 分钟、成本 $0.06 的调用。简单任务设置 enable_thinking: false，其余任务使用 reasoning_effort: medium 或 high，GLM 5.2 就能在各类任务中兼顾低成本和正确性。如果沿用默认 reasoning 设置，它反而会成为最慢、最贵的选择。

资料来源

• VentureBeat：Z.ai 的开放权重 GLM-5.2 以六分之一的成本，在长周期编程任务上超过 GPT-5.5
• eigent.ai：GLM-5.2 规格与概览
• CloudPrice：GLM-5.2 价格与规格
• Z.ai：GLM API 官方价格（GLM-4.5 / 4.6 / 5 系列）

本系列其他实测成本指南：7 种 ASR 模型的音频转写成本和图像生成成本。

（上述 Synthorai 标价为该平台截至 2026-06-24 的价格；各代 GLM 的价格来自 Zhipu 官方价目表。）

成本于 2026-06-24 在 Synthorai 上实测（glm-5.2 每 M token 输入 $1.40、输出 $4.40）；请在据此决策前核实最新价格。

← 返回博客