AI也要007?Letta、伯克利提出「睡眠時間計算」,推理效率翻倍還不加錢

機器之心報導

編輯:+0、陳陳

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 中,我們看到隨著問題從上下文中變得更加可預測,睡眠時間計算和標準測試時間計算之間的準確度差距不斷擴大,這證實了本文的假設,即當問題能夠通過上下文預測時,睡眠時計算最能發揮其優勢。

瞭解更多內容,請參考原論文。