본문으로 건너뛰기

TTFT / ITL — LLM 추론 핵심 지표

[!tldr] 업무 관점 takeaway 우리 미션의 최종 성과 지표. WAF/p99 latency 같은 SSD-level 지표가 얼마나 사용자 체감 응답속도까지 전달되는지 를 측정하는 데 TTFT/ITL이 쓰인다. FDP가 SSD p99 read를 줄이면 → LMCache warm load 시간이 줄어들고 → 결과적으로 warm TTFT가 줄어든다. 이 인과 체인이 우리 실험 가설.

정의​

지표의미사용자 체감
TTFT (Time to First Token)요청 시작부터 첫 토큰이 나올 때까지 시간"응답이 시작된다" — 첫 인상
ITL (Inter-Token Latency)토큰과 토큰 사이 간격"응답이 흐른다" — 읽는 속도

둘 다 낮을수록 빠른 응답.

TTFT 분해 — Cold vs Warm​

Cold TTFT (캐시 없음):
  요청 → Prefill (전체 토큰 attention 계산) → 첫 토큰

Warm TTFT (캐시 있음 — LMCache hit):
  요청 → KV Cache load (SSD → CPU → GPU) → 첫 토큰
              ↑
        이게 [[LMCache-Local-Disk-Backend|NVMe read]]

실측 (LMCache 문서, 15,376 토큰 프롬프트):

  • Cold TTFT: 6.314초
  • Warm TTFT: 0.148초
  • 42.6× 차이

[!important] Warm TTFT를 더 줄일 수 있나? — 우리 핵심 질문 0.148초 안에서 NVMe read 시간이 차지하는 비중이 우리 개선 여지. [[NVMe-FDP|FDP]]로 read p99 안정화하면 warm TTFT가 더 낮아진다는 가설을 측정으로 입증해야 한다.

SSD-level 지표 → 사용자-level 지표 인과 체인​

SSD WAF ↓
   │
   ▼
SSD p99 write latency ↓ + SSD GC interference ↓
   │
   ▼
LMCache disk write throughput ↑ + read p99 ↓
   │
   ▼
KV Cache offload backlog ↓ → CPU에 더 빨리 자리 비움
KV Cache load latency ↓ → warm TTFT ↓
   │
   ▼
사용자 체감 응답속도 ↑

각 단계마다 측정 가능한 지표가 있다 → 어디서 인과 사슬이 끊기는지 확인하는 게 [[단기-Task-목록|Task 1 latency histogram]]의 목적.

측정 방법​

  • LMCache Metrics / Observability: TTFT, throughput
  • vLLM Logs: TTFT 분포
  • SSD-level: nvme fdp stats /dev/nvmeX ([[WAF]] 측정)
  • OS-level: iostat, blktrace, bpftrace

의외의 연결​

[!note] LMCache async batching이 ITL에 미치는 영향 [[LMCache-Async-Loading|I/O-Compute Overlap]]은 prefill 단계뿐 아니라 decode 도중에도 prefetch로 다음 KV를 미리 준비 → ITL의 long tail 완화. 즉 FDP의 read p99 안정화는 TTFT뿐 아니라 ITL tail에도 효과.

관련 페이지​

  • [[Mission]] — 미션의 최종 KPI
  • [[KV-Cache]] — TTFT 단축의 핵심 메커니즘
  • [[LMCache-Local-Disk-Backend]] — warm TTFT 안의 NVMe read 시간
  • [[WAF]] — TTFT 인과 체인의 SSD-level 시작점
  • [[단기-Task-목록]] — Task 1이 이 인과 체인을 데이터로 추적 가능하게 만듦