测试时计算：当推理本身成为新的Scaling Law

摘要

2024年末，OpenAI o3在ARC-AGI-1基准上以87.5%的得分刷新纪录——这个成绩本身不算意外，真正令人震动的是其代价：单次推理调用消耗了数百万token，计算量是普通GPT-4o调用的数千倍。几乎同一时期，DeepSeek R1以约1/20的训练成本实现了可比的推理能力，其核心技术跳过监督微调，直接从强化学习中自举出链式推理行为。这两件事共同指向一个范式级的转变：当预训练规模定律（Scaling Laws）在数据瓶颈与算力天花板的夹击下边际回报急剧递减时，扩展推理阶段的计算投入——即测试时计算（Test-Time Compute）——已成为突破模型能力边界的新主轴。本文从算法谱系（CoT→PRM→MCTS→推理搜索）、标杆对照（o3 vs R1）、工程重构（推理架构、KV Cache、定价模型）与成本经济学四个维度，系统拆解这一范式转换的底层逻辑、落地路径与开发者适配策略，并深入剖析推理阶段算力投入与真实能力提升之间的量化权衡关系，为在预训练红利见顶的2026年寻找第二增长曲线提供可操作的决策参考。

1. 预训练规模定律的黄昏：数据、算力与效能的三重天花板

2019年Kaplan等人提出的语言模型缩放定律（Scaling Laws）曾给整个行业一个简洁的信仰：模型越大、数据越多、算力越强，能力就越强。这个信仰驱动了过去五年从GPT-3到GPT-4、从LLaMA到Llama 3的参数规模军备竞赛。2022年Chinchilla scaling laws进一步修正了方向——不仅模型要大，数据量也要与参数规模同步增长，最优配比约为每1B参数对应20B token。

然而到了2025-2026年，这条曲线开始变得不那么美好了。

Epoch AI在2025年底的研究给出了一个残酷的数字：高质量文本语料的总存量将在2026-2028年间被耗尽。这意味着即便你有无限预算购买H100 GPU，可供模型"学习"的新鲜文本也在急剧减少。合成数据（synthetic data）成为一种替代方案，但合成数据的质量下降和模型坍塌（model collapse）风险尚未被完全解决。

算力侧同样不容乐观。H100级别的训练GPU需求以每年约4倍的速度增长。据行业估算，到2030年仅支持前沿模型的训练就需要近2000万颗加速器——这个数字在当前全球半导体产能约束下几乎不可能实现。更不用说单个训练集群的电力消耗已经逼近一座中型城市的规模。

这些约束叠加起来指向一个判断：预训练规模定律的英雄年代正在落幕。能力增长的边际回报已经出现了明显的递减——从GPT-4到GPT-4o，参数规模未显著扩大（甚至可能缩小）的情况下，能力增益远小于GPT-3到GPT-4的跃升。行业必须找到"第二条曲线"。

这条曲线的名字，就是测试时计算（Test-Time Compute）。

2. 测试时计算的定义、谱系与历史脉络

测试时计算的核心内涵可以概括为：在推理阶段通过增加计算步骤来提升输出质量，而非单纯扩大预训练参数规模。这里的"计算步骤"可以是思考链的展开、候选答案的多次采样与择优、搜索树的回溯与剪枝、甚至是多轮自我修正。

这个想法并非无中生有。梳理它的演进路径，可以看到一条从试探到系统化的清晰脉络：

2022年——萌芽期。 Wang等人提出的Self-Consistency方法首次验证了"多花一点推理算力换更稳定答案"的逻辑：同一个问题用CoT采样多条路径，然后投票选最一致的结果。这本质上是最朴素的测试时计算。

2022年——显式化。 Chain-of-Thought Prompting的提出让推理过程从黑箱变为可见的token序列。Wei等人的工作揭示了一个关键发现：当模型被引导"逐步思考"时，复杂推理任务的准确率出现了跳跃式提升。CoT的价值不仅是准确率，更在于它把推理计算量变成一个可控变量——长CoT = 更多计算 = 更高准确率。

