5천만 토큰을 한 번에 읽는 대신, 저장한 KV 상태를 다시 불러오는 실험

배경과 문제

언어 모델이 한 번에 직접 참고할 수 있는 텍스트에는 길이 제한이 있다. 이 실험의 활성 블록은 약 16,000토큰이다. 이전 문서를 다시 처리할 때, 그 문서의 KV 상태를 재사용하지 못하면 프리필이라는 계산 단계를 다시 수행해야 한다. 이미 기존 서빙 시스템에도 KV 캐시와 공유 프리픽스 재사용이 있으므로 모든 요청이 반드시 처음부터 재계산된다는 뜻은 아니다. 이 연구가 비교한 기준선은 저장 상태를 복원하지 않는 새 16k 블록의 프리필이다.

이 논문은 모델이 각 블록에 대해 계산한 KV 상태를 디스크에 보관하고 필요할 때 복원하는 방식으로 이미 선택한 블록을 다시 처리할 때의 재계산 부담을 줄이려 한다. 저자는 이를 '장기 기억'이라고 부르며 '캐시'라는 용어를 피한다. 저장된 상태가 내구성 있고 암호화되며 바이트 단위로 정확하고, 창 밖에 있는 자료까지 포함하기 때문이다. 이 접근은 단일 패스 주의를 넓히지 않고, 학습된 검색도 하지 않는다. 한 번에 한 블록만 GPU 메모리에 상주하고, 더 깊은 내용은 요청 시 디스크에서 복원된다.

기존 접근의 한계

논문은 실행 중 KV 캐시와 프리픽스 재사용, CPU·디스크로 상태를 옮기는 LMCache·CacheBlend 등의 기존 연구를 소개한다. 저자는 자신의 방식에서 오래 보관하는 암호화 저장과 복원을 강조한다. 다만 다른 제품의 현재 모든 기능을 직접 검증하거나 동일 조건으로 성능을 비교한 실험은 없다. 따라서 기존 제품은 모두 평문만 저장한다거나 특정 아키텍처에 종속된다고 일반화하지 않는다.

RAG는 필요한 원문을 찾아 모델 입력에 넣는 방식이고, 이 실험은 미리 계산한 KV 상태를 복원하는 방식이다. 실제 RAG나 문서 캐시도 여러 재사용 전략과 결합될 수 있다. Galahad가 이 실험에서 보여주려는 것은 선택한 블록의 재계산을 줄이는 효과다. 어떤 블록을 선택할지 학습하는 검색은 제외했으므로, 검색 문제나 컨텍스트 길이 제한을 모두 해결한 것으로 읽으면 안 된다.

연구방법을 단계별로

실험은 공개 PyPI 패키지 galahad-kv==1.31.4(libgalahad.so)를 vLLM 0.31.0에 GalahadConnector KV-transfer 플러그인으로 로드해 수행했다. 커넥터는 두 가지 작업을 한다. 'deposit'에서는 요청의 블록별 KV를 암호화된 온디스크 저장소(MRLNCRY1 형식, AES-256-GCM, 조직별 키 하나)에 기록한 뒤 해제한다. 이로써 한 블록만 상주하고 나머지는 디스크에 있는 이동 창이 만들어져 VRAM이 평평하게 유지된다. 'restore'에서는 이후 요청에서 저장된 블록의 KV를 다시 이식하고, 순전파가 마치 모델이 방금 그 블록을 계산한 것처럼 계속된다. 블록의 토큰은 재계산되지 않는다.

하드웨어는 NVIDIA H100 80GB 한 장과 로컬 NVMe를 사용했다. 모델은 Gemma 4 12B(bf16)와 Gemma 4 31B(FP8)를 각각 vLLM으로 서빙했고, 각자 자신의 Gemma 4 토크나이저를 사용했다. 말뭉치는 5천만 토큰으로, 3,125개 블록 × 16,000토큰이며, WildChat(40%), 허용 라이선스 소스 코드(25%), arXiv 논문(20%), 교육용 웹 텍스트(15%)에서 스트리밍했다. 스트림은 변형기를 거쳐 이름, 날짜, 금액, 이메일이 무작위 논스로 바뀌었고, 100개의 니들 레코드(500k 토큰마다 하나)와 같은 형식의 디코이 레코드가 심어졌다.

