你有没有想过，为什么人类需要睡觉？

不是为了休息——肌肉放松不需要 8 小时。神经科学的答案是：记忆整合。白天经历的海量信息在睡眠中被大脑重新激活、压缩、筛选，重要的写入长期记忆，不重要的被丢弃。没有这个过程，新的学习会覆盖旧的记忆，认知系统逐渐崩溃。

如果把这个逻辑搬到 LLM 上呢？

Transformer 的注意力机制本质上是一个"永不睡觉"的系统——所有上下文都堆积在 KV Cache 里，每来一个新 token 就要和所有历史 token 做注意力计算。上下文越长，计算量呈二次方增长，内存占用线性膨胀。这和大脑在不睡觉时的状态惊人地相似：信息不断涌入，但没有一个"离线整合"的机制来压缩和提炼。

最近，CMU 和 Maryland 的研究团队在 Arxiv 上发了一篇论文 “Language Models Need Sleep”（2605.26099），正式把"LLM 需要睡觉"这个直觉变成了可验证的工程方案。更有趣的是，Letta 团队早在今年 4 月就提出了一个互补的思路 “Sleep-time Compute”（2504.13171），从推理优化的角度证明了"让模型在空闲时提前思考"能大幅降低推理成本。

两篇论文，两个角度，指向同一个结论：AI 系统需要一个类似"睡眠"的机制来处理信息过载。

瓶颈不在记忆容量，而在计算深度

“Language Models Need Sleep” 这篇论文的出发点很直接：现有的 SSM-Attention 混合模型（比如 Mamba-Transformer 混合架构）虽然通过固定大小的快权重（fast weights）解决了长上下文的内存问题，但记忆容量不等于推理能力。

论文作者做了一个干净的实验：他们让 SSM-Attention 混合模型做多跳图检索（multi-hop graph retrieval）和元胞自动机（cellular automata）推理，控制信息量不变，只增加推理深度。结果发现：随着推理深度增加，模型性能显著下降。

这意味着什么？当 KV Cache 被滑动窗口策略（sliding window eviction）强制截断后，被驱逐的 token 并没有"消失"——它们被压缩进了 SSM 的快权重里。但快权重只能存储信息，不能对信息做深度计算。就像你把一本书的内容全部压缩成一张图片，虽然信息都在，但你没法在图片上做逻辑推理。

这个发现比之前的研究更进了一步。以前大家认为长上下文的瓶颈是"记不住"，这篇论文证明真正的瓶颈是"算不动"。

睡眠机制：把计算从推理时转移到离线

论文的核心方案叫做 LLM Sleep——一种受神经科学启发的离线递归记忆整合机制。

工作机制很直觉：

  1. 清醒阶段（Wake Phase）：模型正常推理，注意力机制处理近期 token，KV Cache 不断增长。
  2. 睡眠阶段（Sleep Phase）：模型暂停接收新输入，对积累的上下文执行 N 次离线递归遍历（offline recurrent passes）。
  3. 整合阶段（Consolidation）：通过一个学习到的局部规则（learned local rule），将上下文中的关键信息写入 SSM 块的快权重。
  4. 清除阶段：整合完成后，清空 KV Cache，释放内存。
  5. 再次清醒：模型从"睡眠"中醒来，继续推理，但此时它拥有了一个经过深度处理的压缩记忆。

用人话说就是：模型工作一段时间后，“闭眼"把刚经历的内容反复咀嚼几遍，把重要的东西提炼成一种更紧凑的内部状态，然后把原始的"短期记忆”（KV Cache）清空。这和人类睡眠中的记忆整合过程惊人地相似。

论文中一个关键的技术细节是 N 的作用——睡眠时执行的递归遍历次数。N 越大，模型对上下文的"消化"越充分，推理能力越强。实验显示，在 GSM-Infinite 数学推理任务上，增加 N 能显著提升正确率，而且在需要更深推理的难题上提升最大。

这很符合直觉：简单的题目可能"浅层思考"就够了，但复杂的多步推理需要模型对上下文做更多轮的"反刍"。

实验验证：不只是概念

论文在三个任务上验证了这个方案：

  • 元胞自动机（Cellular Automata）：需要模型追踪多个时间步的演化规则。标准 Transformer 和 SSM-Attention 混合模型在长序列上表现退化，LLM Sleep 版本则能保持稳定。
  • 多跳图检索（Multi-hop Graph Retrieval）：需要在图结构中做多步跳转推理。被滑动窗口截断的模型在 3 跳以上几乎完全失败，而经过睡眠整合的模型表现显著更好。
  • GSM-Infinite 数学推理：一个需要长链条推理的数学任务。标准模型和纯 SSM 模型都失败了，但 LLM Sleep 模型随着 N 增加持续提升。

这些实验虽然在合成任务上进行，但结论指向一个重要的工程启示：把计算从推理时转移到离线阶段，可以同时解决长上下文的内存和推理问题。

互补视角：Sleep-time Compute

如果说 “Language Models Need Sleep” 解决的是"怎么让模型更好地利用长上下文"，那 Letta 团队的 “Sleep-time Compute” 解决的是另一个问题：怎么降低推理成本。

