Scaling Law 没有失效，只是从训练场转向了推理现场

过去几年，Scaling Law 常被简化成一句话：更多参数、更多数据、更多算力，换来更低的训练损失。这个方向仍成立，但它描述的是模型出厂前的经济学。推理模型带来的变化是，能力不再完全冻结在权重里，系统可以在回答某一道题时继续投入计算。缩放没有结束，计算开始从资本开支进入每次请求的成本表。

OpenAI 在 o1 的公开说明中把训练时强化学习与测试时思考时间同时列为能力来源。两条曲线的区别很关键：训练计算被所有用户共同摊销，推理计算却要为每个请求重新支付。于是同一个模型可以快速答常识题，也可以花更多 token 搜索数学证明；产品不再只有模型版本，还有可动态调节的思考档位。

推理时扩展真正改变的是计算的投放方式。系统可以先生成候选路径，再用搜索、执行器或判别器淘汰明显错误，必要时回到分叉点重新探索。计算不再平均撒给所有请求，而是被一个外部控制回路按难度逐步追加；因此，同一底座模型的实际能力取决于预算分配、反馈质量与停止策略的组合。控制回路设计得好坏，往往比单纯增加生成长度更能决定收益。

这意味着新的 Scaling Law 更像一条价值曲线，而不是单纯的损失曲线。系统需要判断多想一秒是否仍能显著提高正确率，并把额外成本留给高价值、高不确定性任务。推理预算正在成为产品参数：极速模式、深度研究、代码审查和高风险决策，本质上是同一模型的不同计算合同。

反方意见是，测试时多算常被包装成能力进步，实质却可能只是昂贵的自我重复。若任务没有明确反馈，模型会把错误假设扩写得更完整；若验证器与生成器同源，它们还可能稳定地共享偏见。延迟增加也会改变用户行为：人在等待中重复提交、提前退出或自行接管，最终让纸面上的正确率提升失去产品价值。高并发场景里，少数长请求还可能拖累所有人的响应。

对开发者而言，最重要的架构变化是把路由、验证与停止条件放到模型调用之外。先用廉价步骤判断问题难度，再决定是否增加搜索、采样、工具调用或验证器；当边际收益下降就停止。只把 max_tokens 调大，常常只会买来更长的解释，并不会自动买来更可靠的答案。

推理时扩展也有清晰的天花板。模型可能在错误前提上反复推演，验证器可能和生成器共享盲点，长思考还会放大延迟与用户焦虑。更多计算不等于更多真相。当任务缺少可验证反馈时，最有效的投入可能是取回新证据、询问用户，或让另一种模型独立复核。

判断是否值得增加推理预算，应从任务分层开始。把请求按可验证性、失败损失、时延容忍度和答案价值分组，记录每一档预算带来的完成率增量，而不是只看平均分。对代码可用测试闭环，对研究可核对来源，对主观建议则应优先补充信息。只有额外计算能稳定减少关键失败时，深度模式才值得成为默认选项。上线后还要按任务类型持续重估这条收益曲线。

商业上，这会改变模型厂商与应用公司的分工。基础模型提供可扩展的推理能力，应用层掌握任务价值、时延容忍度和失败代价，因此更有条件决定计算该花在哪里。能够估计一次回答值多少钱的产品，会比只会比较每百万 token 单价的产品更接近真实毛利。

评估体系也必须跟着改变。单一固定预算的榜单无法回答产品问题；团队要观察不同推理预算下的正确率、P95 延迟、工具失败率和单位成功成本，画出自己的帕累托前沿。只有这样，所谓“深度思考”才是可运营能力，而不是一个让账单失控的按钮。

更深一层看，新的缩放对象不是某个模型，而是整套决策系统。预训练把通用模式压进权重，推理运行时则把企业对风险、价值和速度的判断写进调度。谁拥有真实任务的反馈，谁就能学会把计算放在最有回报的位置。模型参数仍重要，但长期差异会更多来自一套不断更新的计算治理能力。这也是应用公司能够在基础模型之上积累独特优势的地方。

下一阶段的优势不会只属于拥有最大预训练集群的公司。真正难复制的是一套知道何时快答、何时深想、何时查证、何时停下的运行系统。未来的模型体验，本质上是计算分配体验；Scaling Law 从未消失，它只是进入了每一次用户交付。

一个常被忽略的场景是团队协作任务：需求理解、资料检索、代码修改和最终验收需要不同强度的推理。若从头到尾都使用最高档位，成本和等待会集中在机械步骤；若全程快答，关键决策又缺少复核。更合理的流程是让状态变化触发预算升级，把深思留给方案分叉、证据冲突和不可逆动作。阶段之间保留摘要与验收结果，还能避免每次升级都重新阅读全部历史。

以《Scaling Law 没有失效，只是从训练场转向了推理现场》为例，真正可落地的单位不是一次模型调用，而是一张任务卡：输入来自哪里、允许调用哪些工具、什么证据可以判定成功、超过多长时间或多少成本就必须停止。把这些条件写成运行时契约，团队才能区分“模型给了一个看似合理的答案”和“系统完成了一项可以交付的工作”。

这类系统最值得警惕的不是显眼的答错，而是稳定地在错误目标上表现得很流畅。检索到过期材料、把相关性误作因果、验证器和生成器共享同一盲点，都会让结果看起来更有条理却并不更可靠。因此评测必须保留反事实、冲突证据和拒答样本，专门测试系统何时应该减速或说不知道。

这也要求财务与产品指标重新对齐。账单上的 token 消耗只能说明投入，无法说明哪部分计算避免了返工或事故。团队应把推理调用关联到任务阶段和最终结果，识别哪些深度步骤真正贡献了完成率。没有这种归因，降本会误伤质量，追求质量又会演变为没有上限的预算扩张。把费用分摊到成功任务与失败类型，才能判断预算究竟花在了哪里。

运营层面，应把成功率拆成可观察的漏斗：是否理解任务、是否拿到足够证据、是否完成有效行动、用户是否接受结果，以及失败能否低成本恢复。只报一个最终准确率，会掩盖不同环节的瓶颈。按任务价值和风险分层记录这些事件，才能决定昂贵推理、工具调用和人工复核究竟该投向哪里。

推理时扩展最终会逼迫产品明确自己的责任边界：当证据不足时，是继续搜索、让模型猜测，还是把不确定性还给用户。最成熟的系统并非永远愿意多想，而是知道计算不能替代新事实，也不能替代人对价值的选择。停止不是能力耗尽的信号，而是系统判断继续消耗已不再改善承诺。这种克制让深度推理成为可靠工具，而不是新的算力崇拜。

组织也需要为模型行为预留版本纪律。提示词、工具描述、检索索引、模型权重和评测集中的任何一项变化，都可能改变结果；没有基线和回放机制，团队无法判断一次升级是在进步还是在转移失败。把运行轨迹与输入版本保存下来，不是为了事后追责，而是为了让改进真正可学习。

长期来看，模型能力会继续变化，难以替代的资产则是对任务的理解：哪些情况可验证、哪些错误代价最高、哪些决策需要人来承担。能把这些判断沉淀为评测、路由和交付边界的产品，才会把通用能力变成持续可靠的服务，而不是把每次模型更新当成一次重新下注。