Real Long-Term Memory for AI: A 50-Million-Token Window That Is Faster and Cheaper Than Recompute 요약 설명
07 Oct 2026 | Paper Review KV Cache LLM Serving Long-Context Language Models목차
이번 글에서는 Real Long-Term Memory for AI: A 50-Million-Token Window That Is Faster and Cheaper Than Recompute 논문의 핵심 포인트만 간단히 정리한다.
- 2026년 10월 7일(Arxiv)
- Schelpe, Sietse.
- Corbenic AI
- 논문 링크
- Project Page
요약
- 언어 모델 서빙에서는 이미 처리한 텍스트를 다시 계산할 수 있으며, 요청에서 attention에 사용할 수 있는 토큰 범위인 컨텍스트 윈도 밖의 자료에는 직접 접근하지 못한다. galahad-kv는 NVIDIA H100 1개에서 시험한 모델 2개 각각에 대해 50,000,000토큰 저장소에서 조회한 블록 100개를 모두 복원했다. 요청 구성이 같고 이전에 처리한 적 없는 16k-token 블록을 처음부터 처리하는 경우보다 각각 2.8×, 4.25× 빨랐다고 보고한다.
- 이 시스템은 처리한 토큰에서 계산한 attention 상태인 key-value(KV) 상태를 암호화하여 로컬 NVMe 저장장치에 저장한다. 이 로컬 디스크 계층은 GPU 메모리 밖에 블록을 보관한다. 한 번에 블록 1개만 GPU 메모리에 상주하므로, 과거 블록을 복원해도 50 million 토큰 전체에 동시에 attention을 적용하지는 않는다. 의미에 따라 구절을 선택하는 학습 기반 검색도 제공하지 않는다.
- Gemma 4 12B와 Gemma 4 31B는 삽입한 코드를 묻는 질문에 각각 82/100, 98/100의 정답률을 기록했으며, 어느 모델도 복원한 블록에 없는 코드를 반환하지 않았다. 재계산 대비 GPU 에너지 감소 배율은 각각 8.8×, 12.3×로 보고되었지만, 저장소에는 각각 1.86 TB, 6.25 TB가 필요했다. 복원 후와 재계산 후 모델의 출력 점수가 바이트 단위로 일치한다는 logit 동등성은 이번 실험에서 다시 검증하지 않고 연관 연구의 결과로 제시한다.
1 Introduction
서론은 설정된 16k-token 컨텍스트 윈도 밖의 토큰에 접근하지 못하는 문제와 이미 계산한 KV 상태를 다시 만드는 문제, 2가지를 지적한다. 제안 방식은 각 블록을 1회 처리한 뒤 그 상태를 디스크에 보관하고 요청 시 복원한다. 논문의 주장은 일정한 GPU 메모리를 사용하면서 과거 어느 위치의 블록이든 영속적으로 보관하고 재사용하는 데 한정된다. 단일 패스의 attention 범위는 여전히 활성 윈도로 제한된다.
2 Background and related work
논문은 시스템을 공통 프롬프트 시작 부분의 상태를 재사용하는 prefix caching, 해당 상태를 GPU 메모리 밖으로 옮기는 KV offloading과 비교한다. Retrieval-augmented generation(RAG)은 텍스트를 검색한 뒤 컨텍스트 윈도 안에서 다시 처리한다. Cache-augmented generation은 윈도 안에 들어가는 고정된 문서 집합의 상태를 미리 계산한다. MemGPT 같은 에이전트 메모리 시스템은 윈도에 넣을 텍스트를 선택한다.
- Gemma 4는 대부분의 계층에서 attention 범위를 주변 약 1,024토큰으로 제한하는 sliding-window attention을 사용하여 저장할 상태의 크기를 줄인다. 메모리 계층은 모델이 이미 가진 이 특성을 활용한다.
- 이전 보고에서는 97k토큰의 통합 메모리 계층, 모델을 고정한 6M-token 메모리, 검증된 지식의 재사용을 다뤘다. 이번 실험은 코퍼스를 50M토큰으로 늘리고, vLLM 서빙 엔진을 사용하며, 저장 상태를 암호화하고, 부정행위 방지 프로토콜을 추가한다. 학습 기반 문서 검색 구성요소인 Blaise는 제외한다.
3 System under test
시험한 엔진은 galahad-kv==1.31.4이며, libgalahad.so로 구현되어 vLLM 0.31.0에서 GalahadConnector KV-transfer 플러그인을 통해 불러온다. 계산한 상태를 저장하는 deposit 단계에서는 조직별 키로 인증 암호화 방식인 AES-256-GCM을 적용하여 각 블록을 MRLNCRY1 저장 형식으로 기록한 뒤 상주하던 상태를 해제한다. 복원 단계에서는 저장된 상태를 실행 중인 모델에 삽입하여 블록의 토큰을 다시 처리하지 않고 계산을 이어간다. 평가 대상은 이 KV 재사용 모드뿐이다.
4 Anti-cheat protocol
부정행위 방지 프로토콜은 실행 시 원문에 담긴 사실의 변경, 질문 없는 데이터 입력, 삽입 레코드, 같은 형식의 미끼 레코드, 물리적 저장소 감사를 결합한다. 이름, 날짜, 금액, 이메일 주소를 무작위 값으로 바꾸어 사전학습 지식이나 정적 캐싱으로 답하는 일을 방지하려 한다. 50M토큰을 모두 저장할 때까지 질문을 공개하지 않아, 데이터 입력 중 평가 질문에 미리 접근하는 query lookahead를 방지한다.
- needle은 이름과 4자리 코드를 담아 삽입한 레코드이며, decoy는 다른 코드를 담은 유사한 레코드다. Section 4는 블록당 needle 1개를 명시하지만, Section 5는 500k토큰마다 1개씩 총 100개를 명시하여 정확한 분포가 불분명하다.
- 엔진 지표는 cached_tokens ≈ block size를 기준으로 재계산이 0인 복원을 확인한다. 별도의 모델 지표는 출력 코드가 정답표와 정확히 일치하는지 확인하며, 정답표는 엔진에 제공하지 않는다.
- 저장소 감사는 MRLNCRY1 헤더와 예상 바이트 크기를 확인한다. 에너지는 GPU 하드웨어 카운터 인터페이스인 NVIDIA Management Library(NVML)에서 측정하고 유휴 소비량을 뺀다. 음성 대조군에서는 존재하지 않는 레코드를 질문하고 응답 거부를 기대한다.
5 Experimental setup
실험에는 로컬 NVMe를 연결한 NVIDIA H100 80 GB 1개를 사용하며, 생성 설정은 전체 실험에서 temperature 0으로 유지한다. Gemma 4 12B는 16비트 부동소수점 형식인 bf16을, Gemma 4 31B는 8비트 부동소수점 형식인 FP8을 사용한다. 각 모델은 텍스트를 모델 토큰으로 변환하는 자체 토크나이저를 사용하여 vLLM에서 실행한다. 소프트웨어에는 galahad-kv==1.31.4, vLLM 0.31.0, transformers, datasets, nvidia-ml-py가 포함된다.
- 코퍼스는 50,000,000토큰 = 3,125블록 × 16,000토큰으로 구성한다. WildChat이 40%, 허용적 라이선스가 적용된 소스 코드가 25%, arXiv 논문이 20%, 교육용 웹 텍스트가 15%를 차지한다. 이후 실행 시 원문을 변경하고, needle 레코드 100개와 같은 형식의 decoy를 삽입한다.
- 논문은 메모리가 ≥24 GB인 NVIDIA GPU 1개에서 실행할 수 있다고 설명하지만, 보고된 성능 측정에는 H100 80 GB 구성을 사용한다.
5.1 KV footprint
12B 모델의 상태 크기는 36.4 KiB/token으로 보고하며, full attention의 약 160 KiB/token과 비교한다. 이에 따른 저장소 크기는 약 8 TB 대신 1.86 TB라고 보고한다. 31B FP8 모델의 보고 수치는 134 KiB/token과 6.25 TB다. 저자는 각 저장소의 블록 3,125개를 모두 감사하여 예상한 헤더를 확인했으며, 누락되거나 제거된 블록은 없었다고 보고한다. 다만 31B 저장소 계산에 사용한 단위 기준은 불분명하다.
6 Results
결과에서는 상태 복원 성공과 복원한 내용의 읽기 성공을 구분한다. 복원율과 답변 정확도, 복원과 재계산의 지연 시간 및 GPU 에너지, 최초 deposit의 처리량, GPU 메모리 사용량, 디스크 사용량을 보고한다.
6.1 Byte-exact restore at every depth
0토큰부터 49,488,000토큰 사이의 깊이 100곳을 조회한 결과, 모델 2개 모두 재계산 없이 100/100 블록을 복원했다. 정확한 코드 재현율은 Gemma 4 12B에서 82/100, Gemma 4 31B에서 98/100이었다. 어느 모델도 복원한 블록에 없는 코드를 출력하지 않았으며, 모델 2개 모두 존재하지 않는 레코드를 묻는 음성 대조군 20개 전체에서 응답을 거부했다.
- 논문은 여기서 환각을 복원한 블록에 없는 코드를 출력하는 경우로 정의한다. 블록 안의 decoy나 다른 숫자를 고른 오답도 코드 재현 실패로 집계한다.
- 이 하위 절의 제목과 달리, 이번 실험은 logit의 바이트 단위 일치를 다시 검증하지 않는다. 해당 정확성 주장은 연관 연구인 Taliesin에 근거하며, 여기서 직접 측정하는 엔진 지표는 재계산이 0인 복원이다. Taliesin에 대해서는 Smarter and Cheaper at Once: Byte-Exact KV-Cache Grafting Turns a Frozen Small Model into a Verified-Knowledge Flywheel 요약 설명 글을 참조하라.
6.2 Restore is faster and cheaper than recompute
베이스라인은 요청 구성이 같고 이전에 처리한 적 없는 16k-token 블록에 대해 프롬프트 토큰을 처음 처리하는 전체 prefill을 수행한다. 복원과 재계산의 중앙값은 12B에서 각각 0.266 s / 59 J와 0.760 s / 521 J이며, 31B에서 각각 0.347 s / 80 J와 1.475 s / 976 J다. 표에 보고된 속도 향상은 2.8×, 4.25×이며, 에너지 감소 배율은 8.8×, 12.3×다.
- 첫 출력 토큰이 나올 때까지의 지연인 time to first token(TTFT)의 복원 시 90th-percentile 값은 12B에서 0.284 s, 31B에서 0.579 s다.
- 깊이의 low-third 구간에서 high-third 구간으로 갈 때 TTFT는 12B에서 0.193에서 0.274 s로, 31B에서 0.343에서 0.375 s로 변한다. 먼 과거에서도 복원은 빠르지만 수치에는 변화가 있으며, 논문은 차이의 불확실성 추정치를 제공하지 않는다.
- 시험한 모델 중 큰 모델에서 상대적 절감 폭이 더 크다. 서로 다른 수치 정밀도를 사용한 모델 크기 2개만으로는 모델 크기와 재사용 절감 효과 사이의 일반적 관계를 뒷받침하는 근거가 제한적이다.
6.3 Deposit (the one-time cost)
50,000,000토큰을 저장할 때 처리량은 Gemma 4 12B에서 20,839 tok/s, Gemma 4 31B에서 10,700 tok/s다. GPU의 상주 메모리인 video RAM(VRAM)의 보고된 최대 사용량은 각각 70,864 MB, 75,111 MB로 일정하게 유지되며, 해당 암호화 저장소는 각각 1.86 TB, 6.25 TB를 차지한다.
- 논문은 상주 메모리를 O(1) 이동 윈도로 설명한다. 이는 저장한 이력이 늘어나도 크기가 일정하다는 뜻이다. deposit 비용은 1회 발생하며, 보고된 지연 시간과 에너지 비율은 이후 재사용에 적용된다.
6.4 What the numbers say
저자는 동일한 100/100 복원율과 서로 다른 코드 재현 점수를 저장 신뢰성과 복원한 내용을 읽는 모델 능력이 구분된다는 근거로 해석한다. 보고된 코드 재현 실패는 모두 블록에 실제로 있던 decoy나 다른 숫자를 선택한 경우다. 저렴한 모델로 서빙하다가 더 강한 모델로 전환하는 활용 방안을 제안하지만, 실험에서는 전환 정책을 평가하거나 모델 1개의 KV 상태를 다른 모델로 이전할 수 있음을 입증하지 않는다.
7 Why this is long-term memory and not a cache
논문은 재시작 이후에도 유지되는 영속성, 저장 시 암호화, 바이트 단위의 정확한 복원, 활성 컨텍스트 윈도 밖 자료의 재사용이라는 4가지 속성을 근거로 장기 기억이라는 용어를 사용한다. 모델 가중치는 바뀌지 않으며, 상태를 복원하면 이전에 처리한 사실을 요청에서 사용할 수 있다. 이 속성들은 저자의 용어 선택을 설명하며, 이번 실험은 블록 복원, 코드 재현, 자원 사용량을 직접 측정한다.
8 Limitations and scope
블록 1개만 상주하므로 시스템이 50M토큰 전체에 동시에 attention을 적용하지는 않는다. 학습 기반 구절 선택은 범위 밖이며, 이 규모에서 구절 선택과 복원을 결합하는 작업은 향후 과제로 남는다. 따라서 결과는 자동으로 검색한 50M-token 이력에 대한 종단 간 질의응답 성능을 입증하지 않는다.
- 복원에는 약 0.3 s가 걸려 NVML 에너지 카운터의 시간 해상도에 가까워진다. 저자는 상대적 에너지 비율은 신뢰할 수 있다고 보지만, 조회별 절대 에너지 측정값인 줄 단위 수치에는 더 큰 불확실성이 있음을 인정한다.
- 시험한 모델의 저장소에는 1.86 TB와 6.25 TB가 필요하다. 보고된 지연 시간과 에너지 수치는 로컬 NVMe를 전제로 하며 네트워크 볼륨에는 적용되지 않는다.
9 Reproducibility (single GPU, public software)
재현 지침은 pip install galahad-kv==1.31.4 vllm==0.31.0 datasets transformers nvidia-ml-py 실행, Gemma 4 모델 확보, GPU 호스트에서 무료 Galahad 라이선스 취득을 명시한다. 서빙에는 GalahadConnector를 사용하며 kv_role을 kv_both로 설정하고 –max-model-len 16640과 –enable-prompt-tokens-details를 사용한다.
- 평가 스크립트로 구성된 4단계 하네스는 변경된 코퍼스를 만들고, 질문에 접근하지 않은 채 저장하고, 저장소를 감사한 뒤 복원과 코드 재현을 평가한다. 논문은 이를 transformers, datasets, urllib을 사용하는 공개 HTTP 클라이언트로 설명하며, 원시 산출물과 파일 무결성 체크섬 목록인 SHA-256 매니페스트가 보고된 측정을 뒷받침한다고 밝힌다.
부록
- A Harness는 코퍼스 구성, 변경, needle, decoy, 정답표를 위한 build_hardened.py, 질문 없는 데이터 입력과 NVML 메모리 및 에너지 측정을 위한 deposit_blind.py, MRLNCRY1과 저장 크기 확인을 위한 audit_storage.py, 지표 2개와 재계산 베이스라인, 음성 대조군, 실패 분류를 위한 probe_watertight.py를 나열한다.
- B Data and manifest는 RESULT_12b_probe.json, RESULT_31b_probe.json, deposit 로그, 정답표, SHA256SUMS_31b.txt를 명시한다. 로컬 NVMe 저장소마다 MRLNCRY1 블록 3,125개가 들어 있으며, 크기는 12B에서 1.86 TB, 31B에서 6.25 TB라는 점을 다시 설명한다. 이 부록은 산출물 이름을 제시하지만 다운로드 URL은 제공하지 않는다.
짧은 생각
가장 강한 근거는 엔진 복원과 모델의 코드 재현을 구분한 평가이며, 모델당 조회 100회와 존재하지 않는 레코드에 대한 대조군이 이를 뒷받침한다. 입증된 이점은 선택한 과거 블록을 더 저렴하게 재사용한다는 점이다. 자동 검색, 전체 이력에 걸친 동시 추론, 출력의 바이트 단위 동등성은 이 실험이 직접 뒷받침하는 범위 밖이다. 재현을 위해서는 서로 충돌하는 needle 배치 설명과 50,000,000토큰에 134 KiB/token을 적용한 값이 보고된 저장소 크기 6.25 TB로 환산되는 과정을 명확히 해야 한다. 복원 지연 시간이 일정하다는 주장은 보고된 깊이의 하위 구간과 상위 구간의 TTFT 값과 함께 평가해야 한다. 불확실성 추정치가 있으면 차이가 유의미한지 판단하는 데 도움이 된다. 시험한 모델들은 정밀도가 다르며 같은 모델 계열에 속한다. 모델에 독립적이라는 주장이나 모델 크기에 따라 절감 효과가 커진다는 더 넓은 주장을 평가하려면 추가 구성이 필요하다.