推理模型兴起：为什么测试时计算开始变重要

很长一段时间，大家判断一个大模型强不强，主要看三个东西：参数规模、训练数据和榜单分数。模型发布以后，用户发来问题，模型用一次前向计算生成答案；如果答错了，我们通常只能换更大的模型、补更多数据，或者重新训练。

2024 年以后，一个新的方向越来越清楚：有些问题不是模型没有能力，而是一次回答时没有给它足够的时间和计算。让模型多生成几步、检查中间结果、比较多个候选路径，复杂任务的正确率可能明显提高。模型的能力，不再只写在训练完成的参数里，也开始体现在“回答这个问题时愿意花多少计算”上。

这就是 Test-time Compute，通常翻译成测试时计算或推理时计算。它听起来像一个性能技巧，实际上改变了模型训练、服务和评测的共同假设。我研究这条路线时最大的感受是：过去我们把推理看成读出答案，现在开始把推理看成一次有限预算内的求解过程。

但这份变化也带来新的账单。多算一点可能更准确，也可能只是生成更多废话；候选数量增加可能提高成功率，也可能把延迟和成本推到用户无法接受。理解推理模型，不能只看它会不会“想得更久”，还要问它多花的计算是否真的换来了可验证的收益。

一、为什么单次生成开始遇到瓶颈

大模型的单次生成有一个天然限制：它通常沿着当前概率最高或采样得到的路径一路往前走。第一步选择错了，后面可能继续围绕错误前提组织出一套流畅解释。对于简单问答，这种方式足够快；对于多步数学、代码调试和复杂规划，错误会层层积累。

一次性生成：
问题 → 选择路径 A → 继续路径 A → 最终答案
                         ↑
                   早期错误难回退

训练可以改善模型选择正确路径的概率，但并不能让每一次采样都正确。即使一个 token 的错误概率很小，经过很长的生成序列后，累计出错的机会仍然会上升。复杂任务需要的不只是更好的平均概率，有时还需要在关键节点停下来检查，或保留几条候选路径比较。

另一个瓶颈是数据。人类可以为最终答案打标签，却很难为每个中间状态都写出可靠的“应该得多少分”。开放任务尤其如此：什么叫一个好的计划？哪一步算有价值？不同的合理解法如何比较？这让纯粹依赖更大监督数据的路线越来越昂贵。

二、测试时计算到底在增加什么

Test-time Compute 不是简单把 max_tokens 调大。它可以包含多种形式：

让模型生成更长的中间推导，并在结论前自检。
对同一个问题采样多个答案，再使用验证器选择结果。
生成多个计划，比较它们的可行性后再执行。
调用搜索、计算器、代码执行环境和数据库获取外部反馈。
在发现冲突或不确定时回退到上一个状态，重新选择路径。

问题
  ↓
候选路径 / 中间步骤 / 工具观察
  ↓
验证、比较、剪枝或回退
  ↓
最终答案

这些方法的共同点，是把一次“直接生成”变成一个小型求解过程。模型不必第一次就猜中终点，系统可以用额外计算换取更多尝试和检查机会。

但“更多”必须有结构。把同一个 Prompt 重复发送十次，再随机挑一条，不一定比一次回答好；没有验证器、没有独立证据、没有停止条件的额外计算，很容易只是成本放大器。

三、推理模型为什么看起来像是在思考

推理模型通常会在最终答案前生成较长的中间过程，或者在内部完成更多候选、检查和回溯。用户看到的现象是：模型回答变慢了，但数学、代码和逻辑题的成功率提高了。

这不应该被理解成人类意识突然出现，而应该从计算过程看：模型在回答时获得了更多 token、更多采样机会或更多验证步骤。它可以把问题分解，把中间结果暂存下来，再根据当前状态决定下一步。这些都是可观察的计算行为。

普通生成：一次预测 → 答案

推理生成：
  分解问题 → 形成假设 → 计算 / 搜索 → 检查 → 修正 → 答案

“思考更久”只有在任务允许有效反馈时才有意义。数学题可以重算，代码可以运行，检索可以看来源；如果问题缺少信息，模型再长的内部过程也不能凭空创造事实。推理时计算解决的是路径和验证问题，不是所有知识问题。

