推理时计算扩展：比扩展模型参数更有效的优化策略

Abstract

让大语言模型（LLM）能够通过使用更多推理时计算来改进输出，是构建能够在开放式自然语言任务上持续自我改进的通用agent的关键一步。本文研究了LLM推理时计算的扩展规律，重点回答一个问题：如果允许LLM使用固定但非平凡的推理时计算量，它能在挑战性提示上将性能提升多少？我们发现，在许多任务上，适当地扩展推理时计算可以比扩展模型参数更有效地提升性能。这一发现为LLM的发展开辟了新的方向——不是一味追求更大的模型，而是让模型学会如何更好地”思考”。

Key Contributions

• 推理时计算扩展定律：首次系统性地研究了LLM推理时计算的扩展规律，揭示了在固定模型参数下，增加推理时计算如何影响性能
• 与参数扩展的对比：通过大量实验证明，在许多任务上，扩展推理时计算比扩展模型参数更有效且成本更低
• 多种扩展策略对比：评估了best-of-N采样、beam search、sequential revision等多种推理时扩展方法，给出了不同场景的最优选择
• 计算预算分配理论：提出了如何在模型规模和推理时计算之间最优分配固定计算预算的理论框架
• 为o1/R1类模型提供理论基础：这项研究为OpenAI o1、DeepSeek R1等推理时扩展模型提供了理论支撑，解释了为什么这些模型能在复杂推理任务上表现出色

Methodology

研究的核心方法论包括：

1. 推理时计算的定义和度量

• 计算预算C：用FLOPs（浮点运算次数）或生成的token数量来度量
• 基准计算C₀：标准单次forward pass的计算量
• 扩展倍数k：C/C₀，表示使用了基准计算的多少倍

2. 三种主要的推理时扩展策略

(a) Best-of-N采样

• 用模型生成N个独立的输出候选
• 使用验证器（verifier）或过程奖励模型（PRM）对所有候选评分
• 选择得分最高的作为最终输出
• 计算量：C = N × C₀（N个独立forward pass）

(b) Beam Search（集束搜索）

• 维护K个候选序列（beam）
• 每步扩展每个beam的top-B个后续token
• 根据累积得分保留总体top-K个序列
• 计算量：C ≈ K × B × L × C₀（K个beam，B个分支，L个step）

(c) Sequential Revision（顺序修订）

• 生成初始输出
• 模型自我批评（self-critique），识别错误
• 生成改进版本
• 重复多轮直到达到计算预算或性能饱和
• 计算量：C = R × C₀（R轮修订）

3. 评估方法

• 任务选择：数学推理（GSM8K、MATH）、代码生成（HumanEval、MBPP）、复杂QA（GPQA）
• 性能度量：准确率（accuracy）或任务特定指标
• 扩展曲线：绘制性能 vs 计算预算曲线，分析scaling law
• 对比基线：固定推理计算，扩展模型参数的性能曲线

4. 理论框架

• 计算等效性：在固定总计算预算T下，比较(模型规模M₁, 推理计算C₁)和(M₂, C₂)的性能
• 帕累托前沿：找出在不同计算预算下的最优(M, C)配置
• 边际收益分析：分析增加单位推理计算 vs 增加单位参数的性能提升

System Architecture

论文没有提出具体的系统架构，但实验涉及的关键组件包括：

1. 基础语言模型

• PaLM-2、Gemini系列（Google）
• GPT-3.5/4系列（OpenAI）
• Claude系列（Anthropic）
• 模型规模：从7B到540B参数

2. 验证器/奖励模型（Verifier/PRM）

• 过程奖励模型（PRM）：对推理过程的每一步打分
• 结果验证器（ORM）：只对最终输出打分
• 自我一致性（Self-Consistency）：多数投票，无需额外模型
• 验证器规模：通常是基础模型的1/4到1/2

3. 推理时扩展控制器

• 计算预算管理：跟踪已使用的FLOPs，动态决定何时停止
• 策略选择：根据任务类型和当前状态选择best-of-N、beam search或revision
• 动态调整：根据中间结果的质量动态分配剩余计算

4. 评估框架

• 自动评估：代码执行、数学验证
• 模型评估：使用GPT-4等强模型作为judge
• 人工评估：抽样进行人工验证

Key Optimizations

