AI也要007？Letta、伯克利提出「睡眠时间计算」，推理效率翻倍还不加钱

tayun

AI 也要 007 工作制了！

近日，AI 初创企业 Letta 和 UC 伯克利的研究人员提出了一种扩展人工智能能力的新方式 —— 睡眠时间计算（Sleep-time Compute），让模型在空闲时间「思考」，旨在提高大型语言模型（LLM）的推理效率，降低推理成本，同时保持或提升准确性。

睡眠时间计算的核心理念在于：智能体即使在「睡眠」（即用户未提出查询时的闲置状态）时段，也应持续运行，利用这些非交互期重组信息、提前完成推理。当前许多智能体都运行于存在持久化上下文的环境中。例如，代码智能体可以在编程请求到来前预先研习代码库；对话智能体则可反思用户过往的交流记录，在交互前重新整理信息。

在睡眠时段实行推理的过程将「原始上下文」（raw context）转化为「学习到的上下文」（learned context）。与仅拥有原始上下文的智能体相比，具备预处理能力的智能体可在实际应答时减少即时推理计算的负担，因为它们已经提前进行了思考。

论文标题： Sleep-time Compute: Beyond Inference Scaling at Test-time

论文地址：https://arxiv.org/pdf/2504.13171

项目地址：https://github.com/letta-ai/sleep-time-compute

从测试时间扩展到睡眠时间扩展

在过去的一年里，大家见证了「推理模型」的崛起：这些模型在回答之前会进行「思考」。例如，OpenAI 的 o1、DeepSeek 的 R1 和 Anthropic 的 Claude 3.7 等最新模型，不再即时给出回复，而在返回最终回答前输出一段详细的推理过程。这种延迟输出结构在数学、编程等特定应用领域中表现出显著的智能提升。实践证明，让模型在测试时（test time）实行更长时间的推理计算（从几秒至几分钟不等），能够显著提高模型的推理质量。

这种策略被称为「测试时扩展」，它已被广泛证实是推动基于大型语言模型（LLM）的 AI 系统迈向下一个智能层级的高效路径 —— 测试时推理资源投入越多，系统表现往往越佳。

但这是否只是冰山一角？大家是否在严重低估当前 AI 系统的潜力？假如仅在用户触发交互时才启用智能体的推理能力，那是否意味着这些模型的绝大部分时间都未被有效利用？

研究人员相信，AI 系统中存在着一种尚未被充分释放的范式转变：不仅在响应提示时被动地进行推理，而且在未被激活期间主动加深其对世界和任务的理解 —— 这正是他们所提出的「睡眠时间」（sleep time）概念，即：AI 系统在不与用户交互的漫长空闲期间，也能深入处理和组织信息。

于是他们在最新的研究论文中提出「睡眠时间计算」。它为具备状态性的 AI 系统（stateful AI systems）提供了一个令人兴奋的全新扩展路径：通过在系统本应用于空闲的时段启用深层思维，大家可以前所未有地拓展模型的理解能力与推理方式，从而突破仅靠交互时计算资源所能实现的能力上限。

睡眠时间计算

在标准的测试时间计算应用范式中，用户向 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 展示了不同模型在 Stateful AIME 数据集上的结果。大家看到，应用睡眠时间计算后，测试时间和准确率都发生了显著的帕累托偏移，但 o1 除外，它的增益有限。

对于问题 2：扩展睡眠时间计算

接下来，编辑想了解在睡眠时间内扩展计算量如何进一步影响帕累托转变。

在图 7 中，大家看到进一步扩展睡眠时间计算会使帕累托曲线外移，在相似的测试时间预算下，性能提升高达 13%。

在图 26 中，编辑进一步扩展了睡眠时间计算。大家看到了相同的结果，扩展睡眠时间计算通常会使帕累托曲线外移，性能提升高达 18%。

对于问题 3：在具有共享上下文的查询之间分摊睡眠时间计算

编辑还希翼了解如何通过在每个上下文都有多个查询的设置中应用睡眠时间计算来改善推理的总成本。大家看到，与单查询基线相比，当每个上下文有 10 个查询时，每个查询的平均成本降低多达 2.5 倍。

对于问题 4：可预测查询从睡眠时间计算中获益更多

在图 10 中，大家看到随着问题从上下文中变得更加可预测，睡眠时间计算和标准测试时间计算之间的准确度差距不断扩大，这证实了本文的假设，即当问题能够通过上下文预测时，睡眠时计算最能发挥其优势。

了解更多内容，请参考原论文。


来源：36kr