LLM 추론 성능 지표 이해하기, TTFT·TPOT·ITL부터 처리량까지

DEOKS · TECH LEARNINGLLM PERFORMANCELLM이 빠르다는 말은 첫 반응, 답을 이어 쓰는 속도, 전체 처리량 중 무엇을 재는지에 따라 달라집니다. 이 글에서는 TTFT·TPOT·ITL과 처리량을 정의부터 예시·계산 방법까지 차례로 살펴봅니다.

첫 글자는 빨리 나오는데 답변 중간에 멈추는 챗봇을 떠올려보세요. “첫 반응은 빠르다”와 “끝까지 매끄럽게 읽힌다”는 서로 다른 평가입니다. 여기에 여러 사람을 동시에 처리하는 서버의 능력까지 구분하면 성능표가 훨씬 명확해집니다.

다루는 범위는 LLM 추론 서비스의 응답 속도와 처리 능력입니다. 추론 문제의 정답률은 별도 평가해야 합니다. 모든 그림·GIF의 수치는 교육용 가정이며 특정 모델·GPU의 실측 결과가 아닙니다.

핵심 용어 정의 한눈에 보기

용어	먼저 기억할 정의
TTFT	요청부터 첫 내용 토큰을 받을 때까지의 시간.
TPOT	첫 토큰 이후, 출력 토큰당 걸리는 평균 시간.
ITL	이어지는 출력 사이의 간격. 제품에 따라 평균 간격을 뜻하기도 합니다.
Latency / E2E	요청부터 답변 완료까지 걸리는 전체 시간.
Throughput	일정 시간에 처리한 양. 전체 토큰/요청 처리량과 개별 속도를 구분합니다.
TPS / RPS	초당 토큰 수 / 이 글에서 초당 완료한 요청 수.

핵심은 기다림, 이어 쓰는 시간, 전체 처리량을 따로 보는 것입니다. 보조 용어는 아래의 해당 절에서 정의부터 설명합니다.

1. 기본 준비 — 토큰과 생성 단계

Token: 모델이 처리하는 텍스트 조각입니다. 한 글자나 한 단어와 항상 같지는 않습니다.
Tokenizer: 텍스트를 토큰으로 나누고 숫자 ID로 바꾸는 도구입니다.
ISL(Input Sequence Length): 모델에 들어간 입력 토큰 수입니다. 질문·시스템 지시·대화 기록·추가 문서 등이 포함될 수 있습니다.
OSL(Output Sequence Length): 모델이 생성한 출력 토큰 수입니다. 생각 과정 토큰의 포함 여부는 도구에서 확인합니다.

목적은 비교하는 작업의 크기를 맞추는 것입니다. 한국어 한 글자 = 한 토큰으로 계산하지 마세요. 같은 문장도 모델·토크나이저·언어에 따라 토큰 수가 달라질 수 있으므로 “50 tok/s”가 항상 같은 분량의 한국어 답변을 뜻하지는 않습니다.

Prefill: 입력을 처리하고 생성에 필요한 상태를 준비하는 단계입니다.
Decode: 앞선 문맥을 이용해 다음 토큰을 이어 생성하는 단계입니다.
KV Cache: 이전 토큰의 Key/Value 상태를 메모리에 보관해 다시 활용하는 장치입니다.

요청 전송, 대기와 Prefill, 0.80초 첫 토큰, Decode, 1.40초 마지막 토큰을 구분한 LLM 응답 단계 도식 — 첫 반응과 완료 시점 구분. Deoks 자체 제작·가상 사례이며 단계 길이는 시간에 비례하지 않습니다.

입력이 길면 준비할 일이 많아질 수 있고, 답변을 이어 쓰는 동안에는 메모리·스케줄링 등 다른 조건도 중요해집니다. 다만 첫 토큰 전의 시간 전체가 Prefill은 아닙니다. 대기열과 전송도 섞일 수 있습니다.

2. TTFT(Time To First Token) — 첫 반응