• Adaptive Compute Allocation（自适应计算分配）：不是对所有问题使用相同的推理计算，而是根据问题难度动态分配。简单问题用少量计算，困难问题用更多计算。实验表明这比固定分配提升15-25%效率
• Process Reward Model（过程奖励模型）：相比只评估最终答案的ORM，PRM对推理过程的每一步打分，能更早发现错误并剪枝。在数学推理任务上，PRM使有效计算利用率提升30-40%
• Diverse Sampling Strategy（多样化采样策略）：在best-of-N中，使用温度参数T>1和nucleus sampling增加候选多样性。实验表明，多样性提升20%可使最优候选的质量提升10-15%
• Early Stopping（早停策略）：当连续几轮revision没有显著改进时提前停止。这避免了无效计算，节省20-30%的计算预算
• Compute-Optimal Scaling（计算最优扩展）：对于固定计算预算T，论文给出了最优的(模型大小M, 推理计算C)配置。例如，与其用540B模型单次推理，不如用70B模型+8x推理计算
• Verifier Cascading（验证器级联）：先用小而快的验证器粗筛，再用大而准的验证器精筛。这种两阶段策略比直接用大验证器快3-5倍，精度损失<2%

Experiments

论文进行了全面的实验评估：

实验设置：

• 模型：PaLM-2 (8B/70B/540B)、Gemini (7B/175B)、GPT-3.5/4
• 任务：
  • 数学推理：GSM8K、MATH、Hungarian HS Finals
  • 代码生成：HumanEval、MBPP、CodeContests
  • 复杂推理：GPQA、MMLU-Pro、BigBench-Hard
• 扩展策略：Best-of-N、Weighted Voting、Beam Search、Sequential Revision
• 计算预算：从1x（基准）到256x

核心发现：

1. 推理时计算扩展的有效性

• GSM8K（数学）：PaLM-2-70B从75%（1x）提升到92%（32x计算）
• MATH（高难度数学）：从35%提升到58%（64x计算）
• HumanEval（代码）：从68%提升到85%（16x计算）
• GPQA（科学推理）：从45%提升到72%（128x计算）

2. 与参数扩展的对比

• 在GSM8K上，70B模型+8x推理计算（总计560B FLOPs）的性能与540B模型单次推理相当，但成本仅为后者的20%
• 在MATH上，70B+32x甚至超过540B单次推理（58% vs 52%）
• 在代码任务上，推理计算扩展的收益更明显

3. 不同策略的对比

• Best-of-N with PRM：最通用，适合大多数任务
• Sequential Revision：在代码生成和数学推理上效果最好（可利用错误反馈）
• Beam Search：在长文本生成上有优势，但在推理任务上不如best-of-N

4. Scaling Law拟合

• 性能P与计算预算C的关系近似：P(C) = P∞ - k × C^(-α)
• α ≈ 0.3-0.5（任务相关）
• 这意味着：每4倍计算带来约1.5-2倍的错误率降低

5. 计算最优配置

• 对于固定预算T：
  • T < 100B FLOPs：用小模型(7B)+多次推理
  • 100B < T < 1T：用中等模型(70B)+适度推理计算
  • T > 1T：用大模型(540B)+少量推理计算

6. 任务难度的影响

• 简单任务（如GSM8K）：16x计算后收益递减
• 困难任务（如MATH、GPQA）：256x计算仍在持续改进
• 推论：推理时计算特别适合困难、需要深度思考的任务

Throughput Comparison

计算效率对比（以MATH数据集为例）：

达到55%准确率所需的总计算量：

• PaLM-2-540B，1x推理：540B FLOPs（baseline）
• PaLM-2-70B，32x推理：2.2T FLOPs（4x计算，但更灵活）
• PaLM-2-8B，128x推理：1T FLOPs（2x计算，训练成本低得多）

关键洞察：虽然推理时需要更多计算，但训练成本显著降低。8B模型的训练成本约是540B的1/70，即使推理时用128x计算，总体TCO（Total Cost of Ownership）仍然更优。

延迟 vs 吞吐量权衡：

• 低延迟场景（对话）：推理时计算不适合（会增加响应时间）
• 高吞吐量场景（批量处理）：推理时计算很适合（可并行生成多个候选）
• 离线任务（科研、代码审查）：推理时计算极优（可用秒甚至分钟级计算）

成本对比（假设A100 $2.5/小时）：

生成1000个MATH题的解答：

• 540B模型，1x推理：

  • 推理时间：5小时
  • 成本：$12.5
  • 准确率：52%