저자는 평가가 손쉽게 부풀려지는 것을 줄이려 다섯 장치를 제시한다. 이름·날짜·금액 등을 실행 시 무작위 값으로 바꾸고, 질문 없이 전체 자료를 먼저 저장하며, 정답 코드와 혼동용 레코드를 넣는다. 또 디스크 헤더와 용량을 점검해 실제 저장을 확인한다. 이는 저자가 제안한 통제 절차이지 모든 데이터 누출·지름길·측정 조작을 완전히 막았다는 독립 증명은 아니다. 니들 배치는 §4의 블록당 하나와 §5의 100개라는 서술이 서로 맞지 않아 실제 배치의 상세 확인이 필요하다.

결과와 숫자의 의미

전체 저장소는 3,125개 블록이며, 그중 0~49,488,000토큰 깊이에 놓인 100개를 탐침했다. 두 모델 모두 cached_tokens로 확인한 무재계산 복원은 100/100이었다. 정확한 코드를 답한 횟수는 각각 82/100과 98/100이다. 오답 18개와 2개는 블록 안의 다른 코드나 숫자를 선택한 경우였다. 저자가 말하는 환각 0은 블록에 없는 코드를 만든 사례가 없다는 좁은 정의다. 별도로 존재하지 않는 레코드를 물은 부정 대조 질문은 모델마다 20개이며, 보고된 조작 답변은 0/20이다. 두 모델만으로 모든 모델의 호환성을 증명하지 않으며, byte-exact·로짓 동등성은 이번 실험에서 다시 검증하지 않았다고 본문이 명시한다.

중앙값 기준 복원은 12B에서 0.266초·59J, 31B에서 0.347초·80J였다. 같은 요청 형태로 새 16k 블록을 프리필한 기준선은 각각 0.760초·521J, 1.475초·976J였다. 저자가 보고한 속도 비율은 약 2.8배와 4.25배, GPU 에너지 비율은 약 8.8배와 12.3배다. 낮은 깊이 구간과 높은 구간의 TTFT는 12B에서 0.193→0.274초, 31B에서 0.343→0.375초로 달라 정확히 같은 지연이라고 말할 수 없다. 이 표에는 그 차이의 오차막대나 유의성 검증이 없다. 약 0.3초의 측정은 NVML 해상도에 가까워 절대 에너지 값의 불확실성도 있다. GPU 유휴 전력을 뺀 측정이며 SSD·CPU 전력이나 전체 서비스 요금은 포함하지 않는다.

저장은 1회 전처리 비용이며 재사용 절감과 분리된다. 12B는 5천만 토큰을 20,839 tok/s로 처리해 1.86TB(토큰당 36.4KiB)를 저장했고, 31B는 10,700 tok/s로 6.25TB(토큰당 134KiB)를 저장했다. 피크 VRAM은 각각 70,864MB와 75,111MB로 5천만 토큰 스트림 전체에서 평평했다. 이는 O(1) 이동 창에 해당한다. 134KiB × 5천만은 약 6.86TB(6.24TiB)이므로 31B의 TB/TiB 표기에 불명확함이 있다. 시험한 설정의 중앙값에서 복원 시간은 재계산보다 약 2.8~4.3배 짧고 GPU 에너지는 약 8.8~12.3배 적었다.

구체적인 예시

설명을 위한 가상 예시로, 한 조직이 문서를 모델별 KV 블록으로 저장해 두고 나중에 특정 계약서의 코드를 확인한다고 하자. 별도 검색이나 문서 식별 과정이 필요한 블록을 이미 골라주었다면, 그 블록의 KV를 다시 불러와 계산을 줄일 수 있다. 블록을 어떻게 찾는지는 이 논문이 평가하지 않은 별도 단계다. 몇 달 뒤의 실제 운영이나 여러 계약서를 함께 추론하는 성능을 측정한 사례도 아니다.

