当思考模型真正发挥作用时：生产环境推理算力的决策框架

有一项研究，研究人员要求一个推理模型比较两个数字：0.9 和 0.11。一个模型花了 42 秒才给出答案。数学计算只花了几毫秒。模型在剩下的 41.9 秒里都在进行糟糕的思考。它重新审视自己的答案，怀疑自己，重新考虑，最后得出了它在前三个 token 中就已经得出的正确结论。

这就是过度思考的问题，它并非个案。当你将推理侧计算（inference-time compute）不加区分地应用于不需要它的任务时，就会发生这种情况。

"https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E4%BD%95%E6%97%B6%E6%8E%A8%E7%90%86%E6%A8%A1%E5%9E%8B%E7%9C%9F%E6%AD%A3%E6%9C%89%E7%94%A8%EF%BC%9A%E6%8E%A8%E7%90%86%E4%BE%A7%E8%AE%A1%E7%AE%97%E7%9A%84%E7%94%9F%E4%BA%A7%E5%86%B3%E7%AD%96%E6%A1%86%E6%9E%B6"

推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。

推理侧计算到底做了什么

标准的 LLM 策略是在训练时进行扩展：更多的参数、更多的数据、更多的计算。推理模型颠覆了这个等式。它们不是在部署前投入计算，而是在处理每个请求时投入计算——在产生最终答案之前，生成内部思维链（CoT）、探索多条解决路径、从死胡同中回溯。

在困难的基准测试中，其结果是惊人的。使用推理侧缩放的模型在国际数学奥林匹克竞赛（IMO）预选赛中获得了 74% 的分数，而其非推理型对应的模型仅为 9%。在特定的推理任务中，只要给予足够的推理预算，小巧的 1B 参数模型可以超越未经缩放的 405B 模型。

但这种性能并非免费的。Token 经济学是严苛的：

• 在同类任务中，推理模型生成的 token 数量是直接回答模型的 3–10 倍
• o3 级别的模型每个请求的成本大约是非推理型对应模型的六倍
• 复杂问题的首个 token 响应时间（TTFT）可能超过五分钟
• 随着规模的扩大，推理成本的增长快于请求量，因为推理任务触及了成本分布中昂贵的一端

这并不意味着你应该避免使用思考型模型。它的含义是，在没有路由策略的情况下部署它们，大约相当于用喷气发动机去过马路。

过度思考的陷阱

这种失败模式比简单的“推理需要更长时间”更为微妙。推理模型患有一种被称为“过度思考”的特定病症：它们在思维链的早期就找到了正确答案，然后却依然继续。

对长思维链模型的研究发现，在许多情况下，模型得出了正确的解决方案，然后引入了不确定性，接着重新探索替代方案，再重新验证最初的正确答案——整个过程都在消耗 token。在失败的案例中，模式则有所不同：模型固着在一个早期的错误路径上无法脱身，在错误的轨迹上耗尽了 token 预算。

这两种失败模式有着相同的根源：模型缺乏对何时已经思考足够的校准感知。人类可能会检查答案并感到自信，但推理模型没有内部的“充分性”信号。它们继续思考，是因为它们被训练去做的事情就是继续。

对生产系统的实际后果是，在分类任务上投入 16,000 个 token 的推理预算并不会产生更准确的分类。它会产生同样的答案——或者偶尔是一个更糟的答案——而成本却是原来的 15 倍。

路由决策框架

在部署任何 AI 功能之前，核心问题是任务的复杂性是否证明了推理计算的合理性。以下是一个实用的分类法：

受益于扩展思考的任务：

• 多步骤数学推理（证明、优化问题、带约束的财务建模）
• 涉及多个交互系统或非显而易见算法选择的复杂代码生成
• 需要在多个章节之间追踪矛盾的长文档综合
• 具有硬约束且朴素方法失效的规划问题
• 训练数据中没有太多先例的新型问题表述

不从扩展思考中受益的任务：

• 文本分类、情感分析、意图检测
• 从结构化或半结构化文档中提取信息
• 关键点明确的摘要
• 答案在上下文中、仅需要格式化而非推导的检索增强生成（RAG）
• 非推理模型在你的评估中已经达到可接受准确度的任何任务

扩展思考反而有害的任务：

• 关注 p99 延迟的实时或交互式应用
• 按 token 付费且利润空间有限的高吞吐量流水线
• 简单的字符串转换、实体归一化或模式映射
• “错误”答案源于过度思考的任务：推理模型有时会因为对确定的初始结论进行过度限定而引入错误

一个有用的启发式方法：如果一项任务能被人类专家在十秒钟的阅读内解决，推理模型就不太可能优于标准模型。只有在确实存在复杂性需要处理时，即答案并非显而易见、需要探索解决方案空间时，推理预算才会有所回报。

Token 预算校准

如果你已确定任务需要推理模型，下一步决策就是思考预算（Thinking Budget）。设置过高会浪费资金；设置过低则会在推理链中途截断，产生的结果往往比完全不推理还要糟糕。

来自生产环境部署的经验性指导：

• 1,000–2,000 tokens：带有细微差别的简单事实问题 —— 适用于那些你希望模型双重确认而非深度审议的边缘案例。
• 5,000–10,000 tokens：中度推理 —— 多步骤问题、涉及少量交互组件的代码、涉及多个因素的分析。
• 15,000–32,000 tokens：复杂推理 —— 数学竞赛、多文件代码生成、详尽的约束满足问题。

