91편 · 약 14분

VeriCache: 손실 KV 캐시 압축을 무손실 추론으로 바꾸는 검증-스왑 프레임워크

요약

LLM 추론에서 KV 캐시는 긴 시퀀스를 처리할 때 GPU 메모리의 주된 병목이 된다. 이를 해결하기 위해 토큰 드롭, 양자화 같은 압축 방식들이 제안됐지만, 모두 본질적으로 손실(lossy)이다. 짧은 출력에서는 차이가 미미하지만, 코드 생성이나 도구 호출처럼 긴 출력을 요구하는 작업에서는 전체 KV와 점점 다른 결과를 내놓아 치명적 오류로 이어진다.

2026년 5월 공개된 VeriCache(arXiv:2605.17613)는 이 문제를 뒤집어서 접근한다. 압축 KV로 토큰을 초안(draft)하고, 전체 KV로 그것을 검증(verify)하는 구조를 택한다. 검증 중에 GPU는 또 다른 초안 배치를 처리하고 있고, 전체 KV는 PCIe로 전송 중이다. 두 작업이 서로 다른 하드웨어 리소스를 쓰기 때문에 진짜로 병렬화된다. 결과적으로 출력은 전체 KV 추론과 동일하면서 처리량은 최대 4배 높다.

배경: KV 캐시 압축의 손실 문제

왜 KV 캐시를 압축하는가

Transformer 기반 LLM은 어텐션 계산을 위해 각 레이어마다 Key와 Value 텐서를 메모리에 유지한다. 이것이 KV 캐시다. 시퀀스 길이 $L$, 레이어 수 $N$, 헤드 차원 $d$라면 KV 캐시 크기는 $2 \times N \times L \times d$에 비례한다. 128K 토큰, 80레이어, FP16 기준으로 약 80GB를 차지하는데, A100 한 장의 HBM 용량과 맞먹는다. Decode 단계에서 이 캐시를 매 스텝마다 읽어야 하므로 메모리 대역폭이 처리량을 결정한다.

대표적인 압축 방법은 두 가지다.

방식	예시	핵심 아이디어	손실 원인
토큰 드롭	SnapKV, H2O, ScissorHands	어텐션 점수가 낮은 토큰의 KV를 버림	버려진 문맥 영구 손실
양자화	KVQuant, KVSharer	KV를 FP8/INT4 등 낮은 정밀도로 저장	반올림 오차 누적

단기 출력에서는 손실이 감지되지 않는다. 하지만 긴 생성 시퀀스에서는 누적 오차가 폭발적으로 커진다. 정확히 일치하는 스텝 수가 길수록 잃어버린 문맥의 영향이 증폭되기 때문이다. 코드 생성에서 변수 이름이 바뀌거나, 도구 호출 결과의 JSON 키가 달라지거나, 다중 단계 추론이 중간에 틀어지는 현상이 모두 이 패턴에서 비롯된다.

기존 해법의 한계

두 가지 대안이 있었다.

전체 KV 사용: 압축하지 않으면 정확하지만 GPU VRAM 병목이 그대로다.
압축 후 손실 허용: 처리량은 높지만 출력 신뢰성이 떨어진다.

VeriCache는 "둘 다 갖는" 방법을 찾는다.

VeriCache의 핵심 아이디어

VeriCache는 투기적 디코딩(Speculative Decoding)의 검증 패턴을 KV 압축 문제에 적용한다.

압축 KV로 초안을 생성하고, 전체 KV로 한 번에 검증한다.

투기적 디코딩에서 작은 드래프터 모델이 여러 토큰을 추측하고 큰 타깃 모델이 한 번에 검증하는 것과 구조가 같다. 차이는 드래프터가 다른 모델이 아니라 동일 모델에 압축된 KV를 준 것이라는 점이다. 이 덕분에 드래프터와 타깃의 토큰 분포가 매우 비슷하다. 실험에서 압축 KV 드래프터는 회차당 25~40개의 연속 토큰을 수용하는데, 일반 투기적 디코딩의 소형 모델(5~10개)보다 훨씬 길다.

VeriCache 파이프라인 — 압축 KV 초안과 전체 KV 검증의 병렬 실행

병렬 실행의 하드웨어 근거

왜 두 작업이 진짜로 겹쳐 실행되는가?

자원 충돌 없음

