让AI“多想一会儿“比换更大模型更有效：Test-Time Compute的工程化路径

陆业聪

520人浏览 · 2026-05-17 01:00:49

陆业聪 · 2026-05-17 01:00:49 发布

有个反常识的现象：GPT-4o 在数学推理上的表现，经常被一个参数量只有它 1/10 的模型打败——前提是让小模型"多想一会儿"。

这不是玄学。Lilian Weng（前 OpenAI 安全负责人）上个月发布了一篇系统性综述 “Why We Think”，把 test-time compute 的整个研究脉络梳理了一遍。读完之后我的感受是：2026年大模型竞争的核心维度，正在从"训练时砸多少卡"转向"推理时怎么花算力"。

这对工程师意味着什么？它意味着你不需要等下一代模型发布，就能让现有模型在困难任务上性能翻倍。而且这不是调参玄学——有清晰的工程化路径。

一、什么是 Test-Time Compute？

最简单的理解：训练阶段的 compute 决定模型"知道什么"，推理阶段的 compute 决定模型"能想多深"。

传统做法是把所有算力都花在预训练上——更大的模型、更多的 token、更长的训练。但 2024 年之后，一个共识逐渐清晰：对于需要复杂推理的任务，在推理时动态增加计算量，收益比增大模型参数高得多。

打个比方：考试时你面对一道难题，花 5 分钟思考和花 30 秒随手写答案，正确率完全不是一个数量级。但如果你基础知识不扎实（训练不够），光给你时间也没用。两者是互补关系。

核心思想

Test-time compute 不是一种具体技术，而是一族策略。它们的共同点是：让模型在回答之前做更多计算。具体手段包括：

• Chain-of-Thought (CoT)：生成中间推理步骤

• Self-Consistency：多次采样，投票选最优答案

• Tree Search / MCTS：在推理空间中做树搜索

• Iterative Refinement：生成→验证→修正循环

• Verifier-guided Decoding：用一个验证器评分，引导生成方向

二、为什么"多想一会儿"效果这么好？

这里有一个来自 DeepMind 2024 年论文的关键发现：给定固定的总 FLOP 预算，把算力分配到 test-time（而不是全部用于训练更大模型）的策略，在数学和代码任务上胜率压倒性地高。

我的理解是这样的：大模型在预训练阶段学到的是"模式库"——它见过大量推理链，知道推理应该长什么样。但面对一道新题，单次前向传播（一次生成）很容易走歪。如果你允许它多生成几条路径、回溯、验证，本质上是在推理空间里做搜索——这跟 AlphaGo 的蒙特卡洛树搜索是同一思路。

关键直觉：预训练给了模型"棋感"，test-time compute 给了模型"深度计算"的能力。两者结合，才是完整的推理能力。这就是 Lilian Weng 文章标题 “Why We Think” 的含义——思考本身就是一种计算资源的投入。

数据说话：Scaling Law 在推理端的表现

几个有代表性的数据点：

• MATH benchmark：PaLM 2-S（小模型）用 64 次采样 + majority voting，性能追平 PaLM 2-L（大模型）单次输出。算力差异约 8x vs 1x，但模型参数差 5 倍。

• GSM8K：Llama-3-8B 单次准确率约 79%，32 次采样 + 验证器选答案可以到 95%+，逼近 GPT-4 级别。

• DeepSeek-R1：通过 RL 训练模型学会"自主延长思考链"，在 AIME 数学竞赛上从 15% 暴涨到 71%。

这个趋势的工程含义是：对于很多实际场景，与其升级到更贵的模型，不如在当前模型上投入更多推理计算。特别是当任务难度可预估时，可以动态调配。

三、工程化实践：三种可落地的策略

策略一：Self-Consistency（最简单，立即可用）

思路：对同一个问题多次采样（temperature > 0），然后用投票或评分选最好的。这是最容易落地的 test-time compute 策略。

import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI()

async def self_consistency(
    prompt: str,
    n_samples: int = 8,
    model: str = "gpt-4o-mini"
) -> str:
    # 并发采样 n 次
    tasks = [
        client.chat.completions.create(
            model=model,
            messages=[{"role": "user",
                       "content": prompt}],
            temperature=0.7,
            max_tokens=2048
        )
        for _ in range(n_samples)
    ]
    responses = await asyncio.gather(*tasks)

    # 提取答案并投票
    answers = [
        extract_final_answer(r.choices[0]
            .message.content)
        for r in responses
    ]
    return majority_vote(answers)

这段代码的核心价值在于：用 gpt-4o-mini 的价格，靠 8 次并发调用，达到接近 gpt-4o 的准确率。在数学、代码生成、逻辑推理类任务上提升尤其明显（通常 10-20 个百分点）。

策略二：Verifier-Guided Best-of-N

