1. 개요
TTFT(Time To First Token)는 LLM 에 요청을 보낸 뒤 첫 토큰이 도착할 때까지 걸린 시간이다. 한국어로는 흔히 ‘첫 토큰 시간’이라고 부른다.
채팅 서비스에서 질문을 보내고 답의 첫 글자가 뜨기까지 멍하니 기다리는 그 시간이 TTFT 다. LLM 은 답을 한 번에 주지 않고 토큰을 하나씩 흘려보내기(스트리밍) 때문에, 사용자가 받는 “느리다"는 첫인상은 대부분 TTFT 에서 정해진다.1
2. 구성
TTFT 는 '언제 나오기 시작하나', ITL 은 '얼마나 빨리 나오나', E2E 는 '언제 끝나나'
TTFT 는 크게 두 구간의 합이다.
2.1. 대기 시간
서버가 이미 다른 요청으로 바쁘면 새 요청은 대기 줄에서 순서를 기다린다. vLLM 에서는 /metrics 의 vllm:num_requests_waiting 으로 줄 길이를 볼 수 있다. 이 값이 0 보다 크면 TTFT 가 기다린 시간만큼 늘고 있다는 뜻이다.
2.2. 입력 처리(prefill)
모델이 입력 전체를 한 번에 읽고 첫 토큰을 만드는 단계다. 입력이 길수록, 모델이 클수록 길어진다. 이 단계에서 입력 토큰의 Key·Value 가 KV 캐시에 쌓인다.
3. 다른 지표와의 관계
| 지표 | 뜻 | 사용자가 느끼는 것 |
|---|---|---|
| TTFT | 요청부터 첫 토큰까지 | 글자가 나오기 시작하는 시간 |
| ITL | 토큰과 다음 토큰 사이 간격 | 글자가 나오는 속도, 끊김 |
| E2E 지연 | 요청부터 마지막 토큰까지. 대략 TTFT + 출력 토큰 수 × 토큰 간격 | 답이 다 나올 때까지 |
4. 늘어나는 원인
| 원인 | 서버 안에서 일어나는 일 | 흔한 경우 |
|---|---|---|
| 입력 처리가 몰림 | 여러 요청의 prefill 이 한꺼번에 들어와 대기 줄이 생긴다 | 큰 dense 모델, 긴 입력 |
| KV 캐시 부족 | 자리가 없어 새 요청이 대기 줄에서 기다린다 | 높은 동시 요청 |
| 꺾이는 지점을 넘음 | 처리량은 그대로인데 기다린 시간만큼 TTFT 가 는다 | Concurrency 참고 |
5. 여담
- 스트리밍을 끄고(
stream: false) 호출하면 응답이 한꺼번에 오므로, 클라이언트 입장에서는 TTFT 와 E2E 지연이 같아진다. - 추론(reasoning) 모델은 답을 쓰기 전에 생각 토큰을 먼저 만든다. 생각 토큰을 화면에 보여 주지 않는 서비스라면, 서버가 잰 TTFT 와 사용자가 체감하는 ‘첫 글자’는 꽤 차이 난다.
기다리는 사람 입장에선 그게 그거다 - SLA 는 보통 평균이 아니라 “TTFT p95 ≤ 1초"처럼 백분위수로 적는다.
6. 관련 문서
- ITL — 첫 토큰 뒤 토큰 사이 간격
- Percentile — p95 로 읽는 법
- Concurrency — 동시 요청이 늘 때 TTFT 가 꺾이는 지점
- KV 캐시 — 차면 새 요청을 대기 줄로 보내는 메모리
7. 출처
답이 끝까지 다 나오는 데 걸린 시간은 따로 E2E(End-to-End) 지연이라고 부른다. ↩︎