SparseEngine이 희소 추론 방법 15종을 하나의 수명주기 계약으로 묶는다

무엇인가

긴 문맥 LLM 에이전트는 도구 호출과 추론 사슬을 반복하면서 상호작용 이력을 빠르게 쌓고, 이것이 KV 캐시 용량과 어텐션 연산 지연이라는 두 개의 GPU 병목을 만든다. 희소 추론 기법들은 선택적 어텐션 또는 압축된 KV 저장으로 이 비용을 줄이지만, KV를 어떻게 표현하고 언제 갱신하는지가 방법마다 다르다. 문제는 이들이 요청 스케줄링과 캐시 재사용이라는 공유 인프라 위에서 함께 돌아가야 한다는 점이다. 기존 엔진들은 인터페이스를 특정 캐시 레이아웃이나 워크플로에 맞춰 조직했다. Vortex는 페이지 중심 연산을, SPIN은 GPU-CPU 파이프라인 기반 파티션 관리를, Tangram은 헤드별 비균일 KV 보존을 노출한다. 이런 인터페이스는 어떤 방법에는 맞고 어떤 방법에는 제약이 된다. Quest는 쿼리 의존적 페이지 선택을 쓰지만 H2O는 생성 중에도 지속적인 어텐션 점수와 물리적 KV 축출이 필요하다. 논문이 던지는 핵심 질문은 공유 서빙 인프라와 방법별 KV 상태·연산 제어 사이의 추상화 경계를 어디에 둘 것인가다.

어떻게 동작하나

SparseEngine은 이 경계를 공유 수명주기 계약(lifecycle contract)에 놓는다. 추상화의 기준점은 특정 워크플로가 아니라 모델의 원래 모듈 실행 순서라는 불변식이다. 이 순서를 따라 세밀한 훅을 노출함으로써, 모델 구현을 수정하지 않고도 각 희소 방법이 콜백을 등록해 자기만의 계산 흐름을 조합할 수 있게 한다. 계약은 세 부분으로 구성된다. 첫째, SparseController가 프리필과 디코딩 양쪽에 걸쳐 어텐션 전후, 각 레이어 끝, 각 실행 스텝 끝에 훅을 제공하고, 초기화 시 선택된 SparseMethodRuntime이 방법별 콜백을 구현한다. 예컨대 프리필의 finish_step 훅은 누적 어텐션 점수를 이용한 H2O의 청크 단위 축출과 SnapKV의 마지막 프롬프트 청크 이후 선택·축출을 지원하며, 디코딩의 build_decode_selection은 Quest의 쿼리 의존적 페이지 선택을 수행한다. 둘째, CacheManager가 방법별 상태와 저장소를 소유한다. 각 방법이 KV 표현, 물리적 레이아웃, 위치 매핑, 할당·쓰기·갱신·해제 연산을 정의하고, 대응하는 KV 상태 옆에 지속 메타데이터를 유지한다. 물리적 축출은 보존 슬롯 매핑과 문맥 길이를 갱신한 뒤 버려진 슬롯을 할당자에 반환하는 반면, 논리적 선택은 어텐션이 읽는 상주 엔트리만 바꾼다는 구분이 여기서 나온다. 셋째, AttentionView가 방법 소유의 캐시 표현을 어텐션 실행에 연결한다. 선택 기반 방법의 경우 View = BuildView(C, I), o = Attention(q, View) 형태로, 지속 캐시 상태 C와 선택된 토큰·페이지 식별자 I로부터 접근 가능한 데이터와 물리적 레이아웃을 기술하는 뷰를 CacheManager가 구성한다. 이 뷰는 선택·압축·양자화·온디맨드 복원된 KV 위에서의 어텐션을 지원하면서 지속 상태 관리는 CacheManager에 남긴다.

무엇과 다른가

이 계약 위에 요청 간 상태 관리가 확장된다. Chain Cache는 축출 기반 방법이 턴을 넘어 압축된 상태를 재사용하게 한다. Quest·OmniKV·NSA·DSA 같은 동적 희소 어텐션 방법은 전체 KV 이력을 보존하므로 기존 프리픽스 캐싱이 통하지만, SnapKV·KVzip·H2O 같은 축출 기반 방법은 상주 KV 가정을 깨뜨린다. ChainCacheIndex는 세션을 레이어별 보존 KV, 방법별 메타데이터, 논리적 토큰 프리픽스와 연결한다. SnapKV가 물리적 KV 엔트리 일부를 제거해도 논리적 프리픽스는 매칭에 그대로 쓸 수 있어, 이어지는 요청은 전체 프리픽스를 재구성하는 대신 보존된 KV와 방법 상태에서 재개하고 처리되지 않은 접미사만 프리필한다. 세션마다 chain_id가 부여되고, 유휴 체인은 용량이 필요할 때 최근 최소 사용 순서로 회수된다. 두 번째 확장인 희소 기반 프리픽스 캐시 프루닝은 애플리케이션이 지정한 이력 구간에서 KV를 제거하면서 논리적 프리픽스 매칭을 보존한다. 애플리케이션이 요청의 전체 token_ids와 0 기반 경계의 프루닝 구간 [L, R)을 제출하면, SnapKV나 KVzip 같은 스코어링 정책이 구간 내에서 보존할 위치를 골라 마스크를 반환하고, 캐시 관리자는 활성 참조나 전송 중인 블록이 없는 유휴 블록에만 이 마스크를 적용한다. 논리적 프리픽스 P는 그대로 두고 상주 KV 위치 집합만 R' = (R ∖ T) ∪ I로 바꾸며, R'에서 빠진 물리 슬롯을 해제한다.

