LMCache 아키텍처
[!tldr] 업무 관점 takeaway 우리가 FDP/HC-SSD를 붙일 자리는 Local Storage 티어 (NVMe), 더 정확히는 Async Offloading이 LRU eviction으로 CPU → 디스크 write를 던지는 순간이다. 다른 컴포넌트는 그 write가 일어나는 맥락만 제공한다. 4티어 / 2모드 / 5컴포넌트 구조 중 우리에게 결정적인 건 Local Storage 티어와 Async Offloading 컴포넌트 두 가지.
4-Tier 멀티 스토리지
| 계층 | 역할 | 특징 |
|---|---|---|
| GPU Memory | 현재 추론에 사용 중인 KV Cache의 Active Working Set | 가장 빠름, 용량 제한 |
| CPU DRAM | 최근 사용 KV Cache의 Hot Cache | Pinned Memory로 GPU↔CPU 전송 최적화 |
| Local Storage | 대용량 KV Cache 저장 (NVMe) | ← FDP/HC-SSD 적용 대상 |
| Remote Storage | 영속 KV Cache (Redis, Mooncake 등) | 신뢰성 ↑, 속도 ↓ |
데이터 흐름
GPU memory
│ (offload, GPU 메모리 확보)
▼
CPU DRAM (Pinned)
│ (LRU eviction → 비동기 write) ← 여기서 NVMe write 발생!
▼
Local Storage (NVMe) ──┐
│ (prefetch ↑) │
▼ ▼
재사용 시 CPU → GPU 복원 Remote Storage
NVMe I/O가 발생하는 두 지점은:
- CPU → Disk 비동기 write (LRU evict): burst pattern → [[WAF]] 증가 주범
- Disk → CPU prefetch read: blocking → [[TTFT-ITL|TTFT]]에 직접 영향
2-Mode 운영
Mode 1: Storage Mode (KV Cache Offloading) — 우리 주력
LMCache를 영속적인 KV 저장소처럼 운영. 세션 간 KV Cache 재사용.
1. GPU에서 새 KV 청크 생성
2. CPU 버퍼로 복사
3. 디스크 write 태스크 + 원격 업로드 태스크를 비동기로 실행
4. 추론 스레드는 블로킹 없이 계속
[!note] 우리 업무 관점 async write가 burst로 쏟아짐 → SSD 입장에서 write 집중 패턴 → [[Garbage-Collection]] 폭주 가능 → FDP로 스트림 분리하면 효과 큼.
Mode 2: Transport Mode (PD Disaggregation)
[[PD-Disaggregation|Prefill ↔ Decode]] 분리 환경에서 노드 간 KV Cache 실시간 전송. NIXL 같은 P2P 라이브러리 사용. FDP 직접 적용 포인트 적음 (네트워크 중심).
| Storage Mode | Transport Mode | |
|---|---|---|
| 목적 | KV 재사용 (세션 간) | 노드 간 KV 전송 (실시간) |
| 주요 I/O | 디스크 R/W | 네트워크 |
| FDP 연관 | 핵심 타겟 | 부분적 |
5개 핵심 컴포넌트
| 컴포넌트 | 한 줄 요약 | FDP 관련성 |
|---|---|---|
| Connector | vLLM ↔ LMCache 문지기. Cache hit이면 가져오고 miss면 신규 저장 트리거 | 낮음 |
| Cache Index | 토큰 시퀀스 → KV 위치 매핑. 기본 청크 256 토큰, 해시 조회 | 높음 (I/O 단위 결정) |
| Memory Object & Allocator | CPU DRAM KV 관리. Pinned Memory, NUMA-aware, LRU eviction | 높음 (eviction = NVMe write 트리거) |
| Async Offloading | KV offload/load를 비동기로 처리. 추론 스레드 블로킹 방지 | 높음 (burst write 패턴) |
| Remote Connectors | Redis/Mooncake/NIXL 플러그인 시스템 | 중간 (FDP backend도 플러그인으로 추가 가능) |
[!note] 의외의 연결 Cache Index의 256-token chunk 단위가 곧 NVMe write 사이즈 = FDP의 RU(Reclaim Unit) 정렬 대상이 된다. AI 모델의 hidden dim이 결국 SSD의 erase unit 크기에 영향을 주는 셈. ([[기여-포인트-맵|기여 포인트 [3]]])
자세한 배경: [[LMCache-Local-Disk-Backend]], [[LMCache-Async-Loading]]
LMCache Controller (운영 API)
런타임에 KV Cache를 중앙 관리하는 API. 단일 인스턴스/분산 모두 지원.
| API | 우리 실험에서의 활용 |
|---|---|
| Lookup | "이 KV가 어느 티어에 있는가" — 실험 변수 확인 |
| Clear | FDP ON/OFF 비교 전 캐시 초기화 |
| Compress/Decompress | I/O 크기 축소 효과 vs FDP 효과 분리 측정 |
| Move | 캐시를 강제로 NVMe로 내려 read 성능 측정 시나리오 |
| Pin/Unpin | 실험 변수 통제 (특정 KV가 evict 안 되게) |
| Health Check | async write 완료 확인 → 벤치 타이밍 |
전체 한 장 다이어그램
[vLLM] ←Connector→ [LMCache]
│
Cache Index (256 토큰)
│
┌──────────────┼──────────────┐
GPU Mem CPU DRAM NVMe / Remote
│
Async Offloading
(LRU evict) ← NVMe write 발생 지점
│
Controller
(Lookup/Clear/Move...)
FDP/HC-SSD 적용 관점에서의 시사점
| 관점 | 분석 |
|---|---|
| I/O 패턴 | 256-token chunk 단위 W/R → FDP RU 정렬 검토 필요 |
| Write 특성 | async burst write → FDP 스트림 분리 효과 극대화 기대 |
| Read 특성 | LRU evict 후 prefetch → 랜덤 read 가능성. [[GPU-Direct-Storage |
| GDS Backend | LMCache 공식 지원 — Direct I/O 레퍼런스로 참고 가치 |
| 검증 포인트 | Storage Mode + NVMe Backend에서 FDP ON/OFF 비교 — [[WAF]], p99 latency, throughput, [[TTFT-ITL |
관련 페이지
- [[LMCache-개요]] — 상위 페이지
- [[LMCache-Local-Disk-Backend]] — Local Storage 티어 깊게
- [[LMCache-Async-Loading]] — Async Offloading 깊게
- [[KV-Cache]] — 다루는 데이터
- [[vLLM-PagedAttention]] — 입력 데이터의 페이지 구조