본문으로 건너뛰기

LMCache Disk TCO Analysis: HC SSD vs 표준 SSD (한국어 번역본)

원문: private/raw/LMCache Disk TCO Analysis 적용 대상: 로컬 SSD/NVMe를 KV 캐시 티어로 사용하는 LMCache 배포 환경

1. 목표​

LMCache 디스크 티어에 고용량 SSD(HC SSD) 와 표준 SSD(Std SSD) 중 어떤 것을 사용할지 결정한다. 비교 기준은 두 가지다:

  1. 전체 디스크 비용: 용량 + 전력 + 내구성에 따른 교체 비용
  2. 캐시 히트로 창출되는 가치: 절감된 GPU 연산 시간 / 불필요해진 GPU 대수

단, LMCache의 디스크 읽기는 크리티컬 패스(critical path) 에 위치하므로 SLO 안전성을 반드시 확보해야 한다.

핵심: LMCache의 디스크/원격 백엔드는 쓰기는 비동기로 처리하지만 읽기(get)는 블로킹 방식이다. 따라서 디스크 읽기 지연시간이 TTFT(Time To First Token) 및 테일 레이턴시에 직접 영향을 준다. [2]

2. 비교 대상 스토리지 옵션​

2.1 정의​

옵션설명
Option A — HC SSD (고용량 SSD)소수의 초대용량 드라이브(예: 드라이브당 15TB~30TB 이상). $/TB 및 밀도 최적화
Option B — Std SSD (표준 SSD)일반 엔터프라이즈 용량(예: 3.84TB~7.68TB)의 드라이브를 더 많이 사용. GPU 노드 기본 NVMe로 널리 사용됨

2.2 LMCache에서 이 비교가 중요한 이유​

LMCache는 GPU → CPU → 로컬 스토리지/원격 계층형 KV 캐시로 추론을 확장한다. 디스크는 일반적으로 프리픽스/KV 재사용을 위한 대용량 티어다. [1]

HC vs Std SSD 비교 시 평가해야 할 항목:

  • 용량 경제성: $/TB, 드라이브 수, 슬롯(베이) 수
  • 내구성 경제성: DWPD/TBW → 교체 횟수
  • 성능 리스크: 블로킹 get() → TTFT 테일 레이턴시 [2]

3. 측정해야 할 항목​

3.1 LMCache 메트릭 (Prometheus)​

LMCache는 vLLM /metrics 또는 LMCache 내부 API 서버를 통해 메트릭을 노출한다. [3][6]

TCO 계산에 사용할 메트릭:

카테고리메트릭
히트/미스 및 볼륨lmcache:num_requested_tokens
lmcache:num_hit_tokens
lmcache:num_stored_tokens
디스크 사용량lmcache:local_storage_usage
조회/저장 성능lmcache:time_to_retrieve, lmcache:retrieve_speed
lmcache:time_to_store, lmcache:store_speed

3.2 GPU 성능 및 비용 입력값 (LMCache 외부)​

필요한 값:

  • GPU 또는 노드의 시간당 비용 (fully loaded, $/hour)
  • 모델 병렬 구성에서의 프리필 처리량 (tokens/sec)
  • SLO 목표 (TTFT p95/p99, 엔드-투-엔드 레이턴시, 처리량)

3.3 디스크 텔레메트리 (SSD 비교에 필수)​

SSD 옵션별로 수집:

  • 부하 상황에서의 p95/p99 읽기 지연시간
  • 읽기/쓰기 처리량 (MB/s) 및 IOPS
  • NVMe SMART: Data Units Written
  • 드라이브당 전력 소비 (실측 또는 추정치)

4. 실험 설계 (HC SSD vs Std SSD)​

두 가지 조건에서 동일한 실험을 수행한다:

A) HC SSD 실험

  • 동일한 모델, 동일한 vLLM 설정, 동일한 LMCache 설정 (tensormesh 워크로드 A 기준)
  • 변경점: 디스크 타입만 다름

B) Std SSD 실험

  • A와 동일한 모든 설정

고정 유지 항목:

  • LMCache 청크 크기, 에빅션 정책, O_DIRECT 설정, CPU 티어 설정
  • 워크로드 트래픽 믹스 (프롬프트 크기, 재사용 패턴, 동시성)
  • SLO 기준

기록 항목:

  • 시간에 따른 히트율 (토큰 단위)
  • local_storage_usage 정상 상태(steady-state) 동작
  • TTFT p95/p99 및 엔드-투-엔드 p95/p99
  • 디스크 읽기 지연시간 p95/p99 및 큐 깊이(queue depth) 동작

5. 토큰 ↔ 디스크 용량 변환​

토큰 수를 KV 바이트로 변환하려면 사용 중인 모델의 LMCache FAQ 표를 참조한다. [5]

kv_GB_per_1000       = 1000 토큰당 KV 캐시 크기 (GB, FAQ 참조)
stored_tokens_per_day = lmcache:num_stored_tokens 레이트로 측정

GB_written_per_day ≈ (stored_tokens_per_day / 1000) × kv_GB_per_1000 × write_amp

write_amp는 파일시스템 오버헤드를 반영하는 쓰기 증폭 계수다.

6. 두 옵션 TCO 모델 (HC vs Std)​

각 옵션 i ∈ {HC, Std} 에 대해 아래 항목을 계산한다.