어떻게 쓰나

실험은 LongBenchV1·LongBenchV2로 긴 문맥 품질을, AIME로 추론 품질을, SWE-Bench Lite와 Claw-Eval로 다중 턴 에이전트 품질을 평가한다. 서빙 성능 비교 대상은 Vortex, HiSparse, Tangram, vLLM v0.26.0이다. 모델은 GQA 계열로 Llama-3.1-8B-Instruct, Qwen3-4B-Thinking-2507, MoE인 Qwen3-30B-A3B-Instruct-2507을, MLA 계열로 GLM-4.7-Flash를, 선형 어텐션과 GQA를 결합한 하이브리드로 Qwen3.6-27B를 쓴다. 하드웨어는 NVIDIA H100, H20, RTX PRO 6000, 4090, 5090이다. 결과부터 보면, 물리적 KV 축출 덕분에 같은 GPU 구성에서 훨씬 큰 디코드 배치를 유지할 수 있어 SnapKV를 얹은 SparseEngine은 두 모델 모두에서 순정 vLLM 대비 약 10배의 집계 디코드 처리량을 낸다. 동적 희소 어텐션은 동일 배치 크기에서 Quest와 OmniKV로 순정 vLLM 대비 약 1.5~2.6배의 디코드 처리량을 달성한다. 특화 시스템과의 방법별 비교에서는 Qwen3 128K 입력, 배치 2에서 Quest가 Vortex의 1.24배, HiSparse의 1.55배 처리량을, SnapKV가 Tangram의 1.55배를 기록했다.

전제와 한계

품질 쪽에서는 LongBench V1·V2의 전체 점수 비교 20건에서 SparseEngine이 참조 구현 대비 평균 +0.17점 차이, 모집단 분산 0.32 제곱점을 보여 방법의 과제 품질을 근접하게 보존한다. 다만 top-p 샘플링의 무작위성과 LongBench V2 하위 과제의 적은 인스턴스 수 때문에 개별 하위 점수는 눈에 띄게 흔들린다. 에이전트 과제에서는 SnapKV와 H2O가 Chain Cache로 압축 KV와 방법 상태를 유지했고, SnapKV는 GLM에서 전체 어텐션 참조에 근접한 성공률을, Qwen3에서는 참조보다 많은 과제를 해결했다. 프리픽스 프루닝은 KVzip 기반 전역 스코어링으로 대상 도구 결과의 정렬된 KV 토큰 20%를 보존할 때 성능이 소폭 하락했지만, lag=4로 프루닝을 지연해 최근 네 라운드를 온전히 남기자 원래 성능이 즉시 회복되며 25.0% 과제 성공률을 기록했다. 엔드투엔드 리플레이에서는 8K 캐시 예산의 SnapKV와 Chain Cache가 Gasai 트레이스에서 Vanilla 대비 2.24배 속도를 냈다.

개발자 관점에서 이 논문의 실용적 의미는 희소 추론 기법을 서빙 스택에 넣는 방식을 바꾼다는 데 있다. 기존에는 엔진이 정한 캐시 레이아웃에 방법을 끼워 맞추거나 모델별 특수 구현(LlamaSnapKV, Qwen3H2O 같은)을 따로 만들어야 했다. SparseEngine은 프리필·디코딩·레이어 경계·스텝 전환의 훅과 방법 소유 CacheManager, AttentionView라는 세 지점만 맞추면 4개 계열 15개 방법을 같은 스케줄러와 연속 배칭, 프리픽스 캐싱 위에서 돌릴 수 있다고 주장한다. 특히 물리적 축출과 논리적 선택을 분리한 설계는 축출 기반 방법에서도 프리픽스 재사용을 가능하게 하므로, 다중 턴 에이전트처럼 이력이 계속 자라는 워크로드에서 메모리 예산과 동시성 설정을 다시 계산할 근거가 된다. 도입을 검토한다면 자신이 쓰는 방법이 어느 계열(동적 선택·축출·압축·양자화)인지, 그리고 그 방법이 요구하는 지속 메타데이터가 Chain Cache의 체인 상태로 보존되는지를 먼저 확인해야 한다.

저자들이 밝힌 전제와 한계도 분명하다. AIME 실험은 품질-효율 트레이드오프가 넓게 존재하며 더 큰 속도를 주는 방법일수록 정확도 하락이 크다고 보고한다. 이 실험의 속도 향상이 디코드 벤치마크보다 낮은 것은 평가 문맥이 더 짧아 전체 실행 시간에서 어텐션이 차지하는 비중이 줄었기 때문이다. Chain Cache는 지나치게 공격적인 희소 예산을 쓰지 않는 한 복잡한 다중 턴 과제에서 견고한 품질을 유지한다고 저자들은 조건을 달아 말한다. 프루닝 임계값과 선택 정책은 같은 캐시 관리 추상화 안에서 더 탐구할 여지가 있다고 남겨 둔다. 또한 이 시스템은 효율과 캐시 관리만 다루며 기반 모델의 안전성이나 편향은 해결하지 않으므로 배포 시 별도 보호 장치가 필요하다고 명시한다.