测试时计算
测试时计算（也称推理时计算）是一种做法，让 LLM 在推理时"思考"更久，比如生成更多推理 token、运行多条推理链，或采样许多候选并挑出最佳，从而在不重新训练模型的前提下提升回答质量。它因 OpenAI 的 o1 和 DeepSeek-R1 在 2024 至 2025 年的流行而广为人知，把推理从一个训练问题变成了一个运行时旋钮。
测试时计算（也称推理时计算）是一种做法，让 LLM 在推理时"思考"更久，比如生成更多推理 token、运行多条推理链，或采样许多候选并挑出最佳，从而在不重新训练模型的前提下提升回答质量。它因 OpenAI 的 o1 和 DeepSeek-R1 在 2024 至 2025 年的流行而广为人知，把推理从一个训练问题变成了一个运行时旋钮。
为什么重要
在 LLM 时代的大部分时间里，让模型更聪明的唯一办法就是用更多数据训练一个更大的模型。测试时计算打破了这种依赖。OpenAI 的 o1 表明，同一个基础模型，在回答前被给予 10 到 30 倍的 token 来推理，就能在数学、编程和逻辑基准上追平甚至超越大得多的非推理模型。这重新定义了推理预算：团队现在不再问"用你能负担得起的最大模型"，而是问"在这条查询上，我愿意为多少思考量付费？"推理的经济性发生了变化，产品设计也随之改变，因为推理质量如今可以在单次请求层面进行调节。
工作原理
更长的思维链：模型在可见答案之前输出数百乃至数千个内部推理 token。思考越多 → 答案越好。
多次采样（自洽性）：生成 N 个不同的答案，挑出模型最常得出的那一个。在数学上简单而有效。
树搜索 / 集束搜索：并行探索多条推理分支，剪掉差的，延展有希望的。
过程奖励模型：用第二个模型为每个推理步骤打分，并引导主模型走向更好的路径。OpenAI 的过程监督中用到了这一点。
验证器引导的搜索：生成许多候选，运行一个外部验证器（单元测试、数学检查器、LLM 评判者），返回最佳结果。
Best-of-N + 重排序：更简单的变体。生成 16 到 64 个候选，用奖励模型重排序，返回排名第一的。
取舍
每一种测试时计算技术都是用延迟和成本来换取准确度：
延迟：一个不做推理时只需 500 毫秒的回答，在重度测试时计算下可能需要 5 到 30 秒。
成本：推理 token 的费用和其他输出 token 一样高。一个带有 10000 个思考 token 的 o1 回答，成本约为一个简单 GPT-4o 回答的 30 到 50 倍。
收益递减：准确度与计算量的曲线会趋于平缓。从 1000 增加到 10000 个推理 token 的帮助，大于从 10000 增加到 100000 个的帮助。
并非总是有用：简单的事实查询和友好的闲聊并不能从推理中获益。在"今天天气怎样"上强用 o1 是浪费钱。
何时使用
数学与形式逻辑：测试时计算帮助巨大。在 GSM8K、MATH、AIME 上，推理模型比基础模型高出 20 到 40 分。
带测试的代码生成：生成、运行测试、迭代。验证器引导的搜索大放异彩。
多步规划：智能体决策、复杂指令、多约束优化。
高风险的单次查询：医疗、法律、金融，在这些领域，为一个正确答案花 5 秒和 0.3 美元，相比答错的代价是很便宜的。
何时不要使用
1 秒以内预算的聊天 UX：延迟会拖垮用户体验。
大批量工作负载：token 膨胀 20 到 50 倍，会让任何高流量端点变得不经济。
简单的检索或摘要：一次成型的答案就够了，思考更久也无济于事。
开放式创意写作：更多的推敲会让输出显得生硬。
推理模型 vs 常规模型
| 维度 | 常规（GPT-4o、Claude 3.5） | 推理（o1、R1、Claude Opus 4.6 thinking） |
|---|---|---|
| 响应速度 | 快 | 慢 |
| Token 成本 | 低 | 高 |
| 数学 / 逻辑 | 尚可 | 出色 |
| 创意写作 | 强 | 有时生硬 |
| 聊天 UX | 理想 | 大材小用 |
| 最佳用途 | 大多数请求 | 困难查询 |
模型路由，即把简单查询发给快速模型、把困难查询发给推理模型，是标准的生产模式。
常见错误
到处都用推理模型：会迅速推高成本和延迟，却并不能改善大多数答案。
不限制思考 token 的预算：一段无上限的推理轨迹，可能在一条查询上吃掉数千美元。
忽视缓存：推理轨迹往往是重复的。提示词缓存可以大幅降低成本。
跳过评估：团队想当然地认为推理 = 更好。但对于他们特定的领域，未必如此，投入之前先做基准测试。
把思考 token 与输出混为一谈：除非用户主动要求，否则不应让他们看到推理轨迹。那是内部独白。
Sources: