一、同一道题，多想一会儿确实更对#

先看一道小学题：

3 个人 3 天做 3 个零件，9 个人 9 天做几个零件？

标准模型的典型回答是 9：人数和天数都乘了 3，答案就乘 3。推理模型会先把速率拆出来：3 人 3 天做 3 个，说明 3 人 1 天做 1 个，也就是 1 人 1 天做 1/3 个；9 人 9 天就是 9 × 9 × 1/3 = 27。它多花了几百个 token，把一个会被直觉带偏的题做对了。

这个对比很容易让人得出一个结论：多想一会儿 = 更聪明。但把同一套配置换到另一类任务上，结论会立刻变形。

比如从一份采购合同里抽「付款账期」。合同正文写「验收后 30 日内付款」，补充条款写「账期以附件二为准」，附件二又写「月结 60 天」。标准模型可能直接返回 30；推理模型则会写一段很长的推理，论证「正文优先」「附件是补充」「以验收日为起点」，最后给出一个看起来很严谨的 30 天，或者 60 天——它没有停下来指出这三处互相冲突。

两件事放在一起，才是这篇文章的起点：test-time compute 不是一枚「质量旋钮」。它是一组把推理时间换成准确率的手段，有明确的适用条件，也有明确的失效方式。用对了，它能把一个做不对的任务抬过可用线；用错了，它只是让你为同一个错误多付几倍的钱。

二、先把「推理模型」拆成两件事#

「推理模型」这个词经常把两个层面的东西混在一起：

一个模型可以在训练侧被专门训练成「愿意长时间思考」，也可以在推理侧被要求「多想几步」；两者可以叠加，但不是一回事。推理侧的手段并不要求模型经过推理训练——自洽性投票、best-of-n、树搜索，这些方法在普通指令模型上也能用，只是收益通常更小。

另一个容易踩的坑是计费单位。推理模型产生的 thinking token（不同厂商叫 reasoning token、thinking token 或内部推理 token）通常按输出 token 计费，而且会计入 max_tokens / max_completion_tokens 这类总预算。也就是说：

• 你看到的输出可能只有 200 个 token，账单上却按 2,200 个输出 token 算；
• 预算给少了，模型可能把预算全花在思考上，最后返回一个空答案或半截答案；
• 「思维链不可见」不等于「思维链不花钱」。

后面所有的成本计算，都建立在这一点上。

三、四个旋钮，四种成本形状#

把推理侧的手段拆开，常用的其实是四个旋钮。它们买的不是同一种东西，成本曲线也不一样。

它们有一个共同的上限：正确路径必须已经在模型的输出分布里，而且你得有办法把它认出来。 前者决定「采样有没有用」，后者决定「采样之后能不能选对」。这两个前提，值得单独拆开看。

四、前提一：路径覆盖——样本再多，也救不回共享的错误前提#

自洽性（self-consistency）的常见说法是：采样 k 条思维链，取多数答案，准确率就会上升。这个说法隐含了一个很强的假设：样本之间是独立的。现实里，模型的多条样本往往共享同一个错误前提。

写一个小模拟就能看清这件事。假设：

• 有 15% 的概率，模型从一开始就理解错了题意（q = 0.15）。这时 k 条样本会一起错，而且错得一致；
• 在理解正确的前提下，每条样本有 60% 的概率得到正确答案（p = 0.60），否则随机落到 20 个错误答案之一。

1
import random, collections
2

3
def simulate(k, q=0.15, p=0.60, trials=50000, seed=7):
4
    rng = random.Random(seed)
5
    maj = any_ok = 0
6
    for _ in range(trials):
7
        if rng.random() < q:
8
            votes = ["shared_wrong"] * k       # 共享错误前提：k 条一起错
9
        else:
10
            votes = ["right" if rng.random() < p else f"w{rng.randrange(20)}"
11
                     for _ in range(k)]
12
        top = collections.Counter(votes).most_common(1)[0][0]
13
        maj += top == "right"
14
        any_ok += "right" in votes
15
    return maj / trials, any_ok / trials
16

17
for k in (1, 3, 5, 9, 15):
18
    m, a = simulate(k)
19
    print(f"k={k:<2} majority={m:.3f} pass@k={a:.3f}")

输出：

1
k=1  majority=0.512 pass@k=0.512
2
k=3  majority=0.629 pass@k=0.795
3
k=5  majority=0.773 pass@k=0.843
4
k=9  majority=0.836 pass@k=0.849
5
k=15 majority=0.848 pass@k=0.849

三个读数值得注意：

1. pass@k 的上限是 0.85，不是 1。 因为 15% 的情况下所有样本共享同一个错误前提，采样再多也覆盖不到正确路径。这就是「路径覆盖」的上限。
2. 多数投票也会撞到同一个上限。 k 从 1 加到 15，多数投票从 0.512 升到 0.848，然后停住。它并没有把「至少一条对」变成「交付的那条对」的免费转换器。
3. k=5 时，pass@k 是 0.843，多数投票只有 0.773。 中间那 7 个百分点，就是「选择器」的缺口。候选里有正确答案，但你没能把它选出来。

