搞了两个小时读论文，发现一个让人拍大腿的工作——s1: Simple Test-time Scaling。这玩意儿简单到什么程度？用 1000条推理数据 + 26分钟训练，直接干翻了 OpenAI 的 o1-preview。

我知道这话听起来跟标题党似的，但数据不会骗人：AIME24 数学竞赛题上，s1-32B 比 o1-preview 高了 27%。而且整个方案全开源，代码、模型、数据全部公开。

背景：o1 之后，大家都在卷什么？

自从 OpenAI 放出 o1，整个 AI 圈就进入了一个新赛道——测试时计算缩放（Test-time Scaling）。

传统路线是训练时堆算力：模型越大、数据越多，效果越好。o1 展示了另一条路：推理的时候多想想，效果也能涨。

但问题在于，o1 没开源。DeepSeek-R1 虽然复现了类似效果，但用了百万级数据和多阶段强化学习。那问题就来了：

有没有最简单的方案？能不能只花一点点代价，就搞出测试时缩放的能力？

这是 s1 论文要回答的核心问题。而他们的答案，简单得有点离谱。

s1K：只有 1000 条的宝藏数据集

整个工作的第一块基石，是一个只有 1000 条数据 的数据集，叫 s1K。

这 1000 条不是随便挑的，作者用了三个筛选原则：

1. 难度（Difficulty） — 太简单的题去掉，模型本来就做得对，学了没意义
2. 多样性（Diversity） — 覆盖数学、物理、化学、生物、天文、编程等不同领域
3. 质量（Quality） — 推理过程要完整、规范

他们先从 16 个公开数据集凑了 59K 条原始数据，然后用这三个标准层层筛选，最后只留下 1000 条。

消融实验（ablation）结果很有意思：

• 随机选 1000 条 → 性能暴跌约 30%
• 选最长的推理轨迹 → 也不行
• 只追求多样性 → 同样不行
• 三个条件都满足 → 效果最好

更有意思的是，把全部 59K 数据都用上，效果并没有比 1000 条好多少。这说明数据质量远比数量重要，跟之前指令微调领域的发现（比如 LIMA 论文）是一致的。

Budget Forcing：最优雅的"思维控制术"

如果说 s1K 解决了"学什么"的问题，那 Budget Forcing 就解决了"想多久"的问题。

这个 idea 既简单又巧妙：

场景一：想太多了

当模型思考超过你设定的预算时，直接强制终止思考过程，让它开始输出答案。

场景二：想太少了

当模型想结束但你觉得还能再想想时，拦截它的结束标记，在推理轨迹后面追加一个 “Wait”，模型就会继续思考，经常能自己纠正之前的错误。

想象一下：模型算到一半说"结果是 2"，你把它的"句号"抢过来，说"等等，再想想"，它就会嘀咕"哦不对，应该是 4"。就是这个效果。

而且这个方案最妙的地方在于 —— 你可以精确控制思考深度。想让它想 100 个 token 就想 100 个，想让它想 10000 个也行。不像其他方案只能被动等它结束。

=80%x

效果：就硬比 o1-preview 高 27%

在 Qwen2.5-32B-Instruct 上做 SFT 微调（16 张 H100，26 分钟搞定），然后用 Budget Forcing 控制推理深度，结果如下：

基准	s1-32B vs o1-preview
MATH	高 27%
AIME24	基础 50% → Budget Forcing 可推到 57%

而且 s1-32B 还有个特别棒的性质：随着测试时计算量的增加，性能持续线性提升。你给它越多思考时间，它答得越好。这是真正的"测试时缩放"，不是碰巧蒙对的。

为什么这篇论文值得认真看

说几个让我觉得特别牛的点：

极致的简洁。用 1000 条数据 + 标准 SFT + 一个简单的 trick，就复现了 o1 级别的测试时缩放能力。没有 MCTS，没有多智能体，没有多阶段 RL。26 分钟训练完事。

清晰的 scaling 行为。很多 o1 复现方案只报告了最终分数，没有展示随着思考时间增长性能如何变化。s1 明确给出了 scaling curve，这是真东西。

全开源。模型、数据、代码全部公开，任何人都可以复现和改进。

“Wait” 的妙用。这个简单的 trick 其实揭示了一个深层原理：在推理轨迹后面追加提示词，本质上是在给模型创造"重新审视"的机会。这跟人类思考时的"等等，我再看一遍"是同一个道理。

一些自己的思考

测试时计算缩放这个方向，s1 做了很重要的"科学简化"工作，把复杂的东西拆到最简。但我觉得还有几个问题值得想：

• 数据来源依赖 Gemini。s1K 的推理轨迹是从 Gemini Thinking Experimental 蒸馏的，如果教师模型有偏见或错误，会直接传递给 s1。
• 只有数学/竞赛场景。论文的评估集中在数学和竞赛题上，在更开放的写作、代码生成等场景中，测试时缩放的效果如何还不好说。
• Budget Forcing 的"Wait"策略虽然有效，但每次追加都加一个 token，有没有更好的引导方式？

不管怎么说，作为一个起点，“1000 条数据 + SFT + Budget Forcing” 这个组合拳已经够漂亮了。强烈推荐感兴趣的读者去看看原文和代码：

• 论文：https://arxiv.org/abs/2501.19393
• 代码：https://github.com/simplescaling/s1
• 数据集：s1K 随代码仓库一起发布

写在最后

说实话，读这篇论文的时候我一直在想：有时候最简单的方法反而是最被低估的。 大家都在堆 RL、堆搜索、多轮蒸馏的时候，有人停下来思考"最简方案是什么"，然后真的做出来了。

这可能才是科研该有的样子。

---

如果你对测试时计算缩放、推理模型感兴趣，欢迎留言讨论。后续我会继续解读其他相关工作，比如 DeepSeek-R1 的技术细节、Overthinking 现象等。