[AI Search] Language Models Need Sleep: 긴 컨텍스트를 잠자는 동안 압축하는 법

한 줄 요약

이 논문은 긴 컨텍스트를 계속 KV cache에 붙잡고 있는 대신, context를 버리기 직전에 모델이 잠깐 “잠들어서” 여러 번의 offline recurrent pass를 수행하고, 그 정보를 SSM fast weights에 통합한 뒤 cache를 비우는 방법을 제안한다.

AI Search 관점에서 보면 이건 검색 알고리즘 논문이라기보다, 검색된 context를 읽는 long-context reader / agent runtime의 메모리 운영 방식에 대한 논문이다.

retrieval / reranking
  ↓
context assembly
  ↓
reader model / agent runtime
  ↓
KV cache를 계속 들고 갈 것인가,
아니면 잠깐 쉬면서 fast weights에 통합할 것인가

앞선 QKV projection sharing 글이 KV cache를 “더 작게 저장하는 법”을 봤다면, 이번 논문은 한 단계 더 나아간다. 아예 오래된 context를 cache에서 evict하되, evict하기 전에 모델 내부 memory로 정리해서 넣을 수 있는가를 묻는다.

왜 이 논문이 AI Search에 중요한가

AI Search stack에서 흔히 병목은 “문서를 찾는 단계”라고 생각하기 쉽다. 하지만 실제 제품에서는 찾은 뒤가 더 비싸다.

• 검색 결과가 많아질수록 reader model의 context가 길어진다.
• multi-hop 질의는 문서 여러 개를 읽고 중간 정보를 연결해야 한다.
• agent는 tool result, 과거 대화, retrieved document를 계속 누적한다.
• 긴 세션을 그대로 KV cache로 유지하면 memory cost가 선형으로 커지고 attention compute도 부담이 된다.

그래서 long-context AI Search의 중요한 질문은 이것이다.

모델이 과거 context 전체를 계속 직접 볼 수 없어도, 나중에 필요한 reasoning을 할 수 있을까?

이 논문은 그 답을 sleep-like consolidation에서 찾는다. 사람의 수면 비유를 쓰지만 핵심은 꽤 시스템적이다. wake-time, 즉 실제 답변을 생성하는 순간에는 latency를 늘리지 않고, context eviction boundary에서 미리 추가 계산을 해 둔다.

기본 문제: attention cache는 좋지만 오래 들고 가기 어렵다

Transformer는 과거 token을 KV cache에 저장해 둔다. 이 방식은 강력하지만 긴 context에서는 비용이 커진다.

• attention compute는 context length에 대해 비싸진다.
• KV cache memory는 token 수에 따라 계속 증가한다.
• sliding window나 hard eviction을 쓰면 오래된 context를 더 이상 직접 attend할 수 없다.

최근 SSM이나 linear recurrent model은 고정 크기의 state, 또는 논문 표현으로는 fast weights를 유지한다. 이론적으로는 오래된 정보를 compact하게 담을 수 있다.

문제는 단순 저장이 아니다. 논문이 반복해서 강조하는 지점은 이거다.

fast weight capacity가 충분해도, 그 안에 정보를 “나중에 reasoning 가능한 형태”로 조직하지 못하면 실패한다.

검색으로 비유하면, 문서를 어딘가에 압축 저장하는 것만으로는 부족하다. 나중에 query가 들어왔을 때 multi-hop으로 연결하거나 distractor를 무시할 수 있게 구조화되어 있어야 한다.

핵심 아이디어: eviction 전에 잠깐 반복해서 정리한다

논문의 방법은 SSM-attention hybrid model을 전제로 한다. attention은 현재 window를 보고, SSM block은 fast weights를 업데이트한다.

일반적인 hybrid model은 context window를 한 번 처리하고, window가 끝나면 KV cache를 비운다. 이 논문은 그 경계에서 모델을 한 번 더 일하게 한다.

기존 hybrid:
  window 처리 1회
  → KV cache eviction
  → 다음 window
 
LLM Sleep:
  window 처리
  → sleep phase에서 같은 window를 N번 offline recurrent pass
  → SSM fast weights 반복 업데이트
  → KV cache eviction
  → 다음 window