정의: 요청 전송부터 첫 비어 있지 않은 내용 토큰을 받을 때까지의 시간입니다.
의미·목적: 사용자가 답변의 시작을 기다리는 경험을 평가합니다.
단위·읽는 법: 초(s) 또는 밀리초(ms). 같은 조건에서 작을수록 첫 반응이 빠릅니다.

예를 들어 요청을 0초에 보내고 첫 토큰을 0.80초에 받았다면 TTFT는 800ms입니다. 1초는 1,000ms입니다. 연결 헤더나 빈 스트리밍 메시지가 온 순간을 첫 답변으로 세면 안 됩니다.

언제 쓰나요?
전송 버튼을 눌렀는데 답이 늦게 시작된다면 TTFT와 큐 대기·ISL·캐시 상태를 확인합니다. 클라이언트 기준 TTFT에는 입력 처리·첫 출력 준비·전송 등이 포함될 수 있으므로 GPU 계산 시간과 동일시하지 않습니다.

3. TPOT(Time Per Output Token) — 평균 생성 간격

정의: 첫 토큰 이후 출력 토큰당 걸리는 평균 시간입니다.
의미·목적: 답변이 시작된 뒤 평균적으로 얼마나 빨리 이어지는지 비교합니다.
단위·읽는 법: ms/token. 같은 조건에서 작을수록 평균적으로 빠릅니다.

첫 토큰은 0.80초, 마지막 토큰은 1.40초에 왔고 전체 출력은 5토큰이었다고 해봅시다. 첫 토큰 뒤에는 4개 간격이 있으므로 1을 뺍니다.

TPOT = (E2E − TTFT) ÷ (출력 토큰 수 − 1)
= (1.40 − 0.80) ÷ (5 − 1)
= 150ms/token

쓰임새: 같은 모델·부하·출력 조건에서 생성 속도를 비교할 때 봅니다. 평균 TPOT가 같아도 중간에 한 번 오래 멈출 수 있으므로 ITL도 함께 봐야 합니다.

계산 조건
위 식은 첫 응답에 토큰 하나가 오고, 마지막 내용 토큰 수신을 완료로 잡은 예제입니다. 출력이 1개 이하이면 이 식은 정의되지 않습니다. 첫 청크에 여러 토큰이 있거나 완료 끝점이 다르면 측정 도구의 식을 확인합니다.

4. ITL · Chunk · ICL — 스트리밍의 끊김

정의: ITL(Inter-Token Latency)은 이어지는 출력 사이의 간격입니다. 이 글에서는 개별 간격으로 설명합니다.
의미·목적: 평균 속도에 숨은 멈춤과 간격의 흔들림을 확인합니다.
단위·읽는 법: ms. 평균뿐 아니라 긴 간격과 분포를 확인합니다.

간격이 100 · 300 · 100 · 100ms이면 평균은 150ms지만 두 번째 간격에서는 300ms를 기다립니다. 네 간격이 모두 150ms인 경우와 평균은 같아도 읽는 느낌은 달라질 수 있어요.

모든 간격이 150ms인 A와 100·300·100·100ms인 B의 TPOT는 모두 150ms지만 B의 끊김이 더 크다는 막대 차트 — 평균 TPOT가 같아도 개별 간격은 다릅니다. Deoks 자체 제작·가상 수치.

쓰임새: 첫 반응은 빠른데 답변 중간이 끊긴다면 ITL 분포와 스케줄링·전송 조건을 확인합니다. 이것만으로 원인이 확정되는 것은 아닙니다.

Chunk: 스트리밍에서 함께 전달하는 묶음입니다. 토큰 여러 개가 한 청크에 들어갈 수 있습니다.
ICL(Inter-Chunk Latency): 이어지는 청크 사이의 수신 간격입니다.

주의: ITL이라는 이름도 도구마다 다릅니다
NVIDIA NIM/AIPerf는 평균 ITL을 TPOT와 같은 뜻으로 설명하기도 합니다. vLLM의 출력 이벤트 간격과 요청별 TPOT는 집계 방식이 다를 수 있습니다. 토큰/청크, 개별 간격/요청 평균, 가중치를 먼저 확인해야 합니다. 수신 간격은 서버의 순수 한 토큰 계산 시간과도 다릅니다.

