LLM 推理即训练：Test-Time Compute Scaling 的架构革命

在 LLM 领域，有一个正在发生的范式转移，它的颠覆性不亚于 2020 年的 Scaling Law，但讨论度远没有那么大——Test-Time Compute Scaling（推理时计算扩展）。

从"训练即智能"到"推理即智能"

过去五年，业界形成了一个根深蒂固的信仰：模型越强，必须在预训练阶段用更多算力。Scaling Law 告诉我们：模型参数越大、训练 token 越多，模型能力越强。这个范式统治了 GPT-2 → GPT-3 → GPT-4 的整个时代。

但 2024 年的 o1 和 2025 年的 o3 已经打破了这条规则。它们的核心洞察是：有些智能不能被"记忆"进权重里，必须在推理时动态产生。

o1/o3 的做法是：在推理时让模型生成一个很长的"思维链"（Chain-of-Thought），然后通过一个 verifier model 来评估每一步的正确性，逐步筛选出最优路径。这个过程本质上是把"推理"变成了一个 在 token 空间里的搜索问题，而不仅仅是记忆检索。

为什么这条路在 2026 年突然变热？

有三个技术原因让它从 research paper 走进了生产系统：

1. 推理成本每年下降 10 倍

2023 年，用 GPT-4 处理一个复杂数学问题，成本是 ~$0.03。现在同等能力可以用开源模型（Llama-3 + 思维链）压到 ~$0.0003。成本下降使得"多生成几个候选答案再筛选"变得经济可行。

2. Verifier Model 的质量飞跃

早期的 self-verification 效果很差——模型自己打分容易自欺欺人。2025 年的关键突破是训练出了一个独立的 reward model，它不参与答案生成，只负责判断答案质量。这个 reward model 的训练数据来自于人类标注的推理轨迹，质量远高于模型自己的隐式反馈。

3. 并行生成技术的成熟

自回归生成是顺序的，但 Speculative Decoding 和 Beam Search 变体让多个候选路径可以高效并行生成，代价是略微增加内存使用，但延迟保持在可接受范围内。

架构影响：Inference Infrastructure 正在被重写

Test-Time Compute Scaling 带来的一个被低估的影响是：传统的推理架构（单次前向传播）正在被"推理引擎"取代。

传统架构：

`

Client → API Gateway → Model Server → Response

(1次调用，1次推理)

`

新的推理架构：

`

Client → Inference Engine

├── Prompt Router（判断问题复杂度）

├── Compute Allocator（分配推理时算力预算）

├── Parallel Sampler（并行生成多个候选）

├── Verifier（打分筛选）

└── Response Aggregator（聚合输出）

`

这意味着推理基础设施不再是"把模型跑起来"那么简单，而是一个需要调度、搜索和评估的运行时系统。

成本悖论：为什么这反而降低了总成本？

这看起来违反直觉：生成多个候选不是更贵吗？

关键在于 任务难度分布。现实中 80% 的请求是简单问题（简单问答、格式转换），这些用传统方式（单次推理）成本极低。但剩下的 20% 复杂问题（数学证明、复杂代码、深度分析）用传统方式需要调用更大的模型（如 GPT-4），单价很高。

Test-Time Compute Scaling 的做法是：用小模型 + 推理时扩展处理所有问题。对于简单问题，小模型一步出答案，成本极低；对于复杂问题，小模型通过推理时扩展达到接近大模型的效果，总成本仍然比直接调用大模型低。

`

传统方案：

• 简单问题 → GPT-4 → $0.03（贵了）
• 复杂问题 → GPT-4 → $0.03（还行）

Test-Time Scaling：

• 简单问题 → Llama-3-8B → $0.0001（极便宜）
• 复杂问题 → Llama-3-8B + 推理搜索 → $0.001（仍然很便宜）

`

实践中的挑战

虽然方向清晰，但在生产环境中落地仍有不少坑：

Verifier 的天花板效应

