개요
Latency는 하나의 요청이 들어온 뒤 결과가 나올 때까지 걸리는 시간을 나타내고, Throughput은 일정 시간 동안 시스템이 처리할 수 있는 요청이나 작업의 양을 나타낸다. 두 지표는 관련되어 있지만 같은 의미가 아니며, 시스템 설정에 따라 서로 절충 관계가 생길 수 있다.
벤치마크에서의 측정
MLPerf Inference는 실제 배포 환경을 반영하기 위해 여러 요청 패턴과 시나리오를 정의하고 지연시간 제약과 처리량 지표를 함께 사용한다.[1] 같은 하드웨어라도 배치 크기와 요청 도착 패턴, 모델과 정확도 조건이 달라지면 결과를 직접 비교하기 어렵다.
LLM 서비스
Inference 시스템에서는 여러 요청을 배치하면 Throughput을 높일 수 있지만 개별 요청의 Latency가 늘 수 있다. vLLM 연구도 높은 동시 처리량을 얻기 위해 요청 배치와 KV Cache 메모리 관리를 중요한 시스템 문제로 다룬다.[2] 따라서 성능 평가는 하나의 숫자보다 사용 시나리오를 먼저 정하는 것이 중요하다.
예제: 평균 1.9초가 긴 대기를 가리는 경우
가상의 완료 요청 100개에서 90개는 1초, 10개는 10초가 걸렸다면 평균은 (90×1+10×10)÷100=1.9초다. 시간을 정렬한 뒤 95번째 값을 택하는 최근접 순위 방식의 p95는 10초다. 평균만 보면 일부 사용자의 긴 대기를 놓칠 수 있다. 백분위 계산 방식과 표본 수를 함께 기록하며, 이 예는 실제 서비스 측정이 아니다.
완료한 요청만 남기면 시간 초과·실패가 빠져 성능이 좋아 보일 수 있다. 별도의 가상 1분 구간에 응답 100건 중 품질 기준을 충족한 작업이 92건이면 유효 완료율은 92÷60≈1.53건/초다. 모든 응답을 센 100÷60≈1.67건/초와 의미가 다르다. 성공 작업당 비용과도 같은 완료 기준을 사용한다.
측정의 시작점과 끝점을 고정
브라우저 요청 시작→첫 표시, 서버 접수→첫 생성, 마지막 토큰 생성→사용자 수신은 다른 시간 구간이다. vLLM 운영 지표 ↗에서 엔진의 지표 정의를 확인하고, 서버 수치를 사용자 체감 시간으로 그대로 바꾸지 않는다.[3] 검색·네트워크·도구 구간이 빠졌는지 기록한다.
음성 응답은 사용자의 발화 종료·첫 오디오 재생·끼어들기 이후 중단도 고려할 수 있다. 도구 작업은 모델의 답이 나온 시간과 실제 실행 결과가 확인된 시간을 구분한다. 목표 과제에 맞는 종료 조건을 먼저 정한다.
배치를 바꿀 때 함께 남길 조건
MLPerf Datacenter 안내 ↗는 시나리오·품질 조건을 포함한 성능 비교의 원문이다.[1] 입력·출력 길이, 도착 패턴, 동시 요청, 장치·엔진·정밀도·캐시 상태를 함께 남긴다. 요청을 크게 묶어 처리량이 올라도 첫 응답이나 긴 대기 요청이 목표를 넘는지 확인한다.
짧은 입력만으로 얻은 수치를 긴 문서 작업에 일반화하지 않는다. 같은 자료·품질에서 평균·상위 백분위·시간 초과·유효 완료량을 비교하고, 변경 전후의 비용에 재시도와 사람의 검토를 같은 범위로 포함한다. 가장 큰 처리량 숫자 하나로 운영 설정을 확정하지 않는다.