5. Latency(E2E) — 총 응답 시간

정의: E2E 또는 E2EL(End-to-End Latency)은 요청부터 답변 완료까지의 시간입니다.
의미·목적: 완성된 답변을 언제 사용할 수 있는지 평가합니다.
단위·읽는 법: 초(s) 또는 ms. 같은 작업·출력 길이에서 비교합니다.

앞의 가정에서는 마지막 토큰이 1.40초에 도착하므로 E2E는 1.40초입니다. 첫 반응이 빠르더라도 답변이 길거나 생성이 느리면 완료까지 오래 걸릴 수 있습니다.

E2E = TTFT + TPOT × (출력 토큰 수 − 1)
= 0.80 + 0.15 × 4 = 1.40초
앞의 토큰당 1회 전달·마지막 토큰 완료 조건에서의 계산입니다.

쓰임새: 요약·보고서·코드 생성처럼 전체 결과가 필요한 작업에 유용합니다. 스트리밍에서도 E2E를 잴 수 있습니다. 도구가 마지막 내용 토큰, 종료 신호, 클라이언트 대기 중 어디까지 포함하는지는 확인하세요.

6. Throughput · TPS · RPS — 처리 능력

정의: Throughput은 일정 시간 동안 처리한 양입니다. 여기서는 서버 전체 출력 토큰 처리량을 중심으로 봅니다.
의미·목적: 많은 요청을 처리하는 서비스의 용량과 효율을 평가합니다.
단위·읽는 법: 출력 토큰 처리량은 tok/s, 요청 처리량은 req/s. 같은 조건에서 비교합니다.

TPS(Tokens Per Second): 초당 토큰 수입니다. 요청 하나의 속도인지 서버 전체의 처리량인지 표시해야 합니다.
RPS(Requests Per Second): 이 글에서는 초당 완료한 요청 수입니다. 들어오는 요청의 속도와 구분합니다.

한 사람이 받는 속도와 서버 전체의 처리량은 같은 숫자가 아닙니다. 아래는 동시 요청 수가 늘면서 전체 처리량은 증가하지만, 요청 하나의 몫은 줄어들 수 있다는 가상 차트입니다.

동시 요청 1·4·16개에서 전체 처리량 50·160·320 tok/s와 한 요청당 50·40·20 tok/s를 같은 축으로 비교한 가상 차트 — 전체 처리량 증가와 개별 요청 속도 저하가 함께 나타날 수 있습니다. Deoks 자체 제작·특정 제품 측정 결과 아님.

쓰임새: 서버 용량을 판단할 때는 전체 처리량을, 사용자 경험에는 요청별 TTFT·TPOT를 함께 봅니다. 입력+출력 토큰 처리량을 출력 전용 처리량과 섞지 않으며, 요청마다 답변 길이가 달라 RPS와 TPS도 서로 대체하지 않습니다.

TPOT와 Throughput의 차이
TPOT는 요청 하나의 평균 생성 간격, 전체 Throughput은 서버가 처리한 양입니다. 같은 부하에서 지연 목표를 지키면서 처리량이 얼마인지 확인해야 합니다. 큰 배치가 항상 더 빠른 사용자 경험이나 항상 더 나쁜 지연을 뜻하는 것은 아닙니다.

7. 부하 조건 — Concurrency · Request Rate · Batching

Concurrency: 동시에 진행 중인 요청 수입니다.
Request Rate: 초당 새로 들어오는 요청 수입니다. 완료한 RPS와는 다릅니다.
Batching: 여러 요청을 묶어 처리하는 방식입니다.
Continuous Batching: 완료된 요청을 빼고 새 요청을 넣으며 처리 묶음을 계속 갱신하는 방식입니다.

목적·쓰임새: 성능표가 어느 부하에서 나온 값인지 설명합니다. 동시에 10개가 진행 중인 상황과 초당 10개가 새로 들어오는 상황은 다릅니다. 도착률이 완료 능력을 계속 넘으면 대기열이 늘 수 있습니다.

