另一种扩展定律
过去几年 LLM 领域最坚定的信仰是 Scaling Law——模型越大、数据越多、训练越久，性能越好。这条路走得很远，也走得很贵。GPT-4 的训练成本据估计超过一亿美元，而到了 2025 年底，业界开始频繁听到一个词：训练的边际收益在下降。
不是 Scaling Law 错了，是它的斜率在变缓。继续加参数、加数据当然还有用，但同样的投入换来的提升越来越小。如果你把训练阶段的算力比作一个学生的学制——从小学到博士——那么这个学生现在已经读到了博士后期，再多读一年，能学到的新东西在指数衰减。
正是在这个背景下，一个不同方向的思路浮出水面：与其在训练时砸更多算力，不如在推理时让模型多想一会儿。
2024 年，一篇后来成为 ICLR 2025 Oral 的论文给了这个方向最清晰的表述：Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Model Parameters——推理时的算力扩展，可以比扩大模型参数更高效。
这不是一个小优化。它在暗示 LLM 的能力提升可以沿着一条全新的轴进行——不是”训一个更大的模型”，而是”让现有模型在每个问题上多花一点时间”。就像同一个学生，面对难题时多草稿纸上演算一会儿，比再多读一年学制更有效。
这个研究方向叫 Test-Time Compute，或者叫 Inference-Time Compute Scaling。
想，然后再说
Test-Time Compute 的核心机制并不复杂。
传统 LLM 推理是”一次出结果”：模型读完 prompt（prefill），直接生成回复（decode）。这个过程里模型没有”想”的余地——它吐出的每个 token 都直接呈现给用户，中间没有草稿纸。
Test-Time Compute 的做法是在最终回复之前，插入一段模型自己生成的推理链——通常叫 thinking tokens 或 reasoning tokens。模型先在内部做一轮推演：拆解问题、尝试路径、检验中间结果、纠正错误，然后再基于这段推理给出最终答案。这段推理链对用户可见或不可见（取决于厂商的设计），但它实实在在地消耗了计算资源——每个 thinking token 都走 decode 阶段，串行生成，按 output 计费。
为什么”多想一会儿”有用？直觉上很好理解：复杂问题的答案往往不在模型权重里直接存着，而是需要通过多步推理才能”算”出来。一个数学证明、一段多步骤的代码调试、一个需要权衡多个约束条件的决策——这些任务要求的不是更多知识（训练时已经学了），而是更深的推理（推理时才能做）。
但故事没有这么简单。
倒 U 型曲线：想多了反而出错
如果”想得越多越好”是成立的，那 test-time compute 就是一个纯粹的”花钱买准确率”的生意——预算越高，效果越好。可现实不是这样。
2025 到 2026 年的一系列研究揭示了一个令人不安的现象：思考 token 数量与准确率之间不是单调递增的关系，而是一条倒 U 型曲线。 其中 When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling 对这个现象做了系统性的实验验证。
简单任务在大约 2K thinking tokens 之后开始出现”过度思考”（overthinking）——模型的推理链越长，准确率反而下降。困难任务的拐点大约在 8K tokens。过度思考的典型表现是：模型在推理链的中段已经得出了正确答案，但因为还有预算，它继续推演，结果说服自己推翻了之前正确的结论。
这个发现改变了 test-time compute 的叙事。它不再是”越多越好”，而是”给对了比给多了更重要”。就像那个学生在草稿纸上演算——算到第三步已经有了正确答案，但强迫他继续写满整张纸，他可能在第七步说服自己之前算错了。
倒 U 型曲线意味着思考强度控制不只是一个成本优化工具，更是一个质量优化工具。这为后面各家厂商的工程实现埋下了伏笔——它们面临的核心问题不是”怎么让模型想得更多”，而是”怎么让模型恰好想到该停的地方”。
从论文到产品：四家厂商的路径
学术界画好了地图，工业界要修路。四家主流厂商各自选择了不同的路径来实现思考强度控制，它们之间的差异不是 feature 的差异，是对”谁来决定思考量”这个问题的不同回答。
Anthropic：从手术刀到自动挡
Anthropic 的演进最完整，也最值得细看——因为它在两年内经历了一次完整的范式转移。
第一阶段是 Extended Thinking，从 Claude 3.7 Sonnet 开始引入，一直延续到 Opus 4.6 和 Sonnet 4.6。开发者通过 budget_tokens 精确设定思考预算的上限——比如 10000 个 token。模型在这个预算内自由推理，可以用不满，但不能超出。这像是给了开发者一把手术刀：你精确地决定模型在每个请求上花多少脑力。
问题是，手术刀要求你知道该切多深。一个简单的分类任务和一个复杂的数学证明需要的思考量差了两个数量级，但 budget_tokens 是写在代码里的固定值。给多了简单任务浪费钱，给少了复杂任务思考不充分。倒 U 型曲线让这个问题更加尖锐——给多了不仅浪费，可能还会伤害质量。
第二阶段是 Adaptive Thinking，随 Opus 4.7 落地。budget_tokens 被直接移除——在 Opus 4.7 上传入这个参数会返回 400 错误（详见 迁移指南）。取而代之的是 thinking: {type: "adaptive"} 配合 effort 参数，后者只有几个语义级别：low、medium、high、xhigh、max。
从精确数值到语义级别，看起来是控制力的丧失，实际上是判断权的移交。模型自己来决定每个请求需要多少思考——effort 只是一个宏观的指导方针，告诉模型”这个任务你大概需要多认真”。简单问题即使 effort 设了 high，模型也可能只想几百个 token；复杂问题在 medium 下也可能产生长长的推理链。
这个演进的底层逻辑和倒 U 型曲线高度吻合：既然最优思考量取决于任务难度，而任务难度人类很难预判，那不如让模型自己判断。
Opus 4.7 还引入了一个值得注意的设计：thinking 默认关闭。不传 thinking 字段的请求就不会思考，和之前的模型行为一致。你必须显式写 thinking: {type: "adaptive"} 才会开启。这意味着 Anthropic 把思考当作一个需要主动选择的特性，而不是一个默认启用的能力。
OpenAI：推理模型是另一个物种
OpenAI 走了一条完全不同的路。它没有在通用模型上加一个”思考开关”，而是训练了专门的推理模型——o1、o3、o4 系列。这些模型天生就会思考，你不需要开启任何特性，发请求就会自动产生 reasoning tokens。
思考强度通过 reasoning.effort 控制，值域从 none 到 xhigh。和 Anthropic 一样是语义级别，但有一个关键区别：OpenAI 从来没有提供过 budget_tokens 这样的精确数值控制。它一开始就是语义级别，跳过了 Anthropic 走过的”精确控制→发现不好用→改成语义”的弯路。
另一个差异是透明度。OpenAI 的 reasoning tokens 不暴露原始内容——你看不到模型在想什么，只能通过 summary 参数获取摘要。Anthropic 则允许开发者选择是否显示思考过程（Opus 4.7 默认隐藏，但可以设 display: "summarized" 打开）。这背后是对”思考过程是产品特性还是实现细节”的不同判断。
Google Gemini：两代参数并存
Google 的设计最务实，也最”Google”——它同时保留了两种控制方式。
Gemini 2.5 系列用 thinkingBudget，接受具体数值，设 0 关闭思考，设 -1 让模型自行决定。这和 Anthropic 早期的 budget_tokens 思路几乎一致。Gemini 3.x 系列则引入了 thinkingLevel，值域 minimal / low / medium / high，和 Anthropic 的 adaptive thinking 走到了同一条路上。
两代参数在文档里并存，没有互斥。这意味着如果你从 2.5 迁移到 3.x，既可以沿用数值控制，也可以切换到语义级别。Google 的哲学一如既往：给你所有选项，让你自己选。
一个有意思的细节：Gemini 2.5 Pro 不能完全关闭思考，thinkingBudget = 0 对它无效。这暗示某些模型的思考能力已经深度融入了前向传播路径，不是一个可以随意拔掉的插件。
DeepSeek：只有开关，没有刻度
DeepSeek 的实现最简洁——思考模式只有开和关，没有强度调节。R1 和 V4 等模型通过 thinking: {type: "enabled"} 开启，开启后 temperature 等采样参数被忽略，思考链通过 reasoning_content 字段返回。
没有 budget，没有 effort，没有 level。模型想多少就想多少，开发者无法在 API 层面限制。R1 的思考链可以长达数万个 token，完全由模型内部决定。
这是开源模型的典型思路——控制权交给部署侧。如果你用 DeepSeek 的 API，你只能接受它的思考量；如果你自己部署，可以在推理引擎层面设置 max_tokens 来间接限制。API 简单，灵活性留给基础设施。
思考 token 的经济学
把四家厂商的实现铺在一起看，有几条共性值得提炼。
所有厂商都把 thinking tokens 按 output token 计费。 以 Claude Opus 4.7 为例，output 价格是 $25/MTok。一次中等深度的思考大约产生 8K thinking tokens，成本约 $0.20；一次深度思考可能 32K tokens，成本约 $0.80。这些成本在每轮推理中都要重新支付——thinking tokens 不像 prompt 那样可以被缓存。
Thinking tokens 在本轮生成后被丢弃，不带入下一轮。 这是它和普通 assistant message 的关键区别。模型上一轮的回复会变成下一轮的 input（走 prefill，可被 prompt cache 覆盖），但模型上一轮的思考过程不会——它在生成完毕后就消失了。下一轮推理时，模型需要重新思考。
这两条加在一起，画出了 thinking tokens 的成本画像：高单价、不可缓存、每轮重新生成。在 上一篇关于 Prompt Caching 的文章 里，我讲了 LLM 推理成本的非对称性——prefill 是可以通过缓存优化的”读”，decode 是无法缓存的”写”。Thinking tokens 把这个非对称性推向了极端：它们是纯粹的”写”，是 prompt caching 的盲区。在 agent 场景下，如果每轮工具调用都伴随深度思考，思考成本很可能超过 prompt 本身的成本。
从推理经济学的全景来看，Prompt Caching 和 Test-Time Compute 是推理成本优化的一体两面。前者压缩的是”读”（prefill）的浪费，后者承担的是”写”（decode）的代价。前者的方向是”少做重复的事”，后者的方向是”多做有价值的事”。一个省钱，一个花钱——但都是为了让推理的每一分钱花在对的地方。
从”数值”到”语义”：行业共识正在形成
如果只看一个趋势，那就是这个：精确的 token 数预算正在让位给语义级别的 effort 控制。
Anthropic deprecated 了 budget_tokens，在 Opus 4.7 上直接移除。Google 从 thinkingBudget 走向 thinkingLevel。OpenAI 从一开始就没给过数值控制。三家的终点是同一个设计：开发者说”仔细想”或”快点回”，模型自己决定具体想多少。
这不是偶然。倒 U 型曲线表明，最优思考量是 per-task 的——同一个 effort level 下，简单问题和复杂问题的实际思考量应该差很多。固定 budget 做不到这一点，但 adaptive 可以。模型见到了题目，它比开发者更清楚这道题需要想多久。
Anthropic 的 Opus 4.7 还走得更远：effort 参数不仅控制思考量，还影响模型的整体行为——工具调用频率、回复详细度、subagent 的派生策略。“思考强度”正在泛化为”整体努力程度”。effort: "low" 不只是”少想一点”，而是”这是一个不需要太认真的任务，各方面都可以从简”。
这是一个值得注意的信号。它意味着 test-time compute 不再只是”在回答前多想一会儿”这个技术机制，而是正在成为一个控制模型行为的元参数——类似于汽车的驾驶模式，一个旋钮同时调节油门响应、悬挂硬度、转向手感。
两篇文章，一个成本结构
写完这篇文章，回头看 Prompt Caching 那篇，两者拼在一起正好覆盖了 LLM 推理成本的完整版图。
一次 LLM 推理的 token 流可以被分成三段：
- Cached input（prompt cache 命中的部分）——最便宜，约为基础输入价的 10%，是”已经读过的书”
- Uncached input（需要 prefill 的新内容）——基础价，是”第一次读的书”
- Output + Thinking（decode 生成的部分）——最贵，而且不可缓存，是”写下的答案和草稿”
Prompt Caching 做的是把第二段尽可能多地变成第一段——通过”静态在前，动态在后”的 prompt 结构设计，让大部分 input 命中缓存。Test-Time Compute 做的是合理控制第三段——通过 effort 级别或自适应机制，让模型在每个问题上花”恰好够用”的思考量，不多不少。
两个方向互不相交，但共享同一个信念：推理的成本结构不是铁板一块，它可以被理解、被拆解、被重新设计。 识别哪些计算是重复的（缓存它），识别哪些计算是有价值的（投入它），识别哪些计算是浪费的（砍掉它）——这是 2026 年做 LLM 应用绕不开的基本功。
非对称性是成本结构的本质特征。上一篇讲了”读”这一侧的优化。这一篇讲了”写”这一侧的权衡。把它们放在一起，你对 LLM 推理的钱花在哪里、该怎么花，应该有了一张完整的地图。
参考资料
论文
- Snell, C., Lee, J., Xu, K., & Kumar, A. (2024). Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Model Parameters. ICLR 2025 Oral.
- Chen, X., et al. (2026). When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling. arXiv preprint.
厂商文档
- Anthropic. Extended Thinking — budget_tokens 机制说明（适用于 Opus 4.6 及之前版本）。
- Anthropic. Adaptive Thinking — Opus 4.7 推荐的思考控制方式。
- Anthropic. Migration Guide: Claude Opus 4.7 — 从 budget_tokens 到 adaptive thinking 的迁移指南。
- OpenAI. Reasoning Models — reasoning.effort 参数与推理模型使用指南。
- Google. Gemini Thinking — thinkingBudget 与 thinkingLevel 参数说明。
- DeepSeek. Thinking Mode 与 Reasoning Model — R1 思考模式文档。