一句话定义
测试时计算（Test-time Compute）指模型训练完成之后，在每次回答具体问题时额外投入的算力——让模型多想一会儿、多试几次，而不是只靠训练时把知识压进参数里。
它为什么有用
过去提升模型能力，主要靠训练时计算（Train-time Compute）：更多数据、更大参数、更多训练算力。现在大家发现，推理阶段也能形成一条新的缩放曲线：给模型更多 token 去写中间推理步骤，或者并行采样多个候选答案再挑选，或者让它自我检查、回溯、重新尝试。
打个比方：训练时计算像平时刷题、背书；测试时计算像考试时允许你在草稿纸上多推演、多验算，甚至写几种解法再选最靠谱的。模型“多想一会儿”不是真的有了意识，而是把更多中间 token 当作计算步骤，每一步都可能修正方向。
和相邻概念的区别
| 概念 | 改什么 | 什么时候生效 | 典型代价 |
|---|---|---|---|
| 训练时计算 | 模型权重 | 训练一次，所有人共享 | 训练成本高 |
| 微调/蒸馏 | 模型参数或能力 | 训练后固化 | 需要数据和训练 |
| RAG/工具调用 | 给外部信息或执行动作 | 请求时 | 依赖外部系统 |
| 测试时计算 | 不改变权重，只增加当前请求的算力 | 每次回答时 | 延迟和 token 成本上升 |
简单说：RAG 是“查资料”，工具调用是“动手做”，测试时计算是“在脑子里多推几遍”。
代价是什么
第一，延迟。用户可能从等一两秒变成等十几秒甚至更久，交互式产品体验会明显变化。
第二，成本。输出 token 成倍增加，如果并行采样多个答案，消耗可能是普通回答的数倍。对服务方来说，同样的 GPU 能支撑的并发请求变少，推理吞吐下降。
第三，可能过度思考。简单问题也写一大段推理，回答啰嗦，还容易把本来对的答案改错。测试时计算的收益通常不是线性的：简单题收益低，难题收益高，超过一定预算后还会边际递减。
第四，系统复杂度。想让“多想”真的更准，往往需要验证器、奖励模型、投票策略或预算控制；否则只是让模型多写废话。
第五，安全与可观测性。更长的中间推理可能包含敏感信息，需要过滤和审计；同时，更复杂的推理也可能被用于更复杂的攻击。
对从业者和普通人的意义
对从业者，测试时计算是一个预算分配问题：简单请求走快路径，复杂请求走慢路径；监控 token 成本和延迟；用验证器或多数投票提升可靠性；常见问题做缓存。对普通人，会越来越多看到“深度思考”这类选项：答案可能更准，但更慢、更贵，免费额度也可能更有限。提问时把约束说清楚，能减少无效思考；涉及事实和时效信息，仍然要核实。具体产品能力、价格和限制，以官方页面为准。