四、从 Chain-of-Thought 到可验证推理

Chain-of-Thought 让模型输出中间步骤，是这条路线的重要起点。它帮助模型把复杂任务拆开，也让研究者有机会观察错误发生在哪里。但自然语言思维链本身不一定可靠：模型可能事后编造解释，或者写出看似严谨却不合法的推导。

因此，推理系统逐渐重视可验证的中间产物：

数学：公式、数值、单位 → 重新计算
代码：补丁、测试 → 沙箱运行
SQL：查询、结果集 → 隔离数据库执行
规划：步骤、约束、资源 → 规则检查
检索：结论、来源 → 引用匹配

可验证性让额外计算有了方向。模型提出候选，验证器判断结果，系统再决定是否继续。对于不可完全自动验证的任务，也至少应该记录证据、来源和不确定性，而不是把一段流畅文字直接当成正确证明。

type CandidateResult = {
  answer: unknown
  evidence: string[]
  tokens: number
}

type Verification = {
  passed: boolean
  score: number
  errors: string[]
}

async function solveWithVerification(prompt: string) {
  const candidates: CandidateResult[] = await sampleCandidates(prompt, 4)
  const checked: Array<CandidateResult & Verification> = []

  for (const candidate of candidates) {
    const result = await verifyCandidate(candidate)
    checked.push({ ...candidate, ...result })
  }

  return checked
    .filter((candidate) => candidate.passed)
    .sort((a, b) => b.score - a.score)[0]
}

代码是示意，但原则很重要：先产生候选，再独立验证，最后选择或拒答。不要让模型自己宣布“我的推理正确”，那相当于让参赛者同时担任裁判。

五、为什么这会改变模型训练

如果回答时可以多算，训练目标就不必只追求“第一次生成就答对”。训练可以教模型如何分解问题、如何使用验证器、如何在发现错误后回退，以及如何在有限预算内选择更有希望的路径。

这也解释了为什么强化学习和可验证奖励重新受到重视。数学、代码和结构化任务可以提供相对清晰的结果反馈，模型能够通过多次尝试学到哪些行为更容易得到正确结果。训练时学会策略，推理时使用更多计算执行策略，两者形成互相配合的关系。

训练阶段：学习“如何使用推理预算”
推理阶段：为当前问题分配和消耗推理预算

训练不应该只奖励最终数字，也要防止模型通过堆长度、重复模板或钻验证器漏洞取得高分。奖励函数、独立评测集和人工抽检都很重要。模型会认真优化真正写进目标的东西，口头上说“希望它理解”，不等于目标函数里真的有理解。

六、推理预算是一种新的服务资源

普通聊天服务常按请求数、输入 Token 和输出 Token 估算成本。推理模型出现后，还要把候选数、验证轮数、搜索深度和工具调用次数纳入预算。

单任务总成本
= 基础生成成本
 + 候选采样成本
 + 验证器运行成本
 + 检索 / 工具成本
 + 重试与回退成本

延迟也会发生变化。多个候选可以并行生成，降低墙钟时间，却增加瞬时 GPU 压力；串行检查节省并发资源，却会拉长用户等待。服务端不能只报平均延迟，要看 P95、P99、超时率和每个成功任务的真实成本。

最实用的策略是动态预算。简单问题先用短路径，验证失败或难度较高时再增加计算；答案已通过检查就提前结束；连续几次没有带来新信息就停止。推理预算应该像数据库连接池一样被管理，而不是无限供应。

type Budget = {
  maxAttempts: number
  maxTokens: number
  deadlineMs: number
}

function budgetFor(complexity: 'low' | 'medium' | 'high'): Budget {
  switch (complexity) {
    case 'high':
      return { maxAttempts: 4, maxTokens: 12000, deadlineMs: 15000 }
    case 'medium':
      return { maxAttempts: 2, maxTokens: 5000, deadlineMs: 7000 }
    default:
      return { maxAttempts: 1, maxTokens: 1200, deadlineMs: 2500 }
  }
}

七、质量曲线比单点榜单更重要

研究推理模型时，不能只问“它的准确率是多少”，还要问“准确率随着计算预算怎么变化”。可以设置预算为 1、2、4、8，观察正确率、平均 Token、P95 延迟和单位任务成本。

