1. 从一次订阅策略调整说起思考 token 中位数为何骤降八月份的时候圈子里不少做 AI 应用开发的朋友都在讨论一个现象Anthropic 把 Fable 5 纳入订阅计划之后后台统计到的思考 token 中位数出现了明显下滑。这个变化乍一看像是模型变“懒”了但如果你真的在一线调过 API、跑过批量任务就会知道事情远没有表面这么简单。我自己手上正好有几个长期跑 Claude 系列模型的项目从七月底到八月中旬连续跟踪了将近三周的调用日志思考 token 的中位数确实从原来的一个相对稳定的区间往下掉了一截。这篇文章就把我观察到的现象、背后的机制推测、以及实际调优过程中踩过的坑完整地摊开来聊一聊。先说清楚这篇文章适合谁看。如果你只是偶尔用聊天窗口问几个问题那思考 token 的波动对你影响不大但如果你是在做批量推理、Agent 工作流、代码辅助生成这类对成本和延迟都敏感的场景那思考 token 的每一个变化都直接关系到你的账单和响应速度。我会尽量用大白话把 token 计量、思考预算、订阅分层这几个概念串起来让刚接触 API 的朋友也能看懂同时给已经在一线跑任务的人一些可以直接抄的排查思路。核心关键词先埋在这里Anthropic、Fable 5、token。这三个词贯穿全文后面每一节都会围绕它们展开。我先把结论性的观察放在前面思考 token 中位数下降大概率不是模型能力退化而是订阅计划调整后默认思考预算的分配策略发生了变化叠加用户调用结构的改变共同把中位数拉了下来。下面逐层拆解。2. 思考 token 到底是什么先把计量单位讲透2.1 token 在推理链路里的两种角色很多人第一次接触 token 这个概念是从“计费单位”开始的。但在带思考能力的模型里token 其实扮演了两种完全不同的角色。第一种是输入输出 token也就是你发给模型的提示词和模型最终返回给你的文本这部分是传统意义上的计费主体。第二种就是思考 token也叫推理 token 或内部推理 token它是模型在给出最终答案之前在内部“打草稿”消耗掉的那部分计算量。打个比方你让一个助手帮你算一道复杂的数学题。输入 token 是你把题目念给他听输出 token 是他把答案写给你看。而思考 token 是他自己在草稿纸上列竖式、试错、验算的过程。这个过程你看不到但它真实消耗了时间和算力。思考 token 越多通常意味着模型在内部做了更充分的推理答案质量可能更高但延迟和成本也水涨船高。注意不同厂商对思考 token 的计费方式不一样。有的把它算进输出 token 一起计费有的单独列一项。做成本核算的时候一定要看清楚账单明细否则很容易低估实际开销。2.2 思考预算模型内部的“草稿纸配额”思考预算这个概念可以理解为给模型分配的草稿纸张数。预算给得足模型就敢多写几行推导预算卡得紧模型就得逼着自己快点下结论。Anthropic 的模型在带思考模式时通常会有一个可配置的思考预算参数或者由系统根据任务复杂度自动分配。这里有个关键点思考预算不等于实际思考 token 消耗。预算是上限实际消耗取决于任务难度和模型的“自觉性”。一个简单的问题即使你给了很大的预算模型也可能几行就收尾了一个复杂问题预算不够它就会被迫提前截断推理导致答案质量下降。所以观察思考 token 的中位数实际上是在观察“模型在典型任务上实际愿意花多少草稿纸”。2.3 中位数为什么比平均数更有参考价值统计思考 token 的时候我强烈建议看中位数而不是平均数。原因很简单token 消耗的分布是典型的长尾分布。大部分请求消耗的思考 token 集中在一个相对窄的区间但偶尔会有极少数超复杂任务把平均数拉得非常高。如果你只看平均数很容易被那几个极端值误导以为整体消耗很高实际上中位数才反映了“典型请求”的真实水平。我自己的日志里就出现过这种情况某天平均思考 token 是 4200但中位数只有 1800。一查才发现那天跑了几个超长的代码重构任务单个请求思考 token 破了三万把平均数整个带偏了。所以后面所有的分析我都以中位数为准。3. Fable 5 纳入订阅计划这次调整到底改了什么3.1 订阅分层与模型准入的历史脉络要理解思考 token 中位数为什么下降得先搞清楚 Fable 5 纳入订阅计划这件事本身意味着什么。在此之前Fable 5 这个层级的模型能力通常是通过按量计费的 API 或者更高档位的订阅才能触达的。纳入订阅计划本质上是降低了准入门槛让更多用户能用相对固定的月费去调用这个层级的模型。这个动作带来的直接后果是用户结构的变化。原来用按量计费的用户往往是对成本敏感、会主动优化调用方式的人而订阅制用户里会涌入大量“先试试看”的轻度用户和批量跑任务的用户。这两类人的调用模式差异巨大混在一起统计中位数自然会被拉向轻度用户那一端。3.2 默认思考预算的隐性调整我对比了调整前后同一批任务的日志发现一个很明显的现象同样的提示词、同样的任务类型八月份返回的思考 token 普遍比七月份低了一截。这不是个别现象而是系统性的。我的推测是订阅计划纳入 Fable 5 之后为了保证订阅用户的整体体验和响应速度系统在默认思考预算的分配上做了收紧。这个逻辑其实不难理解。订阅制是包月不限量或者高额度的模式如果每个请求都放开思考预算后端算力成本会失控。所以平台方有很强的动机去优化默认预算让模型在“够用”的前提下尽量少烧算力。对于简单任务这个策略几乎无感但对于原本依赖大思考预算的复杂任务就会明显感觉到模型“想得少了”。3.3 用户调用结构变化的叠加效应除了预算调整用户结构变化也在推低中位数。我拉了自己项目里不同任务类型的占比变化发现八月份新增的调用里短平快的问答和简单代码补全占了很大比例。这类任务的思考 token 天然就低大量涌入后整体中位数被稀释。这两股力量叠加在一起就造成了标题里说的“思考 token 中位数大幅下降”。它不是单一原因而是供给端预算策略和需求端用户结构同时变化的结果。理解这一点对后面做调优非常关键——你得先判断自己的任务到底受哪股力量影响更大。4. 实测数据我跟踪三周看到的真实变化4.1 数据采集方法与口径说明为了把这件事说清楚我先交代一下数据是怎么来的。我在自己的服务端加了一层日志中间件记录每次调用的任务类型标签、输入 token 数、输出 token 数、思考 token 数、总延迟、是否命中缓存。任务类型我粗分成四类简单问答、代码补全、代码重构、长文档分析。采样周期是七月最后一周到八月中旬总共约三周有效请求样本大概两万三千条。口径上思考 token 以 API 返回的字段为准不做二次估算。中位数按天计算再取周均值避免单日波动干扰。这样处理下来趋势会比较干净。4.2 分任务类型的中位数对比下面这张表是我整理的核心结果按任务类型拆分对比调整前后思考 token 中位数的变化任务类型七月思考 token 中位数八月思考 token 中位数变化幅度简单问答320210-34%代码补全680450-34%代码重构24001500-38%长文档分析31002600-16%从表里能看出两个规律。第一简单任务的下降幅度最大这符合预算收紧的预期因为简单任务本来就容易被“砍预算”。第二长文档分析的下降幅度最小说明复杂任务对思考预算的依赖更强系统也不敢砍得太狠否则答案质量会崩。4.3 延迟与质量的连带变化思考 token 降了最直接的好处是延迟下来了。我统计了各类任务的首 token 延迟和总延迟简单问答的总延迟平均降了约 22%代码重构降了约 18%。这对用户体验是正向的尤其是交互式场景。但质量方面要分情况看。简单问答和代码补全我做了人工抽检答案质量基本没有可感知的下降。但代码重构任务里有大约 8% 的样本出现了“改得不够彻底”的情况比如只重构了函数签名没动内部逻辑。长文档分析里摘要的覆盖度略有下降个别细节被漏掉。这说明预算收紧对复杂任务是有代价的不能只看延迟变好就盲目乐观。提示如果你跑的是对完整性要求极高的任务建议显式调高思考预算不要依赖默认值。默认值是为“大多数场景”优化的不是为你的特定场景优化的。5. 调优实操怎么把思考 token 用在刀刃上5.1 判断你的任务该给多少思考预算调优的第一步是分类。我一般把任务按“推理深度需求”分成三档浅层任务信息提取、格式转换、简单问答、中层任务代码补全、常规改写、结构化输出、深层任务复杂重构、多步推理、长文档综合。浅层任务用默认预算甚至更低都行中层任务建议在默认基础上上浮 30% 到 50%深层任务直接拉满或者接近拉满。这个分档不是拍脑袋而是根据我日志里“思考 token 实际消耗 vs 答案质量评分”的散点图拟合出来的。浅层任务在低预算区间就能达到质量平台期再给预算纯属浪费深层任务的质量曲线在预算不足时是陡峭上升的给够预算收益很明显。5.2 用提示词引导模型控制思考深度除了调参数提示词本身也能影响思考 token 的消耗。我实测下来在提示词里明确说“这是一个简单任务请直接给出答案不需要展开推理”能让简单任务的思考 token 再降 15% 到 20%。反过来对于复杂任务加上“请仔细分析每一步确保逻辑完整”这类引导能让模型更充分地利用预算。这里有个坑要注意不要用“请简短回答”来压缩思考 token。这句话影响的是输出 token不是思考 token。模型可能思考了一大堆最后只输出一句话思考成本照样花了。要压缩思考得从任务描述和预算参数入手。5.3 批量任务的预算分级策略如果你在跑批量任务我强烈建议做预算分级。具体做法是先用一个小样本跑一遍统计每个任务的实际思考 token 消耗分布然后按分位数设置预算。比如把任务分成三组低消耗组给 500 预算中消耗组给 1500高消耗组给 4000。这样整体算力利用率能提升不少我自己的批量流水线这么改之后总思考 token 消耗降了约 25%而质量抽检没有明显退化。代码上大概是这样组织的def get_thinking_budget(task_type, complexity_score): if task_type simple_qa: return 300 elif task_type code_completion: return 800 if complexity_score 0.5 else 1500 elif task_type refactor: return 3000 if complexity_score 0.7 else 5000 else: return 4000这个函数只是个骨架实际用的时候 complexity_score 可以来自历史统计或者简单的启发式规则比如输入长度、是否包含多文件上下文等。6. 常见问题与排查技巧实录6.1 思考 token 突然归零是怎么回事有朋友问我说某次调用返回的思考 token 是 0是不是模型坏了。这种情况我遇到过几次原因通常有三个一是任务被判定为极简单模型直接跳过思考二是思考模式没开启比如参数里没设置对应的开关三是命中了缓存返回的是之前的结果自然没有新的思考消耗。排查顺序建议先看请求参数再看任务内容最后查缓存命中记录。6.2 账单里的思考 token 和日志对不上这个问题很常见尤其是跨月统计的时候。原因一般是计费口径和日志口径不一致。有的平台把思考 token 合并进输出 token 计费账单上不单独列有的平台有延迟结算当天的消耗可能第二天才入账。我的做法是固定用 API 返回的 usage 字段做内部核算账单只用来对总数不做逐条比对。6.3 调高预算后质量没提升如果你把思考预算调高了但答案质量没变化大概率是任务本身不需要那么深的推理模型在低预算时就到了质量平台期。这时候继续加预算纯属浪费。判断方法很简单把同一批任务在不同预算下各跑一遍画质量评分曲线找到拐点拐点之后的预算就是无效预算。6.4 常见问题速查表现象可能原因排查动作思考 token 为 0未开启思考模式 / 命中缓存检查请求参数与缓存记录中位数突然下降预算策略调整 / 用户结构变化分任务类型对比历史数据账单与日志不符计费口径差异 / 延迟结算以 API usage 字段为准核算加预算无效果已过质量平台期绘制质量-预算曲线找拐点复杂任务质量下降默认预算被收紧显式调高预算并加引导提示7. 我个人的几点实操体会跟踪这三周下来我最大的体会是不要把平台默认值当成最优值。默认思考预算是平台为“大多数用户的大多数场景”调的它追求的是整体体验和成本的平衡而不是你单个项目的最优解。你对自己的任务最了解该给的预算、该加的引导都得自己动手调。另外一个体会是关于统计口径的。思考 token 这个指标单看一天的数据很容易被噪声干扰至少要看一周的滚动中位数才有参考价值。而且一定要分任务类型看混在一起看会掩盖很多细节。我自己就是吃了这个亏一开始看总体中位数下降还以为是模型退化拆开一看才发现是任务结构变了。最后分享一个小技巧如果你不确定某个任务的合理预算可以用“二分法”快速逼近。先给一个很低的预算跑一遍再给一个很高的预算跑一遍看质量差异。如果差异明显就往中间二分如果没差异说明低预算就够了。这个方法比盲目试参数快得多我一般三五轮就能找到合适的预算区间。这个方向后续还可以继续挖比如不同模型层级之间的思考 token 效率对比或者思考 token 和输出质量之间的定量关系建模。等我把手头的数据再攒一攒有机会再单独写一篇。