9.0
重磅
AI SCORE
技术实践2026-08-29 02:27
Test-Time Compute：推理阶段计算扩展成为LLM新Scaling方向
dev.to · AI#LLM#推理优化#模型缩放
Editor brief · 编辑速览
大模型不仅靠训练时扩展参数和数据，推理时给予更多计算资源（生成多个候选、验证、回溯）可显著提升效果。这改变了LLM系统的架构思路，从单次前向传播转向推理引擎模式。
你好，我是 Shrijith Venkatramana。我正在构建 git-lrc，这是一款在每次提交时运行的 AI 代码审查工具。给我们点个 Star，帮助开发者发现这个项目。一定要试试，并分享你的反馈来改进这个产品。
现代 LLM 中正在发生一件奇特的事。
多年来，主流的配方是：
把模型做大。用更多数据训练它。投入更多算力。
这个配方依然重要。但越来越明显的是，另一个调节方式也变得同样有趣：
在模型实际解决问题时，给它更多的算力。
不再要求模型一次前向传播就给出答案，而是让它生成多个候选方案、检查自己的工作、回溯、验证中间步骤、搜索替代方案、调用工具，或者 simply 花更多 token 去思考。
这通常被称为 test-time compute（测试时算力）或 inference-time compute（推理时算力）。
有趣的是，这改变了 LLM 系统的经济学和架构。我们不再把 LLM 看作：
prompt -> model -> answer
-> candidate 1 -
/ \
prompt -> reason/search -> candidate 2 -> verify/select -> answer
\ /
-> candidate 3 -
模型变得更接近于一个推理引擎，其计算预算可以按问题分配。
这里有一个精彩的历史先例：这个想法并不是特别新鲜。
2016 年，DeepMind 的 AlphaGo 以 4:1 击败了李世石。神经网络很重要，但 AlphaGo 并没有简单地问网络"我应该下哪一步棋？"它将神经网络与蒙特卡洛树搜索相结合，在推理时投入大量计算来探索可能的未来。([nature.com][1])
LLM 现在正在重新发现同一个想法的某个版本。
你可能会立即回答。
找出所有满足以下条件的整数 n：使 n² + 3n + 2 能被 17 整除，且……
你可能会拿出一张纸。
区别不一定是你突然变成了一位更厉害的数学家。而是你给这个问题分配了更多的计算。
LLM 可以做类似的事情。
传统的语言模型推理大致如下：
x -> Transformer(x) -> y
其中 x 是 prompt，y 是生成的答案。
但自回归生成已经包含了一种原始形式的测试时算力：
x
-> token 1
-> token 2
-> token 3
-> ...
-> token N
每生成一个额外的 token 都需要另一次模型评估。
因此，如果模型已经学到难题受益于更长的推理链，我们就可以简单地给它更大的推理预算。
这就是随着 OpenAI 的 o1 而广为人知的推理模型转型的核心思想。OpenAI 报告称，o1 的性能不仅随着额外训练算力提升而提升，也随着测试时更多思考时间的投入而提升。([openai.com][2])
这个区别很重要：
training-time compute（训练时算力）：
改进模型本身
test-time compute（测试时算力）：
给模型更多机会来解决这个特定问题
第二种在经济学上可能比听起来有趣得多。
如果 99% 的请求都很简单，你不一定想要构建一个永久足够昂贵的模型来解决最难的 1%。
简单问题 -> 小计算预算
中等难度问题 -> 中等预算
困难问题 -> 大计算预算
极难问题 -> 搜索 / 工具 / 验证 / 智能体
这就是自适应计算。
测试时算力最简单形式几乎简单得令人尴尬：
多次向模型提问。
假设模型在一次独立尝试中正确解决某个特定问题的概率为 p。
如果我们生成 N 次尝试并能识别出正确答案，那么至少有一次正确的概率是：
P(at least one correct) = 1 - (1-p)^N
p = 0.60
N = 1
P(correct) = 60%
进行 10 次独立尝试：
P(at least one correct)
= 1 - 0.4^10
~= 99.99%
显然，有个问题。
你怎么知道哪个答案是正确的？
如果你只是让模型给出十个答案然后随意挑选一个，什么都不会改善。
这就引出了测试时算力中最重要的想法之一：
生成和评估是两种不同的计算问题。
你可以花费算力来生成可能性，然后再花费额外算力来决定选择哪个。
generate
|
+------------+------------+
| | |
answer A answer B answer C
| | |
+------------+------------+
|
verifier
|
answer B
这正是 best-of-N sampling 优于单次采样的基本原因。
这也是为什么验证成为了一个核心问题。
考虑一个编程问题。
def solve(x):
...
有两个根本不同的问题：
模型能生成一个解决方案吗？
我们能判断这个解决方案是否好吗？
对于代码，我们有一个异常强大的验证器：
compile
|
unit tests
|
integration tests
|
correct / incorrect
这使得代码成为测试时算力最有吸引力的领域之一。
对于数学，我们可能有：
candidate solution
|
symbolic checker
|
numerical checker
|
another LLM
|
final answer
对于开放式推理，验证器就变得困难得多。
这一区别推动了过程监督（process supervision）的大量研究。OpenAI 研究人员包括 Hunter Lightman 和同事研究了不仅奖励最终答案是否正确，还奖励正确中间推理步骤的奖励方式。他们的 2023 年工作《Let's Verify Step by Step》展示了过程级反馈对数学推理的价值。([huggingface.co][3])
概念上的转变很微妙：
outcome supervision（结果监督）：
problem -> reasoning -> answer
^
reward
process supervision（过程监督）：
problem -> step1 -> step2 -> step3 -> answer
^ ^ ^ ^
reward reward reward reward
为什么这在推理时有用？
因为现在系统可能会问：
"这些推理路径中哪个看起来最有希望？"
而不是盲目接受第一个完整答案。
这让我们更接近于搜索。
这才是真正有趣的地方。
想象模型已经生成了：
Step 1
|
+-- Step 2A
| |
| +-- Step 3A
|
+-- Step 2B
|
+-- Step 3B
不急于确定一条路径，我们可以探索多条。
problem
|
+-----+-----+
| |
A1 B1
/ \ / \
A2 A3 B2 B3
| | | |
... ... ... ...
每个节点代表一个部分推理状态。
验证器估计哪些分支看起来有希望。
然后系统向有希望的分支分配更多算力。
这是一个搜索算法。
这正是与 AlphaGo 的知识关联。
neural network
+
tree search
神经网络提供了从棋局中学习到的直觉，而搜索则花费额外计算来探索可能的未来。
Silver 和同事们的 2016 年 Nature 论文描述了 AlphaGo 如何结合深度神经网络和蒙特卡洛树搜索，该系统随后以 5:0 击败了欧洲围棋冠军樊辉，然后在与李世石的著名对弈中获胜。([nature.com][1])
同样的架构分解对 LLM 推理也是有意义的：
LLM = learned heuristic（学习到的启发式）
search = computational deliberation（计算性审慎）
模型不需要在单个确定性轨迹中编码整个解决方案。
它可以 대신 提供一个关于可能推理轨迹的策略，而推理时的计算来探索这些可能性。
这是一个更强大的抽象。
现在我们来到了有趣的工程问题。
Model A:
70B 参数
1 单位推理成本
70% 准确率
Model B:
200B 参数
3 单位推理成本
75% 准确率
你可能会自然地选择 Model B。
但假设 Model A 可以使用测试时搜索：
Model A + 8 倍推理算力
-> 85% 准确率
现在比较不再是简单地：
70B vs 200B
而是：
便宜模型 + 更多推理算力
vs
昂贵模型 + 更少推理算力
Charlie Snell、Jaehoon Lee、Kelvin Xu 和 Aviral Kumar 在 ICLR 2025 发表的论文《Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters for Reasoning》中对这种权衡进行了系统研究。他们探究了推理时算力如何通过过程奖励模型的搜索以及模型输出分布的自适应调整等机制进行分配。（[openreview.net][4]）
他们的一项重要观察是：不存在放之四海而皆准的最优策略。
正确的算力分配取决于以下因素：
model size
problem difficulty
available inference budget
quality of the verifier
search strategy
如果从经济学角度思考，这就很直观了。
假设你有 1 美元的算力预算。
你可以把它花在：
更大的模型
或者
更长的推理
或者
多次采样
或者
验证
或者
工具调用
前沿问题是：
下一美元算力投在哪里，能最大概率提高答对率？
这是一个扩展定律问题，但发生在推理阶段。
下面是一个刻意粗略的计算。
假设一个模型的费用是：
$0.002 / 1,000 个生成 token
而普通回复使用：
500 个 token
cost = $0.001 / 次回复
现在想象一个推理系统，在产生 500 token 的回答之前，使用了：
5,000 个推理 token
$0.011 / 次回复
这大约是生成 token 成本的 11 倍。
对于消费者聊天机器人来说，这可能是相当大的差异。
对于一个能为开发者节省 20 分钟的编程智能体来说，可能微不足道。
这就产生了一个非常不同的优化目标：
边际推理成本
|
v
problem -> compute allocation -> expected success
|
v
business value
假设一个编程任务如果正确解决，价值 5 美元的工程时间。
那么再花 0.02 美元来提高 2 个百分点的成功概率，期望值是：
0.02 * $5 = $0.10
这是非常划算的。
但如果是"翻译这个句子"这样的任务，花 0.02 美元把准确率从 99.5% 提高到 99.9%，可能就很划不来。
这意味着架构更像是计算调度器，而不是传统的 LLM API：
+----------------+
| classify task |
+-------+--------+
|
+------------+-------------+
| | |
easy medium hard
| | |
1 sample 4 samples search
| | |
+------------+-------------+
|
verifier
|
answer
换句话说，推理变成了一个资源分配问题。
这可能是思考测试时计算最实用的方式。
不要把模型当作一个函数：
answer = model(prompt)
把它当作一个计算基底：
candidates = generate(prompt, budget=B1)
scores = verify(prompt, candidates, budget=B2)
answer = select(candidates, scores)
state = initialize(problem)
while budget_remaining():
candidates = expand(state)
scores = evaluate(candidates)
state = select_and_expand(candidates, scores)
return best_answer(state)
这种抽象打开了几个我们熟悉的技术。
生成多个解决方案并选择最好的：
generation is stochastic
verification is cheap
solutions are relatively independent
生成多个推理轨迹，取共识答案。
当多条独立推理路径收敛到相同答案时，这种方法效果特别好。
验证器引导的搜索
生成部分解决方案，评分，然后扩展有希望的：
generate -> score -> prune -> expand -> score -> ...
工具辅助验证
生成代码
-> 编译
-> 运行测试
-> 检查失败
-> 修改代码
-> 重复
生成证明
-> 符号检查器
-> 识别失败步骤
-> 修订
假设
-> 搜索
-> 获取证据
-> 比较来源
-> 修订
-> 再次搜索
到了这一步，你已经跨越了一个重要的概念边界。
你不再只是在提示 LLM。
你在围绕 LLM 构建一个搜索过程。
这里有一个更广泛的含义。
传统扩展定律问的是：
我们能把模型做到多强？
测试时扩展问的是：
我们应该在这个特定问题上花多少算力？
这是非常不同的问题。
想象两个问题：
Problem A:
"将 37°C 转换为华氏度。"
Problem B:
"找出这个 20,000 行分布式系统中的一个 bug。"
固定算力的模型对它们的处理方式相似。
推理系统不应该这样。
Problem A
-> 1-2 次前向传播
-> 完成
Problem B
-> 检查代码
-> 形成假设
-> 搜索
-> 运行测试
-> 修订
-> 调查失败
-> 重复
计算预算变得依赖于不确定性和难度。
这是推理模型比"产生更长回答的 LLM"更有趣的原因之一。
真正的发展方向是：
model intelligence
+
search
+
verification
+
tools
+
adaptive compute
形成一个单一的推理过程。
这与经典 AI 有一个有趣的对称性。
AlphaGo 表明，一个学习到的模型可以提供直觉，而搜索提供额外的计算。现代推理 LLM 正在语言和代码领域探索同样的基本劳动分工。区别在于，搜索空间现在由 token、程序、证明、假设、工具调用和动作组成，而不是围棋落子。（[nature.com][1]）
这里有一个容易犯的错误。
测试时计算不是魔法。
如果模型的采样高度相关：
sample 1 -> 同样的错误
sample 2 -> 同样的错误
sample 3 -> 同样的错误
...
那么生成 100 个采样不会给你带来多少收益。
同样，一个糟糕的验证器可能自信地选择一个糟糕的答案。
你甚至可能得到一个病态的系统：
更多推理
-> 更多犯错的机会
-> 更 elaborate 的错误解释
所以搜索空间的质量很重要。
一个有用的心智模型是：
test-time performance
~
generation diversity
x verifier quality
x search efficiency
x compute budget
这不是作为一个通用公式，而是作为工程分解。
这就是为什么过程奖励模型、自验证和搜索的研究如此重要。推理模型不仅需要生成可能性，还需要区分有希望的轨迹和糟糕的轨迹。（[huggingface.co][3]）
这也解释了为什么最强的系统越来越像是系统工程项目，而不是简单的模型训练问题。
结论：模型可能是推理的开始，而不是结束
旧的 LLM 心智模型是：
prompt
|
v
neural network
|
v
answer
+--> candidate
|
prompt -> model -> search -> verify
|
+--> candidate
|
+--> candidate
|
v
answer
这个差异是巨大的。
这意味着，在训练期间花费数十亿美元让模型变得更强之后，我们可以通过决定在解决每个单独问题时花费多少算力，获得另一个维度的改进。
有时这意味着简单地生成更多采样。
有时这意味着思考更久。
有时这意味着验证中间步骤。
有时这意味着搜索可能的推理轨迹树。
对于软件智能体，它可以意味着编译代码、运行测试、检查失败并重试。
因此有趣工程问题不仅仅是：
"我应该调用哪个模型？"
而是：
"我应该在模型周围运行什么推理算法，这个问题值多少算力？"
这是一个有趣得多的问题。
也许最奇怪的后果是，"扩展 LLM"可能越来越多地意味着扩展模型完成训练后执行的计算。
如果你现在正在构建一个由 LLM 驱动的编程 AI 智能体，你会把 10 倍的推理预算花在什么地方：更长的思维链、并行采样、验证器引导搜索，还是实际运行更多的工具/测试？
AI 智能体写代码很快。它们也会静默删除逻辑、改变行为、引入 bug——而不告诉你。你往往在生产环境中才发现。
git-lrc 解决了这个问题。它挂钩到 git commit，在每次代码变更落地之前审查每一个 diff。60 秒配置完成。完全免费。
任何反馈或贡献者都非常欢迎！它已上线、开源，任何人都可以使用。
Free, Micro AI Code Reviews That Run on Git Commit
| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |
Free, Micro AI Code Reviews That Run on Commit
今天的 GenAI 就像一辆没有刹车的赛车。它加速很快——你描述一个需求，大量代码块就瞬间出现。但 AI 智能体会静默破坏东西：它们删除逻辑、放松约束、引入昂贵的云调用、泄露凭证、改变行为——而不告诉你。你往往在生产环境中才发现。
git-lrc 就是你的刹车系统。它挂钩到 git commit，在每次 diff 落地之前运行 AI 审查。60 秒配置完成。完全免费。
简而言之，git-lrc 帮助在故障、入侵和技术债务发生之前预防它们
概览：10 个风险类别 · 100+ 失败模式追踪 · 每次 commit…
For further actions, you may consider blocking this person and/or reporting abuse