2023年——监督升级。 过程奖励模型（PRM）的出现标志着测试时计算从"暴力采样"走向"智能搜索"。OpenAI在Let's Verify Step by Step中展示了如何为推理路径的每一步打分，从而引导搜索走向更优分支。

2024年——里程碑。 OpenAI o1将Scalable Test-Time Compute的概念推向前台。o1的推理链可以达到数万token，内部走过多轮验证和回溯。其核心技术细节虽未公开，但性能提升的幅度（尤其在数学和代码领域）清晰地证明了"算力换智能"的可行性。

2024年末——里程碑。 OpenAI o3在ARC-AGI-1基准上以87.5%刷新纪录，同时将测试时计算泛化到视觉推理任务。Meta、Google、Mistral等厂商全部跟进，测试时计算成为新一代模型的标配能力。

2025年——开源对齐。 DeepSeek R1 使用少量冷启动CoT引导后，以纯RL路径（GRPO算法）自举出链式推理行为，跳过了传统RLHF中的大规模SFT阶段。R1证明了测试时计算的核心能力可以被低成本地训练出来。

这条脉络揭示了一个关键趋势：测试时计算正在从一种"工程技巧"演变为一套系统化的推理方法论——它有自己的算法家族、训练范式、工程优化和成本经济学。

3. 链式思维（Chain-of-Thought）：推理显式化的起点

CoT的成功不仅在于它提升了准确率，更在于它揭示了语言模型推理的本质困境：模型的计算能力在token层面是均匀的——它对"1+1"和"黎曼猜想"分配相同的单位计算资源。CoT通过将推理过程展开为token序列，打破了这种均匀性，让模型可以对复杂问题分配更多计算。

Zero-shot CoT与Few-shot CoT

CoT有两种触发方式。Zero-shot CoT通过追加一个简单指令——"Let's think step by step"——就能激活模型的推理链行为。Kojima等人的实验表明，这个技巧在数学推理任务上可以带来10-20个百分点的提升。Few-shot CoT则通过提供几个完整的示例（包含推理链和最终答案）来引导模型模仿其推理格式。

这两种方式的本质区别在于：Zero-shot CoT依赖模型在预训练阶段习得的"逐步思考"模式的泛化，而Few-shot CoT则是通过上下文学习（in-context learning）显式注入推理结构。

flowchart LR
    Q["用户提问"] --> P["问题理解"]
    P --> S1["推理步骤 1"]
    S1 --> S2["推理步骤 2"]
    S2 --> S3["...逐步推进..."]
    S3 --> S4["推理步骤 N"]
    S4 --> A["最终答案"]
    S1 -. "回溯修正" .-> P
    style S1 fill:#4a6fa5,color:#fff
    style S3 fill:#6b8ec4,color:#fff
    style S4 fill:#4a6fa5,color:#fff

图1：Chain-of-Thought推理流程图。与普通推理不同的是，CoT将隐式的联想跳跃转化为显式的线性推理步骤序列，每一步都在见证空间（context window）中留下可追溯的中间结果。当模型发现后续步骤与前期推理矛盾时，回溯修正机制允许调整先前的中间结论。

CoT为何有效

Google DeepMind在2024年的一项研究中系统地分析了CoT长度与准确率的关系。核心发现是：CoT长度（step数）与任务复杂度的相关系数约为0.72——模型会自然地为更复杂的问题生成更长的推理链。当人为强制短CoT时（如限制"请用不超过3步思考"），复杂任务的准确率平均下降18%。

但CoT有结构性局限。它是线性单路径的：一旦模型在一个步骤上误入歧途，后面的所有推理都会建立在这个错误基础之上。CoT没有回溯机制——虽然图1中标注了回溯修正，但在纯CoT实现中，这种"修正"只能由模型自身在后续步骤中自发发现并纠正，效率很低。对于需要探索多条路径、比较不同方案的复杂问题，CoT的线性结构力不从心。

这引出了下一层的进化：如何让模型不仅会说"逐步思考"，还会说"这条路不对，换一条试试"？答案是从线性思维转向树状搜索。

