Perf Analyzer 측정·메트릭

Perf Analyzer 측정·메트릭

Perf Analyzer에는 현재 2가지 측정 모드가 있어요.

시간 윈도우 (Time Windows)

시간 윈도우 측정 모드(--measurement-mode=time_windows)를 쓰면 Perf Analyzer는 X(밀리초, --measurement-interval=X로 지정, 기본 5000) 길이의 윈도우 동안 완료된 요청 수를 셉니다. 이것이 기본 측정 모드예요.

카운트 윈도우 (Count Windows)

카운트 윈도우 측정 모드(--measurement-mode=count_windows)를 쓰면 Perf Analyzer는 윈도우를 1초에서 시작해, X개 요청이 완료될 때까지(--measurement-request-count=X로 지정, 기본 50) 잠재적으로 동적으로 늘려갑니다.

메트릭

처리량 계산 방법

Perf Analyzer는 처리량을 측정 중 완료된 총 요청 수를 측정 기간(초)으로 나눈 값으로 계산해요.

지연시간 계산 방법

각 요청 동시성(concurrency) 수준에 대해 Perf Analyzer는 자체 관점에서 본 지연시간·처리량과 서버의 평균 요청 지연시간을 보고합니다.

서버 지연시간은 요청이 서버에 도착한 시점부터 서버가 응답을 보낸 시점까지의 총 시간을 측정해요. HTTP·gRPC 서버 엔드포인트를 구현하는 데 쓰는 라이브러리 때문에, 총 서버 지연시간은 첫 바이트 수신부터 마지막 바이트 전송까지 측정하는 HTTP 요청에서 대개 더 정확합니다. HTTP·gRPC 모두 총 서버 지연시간은 다음 구성 요소로 나뉩니다.

  • queue: 요청이 모델 인스턴스를 기다리며 추론 스케줄 큐에 보낸 평균 시간.
  • compute: GPU로/로부터 데이터를 복사하는 데 필요한 시간까지 포함해 실제 추론을 수행한 평균 시간.
  • overhead: gRPC·HTTP 라이브러리가 구성된 방식 때문에 send/receive 시간에 정확히 잡히지 않는, 엔드포인트에서 쓴 평균 시간.

클라이언트 지연시간은 HTTP·gRPC에 대해 다음과 같이 더 세분화됩니다.

  • HTTP: _send/recv_는 클라이언트가 요청을 보내고 응답을 받는 데 쓴 시간, _response wait_는 서버 응답을 기다린 시간을 나타냄.
  • gRPC: _(un)marshal request/response_는 요청 데이터를 gRPC protobuf로 마샬링하고 응답 데이터를 언마샬링하는 데 쓴 시간, _response wait_는 gRPC 요청을 네트워크에 쓰고, 응답을 기다리고, 네트워크에서 gRPC 응답을 읽는 데 쓴 시간을 나타냄.

각 요청 동시성 수준 또는 요청 비율에 대해 실행되는 안정화 패스(stabilization pass)를 포함한 더 많은 출력을 보려면 상세(-v) 옵션을 사용하세요.

보고서

지연시간 vs 처리량 시각화

Perf Analyzer는 결과의 CSV 출력이 담긴 파일을 생성하는 -f 옵션을 제공해요.

$ perf_analyzer -m inception_graphdef --concurrency-range 1:4 -f perf.csv
...
$ cat perf.csv
Concurrency,Inferences/Second,Client Send,Network+Server Send/Recv,Server Queue,Server Compute Input,Server Compute Infer,Server Compute Output,Client Recv,p50 latency,p90 latency,p95 latency,p99 latency
1,69.2,225,2148,64,206,11781,19,0,13891,18795,19753,21018
3,84.2,237,1768,21673,209,11742,17,0,35398,43984,47085,51701
4,84.2,279,1604,33669,233,11731,18,1,47045,56545,59225,64886
2,87.2,235,1973,9151,190,11346,17,0,21874,28557,29768,34766

참고: CSV 파일의 행은 처리량(Inferences/Second) 증가 순으로 정렬됩니다.

CSV 파일을 스프레드시트로 가져오면 지연시간과 초당 추론의 트레이드오프를 시각화하고 지연시간의 일부 구성 요소도 볼 수 있어요.

서버 측 Prometheus 메트릭

Perf Analyzer는 GPU 사용률·GPU 전력 사용량 같은 서버 측 메트릭을 수집할 수 있어요. 이 메트릭 수집을 활성화하려면 --collect-metrics 옵션을 사용하세요.

기본적으로 Perf Analyzer는 localhost:8002/metrics URL의 메트릭 엔드포인트를 조회해요. 메트릭이 다른 URL에서 접근 가능하다면 --metrics-url=<url> 옵션으로 지정합니다.

기본적으로 Perf Analyzer는 1000밀리초마다 메트릭 엔드포인트를 조회해요. 다른 조회 주기를 쓰려면 --metrics-interval=<n> 옵션을 사용합니다(밀리초 단위).

Perf Analyzer는 실행당 서버 측 메트릭을 여러 번 수집할 수 있으므로, 이 메트릭들은 특정 방식으로 집계되어 탐색된 동시성 또는 요청 비율당 최종 숫자 하나를 만듭니다. 집계 방식은 다음과 같습니다.