质量
  │                 ───── 平台期
  │            ____/
  │        ___/
  │    ___/
  └──────────────────────→ 推理预算
       收益明显     边际收益下降

很多任务会出现收益递减：从一次尝试增加到两次，提升很明显；从八次增加到十六次，几乎没有变化。还有一些任务完全没有收益，因为缺少信息或验证器，模型只是重复错误。

评测集必须包含不同难度和不同风险等级。简单题、复杂题、无答案题、对抗输入和工具失败都要分别统计。平均分上升，可能只是简单题变好了；高风险任务的拒答率、引用正确率和结果校验通过率同样重要。

还要保留完整轨迹。最终答案相同，可能一个模型只调用一次就找到可靠证据，另一个模型调用了八次并碰巧选对。没有轨迹，就无法知道多出来的计算到底用在了哪里。

八、它对模型产品意味着什么

推理模型会改变产品的交互预期。用户可能愿意为复杂任务等待更久，但不愿意为一个简单问题等十几秒。界面需要展示合理的进度、当前阶段和必要的引用，同时允许取消长任务。

后端需要把短请求和长推理任务区分开。长任务最好具备队列、检查点、超时、取消和断点恢复，不要占住一个 HTTP 连接等模型慢慢想。高价值任务可以异步执行，完成后通知用户；低价值任务则应该使用小预算快速回答。

工具调用也必须有边界。模型多想几步不等于可以多做几次副作用操作。搜索可以重试，付款和发布不能因为推理循环重复而执行多次；每一个写操作都需要幂等键、权限检查和必要审批。

九、它没有解决什么问题

Test-time Compute 很容易被过度宣传。它不能替代新鲜数据，不能绕过权限，不能保证模型不产生幻觉，也不能让一个没有目标的任务自动变得清楚。

如果知识库没有答案，模型再采样十次也只是在不同措辞下猜测；如果验证器本身有漏洞，更多计算可能让模型更擅长钻漏洞；如果目标标准不明确，搜索更多路径只会产生更多争论。

因此，推理时计算必须和检索、工具、验证器、用户澄清以及人工审批结合。它是一种扩大有效求解空间的方法，不是一颗“再想久一点就什么都能解决”的药丸。

十、作为开发者应该怎样学习

学习这条路线，不需要一开始复现庞大训练集群。可以从一个有明确答案的小任务开始：准备数学题或代码题，写一个独立验证器，让模型生成多个候选，比较预算和正确率。然后增加一个搜索工具，观察外部反馈如何改变下一步。最后再加入动态停止、轨迹记录和成本统计。

确定性问题
  ↓
独立验证器
  ↓
多候选采样
  ↓
比较质量 / 成本曲线
  ↓
动态预算与失败恢复

这个练习会让你亲手看到几个重要事实：有验证器时，多算更有价值；没有验证器时，多算很容易变成重复；预算必须和任务难度匹配；最终答案之外，轨迹和资源数据同样重要。

十一、我的总结：模型的能力开始有了“运行时维度”

推理模型兴起的意义，不只是模型回答前多显示了一段文字。它提醒我们，大模型能力有两个维度：训练完成后它学会了什么，以及面对当前问题时系统允许它调用多少时间、多少候选、多少工具和多少验证。

过去我们常把模型当成一个固定函数：输入相同，期待一次得到答案。现在更准确的理解是，模型可以成为一个有限预算内的求解器。预算越多，理论上有更多机会发现和修正错误；但收益必须通过验证证明，成本也必须被诚实地计算。

我最愿意留下的判断是：推理时计算不是让模型“慢一点”，而是给它一个可以管理的探索空间。好的系统会先用小预算试探，发现困难后逐步加码，找到可靠答案就停止，信息不足就追问，风险过高就交给人。它把计算用在真正值得的地方，也承认计算不能创造不存在的事实。

这可能就是 2025 年大模型路线最重要的变化之一：竞争不再只有谁训练了更大的模型，还包括谁更会设计验证、分配预算、管理轨迹和承担成本。模型会不会推理只是起点，系统能不能让它在正确的边界内推理，才是接下来真正要学习的工程。