Sleep-time Compute: Beyond Inference Scaling at Test-time
Kevin Lin, Charlie Snell, Yu Wang, Charles Packer, Sarah Wooders, Ion Stoica, Joseph E. Gonzalez
cs.AI, cs.CL
2025-04-18
提问前对已有上下文离线推理。GSM与AIME上同等准确率只需约1/5测试时token,加大睡眠期算力准确率最高再涨13%和18%。
测试时扩算力已经是难问题的标准打法。o1、DeepSeek-R1 这类模型拿到题之后会想很久,准确率上去了,用户要等几分钟,单次查询甚至能花到几十美元。现有做法默认问题是无状态的:上下文和查询同时到达,模型从零开始推。同一份文档、同一份代码仓库上连问三句,重复的中间推理每次都要重算一遍。
实际产品很少是无状态的。文档问答、代码助手、多轮对话里,文档、仓库、聊天记录在用户下一次开口之前就已经在那儿了。模型空闲的那段时间被浪费掉。Letta 和 UC Berkeley 把这段空闲叫 sleep-time,并把推理挪到查询到达之前。
标准流程把全部预算 B 花在用户提交之后,记作 TB(q, c) → a。sleep-time compute 拆成两段。
睡眠期只有上下文 c、没有查询 q。模型被提示去推断可能的问题,把上下文重写成更利于答题的表示 c′,记作 S(c) → c′。实现上走 function calling:rethinkmemory 用新字符串替换当前上下文,finishrethinking 结束循环,最多调用 10 次。测试时把 c′ 塞进提示,用小得多的预算 b 答题。同一段 c′ 可以在多条相关查询之间共享,睡眠期开销被摊薄。
为了制造「上下文先到、问题后到」的评测环境,论文把现成推理基准按句切开:
GSM 上用 GPT-4o-mini 和 GPT-4o,靠五档 verbosity 提示控制测试时算力,从「直接一句话回答」到「先复查推理」,温度 0。AIME 上用 o1、o3-mini、Claude 3.7 Sonnet Extended Thinking、DeepSeek-R1;前三个走 API 的 reasoning effort,R1 用 s1 论文的 budget forcing。o1、o3-mini、R1 各跑 3 次取平均,Claude 噪声大,跑 10 次。主基线是标准测试时算力。附录里还有一个「只给 c、让模型猜最可能的问题并作答」的对照,用来确认问题不能从上下文直接猜出来。
低测试时预算下,sleep-time compute 把准确率-算力 Pareto 往外推:达到同等准确率,Stateful GSM-Symbolic 和 Stateful AIME 大约只需 1/5 的测试时 token。预算拉满时,纯测试时基线会略胜一筹。论文的解释是标准设置里提示词更干净,睡眠期写进去的额外推断成了干扰。o1 是例外,增益有限。
加大睡眠期算力还能再抬准确率。非推理模型对同一 c 并行生成 k 份 c′ 再拼起来;推理模型则调高睡眠期的 reasoning effort。GSM-Symbolic 上准确率最多再涨 13%,AIME 上最多 18%。并行份数不是越多越好,5 路通常好过 10 路。
跟并行测试时扩算力比,同等测试时 token 预算下 sleep-time 整体压过 pass@k。pass@k 还默认测试时有标准答案校验器,sleep-time 没有这个假设。
摊销实验把测试时 token 按延迟优化推理大约贵 10 倍来计价。每个上下文摊到 10 条相关查询时,平均每问成本最多降 2.5 倍;查询很少时,睡眠期开销摊不薄,总账不一定划算。
用 Llama-2-70B 计算 log P(question | context),按可预测性分成五档,测试时用最低 verbosity。问题越容易从上下文猜到,sleep-time 相对标准测试时的准确率缺口越大。
SWE-Features 上低预算时 sleep-time 的文件级 F1 更高,测试时 token 大约少 1.5 倍;图上 F1 大致落在 0.3 到 0.4。高预算时标准测试时更好,精度更高、召回差不多。睡眠期逛过更多文件的 agent,测试时也倾向于改更多文件。
产品形态对得上:文档助手、代码 agent、带长期记忆的对话,上下文本来就先到。o1 级思考不必整段落在用户提交之后,可以挪到空闲窗口。对延迟敏感、查询模式可预期的场景,这是一条比 pass@k 更贴近真实约束的扩算力轴。
它不是新模型,是调度。现有的长 CoT、best-of-N、reasoning effort 都可以原样塞进睡眠期。代码和数据已公开。
边界也很清楚。查询不可预测时,预先写进去的 c′ 就是噪声。高预算时它甚至会拖后腿。数学基准是把原题最后一句拆开构造的,比真实用户会问什么要规整。SWE 实验只有 33 条,指标还停在改了哪些文件。
论文自己点了几处。查询难以从上下文预测时,sleep-time 不如直接把算力花在测试时。真实交互不是干净的两阶段:仓库会被改,空闲可长可短,当前实验没覆盖。作者把 c′ 类比成自然语言空间里的 representation learning,这是展望,没有实验支撑。
实验设计有几处偏乐观。把原题按句切开,「问题从上下文可预测」几乎是构造出来的性质,可预测性分析等于在自己造的分布上验证假设。Multi-Query 的额外问题由 o3-mini 生成,相关性被写进了数据生成过程,2.5 倍摊销数字不能直接外推到真实用户提问。SWE-Features 不用测试通过率,文件 F1 停在大约 0.3 到 0.4,离「这个功能写对了」还远。o1 增益有限这件事没有细拆,不清楚是模型已经会自己规划,还是睡眠期提示对 o1 不合适。