서울대 연구진, KVGuard로 vLLM·SGLang KV 캐시 오류 8건 찾아

서울대의 Jonguk Cheong, Myungbin Hwang, Eulgyu Kim, Byoungyoung Lee 연구진은 2026년 11월 4일 arXiv에 공개한 논문에서 KV 캐시 메모리 안전성 검사기 KVGuard를 제시했습니다. 연구진은 KVGuard를 vLLM과 SGLang에 구현해 과거 오류 29건을 재현하고, 실제 서빙 실행에서 새 안전성 위반 8건을 찾았다고 보고했습니다. 새 사례마다 상류 프로젝트에 수정 PR을 제출했습니다.

KV 캐시는 모델이 앞선 토큰을 처리하며 만든 키·값 벡터를 저장해 다음 토큰 생성에 재사용하는 메모리입니다. PagedAttention은 GPU 메모리의 큰 버퍼를 고정 크기 물리 블록으로 나누고, 요청별 토큰 구간인 논리 블록을 물리 블록에 연결합니다. CPU가 만든 블록 테이블을 커널 실행 전에 GPU로 복사하면, GPU 커널은 이 표를 따라 KV 값을 읽고 씁니다. 접두부 캐시처럼 여러 요청이 같은 블록을 공유하면 읽기는 허용하되 쓰기는 막아야 합니다.

기존 메모리 검사기는 주로 CUDA 주소와 할당 단위를 기준으로 접근을 점검합니다. 잘못된 매핑이 같은 GPU 버퍼 안의 다른 물리 블록을 가리키면 주소 자체는 할당 범위 안에 있어 검사에서 놓칠 수 있습니다. 예를 들어 논문이 든 vLLM 오류에서는 CUDA 그래프의 패딩 행에 남은 낡은 매핑이 실제 요청이 사용하는 블록에 쓰기를 시도했습니다. 이런 접근은 시스템을 멈추게 하는 대신 출력 손상이나 요청 간 상태 혼선을 일으킬 수 있습니다.

KVGuard는 물리 KV 블록마다 shadow 기록을 두고, 어떤 요청이 해당 블록을 읽거나 쓸 수 있는지와 블록 안 각 항목에 값이 기록됐는지를 추적합니다. 권한은 블록 단위로, 초기화 여부는 항목 단위로 관리합니다. 블록이 새 요청에 배정되면 초기화 기록을 지우고, 값이 기록될 때마다 해당 항목의 초기화 상태를 갱신합니다. 요청 식별자를 재사용하지 않는 시스템 특성도 블록의 현재 사용 상태를 추적하는 데 활용합니다.

검사는 CPU의 블록 할당·공유·해제, CPU 블록 테이블 작성, GPU로 전달되는 테이블 확인, GPU 커널의 블록 조회와 KV 항목 접근으로 이어집니다. KVGuard는 CPU 블록 테이블의 각 매핑에 요청의 접근 권한이 있는지 확인하고, GPU에 복사된 테이블이 CPU에서 만든 표와 같은지 대조합니다. 커널에서는 현재 요청의 행과 허용된 논리 블록 범위에 맞는 매핑인지, 실제 블록에 읽기·쓰기 권한이 있는지, 읽을 항목이 초기화됐는지를 검사합니다. 위반이 처음 생긴 경계에서 잡아 이후의 출력 손상보다 원인을 빨리 드러내려는 설계입니다.

DMA나 네트워크로 KV 블록을 옮기는 경우에도 같은 권한·초기화 검사를 적용합니다. 보내는 쪽은 전송할 항목이 초기화됐는지 확인하고, 전송이 끝날 때까지 원본 블록을 유지합니다. 받는 쪽은 자기 요청에 속한 목적 블록에만 쓰며 실제로 도착한 항목만 초기화된 것으로 기록합니다. 일부 항목만 전달된 경우에는 보내는 쪽이 전달한 항목 수를 알려 받는 쪽이 나머지를 초기화된 값으로 처리하지 않게 합니다.

연구진은 vLLM과 SGLang의 수정 이력에서 모은 과거 오류 29건을 버그가 있던 버전과 수정본에서 각각 재현했습니다. KVGuard는 오류가 있던 실행에서는 위반을 보고하고 수정본에서는 보고하지 않았습니다. 새로 찾은 8건은 vLLM에서 3건, SGLang에서 5건입니다. 그중 하나는 sliding-window eviction 뒤 작업자의 블록 테이블에 이전 물리 블록 번호가 남은 문제였습니다. 논문은 평가한 실행에서 거짓 양성을 보고하지 않았다고 밝혔습니다.

Qwen 2.5 14B 평가에서 KVGuard의 TPOT 오버헤드는 기하평균 기준 vLLM 3.0%, SGLang 7.4%였고, H100에서 shadow 메타데이터가 KV 캐시 용량에서 차지한 비율은 최대 0.11%였습니다. 별도로 NVIDIA Compute Sanitizer와 비교할 때는 내부 메모리 사용량 때문에 두 서빙 엔진의 GPU 메모리 사용률을 0.50으로 낮추고 KV 풀을 일반 설정의 4분의 1로 줄였습니다. 이 설정에서 프롬프트 40개를 초당 1건과 4건 처리했으며, initcheck는 켜면 서빙 시스템이 실행되지 않아 제외했습니다.

Llama 3.2 1B를 초당 4건 처리한 vLLM 실행에서 중앙값 TPOT는 기준 실행 1.7ms, KVGuard 적용 3.5ms였습니다. 같은 조건에서 전체 커널을 검사한 memcheck는 194ms, KV 캐시 커널만 검사한 memcheck-kv는 51ms였습니다. 두 모드는 KV 풀을 하나의 할당으로 취급해 풀 안의 다른 물리 블록을 향한 접근을 놓칠 수 있습니다. NVTX로 각 KV 블록을 별도 할당처럼 등록해 memcheck-kv에 블록 단위 경계를 제공하면, Llama 3.2 1B vLLM의 초당 1건 실행에서 TPOT 지연은 기준 실행의 522배가 됐습니다. 초당 4건 조건에서는 엔진이 초당 약 한 스텝만 처리해 측정값을 내지 못했습니다.

연구진은 KVGuard를 상시 운영용 보호 기능보다 CI, 사전 릴리스 검사와 사고 원인 추적에 쓰는 sanitizer로 제시합니다. 검사 범위는 KV 블록의 할당·매핑·접근 권한과 초기화 상태입니다. 접두부 캐시의 해시 충돌이나 KV 캐시 밖의 보조 메타데이터 오류는 검사 대상에 포함되지 않습니다.