요약
멀티턴 대화는 챗봇과 AI 에이전트의 핵심 시나리오다. 대화가 길어질수록 KV 캐시가 쌓이고, GPU의 HBM(High Bandwidth Memory) 용량을 초과하면 CPU 메모리나 SSD로 오프로드해야 한다. 오프로드된 KV 캐시를 다시 불러올 때는 느린 PCIe 대역폭이 병목이 돼 TTFT가 급격히 늘어난다. 2026년 6월 arXiv에 발표된 SwiftCache(arXiv:2606.16135)는 이 문제를 다른 각도로 푼다. 같은 서버에 공존하는 이종 모델들이 NVLink를 통해 유휴 GPU 메모리를 서로 공유하도록 해 HBM 부족 문제를 해결한다. 결과는 P99 TTFT 최대 69% 감소, 최대 컨텍스트 길이 최대 3.98배 확장이다.
배경: 멀티턴 대화의 KV 캐시 문제
왜 멀티턴은 어려운가
싱글 턴 요청은 요청당 KV 캐시가 독립적이라 GPU 메모리 관리가 비교적 단순하다. 멀티턴에서는 이전 모든 턴의 KV 캐시를 유지하거나 재계산해야 한다.
| 문제 | 내용 |
|---|---|
| HBM 초과 | 대화가 길어질수록 KV 캐시 누적이 HBM 용량을 초과 |
| 오프로드 지연 | CPU/SSD로 오프로드 시 PCIe(≈16 GB/s)가 병목 |
| 최대 길이 제한 | HBM 부족이 지원 가능한 최대 컨텍스트 길이를 제한 |
| 재로드 비용 | 턴마다 이전 KV 캐시를 다시 GPU로 가져오는 비용 누적 |
기존 접근법의 한계
CPU 오프로드(PCIe), SSD 오프로드, PagedAttention 기반 단편화 최소화가 주류 방법이었다. 이 방법들은 같은 서버 안에서 유휴 상태의 GPU 메모리가 많다는 사실을 활용하지 않는다. 실제 서빙 환경에서는 여러 모델이 같은 서버에 공존하며, 요청 패턴에 따라 특정 모델은 KV 캐시를 거의 사용하지 않는 시간대가 있다.
SwiftCache의 핵심 아이디어
SwiftCache의 통찰은 한 문장으로 요약된다. "같은 서버 안의 GPU는 NVLink로 연결돼 있고, 어떤 모델의 GPU 메모리는 유휴 상태다. 그 메모리를 KV 캐시 저장소로 쓰면 된다."
세 가지 핵심 기술
1. NVLink 기반 이종 KV 캐시 공유
실서빙 클러스터에서는 여러 모델이 같은 서버에 공존한다. 챗봇 모델은 긴 대화 컨텍스트로 KV 캐시가 많이 필요한 반면, 도구 실행 모델이나 분류 모델은 짧은 요청만 처리해 HBM 여유가 많다.
SwiftCache의 공유 메커니즘은 두 단계로 동작한다.
- 기증(Donation): 저수요 모델(GPU 1)이 유휴 HBM 블록을 공유 풀에 등록한다.
- 할당(Allocation): 고수요 모델(GPU 0)이 이전 턴 KV 캐시를 GPU 1의 공유 블록에 저장한다.
전송 경로는 NVLink다. NVLink의 대역폭은 ~600 GB/s로 PCIe(~16 GB/s)보다 약 37배 빠르다. KV 캐시를 CPU로 내보내는 대신 인접 GPU에 두면 재로드 지연이 대폭 줄어든다.
2. Layer Stream Cache
SwiftCache는 추론 시 전체 레이어의 KV 캐시를 로컬에 보관하지 않는다. 현재 실행 중인 레이어 N의 KV 캐시만 로컬 HBM에 두고, 나머지 레이어의 KV 캐시는 원격 GPU 메모리에 저장된다.
실행 순서는 다음과 같다.
- 레이어 N 실행 시작 → 레이어 N KV 캐시를 원격 GPU에서 NVLink로 가져온다.
- 레이어 N 어텐션 연산 완료 → 결과 KV를 다시 원격 GPU에 저장한다.
- 레이어 N+1로 이동 → 같은 과정 반복.
이 방식은 HBM 소비량을 단일 레이어 KV 크기로 제한한다. 전체 레이어 KV 캐시를 보유할 필요가 없어 최대 컨텍스트 길이가 크게 늘어난다.
3. Elastic Cache
기증 GPU의 수요가 늘어나면 이전에 기증한 공간을 회수해야 한다. Elastic Cache는 공유 공간을 동적으로 조정한다.
- 저수요 상태 → 유휴 HBM을 추가로 기증
- 고수요 상태 → 기증 공간을 단계적으로 회수
- 회수 시 → 해당 블록의 KV 캐시는 CPU로 이전하거나 재계산
성능 결과
실험 환경: 단일 멀티-GPU 서버, 이종 모델 공존 환경.
| 지표 | SwiftCache | 비고 |
|---|---|---|
| P99 TTFT | 최대 69% 감소 | 베이스라인 대비 |
| 최대 컨텍스트 길이 | 최대 3.98배 확장 | HBM 단일 레이어 사용으로 가능 |
| 공존 모델 간섭 | 소폭(modest) | 기증 GPU 성능 영향 제한적 |
PCIe 오프로드 대비 NVLink 전송은 대역폭 차이(~37배)만큼 재로드 지연이 줄었다. Layer Stream Cache는 HBM 사용량을 단일 레이어 수준으로 줄여 컨텍스트 확장에 결정적으로 기여했다.
운영 시 고려사항
적용 조건
- NVLink 연결 멀티-GPU 서버: 다른 서버의 GPU는 NVLink로 직접 연결되지 않으므로 이 구조가 적용되지 않는다. PCIe로만 연결된 GPU 환경에서는 이점이 대폭 줄어든다.
- 이종 모델 공존: 수요 패턴이 다른 여러 모델이 같은 서버에 공존해야 기증·수혜 관계가 성립한다. 단일 모델만 올리는 서버에는 효과가 없다.
- 긴 멀티턴 대화: 싱글 턴이나 짧은 컨텍스트 워크로드는 오프로드 필요 자체가 작아 효과가 제한적이다.
주의사항
| 항목 | 내용 |
|---|---|
| 기증 풀 회수 지연 | 저수요 모델 수요가 급증하면 기증 회수가 KV 캐시 중단으로 이어질 수 있다. Elastic 정책 파라미터 조정이 필요하다. |
| 레이어 통신 오버헤드 | Layer Stream Cache는 레이어마다 NVLink 왕복이 발생한다. 레이어 수가 많은 대형 모델(70B+)에서는 통신 빈도도 증가한다. |
| 동기화 복잡도 | 여러 모델이 공유 메모리 풀을 동시에 읽고 쓰면 메모리 관리가 복잡해진다. 세밀한 잠금 메커니즘이 필요하다. |
| NVLink 토폴로지 의존성 | NVSwitch 기반 풀-메시(full-mesh) 구성이 최적이다. 링(ring) 토폴로지에서는 GPU 간 홉 수에 따라 대역폭이 달라진다. |
다른 접근법과 비교
| 방식 | 전송 매체 | 특징 | SwiftCache 대비 |
|---|---|---|---|
| CPU 오프로드 | PCIe (~16 GB/s) | 구현 단순 | 재로드 약 37배 느림 |
| SSD 오프로드 | NVMe (~7 GB/s) | 더 큰 용량 | 재로드 약 85배 느림 |
| PagedAttention | 로컬 HBM | 단편화 최소화 | HBM 상한 해결 못함 |
| SwiftCache | NVLink (~600 GB/s) | 이종 GPU 협력 | 최저 재로드 지연 |
요점 정리
- 멀티턴 대화에서 KV 캐시 오프로드의 핵심 병목은 PCIe 대역폭이다.
- SwiftCache는 같은 서버의 저수요 모델 GPU 메모리를 NVLink로 빌려 이 병목을 우회한다.
- Layer Stream Cache는 현재 레이어의 KV 캐시만 로컬 HBM에 유지해 HBM 소비를 최소화하고 최대 컨텍스트 길이를 최대 4배 늘린다.
- P99 TTFT 최대 69% 감소, 최대 컨텍스트 3.98배 확장이 이종 GPU 공존 환경에서 검증됐다.
- NVLink 연결 멀티-GPU 서버와 이종 모델 공존이 적용의 전제 조건이다.
References
- SwiftCache 논문 (arXiv:2606.16135, June 2026): <https://arxiv.org/abs/2606.16135>
- HyMCache: CXL 하이브리드 메모리 KV 캐시 (arXiv:2607.18141): <https://arxiv.org/abs/2607.18141>
- ACL 2026 KV 캐시 최적화 서베이: <https://github.com/jjiantong/Awesome-KV-Cache-Optimization>
- vLLM PagedAttention 문서: <https://docs.vllm.ai/en/latest/design/v1/prefix_caching.html>
- NVIDIA NVLink 기술 개요: <https://www.nvidia.com/en-us/data-center/nvlink/>