GLM 5.2：reasoning effort 才是成本的总开关

GLM 5.2 已经上线 Synthorai，单 token 价格大约只有前沿模型的六分之一，「开放权重 + 前沿跑分」这个卖点也确实站得住脚。但单 token 价格其实是个会误导人的参考值。GLM 5.2 上一个编码任务到底花多少钱，会因为一个旋钮——reasoning effort——而出现一个数量级以上的波动，而它的默认值恰恰把这个旋钮拨到了最糟糕的位置。调好了，GLM 5.2 在简单任务和困难任务上都能做对，而且比前沿模型更便宜。用默认值，同样的答案会贵上二十倍，还要等上好几分钟。这些我们都实测过。

GLM 5.2 是什么

GLM 5.2 是智谱的开放权重前沿模型，2026-06-13 发布：一个 mixture-of-experts 架构（总参数约 744B，激活约 40B），可用的 1M-token 上下文，加上一份允许自部署的 MIT 许可证。它面向编码和 agentic 场景，公布的跑分相当强（SWE-bench Pro 62.1、Terminal-Bench 2.1 81.0、AIME 2026 99.2、GPQA Diamond 91.2）。在 Synthorai 上它叫 glm-5.2，定价为输入每百万 token 1.40 美元、输出每百万 token 4.40 美元。

下面所有内容的关键就在一点：它是一个推理模型，而它推理多少，由你来设定。

价格上它处在什么位置

按单 token 标价看，GLM 5.2 明显低于西方前沿模型，处在偏便宜的国产模型这一档。下面是 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 倍（以下为智谱官方价格）：

这个价格换来的是 1M 上下文和那一串前沿跑分。但单 token 价格只是表面文章，每个任务你实际付多少钱，是由 reasoning effort 决定的。

reasoning-effort 旋钮

GLM 5.2 的推理是个旋钮，不是开关。你可以把它关掉（enable_thinking: false），把 reasoning_effort 设成 low、medium 或 high，也可以保持默认值——让推理无上限地跑。这个设置对成本和延迟的影响，远比价格本身大得多。我们拿一个简单编码任务和一个困难编码任务，跑遍了各档设置，并在数百个随机化用例上拿每个答案对照参考答案做了校验。

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

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

有两点很明显。关闭 thinking 后答案正确，而且是全场最便宜的，比顶尖模型还低约 8 倍；往上调任何一档都只是花更多钱换来同一个答案。账单跟的是推理，而不是答案：GLM 每次返回的代码都在 150 token 左右，但前面的推理却从零一路涨到约 6,300，按同样的 $4.40/M 输出价计费。无上限默认值花掉这些推理，最后得到的答案跟关闭 thinking、零推理时算出来的一模一样，这中间的差距正好就是全部的成本差。顶尖模型在这道题上几乎不需要报告推理就能作答：gpt-5.5 花了 59 个推理 token，claude-opus-4-8 的用量报告里则是零。

一个难题：推理模式物有所值，默认模式则不然

通配符字符串匹配（? 和 *），这是个经典问题，稍不留神就会在细节上出错。关闭 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)

乍一看是对的，记忆化也显得颇为讲究。但 * 那个分支在递归 match(i + 1, j) 时没有给 i 设上界。一旦字符串已经消耗完，模式里还剩 *，i 就会无限增长，最终栈溢出。快、便宜，但是错的。

把档位调高，它就返回了正确的迭代式双指针算法，遇到不匹配时回退到上一个 *，而不是递归：

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 还多，两个任务上都是如此，所以档位名称跟 token 数量并不对应。medium 和 high 才是又便宜又快的设置。

无上限默认是唯一应该避开的设置。它集两头之短于一身：既为任务买了可能用不上的推理，又花上好几分钟，最后给出的答案跟 reasoning_effort: high 一样，成本却高 20 倍。

决策规则

可调的杠杆是 reasoning effort，正确的设置取决于任务本身，而不是模型：

• 简单或高并发的任务，正确性容易保证：关闭 thinking（enable_thinking: false）。结果正确，成本约为前沿模型的八分之一。
• 更难的问题，关闭 thinking 会失败：用 reasoning_effort: medium 或 high。结果正确，每个任务约 $0.003，成本低于前沿模型，只慢几秒。
• 永远别用无上限默认。 开着推理又不设 effort 上限，本来 $0.003 的答案就会变成 $0.06、耗时七分钟的答案。

如果事先判断不出一个任务到底需不需要推理，reasoning_effort: high 是个稳妥的默认值：便宜、两个任务都解出来了，而且从不失控。

缓存能省输入，省不了推理

GLM 5.2 在网关上支持缓存，效果也在意料之中。我们用一段 1494 token 的共享前缀（一个待审查的代码模块）配上几个不同的问题做了测试：

大段前缀一旦被处理过就会进缓存。缓存的输入 token 计费大约只有正常输入价的五分之一，把一个原本完全相同的请求从 $0.0026 压到了 $0.0009，降幅约 64%。完全重复的请求直接走语义缓存：答案和成本跟命中缓存那次一样，但响应时间从五秒缩短到约一秒。

问题还是那个旋钮教给我们的道理：缓存打折的是输入，而一旦开启推理，成本和延迟就都落在推理输出上，那部分是不缓存的。所以缓存对关闭推理、高上下文的场景（每次调用都带同样的 system prompt 或代码库）是实打实的收益，开了推理之后收益就很有限了。

在 Synthorai 上的用法

glm-5.2 已经在网关上线。基于我们的测试，给三条实用建议：

• 显式设定推理强度。 简单任务用 enable_thinking: false，复杂问题用 reasoning_effort: medium 或 high。唯一要避免的，是开着推理却不设上限（也就是无限制的默认值）——那就是花 $0.06、跑七分钟的坑。
• 开了推理就用 streaming。 推理响应可能跑上好几分钟，非 streaming 请求会让连接长时间没有任何返回，客户端很可能在答案到达之前就超时了。用 stream: true，既能拿到增量输出，也能拿到完整结果。
• 复用上下文。 如果每次调用都带同样的大块 system prompt 或代码库，前缀缓存能砍掉输入成本，再配上关闭推理，整个请求就很便宜。

价格是每百万 token $1.40 / $4.40，网关每次调用都会返回一个 cost 字段，能让你清楚看到每个请求到底花了多少。

结论

GLM 5.2 确实是一个又便宜又能干的编码模型，配置得当的话，无论简单还是复杂任务，价格都能打过前沿模型。问题就出在配置上。它的推理是一个旋钮，而默认状态是不设上限——一个本该花 $0.003 的任务，就是这么变成了 $0.06、七分钟的调用。简单任务设 enable_thinking: false，其余用 reasoning_effort: medium 或 high，GLM 5.2 在各种场景下都又便宜又准。要是放任推理走默认值，它就成了你能选的最慢、最贵的那个选项。

来源

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

（上面列出的 Synthorai 价格是本平台截至 2026-06-24 的费率；GLM 各代费率为智谱官方标价。）

成本数据于 2026-06-24 在 Synthorai 上实测（glm-5.2，每百万 token $1.40 / $4.40）；以此为依据前请先核对当前价格。

← 返回博客