4. 自我修正与自举推理：模型内部的"System 2"能力

如果CoT是让模型"一步一步想"，那自我修正（Self-Correction）就是让模型"想完了再检查一遍"。这个机制在人类认知中对应"双系统理论"中的System 2——慢思考、反思、纠错。

Self-Correction的三段式循环

标准的自我修正流程分为三步：生成（Generate）→ 批判（Critique）→ 修订（Revise）。模型先生成一个初始答案，然后以批判者的身份审视这个答案的推理过程，指出潜在的错误或遗漏，最后基于批判意见生成修正版本。这个循环可以重复多轮。

Madaan等人在2023年提出的SELF-REFINE框架展示了这种模式的有效性。在对话、代码生成和数学推理任务上，经过2-3轮自修正后的输出质量显著优于单次生成。关键在于，批判阶段需要使用不同的提示策略——如果让模型用与生成阶段相同的思维模式去检查自己的输出，它往往发现不了问题。

自举推理：多条路径的聚合效应

Self-Bootstrapping（自举推理）采取了不同的策略：不修改单一路径，而是生成多个独立的推理路径，然后通过一致性比较来选优。这背后的直觉是：如果同一个问题，模型在五条独立的推理链中有四条得出相同答案，那么这个答案的可信度远高于单次生成的结果。

Wang等人（2022）的Self-Consistency方法就是自举推理的早期代表。它在CoT基础上引入采样多样性（通过temperature控制），然后用投票或加权聚合选出最一致的答案。该方法在GSM8K（数学推理）和SVAMP（算术推理）上分别将准确率提升了约8%和12%。

关键瓶颈

自我修正有一个被广泛忽视的限制：模型对自身错误的识别能力存在明确的上限。Kadavath等人（2023）在研究中发现，语言模型在判断"自己生成的内容是否正确"时，准确率并不显著高于判断"他人生成的内容"。这意味着当模型的推理在某个节点出现系统性偏差时，自我修正很难发现并纠正——因为这需要模型跳出自己的知识框架来审视自己的输出。

这个限制推动了更激进的方向：不再依赖模型自身做检验，而是训练一个独立的、更精细的评判者——这就是过程奖励模型（PRM）的出发点。

5. 过程奖励模型（PRM）：从结果监督到推理路径监督的信号升级

ORM的先天不足

在PRM出现之前，强化学习用于对齐（RLHF）和推理优化主要依赖结果奖励模型（ORM, Outcome Reward Model）。ORM的做法很简单：给模型的完整输出打一个最终分数——这个回答是对是错？但这个二值信号的信息密度太低。考虑下面的推理过程：

一个苹果5元，小明买了3个苹果和2个橘子，橘子每个3元，他付了50元，找零多少？

步骤1：苹果总价 = 5 × 3 = 15元 ✓
步骤2：橘子总价 = 3 × 2 = 6元 ✓
步骤3：总花费 = 15 + 6 = 25元 ✓（注：此处应为21元）

如果最终答案是25元，ORM会标记为错误——但它无法告诉你错误发生在步骤3的加法上。更致命的是，它无法为步骤1和步骤2的正确推理提供任何正向强化信号。

PRM的信号革命

PRM（Process Reward Model）的核心创新在于：为推理链中的每一步（或每K步）单独打分。这带来了三个关键优势：

1. 定位精度：可以精确定位推理链中错误发生的具体步骤。
2. 部分正确信号：即使最终答案错误，正确的中间步骤仍能获得正向反馈。
3. 搜索引导：在Beam Search或MCTS中，PRM的中间分数可以作为分支选择的决策依据。

