详细解释
测试时计算扩展（Test-Time Compute，简称 TTC，也称 Test-Time Scaling 或推理时扩展）指的是在模型训练完成之后，于推理（也叫测试）阶段通过多花算力来换取更高准确率的一类技术。它之所以被称为「第三条扩展轴」，是因为在大模型发展的前几年，提升效果主要靠两条路线：一是把训练时的模型参数量做大，二是把训练数据量做大。而 2024 年之后的研究（见 测试时计算扩展论文）与 推理模型 的实践都表明，在推理阶段多花算力——让模型多采样几条候选、多做几步搜索、多轮自我反思——也能显著提升准确率，而且在小模型上甚至比「直接换一个更大的模型」更划算。换句话说，测试时计算让「花算力换准确率」这件事不再只发生在训练阶段，而是可以在每次请求到来时按需用上。
主流技术路线可以清晰分为两类，第一类是搜索型：并行采样 N 条候选，再用验证器或奖励模型挑出最好的那条。代表做法有 Best-of-N 采样（生成 N 条并选最优）、束搜索（Beam Search，按累积概率保留若干条最优路径）以及 思维树（Tree-of-Thoughts，把推理组织成可回溯搜索的树）。这类方法的共同点是「并行度换准确率」，延迟增长相对可控，但依赖一个可靠的挑选机制。第二类是修订型：串行地对同一答案反复自我反思与迭代修订，代表做法是 Self-Refine（自我精炼）与各种顺序修订（Sequential Revision）。这类方法不需要并行采样，但对推理链质量的要求更高，且延迟随修订轮数线性增长。此外，自一致性 投票（Self-Consistency，让模型用不同随机路径解同一题再投票）介于两者之间，它既并行采样又用投票而非外部验证器来汇总，工程上非常好落地。无论哪一类，其底层都依托 思维链 让模型把中间推理写出来，才有可搜索、可打分的空间。
测试时计算的收益曲线是「对数型」的：从采样 1 条涨到 8 条，收益提升最明显；继续涨到 32 条、64 条以上，边际递减非常明显，通常需要数量级的算力才能再换来几个百分点的准确率。因此工程上的关键不是「无脑拉高 N」，而是「按请求难度动态分配推理预算」——简单任务用基线预算，难题才加大多样本数或搜索深度。唯元智创 的网关把测试时计算封装成可分级的推理预算档位，支持按请求难度、租户等级与延迟敏感度自动路由到不同档位，并在有可验证结果的场景下接入判对器做 Best-of-N 挑选，让企业不必自己实现采样编排与验证逻辑，也能把算力精准花在真正需要它的难题上。
训练时扩展与测试时扩展对比表
| 扩展轴 | 成本投入位置 | 见效速度 | 典型收益 | 边际递减拐点 | 对延迟影响 | 适用场景 |
|---|---|---|---|---|---|---|
| 训练时扩参数量 | 一次性训练算力与后续推理成本 | 慢，需重新训练与部署 | 能力全面提升，泛化好 | 参数量按倍数增长后收益放缓 | 单次推理略增 | 通用底座模型 |
| 训练时扩数据量 | 数据采集、清洗与训练算力 | 慢，需数据管线与再训练 | 覆盖更广、幻觉更少 | 数据质量下降后收益锐减 | 基本不变 | 领域能力补齐 |
| 测试时扩采样数（搜索型） | 每次请求的推理算力 | 快，改配置即可生效 | 数学推理等任务提升明显 | 超过 32 条候选后明显递减 | 并行采样可控，成本线性上升 | 有明确判对标准的难题 |
| 测试时扩反思轮数（修订型） | 每次请求的推理算力 | 快，无需重训 | 写作、代码修订等提升明显 | 超过 3 至 5 轮后收益有限 | 延迟随轮数线性增长 | 可迭代打磨的开放任务 |
| 混合策略（训练打底 加 推理加码） | 训练与每次请求双重投入 | 中，需两者配合 | 综合收益最高 | 两者各自拐点叠加 | 可控，按难度分级 | 生产环境主流选择 |
推理时扩展策略对比表
| 策略 | 并行度 | 是否需验证器 | 典型准确率增益 | 延迟倍数 | Token 成本倍数 | 适用范围 |
|---|---|---|---|---|---|---|
| 贪心解码（1 倍基线） | 1 | 否 | 基线 | 1 倍 | 1 倍 | 所有任务的基础模式 |
| Best-of-N 采样（N 为 8） | 8 | 是 | 视任务 5 至 20 个百分点 | 约 8 倍并行，可控 | 约 8 倍 | 有判对标准或强奖励模型的难题 |
| 自一致性投票 | 5 至 40 | 否，用投票代替 | 视任务 3 至 15 个百分点 | 随采样数上升 | 随采样数上升 | 有唯一答案的推理题 |
| 思维树 与 束搜索 | 分支数 乘 深度 | 是，需过程打分 | 复杂推理提升显著 | 高，搜索开销大 | 高，随节点数增长 | 需要多步规划与回溯的任务 |
| 序列化自我反思（Self-Refine） | 1 | 否，靠自评 | 视任务 2 至 10 个百分点 | 随轮数线性增长 | 随轮数线性增长 | 写作、代码、开放生成 |
| 唯元智创 推理预算分级档位 | 按难度自适应 | 可接判对器 | 按档位 2 至 20 个百分点 | 低档近乎不变，高档可控 | 按档位计费 | 生产环境按请求难度路由 |
实战经验与避坑
-
收益曲线是对数型的，采样从 1 涨到 8 条收益最大，涨到 32 条以上边际递减明显，不要无脑拉高 N：很多团队一看到 Best-of-N 有效，就把采样数一路拉到 64 甚至 128，结果 Token 成本涨了几十倍，准确率只多了两三个百分点。2026 年公开档的经验是：采样数从 1 涨到 8 时，多数推理任务的准确率提升最快；从 8 到 32 提升明显放缓；超过 32 之后，往往要再翻好几倍算力才能换来一两个百分点。所以务实的做法是把 N 默认设为 8 到 16，只有当请求被识别为「高难度且可验证」时才临时上调，用难度路由把预算花在刀刃上，而不是让所有请求都跑满 N。
-
必须有可靠的验证手段，否则 Best-of-N 会放大「流畅但错误」的答案：Best-of-N 的成败几乎完全取决于「挑最好的那条」这一步是否可靠。如果判对标准模糊、或奖励模型没有校准，模型很容易选出措辞最流畅、最像标准答案的那一条，而它恰恰可能是错的，此时采样数越多，选中错误答案的概率反而越高。可靠验证有两种：一是可验证结果的判对器（数学题能数值校验、代码题能跑单测、结构化抽取能字段比对），二是有 过程奖励模型 或 对数概率 支撑的、经过校准的打分器。没有这两者之一时，应改用 自一致性 投票这类不依赖外部验证器的汇总方式。
-
简单任务开测试时扩展是纯浪费，必须做任务分级：分类、抽取、格式转换、简单改写这类任务的正确答案往往唯一且模型一次就能做对，此时开 Best-of-N 或自我反思只是把同一份正确结果重复算了 8 遍，成本和延迟翻几倍而准确率毫无变化。正确做法是先做任务分级：建立一张「任务类型到推理预算」的路由表，把简单任务固定为基线预算，只有数学推理、多步规划、复杂代码、长链条分析这类真正有难度的任务才启用测试时扩展。实测中，做过分级路由的系统相比「全量开高档」，能在保持几乎相同准确率的前提下把整体推理成本降低 50% 至 70%。
-
延迟敏感场景要用并行采样而不是串行修订，串行修订延迟随轮数线性增长：搜索型（Best-of-N、自一致性）的 N 条候选可以并行生成，只要推理集群并发足够，延迟大致等于生成一条的时间加上汇总时间；而修订型（Self-Refine 等）必须一轮接一轮串行执行，第 2 轮依赖第 1 轮的结果，延迟随轮数近似线性增长，3 轮就是 3 倍延迟起步。因此对实时对话、在线 Agent 这类延迟敏感场景，应优先选并行采样；只有在离线批处理或用户可接受长等待的场景，才使用串行自我反思，并严格控制轮数（经验上 2 至 3 轮往往已到性价比拐点）。
-
要把推理 Token 成本计入预算，测试时扩展的计费是真实翻倍的：测试时扩展省不了钱，它本质是「多花 Token 换准确率」。开 8 条采样就是 8 倍的输出 Token 成本，若再叠加思维链的长推理，单次请求的费用可能涨到基线的十倍以上。因此上线前必须把「准确率提升」与「Token 成本上升」放在一起算账：如果某个任务准确率只提升 2 个百分点、成本却涨了 8 倍，那多半不值得；反之若是关键的高价值难题（如合同条款核验、复杂数学证明），昂贵但准确率显著提升则是划算的。建议按租户或业务线设置独立的测试时预算上限，避免个别高难度请求把整体成本打爆。
-
生产环境要按请求难度做动态路由，只把预算花在难题上：静态地把所有请求都设成同一个推理预算档位，要么浪费（简单任务）要么不够（难题）。更聪明的做法是先用一个轻量判断（可以是小模型打分、也可以是规则与置信度信号）估计请求难度，再决定给多少测试时预算。例如低难度请求走基线预算，中等难度走 N 为 8 的采样，高难度且可验证的请求才走高 N 加判对器。难点在于难度判断本身要够快够准，否则路由开销会吃掉收益。实测中，一个简单的「先让模型自评置信度再决定预算」的两段式方案，就能在几乎不损失准确率的情况下省下大半测试时算力。