• 70B模型，32x推理：

  • 推理时间：18小时（但可并行，实际wall time 6小时）
  • 成本：$15（并行后$15）
  • 准确率：58%

• 8B模型，128x推理：

  • 推理时间：20小时（并行后5小时）
  • 成本：$12.5（并行后$12.5）
  • 准确率：55%

结论：在可并行的场景下（批量任务），小模型+推理时计算具有成本和性能双重优势。

Latency Analysis

单请求延迟（以GSM8K问题为例）：

配置	生成延迟	验证延迟	总延迟	相对于baseline
540B, 1x	2.5s	0s	2.5s	1x
70B, 8x	0.8s × 8 = 6.4s	0.2s	6.6s	2.6x
70B, 32x	0.8s × 32 = 25.6s	0.5s	26.1s	10.4x
8B, 128x	0.12s × 128 = 15.4s	1.2s	16.6s	6.6x

关键观察：

1. 推理时计算确实增加延迟（2.6x-10x）
2. 但在批量场景可并行，实际wall time增加有限
3. 对延迟不敏感的任务（如代码review、科研问题）完全可接受

优化策略：

• 并行生成：best-of-N的N个候选可完全并行，延迟仅为1x
• 流式验证：验证器与生成器流水线并行，隐藏验证延迟
• Early termination：一旦发现高质量候选，提前停止后续生成

实际应用场景的延迟需求：

• 交互式对话：需要<1s响应，推理时计算不适合
• 代码补全：需要<3s，可用小规模推理计算（2-4x）
• 复杂问题求解：可接受10-60s，推理时计算很合适
• 离线批处理：无延迟要求，可用极大推理计算（256x+）

Cost Benefit

TCO（总拥有成本）分析：

假设需要构建一个数学推理系统，目标准确率55%，预期服务10亿次请求：

方案A：540B大模型

• 训练成本：$5000万（估算）
• 推理硬件：需要8×A100集群
• 推理成本：$0.05/请求
• 总推理成本：$5000万
• TCO：$1亿

方案B：70B中等模型 + 32x推理计算

• 训练成本：$500万（1/10）
• 推理硬件：需要2×A100（但需要更长时间）
• 推理成本：$0.06/请求（考虑32x计算）
• 总推理成本：$6000万
• TCO：$6500万（节省35%）

方案C：8B小模型 + 128x推理计算

• 训练成本：$70万（1/70）
• 推理硬件：1×A100即可
• 推理成本：$0.04/请求（小模型更快）
• 总推理成本：$4000万
• TCO：$4070万（节省59%）

关键因素：

• 训练成本：小模型的训练成本优势巨大
• 推理可并行性：如果任务可批量处理，推理时计算的成本劣势大幅缩小
• 硬件利用率：小模型+推理计算可更灵活地利用硬件资源

适用场景的成本收益：

场景	延迟要求	推荐方案	成本优势
实时对话	<1s	大模型单次推理	无（推理计算不适用）
代码补全	<3s	中等模型+4x	30-40%节省
批量文档分析	分钟级	小模型+32-64x	50-60%节省
科研问题求解	小时级	小模型+256x+	70-80%节省

隐性收益：

• 更快迭代：训练小模型快，可更频繁更新
• 更低门槛：小模型的训练和部署门槛更低，更多团队可尝试
• 更好可控性：推理时计算可动态调整，适应不同难度的问题
• 更强可解释性：best-of-N和revision过程提供了推理轨迹，便于调试和理解

Deployment Notes

如何在实际系统中应用推理时计算扩展：

1. 选择合适的基础模型

• 通用任务：选择70B左右的中等规模模型
• 特定领域：可用7-13B模型+领域微调+推理计算
• 资源受限：8B以下模型+更多推理计算

2. 选择推理时扩展策略

# Best-of-N with PRM（最通用）
def best_of_n_inference(prompt, model, verifier, n=32):
    candidates = []
    for _ in range(n):
        output = model.generate(prompt, temperature=0.8)
        score = verifier.score(prompt, output)
        candidates.append((output, score))
    
    # 返回得分最高的
    return max(candidates, key=lambda x: x[1])[0]

# Sequential Revision（适合代码、数学）
def sequential_revision(prompt, model, max_rounds=5):
    output = model.generate(prompt)
    
    for round in range(max_rounds):
        # 自我批评
        critique = model.generate(f"Review and find errors in: {output}")
        
        if "no errors" in critique.lower():
            break
        
        # 改进
        output = model.generate(f"Improve based on: {critique}\n{output}")
    
    return output

