AI也要007？Letta、伯克利提出「睡眠时间计算」，推理效率翻倍还不加钱
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
机器之心报道
编辑：+0、陈陈
AI也要007工作制了！
近日，AI初创公司Letta和UC伯克利的研究人员提出了一种扩展人工智能能力的新方式——睡眠时间计算（Sleep-timeCompute），让模型在空闲时间「思考」，旨在提高大型语言模型（LLM）的推理效率，降低推理成本，同时保持或提升准确性。
睡眠时间计算的核心理念在于：智能体即使在「睡眠」（即用户未提出查询时的闲置状态）时段，也应持续运行，利用这些非交互期重组信息、提前完成推理。当前许多智能体都运行于存在持久化上下文的环境中。例如，代码智能体可以在编程请求到来前预先研习代码库；对话智能体则可反思用户过往的交流记录，在交互前重新整理信息。
在睡眠时段执行推理的过程将「原始上下文」（rawcontext）转化为「学习到的上下文」（learnedcontext）。与仅拥有原始上下文的智能体相比，具备预处理能力的智能体可在实际应答时减少即时推理计算的负担，因为它们已经提前进行了思考。
论文标题：Sleep-timeCompute:BeyondInferenceScalingatTest-time
论文地址：https ://arxiv.org/pdf/2504.13171
项目地址：https ://github.com/letta-ai/sleep-time-compute
从测试时间扩展到睡眠时间扩展
在过去的一年里，我们见证了「推理模型」的崛起：这些模型在回答之前会进行「思考」。例如，OpenAI的o1、DeepSeek的R1和Anthropic的Claude3.7等最新模型，不再即时给出回复，而在返回最终回答前输出一段详细的推理过程。这种延迟输出结构在数学、编程等特定应用领域中表现出显著的智能提升。实践证明，让模型在测试时（testtime）执行更长时间的推理计算（从几秒至几分钟不等），能够显著提高模型的推理质量。
这种策略被称为「测试时扩展」，它已被广泛证实是推动基于大型语言模型（LLM）的AI系统迈向下一个智能层级的高效路径——测试时推理资源投入越多，系统表现往往越佳。
但这是否只是冰山一角？我们是否在严重低估当前AI系统的潜力？假如仅在用户触发交互时才启用智能体的推理能力，那是否意味着这些模型的绝大部分时间都未被有效利用？
研究人员相信，AI系统中存在着一种尚未被充分释放的范式转变：不仅在响应提示时被动地进行推理，而且在未被激活期间主动加深其对世界和任务的理解——这正是他们所提出的「睡眠时间」（sleeptime）概念，即：AI系统在不与用户交互的漫长空闲期间，也能深入处理和组织信息。
于是他们在最新的研究论文中提出「睡眠时间计算」。它为具备状态性的AI系统（statefulAIsystems）提供了一个令人兴奋的全新扩展路径：通过在系统本应用于空闲的时段启用深层思维，我们可以前所未有地拓展模型的理解能力与推理方式，从而突破仅靠交互时计算资源所能实现的能力上限。
睡眠时间计算
在标准的测试时间计算应用范式中，用户向LLM输入一个提示p，然后LLM应用测试时间计算来帮助回答用户的问题。
然而，提供给LLM的提示p通常可以分解为一个已存在的上下文c（例如一个代码库）和一个用户查询q（例如关于代码库的问题）。
当LLM没有及时响应用户时，它通常仍然可以访问现有的上下文c。在这段时间里，LLM通常处于闲置状态，错过了离线思考c的机会：本文将这个过程称为睡眠时间计算。
测试时间计算：在测试时间计算设置中，用户提供q和一些上下文c，模型输出推理跟踪，后面跟着最终答案a。
这个过程可以表示为：T_B（q,c）→a，其中T是在预算B下测试时间计算的方法，包括扩展思维链或best-of-N等技术。
在实践中，用户可能对同一上下文有多个查询q_1，q_2…q_N。在此设置下，模型将对每个q_i进行独立的推理过程，即使它们与相同的上下文有关。
此外，在许多情况下，上下文信息c可能非常复杂，需要执行大量的推理才能生成问题q的答案。由于传统测试时计算范式T(q,c)→a假定c与q同时获取，标准测试时计算会在用户提交查询后才启动所有这些推理，导致用户可能需要等待数分钟才能获得响应。然而在实际应用中，我们往往能够提前获取c，并将大部分预处理工作前置完成。
睡眠时间计算：在睡眠时间，可以得到上下文c但没有查询q。仅基于这个上下文c，可以使用LLM推理可能的问题并推理上下文，最终产生一个更新的重新表示的上下文c′。研究者将这个过程表示为：S(c)→c′，其中S可以是任何标准的测试时间扩展技术，用于在睡眠时间预处理上下文。
在这项工作中，S(c)是通过提示模型进行推理并以可能在测试时有用的方式重写c来实现的。在对上下文进行预处理之后，可以在测试时提供新的上下文c′代替c来生成对用户查询的最终答案：T_b(q,c′)→a。由于在这种情况下，关于c的大部分推理已经提前完成，就可以使用小得多的测试时间预算b<<B。此外，c′可以在关于相同上下文的不同查询q_i之间共享，从而有效地摊销在查询之间得出c′所需的计算，从而节省总体成本。
实验及结果
本文通过实验来探究睡眠时计算的优势，并重点回答了以下问题：
1.睡眠时计算能否改变测试时计算与准确率之间的帕累托边界？
2.扩展睡眠时计算规模能否进一步优化该帕累托边界？
3.当单个上下文对应多个关联问题时，分摊测试时计算与睡眠时计算能否带来总体token效率提升？
4.睡眠时计算在哪些场景中能带来最显著的性能提升？
对于问题1：应用睡眠时间计算改变帕累托边界
图3表明准确率和测试时计算之间存在权衡，并且添加睡眠时间计算可以超越帕累托计算-准确率曲线。
图4展示了不同模型在StatefulAIME数据集上的结果。我们看到，应用睡眠时间计算后，测试时间和准确率都发生了显著的帕累托偏移，但o1除外，它的增益有限。
对于问题2：扩展睡眠时间计算
接下来，作者想了解在睡眠时间内扩展计算量如何进一步影响帕累托转变。
在图7中，我们看到进一步扩展睡眠时间计算会使帕累托曲线外移，在相似的测试时间预算下，性能提升高达13%。
在图26中，作者进一步扩展了睡眠时间计算。我们看到了相同的结果，扩展睡眠时间计算通常会使帕累托曲线外移，性能提升高达18%。
对于问题3：在具有共享上下文的查询之间分摊睡眠时间计算
作者还希望了解如何通过在每个上下文都有多个查询的设置中应用睡眠时间计算来改善推理的总成本。我们看到，与单查询基线相比，当每个上下文有10个查询时，每个查询的平均成本降低多达2.5倍。
对于问题4：可预测查询从睡眠时间计算中获益更多
在图10中，我们看到随着问题从上下文中变得更加可预测，睡眠时间计算和标准测试时间计算之间的准确度差距不断扩大，这证实了本文的假设，即当问题能够通过上下文预测时，睡眠时计算最能发挥其优势。
了解更多内容，请参考原论文。
©THEEND
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