여기서 N이 sleep duration이다. N=1이면 사실상 vanilla SSM-attention hybrid baseline에 가깝고, N을 늘리면 eviction 전에 더 오래 “정리”한다.

중요한 점은 답변 생성 시점에 loop를 돌리는 게 아니라는 것이다. 추가 compute는 consolidation phase에 지불한다. 논문 표현대로라면 wake-time prediction은 single forward pass로 유지된다.

이건 AI Search runtime에서 꽤 좋은 trade-off다.

실험 1: Rule 110 — 단순 retrieval이 아니라 순차 계산을 보는 테스트

첫 번째 controlled task는 Rule 110 cellular automaton이다. 모델은 길이 24의 binary state 여러 개를 읽고, 각 state를 t step만큼 rollout한 뒤 첫 bit를 맞춰야 한다.

여기서 t=0이면 거의 “첫 bit를 기억해라”에 가깝다. 하지만 t가 커질수록 단순 기억이 아니라 순차 계산이 필요하다. 논문은 t=32 같은 어려운 설정에서 hard eviction을 걸어, 모델이 과거 state를 attention으로 다시 볼 수 없게 만든다.

결과는 명확하다.

• non-looped hybrid model은 t=32에서 거의 random guessing 근처에 머문다.
• 약 5B training tokens 후에도 exact accuracy가 약 10% 수준이다.
• sleep loop를 2회로 늘리면 약 20%까지 올라간다.
• 3회와 4회 loop는 30%를 넘긴다.

이 실험의 포인트는 정확도 숫자 자체보다, context length와 prediction-time compute를 고정했는데 sleep-time compute만 늘리면 더 깊은 reasoning이 가능해진다는 것이다.

실험 2: Depo — multi-hop retrieval을 fast weights로 할 수 있는가

두 번째는 Depo라는 multi-hop knowledge retrieval task다. sequence에는 shuffled directed cycle이 들어 있고, query는 “어떤 node에서 k hop 뒤에 도착하는 node가 무엇인가”를 묻는다.

예를 들면 이런 구조다.

b → a, f → l, ... e → b
...
1 hop after a: ?
4 hops after e: ?

이 task가 AI Search와 더 가까운 이유는 두 가지다.

1. context는 여러 cache window에 조각난다.
2. query가 나중에 나오기 때문에, 모델은 특정 query에만 맞춘 저장이 아니라 query-agnostic representation을 만들어야 한다.

논문 설정에서는 cycle이 최대 75 nodes, 최대 300 tokens이고, query-answer 10쌍까지 포함해 총 sequence length는 360이다. window size는 75라서 cycle context는 네 개 cache window로 쪼개지고, 답변 시점에는 이미 KV cache에서 evict되어 있다.

결과적으로 N을 늘릴수록 어려운 hop에서 learning speed가 좋아진다.

이건 검색 시스템으로 치면 단순 lookup과 multi-hop reasoning의 차이다. 문서를 저장하는 것과, 저장된 조각을 나중에 연결해 답을 만드는 것은 다르다.

실험 3: GSM-Infinite — 긴 수학 문제에서 pre-trained LLM도 좋아지는가

논문은 synthetic task에서 끝내지 않고 GSM-Infinite로 간다. GSM-Infinite는 GSM8K 스타일의 synthetic math reasoning benchmark인데, 문제 길이를 distractor token으로 늘리고, 필요한 arithmetic operation 수로 난이도를 조절한다.

설정은 꽤 중요하다.

• evaluation set은 1,600 held-out examples다.
• 각 문제는 2,000~3,300 tokens다.
• 필요한 operation 수는 1~8 사이에서 sampling한다.
• Chain-of-Thought trace는 제거한다.
• question을 context 앞에 배치해, 모델이 읽는 동안 관련 정보를 선택적으로 consolidate할 수 있게 한다.
• context-window size는 L=2000이라 전체 문제를 active context에 다 담을 수 없다.

모델은 두 가지를 쓴다.

결과는 어려운 문제일수록 sleep loop의 이득이 커진다.

쉬운 2-operation, 4-operation 문제에서는 이미 accuracy가 saturation에 가까워지는 구간이 있다. 반대로 6-operation, 8-operation처럼 multi-step reasoning이 필요한 구간에서는 loop count 차이가 더 잘 드러난다.

