GPU 두 장에서 긴 문맥 8개를 처리하기 위한 SparseKV 실험
호스트 RAM에 KV 캐시를 두고 필요한 토큰만 가져오는 실험의 측정 조건과 정확도 제약을 살펴본다.

긴 코드를 읽는 로컬 에이전트를 여러 개 띄우면 모델 가중치뿐 아니라 대화의 KV 캐시도 GPU 메모리를 차지한다. sparsekv-hyperqwen은 이 캐시를 호스트 RAM에 두고 매 생성 단계에서 일부만 가져오는 실험이다. 저장소는 2026년 11월 2일 생성됐다. 이 날짜는 저장소 생성 시각이며 별도의 발표일은 확인되지 않았다.
제작자는 RTX 3090 Ti와 RTX 3090을 쓴 한 대의 PC에서 에이전트 8개를 동시에 실행했다고 설명한다. 각 에이전트의 문맥은 약 250K 토큰이었다. 이는 특정 모델과 설정에서 측정한 결과다. 독립적으로 재현하거나 다른 작업에서 같은 속도를 확인한 것은 아니다.
캐시를 골라 읽는 방식
구현은 HyperQwen의 vLLM 0.31 기반 포크와 Qwen3.8-27B W4A16 모델에 맞춘 패치다. 전체 KV 캐시는 int4 형태로 호스트 RAM에 보관한다. GPU에는 검색용 축약 정보와 최근 토큰, 자주 쓰는 일부 캐시를 둔다.
생성 단계에서는 각 full-attention 계층이 rank-64 축약 정보를 사용해 토큰을 고른다. README에 따르면 선택한 상위 2,048개와 초기 64개, 최근 1,024개 토큰을 attention에 사용한다. 필요한 행이 GPU에 없으면 PCIe를 통해 호스트 메모리에서 읽는다. 초기 프롬프트 처리와 MTP 초안 모델은 이 희소 디코딩 경로를 사용하지 않는다.
숫자를 읽을 때 필요한 조건
제작자가 공개한 결과에서 8개 세션의 합산 생성 속도는 설명형 출력에서 약 545토큰/초, 복사 위주 출력에서 약 790토큰/초였다. 문서는 약 244K 토큰의 vLLM 소스 덤프였고 응답은 1,024토큰, temperature는 0이었다. 두 GPU는 각각 250W로 제한했다. 제작자는 실험 소개글에서 모든 수치를 GPU 커널 모듈 gpu-unlock을 불러온 상태에서 측정했다고 밝혔다. 두 값은 세션 하나의 속도가 아니라 전체 합계다.
후속 질문의 첫 토큰까지 걸린 시간은 5.2~5.9초로 보고됐다. 반면 244K 문서 하나를 처음 처리하는 데는 390초가 걸렸고 초기 처리는 한 번에 하나씩 진행됐다. 따라서 후속 질문의 지연만 보고 첫 요청도 빠르다고 판단하면 안 된다.
정확도와 운영상의 제약
이 방식의 attention은 근사치다. 제작자의 검색 테스트는 32개 중 31개를 맞혔으며 비슷한 코드 줄을 혼동한 사례가 있었다. 별도의 dense 비교 시험은 최대 192K 문맥에서 수행됐다. 제작자는 250K에서는 dense 비교 서버의 메모리 부족으로 같은 시험을 하지 못했다고 설명한다. 이 측정이 일반적인 코딩 작업의 정확도를 보장하지는 않는다.
패치는 vLLM 스케줄러 내부를 변경하므로 버전 업그레이드에 취약할 수 있다. 저장소에는 실행 스크립트와 결과가 있지만 일부 결과를 만든 내부 평가 도구는 포함되지 않았다. 실제 도입 전에는 자체 코드와 질문으로 정확도, 첫 요청 지연, 동시 처리량을 함께 측정하고 기존 환경과 분리해 시험하는 편이 좋다.



Discussion
No comments yet