flowchart TD
    subgraph ORM["结果奖励模型（ORM）"]
        direction TB
        I1["输入问题"] --> S1["推理链"]
        S1 --> O1["最终答案"]
        O1 --> R1["单一分数"]
        R1 --> F1["正确/错误"]
    end

    subgraph PRM["过程奖励模型（PRM）"]
        direction TB
        I2["输入问题"] --> S2["步骤 1"]
        S2 --> R2_1["分数 0.9"]
        R2_1 --> S3["步骤 2"]
        S3 --> R2_2["分数 0.8"]
        R2_2 --> S4["步骤 3（错误）"]
        S4 --> R2_3["分数 0.2"]
        R2_3 --> O2["最终答案"]
    end

    ORM -. "信号密度低" .-> PRM

    style R1 fill:#d9534f,color:#fff
    style R2_1 fill:#5cb85c,color:#fff
    style R2_2 fill:#5cb85c,color:#fff
    style R2_3 fill:#d9534f,color:#fff

图2：结果奖励模型（ORM）与过程奖励模型（PRM）的信号粒度对比。ORM只能对整个推理链给出单一分数（红框），无法区分正确步骤和错误步骤。PRM为推理链中的每一步赋予分数——正确步骤获得高评分（绿色），错误步获得低评分（红色），使错误定位精确到单步，为后续搜索优化提供精细的引导信号。

PRM的训练方法

PRM的训练经历了从高成本到自动化的演进：

• 人工标注（OpenAI, 2023）：在Let's Verify Step by Step中，OpenAI雇佣标注员对每一步的正确性进行标记。这是最准确的但成本最高——每道数学题的标注成本大约在10-20美元。
• SCR（Self-Consistency-based Reranking）：利用多路径采样的结果一致性作为自动标注信号。如果多条路径在某个步骤后出现分歧，则分歧点可能是一个错误步骤。
• MCTS自动生成：用MCTS搜索树中的节点访问频率和价值估计来自动生成过程标签。Wan等人的AlphaMath框架证明了这种方法的可行性。

PRM在Best-of-N和Beam Search中的应用已经相当成熟。OpenAI的o系列模型据推测在后端使用了大规模的PRM驱动的推理搜索——从数万条候选推理链中筛选出最优路径。

6. 蒙特卡洛树搜索与推理搜索：从AlphaGo到语言模型的范式迁移

MCTS（Monte Carlo Tree Search）在2016年因AlphaGo一战成名，但其与语言模型的结合直到2023-2024年才真正进入工程实践。

将推理建模为搜索问题

MCTS应用到语言模型推理的核心抽象是：将每一步推理token的生成视为一次"落子"，将当前的context window状态视为"棋局"，将最终答案的正确性视为"胜率"。在这个框架下：

• 选择（Selection）：从当前状态出发，使用UCT（Upper Confidence Bound applied to Trees）公式选择最有希望的推理分支
• 扩展（Expansion）：在选定节点上，让模型生成多个后续推理步骤
• 模拟（Simulation）：从新节点出发，用模型快速走完剩余推理链
• 回溯（Backpropagation）：将模拟结果（答案正确与否）向上传播，更新路径上各节点的估值

这个框架与标准自回归解码有根本性差异：后者是贪心的逐token生成，而MCTS是有引导的搜索——它愿意花计算资源去探索看起来不那么有希望的路径，只为了确认它们确实不好。

Tree-of-Thoughts与Graph-of-Thoughts

Yao等人（2023）提出的Tree-of-Thoughts（ToT）框架是MCTS在语言模型上的一次系统化适配。ToT将CoT的线性推理扩展为树状搜索，并在24点游戏、创意写作等需要探索的任务上取得了显著提升。

ToT的关键参数有三个：搜索深度（最多回溯几次）、分支数（每步生成几个候选）和评估方法（如何判断中间状态的质量）。这三个参数共同决定了"推理计算预算"——与预训练时的flops预算类似，在测试时计算范式下，开发者需要为每个请求分配推理计算预算。

Graph-of-Thoughts（GoT, 2024）进一步将树状结构扩展为图状结构，支持推理节点之间的合并、交叉和并行推进。GoT的优势在于可以处理更复杂的任务——例如多文档综合分析——其中不同推理分支的结论需要相互印证或否定。

