Mission — NVMe SSD × LMCache 최적화

[!tldr] 업무 관점 takeaway 이 위키 전체의 좌표축. "Storage 회사의 System SW 엔지니어가 LMCache를 통해 자사 NVMe SSD(Std·HC)를 AI 인프라 1티어 옵션으로 만든다"가 모든 페이지가 봉사해야 할 단일 목표다. FDP는 NVMe 스펙 — Std SSD와 HC SSD 양쪽에 적용된다. HC SSD(15~~30TB, QLC)가 핵심 타겟이며, Std SSD(1.92~~7.68TB)도 포함된다. HC SSD에서 WAF 민감도가 높아 FDP 효과가 더 두드러진다. 모든 위키 페이지는 이 미션을 기준으로 왜 중요한지 가 명확해야 한다.

한 문장 정의

LMCache의 raw block backend를 개선하고, 자사 NVMe SSD(Std·HC)에 FDP(NVMe 스펙)를 적용하여 WAF·TTFT·처리량이 유의미하게 개선됨을 실험적으로 검증하고, 그 결과를 LMCache upstream에 기여한다.

3대 방향

Direction 1: 검증
  자사 SSD(Std/HC)가 LMCache 성능에 실제로 도움이 되는가?
  → WAF, p99 latency, TTFT, 처리량 측정

Direction 2: 최적화
  LMCache의 I/O 패턴을 분석해 Storage Stack 각 레이어 튜닝
  → FS 선택, IO scheduler, chunk size, O_DIRECT, io_uring

Direction 3: 기여 (Contribution)
  ① raw block backend 자체 개선 (안정성·성능·운영성) → upstream PR
  ② FDP/io_uring Backend 구현 → upstream PR 또는 내부 솔루션

세 방향은 시간순(단기 → 중기 → 장기)으로 진화한다. Direction 3-①이 현재 가장 활발.

회사 포지셔닝

우리 회사 = Storage 회사
              │
              ├── HW팀 → NVMe SSD (Std/HC, FDP 지원)
              │
              └── SW팀 (우리!) → Storage System SW
                    ├── Storage Stack 최적화
                    ├── Driver / Firmware 인터페이스
                    ├── io_uring 같은 커널 레벨 I/O
                    └── LMCache 같은 AI SW와의 연동

LMCache는 "자사 SSD를 AI 인프라에 연결해주는 핵심 SW 레이어". 우리 SW팀의 역할은 그 연결 지점에서 양쪽을 가장 잘 아는 사람이 되는 것이다.

핵심 가설 (검증 대상)

WAF 가설 — LMCache의 KV Cache 워크로드는 Meta CacheLib와 패턴이 유사하므로, FDP 적용 시 WAF 3.x → ~1.0 효과를 재현할 수 있다. ([[CacheLib-FDP-사례]] 참조)
SSD 타겟 가설 — Std SSD(1.92~~7.68TB)는 즉시 활용 가능한 현실적 1차 타겟. HC-SSD(15~~30TB)는 QLC 특성상 WAF 민감도가 더 크고 FDP 효과가 TLC보다 두드러지는 확장 타겟. ([[HC-SSD]] 참조)
레이턴시 가설 — WAF 감소 → SSD 쓰기 tail latency 감소 → LMCache write throughput 향상 → 결과적으로 TTFT 단축.
raw block 개선 가설 — checkpoint overflow(S2), FIFO wear leveling(H2), O(1) slot 관리(H1) 등 현재 raw block backend의 correctness·성능 버그를 먼저 고치면, 이후 FDP/io_uring 기능 추가의 신뢰성 기반이 생긴다.

핵심 의외의 연결

[!note] FDP RUH ↔ LMCache LRU bucket 둘 다 본질은 "수명별 데이터 그룹화" 다. LMCache가 hot/cold를 분리하는 정책(LRU/LFU)을 FDP RUH 매핑으로 직접 옮기면 양쪽 그룹화가 한 번에 일치한다. ([[NVMe-FDP]], [[LMCache-Local-Disk-Backend]])

[!note] io_uring ↔ LMCache LocalDiskWorker LMCache는 현재 스레드 풀로 비동기를 흉내내는 구조다. 진짜 async I/O인 io_uring으로 바꾸면 스레드 컨텍스트 스위칭이 사라지고, 추가로 FDP placement hint도 그 경로로 전달된다. 하나의 변경으로 두 마리 토끼. ([[io_uring]], [[LMCache-Async-Loading]])

[!note] 256-token chunk ↔ NVMe optimal I/O size LMCache 기본 청크 256토큰 × 2(K,V) × 32 layers × 32 heads × 128 head_dim × 2bytes ≈ 134MB (Llama-3.1-8B 기준). small file이 아니다. chunk size와 NVMe stripe/RU 정렬을 맞추는 게 의외로 큰 최적화 포인트. ([[LMCache-Local-Disk-Backend]])

단기·중기·장기 액션

단기: raw block backend 개선 PR(H1/H2/S2/M1/M2) + L2 latency 가시성 추가 — [[raw_block-개선-Task]], [[단기-Task-목록]]
중기: Storage Stack 튜닝 가이드 도출 (FS, scheduler, alignment) + L2 health check — [[Storage-Stack]], [[기여-포인트-맵]]
장기: FDP Backend 구현, io_uring 도입, Std/HC SSD 성능 검증 → upstream PR — [[기여-포인트-맵]]

한 문장 정의​

3대 방향​

회사 포지셔닝​

핵심 가설 (검증 대상)​

핵심 의외의 연결​

단기·중기·장기 액션​

관련 페이지​

한 문장 정의

3대 방향

회사 포지셔닝

핵심 가설 (검증 대상)

핵심 의외의 연결

단기·중기·장기 액션

관련 페이지