KV 캐시 중심으로 본 LLM 서빙

서빙 기법을 하나씩 고르는 대신, KV 캐시를 어디에 둘지와 얼마나 줄일지와 누가 가질지와 어떻게 검증할지 네 축으로 나눠 고르는 편이 낫습니다.

캐시 하나로 모이는 서빙 최적화

프리필-디코드 분리, KV 캐시 압축, 접두사 인지 라우팅, 투기적 디코딩은 보통 서로 다른 계층의 기법으로 소개됩니다. 그런데 이들이 건드리는 자원은 하나입니다. Texas Tech 연구진의 KV 캐시 관리 서베이(arXiv:2607.02574)는 서른 개가 넘는 서빙 시스템을 네 축으로 분류합니다. 그 서두는 KV 캐시의 지위가 요청마다 잠깐 쓰는 텐서에서 일급 메모리 객체(first-order memory object)로 바뀌었다고 선언합니다.

이 선언에는 산술적 근거가 있습니다. 같은 서베이는 T스텝을 디코딩하는 동안 누적 KV 읽기 트래픽이 프롬프트 길이 S에 대해 O(TS + T²)로 늘어난다고 정리합니다. 컨텍스트가 길어지고 동시 요청이 늘수록 디코드 단계가 KV 대역폭과 용량에 점점 더 민감해진다는 뜻입니다.

서베이 자신은 위치성, 생명주기, 소유권, 기질이라는 네 축으로 시스템을 분류합니다. 이 글에서 쓰는 네 축은 그 분류와 다르며, 실무자가 기법을 고르는 순서에 맞춰 제가 다시 나눈 것입니다. 캐시를 어디에 둘지(위치), 몇 바이트로 만들지(크기), 어느 인스턴스가 들고 있을지(소유권), 줄인 캐시의 출력을 어떻게 보증할지(검증)입니다.

캐시가 놓이는 자리

프리필은 연산 집약 단계이고 디코드는 메모리 대역폭 제약 단계입니다. 한 GPU에 두면 서로를 밀어냅니다. DistServe(arXiv:2401.09670, OSDI 2024)는 두 단계를 별도 GPU 풀에 배치했습니다. 기존 시스템 대비 7.4배 많은 요청 또는 12.6배 엄격한 SLO를 처리했다고 보고합니다.

중요한 것은 분리가 캐시의 물리적 위치를 바꾼다는 점입니다. 프리필 노드가 만든 캐시를 디코드 노드로 옮겨야 하므로, KV 캐시는 GPU 안의 버퍼에서 네트워크와 저장소 경계를 넘는 명시적 페이로드가 됩니다. KVServe(arXiv:2605.13734, 2026-05)는 이 전환을 두고 KV가 종단 병목을 지배하게 됐다고 표현합니다.

옮기는 값이 얼마나 큰지는 측정값이 말해 줍니다. 2026-07에 나온 프리필 디플렉션 논문(arXiv:2607.02043)은 프리필 노드 2개와 디코드 노드 2개로 짠 A100 클러스터를 쟀습니다. 프리필 연산 자체는 P95 TTFT의 2~23%만 차지했고, 나머지는 큐 대기와 노드 간 KV 캐시 전송이 가져갔습니다. 같은 논문은 디코드 노드가 여유 있을 때 프리필을 청크로 흡수해 전송을 없애고 P95 TTFT를 최대 81% 줄였습니다.

이 수치는 커널을 깎는 일의 우선순위가 낮다는 뜻입니다. 캐시가 어디서 만들어져 어디로 가는지를 먼저 봐야 합니다.

캐시가 차지하는 바이트

바이트를 줄이는 길은 세 갈래로 갈립니다. 어텐션 구조를 바꿔 애초에 적게 만드는 쪽, 만들어진 텐서를 부호화하는 쪽, 덜 중요한 토큰을 버리는 쪽입니다.

구조를 바꾸는 대표 사례는 MLA입니다. Key와 Value를 저차원 잠재 벡터로 접어 캐시하면 분리형 서빙의 전송량도 함께 줄어듭니다. Multi-head Latent Attention과 KV 캐시 압축에서 자세히 다뤘습니다. 다만 구조 변경은 학습 시점에 결정되므로 이미 배포한 모델에는 적용할 수 없습니다.

배포된 모델에는 부호화가 붙습니다. KVTC(arXiv:2511.01815, ICLR 2026)는 PCA 기반 상관 제거와 적응적 양자화와 엔트로피 부호화를 이어 붙입니다. 모델 파라미터를 그대로 둔 채 최대 20배, 특정 용례에서는 40배 이상 압축하면서 추론 및 장문 정확도를 유지했다고 보고합니다.

