思考模型使用实录：GLM-5.3 的 reasoning token 坑

> 《LLM 工程实录》系列五 · 第 1 篇。一次教科书级踩坑，替你把学费交了。

核心要点

• 思考 token 计入输出预算：max_tokens 不只管正文，思考过程先吃配额，吃光就吐空串。
• 思考内容照常计费：按输出单价算钱，轻量任务的成本大头往往是“思考”而不是答案。
• 实测数据：单次 slug 生成输出近 1 万 token，正文只占几十个。
• 分工原则：判断推理类上思考模型，轻量生成类用普通模型，别赌运气。

一、翻车现场：max_tokens=60，返回一个空串

凌晨一点，文章自动发布的流水线红了。slug 生成接口返回空串，两百篇文章全部卡死。

我盯着日志看了十分钟：请求没报错，状态码 200，但 content 是空的。出事故的永远是在半夜接盘排查的你。

到底哪里出的问题？我把 GLM-5.3 的原始响应打出来，傻眼了：

{
"content": "",
"reasoning_content": "……（几千 token 的思考过程）",
"finish_reason": "length"
}

思考模型把“动脑”也算输出。reasoning_content 和 content 共享同一个 max_tokens 池子，我给的 60 token，思考过程两口就吞完了，正文一个字没剩。

这是硬伤级的认知盲区：你以为 max_tokens 限制的是答案长度，实际上它限制的是“思考 + 答案”的总长。

二、实测：一次生成到底吃多少 token

改到 max_tokens=4096 重跑，还是偶发空串。

再放大。我写了个统计脚本跑了一百次，结论很难看：思考模型的单次输出在几千到近 1 万 token 之间波动，而正文永远只有几十个。

给多少才安全？我的经验值：输出预算至少 16k 起步，给思考留足空间。想靠压 max_tokens 省成本属于突击套利，省下的配额不够一次线上事故赔的。

顺带一提，GLM 新接口里可以用 thinking 参数关掉思考，slug 这种任务关掉立刻清爽。但更彻底的解法在下面。

三、成本账：思考内容才是隐形大户

reasoning token 免费吗？不免费，而且按输出单价计费——通常比输入价贵一个量级。

算笔账：同一个 slug，普通模型 50 token 输出搞定；思考模型烧掉近 1 万 token 输出配额，其中 99% 是思考。单次成本差出上百倍，跑批量一上来就是真金白银。

被坑惨了之后我定了个规矩：跑批任务必须先小流量实测 token 分布，看思考占比多少再决定上不上思考模型。躺赚是不存在的，不看账单的“省成本”都是自我感动。

四、分工：动脑的和动手的分开招

说人话版本的分工表：

• 判断类任务上思考模型：内容审核、复杂分类打标、意图路由、代码 bug 定位、多步骤推理。思考过程真能换回准确率。
• 生成类任务用普通模型：slug、标题改写、摘要、翻译、格式转换。这些任务“想”不出花来，快和便宜才是王道。
• 混合流水线最香：难的判断交给思考模型出结论，简单的执行丢给便宜模型批量跑。贵的动脑，便宜的动手。

判断标准就一条：这个任务需不需要推理链？不需要，思考模型就是杀鸡用牛刀，还动不动翻车。

对了，调这类接口我有个习惯动作：把原始响应丢进本站的 JSON格式化 里展开，content、reasoning_content、finish_reason 一眼扫清，比在终端里人肉数括号舒服多了。

FAQ / 常见问题

思考模型的 max_tokens 只限制正文？

错。思考 token 和正文共享同一个输出预算，思考先吃、吃光正文就没——空串的元凶基本就是它。

思考过程不占成本？

占，而且按输出单价计费。轻量任务里思考能吃掉 99% 的输出成本，账单刺客本客。

返回空串就是模型坏了？

大概率不是。先看 finish_reason 是不是 length，是的话就是预算被思考吞了，加预算或者关思考就能救。