배칭은 하드웨어 활용도를 높일 수 있지만 지연과 처리량의 균형은 묶음 크기·스케줄링·모델에 따라 달라집니다. 배칭 설정을 바꿀 때 요청별 TTFT·TPOT와 전체 처리량을 함께 비교하세요.

8. 느린 경험과 목표 — P50 · P95 · P99 · SLO · Goodput

P50: 중앙값입니다. 측정값의 약 절반이 이 값 이하입니다.
P95 / P99: 측정값의 약 95% / 99%가 이 값 이하인 경계입니다.
SLO(Service Level Objective): 서비스가 지키려는 목표입니다.
Goodput: 정한 SLO를 충족한 요청의 유효 처리량입니다.

목적·쓰임새: 평균에 가려진 느린 사용자 경험과 목표를 지킨 처리량을 확인합니다. P95 TTFT가 2초라면 측정한 요청의 약 95%가 2초 이내에 첫 토큰을 받았다는 의미입니다. 작은 표본의 P99는 불안정할 수 있습니다.

Goodput 가상 예제
10초 동안 100개 요청 완료 → 전체 10 req/s
정한 목표를 모두 지킨 요청은 60개 → Goodput 6 req/s
목표 만족률은 60%이며 Goodput과 단위가 다릅니다.

SLO는 예를 들어 “TTFT 1초 이하 그리고 TPOT 100ms 이하”처럼 정할 수 있지만 모든 서비스에 맞는 권장값은 아닙니다. 요청별 평균 TPOT와 개별 ITL은 다른 분포이므로 P95 TPOT가 낮다고 모든 출력 간격이 짧다고 단정하지 않습니다.

9. 그래서 어떻게 재고 계산하나요?

9.1 요청 시각과 내용 도착 시각을 같은 시계로 기록하기

클라이언트에서 요청 전송 시각, 첫 내용 도착 시각, 이후 내용 도착 시각, 완료 시각을 기록합니다. 시간 간격은 단조 증가 시계를 사용하는 방식이 적합합니다. 빈 메시지는 첫 답변으로 세지 않고, 청크마다 몇 토큰이 들어왔는지도 구분해야 합니다.

이벤트	요청 이후 도착 시각
요청 전송	0.00초
T1: 첫 토큰	0.80초
T2	0.90초
T3	1.20초
T4	1.30초
T5: 마지막 토큰	1.40초

가상 요청에서 첫 토큰이 0.80초에 오고 마지막 토큰이 1.40초에 오는 과정, 가운데 300ms 간격을 보여주는 29프레임 GIF — 토큰당 한 번 전송하는 개념 애니메이션. Deoks 자체 제작·실측 아님·가상 시간을 2배 느리게 재생.

이 가정은 한 번에 토큰 하나씩 전달합니다. GIF는 가상 시간을 2배 느리게 보여줍니다. 실제 스트리밍 청크를 토큰 하나라고 간주하면 ITL과 TPOT가 잘못 계산될 수 있습니다.

9.2 가상 시각으로 계산하는 Python 예제

아래 코드는 이미 주어진 가상 시각의 산술만 계산합니다. 실제 모델이나 API를 호출하는 벤치마크 코드가 아닙니다. 이 계산 코드는 실행해 결과를 확인했습니다.

PYTHON · 가상 시각 계산

request_sent = 0.0
token_arrivals = [0.80, 0.90, 1.20, 1.30, 1.40]

ttft = token_arrivals[0] - request_sent
itl = [b - a for a, b in zip(token_arrivals, token_arrivals[1:])]
e2e = token_arrivals[-1] - request_sent
tpot = (e2e - ttft) / (len(token_arrivals) - 1)

print(f"TTFT: {ttft * 1000:.0f} ms")
print("ITL:", [round(x * 1000) for x in itl], "ms")
print(f"TPOT: {tpot * 1000:.0f} ms/token")
print(f"E2E: {e2e:.2f} s")