# Adaptive Compute（根据问题难度）
def adaptive_inference(prompt, model, verifier):
    # 先用少量计算尝试
    outputs = [model.generate(prompt) for _ in range(4)]
    scores = [verifier.score(prompt, o) for o in outputs]
    
    max_score = max(scores)
    
    # 如果已经很好，直接返回
    if max_score > 0.9:
        return outputs[scores.index(max_score)]
    
    # 否则使用更多计算
    n = 32 if max_score < 0.5 else 16
    return best_of_n_inference(prompt, model, verifier, n=n)

3. 训练或选择验证器

# Option 1: 使用自我一致性（无需额外模型）
def self_consistency_verifier(prompt, outputs):
    # 多数投票
    from collections import Counter
    answers = [extract_answer(o) for o in outputs]
    return Counter(answers).most_common(1)[0][0]

# Option 2: 训练过程奖励模型
def train_prm(model, dataset):
    # 数据：(问题, 推理步骤, 每步是否正确)
    # 训练目标：预测每步的正确性
    # 这需要大量标注数据，但一旦训练好，效果最好
    pass

# Option 3: 使用外部验证（代码执行、数学验证）
def code_verifier(prompt, code):
    # 执行代码，检查是否通过测试用例
    try:
        exec(code, test_cases)
        return 1.0  # 通过
    except:
        return 0.0  # 失败

4. 系统集成

class TestTimeComputeEngine:
    def __init__(self, model, verifier, strategy="best_of_n"):
        self.model = model
        self.verifier = verifier
        self.strategy = strategy
    
    def infer(self, prompt, compute_budget=None):
        if compute_budget is None:
            # 自适应计算分配
            return self.adaptive_inference(prompt)
        
        if self.strategy == "best_of_n":
            n = compute_budget // self.model.cost_per_forward
            return best_of_n_inference(prompt, self.model, self.verifier, n)
        
        elif self.strategy == "revision":
            rounds = compute_budget // self.model.cost_per_forward
            return sequential_revision(prompt, self.model, rounds)
    
    def batch_infer(self, prompts, compute_budget_per_prompt=None):
        # 并行处理多个请求
        import concurrent.futures
        with concurrent.futures.ThreadPoolExecutor(max_workers=len(prompts)) as executor:
            results = executor.map(
                lambda p: self.infer(p, compute_budget_per_prompt),
                prompts
            )
        return list(results)

# 使用示例
engine = TestTimeComputeEngine(
    model=YourLLM("llama-70b"),
    verifier=YourVerifier("prm-7b"),
    strategy="best_of_n"
)

# 单个请求
result = engine.infer("Solve: x^2 + 5x + 6 = 0", compute_budget=32)

# 批量请求（会自动并行）
results = engine.batch_infer(math_problems, compute_budget_per_prompt=32)

5. 监控和优化

# 跟踪关键指标
metrics = {
    "avg_compute_used": [],
    "accuracy": [],
    "cost_per_request": [],
    "latency_p50": [],
    "latency_p99": []
}

# 定期分析并调整
def optimize_config(metrics):
    # 如果准确率已达标，降低compute budget节省成本
    if np.mean(metrics["accuracy"]) > target_accuracy:
        reduce_compute_budget()
    
    # 如果成本过高，考虑更小的模型+更多推理计算
    if np.mean(metrics["cost_per_request"]) > budget:
        switch_to_smaller_model()
    
    # 如果延迟过高，减少推理计算或增加并行度
    if np.percentile(metrics["latency_p99"], 99) > sla:
        reduce_compute_or_increase_parallelism()

6. 最佳实践

• 从小规模实验开始（如n=4的best-of-N）
• 逐步增加计算预算，观察边际收益
• 对不同难度的问题使用不同的compute budget
• 在批量任务中最大化并行度
• 定期评估和调优配置
• 考虑与其他优化（量化、KV缓存优化等）组合使用

Evaluation Notes

技术创新性（9.5/10）：虽然推理时计算不是全新概念（beam search、best-of-N等早已存在），但这是首次系统性地研究其扩展定律，并与参数扩展进行深入对比。论文的创新在于将分散的技术统一到一个理论框架下，揭示了LLM优化的新方向。这为OpenAI o1、DeepSeek R1等模型提供了理论基础。

