로컬 LLM의 KV 캐시 성능을 실제 부하 상황에서 검증하고 캐시 퇴거 과정을 확인하세요

안녕,

요즘 로컬 LLM 캐시 관리에 좀 미쳐있어.

지난 며칠 동안 2x DGX Spark랑 DeepSeek v4 Flash 0731 환경에서 vLLM 캐시 관리 가지고 씨름 좀 했거든. 뭔가 좀 이상해서 파고들어 보니까 역시나 문제가 있더라고. 그래서 고치긴 했는데, 이게 제대로 된 건지 검증할 방법이 필요했어.

그래서 내 배포 환경에서 캐시가 실제로 얼마나 잘 관리되고 있는지 정확히 짚어낼 수 있는 간단한 프로토콜 기반의 툴을 하나 만들었어:

1. 프로브를 돌려서 기대치를 보정함 (내 환경에서 캐시 히트랑 미스가 뭔지 파악)

2. 캐시를 꽉 채우기 위해 Y 토큰짜리 X개의 안정적인 컨텍스트를 주입함

3. 캐시 미스가 발생할 때까지 역순으로(마지막에 추가된 것부터) 캐시 히트 검증을 수행함

제대로 된 값을 얻으려면 아무것도 안 돌리는 상태에서 혼자 실행하는 게 좋아. 이거 돌리면 현재 캐시된 컨텍스트 다 날아가니까, 실제 작업 중일 때는 절대 돌리지 마.

내 결과

이건 내 A/B 테스트 결과야. 기존 프로덕션 환경(control)이랑 내가 수정한 프로덕션 환경 비교한 거임.

aidendle94/sparkrun-vllm-ds4-gb10:production-3.7-reffix-schedfix (수정 전 이미지, 리텐션 4096):

── Retention under pressure ──
capacity: 2,023,924 tokens
retained contexts: 27/80
retained tokens: 1,052,025
retained % capacity: 51.98%
oldest evicted: context #52 (older contexts evicted)

dedupe + boundfix 패치 적용 후 (리텐션 0):

── Retention under pressure ──
capacity: 2,047,043 tokens
retained contexts: 77/80
retained tokens: 3,000,048
retained % capacity: 146.56%
oldest evicted: context #2 (older contexts evicted)

이게 왜 중요한가

이걸 쓰면 네 캐시가 실제로 토큰을 얼마나 들고 있는지 정확히 알 수 있어.

우리 대부분한테 캐시 관리는 그냥 블랙박스잖아? 이건 그 실체를 보여주는 팩트 체크 도구야.

그리고 맞아, 내가 수정한 버전에서는 광고하는 2M 캐시가 실제로는 3M 토큰까지 유지돼. 못 믿겠으면 코드 직접 까봐. 다 오픈소스니까: cache-pressure (그리고 내 ds4 프리픽스 캐시 수정본: ds4-prefix-cache-fixes).

엔진에서 광고하는 수치는 틀렸고, 이 툴이 진짜 값을 찾아줌.

이 툴은 이런 사람들을 위한 거야: 1. 자기 환경 검증하거나 여러 추론 엔진 비교해보고 싶은 사람들 ; 2. 추론 엔진 유지보수하면서 캐시 관리 변경 사항 검증하려는 사람들

단, 한 가지 큰 전제가 있어: 가장 최근 컨텍스트가 최대한 보존되어야 한다는 거야.

툴 돌리면서 느낀 건데, vLLM은 괜찮은데 다른 엔진들은 설정 좀 더 다듬어야겠더라. 난 주로 vLLM만 써서 최상의 결과 뽑아내려고 설정을 몇 시간 동안 쥐어짰거든. 다른 엔진 쓰는 사람들은 위 전제가 자기 상황에 맞는지 판단해서 알아서 설정 잘 맞춰봐 (당연히 그래야 하는 거 아니냐 싶긴 한데, 뭐 사람마다 니즈가 다르니까).