실행 결과(가상 시각 계산)
TTFT: 800ms
ITL: 100 · 300 · 100 · 100ms
TPOT: 150ms/token
E2E: 1.40s

같은 요청의 속도도 분모에 따라 다릅니다. 첫 토큰 이후만 계산하면 4 ÷ 0.60 ≈ 6.67 tok/s, 첫 대기까지 포함하면 5 ÷ 1.40 ≈ 3.57 tok/s입니다. “사용자당 속도”라는 이름만 보지 말고 계산 범위를 확인하세요.

실제 벤치마크에서 맞출 조건
모델·버전·토크나이저·언어·ISL·OSL, 하드웨어·정밀도·엔진·캐시, 동시 요청·도착률, 클라이언트/서버 시계와 완료 끝점, 평균/백분위·표본 수·워밍업, 오류·답변 품질·비용을 함께 기록합니다. 실제 GPU/API 성능 테스트는 이 글에서 실행하지 않았습니다.

10. 요약 — 어떤 지표를 먼저 볼까?

질문	먼저 볼 지표
첫 답변이 왜 늦을까?	TTFT → 큐 대기·입력 길이·캐시
답변 중간이 왜 끊길까?	ITL/ICL 분포 → 스케줄링·전송
평균적으로 얼마나 빨리 이어 쓰나?	TPOT
완성된 결과를 언제 받나?	E2E와 출력 길이
서버가 얼마나 처리하나?	같은 부하의 전체 Throughput·RPS
느린 경험과 목표를 놓치지 않았나?	P95/P99·SLO·Goodput·오류

이 표는 원인을 확정하는 진단표가 아니라 다음 확인 항목을 고르는 안내입니다. 하나의 속도 숫자보다 같은 조건의 지연·처리량·목표 달성을 함께 보는 것이 중요합니다.

KV Cache와 메모리의 관계를 더 알고 싶다면 기존 한국어 산업 글 KV 캐시 재사용, HBM은 덜 필요할까를 함께 읽어보세요. 이 성능 지표를 특정 기업의 매출이나 주가 전망으로 바로 바꾸지는 않습니다.

Appendix. 다음 단계에서 알아둘 최적화 용어

용어	정의와 확인할 점
Prefix Caching	공통 입력 접두부의 계산 결과를 재사용합니다. 캐시가 있는 측정과 없는 측정을 구분합니다.
Chunked Prefill	긴 입력 처리를 나눠 스케줄링합니다. TTFT·생성 간격·처리량의 균형을 확인합니다.
Quantization	양자화. 낮은 정밀도로 표현해 메모리·계산 비용을 바꿉니다. 답변 품질과 지원 환경도 확인합니다.
Speculative Decoding	추측 디코딩. 후보 토큰을 제안하고 검증해 생성 속도를 높이는 기법입니다. 여러 토큰이 함께 전달될 수 있어 청크/토큰 구분이 중요합니다.

공식 출처와 자료 사용 안내

Hugging Face — Tokenization algorithms: 토큰·토크나이저
NVIDIA — Inference Optimization: Prefill·Decode·KV Cache·배칭
NVIDIA NIM — Benchmarking Metrics: TTFT·E2E·평균 ITL·TPS·RPS
vLLM — Metrics: 이벤트 간격·TPOT·집계 방식
NVIDIA AIPerf — Metrics Reference: 청크·ICL·사용자당 처리 속도
vLLM SenDNN — Benchmarking and Performance: 성능 비교 조건
GuideLLM — GoodputSLO: 서비스 목표 충족 기준

구성 참고: AI의 정석의 LLM 속도 개념 글. 용어별 정의·의미에서 예시·측정·요약으로 이어지는 조직 방식을 참고했으며 문장·그림·코드는 복제하지 않았습니다.

기준일: 2026-10-12. 도표·GIF는 Deoks 자체 제작이며 가상 수치입니다. Python 시각 계산만 실행했고 실제 GPU/API 벤치마크는 실행하지 않았습니다. 실제 비교에는 도구의 버전과 측정 정의를 확인하세요.

이 블로그 검색

Deoks