Verifier 的质量直接决定了最终效果上限。如果 verifier 也会犯错，整个搜索过程就会把错误路径排到前面。训练一个可靠的 reward model 需要大量高质量的人类偏好数据，成本不低。

延迟 vs 质量的权衡

Test-Time Scaling 会显著增加单次请求的延迟。对于需要实时反馈的对话场景，搜索深度需要保守控制；对离线任务（代码生成、数学证明），可以给更充足的 compute budget。

内存瓶颈

并行生成多个候选路径意味着要把多个 KV Cache 同时保存在 GPU 显存里。在 compute budget 很大时，显存可能成为新的瓶颈。

搜索空间的指数爆炸

对于复杂问题（如数学证明），可能的推理路径数量随深度指数增长。粗暴地枚举所有路径不现实，需要剪枝策略——也就是 verifier 的核心价值。

关键公式

Test-Time Compute Scaling 的核心可以用这个框架理解：

`

最终答案 = argmax_{candidate ∈ SearchSpace(prompt, compute_budget)}

VerifierScore(prompt, candidate)

`

其中：

• `SearchSpace` 是通过某种解码策略生成的候选答案集合
• `compute_budget` 决定了你愿意在单个请求上消耗多少 token
• `VerifierScore` 是奖励模型对答案质量的评判

这实际上是把推理问题建模成了一个受限的决策过程，而在传统范式下，推理只是前馈计算。

实际代码示例

`python

import torch

from typing import List, Callable

class TestTimeScaling:

def __init__(

self,

model: Callable,

verifier: Callable,

max_compute: int = 4096

):

self.model = model

self.verifier = verifier

self.max_compute = max_compute

def generate(

self,

prompt: str,

depth: int = 4,

branches_per_level: int = 4

):

"""

典型的 Tree-of-Thought 实现：

• 每层生成多个候选
• verifier 打分，剪枝只保留 top-k
• 递归直到达到深度或 compute 上限

"""

current_level_candidates = [prompt]

for d in range(depth):

next_level = []

for cand in current_level_candidates:

# 在当前候选下生成多个分支

tokens_used = (d + 1) * 50 # 估算

if tokens_used > self.max_compute:

break

responses = self.model.generate_n(

cand,

n=branches_per_level,

max_tokens=50

)

scored = [

(self.verifier.score(cand, r), r)

for r in responses

]

scored.sort(key=lambda x: x[0], reverse=True)

# 只保留 top-1 继续搜索

best_score, best_response = scored[0]

next_level.append(best_response)

current_level_candidates = next_level

# 最终从所有层的结果中选最优

final_scores = [

(self.verifier.score(prompt, c), c)

for c in current_level_candidates

]

final_scores.sort(reverse=True)

return final_scores[0][1]

`

生态现状

目前实现 Test-Time Scaling 的主流框架：

• **OpenAI o1/o3**：闭源，通过 API 提供，体验最完整但不可定制
• **vLLM 0.6+**：实现了 `generate_with_speculative`，可以配合外部 verifier
• **SGLang 0.4+**：支持 Tree-of-Thought 的beam search 变体
• **LMQL**：专门为可控生成设计的 DSL，原生支持 test-time compute

总结

Test-Time Compute Scaling 代表的不仅仅是一个优化技巧，而是对"智能在哪里产生"这个根本问题的重新回答。当我们不再把所有知识压缩进模型权重，而是允许在推理时动态组合和验证，那模型可以变得更小、更便宜，同时在复杂任务上保持竞争力。

这对于部署在资源受限环境（边缘设备、移动端、私有化部署）的 AI 应用来说，尤其有意义。一个可以在消费级 GPU 上通过推理时扩展达到 GPT-4 水平的 7B 模型，和一个必须调用云端 API 的 70B 模型，在隐私性、延迟和成本上的差异是本质的。

2026 年的 LLM 竞争，已经不只是训练场的军备竞赛——推理时计算正在成为新的主战场。