본문으로 건너뛰기

goal

우리 회사 입장에서 보면​

우리 = Storage 회사
      └── NVMe SSD (FDP/HC-SSD) 만드는 곳
      
LMCache = AI 추론의 KV Cache를 Storage에 내려보내는 SW 레이어

접점 = LMCache가 우리 SSD를 얼마나 잘 쓸 수 있느냐

즉 우리 입장에서 LMCache는 "우리 제품을 AI 인프라에 연결해주는 핵심 SW 레이어" 야.

그래서 우리가 할 수 있는 것들을 다시 보면​

단기 (검증)

  • LMCache + FDP/HC-SSD 조합이 실제로 얼마나 좋은지 수치로 증명
  • "우리 SSD 쓰면 TTFT 얼마나 줄어드는지" → 고객 설득 자료가 돼

중기 (최적화)

  • Storage Stack 튜닝 가이드 도출
  • "우리 SSD랑 LMCache를 같이 쓸 때 이렇게 설정하면 최적" 이라는 레퍼런스

장기 (기여)

  • LMCache에 FDP/HC-SSD Backend 직접 구현해서 upstream 기여
  • io_uring 지원 추가
  • raw block 성능 개선
  • "LMCache 공식 문서에 우리 SSD가 레퍼런스로 올라가는 것" 이 최종 그림

포지션 재정의​

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

그러면 우리 업무 핵심이 더 선명해져​

단순히 "FDP 쓰면 빨라요" 검증이 아니라:

① LMCache I/O 경로 분석

LMCache가 Storage Stack을 어떻게 타고 내려오는지 끝까지 추적 (LMCache → FS → Block Layer → NVMe Driver → SSD)

② Storage Stack 각 레이어 최적화

io_uring 도입, IO scheduler 튜닝, block alignment 등 이게 진짜 System SW 업무야

③ FDP/HC-SSD와 연결

우리 HW팀이 만든 SSD를 최대한 잘 쓸 수 있도록 SW 레이어에서 인터페이스 설계

④ LMCache Backend 기여

우리가 설계한 최적 I/O 경로를 LMCache에 직접 구현 FDP Backend, io_uring 지원 등