flowchart TD
    Q["问题"] --> L1_1["推理路径 A-1"]
    Q --> L1_2["推理路径 A-2"]
    Q --> L1_3["推理路径 A-3"]

    L1_1 --> L2_1A["路径 B-1A"]
    L1_1 --> L2_1B["路径 B-1B"]
    L1_2 --> L2_2["路径 B-2"]
    L1_3 -. "剪枝 prune" .-> X["✗"]

    L2_1A --> L3["路径 C"]
    L2_1B -. "回溯" .-> L1_1
    L2_2 --> L3

    L3 --> A["最终答案"]

    style X fill:#d9534f,color:#fff
    style L2_1B fill:#f0ad4e,color:#fff
    style L1_3 fill:#d9534f,color:#fff
    style Q fill:#4a6fa5,color:#fff

图3：推理搜索技术谱系——从CoT到ToT再到MCTS的演进。树状搜索将单一的推理链扩展为多路径并行探索。当搜索评估发现某条路径希望渺茫时（红色剪枝），计算资源被重新分配到更有潜力的分支。当路径C发现与路径B-1B的结论矛盾时，回溯机制允许返回到B-1B节点重新选择——这是CoT不具备的核心能力。

搜索与生成的权衡

推理搜索的核心挑战是计算效率。一个深度为5、分支数为4的搜索树在最坏情况下会产生4⁵ = 1024条完整推理链——每一条都是千万级token的计算量。这使得MCTS风格的推理搜索暂时只能用于高价值的推理任务（数学证明、代码审查、科学文献分析），而对用户日常对话中的简单查询来说，这个开销是不可接受的。

自适应推理深度——让模型自主决定在一个任务上花费多少推理计算量——因此成为2026年的一个关键研究方向。Google的PaLM 2和DeepMind的Chinchilla相关工作已经在这个方向上取得了初步进展。

7. 标杆解剖：OpenAI o3 与 DeepSeek R1 的技术路径深度对照

2025-2026年最受关注的两个推理模型——OpenAI o3和DeepSeek R1——虽然都在测试时计算的旗帜之下，但技术路线几乎背道而驰。将两者放在一起对照，有助于看清测试时计算领域两种范式的本质差异。

OpenAI o3：大规模合成数据 + 强监督搜索

OpenAI o3的技术细节主要由其ARC-AGI-1的表现和一些零星的技术摘要拼凑。从已知信息来看：

o3的推理链可以长达数万token。一条典型的推理链包含问题分解、假设生成、候选方案评估、回溯修正和最终验证等完整环节。支撑这个长链推理的核心基础设施包括：大规模合成训练数据生成管道、过程奖励模型网络、以及内部验证器。

o3在ARC-AGI-1上的87.5%得分（普通人类基线约85%）背后，据估计使用了每任务约数百万token的推理计算量。这个数字远高于o1（约10万token量级）。OpenAI显然相信"计算换智能"的边际回报尚未耗尽——至少对于足够难的任务是这样。

但o3的弱点同样在ARC-AGI-2上暴露了。ARC-AGI-2是比AGI-1更难的分布外测试集。o3在这个测试集上的得分骤降至约4%（o3-low约1.9%，o3-medium约2.9%）。这个落差揭示了测试时计算的一个结构性局限：深度推理可以解决目标分布内的复杂问题，但对分布外（OOD）的泛化能力提升有限。模型在推理链上花了更多计算量，但它仍然受限于训练阶段学到的知识模式和策略空间。

DeepSeek R1：跳过SFT，纯RL自举推理

DeepSeek R1 走的是一条完全不同的路。它的核心创新在于使用少量冷启动CoT引导后，以纯强化学习从基座模型中自举出推理行为，跳过了传统RLHF流程中先做大规模SFT再上RL的阶段。

具体来说，R1使用GRPO（Group Relative Policy Optimization）算法。GRPO与PPO的核心区别在于：它不需要独立的价值网络（critic），而是从同一批采样（group）中计算相对优势。这个简化带来了训练效率的显著提升——在R1的训练过程中，模型只要生成推理链并最终得出正确答案，就会获得正向奖励，而不需要每个中间步骤有人工标注。