압축 KV 디코드: GPU 컴퓨팅 유닛과 HBM 내부 대역폭을 사용한다. GPU SM이 주인이다.
전체 KV 스왑: CPU↔GPU 간 PCIe 버스(또는 NVLink)를 사용한다. PCIe 컨트롤러가 주인이다.

두 작업이 서로 다른 하드웨어를 사용하므로 CUDA 스트림을 분리하면 진짜 동시 실행이 가능하다.

긴 초안 수용 길이가 필요한 이유

전체 KV 스왑은 한 번에 수십~수백 GB를 이동하는 작업이다. 스왑 1회에 걸리는 시간 동안 압축 KV 디코더가 충분히 많은 토큰(초안)을 생성해야 스왑 오버헤드가 희석된다. 관건은 회당 수용 길이다.

드래프터 종류	평균 수용 길이	비고
소형 모델 (일반 투기적 디코딩)	5~10 토큰	모델 구조 차이로 분포 불일치
압축 KV 드래프터 (VeriCache)	25~40 토큰	동일 모델, 문맥만 다름

압축 KV 드래프터가 월등히 긴 이유는 간단하다. 같은 모델 가중치를 쓰므로 생성 분포가 거의 일치한다. 압축으로 잃어버린 문맥 일부가 출력에 영향을 미치지 않는 구간이 길기 때문이다.

검증 프로토콜 상세

VeriCache의 한 사이클은 다음 순서로 진행된다.

초안 단계: 압축 KV를 GPU HBM에 올린 상태로 자동회귀 디코딩을 진행한다. $K$개의 토큰을 생성한다 ($K$는 검증 윈도우 크기).
전체 KV 스왑 인: 초안 단계와 동시에, PCIe를 통해 CPU DRAM(또는 원격 서버)에서 전체 KV를 GPU로 전송한다.
검증 단계: 전체 KV 스왑이 완료되면, GPU는 전체 KV로 생성된 초안 $K$개를 한 번의 포워드 패스로 검증한다. 검증은 $K$개 토큰을 병렬로 평가하므로 시퀀셜 디코딩 $K$회가 아닌 1회 연산이다.
수용 또는 수정: 처음 불일치 지점까지의 토큰을 모두 수용한다. 불일치 지점부터는 전체 KV로 교정 토큰 하나를 생성한 뒤, 다시 압축 KV 초안 단계로 넘어간다.
전체 KV 스왑 아웃: 검증이 끝나면 전체 KV를 GPU HBM에서 내려 공간을 확보한다. 다음 스왑 사이클을 위해 압축 KV만 남긴다.

원격 프리픽스 캐싱에서의 응용

분산 서빙에서 프리픽스 KV를 다른 서버에 두고 요청이 올 때마다 네트워크로 전송하는 방식이 있다. VeriCache는 이 시나리오에서도 동작한다. 로컬 GPU는 압축 KV로 먼저 디코딩하고, 동시에 원격 서버에서 전체 KV를 가져온다. 네트워크 대기 시간이 초안 생성으로 숨겨진다.

성능 결과

처리량 향상 (긴 컨텍스트 디코딩)

설정	전체 KV 대비 처리량
Llama-2-70B, 128K 컨텍스트, A100	최대 3.82×
일반적인 긴 컨텍스트 워크로드	평균 2.5~4×

출력 품질

출력 KL divergence가 전체 KV 대비 0.01 nats 이하다. 수치상 무손실에 해당한다.

원격 프리픽스 캐싱

설정	전체 KV 대비 처리량
원격 프리픽스 캐싱, 평균	최대 2×

네트워크 지연이 더 크므로 로컬 스왑보다 이득이 작지만, 원격 통신 지연을 숨기는 데 효과적이다.

투기적 디코딩과의 조합

VeriCache는 전통적인 투기적 디코딩과 직교적이다. 소형 드래프터 모델을 사용하는 투기적 디코딩을 VeriCache 위에 중첩 적용하면 두 기법의 이득이 더해진다.

압축기 인터페이스

VeriCache는 특정 압축 방식에 묶이지 않는다. 압축기를 추상 인터페이스로 정의하고, 그 위에 토큰 드롭 방식(SnapKV, H2O, ScissorHands)과 양자화 방식(KVQuant 등)을 모두 플러그인으로 연결할 수 있다.