이건 AI Search에서도 자연스럽다. 단일 fact lookup은 기존 retrieval과 reader로 충분할 수 있다. 하지만 여러 evidence를 연결해야 하는 query에서는, context를 “읽었다”보다 읽은 내용을 어떤 내부 상태로 정리했는가가 중요해진다.

Sliding-window eviction: hard eviction만 되는 아이디어는 아니다

논문은 hard eviction뿐 아니라 sliding-window eviction도 본다. sliding-window attention처럼 최근 L tokens는 유지하되, 오래된 token이 window 밖으로 밀려나기 전에 sleep consolidation을 수행한다.

GSM-Infinite에서 window size를 L=512로 줄이면 전체 sequence length는 window의 대략 4~6배가 된다. 이때 Ouro 1.4B에 대해 N ∈ {1, 2, 4}를 비교한다.

주요 결과는 꽤 강하다.

sliding-window 설정에서 sleep loop를 사용하면 accuracy가 0.596에서 0.905로 올라간다. 논문은 이를 52% improvement로 보고한다.

이 결과는 중요한 신호다. active attention window가 전체 sequence보다 훨씬 작을 때, sleep은 multi-step reasoning뿐 아니라 관련 context를 압축하고 다시 꺼내는 능력에도 도움을 준다.

AI Search agent를 떠올리면, 긴 tool trace나 retrieved chunks를 모두 context에 유지하지 않고도, 오래된 정보를 내부 memory로 넘기는 방향이다.

비용: wake-time latency는 유지하지만 training은 공짜가 아니다

이 논문의 trade-off는 솔직하다. prediction phase는 single-pass로 유지되지만, consolidation phase와 training은 비싸진다.

논문은 1개의 NVIDIA H200 GPU에서 sequence length 12,000으로 training throughput을 비교한다. 관찰은 두 가지다.

1. window size가 충분히 크면, context window 사이의 sequential dependency가 wall-clock throughput을 크게 망치지 않을 수 있다.
2. 하지만 recurrent depth, 즉 N을 늘리는 비용은 대체로 선형적으로 증가한다.

즉 이 방법은 “free lunch”가 아니다. 더 긴 sleep은 더 깊은 reasoning을 가능하게 하지만, 그만큼 training과 consolidation에 compute를 쓴다.

제품 관점에서는 이 질문으로 바뀐다.

답변 생성 시점의 latency를 줄이기 위해, context ingestion / consolidation 단계에서 compute를 먼저 쓸 가치가 있는가?

검색 서비스나 agent runtime에서는 충분히 말이 된다. 사용자가 문서를 업로드하거나 agent가 background로 자료를 읽는 단계에서는 latency budget이 상대적으로 넓고, 실제 질의 응답 시점에는 빠른 응답이 중요하기 때문이다.

AI Search Stack에서의 위치

이 논문은 AI Search stack에서 retrieval layer보다 아래, 또는 reader runtime 쪽에 위치한다.

Document / tool result / memory stream
  ↓
chunking, filtering, retrieval, reranking
  ↓
context assembly
  ↓
LLM Sleep 같은 consolidation
  ↓
fast-weight memory를 가진 reader / agent
  ↓
single-pass answer generation

특히 다음 시나리오에서 의미가 있다.

여기서 흥미로운 점은 기존 RAG 요약과 다르다는 것이다. 보통 우리는 오래된 context를 summary text로 압축한다. 하지만 summary는 사람이 읽을 수 있는 token sequence이고, 다시 prompt에 들어가야 한다.

LLM Sleep은 압축 결과가 text summary가 아니라 model의 fast weights다. 그래서 “무엇을 버리고 무엇을 남길지”를 learned local rule과 recurrent pass에 맡긴다.

실무적으로 생각해볼 점

첫째, long-context를 무조건 늘리는 방향만이 답은 아닐 수 있다. context window를 키우는 것은 단순하고 강력하지만, cost와 latency가 계속 커진다. 일정 시점 이후에는 context를 어떻게 consolidate할 것인가가 더 중요해진다.

둘째, query-time reasoning과 ingestion-time reasoning을 분리할 수 있다. 지금 RAG 시스템은 대체로 retrieval과 answer generation에 compute가 몰려 있다. 하지만 이 논문식 접근은 문서를 읽는 시점, tool result가 쌓이는 시점, cache eviction 직전에 reasoning compute를 미리 쓸 수 있다.