R1的冷启动阶段使用了少量经过筛选的CoT数据来引导模型到"推理模式"，但随后的RL训练完全是自举的。这意味着模型的推理策略——包括CoT的长度、分支的时机、回溯的模式——都不是人工设计的，而是模型在RL训练中自发涌现的。

成本方面，R1的训练算力据估计约为同等能力水平闭源模型的1/20。这个数字直接颠覆了"强推理能力必须依赖大规模监督数据"的行业假设。

五维度对比

两种路线的启示

o3和R1并非"谁更好"的关系，而是探索了测试时计算的两条极端路径。o3走的是"无限算力投入换最高精度"的路线，适合对正确性要求极高、预算充裕的场景。R1走的是"用算法效率换低成本"的路线，适合开源生态和成本敏感的商业部署。

对开发者而言，两条路线的存在本身就是好消息——未来可选的不再只是"用哪个API"，而是"用哪种推理策略"。

8. 工程层面的连锁反应：推理基础设施的重构

测试时计算的普及不是在现有推理系统上修修补补，而是要求推理基础设施做一次根本性的架构重构。

从单次前向传播到多步搜索

传统推理系统的核心路径是：接收prompt → 一次前向传播 → 输出token序列。这是O(1)的——处理每个请求的时间基本可预测。

测试时计算改变了这个格局。一个使用Best-of-N或MCTS的推理请求可能触发数十甚至数百次前向传播。这意味着推理系统必须从"单次计算"的SLA保障转向"多步计算"的资源调度。系统不再只是做LLM inference serving，而是在做推理任务编排。

投机解码的新价值

投机解码（Speculative Decoding）——用一个小模型（draft model）快速生成候选token序列，再由大模型做一次性验证——在测试时计算场景下获得了新的意义。在长推理链中，draft模型可以快速展开"看起来合理的推理路径"，而大模型只负责验证和择优。这会显著降低推理搜索中的"每次扩展都要跑大模型"的天价开销。

DeepSeek在其技术报告中提到，R1的推理链实现在某些场景下使用了分层推测策略——一层负责快速路径展开，一层负责质量校验。

动态批处理与KV Cache管理

推理链长度差异巨大的请求给批处理引擎带来了新挑战。传统动态批处理假设所有请求的输入输出长度大致处于同一量级。但在测试时计算场景下，一个简单的"查天气"请求可能输出200个token，而一个复杂的数学证明请求可能产出5万token的推理链。将它们混在同一批次中，短请求会被长请求严重阻塞。

解决方案之一是推理链级别的调度：系统将推理链拆分为"步"的粒度，每步作为一个可调度的计算单元。这相当于在现有的continuous batching之上再加一层调度抽象。

KV Cache的管理也被迫升级。推理链越长，KV Cache的单请求占用越大。在长推理链（数万token）下，单个请求的KV Cache可能消耗数GB的HBM内存。MLA（Multi-head Latent Attention，DeepSeek V2引入）和GQA（Grouped Query Attention）通过压缩KV Cache的维度来缓解这个问题。PageAttention（vLLM的核心技术）通过分页管理避免了KV Cache的内存碎片。

定价模型革命

测试时计算对API定价模式的冲击是直接的：如果一次高价值推理请求消耗了普通请求1000倍的token，按per-token定价就无法区分"需求价值"。OpenAI在o3上引入了"推理预算"（reasoning effort）等级——低/中/高——不同等级对应不同的推理计算上限和不同价格。这个模式本质上是在为推理算力定价，而不是为token定价。

2026年，多家推理API提供商推出了per-answer和per-task的定价方案，标志着推理服务从资源售卖（卖token）向能力交付（卖结果）的演进。

9. 成本经济学的重新审视：从每Token到每正确答案

预训练时代的成本结构极度偏斜：训练成本占90%以上，推理成本在总拥有成本（TCO）中占比不到10%。这意味着开发者几乎不需要关心推理效率——一个API调用的token消耗再大，也远低于分摊到每次推理的训练成本。

测试时计算逆转了这个比例。

推理成本占比的跃迁

以一个典型的"复杂数学证明"请求为例：