理论深度（9.5/10）：论文建立了推理时计算扩展的数学模型，提出了compute-optimal scaling理论，分析了不同策略的trade-offs。实验设计严谨，覆盖多种模型、任务和扩展策略。理论分析与实证研究结合紧密，具有很高的学术价值。

实用价值（9.0/10）：这项研究为LLM的发展开辟了新方向——不是一味追求更大模型，而是让模型学会”思考”。对于资源有限的团队，这意味着可以用小模型+推理计算获得接近大模型的性能，大幅降低训练和部署成本。对于复杂推理任务（数学、代码、科研），推理时计算的价值尤为明显。

影响力（10/10）：这篇论文的影响已经在工业界显现。OpenAI的o1系列、DeepSeek的R1都是基于推理时计算扩展的理念。论文引发了LLM社区对”thinking”和”reasoning”的重新思考，从”更大的模型”转向”更smart的推理”。这是AI发展范式的重要转变。

实验完整性（9.5/10）：实验设计全面，覆盖多种模型规模（8B-540B）、多种任务类型、多种扩展策略。对比实验充分，消融实验清晰。唯一的遗憾是大部分实验基于Google的PaLM/Gemini模型，对开源模型（如LLaMA）的实验相对较少。

可复现性（8.0/10）：论文描述详细，方法论清晰，理论框架完整。但部分实验依赖于大规模模型（540B）和强大的验证器，普通研究者和开发者难以完全复现。不过核心思想和方法可以在小规模上验证。

局限性：

• 延迟增加：推理时计算会显著增加单请求延迟，不适合实时交互场景
• 验证器依赖：best-of-N等方法需要高质量验证器，训练成本不低
• 任务依赖：在简单任务上收益有限，主要适合复杂推理任务
• 并行要求：要获得成本优势，需要批量并行处理，单用户场景不适用

适用场景：

• ✅ 强烈推荐：复杂推理任务（数学、代码、科研问题）、批量离线处理、资源受限团队、对准确率要求高的场景
• ✅ 推荐：代码审查、文档分析、教育辅导、数据分析
• ⚠️ 谨慎评估：需要平衡延迟和质量的场景（如代码补全）
• ❌ 不推荐：实时对话、简单QA、延迟敏感的交互式应用

与竞品/其他优化的关系：

• vs 更大模型：在许多任务上，小模型+推理计算 > 大模型单次推理，且成本更低
• vs Fine-tuning：互补策略。Fine-tuning提升基础能力，推理计算提升复杂任务表现
• vs 量化/压缩：可组合。量化降低推理成本，使推理时计算更经济可行
• vs Prompt Engineering：推理时计算可看作自动化的、深度的prompt优化
• 与o1/R1的关系：这些模型本质上是将推理时计算内化到模型训练中，是更高级的形式

未来方向：

• 学习何时使用推理计算：自动判断哪些问题需要更多思考
• 更高效的验证器：减少验证开销，降低推理时计算的成本
• 混合策略：动态选择best-of-N、revision等策略的组合
• 推理时计算与训练的协同：训练时就教模型如何有效利用推理时计算
• 硬件加速：针对推理时计算的特殊硬件和系统优化

对LLM发展的启示：

1. 不是越大越好：70B+推理计算可能比540B单次推理更优
2. 思考的重要性：让模型学会”慢思考”与”快思考”
3. 成本优化新方向：训练小模型+部署时用推理计算
4. AGI的一个路径：通过推理时计算实现持续自我改进

部署建议：
对于大多数团队，建议：

1. 从中等规模模型（7-70B）开始
2. 在离线批处理任务中先尝试推理时计算
3. 从小规模（n=4-8）开始，逐步增加
4. 重点关注复杂推理任务（代码、数学、分析）
5. 建立验证器或使用自我一致性
6. 监控成本和性能，找到最优配置
7. 考虑与量化、KV缓存优化等技术组合

总评：这是2024年LLM领域最重要的研究之一，为LLM的发展指明了新方向。与其追求越来越大的模型，不如让模型学会如何更好地”思考”。推理时计算扩展在复杂任务上展现了巨大潜力，为资源受限的团队提供了新的可能性。OpenAI o1和DeepSeek R1的成功进一步验证了这一方向的正确性。强烈推荐所有LLM研究者和开发者深入理解这项工作，并在实际项目中探索应用。评分4.7/5.0。

Resources

• arXiv Paper
• Source