LLM 서버 성능 지표 완전 정리
LLM 서비스를 운영한다는 것은 단순히 모델을 띄워두는 것이 아니다. 사용자가 체감하는 속도, 서버가 감당할 수 있는 트래픽, GPU 비용까지 모두 수치로 측정하고 균형을 맞춰야 한다. 이 지표들은 각각 독립적으로 존재하는 것이 아니라 서로 트레이드오프 관계에 있기 때문에, 전체 구조를 이해하고 봐야 한다.
1. Latency Metrics — 사용자가 느끼는 속도
TTFT (Time To First Token)
요청을 보낸 시점부터 첫 번째 토큰이 출력되기까지 걸리는 시간이다.
사용자 체감 UX에서 가장 직접적인 지표다. 챗봇에서 "응답 시작이 느리다"는 불만은 거의 대부분 TTFT 문제다. 전체 응답이 빠르더라도 첫 글자가 늦게 나오면 사용자는 느리다고 인식한다.
TTFT가 느려지는 원인
- 모델 로딩 및 KV cache 초기화
- request queue 대기 (앞선 요청들이 처리되길 기다림)
- batch waiting (vLLM이 요청을 모아서 한 번에 처리하는 정책)
[요청 전송] ──── 대기 ────▶ [첫 토큰 출력]
↑
이 구간이 TTFT"서버가 얼마나 빨리 반응을 시작하느냐" 를 측정하는 지표이다.
TPOT (Time Per Output Token)
토큰 하나를 생성하는 데 걸리는 평균 시간이다.
첫 토큰이 나온 이후, 이어지는 토큰들이 얼마나 일정한 속도로 출력되는지를 나타낸다. 이 값이 일정하지 않고 튀는 구간이 생기면 사용자는 텍스트가 끊기는 느낌을 받는다.
TPOT에 영향을 주는 요소
- GPU 연산 성능
- KV cache hit/miss 여부 (cache miss가 발생하면 재계산이 필요해 느려진다)
- sequence 길이 (문맥이 길어질수록 attention 연산량이 증가한다)
핵심 해석: "말하기 시작한 뒤 얼마나 부드럽게 이어지는가"
E2E Latency (End-to-End Latency)
요청 전송부터 응답 완전 수신까지의 총 시간이다.
E2E Latency = TTFT + (TPOT × 생성된 토큰 수)배치 처리 작업이나 API SLA(Service Level Agreement) 계약에서 중요하게 다뤄진다. 다만 실시간 대화형 서비스에서는 사용자가 스트리밍으로 텍스트를 읽기 때문에 TTFT보다 체감 중요도가 낮다.
"전체 처리 시간 (백엔드 기준 KPI)"
2. Throughput Metrics — 얼마나 많이 처리하느냐
TPS (Tokens Per Second)
초당 생성되는 토큰 수다.
LLM 서버 성능을 나타내는 가장 핵심적인 지표다. vLLM, TensorRT-LLM 같은 추론 최적화 프레임워크의 목표가 이 수치를 높이는 것이다.
TPS와 Latency의 트레이드오프
batch 크기를 늘리면 GPU 활용률이 높아져 TPS가 올라가지만, 각 요청의 대기 시간이 늘어나 TTFT가 증가한다. TPS와 Latency는 반비례 관계인 경우가 많다.
Batch Size ↑ → TPS ↑ → TTFT ↑해석: "GPU를 얼마나 효율적으로 사용하고 있느냐"
RPS (Requests Per Second)
초당 처리하는 API 요청 수다.
일반적인 웹 서버에서 자주 쓰이는 지표지만, LLM 서버 측면에서는 TPS보다 간접적인 지표다. 요청 하나당 생성되는 토큰 수가 천차만별이기 때문에, RPS가 높다고 해서 반드시 처리량이 많은 것은 아니다.
예를 들어 짧은 응답 1000개를 처리하는 것과 긴 응답 10개를 처리하는 것은 RPS 지표 자체는 다르지만 실제 GPU 부하는 비슷할 수 있다.
해석: "트래픽 감당 능력"
Concurrent Requests
현재 동시에 처리 중인 요청 수다.
이 수치가 서버 용량을 초과하기 시작하면 요청이 queue에 쌓이고, 그 결과 TTFT가 직접적으로 증가한다. 오토스케일링 정책을 설계할 때 임계값 기준으로 자주 사용된다.
Concurrent Requests ↑ → Queue 발생 → TTFT ↑해석: "현재 서버 부하 상태"
3. Efficiency Metrics — 비용과 자원
GPU Utilization
GPU 연산 유닛이 실제로 사용되는 비율이다.
낮으면 GPU를 놀리는 것이므로 비용 낭비다. 너무 높으면 모든 연산 자원이 포화 상태가 되어 latency가 증가한다.
| 구간 | 상태 |
|---|---|
| 0 ~ 50% | GPU 낭비, 배치 정책 재검토 필요 |
| 70 ~ 90% | 이상적인 균형 상태 |
| 90% 이상 | 포화 상태, latency 증가 위험 |
핵심 해석: "GPU 투자 대비 얼마나 뽑아쓰고 있느냐"
GPU Memory / KV Cache Usage
LLM 추론에서 메모리의 대부분은 KV cache가 차지한다.
KV cache는 이전에 처리한 토큰들의 Key-Value 벡터를 저장해두는 공간이다. 이미 계산한 내용을 재사용하기 위해 존재한다. 이 cache가 부족해지면 두 가지 문제가 발생한다.
- OOM(Out of Memory): 메모리 초과로 서버가 다운된다
- Recompute: cache를 버리고 처음부터 재계산하므로 성능이 급격히 떨어진다
KV Cache 부족
├── OOM 발생 → 서버 다운
└── Recompute → 성능 폭락해석: "얼마나 긴 문맥을 안정적으로 처리하느냐"
Cost per 1K Tokens
토큰 1,000개를 생성하는 데 드는 비용이다.
서비스 운영 관점에서 가장 현실적인 KPI다. OpenAI, Anthropic 등의 API 과금 단위도 이 기준으로 책정된다.
Cost per 1K Tokens = (총 GPU 운영 비용) / (총 생성 토큰 수) × 1000GPU 효율이 높을수록, TPS가 높을수록 이 값이 낮아진다. 결국 모든 최적화의 최종 목적지는 이 수치를 낮추는 것이라고도 볼 수 있다.
해석: "이 서비스를 운영하는 데 돈이 얼마나 드는가"
4. vLLM / TensorRT-LLM 핵심 지표 — 최적화 레벨
Request Queue Time
요청이 처리되기 전 대기열에서 기다린 시간이다.
이 시간이 TTFT에 직접 더해지기 때문에, TTFT를 낮추려면 Queue Time을 먼저 봐야 한다.
Queue Time이 길어지는 원인
- 트래픽 폭주로 인한 요청 적체
- 배치 정책으로 인한 의도적 대기 (효율을 위해 요청을 모으는 것)
- GPU 부족으로 인한 처리 지연
해석: "서버가 요청을 얼마나 빠르게 집어올리는가"
Cache Utilization (PagedAttention)
vLLM이 도입한 PagedAttention 기술 기반의 KV cache 활용률이다.
기존 LLM 추론 방식은 KV cache를 연속된 메모리 블록으로 관리했기 때문에 메모리 단편화(Fragmentation)가 심했다. PagedAttention은 운영체제의 가상 메모리 페이징 방식을 차용하여 KV cache를 비연속적인 작은 블록으로 나눠 관리한다. 덕분에 같은 GPU 메모리로 훨씬 많은 요청을 동시에 처리할 수 있다.
| Cache 활용률 | 의미 |
|---|---|
| 높음 | 메모리 효율 좋음, 더 많은 요청 동시 처리 가능 |
| 낮음 | 메모리 낭비 발생, 배치 정책 재검토 필요 |
해석: "같은 GPU로 얼마나 많은 요청을 처리하느냐"
5. 전체 트레이드오프 구조
이 지표들은 서로 독립적으로 존재하지 않는다. 하나를 개선하면 다른 것이 나빠지는 트레이드오프 관계가 존재한다.
┌─────────────────────────────────────────────────────┐
│ 트레이드오프 관계 │
│ │
│ TPS ↑ → TTFT ↑ (요청당 대기 증가) │
│ Batch Size ↑ → TPS ↑ but Latency ↑ │
│ Concurrent ↑ → Queue ↑ → TTFT ↑ │
│ KV Cache ↑ → Memory ↑ → 안정성 ↑ │
│ GPU Util ↑ → Cost ↓ but Latency ↑ 가능 │
└─────────────────────────────────────────────────────┘실제 운영에서는 서비스 성격에 따라 어떤 지표를 우선순위에 둘지 결정해야 한다.
| 서비스 유형 | 우선 지표 |
|---|---|
| 실시간 챗봇 | TTFT 최소화 |
| 문서 요약 배치 작업 | TPS, E2E Latency |
| 비용 절감 최우선 | GPU Utilization, Cost per 1K |
| 긴 문맥 처리 | KV Cache Usage |
정리
LLM 서버 성능 지표는 사용자 경험(Latency), 처리 능력(Throughput), 비용 효율(Efficiency) 세 축으로 구성된다. 세 축은 항상 긴장 관계에 있으며, 하나를 극단적으로 최적화하면 다른 축이 희생된다. 좋은 LLM 서비스 운영이란 이 세 축의 균형점을 서비스 특성에 맞게 찾아내는 과정이다.