• 传统模型（GPT-4o）：输入约500 token，输出约800 token → 成本约 $0.01
• o3推理模式（高预算）：输入约500 token，推理链约50,000 token → 成本约 $0.50-1.00

成本增长了50-100倍。这不是边缘场景——在代码生成、文献分析、法律文书审核等需要深度推理的企业级场景中，推理链长度的增长是系统性的。

"计算换智能"的边际回报

关键问题因此变为：在每个token上花的钱，换来了多少能力提升？ 这个问题的答案取决于任务类型：

• 简单事实问答：深度推理几乎不带来回报。问"法国首都是哪里？"不需要50K token的推理链。分配过度的推理计算不仅浪费，由于无关token的引入甚至可能降低响应质量。
• 中等难度任务（编程debug、事务处理）：适度推理（2-5条CoT路径 + 自一致性）带来约15-25%的准确率提升，十倍于无推理的成本，ROI可接受。
• 高难度任务（数学证明、科研分析）：深度推理（MCTS、30+条候选 + PRM排序）可能带来50%+的准确率提升，成本增长100倍。对于"判对决定胜负"的场景——如代码安全审计——这个ROI是划算的。

关键设计原则：推理深度不应该是一个全局配置，而应该根据任务复杂度动态调整。Google的Adaptive Computation Time和DeepSeek的"pass@k vs compute"分析都指向同一个方向——让模型自己决定在每个问题上投入多少推理计算。

企业部署的策略建议

对预算敏感的企业部署场景，三层的推理策略分级已被验证为有效：

1. 浅推理层（非CoT）：用于客服对话、信息检索等简单任务。使用普通生成模式，temperature=0。
2. 中推理层（CoT + Best-of-4）：用于代码辅助、数据分析等需要一定推理的任务。采样4条路径，自一致性投票。
3. 深推理层（CoT + PRM搜索）：用于合同审核、技术决策等高价值任务。使用PRM引导的Beam Search，最多搜索64条路径。

10. 局限、争议与未来方向

测试时计算的爆发式增长不应该掩盖它仍然面临的根本性问题。

推理的可扩展性天花板

推理链越长，注意力稀释问题越严重。当CoT长度超过模型在训练时见过的最大序列长度时，注意力分布的置信度会显著下降。更关键的是长推理链中的错误累积：每一步推理都有一定的错误概率，当推理链有100步时，即使单步错误率只有1%，整条链的无错概率也只有约36.6%。自我修正和PRM可以缓解这个问题，但无法根除——因为PM的评分本身也有误差。

过度推理的效率损失

并非所有任务都适合深度推理。对于简单任务——"今天天气怎么样"或"提醒我下午三点开会"——使用多轮MCTS搜索的结果可能比直接输出更差，因为模型在"过度思考"中加入了不必要的条件和假设。Sweet Spot（甜区）的概念正在成为行业共识：每个请求存在一个最优推理深度，低于这个深度准确率不够，高于这个深度边际回报为负。

ARC-AGI-2的警示

o3在ARC-AGI-1（87.5%）和ARC-AGI-2（约4%）之间的巨大落差是整个测试时计算范式最值得警惕的信号。ARC-AGI-2的设计原则是"看起来与AGI-1类似，但要求真正的泛化而不是模式匹配"。o3在这个测试集上的惨败表明：目前的推理搜索本质上仍是在训练分布（或邻近分布）内搜索最优路径，而不是真正意义上的"理解"。当面对与训练数据分布差异足够大的新问题时，再多的推理计算也无法弥补这个空白。

未来方向

三个方向值得追踪：

1. 自适应推理深度：让模型自主感知任务复杂度并决定推理预算。当前的主要方案有"budget forcing"（DeepSeek-R1）、"adaptive computation time"（Google）和"early exit with confidence threshold"。2026年下半年很可能出现首个生产级的自适应推理API。
2. 推理能力蒸馏：将大模型（o3级别）通过长时间推理产生的"推理链"数据蒸馏回小模型，让小模型在不经过显式推理搜索的情况下也能具备一定推理能力。DeepSeek R1已经展示了这个方向的可行性——蒸馏版R1在数学推理上超过了同等规模的所有模型。
3. Agentic Test-Time Compute：将推理搜索扩展到对外部工具的调用。模型在推理过程中不仅可以"想"还可以"查"——调用搜索引擎验证事实、运行代码验证逻辑、查询数据库确认数据。这可能是测试时计算的下一个量级跨越。

