NVIDIA는 GenAI-Perf를 잇는 AIPerf를 공개했고, 9월 18일 기술 블로그에서 전체 그림을 설명했습니다. 핵심 문장 하나만 뽑으면 이렇습니다.

클라이언트가 병목이 되면 서버 측정은 의미가 없다.

LLM 벤치마크가 모델 점수에서 실제 서빙 성능으로 이동하고 있다는 좋은 사례입니다. 이 글에서는 AIPerf가 무엇이 달라졌는지, 그리고 로컬 모델이나 inference server를 운영한다면 무엇을 어떻게 재야 하는지 정리합니다.

왜 새 도구가 필요했나요

기존 벤치마커는 단일 프로세스 구조라 동시성이 올라가면 GIL에 묶이기 쉽습니다. 측정 클라이언트 자체가 먼저 지쳐버리면 서버 성능을 잰 게 아니라 클라이언트 한계를 잰 셈이 됩니다.

AIPerf는 멀티프로세스 구조로 바꿨습니다. 부하를 거는 워커 프로세스, 결과를 계산하는 레코드 프로세서, 전체를 조율하는 컨트롤 플레인이 ZMQ 메시지로 붙습니다. 데이터셋은 메모리 맵 파일로 워커가 바로 읽고, 타이밍 매니저가 크레딧 방식으로 요청을 내보냅니다. 높은 동시성에서도 benchmark client 자체가 병목이 되지 않도록 하려는 설계입니다.

Control Plane (무엇을·언제·얼마나 보낼지)
  → Timing Manager (크레딧 발급)
  → Workers (HTTP 요청 발송·응답 시간 측정)
  → Record Processors (지표 계산, 병렬)
  → Records Manager (집계·내보내기)

지원 범위도 넓어졌습니다. 채팅을 포함한 15개 넘는 엔드포인트 타입, ShareGPT 같은 공개 데이터셋, Mooncake·Baseten·WEKA AgentX 같은 trace replay 형식을 한 도구에서 다룹니다. 합성 프롬프트로 가볍게 돌리는 smoke test부터 실제 운영 트래픽을 그대로 재생하는 방식까지 고를 수 있습니다.

부하 모양을 고를 수 있다는 게 포인트입니다

평균 latency만 재면 실제 서비스와 동떨어진 숫자가 나오기 쉽습니다. 실제 트래픽은 일정한 간격으로 오지 않고 뭉치고 비기를 반복하기 때문입니다. AIPerf는 부하 모양을 고를 수 있게 했습니다.

constant   — 일정한 간격으로 요청
poisson    — 실제 큐잉처럼 뭉치고 비는 도착 분포
gamma      — 뭉침 정도를 조절하는 분포
ramp       — 동시성·요청률을 서서히 올리기
fixed-schedule — trace의 타임스탬프대로 그대로 재생
user-centric   — 사용자 단위로 턴을 나눠 생각

사용 예시는 문서 그대로 따라 하면 됩니다.

# ShareGPT 데이터로 스트리밍 서빙 측정
aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --public-dataset sharegpt \
  --request-count 20 \
  --concurrency 4

# Mooncake trace를 원래 타이밍대로 재생
aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --input-file mooncake_trace.jsonl \
  --custom-dataset-type mooncake_trace \
  --fixed-schedule

여기서 --streaming은 선택이 아니라 필수에 가깝습니다. 스트리밍 없이 돌리면 서버가 전체 응답을 모아서 한 번에 보내서 첫 토큰과 디코딩 이벤트가 없습니다. TTFT와 ITL을 잴 수 없습니다.

다섯 개 지표의 역할을 나눠서 보세요

AIPerf 문서에서 반복해서 나오는 지표를 역할별로 나누면 이렇습니다.

TTFT (Time to First Token)
요청을 보내고 첫 토큰을 받기까지.
큐 대기 + 프리필 + 네트워크가 들어간다.
체감 반응 속도와 직결된다.

ITL (Inter-Token Latency)
토큰과 토큰 사이 평균 간격. TPOT라고도 부른다.
AIPerf 정의: (e2e latency - TTFT) / (출력 토큰 수 - 1)
TTFT를 빼고 디코딩 구간만 본다.

Request Latency
요청부터 마지막 토큰까지 전체 시간.
e2e = TTFT + 생성 시간.

