LLM 벤치마킹을 위한 핵심 메트릭

셀프 호스팅 LLM을 벤치마킹할 때 단순한 처리량 수치를 넘어서 살펴보는 것이 중요합니다. 다양한 메트릭은 응답이 얼마나 빨리 시작되는지부터 시간이 지남에 따라 토큰이 얼마나 효율적으로 생성되는지까지 모델 성능의 다양한 측면을 포착합니다. 아래는 성능 테스트를 실행하기 전에 모든 고객이 이해해야 하는 핵심 메트릭입니다.

Time to First Token (TTFT)

Time to First Token은 모델이 프롬프트를 처리하고 출력의 첫 번째 토큰을 생성하는 데 걸리는 시간을 측정합니다. 이는 요청을 보내고 첫 번째 단어가 나타나는 것을 보는 사이의 지연인 사용자의 초기 대기 시간을 나타냅니다.

수식: first_non_empty_token_received_time - request_send_time

포함 내용:

• 요청 대기열 시간 (다른 요청이 처리 중인 경우 대기 시간)
• Prefill 시간 (KV 캐시를 생성하기 위해 전체 입력 프롬프트를 처리하는 모델)
• 네트워크 지연 시간

기술적 고려 사항:

• 더 긴 프롬프트는 더 큰 TTFT를 초래합니다; 어텐션 계산은 입력 시퀀스 길이에 따라 확장됩니다
• Inference Perf와 같은 벤치마킹 도구는 의미 있는 측정을 보장하기 위해 초기 빈 응답을 무시합니다
• TTFT는 현재 배포 구성에 대한 최소 지연 시간 기준선을 나타냅니다; 사용자는 동일한 설정 내에서 TTFT보다 빠른 응답 시간을 볼 수 없지만, 이 기준선은 모델 양자화, 더 빠른 하드웨어 또는 개선된 병렬화 전략과 같은 최적화를 통해 줄일 수 있습니다
• 고급 최적화 참고: 일부 프로덕션 배포는 리소스 활용을 최적화하기 위해 prefill과 토큰 생성 단계가 별도의 인프라에서 실행되는 분리된 prefill/decode 아키텍처를 사용합니다; 이는 이 가이드의 범위를 벗어나지만 특수화된 설정에서 TTFT에 상당한 영향을 미칠 수 있습니다.

Intertoken Latency (ITL)

Intertoken Latency(출력 토큰당 시간 또는 TPOT라고도 함)는 모델이 생성하는 연속 토큰 간의 평균 지연을 측정합니다. 이는 생성이 시작된 후 모델이 출력을 얼마나 부드럽고 꾸준히 스트리밍하는지를 반영합니다.

수식 (Inference Perf): generation_time / (output_tokens - 1)

핵심 세부 사항: 수식은 분모에서 1을 빼서 TTFT를 제외하므로 ITL은 디코딩/생성 단계만의 메트릭이 됩니다.

기술적 고려 사항:

• 출력이 증가함에 따라 KV 캐시가 증가하여 메모리 대역폭과 어텐션 계산 비용에 영향을 미칩니다 (입력 + 출력 길이에 비례)
• 일관된 ITL은 효율적인 메모리 관리와 대역폭 활용을 나타냅니다
• 긴 생성 중 ITL이 증가하면 메모리 대역폭 제약 또는 KV 캐시 압력을 시사합니다
• 다른 도구는 ITL을 다르게 계산합니다; Inference Perf는 TTFT를 제외하는 반면 일부 도구(예: LLMPerf)는 평균에 포함합니다

Tokens per Second (TPS)

Tokens per Second는 시스템의 전체 처리량, 즉 모델이 모든 활성 요청에서 매초 생성하는 출력 토큰 수를 포착합니다. 더 많은 요청이 병렬로 실행됨에 따라 TPS는 일반적으로 하드웨어가 포화 지점에 도달할 때까지 증가합니다. 그 이후에는 리소스가 과도하게 활용됨에 따라 성능이 정체되거나 심지어 떨어질 수 있습니다. 이 메트릭은 팀이 시스템 용량을 이해하고 확장 또는 배칭 전략을 계획하는 데 도움이 됩니다.

수식 (Inference Perf): total_output_tokens / (last_response_time - first_request_time)

이해해야 할 두 가지 관점:

• 시스템 TPS (총 처리량): 모든 동시 요청에 걸친 집계 용량, 포화까지 동시성과 함께 증가
• 사용자당 TPS: 개별 요청 처리량 (output_tokens / e2e_latency), 시스템 부하가 증가함에 따라 감소

중요한 관계: 동시 부하가 사용 가능한 모델 복제본을 초과하여 증가하면, 시스템 TPS는 상승하고 사용자당 TPS는 하락합니다 (동시 요청 수가 시스템의 즉각적인 서빙 용량을 초과한다고 가정)

기술적 고려 사항:

• Inference Perf는 슬라이딩 윈도우 기법을 사용하여 안정적인 측정을 위해 워밍업 및 쿨다운 요청을 제외합니다
• 다른 도구는 전체 벤치마크 기간을 포함하여 오버헤드를 추가할 수 있습니다 (단일 동시성 시나리오에서 최대 33%)
• 포화 지점은 TTFT가 급증하고, TPS가 정체되며, 오류율이 나타나기 시작하는 곳입니다

중요한 이유: TPS는 용량 계획에 필수적입니다; 최대 지속 가능한 처리량을 이해하면 인프라 크기 조정 및 프로덕션 운영 지점(일반적으로 포화의 50-70%)을 결정하는 데 도움이 됩니다.