11. 开发者行动指南：如何适配Test-Time Compute新范式

对开发者而言，测试时计算范式的到来意味着调整是系统性的，从API调用策略到架构设计再到成本模型。

API调用策略

• 利用采样多样性做隐式Best-of-N：如果API不支持显式的"推理预算"配置，可以通过设置temperature=0.7-0.9、top-p=0.95来获得多样化的推理路径，然后自行聚合（投票或加权合并）。在GSM8K上，这个技巧可以将单次调用的准确率从约75%提升到约85%。
• 缓存推理链：对同一类型的问题，第一个请求的推理链可以缓存起来。后续相同或相似的问题可以复用或微调缓存的推理模式，避免每次都从头搜索。在客服场景中，推理链缓存可以将推理token消耗降低40-60%。

架构调整

• 推理深度路由：在应用层引入一个"复杂度分类器"——一个简单的分类模型或规则引擎——来预估请求的推理需求等级。简单请求直接发往非推理端点（如GPT-4o-mini），复杂请求发往推理端点（如o3-mini-high）。这个分层路由可以防止推理API预算被简单请求浪费。
• 混合模型策略：对于需要高精度但成本敏感的流程，采用"小模型生成 + 大模型验证"的模式。例如，DeepSeek-R1-Distill-Llama-70B负责初步推理，o3-mini负责验证和纠错。在代码审查场景中，这个模式可以将成本降低约60%，同时保持接近全量o3的准确率。

成本管控

• 设置推理预算上限：为每个请求或每个用户设置最大推理token数。这对应o3的"reasoning_effort"参数（low/medium/high）在API层面提供了控制，但应用层仍需要额外的硬上限防止失控。
• 按请求价值分配推理预算：并非所有用户请求都值得同样的推理投入。可识别高价值请求（企业客户、付费用户的关键决策请求）和低价值请求（免费用户的闲聊），分配不同的推理层。

12. 结语：两条Scaling Law的交汇

预训练Scaling Law与测试时计算Scaling Law并非替代关系，而是互补的双轮驱动。

预训练Scaling Law决定模型的知识储备上限——它能记住多少事实、理解多少语言模式、覆盖多少领域。测试时计算Scaling Law决定模型的推理深度上限——它能在给定知识的基础上，通过计算资源的投入，达到多高的推理质量。

用Meta在2026年内部技术分享中的一句话来概括："预训练给你的是词汇表，测试时计算给你的是查字典的时间。"

对开发者而言，核心启示是：不要再只盯着模型参数大小和基准分数。一个140B参数但不支持推理搜索的模型，在某些复杂任务上的实际表现可能不如一个70B参数但配有PRM引导搜索的模型。评估模型时，应该将"推理策略"作为与"模型权重"同等重要的维度。

回头再看开篇的问题——当一个模型在面对一个它从未见过的复杂问题，使用5000 token生成推理链时，它真的在"思考"吗？这个问题可能没有确切的答案。但有一点是确定的：这条推理链上的5000个token，每一个都经过了精心搜索、验证和择优——这个过程的工程价值，已经远远超出了对"机器是否真的在思考"的哲学讨论。

测试时计算不是万能钥匙。它无法让模型获得训练数据中没有的知识（如最新事件的时间线），也无法让模型跳出其策略空间的限制去"真正创造"。但在它适用的领域——数学、代码、逻辑推理、结构化决策——它提供的性能提升是预训练参数扩大100倍才能达到的。而成本只有后者的零头。

这才是"新的Scaling Law"的真正含义：不是用更大的训练集群烧更多的钱，而是在推理阶段更聪明地使用已有的算力。