Letta 的思路更偏工程优化：在用户还没提问的时候，模型就提前"预习"上下文，预计算可能需要的中间结果。论文把这叫做 sleep-time compute——在"睡眠"期间提前做计算。

具体来说：

  1. 模型在空闲时分析已有的上下文（比如一份长文档）。
  2. 预测用户可能问的问题类型。
  3. 提前计算相关的中间表示和推理路径。
  4. 当用户真正提问时，直接利用预计算的结果，大幅减少推理时的计算量。

实验结果很亮眼：

  • 在 Stateful GSM-Symbolic 和 Stateful AIME 任务上，sleep-time compute 能把推理时的计算量降低 约 5 倍，同时保持相同的准确率。
  • 通过扩展 sleep-time compute（增加预计算量），准确率还能进一步提升 13%-18%。
  • 在多查询场景下（同一上下文的多个相关问题），平均成本可以降低 2.5 倍。

这篇论文还发现了一个有趣的规律：用户查询的可预测性与 sleep-time compute 的有效性高度相关。如果用户的问题很容易预测（比如对一份合同文档的常见查询），预计算的收益就很大；如果问题完全不可预测，收益就有限。

这其实也和人类的"睡眠"吻合——你白天学的东西越有结构、越可预测，晚上睡眠中的记忆整合就越有效。

从论文到工程：开源项目已经在行动

虽然这两篇论文都还停留在研究阶段，但"AI 需要睡眠"这个概念已经在开源社区引发了实际项目。

openclaw-auto-dream（562 Stars）是 OpenClaw 生态中的一个"睡眠技能"，给 AI Agent 提供了五层记忆架构、重要性评分、遗忘曲线和知识图谱。它的核心理念是"你的 AI 不只是记住，它会做梦"——通过离线的记忆整合，让 Agent 在每次对话后自动提炼和压缩经验。

mnemos（21 Stars）则更偏学术向，实现了多种仿生记忆机制：惊奇度门控（surprisal gating）、再巩固（reconsolidation）、情感路由（affective routing）和睡眠整合（sleep consolidation）。它以 MCP 服务的形式集成到 Claude Code 等编程 Agent 中，尝试用神经科学的原理来优化 Agent 的记忆管理。

Letta（22,975 Stars）本身就是最成熟的有状态 Agent 平台，他们的 sleep-time compute 研究直接来源于产品中的实际需求——如何让 Agent 在长对话中保持推理能力的同时控制成本。

这些项目虽然实现路径不同，但都在尝试解决同一个问题：LLM 的上下文窗口是有限资源，需要一个智能的管理机制来决定什么该记住、什么该遗忘、什么该提前计算。

对工程实践的启示

作为一个在生产环境中折腾过 AI Agent 系统的人，我认为这两篇论文有几点值得关注：

第一，长上下文不等于强推理。很多团队在部署 Agent 时盲目追求更长的上下文窗口（128K、1M），但论文的实验证明，光有容量不够，还需要足够的计算深度来处理信息。如果你的 Agent 需要多步推理，单纯扩大上下文窗口可能不是最优解。

第二，离线计算是一个被严重低估的优化维度。目前的 LLM 推理优化主要集中在量化、推测解码（speculative decoding）、KV Cache 压缩等"在线"技术上。sleep-time compute 提供了一个新思路：把一部分计算提前到空闲时完成。对于有固定上下文、重复查询的场景（比如客服、文档问答、代码审查），这个方案的 ROI 可能很高。

第三，记忆管理需要分层。就像 Stash 这样的开源记忆层 试图用多阶段管道来管理 Agent 记忆，“睡眠"机制本质上是在模型架构层面做分层记忆管理——短期记忆（KV Cache）负责精确回忆，长期记忆（快权重）负责压缩存储。这种分层思路和 AI 芯片领域的 memory wall 问题 其实是同一个问题的不同表现。

第四，Agent 架构需要重新思考。当前的 Multi-Stream LLM 论文提出了把 Agent 的不同"流"拆开并行处理，而 sleep 机制则提出了在时间维度上拆分——工作时和休息时用不同的计算策略。这两个方向如果结合，可能会催生一种全新的 Agent 运行时架构。

局限与展望

坦白说，这两篇论文目前都有一些明显的局限。

“Language Models Need Sleep” 的实验主要在合成任务上进行，还没有在真实的大规模语言模型上验证。从合成任务到真实场景的迁移，中间可能有很多工程挑战——比如，“学习到的局部规则"在不同任务间的泛化能力如何？睡眠阶段的计算开销如何精确控制？

“Sleep-time Compute” 更偏推理优化，它的效果高度依赖于查询的可预测性。在开放域对话或创意写作等不可预测的场景中，预计算的收益可能很有限。

但不管怎样，“LLM 需要睡觉"这个概念已经从一个有趣的隐喻变成了可验证的工程方案。随着 AI Agent 越来越多地承担长时任务（持续运行的编码 Agent、24/7 客服、自动化研究），上下文管理和推理优化的需求只会越来越迫切。

也许未来的 AI 系统真的会有一个"睡眠周期”——不是为了省电，而是为了更好地理解和记忆。

参考来源：