메트릭 집계
GPU Utilization 안정 패스 동안의 각 수집에서 평균. 모든 안정 패스를 대표하는 숫자를 원함.
GPU Power Usage 안정 패스 동안의 각 수집에서 평균. 모든 안정 패스를 대표하는 숫자를 원함.
GPU Used Memory 안정 패스 동안의 모든 수집에서 최대. 사용자는 대개 모델/하드웨어 적합성 판단을 위해 최대 메모리 사용량이 궁금함.
GPU Total Memory 안정 패스 동안의 아무 수집에서 첫 번째. 모든 수집은 GPU의 사용 가능한 총 메모리에 대해 같은 값을 생산해야 함.

멀티 GPU 시스템의 경우 모든 메트릭은 GPU별로 제공된다는 점에 유의하세요.

이 서버 측 메트릭을 CSV 파일로 출력하려면 -f <path>와 --verbose-csv 옵션을 사용합니다. 출력 CSV에는 메트릭당 한 열이 있고, 각 열의 값은 key:value 쌍(GPU UUID:metric value)입니다. 각 key:value 쌍은 서버가 접근 가능한 각 GPU의 메트릭 값을 나타내도록 세미콜론(;)으로 구분됩니다. 끝에 세미콜론이 있습니다. 아래 참고:

<gpu-uuid-0>:<metric-value>;<gpu-uuid-1>:<metric-value>;...;

간단한 CSV 출력 예시:

$ perf_analyzer -m resnet50_libtorch --collect-metrics -f output.csv --verbose-csv
$ cat output.csv
Concurrency,...,Avg GPU Utilization,Avg GPU Power Usage,Max GPU Memory Usage,Total GPU Memory
1,...,gpu_uuid_0:0.33;gpu_uuid_1:0.5;,gpu_uuid_0:55.3;gpu_uuid_1:56.9;,gpu_uuid_0:10000;gpu_uuid_1:11000;,gpu_uuid_0:50000;gpu_uuid_1:75000;,
2,...,gpu_uuid_0:0.25;gpu_uuid_1:0.6;,gpu_uuid_0:25.6;gpu_uuid_1:77.2;,gpu_uuid_0:11000;gpu_uuid_1:17000;,gpu_uuid_0:50000;gpu_uuid_1:75000;,
3,...,gpu_uuid_0:0.87;gpu_uuid_1:0.9;,gpu_uuid_0:87.1;gpu_uuid_1:71.7;,gpu_uuid_0:15000;gpu_uuid_1:22000;,gpu_uuid_0:50000;gpu_uuid_1:75000;,

통신 프로토콜

기본적으로 Perf Analyzer는 HTTP로 Triton과 통신해요. gRPC 프로토콜은 -i [http|grpc] 옵션으로 지정할 수 있고, gRPC가 선택되면 gRPC 스트리밍을 위해 --streaming 옵션도 지정할 수 있습니다.

SSL/TLS 지원

Perf Analyzer는 SSL/TLS가 활성화된 엔드포인트 뒤의 Triton 서비스를 벤치마킹하는 데 쓰일 수 있어요. 이 옵션들은 엔드포인트와 보안 연결을 설정하고 서버를 프로파일하는 데 도움이 됩니다.

gRPC는 다음 옵션을 참고하세요.

  • --ssl-grpc-use-ssl
  • --ssl-grpc-root-certifications-file=<path>
  • --ssl-grpc-private-key-file=<path>
  • --ssl-grpc-certificate-chain-file=<path>

자세한 내용은: https://grpc.github.io/grpc/cpp/structgrpc_1_1_ssl_credentials_options.html

추론 프로토콜 gRPC SSL/TLS 섹션은 Triton의 gRPC 엔드포인트에서 SSL/TLS를 구성하는 서버 측 옵션을 설명해요.

HTTPS는 다음 옵션이 노출됩니다.

  • --ssl-https-verify-peer
  • --ssl-https-verify-host
  • --ssl-https-ca-certificates-file
  • --ssl-https-client-certificate-file
  • --ssl-https-client-certificate-type
  • --ssl-https-private-key-file
  • --ssl-https-private-key-type

전체 문서는 --help를 참고하세요.

gRPC와 달리 Triton의 HTTP 서버 엔드포인트는 SSL/TLS로 구성할 수 없어요.

참고: Perf Analyzer에 이 --ssl-http-* 옵션 몇 개를 제공하는 것만으로 통신에 SSL/TLS가 사용된다는 보장은 없어요. 서비스 엔드포인트에서 SSL/TLS가 활성화되지 않았다면 이 옵션들은 아무 효과가 없습니다. 이 옵션들을 사용자에게 노출하는 의도는 SSL/TLS가 활성화된 엔드포인트 뒤의 Triton 서비스를 벤치마킹하도록 Perf Analyzer를 구성하게 하는 것입니다. 즉 Triton이 HTTPS 서버 프록시 뒤에서 실행 중이라면, 이 옵션들을 통해 노출된 HTTPS 프록시를 거쳐 Triton을 프로파일할 수 있어요.

출처: 공식 문서 - Perf Analyzer Measurements & Metrics

더 알아보기 (Learn more)