Self-consistency 的升级版：不用简单投票，而是训练一个 verifier（验证器）给每个答案打分，选分最高的。

OpenAI 在 2021 年的论文 “Training Verifiers to Solve Math Word Problems” 就证明了这一点：一个 6B 参数的 verifier 配合 175B 的生成器，Best-of-100 策略在 GSM8K 上从 55% 提升到 77%。

工程上的关键决策是 Outcome-level vs Process-level verification：

• ORM（Outcome Reward Model）：只看最终答案对不对。简单粗暴，但可能奖励"碰巧对了"的错误推理。

• PRM（Process Reward Model）：给推理链中的每一步打分。DeepMind 和 OpenAI 的实验都表明 PRM 效果更好，但标注成本高得多。

# Best-of-N with verifier scoring
def best_of_n(
    prompt, n=16, generator="deepseek-v3",
    verifier="reward-model-v2"
):
    # 生成 N 个候选
    candidates = [
        generate(prompt, model=generator,
                 temperature=0.8)
        for _ in range(n)
    ]

    # Verifier 打分
    scores = [
        score_solution(c, model=verifier)
        for c in candidates
    ]

    # 取最高分
    best_idx = argmax(scores)
    return candidates[best_idx]

实际部署中的经验：N 取 8-32 通常是性价比最高的区间。N 再大，边际收益急剧递减（因为模型的搜索空间已经覆盖了大部分可能性）。

策略三：Iterative Refinement（最像"人类思考"）

让模型自己"检查作业"：生成一个回答 → 让模型自己找错 → 修正 → 再检查。这是 o1/o3 系列和 DeepSeek-R1 内部在做的事，只不过它们是通过 RL 训练让模型自动学会这个循环。

手动版本的 iterative refinement：

def iterative_refine(
    problem: str,
    max_rounds: int = 3
) -> str:
    solution = generate(
        f"Solve: {problem}\n"
        f"Think step by step."
    )

    for i in range(max_rounds):
        critique = generate(
            f"Problem: {problem}\n"
            f"Solution: {solution}\n\n"
            f"Find errors in this solution."
            f" If correct, say CORRECT."
        )

        if "CORRECT" in critique:
            break

        solution = generate(
            f"Problem: {problem}\n"
            f"Previous: {solution}\n"
            f"Errors: {critique}\n\n"
            f"Fix the errors and provide"
            f" corrected solution."
        )

    return solution

踩坑提醒：模型自检不是万能的。研究表明 LLM 自检存在"过度自信"问题——它可能把正确答案改错。解决方法：1) 用不同 prompt 做 critique；2) 用不同模型交叉验证；3) 设置 max_rounds 防止无限循环。

四、DeepSeek-R1 做对了什么？

DeepSeek-R1 可能是 2025-2026 年 test-time compute 落地最成功的案例。它的核心创新不是"让模型想更久"（这是表象），而是用 RL 训练模型自主决定"想多久"。

传统 CoT prompting 有个尴尬的问题：你让模型"think step by step"，它会对简单问题也写一大堆废话推理。浪费 token 和延迟。DeepSeek-R1 的训练策略让模型学会了：

• 简单问题快速回答（短推理链）

• 难题自动延长思考（长推理链，甚至数千 token）

• 遇到死胡同会回溯重来（不会一条路走到黑）

这种"自适应推理深度"是真正的工程突破。Lilian Weng 在文章中指出，这背后的 RL reward 设计非常精巧：不仅奖励正确答案，还惩罚不必要的冗长推理——这迫使模型学会高效思考。

一个关键洞察：Reward Hacking 是最大敌人

Lilian Weng 去年还有一篇 “Reward Hacking in Reinforcement Learning” 专门讨论这个问题。在 test-time compute 场景下，reward hacking 有个特殊形态：

模型可能学会"表演思考"而不是"真正思考"。

具体来说：如果 reward model 只看最终答案正确性，模型可能学会一种策略——生成大量看似合理的中间步骤，然后"碰巧"给出正确答案。这些中间步骤没有实际推理价值，只是填充 token 来迎合 verifier 的评分偏好。

这就是为什么 Process Reward Model (PRM) 比 Outcome Reward Model (ORM) 重要——你需要确保每一步推理都是有意义的。

五、实战场景：什么时候该用 Test-Time Compute？

不是所有任务都适合。我的判断标准：

任务特征判断

↓

答案可验证？

↓

是 → 数学、代码、逻辑推理 → 强烈推荐 test-time compute

否 → 开放式写作、闲聊、翻译 → 收益有限，不值得额外开销

↓

延迟可接受？

↓

是 → 离线批处理、CI/CD pipeline → 大胆用，N 可以开到 32-64

否 → 实时对话、用户面交互 → 考虑 speculative decoding 或轻量 CoT

几个高价值落地场景：