这个模拟的参数是人为设定的，但结构在真实任务里很常见：模型把「附件二」当成「附件一」，把「税前」读成「税后」，把「不含运费」漏掉——这些错误不会因为采样次数增加而分散，只会被重复采样放大成一种「共识」。

所以看到一个「多采样几条、取多数」的方案时，先问两个问题：

• 这个任务的错误，是分散的随机错误，还是共享的前提错误？前者投票有用，后者投票有害。
• 你有没有一个独立于采样过程的选择器？如果没有，多数投票只是成本较低的选择器，不是可靠的选择器。

五、前提二：可判定——没有验证器，搜索只是掷骰子#

第二个前提是「可判定」：你得能在多个候选里判断哪个更对。

验证器的强弱，直接决定了 test-time compute 的回报。把验证器按可靠性排一下：

一个反直觉的结论是：best-of-n 的效果上限由验证器决定，而不是由 n 决定。 如果验证器把一个错误答案排在第一，采样 100 条也只是给这个错误答案增加候选；如果验证器和生成器同源、共享同一套偏好，它会把生成器的错误也一起「验证」过去。

这也是为什么推理模型在数学和代码上看起来进步明显：这两类任务恰好有便宜、可靠、可自动化的验证器。数学题可以对答案，代码可以跑测试。换到开放写作、战略判断、需求优先级，验证器要么很贵（人工），要么很弱（LLM 打分），test-time compute 的回报就会明显下降。

六、买不到的四样东西#

把「买不到」的部分单独列出来，比列「买到了什么」更有用。

七、成本曲线：按「每个正确答案」算账#

比较两个配置，不能只比「每次调用多少钱」，也不能只比「准确率多少」。把两者放在一起，才有可比的单位：每个正确答案的成本。

先看一个简化的算例。假设：

• 输入 1,500 token，答案 300 token；
• 示例单价：输入 1 元 / 百万 token，输出 4 元 / 百万 token（只为演示数量级，不代表任何厂商的真实报价）；
• 标准模型每次调用 0.00270 元；
• 推理模型多花 2,000 个推理 token，每次调用 0.01070 元，准确率 0.90。

1
IN_TOK, OUT_TOK = 1500, 300
2
PI, PO = 1.0, 4.0          # 示例单价：元 / 百万 token
3
BASE = (IN_TOK * PI + OUT_TOK * PO) / 1e6
4

5
def per_correct(cost, acc):
6
    return cost / acc
7

8
def reasoning(think, acc):
9
    cost = (IN_TOK * PI + (OUT_TOK + think) * PO) / 1e6
10
    return cost, per_correct(cost, acc)
11

12
for a in (0.25, 0.50, 0.75):
13
    c, pc = reasoning(2000, 0.90)
14
    print(f"std acc={a:.2f}  std/correct={per_correct(BASE, a):.5f}  "
15
          f"reason/correct={pc:.5f}")

输出：

1
std acc=0.25  std/correct=0.01080  reason/correct=0.01189
2
std acc=0.50  std/correct=0.00540  reason/correct=0.01189
3
std acc=0.75  std/correct=0.00360  reason/correct=0.01189

结果有点反直觉：即使标准模型的准确率只有 25%，推理模型的「每个正确答案成本」仍然略高（0.01189 对 0.01080）。原因很简单——推理模型每次调用贵了约 4 倍，而准确率最多只能到 1，单位正确成本不可能低于单次调用成本。

把盈亏平衡点算出来：

1
a0* = a1 × c0 / c1
2
    = 0.90 × 0.00270 / 0.01070
3
    ≈ 0.227

也就是说，在这个示例单价下，只有当标准模型的准确率低于约 22.7% 时，推理模型才在「每个正确答案」上更便宜。标准模型越准，推理模型越难靠成本说服人。

这不是说推理模型没有价值，而是说它的价值不在「普遍更省钱」。它买到的是：在标准模型几乎做不对、而错误又足够昂贵的任务上，把正确率抬过可用线。 如果一次错误要人工复核 30 分钟，多付几厘钱把准确率从 25% 抬到 90%，账立刻就算得过来；如果错误只是让用户多点一次重试，推理模型的溢价就很难成立。

1
级联成本 = 0.00270 + (1 - 0.60) × 0.01070 ≈ 0.00698
2
级联准确率 = 0.60 + 0.40 × 0.90 = 0.96
3
每个正确答案成本 ≈ 0.00698 / 0.96 ≈ 0.00727

八、什么时候值得开推理：一张决策表#

把前面的条件收成一张表。判断顺序是：先问「错了能不能被发现」，再问「这个错误值不值得多花钱」。

一个实用的经验法则：如果这个任务错了以后，你能在 5 分钟内写出一条自动检查，推理预算就值得花；如果检查本身要靠人看半天，先把预算花在「让人更快发现错误」上。