Throughput
초당 생성 토큰 (시스템 전체)과 초당 처리 요청.
용량 계획의 기준이다.

Percentile
avg / min / max / p50 / p90 / p95 / p99 / std.
평균이 좋아도 p99가 무너지면 운영에서는 실패다.

특히 중요한 부분은 단순한 tokens/sec 하나가 아닙니다. 실제 서비스에서는 동시 사용자 수가 증가할 때 p95 latency가 어떻게 무너지는가가 훨씬 중요한 지표이기 때문입니다.

공식 문서의 예시를 보면 감이 옵니다. 합성 부하 1,000 요청 테스트에서는 TTFT 평균 347ms, p50 289ms, p90 577ms, p99 815ms 같은 분포가 나옵니다. 시스템 처리량은 22,521 tokens/sec 수준입니다. 반면 실제 trace 기반 테스트에서는 입력 길이 편차가 커지면서 TTFT 평균 407ms, p99 951ms, 처리량 4,675 tokens/sec처럼 전혀 다른 그림이 나옵니다. 균일한 합성 테스트만 통과한 서버가 실제 트래픽에서 무너지는 이유가 여기에 있습니다.

동시성을 올리는 sweep 예시도 교과서적입니다.

concurrency=1:  TTFT p50=25ms,  throughput=15 tok/s
concurrency=4:  TTFT p50=35ms,  throughput=55 tok/s
concurrency=8:  TTFT p50=50ms,  throughput=95 tok/s
concurrency=16: TTFT p50=120ms, throughput=130 tok/s  ← sweet spot
concurrency=32: TTFT p50=350ms, throughput=140 tok/s  ← 정체
concurrency=64: TTFT p50=900ms, throughput=135 tok/s  ← 포화

처리량이 더 오른다고 끝까지 올리는 게 아니라, TTFT p95가 꺾이기 시작하는 지점이 sweet spot입니다.

reasoning 모델에서는 TTFT와 TTFO를 구분하세요

GenAI-Perf에서 넘어오는 분들이 헷갈리기 쉬운 대목이 하나 있습니다. reasoning token 처리입니다. GenAI-Perf는 reasoning_content를 무시하고 첫 번째 일반 출력 토큰이 나올 때를 TTFT로 잡았습니다. AIPerf는 reasoning 토큰까지 파싱해서 어떤 종류든 첫 토큰이 나오면 TTFT로 잡고, 첫 번째 일반 출력 토큰은 TTFO라는 새 지표로 따로 잽니다.

GenAI-Perf의 TTFT = AIPerf의 TTFO
AIPerf의 TTFT ≤ AIPerf의 TTFO (reasoning 모델에서)

그래서 예전 숫자와 비교할 때는 AIPerf TTFT가 아니라 TTFO를 꺼내야 같은 정의가 됩니다. reasoning 모델을 서빙한다면 두 숫자를 같이 보는 편이 좋습니다. 사용자는 추론 토큰이 아니라 실제 답이 나오기까지를 기다린다고 느끼기 때문입니다.

CodeBridge Mini Lab: 다섯 개를 함께 재보세요

로컬 모델이나 inference server를 운영한다면 평균 latency 대신 이렇게 시작하면 됩니다.

1. TTFT — 첫 토큰까지 얼마나 걸리는가
2. ITL — 스트리밍이 끊기지 않는가
3. Request latency — 끝까지 얼마나 걸리는가
4. Throughput — 동시에 얼마나 처리하는가
5. Concurrency — 몇 동시부터 p95가 무너지는가

aiperf plot으로 TTFT 추이, ITL 추이, 처리량, GPU 사용량을 함께 보면 어디가 먼저 병목인지가 보입니다. DCGM이나 pynvml이 있으면 GPU 텔레메트리까지 붙습니다. AI Engineer 역할이 모델 API 호출에서 evaluation + inference + observability + cost engineering까지 확장되고 있다는 이야기가 바로 이 그림입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

정확도만 올리는 게 아니라 토큰 비용과 응답 속도를 같이 보며 아키텍처를 고르는 연습이 필요하다면, Classic RAG에서 GraphRAG·Agentic RAG로 이어지는 설계 과정이 이 글의 측정 이야기와 바로 이어집니다.