셋째, agent memory 설계와도 맞닿아 있다. 현재 많은 agent memory는 vector store나 text summary 중심이다. 하지만 장기적으로는 “text로 저장된 memory”와 “model state로 통합된 memory”가 함께 갈 가능성이 있다.

넷째, evaluation도 바뀌어야 한다. 단순 needle-in-a-haystack retrieval benchmark는 이런 방법의 강점을 잘 못 볼 수 있다. 논문이 Rule 110, Depo, GSM-Infinite를 쓴 이유도 정보량과 reasoning depth를 분리해서 보기 위해서다.

한계와 열린 질문

논문 자체도 한계를 명확히 둔다.

• controlled synthetic task 비중이 크다.
• GSM-Infinite도 현실 데이터라기보다는 procedurally generated benchmark다.
• 사용 모델은 Jet-Nemotron 2B, Ouro 1.4B 등 modest-scale pretrained model이다.
• N을 늘리면 training cost와 안정성 문제가 커진다.
• recurrent-depth training은 forward/backward가 깊어져 느리고 불안정해질 수 있다.
• 실제 production RAG나 web-scale search workload에서의 검증은 아직 아니다.

또 하나의 열린 질문은 learned fast-weight memory의 debuggability다. text summary는 사람이 읽고 고칠 수 있지만, fast weights에 무엇이 들어갔는지는 훨씬 보기 어렵다. enterprise search나 compliance-heavy domain에서는 이 부분이 채택 장벽이 될 수 있다.

제 해석

이 논문을 “LLM도 사람처럼 잠을 자야 한다”는 재미있는 비유로만 읽으면 조금 아깝다. 제 해석으로는 이 논문의 핵심은 long-context system에서 compute를 언제 쓸 것인가다.

기존 방식은 대체로 둘 중 하나였다.

1. 모든 context를 계속 들고 가며 query-time에 많이 계산한다.
2. 오래된 context를 text summary나 vector memory로 밖에 저장한다.

LLM Sleep은 중간 지점을 제안한다.

context가 사라지기 직전에 모델 내부에서 여러 번 되새김질하고, 나중에 single-pass로 쓸 수 있는 fast-weight memory로 바꾼다.

AI Search에서는 이 발상이 꽤 중요하다. 검색 품질이 좋아질수록 reader model이 읽어야 할 context는 오히려 늘어난다. agent가 길게 일할수록 tool trace도 늘어난다. 이걸 모두 prompt와 KV cache로만 해결하려 하면 언젠가 비용 벽에 부딪힌다.

그래서 앞으로의 AI Search stack은 단순히 “더 좋은 retriever + 더 긴 context model”이 아니라, 다음 세 층을 같이 봐야 할 것 같다.

1. 무엇을 가져올 것인가    retrieval / reranking
2. 무엇을 남길 것인가      filtering / summarization / memory
3. 어떻게 내부화할 것인가   sleep-like consolidation / fast weights

이 논문은 세 번째 층을 꽤 선명하게 보여준다.

정리

Language Models Need Sleep의 메시지는 간단하다.

• 긴 context를 계속 attention cache에 유지하는 것은 비싸다.
• SSM-attention hybrid의 fast weights는 오래된 context를 담을 수 있지만, 그냥 한 번 지나가는 것만으로는 깊은 reasoning에 부족하다.
• eviction 전에 여러 번의 offline recurrent pass를 수행하면, evicted context를 나중에 쓸 수 있는 형태로 더 잘 통합할 수 있다.
• Rule 110, Depo, GSM-Infinite에서 sleep duration N을 늘릴수록 어려운 sequential reasoning task에서 성능이 좋아진다.
• wake-time prediction은 single-pass로 유지되지만, training과 consolidation compute는 증가한다.

AI Search 관점에서는 “검색 결과를 얼마나 많이 넣을까” 다음의 질문을 던지는 논문이다.

가져온 context를 모델이 언제, 어떤 형태로 자기 memory에 정리해야 하는가?

이 질문은 long-context RAG, coding agent, enterprise search, personal memory agent 모두에서 점점 중요해질 것 같다.

참고

• Language Models Need Sleep — arXiv:2605.26099
• arXiv HTML version