추론 모델에서는 압축 대상이 프롬프트가 아닙니다. 답을 내기 전에 긴 사고 과정을 생성하므로 캐시가 디코딩 중에 불어납니다. ThinKV(arXiv:2510.01290, ICLR 2026)는 사고 유형별로 토큰 정밀도를 달리해 원본 캐시의 5% 미만으로 줄이면서 처리량을 최대 5.8배 올렸습니다. R-KV(arXiv:2505.24133, 2025년)는 중복 서술 토큰을 지워 캐시 10%로 원본에 가까운 성능을, 16%에서는 105%를 기록했습니다.

여기서 함정은 압축률이 서빙 품질의 대리 지표가 아니라는 점입니다. Agrawal과 Mayer의 벤치마크(arXiv:2607.05399, 2026년)는 KIVI, TurboQuant, SnapKV, CaM을 같은 모델과 같은 스택에서 비교했습니다. 결론은 압축률만으로 종단 성능을 예측할 수 없다는 것이었습니다. KIVI4는 품질이 가장 안정적이었고, SnapKV는 장문 처리량이 가장 높았으며, CaM은 일부 QA에서 크게 이겼지만 워크로드가 바뀌면 품질과 실현 압축률이 함께 흔들렸습니다.

캐시를 들고 있는 인스턴스

같은 시스템 프롬프트를 쓰는 요청을 같은 인스턴스로 보내면 캐시를 재사용해 TTFT가 줄어듭니다. 그런데 인기 있는 접두사에 요청이 몰리면 그 인스턴스만 과부하됩니다. 캐시 친화성과 부하 분산은 하나의 라우팅 정책으로 동시에 만족시킬 수 없습니다.

서베이는 이 축을 특히 무겁게 봅니다. 워크로드와 하드웨어를 고정하고 나면, 분산 시스템 사이에 남는 설계 차이의 상당 부분을 소유권이 설명한다고 정리합니다(arXiv:2607.02574).

해법은 계층마다 갈립니다. Mooncake(arXiv:2407.00079, 2024년)는 GPU 클러스터의 유휴 CPU와 DRAM과 SSD를 묶어 분산 캐시 풀을 만듭니다. 그 위에 지연 SLO를 지키면서 전체 유효 처리량을 최대화하는 KVCache 중심 스케줄러를 둡니다. 시뮬레이션에서 처리량 최대 525% 증가, 실제 워크로드에서 Kimi가 75% 더 많은 요청 처리를 보고했습니다.

DualMap(arXiv:2602.06502, 2026-02)은 라우팅 알고리즘 자체를 다시 짭니다. 요청을 독립적인 두 해시 함수로 두 후보에 매핑한 뒤 현재 상태가 나은 쪽을 고릅니다. 이 power of two choices로 동일 TTFT SLO에서 유효 요청 용량을 최대 2.25배 올렸습니다.

PEEK(arXiv:2607.02525, 2026년)는 인스턴스 사이가 아니라 한 인스턴스의 대기열 안을 봅니다. 대기 요청에 증분 radix tree를 유지해 접두사 공유 그룹을 드러내고, 그룹의 선발 요청을 먼저 처리해 형제 요청이 갓 생긴 캐시를 물려받게 합니다. SGLang과 vLLM 기준으로 TTFT를 각각 최대 7.9배와 7.1배 개선했고, 공유 접두사가 없는 워크로드에서는 기준선과 같은 수준을 유지했습니다.

BanaServe(arXiv:2510.13223, 2025년)는 반대 방향으로 풉니다. 가중치를 계층 단위로, KV 캐시를 어텐션 단위로 옮길 수 있게 만들고 전역 KV 저장소를 공유해, 라우터가 캐시 위치에 매이지 않고 부하만 보고 스케줄하게 합니다. vLLM 대비 처리량 1.2~3.9배를 보고했습니다. 네 시스템의 차이를 소유권을 고정 제약으로 볼지 움직일 변수로 볼지의 차이로 읽는 것은 제 판단입니다.

틀릴 수 있는 캐시를 쓰는 값

앞의 세 축은 모두 무언가를 포기합니다. 압축은 정확도를, 라우팅은 지역성이나 균형을, 분리는 전송 비용을 감수합니다. 네 번째 축은 그 포기를 되사는 장치입니다.

투기적 디코딩은 작은 드래프트 모델이 여러 토큰을 제안하고 큰 타깃 모델이 한 번의 순전파로 검증해, 출력 분포를 바꾸지 않으면서 지연을 줄입니다. VeriCache(arXiv:2605.17613, 2026-05)는 이 구조를 모델이 아니라 캐시에 적용했습니다. 압축 캐시로 토큰을 초안 생성하고 원본 전체 캐시로 검증해, 손실 압축을 쓰면서도 전체 캐시 디코딩과 동일한 출력을 보장하면서 처리량을 최대 4배 올립니다.

VeriCache 저자들이 짚는 실패 모드가 이 축의 존재 이유입니다. 토큰 제거나 양자화는 짧은 출력에서는 정확도 손실이 작지만, 디코딩이 길어질수록 원본 출력에서 점점 벌어집니다. 그 결과 코드 생성이나 도구 호출에서 치명적 실패로 이어집니다. 압축률을 고를 때 출력 길이를 함께 봐야 하는 이유입니다.