압축기가 갖춰야 할 조건은 두 가지다.

결정론적 압축: 같은 입력에 항상 같은 압축 KV를 생성해야 한다 (재현성을 위해).
부분 매핑 가능: 전체 KV 중 어떤 위치의 토큰이 살아남았는지 인덱스를 제공해야 한다 (검증 시 정합을 위해).

이 두 조건을 만족하는 기존 방식들은 대부분 그대로 연결 가능하다.

운영 시 고려사항

적용 조건

전체 KV 저장 공간: 전체 KV를 CPU DRAM이나 NVMe SSD에 유지해야 한다. 80GB GPU 모델에서 전체 KV를 64K 배치로 저장하면 수백 GB가 필요하다. 충분한 DRAM이 없는 서버에서는 SSD 경로를 사용하지만 대역폭이 낮아 이득이 줄어든다.
PCIe/NVLink 대역폭: 스왑 시간이 초안 생성 시간 내에 완료되어야 한다. PCIe 4.0 × 16 기준 약 60~64GB/s다. 80GB 전체 KV를 스왑하면 1.3초가 걸리므로, 검증 윈도우를 충분히 크게 설정해야 한다.
압축 방식 선택: 수용 길이가 짧은 압축 방식은 스왑 오버헤드를 충분히 희석하지 못한다. 검증 전 오프라인 교정(calibration)으로 수용 길이를 측정한 뒤 윈도우 크기를 설정한다.

적용이 불리한 상황

시퀀스 길이가 짧아 KV 캐시가 HBM에 완전히 들어가는 경우: 전체 KV를 그냥 HBM에 두는 것이 낫다.
생성 길이가 매우 짧아(5~10 토큰) 검증 오버헤드가 이득을 초과하는 경우.
실시간성이 중요한 인터랙티브 워크로드: 스왑 지연이 TTFT를 늘릴 수 있다. 비동기 프리패치로 완화 가능하지만 한계가 있다.

다른 KV 캐시 최적화와의 위치

방식	목표	VeriCache와 관계
PagedAttention (vLLM)	GPU HBM 내 단편화 제거	직교, 같이 사용 가능
SnapKV / H2O	토큰 드롭으로 메모리 절감	VeriCache가 압축기로 사용
FP8 KV 양자화	비트 수 줄여 메모리 절감	VeriCache가 압축기로 사용
투기적 디코딩 (EAGLE 등)	소형 드래프터로 처리량 향상	중첩 적용 가능, 이득 가산
ObjectCache	KV를 오브젝트 스토리지에 저장	원격 프리픽스 시나리오에서 조합 가능

요점 정리

기존 KV 캐시 압축(토큰 드롭·양자화)은 처리량을 높이지만 긴 출력에서 결과가 달라지는 손실 문제를 피할 수 없다.
VeriCache는 압축 KV로 초안을 생성하고 전체 KV로 검증하는 구조를 취한다. 검증 비용은 전체 KV 스왑과 GPU 컴퓨팅을 병렬화해 숨긴다.
두 작업의 하드웨어 리소스(HBM vs PCIe)가 다르기 때문에 진짜 병렬화가 가능하다.
압축 KV 드래프터의 수용 길이(25~40 토큰)가 투기적 디코딩 소형 모델보다 훨씬 길어 스왑 비용을 효과적으로 희석한다.
결과는 전체 KV 추론과 동일하면서 처리량은 최대 4배 높다.
적용 조건: 전체 KV를 저장할 DRAM 또는 SSD 공간, 충분한 PCIe 대역폭, 긴 시퀀스 워크로드.

References

VeriCache 논문 (arXiv:2605.17613, May 2026): <https://arxiv.org/abs/2605.17613>
SnapKV (KV 캐시 압축 토큰 드롭): <https://arxiv.org/abs/2404.14469>
H2O (Heavy-Hitter Oracle): <https://arxiv.org/abs/2306.14048>
KVQuant (KV 캐시 양자화): <https://arxiv.org/abs/2401.18079>
EAGLE (투기적 디코딩 드래프터): <https://arxiv.org/abs/2401.15077>
ObjectCache (오브젝트 스토리지 KV): <https://arxiv.org/abs/2605.22850>
vLLM Paged Attention 문서: <https://docs.vllm.ai/en/latest/design/kernel/paged_attention.html>