LMCache 개요

[!tldr] 업무 관점 takeaway LMCache는 우리 NVMe SSD를 AI 인프라에 연결해주는 SW 레이어 그 자체다. KV Cache를 GPU 밖으로 빼내 CPU/SSD/원격에 계층 저장하는 오픈소스 KV Cache 매니저로, vLLM·SGLang·NVIDIA Dynamo 등에 채택됐다. 핵심은 (1) 256-token chunk 단위 batched I/O로 PCIe 대역폭 활용, (2) 표준 커넥터로 엔진 독립성, (3) Lookup/Move/Pin 등 first-class API. 우리가 손댈 곳은 (1)의 SSD 끝단.

한 줄 정의

LLM 추론의 KV Cache를 GPU 메모리 밖(CPU DRAM, Local SSD, Remote)에 효율적으로 저장·재사용하는 오픈소스 캐시 레이어. 논문: arXiv:2510.09665 (An Efficient KV Cache Layer for Enterprise-Scale LLM Inference).

Motivation — 왜 필요한가?

KV Cache 폭증: 5주 만에 GPU 메모리 초과 KV Cache가 5.57배 증가 (LMCache 논문 실측)
재사용 증가: 전체 사용자 19% 이상이 토큰을 1.5회 이상 재사용
⇒ GPU 밖에서 KV Cache를 빠르고 똑똑하게 관리하는 시스템이 필수

자세한 배경은 [[KV-Cache]] 페이지.

기존 방식의 3가지 한계 (LMCache가 푸는 문제)

① I/O 비효율

엔진들은 KV Cache를 [[vLLM-PagedAttention|16~64KB 작은 페이지]] 단위로 관리. 하나씩 전송하면 PCIe 대역폭 낭비:

64KB 전송  →   4 GB/s
1MB  전송  →  30 GB/s
16MB 전송  →  49 GB/s   (묶음만으로 12배 차이)

② 호환성

2025년 기준 평균 4일마다 새 AI 모델 출시. 매번 KV Cache 인터페이스가 바뀜.

③ 관리 도구 부재

캐시 pin/move/compress 통합 API가 없어 라우터 등 상위 시스템이 캐시를 인식 못함.

LMCache의 3가지 핵심 기여

기여 1 — 고성능 데이터 이동 (우리가 가장 주목할 부분)

256 토큰 단위 chunk로 묶어서 전송. 3가지 기법으로 메모리/대역폭 효율 극대화:

Batched Operation: page-by-page 전송 대신 chunk gather/scatter
Zero-copy: shared buffer + 참조 카운터 / dynamic offloading (start/current/end 포인터)
Pipelining: compute stream과 transfer stream을 다른 CUDA stream으로 동시 실행

결과: LMCache CPU 대역폭 400 Gbps vs vLLM 기본 88 Gbps → 4.5배

[!note] 의외의 연결: chunk 단위가 SSD I/O 단위를 결정한다 256 토큰 chunk는 모델에 따라 수십~수백 MB (Llama-3.1-8B 기준 ≈134MB). small file이 아니라 medium-large file. 그래서 SSD에서 보는 I/O 패턴은 "많은 medium file의 random write"이고, 이게 [[WAF]] 증가의 직접 원인이다. → [[기여-포인트-맵|기여 포인트 [3]·[9]]]

기여 2 — 표준 커넥터 인터페이스

AI 엔진과 LMCache를 분리(Decouple). 엔진이 바뀌어도 커넥터만 교체. 채택 사례: NVIDIA Dynamo, RedHat llm-d, ByteDance AIBrix.

기여 3 — 유연한 KV Cache 관리 API

KV Cache를 first-class 데이터로 취급. 중앙 컨트롤러 + 인스턴스 워커 2계층:

API	역할	실제 사례
lookup	캐시 위치 전역 조회	스마트 라우팅
move	인스턴스 간 이동	서버 축소 시 마이그레이션
pin / unpin	캐시 고정	금융사 주요 문서 고정
compress	캐시 압축	저장 공간 절약
batched_p2p_lookup	P2P 캐시 탐색	다른 인스턴스에서 직접 가져오기

평가 결과 요약 (논문)

실험	결과
GPU만 vs GPU+CPU 오프로딩	TTFT 1.9–8.1× ↓, 처리량 2.3–14× ↑
실제 기업 트래픽	TTFT 3.7–6.8× ↓, [[TTFT-ITL\|ITL]] 19–58% ↓
원격 중앙 서버	처리량 1.3–3× ↑ (긴 입력일수록 유리)
[[PD-Disaggregation\|PD 분리]]	TTFT 1.53–1.84× ↓ — page vs chunk 차이

한계 & 미해결 과제 (논문이 인정한 부분)

원격 vs 재계산 자동 판단 부재: 느린 네트워크 + 짧은 입력에선 새 계산이 빠를 수 있음
컨텍스트 자르기 부작용: 슬라이딩 윈도우로 입력 자르면 히트율 85% → 45%
SGLang에서 우위 약화: vLLM 대비 차별성이 SGLang에서는 자체 CPU 오프로딩 수준
Python 성능 한계: 빠른 개발/커뮤니티 vs Rust/C++ 런타임 성능

우리 미션의 시작점

검증 대상: [[LMCache-Local-Disk-Backend]] — 여기가 NVMe와 만나는 지점
측정 대상 지표: [[TTFT-ITL]], [[WAF]], throughput
코드 분석 우선순위: Storage Plugins → GDS Backend → Caching Policies → Performance Tuning

한 줄 정의​

Motivation — 왜 필요한가?​

기존 방식의 3가지 한계 (LMCache가 푸는 문제)​

① I/O 비효율​

② 호환성​

③ 관리 도구 부재​

LMCache의 3가지 핵심 기여​

기여 1 — 고성능 데이터 이동 (우리가 가장 주목할 부분)​

기여 2 — 표준 커넥터 인터페이스​

기여 3 — 유연한 KV Cache 관리 API​

평가 결과 요약 (논문)​

한계 & 미해결 과제 (논문이 인정한 부분)​

우리 미션의 시작점​

관련 페이지​