검증 단계 자체도 공짜가 아닙니다. FASER(arXiv:2604.20503, 2026-04)는 기존 투기적 디코딩 시스템의 스케줄링 단위를 문제로 지목합니다. 배치 전체에 하나의 추측 길이를 두고 draft와 verify를 직렬로 돌리는 방식입니다. 저부하에서는 draft가 verify를 막아 연산 자원이 놀고, 고부하에서는 거부될 토큰까지 끝까지 계산해 낭비합니다.

FASER는 요청 단위로 추측 길이를 조정하고 verify를 조각내 draft와 겹쳐 실행합니다. 그 결과 처리량을 최대 53% 올리고 지연을 최대 1.92배 줄였습니다.

서로를 밀어내는 네 축

네 축을 따로 최적화할 수 없는 이유는 한 축의 이득이 다른 축의 비용으로 넘어가기 때문입니다. 아래 표는 앞 절들의 근거를 축 사이 관계로 다시 정리한 것입니다.

이 표에서 두 방향이 보입니다. 아래로 내려가며 비용을 넘기는 방향이 하나이고, 비용을 받은 축에서 그 비용을 다시 지우는 방향이 다른 하나입니다. 압축은 전송량을 줄여 위치 축을 돕지만 손실을 검증 축으로 넘기고, VeriCache는 그 손실을 다시 지웁니다. 캐시 친화 라우팅은 소유권을 고정해 위치 축에 핫스팟을 만들고, BanaServe는 캐시를 옮길 수 있게 만들어 그 고정을 푼 뒤 마이그레이션 비용을 떠안습니다.

이 렌즈가 닿지 않는 곳

KV 캐시로 서빙 최적화를 전부 설명할 수는 없습니다. MoE 모델에서는 전문가 배치와 all-to-all 통신이 캐시와 별개인 자원 문제입니다. MoE 로드 밸런싱과 그래디언트 간섭에서 다룬 라우팅 편중은 캐시가 아니라 전문가 부하의 문제입니다. 서베이도 MoE 서빙을 미해결 문제 목록에 남겨 두었습니다.

컨텍스트가 짧고 배치가 작은 구간에서도 이 렌즈는 힘을 잃습니다. O(TS + T²) 스케일링은 T와 S가 커질 때 의미가 있고, 짧은 요청에서는 캐시 크기보다 커널 실행 오버헤드와 네트워크 왕복이 더 큽니다. 전역 캐시 풀이나 프리필 디플렉션 같은 장치는 이 구간에서 복잡도만 늘립니다. 어텐션 자체와 배칭의 기본기는 Transformer 구조와 LLM 서빙 최적화에 정리해 두었습니다.

수치의 출처도 한계입니다. 이 글에 적은 배수는 2026-09 기준으로 각 논문 초록과 대조한 값입니다. 다만 대부분 저자가 자기 프로토타입에서 잰 값이고 기준선과 하드웨어가 논문마다 다릅니다. 다른 프레임워크에서 같은 배수가 재현되는지는 각 논문 밖에서 확인되지 않았습니다.

서베이도 같은 공백을 짚습니다. 현재 평가 관행을 감사해 KV 고유 측정 항목 일곱 가지가 빠져 있다고 지적합니다. 그리고 그 공백을 내결함성과 격리와 계층적 축출과 투기적 디코딩과 MoE 서빙과 공유 캐시 의미론이라는 미해결 문제로 연결합니다.

계측 순서

네 축에는 손대는 순서가 있습니다. 아래 순서는 각 축의 개입 비용과 앞에 인용한 수치들의 크기를 근거로 제가 정리한 것이며, 워크로드에 따라 달라질 수 있습니다.

1번을 맨 앞에 두는 근거는 프리필 연산이 P95 TTFT의 2~23%에 그친다는 측정값입니다. 프리필이 꼬리 지연의 4분의 1에 못 미친다면 커널이나 압축을 손대도 꼬리는 거의 그대로 남습니다. 3번을 뒤로 미루는 이유는 압축이 검증 축으로 비용을 넘기기 때문이고, 4번은 출력이 길고 정확도에 민감한 워크로드에서만 필요합니다.

정리

2025년과 2026년의 LLM 서빙 논문들은 서로 다른 기법처럼 보이지만, 대부분 KV 캐시라는 한 자원의 위치와 크기와 소유권과 검증을 다룹니다. 이 네 축은 독립적이지 않아서, 한 축에서 얻은 이득은 다른 축의 비용으로 옮겨 갑니다. 압축이 전송을 줄이는 대신 손실을 남기고, 캐시 친화 라우팅이 히트율을 올리는 대신 핫스팟을 만드는 식입니다. 그래서 기법을 고르기 전에 TTFT에서 큐 대기와 전송이 차지하는 비율부터 재는 편이 낫습니다. 이 비율이 크면 커널이 아니라 캐시의 자리를 바꿔야 합니다.