노트북 GPU에서 100만 토큰 에이전트 작업공간을 돌리는 KVMem 공개

왜 지금 이 주제인가

오래 도는 에이전트는 실행 기록이 계속 쌓입니다. 기록이 GPU의 KV 캐시 용량과 모델의 기본 컨텍스트 창을 동시에 넘어서면 지금까지의 해법은 두 갈래였습니다. 오래된 부분을 요약으로 압축하거나, 나중에 텍스트로 다시 검색해 붙이는 방식입니다. 앞쪽은 세부 실행 증거를 잃고, 뒤쪽은 모델이 이미 처리한 내용을 다시 프리필합니다. 9월 4일 arXiv에 올라온 KVMem 논문은 이 문제를 기록 요약이 아니라 메모리 가상화 문제로 다시 정의합니다.

KV 상태를 세 계층에 걸쳐 페이징하는 구조

KVMem은 컨텍스트 창을 넘어간 작업 기록을 텍스트가 아니라 KV 상태 그대로 보존합니다. 이 상태를 페이지 단위로 쪼개 GPU 메모리, 호스트 RAM, NVMe 세 계층에 나눠 둡니다. 운영체제의 가상 메모리와 같은 발상이라 논문은 이를 KV 컨텍스트 가상화라고 부릅니다.

핵심은 어떤 과거 블록을 GPU로 다시 올릴지 고르는 색인입니다. KVMem은 Mean-K라는 방식을 씁니다. 레이어와 헤드별로 블록 안 토큰들의 위치 정보를 뺀 K 벡터 평균을 미리 계산해 두고, 현재 질의 벡터와의 스케일드 닷 프로덕트로 점수를 매겨 후보 블록을 고릅니다. 별도의 임베딩 모델이나 재학습 없이 모델 자신의 어텐션 공간을 색인으로 쓰는 셈입니다. 선택된 블록은 모델의 기본 컨텍스트 창 안에 들어가는 실행 뷰로 구성됩니다. 페이징 정책은 최근 검색 여부와 누적 검색 빈도를 함께 보고, 연속된 단계에서 겹치는 블록은 GPU 페이지를 그대로 재사용합니다.

비교 대상은 전체 기록을 다 넣는 Full Context, 최근 토큰만 쓰는 Sliding Window, 요약만 쓰는 Compact-only, 요약에 텍스트 검색을 더한 Compact+RAG였습니다. 활성 컨텍스트 32K의 LongMemEval-S에서 KVMem은 정답률 85.60퍼센트에 지연 0.48초로, Compact+RAG의 86.20퍼센트, 26.63초와 비슷한 정확도를 훨씬 짧은 지연으로 냈습니다. 기록이 256K를 넘는 MemoryAgentBench에서는 40.99퍼센트, 1.81초로 Compact+RAG의 34.80퍼센트, 106.02초를 앞섰고, 100만 토큰 규모의 AgentLongBench에서는 과제 성공률 50.00퍼센트, 0.73초로 42.00퍼센트, 416.38초와 비교됐습니다. Qwen3.8-27B로 돌린 DeepSWE 장문맥 시험에서는 Pass@1이 압축 방식 43.8퍼센트에서 48.4퍼센트로, Pass@4가 81.3퍼센트에서 93.8퍼센트로 올랐고 프리필 시간은 211.5초에서 95.0초로 줄었습니다.

로컬 실행 결과도 함께 실렸습니다. 24GB RTX 5090 Laptop GPU를 단 노트북에서 NVFP4로 양자화한 Qwen3.6/3.8-27B를 MTP와 함께 돌려, 기본 256K인 컨텍스트 창의 네 배에 해당하는 100만 토큰 작업공간을 다뤘습니다. 같은 환경에서 직접 다룰 수 있는 컨텍스트는 vLLM이 10K, llama.cpp가 80K였습니다. 단일 세션 생성 속도는 초당 약 50토큰입니다. 구현은 Apache 2.0으로 공개돼 있고, Linux x86-64와 Ampere 이후 NVIDIA GPU를 요구합니다.

의미와 한계

이 결과가 가리키는 것은 에이전트의 작업공간 크기를 모델의 컨텍스트 창에서 떼어낼 수 있다는 점입니다. 그동안 장기 에이전트의 기억은 요약과 검색의 문제로 다뤄졌고, 그래서 어디까지 압축할지가 품질을 좌우했습니다. KVMem은 같은 문제를 저장 계층 설계로 옮겨, 이미 계산해 둔 어텐션 상태를 버리지 않고 다시 불러 쓰는 쪽을 택했습니다. 노트북 한 대에서 100만 토큰 작업공간이 돌아간다는 것은, 개인 기기에서 며칠짜리 세션을 이어 가는 에이전트가 기술적으로 불가능하지는 않다는 뜻입니다.

다만 논문이 직접 밝힌 제약이 분명합니다. 각 단계에서 모델이 실제로 보는 것은 여전히 컨텍스트 창과 GPU KV 용량으로 제한된 실행 뷰입니다. 색인이 잘못 고르면 필요한 기록은 디스크에 남습니다. 저장해 둔 KV 상태를 다시 쓰는 것은 원문을 다시 계산하는 것과 수학적으로 같지 않습니다. KV 상태는 텍스트보다 훨씬 크기 때문에 저장 부담도 커집니다. 무엇보다 이 방식은 모델 내부에 접근해야 하므로 외부 API로 제공되는 모델 위에는 얹을 수 없고, 현재 구현은 여러 사용자를 동시에 서빙하지 못합니다. 오픈웨이트 모델을 직접 돌리는 환경에 한정된 기법이라고 보는 편이 정확하며, 다른 모델 계열로 얼마나 옮겨 가는지는 아직 확인되지 않았습니다.

한 줄 정리

컨텍스트 창을 넘어간 에이전트 기록을 요약하는 대신 KV 상태로 계층 저장해, 노트북에서도 100만 토큰 작업공간을 다루게 한 시스템입니다.