지연 시간은 하나의 추론 요청에 걸리는 시간이고, TTFT는 스트리밍 요청이 응답을 시작하기까지 걸리는 시간이며, 초당 토큰 수는 하나의 스트림 또는 전체 시스템을 설명할 수 있는 비율입니다. 처리량은 시스템이 시간에 따라 완료하는 총 작업량입니다. 가장 중요한 차이는 범위입니다. 지연 시간과 TTFT는 하나의 요청을 측정하는 반면, 처리량은 측정 구간 동안의 작업량을 집계합니다.
“초당 토큰 수”라는 표현에는 특별한 주의가 필요합니다. 이는 단위일 뿐, 완전한 지표가 아닙니다. 어떤 토큰을 세었는지, 그리고 어떤 시간 구간을 사용했는지를 추가로 알아야 합니다.
각 지표가 측정하는 것
추론 지연 시간
추론 지연 시간은 요청에 걸린 경과 시간입니다. 생성된 응답의 경우 “종단 간 지연 시간”은 일반적으로 요청을 보내거나 수신한 시점부터 최종 출력을 수신한 시점까지입니다.
다음 질문에 답합니다: 이 요청이 완료되기까지 얼마나 걸리는가?
이 경계는 보편적으로 정해져 있지 않습니다. 클라이언트 측 측정에는 라우팅, 네트워크 전송, 대기열 대기, 응답 처리가 포함될 수 있습니다. 추론 서버는 이러한 단계 중 일부가 끝난 뒤 시계를 시작할 수 있습니다. 벤치마크가 단지 “지연 시간”이라고만 말한다면, 해당 수치를 재현하기에 충분한 정보가 제공되지 않은 것입니다.
지연 시간은 출력 길이에도 직접적으로 영향을 받습니다. 짧은 응답과 긴 응답은 TTFT와 생성 속도가 같을 수 있지만, 긴 응답이 완료되기까지는 더 오래 걸립니다.
첫 번째 토큰까지의 시간
첫 번째 토큰까지의 시간(TTFT)은 요청의 시작 경계부터 스트리밍 응답에서 비어 있지 않은 첫 번째 출력 토큰이 도착할 때까지의 시간입니다.
다음 질문에 답합니다: 응답이 나타나기 시작하기까지 얼마나 걸리는가?
TTFT에는 일반적으로 대기열 대기, 입력 처리, 프롬프트에 대한 모델의 프리필 작업, 첫 번째 토큰 생성, 그리고 선택한 경계에 포함되는 네트워크 시간이 포함됩니다. TTFT는 종단 간 지연 시간의 일부이지, 종단 간 지연 시간의 다른 이름이 아닙니다.
TTFT가 낮으면 인터페이스가 반응성 있게 느껴집니다. 그러나 그것만으로는 응답의 나머지 부분이 얼마나 매끄럽게 도착할지, 또는 응답이 언제 완료될지는 알 수 없습니다.
초당 토큰 수
초당 토큰 수는 출력 토큰 수를 경과 시간(초)으로 나눈 값입니다. 제품 비교에서는 첫 번째 토큰 이후 한 요청의 생성 속도를 의미하는 경우가 많습니다.
다음 질문에 답합니다: 생성이 시작된 뒤 생성된 텍스트가 얼마나 빠르게 도착하는가?
출력 토큰이 (N)개인 응답에는 첫 번째 토큰과 마지막 토큰 사이에 (N-1)개의 간격이 있습니다. 이 간격에 (G)초가 걸린다면 첫 번째 토큰 이후 속도는 다음과 같습니다.
[\text{요청별 생성 속도} = \frac{N-1}{G}]
이는 측정된 각 이벤트가 하나의 토큰을 포함할 때, 출력 토큰 간 평균 시간의 역수입니다. 실제 스트리밍 API는 여러 토큰이 포함된 청크를 전달할 수 있으므로, 클라이언트는 이벤트 하나당 토큰 하나라고 가정하지 말고 토큰을 직접 세어야 합니다.
일부 도구는 모든 출력 토큰 수를 요청의 전체 종단 간 지연 시간으로 나눕니다. 또 다른 도구는 동시에 실행 중인 모든 요청의 토큰을 합산합니다. 모두 TPS 또는 tokens/s로 표시될 수 있지만, 이러한 선택에 따라 서로 다른 수치가 산출됩니다.
추론 처리량
추론 처리량은 명시된 워크로드에서 시스템이 단위 시간당 완료하는 총 작업량입니다. 출력 토큰/초, 전체 토큰/초, 요청/초, 샘플/초 또는 워크로드에 적합한 다른 단위로 측정할 수 있습니다.
다음 질문에 답합니다: 시스템이 얼마나 많은 부하를 처리할 수 있는가?
처리량은 집계 속성입니다. 처리량을 측정하려면 테스트 구간과 부하 패턴이 필요합니다. 동시성, 요청 도착률, 프롬프트 및 응답 길이, 배칭, 레플리카 수, 실패한 요청 처리 방식이 모두 처리량을 바꿀 수 있습니다.
요청 처리량과 토큰 처리량은 서로 바꿔 사용할 수 없습니다. 서버는 짧은 요청을 많이 완료하거나 긴 요청을 더 적게 완료하면서도 동일한 초당 출력 토큰 수를 생성할 수 있습니다.
실제 구분
| Metric | Clock stops at | Typical scope | Typical unit | The question it answers |
|---|---|---|---|---|
| Latency | Final response output | One request | ms or s/request | When is this request finished? |
| TTFT | First content token | One streamed request | ms or s/request | When does the answer begin? |
| Tokens per second | Depends on the stated formula | One request or the whole system | output tokens/s | How fast are tokens arriving, and for whom? |
| Throughput | End of a test interval | System or deployment | tokens/s, requests/s, or samples/s | How much work is completed under load? |
보고된 결과를 거의 항상 명확하게 만드는 질문은 세 가지입니다.
- 무엇을 세는가? 출력 토큰, 전체 토큰, 완료된 요청 또는 샘플인가?
- 시계는 언제 시작하고 멈추는가? 클라이언트 전송 시점, 서버 수신 시점, 첫 번째 토큰, 최종 토큰 또는 고정된 테스트 경계인가?
- 범위는 어디까지인가? 하나의 요청, 한 명의 사용자, 하나의 레플리카 또는 동시 부하가 걸린 전체 배포 환경인가?
벤치마크가 이 세 가지 질문에 모두 답하지 못한다면, 그 수치는 비교에 사용할 준비가 되지 않은 것입니다.
계산 예시
출력 토큰 81개를 반환하는 요청 하나를 생각해 보겠습니다.
- 요청은 0.0초에 전송됩니다.
- 첫 번째 토큰은 0.8초에 도착합니다.
- 최종 토큰은 2.8초에 도착합니다.
이 요청의 TTFT는 0.8초이고, 종단 간 지연 시간은 2.8초입니다. 첫 번째 토큰 이후 생성에는 2.0초가 걸렸고 토큰 간 간격은 80개이므로, 첫 번째 토큰 이후 속도는 초당 40토큰입니다.
도구가 출력 토큰 81개 전체를 세고 이를 전체 2.8초 지연 시간으로 나누면 약 초당 29토큰으로 보고합니다. 이는 수학적 불일치가 아닙니다. 시계의 경계와 분자가 서로 다른 것입니다.
이제 하나의 서버에 여러 요청을 배치해 보겠습니다. 10초의 테스트 구간 동안 서버가 출력 토큰 3,000개를 생성하고 요청 50개를 완료했다고 합시다.
- 출력 토큰 처리량: (3{,}000 / 10 = 300) 토큰/초
- 요청 처리량: (50 / 10 = 5) 요청/초
서버의 초당 300토큰은 활성 요청 전체에서 생성된 출력의 합계입니다. 개별 사용자는 여전히 초당 40토큰 또는 그보다 낮은 속도로 출력을 받을 수 있습니다. 부하가 추가되어 대기열 대기와 디코딩 지연이 증가하면 속도는 더 느려질 수 있습니다.
각 지표가 중요한 경우
채팅 인터페이스, 코딩 어시스턴트 또는 기타 스트리밍 상호작용에서는 TTFT가 초기 대기 시간을 설명합니다. 요청별 생성 속도 또는 그 역수인 출력 토큰당 시간은 초기 대기 이후의 속도를 설명합니다. 사용자나 다른 프로그램이 계속 진행하기 전에 완전한 응답을 필요로 한다면 종단 간 지연 시간이 중요합니다.
배치 작업에서는 일반적으로 TTFT보다 처리량이 더 중요합니다. 실패와 출력 품질이 허용 가능한 수준으로 유지된다면, 작업은 총 완료율에 관심을 둡니다.
용량 계획에서는 지연 시간 목표와 함께 처리량을 사용합니다. 동시성을 높이면 하드웨어가 더 많은 작업을 병렬로 처리하므로 처음에는 총 처리량이 향상되는 경우가 많습니다. 그러나 동일한 동시성으로 인해 대기열 대기가 늘어나 개별 사용자의 속도는 느려질 수 있습니다. 포화 상태에 도달하면 지연 시간은 계속 증가하는 반면 처리량은 정체되거나 감소할 수 있습니다.
비스트리밍 API에서는 응답이 완료된 뒤에만 전달되므로 클라이언트가 TTFT를 관찰할 수 없을 수 있습니다. 서버는 여전히 내부 단계를 측정할 수 있지만, 클라이언트가 확인할 수 있는 성능은 종단 간 지연 시간입니다.
사람들이 혼동하는 것과 그 이유
낮은 TTFT가 낮은 지연 시간을 보장하지는 않습니다
응답이 빠르게 시작된 뒤 느리게 생성될 수 있습니다. TTFT는 첫 번째 이정표만 포착합니다. 전체 지연 시간에는 남은 생성 시간도 포함됩니다.
첫 번째 토큰 이후 시간을 명시적으로 정의하면 관계식은 다음과 같습니다.
[\text{종단 간 지연 시간} = \text{TTFT} + (N-1)\times\text{출력 토큰 간 평균 시간}]
구현마다 토큰을 세는 방식이 다르므로, 한 지표에서 다른 지표를 재구성하기 전에 벤치마크의 공식을 확인해야 합니다.
초당 토큰 수가 처리량일 수 있습니다
“초당 토큰 수”는 때때로 한 사용자의 생성 속도를 의미합니다. 또한 집계된 출력 토큰 처리량의 단위일 수도 있습니다. 레이블만으로는 둘을 구분할 수 없습니다.
다음과 같은 한정어를 찾아보세요: 요청당, 사용자당, 스트림당, 집계 또는 시스템입니다. 이러한 표현이 없다면 공식과 테스트 설정을 확인하세요.
높은 처리량이 빠른 요청을 보장하지는 않습니다
서버는 많은 요청을 배칭하여 초당 총 토큰 수를 늘릴 수 있지만, 각 요청은 더 오래 기다리거나 토큰을 덜 자주 받을 수 있습니다. 따라서 실제 서빙 테스트에서는 처리량을 지연 시간 백분위수와 함께 보고하거나, 명시된 서비스 목표를 충족하면서 완료된 작업량인 굿풋을 계산합니다.
서로 다른 워크로드는 서로 다른 결과를 만듭니다
TTFT는 프롬프트 길이와 대기열 대기에 따라 달라집니다. 종단 간 지연 시간은 응답 길이에 따라 달라집니다. 처리량은 동시성, 도착 패턴, 배칭 및 하드웨어 할당에 따라 달라집니다. 토큰 속도 역시 출력 토큰을 세는 데 사용한 토크나이저에 따라 달라집니다.
시스템을 비교할 때는 동일한 모델 동작, 프롬프트 및 출력 분포, 부하 패턴, 스트리밍 모드, 샘플링 설정, 토크나이저, 측정 경계 및 성공 기준을 사용해야 합니다. 유휴 상태의 단일 요청을 테스트하는 것과 포화된 서버를 테스트하는 것은 서로 다른 작업입니다.
평균은 사용자가 기억하는 요청을 가립니다
평균 TTFT 또는 지연 시간이 양호해 보여도 일부 요청은 대기열에서 훨씬 더 오래 기다릴 수 있습니다. 관련 꼬리 백분위수와 관측 수를 포함하여 분포를 보고하세요. 처리량의 경우 성공한 작업만 집계하면서 이를 명시하지 말고, 오류와 거부된 요청도 보고해야 합니다.
추론 벤치마크 읽는 방법
차트나 모델 카드의 주장을 신뢰하기 전에 다음 내용이 명시되어 있는지 확인하세요.
- 초당 토큰 수가 요청별 수치인지 집계 수치인지
- 출력 토큰만 세는지, 입력 토큰과 출력 토큰을 모두 세는지
- TTFT 또는 첫 번째 토큰이 토큰 속도 계산에 포함되는지
- 지연 시간이 클라이언트 측인지, 서버 측인지, 모델만의 수치인지
- 프롬프트 길이와 출력 길이의 분포
- 동시성과 요청 도착 패턴
- 워밍업, 테스트 기간, 시작 및 종료 경계 처리 방식
- 단일 평균뿐 아니라 평균 및 꼬리 지연 시간
- 성공한 요청과 오류의 기준
- 모델, 정밀도, 하드웨어, 엔진 및 레플리카 수
가장 좋은 지표는 이 네 가지 중 하나를 단독으로 사용하는 것이 아닙니다. 현실적인 부하에서 모든 경계를 명시하고 측정하면서, 사용자에게 보이는 목표 또는 운영 목표에 부합하는 지표가 가장 좋은 지표입니다.
다음에 읽을 내용
요청의 시간 측정 경계는 추론 지연 시간이란 무엇인가요?를, 초기 스트리밍 응답 지연은 첫 번째 토큰까지의 시간이란 무엇인가요?를, 토큰 속도 공식은 초당 토큰 수란 무엇인가요?를, 부하 상황에서의 시스템 처리 용량은 추론 처리량이란 무엇인가요?를 읽어 보세요.