6.1 필요 디스크 용량 산출​

DiskBytes_required ≈ p95(lmcache:local_storage_usage)

6.2 드라이브 수 및 초기 비용(CapEx)​

drives_i     = ceil(DiskBytes_required / drive_capacity_bytes_i)
CapEx_i      = drives_i × unit_price_i

HC SSD는 드라이브 수를 줄일 수 있지만, 스트라이핑 없이는 집계 병렬 IOPS가 떨어질 수 있다.

6.3 전력 운영 비용(OpEx)​

OpEx_power_i = (drives_i × power_W_i / 1000) × 24 × 365 × Years × PUE × $/kWh

6.4 내구성 및 교체 비용 (DWPD/TBW 기반)​

데이터시트의 DWPD(N년 기준, 보통 5년) 또는 TBW를 입력값으로 사용한다.

TB_written_per_day   = GB_written_per_day / 1000
DWPD_required_i      = TB_written_per_day / drive_capacity_TB_i

# 수명 추정 (데이터시트에 rated_years 기준 DWPD_rated가 있을 때)
life_years_i         ≈ rated_years × (DWPD_rated_i / DWPD_required_i)

# 교체 횟수 및 비용
replacement_count_i  = max(0, ceil(Years / life_years_i) - 1)
ReplacementCost_i    = replacement_count_i × drives_i × unit_price_i

Std SSD가 유리한 이유: Std SSD는 일반적으로 DWPD가 더 높아, 데이터 변동이 많거나 24×7 고부하 환경에서 유리하다.

6.5 총 디스크 TCO​

TCO_i = CapEx_i + OpEx_power_i + ReplacementCost_i

보고 단위: $/TB-년 및 3년 총 TCO

7. 이득 모델 (두 SSD 옵션 공통)​

디스크는 추가 비용보다 더 많은 GPU 비용을 절감할 때 투자 가치가 있다.

7.1 GPU 연산 절감 단가​

cost_per_prefill_token  = (C_gpu_group / 3600) / TPS_prefill
savings_per_hit_token   ≈ cost_per_prefill_token × (1 - 1/r)
savings_per_hour        = hit_tokens_per_sec × 3600 × savings_per_hit_token
  • C_gpu_group: 풀 모델-패러렐 GPU 그룹의 시간당 비용 ($/hour)
  • TPS_prefill: 프리필 처리량 (tokens/sec, 실측)
  • r: 캐시 히트 경로 vs 재계산 경로의 상대 속도 향상비 (가능하면 실측)
  • hit_tokens_per_sec: rate(lmcache:num_hit_tokens[window]) [3]

7.2 손익분기점 확인​

disk_cost_per_hour_i = TCO_i / (Years × 365 × 24)
손익분기 조건: savings_per_hour ≥ disk_cost_per_hour_i

8. 성능 게이팅 (TCO에서 이겨도 SLO에서 지면 안 됨)​

디스크 get()이 블로킹 방식이므로, 선택한 SSD 옵션은 반드시 테일 레이턴시 기준을 통과해야 한다. [2]

최소 권장 게이팅 조건:

  • TTFT p95/p99가 SLO 예산을 초과하여 회귀하지 않을 것
  • time_to_retrieve p95/p99가 피크 QPS 하에서 안정적으로 유지될 것 [3]

HC vs Std 미묘한 차이: Std SSD는 드라이브 수가 많아 집계 랜덤 읽기 병렬성이 더 높을 수 있다. HC SSD로 드라이브 수가 너무 줄면 스트라이핑이나 추가 드라이브가 필요해지고, 이는 $/TB 계산을 바꾼다.

9. 의사결정 가이드라인​

HC SSD를 선택할 때 (아래 조건 대부분 해당 시)​

  • 워크로드의 재사용률이 높다 (히트 토큰 / 요청 토큰 비율이 높음)
  • DWPD_required가 rated 내구성 대비 충분히 낮다 (예: DWPD_rated의 50% 미만)
  • TTFT 테일 목표를 HC 옵션으로 달성 가능하다
  • 드라이브 수 감소로 노드 비용/복잡도가 실질적으로 줄어든다

Std SSD를 선택할 때 (아래 조건 중 하나라도 해당 시)​

  • 데이터 변동이 많다 (재사용률 낮음, stored_tokens/day 높음)
  • 내구성이 병목이다 (DWPD_required가 DWPD_rated에 근접)
  • TTFT 테일이 촉박하고 조회 지연시간이 민감하다
  • IOPS/레이턴시 목표를 위해 어차피 더 많은 드라이브가 필요하다

10. 보고 템플릿 (나란히 비교)​

항목HC SSDStd SSD
드라이브 용량 (TB)
단가 ($)
필요 드라이브 수
rated DWPD (및 기준 연수)
실측 p95 랜덤 읽기 지연시간
실측 p95/p99 time_to_retrieve
저장 토큰 수/일
추정 쓰기량 (TB/일)
필요 DWPD
예상 수명 (년)
교체 횟수 (3년)
3년 총 TCO ($)
히트 절감액 (3년 $)
ROI

참고 문헌​

번호내용
[1]LMCache Architecture Overview
[2]LMCache Local storage backend
[3]LMCache Metrics Reference
[4]LMCache Chunk Statistics
[5]LMCache FAQ (KV size per 1000 tokens)
[6]LMCache Internal API Server