测试时训练恢复不止于权重：模型检查点与搜索档案的配对难题

在搜索与训练耦合的循环中，仅靠保存最新权重来恢复实验，可能把一个从未存在过的状态当作「断点」继续跑下去。Reddit 上关于「Resuming test-time training needs more than the latest weights」的讨论，指向一个容易被工程团队忽略的问题：模型检查点和搜索档案共同描述同一个演化中的实验，恢复时必须成对还原。

为什么「只存权重」在 TTT 场景下不够

测试时训练（Test-Time Training, TTT）让模型在推理或搜索过程中持续更新参数。如果训练循环里还嵌入了搜索-训练交替的流程，状态就不再只存在于一份权重文件里。

据原帖描述，在 search-and-train loop 中，模型检查点（checkpoint）与搜索档案（search archive）描述的是同一个演化中的实验。搜索档案记录了哪些候选解被探索、哪些被保留，以及未来扩展所依赖的搜索进度。模型权重只反映参数更新，无法回答「之前试过哪些方案、放弃了哪些分支」这类问题。

所以，从「新权重 + 旧档案」重启，会制造出一个原始运行从未出现过的混合状态。后续基于这个状态的搜索扩展，也会偏离原定轨迹，而团队往往难以察觉——因为权重是新的、档案也是「有的」。

PUCT（Predictive Upper Confidence bound applied to Trees）是 AlphaZero 系列算法中使用的一种树搜索策略，全称为 Predictor + UCT。它在每次选择节点时，除了利用 UCT 的探索-利用权衡项，还引入了一个基于策略网络的先验预测项，用来指导搜索往更有希望的分支扩展。在 TTT 与搜索耦合的场景中，PUCT 搜索不是一次性完成的，而会在每个训练 step 后继续扩展，于是搜索树本身（哪些节点被访问、访问次数、价值估计等）构成了必须被持久化的状态。这正是「档案」承载的内容：它是搜索进度的完整快照，而不是简单的结果列表。

Reef Infra 的 TTT-Discover 如何处理配对

原帖提到 Reef Infra 的 TTT-Discover 示例给出了一种显式配对的做法：把 post-step 的 PUCT 搜索档案与已提交（committed）的模型版本绑定在一起。

具体机制是：搜索步骤完成后，先写入一个 pending archive；只有当与之对应的模型提交也建立起来后，才把这个档案标记为 committed。重启时使用配对状态——档案和模型版本必须互相匹配。

如果某一步缺失或不匹配，则 fail closed：不会悄悄用一份更新的检查点去启动 PUCT 搜索。这一点是关键设计选择。对照常见工程习惯，「找不到匹配状态就加载最新的」是默认行为，但在搜索-训练耦合场景里，这种「宽容」会静默污染实验。

档案里到底存了什么

档案承载的是搜索进度本身。恢复模型权重，不等于恢复了「探索过哪些候选解、保留了哪些」。对可验证的优化任务来说，这些信息直接决定后续搜索的起点和分支。

换句话说，档案是搜索的地图，权重是模型的状态。地图丢了或对不上，路线就无从复现。

Fail closed 是一种系统设计原则，指当出现异常、状态缺失或校验不通过时，系统选择中断或拒绝继续，而不是降级到某种「最接近的可用状态」继续运行。与之相对的是 fail open，即遇到问题时采用默认值或最新状态继续。在搜索-训练耦合的实验恢复中，fail open 的危险在于：最新检查点与旧档案可能来自不同演化阶段，一旦组合起来继续跑，产生的轨迹并未在任何一次真实运行中出现过，实验结论就失去了可追溯性。Fail closed 用可用性换取了状态一致性和实验可复现性，这是该场景下更合理的取舍。

一个可操作的恢复检查（提议，非基准）

原帖作者提出一个恢复检查思路，并明确说明这是提议的检查，不是所报告的恢复基准：

• 在一次运行中，于某个 step 边界处中断；
• 检查恢复时究竟是哪个档案与哪个模型版本一起被加载；
• 如果出现错配，恢复流程应当暴露出来，而不是静默继续。

这个检查的价值在于，它把「配对是否成立」变成可验证的动作，而不是依赖文档约定。对可验证的优化任务而言，这比跑一份漂亮的恢复曲线更基础。

「可验证的优化任务」通常指那些目标函数可以被程序自动评估、从而给出客观对错或分数的问题，例如代码生成后跑单元测试、数学题核对答案、约束满足问题检查合法性等。这类任务的搜索过程会被评估信号直接影响——哪些候选解被保留、哪些分支被剪枝，都依赖于此前评估过的结果。因此，档案中记录的历史评估信息不是可有可无的元数据，而是决定下一步搜索行为的输入。若档案与权重错配，即使权重本身正确，搜索也会基于一份错误的历史做出选择，最终优化结果无法对应到原来的实验条件。

基础设施层面的真正贡献：把配对显式化

原帖的判断很克制：有意思的基础设施贡献是让这个配对显式化（making the pair explicit）。

当训练和搜索都会改变状态时，「我们保存了权重」这个描述并不完整——它没回答「你能从什么状态恢复」。把 checkpoint 与 archive 的绑定关系写进提交逻辑、并在不匹配时 fail closed，是把隐性假设变成可执行约束。

这对做 TTT、搜索增强训练、agent 迭代优化的团队都有参考意义：状态管理不只是文件保存，而是对「可恢复状态」的定义。

分歧与待验证之处

原帖本身没有给出恢复基准或量化对比，因此配对机制的收益目前属于工程论证而非实测结论。中断检查也停留在提议阶段。若要在自己的流程里落地，仍需验证：档案与权重的提交粒度是否一致、fail closed 是否会在正常并发下误触发。