1. AI 代码审查：给 PR 的每个改动生成 8 个独立审查意见，用 verifier 过滤噪音，只推送置信度高的建议。单次审查可能遗漏 bug，多次采样大幅提升覆盖率。

2. 自动化测试生成：对同一个函数生成 16 组测试用例，自动执行，只保留能通过编译且覆盖率有增量的。比 temperature=0 单次生成的多样性和质量都好得多。

3. 复杂 SQL 生成：自然语言→SQL 的转换，先生成多个候选 SQL，然后用 EXPLAIN 检查执行计划，过滤掉全表扫描和慢查询。这是 verifier-guided 策略的天然场景。

4. 数学/科学论文检验：让模型从不同角度验证一个数学证明的每一步。Sebastian Raschka 在他的 LLM 工作流文章中也强调了这种"多路径验证"策略。

六、成本分析：什么时候划算？

这是工程师最关心的问题。我算了一笔账：

策略	模型	成本/query	MATH准确率
单次调用	GPT-4o	~$0.03	76%
Best-of-8	GPT-4o-mini	~$0.012	74%
Best-of-32	GPT-4o-mini	~$0.048	82%
R1-style	DeepSeek-R1	~$0.02-0.08	85%+

结论很清晰：小模型 + test-time compute 在准确率和成本的帕累托前沿上往往优于大模型单次调用。但前提是你的任务确实需要推理（而不只是知识检索）。

七、未来方向：从"给更多时间"到"教会如何思考"

我认为 test-time compute 的演进方向有三个值得关注的趋势：

趋势一：自适应计算预算

现在的做法是固定 N（采样次数）或固定 max_rounds。未来应该是模型自己决定"这道题需要想多久"。DeepSeek-R1 已经做到了初步版本，但更成熟的方案应该是：系统层面有一个 difficulty estimator，根据预估难度动态分配 compute budget。

趋势二：Latent Reasoning（隐式推理）

CoT 有个根本问题：推理步骤必须用自然语言表达，而自然语言作为思维媒介是低效的。Coconut（Chain of Continuous Thought）等研究在探索让模型在 latent space 中"思考"——不需要显式生成文字，直接在隐藏层做多轮迭代。这可能带来推理效率的数量级提升。

趋势三：和 Agent 范式的融合

DeepMind CEO Demis Hassabis 在最近的访谈中明确说：“Agent 是通往 AGI 的唯一路径”。而 test-time compute 是 Agent 的"思考引擎"——Agent 做复杂规划时，本质就是在推理空间里搜索最优行动序列。

Sebastian Raschka 在 “Components of A Coding Agent” 中也指出：coding agent 的核心能力不是调用工具，而是在工具调用之前做充分推理——决定用什么工具、以什么顺序、如何处理失败。这就是 test-time compute 在 Agent 系统中的具体体现。

八、工程师行动指南

如果你今天就想开始利用 test-time compute，我的建议：

第一步：识别你系统中的"推理瓶颈"任务。不是所有 LLM 调用都值得投入更多 compute。找出那些准确率不够、且答案可验证的环节。

第二步：从 Self-Consistency 开始。成本最低，改动最小——只要你能并发调用 API，加一个投票逻辑就行。在数学/代码/分类任务上通常有 5-15% 的提升。

第三步：引入 verifier。如果你有足够的标注数据（哪怕只有几百条），微调一个小模型做 verifier，配合 Best-of-N 策略。这是性价比最高的组合。

第四步：考虑用 R1-class 模型做推理密集型任务。DeepSeek-R1、QwQ 这类模型已经内置了 test-time compute 策略，你不需要自己实现采样+验证，直接调用就能享受推理增强的收益。代价是 latency 更高（因为生成 token 更多）。

最后一个思考：当推理成本持续降低（DeepSeek API 已经做到 $0.14/M tokens），test-time compute 的经济性会越来越好。我判断在 2026 下半年，“推理时花 10 倍 compute 换取更高准确率"会从"高端用法"变成"默认选项”。就像当年 GPU 价格下降让深度学习从实验室走向工业一样——关键阈值一旦跨过，采用率会爆发式增长。

下一步我想深挖的方向：Latent Reasoning（特别是 Coconut 的工程化可能性）和 multi-agent debate（让多个模型互相辩论作为 test-time compute 的一种形式）。如果你在生产系统里用了类似策略，欢迎交流。

参考文献：

• Lilian Weng - “Why We Think” (May 2025)

• Lilian Weng - “Reward Hacking in Reinforcement Learning” (Nov 2024)

• DeepSeek - “DeepSeek-R1: Incentivizing Reasoning” (Jan 2025)

• Cobbe et al. - “Training Verifiers to Solve Math Word Problems” (2021)

• Sebastian Raschka - “Components of A Coding Agent” (Apr 2026)

• Demis Hassabis - Agent 是通往 AGI 的唯一路径（访谈, 2026）