九、工程落地：把预算花在刀刃上#

1
type Result = { text: string; finishReason: string; reasoningTokens: number };
2

3
async function ask(prompt: string, budget: number): Promise<Result> {
4
  const r = await callModel({ prompt, maxOutputTokens: budget });
5
  if (r.finishReason === "length") {
6
    // 预算可能被推理 token 吃光，答案被截断或为空。
7
    // 不要静默返回空字符串：要么加预算重试，要么降级到非推理模型。
8
    return ask(prompt, Math.ceil(budget * 1.5));
9
  }
10
  return r;
11
}

十、评测陷阱：别用「感觉更聪明」做结论#

推理模型很容易在演示里显得更强，因为演示通常挑的是「标准模型答错、推理模型答对」的题。评测方法本身——公共基准、自建评测集、A/B 与人工评估——在《如何科学评测一个 LLM 应用》里已经展开，这里只列推理模型特有的几个陷阱。

1. 同成本比较，而不是同模型比较。 公平的对照是：标准模型在同样的 token 预算下采样多次（或加长提示词），对比推理模型的一次调用。只拿「标准模型一次」对「推理模型一次」，你比较的是预算，不是模型。

2. 同时报告准确率、token 和延迟。 只看准确率，会把「贵 4 倍、慢 20 秒」的代价藏起来；只看成本，又会把「便宜但不可用」的配置留下。

3. 公共基准有污染风险。 数学和代码 benchmark 的题目可能出现在训练数据里。至少留一套私有题、改写题或时间上更近的题，作为对照。

4. 多数投票的高一致不等于高正确。 前文的模拟已经说明：共享错误前提会让多条样本一起错、且错得一致。把「一致率」当成置信度，会在正需要报警的时候给出高分。

5. LLM-as-a-Judge 与生成器同源时有系统性偏差。 用同一个模型家族做裁判，它更容易认可自己风格的答案。能用规则就用规则；必须用模型时，换一个家族、交换位置、加人工抽样。

6. 思维链不是模型的真实计算过程。 它是模型生成的文本，不是可审计的内部状态。把 CoT 当成「它为什么这么答」的证据，容易过度信任；把 CoT 原样回放给用户，还可能泄露提示词、内部数据或本不该出现的推理细节。

十一、五个反复踩的坑#

1. 预算被思考吃光，返回空答案。 max_tokens 是总预算，不是答案预算。看到长度截断就重试或降级，别把空字符串当成模型「不会」。
2. 把推理 token 当成免费或不可见。 它按输出计费，通常还更贵。账单对不上时，先查 reasoning token，再查重试。
3. 没有验证器就上自洽投票。 错误相关时，投票会把同一个错误放大成共识；先确认错误是分散的，再谈采样。
4. 用同源 LLM 当验证器。 生成器和裁判共享偏好，裁判会把生成器的错误一起放过。优先用规则、测试、Schema，其次才是异源模型加人工抽样。
5. 把思维链原样回放给用户或写进日志。 它可能包含敏感信息、错误假设和不适合展示的内部推理。对外给结论和证据，对内只留脱敏摘要。

十二、小结#

• 推理模型是两层东西。 训练侧让模型「愿意想」，推理侧让你「让它多想」；后者不要求前者，但前者的收益通常更大。
• test-time compute 买的是采样、搜索和选择，不是智力。 它的上限由两件事决定：正确路径在不在输出分布里，以及你有没有可靠的验证器。
• 错误相关时，多采样会加固错误。 共享的错误前提不会因为 k 变大而分散；多数投票只能处理分散的随机错误。
• 验证器决定搜索的上限。 数学和代码好看，是因为它们有便宜可靠的验证器；开放任务的回报会明显下降。
• 推理买不到知识、题意、外部状态和低延迟。 缺知识补检索，有歧义先澄清，要状态调工具，延迟敏感就级联或降级。
• 按每个正确答案算账。 推理模型通常每次更贵；只有当标准模型准确率足够低、且错误足够昂贵时，溢价才划算。
• 级联的关键是验证器。 没有验证器的级联只是随机分流；有验证器，才能把预算花在真正需要的请求上。
• 把截断、token、延迟、升级率都记下来。 没有这些数，你无法判断下一次该加预算、换模型，还是改验证器。

参考来源#

• Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters（Snell et al., 2024）
• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（Wei et al., 2022）
• Self-Consistency Improves Chain of Thought Reasoning in Language Models（Wang et al., 2022）
• Let’s Verify Step by Step（Lightman et al., 2023）
• Large Language Monkeys: Scaling Inference Compute with Repeated Sampling（Brown et al., 2024）
• Large Language Models Cannot Self-Correct Reasoning Yet（Huang et al., 2023）
• Self-Refine: Iterative Refinement with Self-Feedback（Madaan et al., 2023）
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning（2025）
• s1: Simple test-time scaling（2025）
• OpenAI：Learning to reason with LLMs
• OpenAI Reasoning models 文档（推理 token 与计费说明）