실제 시험은 정답 코드와 같은 형식의 혼동용 레코드를 넣고, 자료를 모두 저장한 후 질문을 보냈다. 저자는 사전학습 지식이나 단순한 일치 규칙에 기대는 답변을 줄이려는 설계라고 설명한다. 보고된 결과에서는 12B가 82개, 31B가 98개 코드를 정확히 답했다. 같은 블록 안의 다른 숫자를 고른 오답도 있었으므로 저장 복원의 성공과 독해의 성공은 구분된다. 프로토콜의 의도만으로 키워드 기반 지름길이 모두 제거됐다고 단정할 수는 없다.

한계와 오해하기 쉬운 점

이 시스템은 5천만 토큰을 동시에 어텐션하는 창이 아니다. 16,000토큰 블록 3,125개를 로컬 NVMe에 저장하고 한 번에 한 블록의 모델별 KV를 복원한다. 블록을 의미로 선택하는 검색과 여러 블록을 합친 추론은 평가 범위 밖이며, 탐침에서는 확인할 블록 위치를 알고 있다. 처리한 전체 자료량, GPU 메모리에 현재 보유한 양, 실제 복원·질문한 양은 서로 다르다.

하드웨어는 H100 80GB 한 장이며, Gemma 4 12B bf16과 31B FP8을 각자 tokenizer/KV로 평가했다. 한 모델에서 만든 KV를 다른 모델에 그대로 사용 가능하다고 일반화해서는 안 된다. 모델 가중치 학습이나 성능 자체 향상을 측정한 것이 아니다. 두 모델의 100/100은 0~49,488,000토큰 깊이의 100개 탐침에서 cached_tokens로 확인한 무재계산 복원이다. 텍스트의 정확한 코드 답은 12B 82/100, 31B 98/100으로 오답이 각각 18개, 2개 있다. 환각 0은 블록에 없는 코드를 만든 경우가 0이라는 좁은 정의이며 모든 오답이 없다는 뜻이 아니다.

§6.1은 이식된 KV의 바이트 단위 로짓 동등성을 이 논문에서 재검증하지 않았고 동반 Taliesin 연구에 맡겼다고 명시한다. 따라서 본 실험만으로 모든 내부 상태/출력이 완전히 동일함을 증명했다고 쓰면 안 된다. 저장은 1회 전처리 비용이며 재사용 절감에서 분리된다. 네트워크 디스크로 확장하면 보고된 지연/에너지 수치는 적용되지 않는다. 원문 §4는 블록마다 needle 1개라고 쓰지만 §5는 100개/500k 토큰마다 1개로 설명해 배치 수가 불일치한다. 이를 임의로 해결하지 말아야 하며, §6 결과의 실제 평가 분모는 100개다. 암호화 AES-256-GCM은 저장 방식을 뜻하며 개인정보 보호·키 관리·전체 시스템 안전성에 대한 독립 보증이 아니다.

실제로 어떻게 활용할까

이 접근은 필요한 블록을 이미 식별할 수 있고 같은 내용을 반복 참조하는 업무에서 검토할 수 있다. 계약서나 소스 코드 같은 자료를 대상으로 자체 비교를 한다면, 검색이 올바른 블록을 찾는지, 모델이 답을 정확히 읽는지, 복원이 재계산보다 유리한지를 따로 측정해야 한다. 보고된 이득은 로컬 NVMe와 특정 H100·두 모델의 재사용 조건이다. 최초 저장 비용과 TB 단위 디스크 용량을 포함한 전체 비용, 네트워크 저장소의 지연은 별도 확인이 필요하다.

논문은 단일 GPU 재현 절차와 네 단계 하네스를 공개했다고 서술한다. 그러나 원문 확보 시 확인한 공식 GitHub tree에서는 README·이미지·index.html만 보였고, 부록에 열거된 하네스·RESULT JSON·SHA256 파일은 찾지 못했다. PyPI의 라이선스 표기도 Proprietary이므로 공개 다운로드와 오픈소스는 구별해야 한다. 기존 패키지는 10월 1일, 별도의 50M 기능 실험은 10월 4일 README에도 공개돼 있으며 10월 7일은 이번 H100·vLLM 실험 보고의 게시일이다. 구현의 독립 검증이나 재현 자료 확보 없이 논문의 숫자를 운영 보장으로 받아들이기는 어렵다.