实际的做法是从产生可接受结果的最低限度开始，然后逐步增加。大多数受益于推理的任务在 10,000 tokens 以下表现良好。除非问题确实非常困难 —— 比如 AIME 竞赛题、带有微妙并发漏洞的生产环境调试任务、复杂的法律分析 —— 否则超过 20,000 tokens 的边际收益会大幅下降。

请注意，计费包含所有的思考 token，而不仅仅是可见的输出。一个看起来只有 200 个 token 的简洁解释，可能在内部消耗了 12,000 个思考 token，而这些都会按输出 token 的费率向你收费。

自适应思考：让模型决定

手动预算的方法要求你在路由之前对任务进行分类 —— 当你的输入分布具有异质性时，这本身就是一个有趣的挑战。较新的模型 API 通过自适应思考（Adaptive Thinking）解决了这个问题：模型根据输入的表观复杂度动态决定应用多少推理量。

这将决策权从你的路由层移交给了模型本身。对于 Claude 的当前代模型，自适应思考是推荐的方法，而非固定预算配置 —— 模型会学习如何根据任务难度校准推理投入。

自适应思考并不意味着不需要人工监督。你仍然需要设置一个最大预算上限，监控每个请求类别的实际 token 消耗，并通过评估（Evals）验证模型的复杂度自我评估是否符合你的质量预期。但它消除了那种容易堆积成难以维护的决策树的脆弱 if-else 路由逻辑。

大规模路由

对于处理混合工作负载的系统 —— 即某些请求需要深度推理而大多数不需要 —— 正确的架构是级联式（Cascade）：

1. 意图分类层：一个快速、廉价的模型（或关键字/嵌入分类器）对传入请求进行分类。
2. 复杂度信号：对于模糊案例，使用轻量级模型估算任务难度 —— 询问“此请求是否可能需要多步推理？”的成本非常低。
3. 模型路由：简单任务分配给标准模型。真正复杂的任务路由到带有相应预算的推理模型。

这就是 FrugalGPT 等系统背后的模式：通过按成本排序的模型列表依次处理请求，从廉价模型开始，仅在未达到质量阈值时才升级。核心洞察在于，路由决策不需要百分之百完美。将 80% 的请求路由到正确的层级就能节省大部分成本。只要基础比率较小，你可以承受将一些简单任务过度路由到推理模型带来的开销。

另一种方案 —— 为了“以防万一”而将所有内容都路由到最强大的模型 —— 正是许多团队发现当使用规模扩大时，其单次请求成本比预期高出 40 倍的原因。

前沿能力的幻象

有一个值得严肃对待的细微反论。Apple 研究团队在 2025 年的一项分析中探讨了前沿推理模型是否真的在以其思维链所暗示的方式进行推理，还是说它们只是非常擅长生成看起来合理的推理痕迹，同时依赖于模式匹配。在远超出训练分布的真正新颖的问题上，一些推理模型的表现显著低于其基准测试数据。

实际的启示是：MATH 或 AIME 上的高基准分数并不一定能转化为你的特定领域表现。在为关键生产路径启用推理模型之前，请针对代表你所关注的硬案例实际分布的留存示例进行自己的评估。基准测试与生产环境之间的差距是真实存在的，对于关于推理能力的宣称尤其明显。

生产环境集成考量

在大规模应用中会浮现的一些实现细节：

超时处理：消耗大量思考预算的任务可能需要五分钟甚至更长时间。大多数 Web 框架在响应到达之前就会超时。对于推理深度高且延迟无上限的任何用例，你都需要异步任务基础设施 —— 队列、状态轮询端点或用于完成通知的 Webhook。

流式传输与用户体验 (UX)：等待推理模型响应的用户需要反馈。对于交互式应用，流式传输部分输出或进度指示器是必选项。如果没有它，六秒钟的审议过程感觉就像是服务宕机。

缓存行为：前几轮对话中的思考 token 不像常规上下文那样可以缓存，而且更改思考预算配置会使提示词缓存（Prompt Cache）失效。这与提示词缓存策略的交互效果较差。例如，A/B 测试期间的预算更改可能会导致缓存命中率骤降。

多轮推理：如果你的智能体（Agent）使用工具，你必须保留并传回前几轮的思考块（Thinking Blocks） —— 它们不是可选的上下文。丢弃它们会破坏推理链，并导致后续行为逻辑不通。

总结

推理模型并非在所有场景下都更好。它们更擅长处理特定类型的难题 —— 那些需要真正探索才能得出答案、传统方法会失效、且为了准确性值得牺牲延迟和成本的场景。对于占据大多数生产系统的任务 —— 分类、提取、基于上下文的生成、实时响应 —— 它们速度更慢，成本更高，而且往往并不比标准模型更准确。

这种严谨性体现在路由（routing）上。明确你的任务到底需要什么。要在你自己的数据上（而非基准测试数据）衡量延长思考时间是否能提升你的指标。根据任务复杂度设定预算，而不是使用默认值。在发现推理成本正大规模吞噬你的利润之前，先构建好底层架构 —— 异步工作流、自适应路由、成本分摊。

思考更多并不总是意味着思考更好。价值在于知道何时你的“思考预算”能带来真正的回报。