推理时计算的范式革命：当大模型学会“多花点时间想”之后，AI 架构发生了什么
OpenAI o1/o3、Anthropic Claude 3.7 Sonnet、Google Gemini 2.5 Pro、DeepSeek R1——四家实验室在 2025 年集体把“推理时计算”推到默认能力。这篇文章拆解这场架构革命的根源、四条路径的差异，以及它对 AI 应用架构的连锁冲击。
约 20 分钟阅读5,734 字27 次阅读博主
OpenAI o1/o3、Anthropic Claude 3.7 Sonnet、Google Gemini 2.5 Pro、DeepSeek R1——四家实验室在 2025 年集体把“推理时计算”推到默认能力。这篇文章拆解这场架构革命的根源、四条路径的差异，以及它对 AI 应用架构的连锁冲击。
如果说 2024 年是大模型"卷参数"的尾声，那么 2025 年就是大模型"卷思考"的元年。OpenAI 的 o1/o3、Anthropic 的 Claude 3.7 Sonnet、Google DeepMind 的 Gemini 2.5 Pro、DeepSeek 的 R1——四家在不到 12 个月内先后把"推理时计算"（test-time compute scaling）从论文概念推到了默认能力。这篇文章想回答三个问题：推理时计算到底是什么？为什么它在 2025 年突然集体爆发？它对 AI 应用的架构意味着什么？
在 2024 年之前，大语言模型的训练范式可以简化为一句口号：让模型在固定的推理算力下，把更多能力固化到权重里。训练阶段烧钱，推理阶段省力；参数规模决定能力上限，思考时间几乎不影响输出质量。我们熟悉的 ChatGPT、Claude 3 Sonnet、LLaMA 3 都是这条路径的产物。
2025 年开始，这条路径被一条新的轴线打破：允许模型在推理阶段花更多算力"想"，换来更高的输出质量。这条思路在学术上叫 test-time compute scaling（推理时计算扩展），在产品上对应 OpenAI 的"reasoning models"、Anthropic 的"extended thinking"、Google 的"thinking models"、DeepSeek 的"R1"系列。
这条范式转换的根可以追溯到 2022 年 Jason Wei 等人在 Google Brain 发表的 Chain-of-Thought Prompting 论文（arXiv:2201.11903）。这篇论文证明：只要在 prompt 里给模型若干"思考过程的样例"，大模型就能自然涌现出分步推理能力，并在 GSM8K 数学题等基准上大幅超越直接回答。这给出了一个关键信号——推理能力不一定只来自训练时的参数扩容，也可以来自推理时的"思考步数"。
但 CoT 仅仅是 prompt 层的诱导。真正把"思考步数"变成可被产品化调控的旋钮，是 OpenAI 在 2024 年 9 月发布的 o1-preview。据 OpenAI 公开的 o1 system card 描述，o1 在内部通过强化学习训练出"长链路思考"的能力，推理时会生成大量隐藏的 chain-of-thought tokens，最终只把精简后的答案返回给用户。这一步打开了"推理算力 ↔ 答案质量"的可调旋钮。
进入 2025 年，推理时计算迅速从 OpenAI 独家变成行业标配。值得专门梳理四家的差异，因为它们的产品形态差异，会直接决定下游应用怎么用。
OpenAI：reasoning_effort 参数化的隐藏思考。o1 / o3 / o3-mini 系列延续隐藏 chain-of-thought 路线，开发者可通过 API 参数 reasoning_effort 在 low / medium / high 三档之间切换。据 OpenAI 2025 年 1 月 31 日发布的 o3-mini 公告，o3-mini 在编程、数学、科学题上比 o1-mini 同档位更高效，且 reasoning_effort 越高结果越稳定。
Anthropic：可见 extended thinking + 128K thinking budget。Anthropic 在 2025 年 2 月 24 日同一天发布了两件事：Claude 3.7 Sonnet 模型（自称"市面上首个混合推理模型"）和 extended thinking 模式。据 Anthropic 公告，Claude 3.7 Sonnet 同时具备"普通 LLM 模式"和"extended thinking 模式"，API 用户可通过 thinking 参数声明一个"思考预算"——最高可达模型输出上限的 128K tokens。关键设计点是思考过程默认对用户可见，而不是像 o1 那样隐藏。
Google DeepMind：Gemini 2.5 Pro Thinking 模式。Google 在 2025 年 3 月 25 日发布 Gemini 2.5 Pro Experimental，据 Google DeepMind 官方博客披露，该模型是"thinking model"，在回答前会先推理其思考过程；在数学/科学基准（GPQA、AIME 2025）上领先，在 Humanity's Last Exam（人类前沿知识考试）上以 18.8% 的成绩在"无工具调用"的模型中达到 state-of-the-art。注：18.8% 这个数字是 Google 在该公告中明确给出的"无工具"档；据后续报道，使用工具或多模型投票可大幅提升到 30%+。
DeepSeek：纯 RL 路径，无需人类标注的思考链。DeepSeek 在 2025 年 1 月发布的 R1 论文（arXiv:2501.12948）提出了一种激进的纯强化学习方案：直接让模型在数学/编程等可验证任务上做 RL，不依赖人类标注的思考轨迹。R1 在训练中自然涌现了"自我反思、验证、动态策略切换"等高级推理模式，并能蒸馏到小模型上让 1.5B–70B 级别的开源模型也具备类似能力。R1 的开源属性让推理时计算范式第一次有了"非闭源"参照系。
四家虽然都收敛到"思考 token ↔ 质量"这条曲线，但产品形态差异巨大：OpenAI 把思考隐藏、Anthropic 把思考可见、DeepMind 把思考做成开关、DeepSeek 把思考做成开源。这种分化并非偶然——它直接对应了不同实验室对"推理可控性 / 可解释性 / 可复现性"的优先级排序。
Anthropic 的 extended thinking 公告里给出了一张图：Claude 3.7 Sonnet 在 2024 AIME（美国数学邀请赛）题上的准确率，与允许消耗的"思考 tokens"数量呈对数增长关系——预算翻倍，准确率上升但边际递减。这张图是理解整场范式革命的核心证据：推理时算力不再是"按字收费的损耗"，而是一种可调节的、对数级有效的能力维度。
这条对数曲线带来三个推论：
第一，训练参数与推理算力是互补关系，不是替代关系。同一组权重，思考预算从 1K 拉到 64K，可能在 AIME 这种高难度题上从 30% 跳到 70%；不增加任何参数，纯靠推理时"想"出来的能力。这种"参数不动 + 推理加力"的扩展轴，在 2024 年之前几乎是不存在的。
第二，延迟和成本首次成为可调的产品维度。以前 LLM 的"快"和"准"基本由模型大小决定——大模型准但慢，小模型快但糙。现在多了一维：可以让小模型"想久一点"逼近大模型质量，可以让大模型"快答"逼近小模型延迟。Anthropic 明确把 thinking budget 当作"速度/成本 ↔ 答案质量"的 trade-off 旋钮来对外宣传。
第三，推理时计算把"训练数据"的瓶颈部分转移到了"可验证信号"。DeepSeek-R1 之所以能用纯 RL 训出强推理能力，关键不在数据量大，而在任务可验证——数学题有标准答案、编程题有单元测试。只要任务可自动判定对错，模型就能自己探索出最优思考路径。这条规律的反面是：开放性、主观性、价值判断类任务，目前仍然无法从推理时计算中获得显著收益。
推理时计算的崛起不是单纯的能力升级，而是对整套 AI 应用架构的连锁冲击。下面四个变化是工程团队在 2025–2026 年必须面对的。
变化一：API 调用形态从"请求 + 响应"变成"预算声明 + 长响应"。传统 LLM API 主要参数是 prompt、temperature、max_tokens。推理模型 API 多了一组参数：reasoning_effort / thinking / budget_tokens。这些参数不只是装饰，它们会显著影响账单（thinking tokens 同样计费）和 P99 延迟。
变化二：流式输出策略必须重写。如果模型要"思考 30 秒"再回答，把整个请求同步等待会严重拖累用户体验。Anthropic 的做法是流式暴露 thinking 内容（用户能看到模型"在干嘛"），OpenAI 的做法是把思考完全隐藏在服务端、只流式输出最终答案——这两种策略对前端 UX 设计的影响完全不同。
变化三：上下文工程要把"思考痕迹"也算进去。如果使用 Anthropic 的 extended thinking 并把思考内容回传给模型做多轮对话，思考 tokens 会迅速占满 context window。实测中一个 64K 预算的思考块，往往比最终答案长 10 倍以上。这意味着所有原本为"短 prompt"调优的 context engineering 策略（如长文档压缩、检索结果筛选）都要重新校准。
变化四：缓存与成本模型被打穿。OpenAI 和 Anthropic 都有 prompt caching 机制，但推理模型的 thinking tokens 通常不进入缓存可命中的范围（因为它们每次随机采样）。结果是：在一个 Agent 工作流里，反复调用推理模型"想清楚再行动"，实际账单可能比预期高 2-3 倍。如果不显式设计"何时调用推理模型、何时退回到普通模型"，整体成本会失控。
这四条都不是"理论问题"，而是 Lonae 自己在做 MCP 工程实践时反复踩过的真实痛点（参考 2026-06-12 的"MCP 工程实战"一文提到的成本测算经验）。
把推理时计算落地到产品里，需要的不是"盲目启用"，而是按任务特征分级调度。下面是一份经验性的决策框架：
任务类型 A：可验证、有标准答案（数学证明、代码生成、SQL 构造、逻辑题）——强建议开启 thinking，预算拉到 16K–64K。DeepSeek-R1 的蒸馏实验显示，同一基模型在 AIME 上的得分可以从 30% 提升到 70% 以上，预算回报极高。
任务类型 B：开放式、有主观性（写作、对话、规划、用户咨询）——不建议默认开启 thinking。开启后 token 成本飙升 5–10 倍，而答案质量提升有限。最佳实践是用普通模型先快速响应，再用推理模型做"质量复核"或"草稿改进"。
任务类型 C：Agent 内部决策节点（是否调用工具、任务分解、错误恢复）——按 step 重要性分级。关键节点（如"是否提交最终答案"）开高预算，常规节点（如"格式化输出"）关掉。Anthropic 的 building-effective-agents 一文给出的"Orchestrator-workers / Evaluator-optimizer"等模式都建议给编排器（orchestrator）使用推理模型，给执行器（worker）使用普通模型。
任务类型 D：实时性敏感（聊天 UI、实时翻译、客服首响）——关闭 thinking 或限到 1K–4K。把推理预算压到"边际收益拐点"附近即可；继续投入预算换来的是几秒延迟，多数 UX 场景下得不偿失。
通用经验法则：thinking budget 与答案质量的对数曲线意味着预算从 4K 拉到 16K 收益最大，从 16K 拉到 64K 收益明显但边际递减，从 64K 再往上多数场景已经回不来成本。不要被 "max thinking = 128K" 这种 marketing 数字迷惑，按任务难度动态分配才是工程正道。
推理时计算不是一种"新模型"，而是一种新维度。它把 LLM 从"训练决定一切"的两点结构变成了"训练 + 推理"的三维结构。这条新维度在 2025 年迅速被四家前沿实验室同步验证，进入 2026 年已经成为大模型 API 的默认能力之一。
对应用开发者来说，最关键的不是"哪家的推理模型更强"，而是自己的任务里哪些环节真的能从"多花点时间想"中获益、哪些环节纯粹是浪费。一旦把任务分级和预算分配想清楚，推理时计算就能从"成本黑洞"变成"能力放大器"。
未来 12 个月值得关注的方向有三：一是推理模型的蒸馏到端侧（手机、嵌入式设备上跑小参数 + 大预算）；二是自适应预算（模型自己判断要"想多久"而不是开发者手动指定）；三是推理过程的可审计性（思考链是否可信、是否会被 reward hacking）。这三个方向一旦有突破，"推理时计算"就会从旗舰模型的能力下放到通用 AI 应用的默认基础设施。
Conversation
0 条