모니터링 메트릭과 Prometheus

Triton은 GPU·요청 통계를 담은 Prometheus 메트릭을 제공해요. 기본적으로 http://localhost:8002/metrics에서 확인할 수 있고, 메트릭은 endpooint에 접근할 때만 노출되며 어떤 원격 서버로 푸시되거나 발행되지는 않아요. 형식이 평문(plain text)이라 그대로 훑어볼 수 있죠.

$ curl localhost:8002/metrics

tritonserver --allow-metrics=false 옵션으로 모든 메트릭 보고를 끌 수 있고, --allow-gpu-metrics=false·--allow-cpu-metrics=false로 각각 GPU·CPU 메트릭만 끌 수도 있어요. 포트를 바꾸려면 --metrics-port를 쓰면 됩니다. 기본적으로 Triton은 --http-address 옵션을 메트릭 엔드포인트에도 재사용해, http 서비스가 켜져 있으면 두 엔드포인트를 같은 주소에 바인딩해요. http 서비스가 꺼져 있으면 메트릭 주소는 기본적으로 0.0.0.0에 바인딩되고요. 엔드포인트를 명시적으로 분리하고 싶다면 --metrics-address 옵션을 씁니다. 자세한 내용은 tritonserver --help를 참고하세요.

메트릭을 폴링/갱신하는 주기를 바꾸려면 --metrics-interval-ms 플래그를 봅니다. 이 주기 설정은 "Per Request"로 갱신되는 메트릭에는 영향이 없고, 아래 각 섹션의 표에서 "Per Interval"로 표시된 메트릭에만 적용돼요.

추론 요청 메트릭
GPU 메트릭
CPU 메트릭
고정 메모리 메트릭
응답 캐시 메트릭
커스텀 메트릭

추론 요청 메트릭

Count(개수)

배칭을 지원하지 않는 모델은 Request Count, Inference Count, Execution Count가 전부 같아요. 각 추론 요청이 따로 실행되기 때문이죠. 배칭을 지원하는 모델이라면 Inference Count / Execution Count로 평균 배치 크기를 계산할 수 있어요. 몇 가지 예시로 감을 잡아볼게요.

클라이언트가 batch-1 추론 요청을 하나 보내면 Request Count = 1, Inference Count = 1, Execution Count = 1.
batch-8 추론 요청을 하나 보내면 Request Count = 1, Inference Count = 8, Execution Count = 1.
batch-1과 batch-8 요청 2개를 보내고(동적 배처 비활성) Request Count = 2, Inference Count = 9, Execution Count = 2.
batch-1 요청 2개를 보내고 동적 배처가 활성 상태라 서버가 두 요청을 하나로 합치면 Request Count = 2, Inference Count = 2, Execution Count = 1.
batch-1과 batch-8 요청 2개를 보내고 동적 배처가 활성이라 합치면 Request Count = 2, Inference Count = 9, Execution Count = 1.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Count	Success Count	`nv_inference_request_success`	Triton이 받은 성공 추론 요청 수(batch 포함 요청도 1개로 카운트)	모델별	요청별
	Failure Count	`nv_inference_request_failure`	Triton이 받은 실패 추론 요청 수(batch 포함 요청도 1개로 카운트)	모델별	요청별
	Inference Count	`nv_inference_count`	수행된 추론 횟수("n" 배치는 "n" 추론으로 카운트, 캐시된 요청은 제외)	모델별	요청별
	Execution Count	`nv_inference_exec_count`	추론 배치 실행 횟수(캐시된 요청은 제외)	모델별	요청별
	Pending Request Count	`nv_inference_pending_request_count`	백엔드가 실행을 기다리는 추론 요청 수(서버에 큐잉될 때 증가, 백엔드가 실행 직전일 때 감소)	모델별	요청별

Failure Count 범주

실패 사유	설명
REJECTED	스케줄러에서 요청 타임아웃으로 인한 추론 실패 수
CANCELED	코어에서 요청 취소로 인한 추론 실패 수
BACKEND	백엔드/모델에서 요청 실행 중 발생한 추론 실패 수
OTHER	코어에서 기타 미분류 사유로 인한 추론 실패 수

참고

앙상블 실패 메트릭은 하위 모델뿐 아니라 부모 모델의 실패 카운트도 반영하지만, "reason" 레이블의 세분화는 현재 잡지 못해 기본적으로 "OTHER" 사유로 잡혀요.

예를 들어 EnsembleA가 ModelA를 품고 있고, ModelA가 스케줄러의 큐/백로그 타임아웃으로 요청 실패를 겪었다면, ModelA에는 reason=REJECTED·count=1로 실패 메트릭이 잡힙니다. 추가로 EnsembleA에는 reason=OTHER·count=2로 실패 메트릭이 잡혀요. count=2는 ModelA가 잡은 내부 실패 1건 + 사용자/클라이언트가 EnsembleA로 보낸 최상위 요청 실패 1건을 합한 값입니다. reason=OTHER는 앙상블이 현재 ModelA 요청이 왜 실패했는지 구체적인 사유를 잡지 못한다는 뜻이에요.

모델별 Pending Request Count (큐 크기)

Pending Request Count는 Triton 코어가 TRITONSERVER_InferAsync로 받았지만 아직 백엔드 모델 인스턴스(TRITONBACKEND_ModelInstanceExecute)가 실행을 시작하지 않은 요청 수를 나타내요. 실질적으로 "pending request count"와 모델별 "queue size"는 바꿔 써도 무방하고, 메트릭 값은 현재 어떤 모델 인스턴스도 실행 중이지 않은 요청 수라고 보면 직관적이에요. 즉 5개밖에 동시 처리하지 못하는 모델에 100개 요청을 보내면 대부분 그 모델의 pending count가 95로 보이는 식이죠.

기술적으로 더 정확히 말하면, Triton은 매우 설정 가능해서 요청이 단일 큐보다 여러 곳에서 pending으로 간주될 수 있어요. 그래서 "queue size"보다 "pending request count"라는 표현이 더 정확합니다. 자주 등장하는 경우를 짚어볼게요.

기본 스케줄러: 실행 중이 아닌 요청을 백로그로 관리해요. 모델 인스턴스 1개가 준비된 상태에서 10개 요청이 빠르게 도착하면, 1번째 요청은 즉시 실행되고 나머지 9개는 pending으로 잡혀요. 1번째가 끝나면 다음 요청이 실행되면서 pending은 8로 줄고, 전부 끝나면 0이 되는 식이죠.
동적 배처 큐: 요청으로부터 동적으로 배치를 만드는 큐예요. 인스턴스 1개에 max_batch_size: 4와 충분히 큰 max_queue_delay_microseconds가 설정돼 10개 요청이 빠르게 도착하면, 처음 4개(또는 스케줄러가 만들 수 있는 최대 배치)가 즉시 실행되고 나머지 6개는 pending이에요. 배치가 끝나면 다음 배치가 실행되며 pending은 2로 줄고, 마지막 2개가 배치로 실행되며 pending은 0이 됩니다.
시퀀스 배처: 진행 중인 시퀀스 요청을 큐잉/백로그하고, 일부는 시퀀스 슬롯을 받고 일부는 못 받을 수 있어요. direct·oldest 두 전략 모두 대체로 동적 배칭 설명과 같은 추이를 보이고, 모델/스케줄러 설정 기준으로 가능한 만큼 즉시 실행하고 나머지는 pending으로 잡아요.
레이트 리미터: 준비된 배치 요청을 큐잉해요. 레이트 제한이 활성화되면 설정한 제약을 만족시키기 위해 요청 실행을 보류할 수 있죠.

pending으로 간주되지 않는 곳도 있어요.

앙상블 스케줄러: 요청을 받으면 앙상블 첫 단계에서 거의 즉시 하위 모델 스케줄러에 큐잉해요. 그래서 하위 모델 스케줄러 입장에선 pending일 수 있지만, 앙상블 관점에선 이미 스케줄된 요청입니다.
프론트엔드(HTTP/gRPC 서버): 클라이언트가 Triton 앞의 프론트엔드 서버로 보낸 요청은 해당 서버가 프로토콜별 메타데이터를 Triton 메타데이터로 매핑하는 동안 시간을 보낼 수 있어요. 대개 짧지만, Triton 코어가 프론트엔드에서 요청을 받기 전까지는 Triton 관점에서 pending으로 간주되지 않습니다.

Latency(지연시간)

23.04부터 Triton은 --metrics-config CLI 옵션으로 어떤 메트릭을 발행할지 고를 수 있어요.

Counter(카운터)

기본적으로 지연시간에 아래 Counter 메트릭을 사용합니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Latency	Request Time	`nv_inference_request_duration_us`	엔드투엔드 추론 요청 처리 시간의 누적치(캐시된 요청 포함)	모델별	요청별
	Queue Time	`nv_inference_queue_duration_us`	요청이 스케줄링 큐에서 대기한 시간의 누적치(캐시된 요청 포함)	모델별	요청별
	Compute Input Time	`nv_inference_compute_input_duration_us`	요청이 추론 입력을 처리하는 시간의 누적치(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별
	Compute Time	`nv_inference_compute_infer_duration_us`	요청이 추론 모델을 실행하는 시간의 누적치(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별
	Compute Output Time	`nv_inference_compute_output_duration_us`	요청이 추론 출력을 처리하는 시간의 누적치(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별

이 메트릭만 끄려면 --metrics-config counter_latencies=false로 설정하면 됩니다.

Histogram(히스토그램)

참고

아래 Histogram 기능은 지금 실험적이며 사용자 피드백에 따라 바뀔 수 있어요.

기본적으로 지연시간에 아래 Histogram 메트릭을 사용합니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Latency	Request to First Response Time	`nv_inference_first_response_histogram_ms`	추론 요청부터 첫 응답까지 걸린 시간의 히스토그램	모델별	요청별

이 메트릭만 켜려면 --metrics-config histogram_latencies=true로 설정하면 됩니다.

각 히스토그램은 여러 개의 하위 메트릭으로 구성돼요. 각 버킷의 카운터를 추적하는 le(less than or equal to) 임계값 집합이 있고, 각각의 카운트·관측값을 합산하는 _count·_sum 메트릭도 있어요. 예를 들어 "Time to First Response" 히스토그램이 노출하는 정보를 보면:

# HELP nv_first_response_histogram_ms Duration from request to first response in milliseconds
# TYPE nv_first_response_histogram_ms histogram
nv_inference_first_response_histogram_ms_count{model="my_model",version="1"} 37
nv_inference_first_response_histogram_ms_sum{model="my_model",version="1"} 10771
nv_inference_first_response_histogram_ms{model="my_model",version="1", le="100"} 8
nv_inference_first_response_histogram_ms{model="my_model",version="1", le="500"} 30
nv_inference_first_response_histogram_ms{model="my_model",version="1", le="2000"} 36
nv_inference_first_response_histogram_ms{model="my_model",version="1", le="5000"} 37
nv_inference_first_response_histogram_ms{model="my_model",version="1", le="+Inf"} 37

Triton은 위와 같은 기본 버킷으로 히스토그램을 초기화해요. 버킷은 모델 설정에서 model_metrics를 지정해 패밀리별로 재정의할 수 있습니다.

// config.pbtxt
model_metrics {
  metric_control: [
    {
      metric_identifier: {
        family: "nv_inference_first_response_histogram_ms"
      }
      histogram_options: {
        buckets: [ 1, 2, 4, 8 ]
      }
    }
  ]
}

참고

메트릭 옵션 변경을 동적으로 적용하려면 모델을 완전히 언로드한 뒤 다시 로드해야 반영돼요.

현재 커스텀 버킷을 지원하는 히스토그램 패밀리는 다음과 같습니다.

nv_inference_first_response_histogram_ms  // Time to First Response

Summary(요약)

참고

아래 Summary 기능은 지금 실험적이며 사용자 피드백에 따라 바뀔 수 있어요.

슬라이딩 시간 윈도우 위에서 설정 가능한 quantile을 얻고 싶다면, Triton은 지연시간용 Summary 메트릭도 지원해요. 기본적으로 비활성화돼 있고 --metrics-config summary_latencies=true로 켤 수 있습니다. quantile 계산 방식은 이 설명을 참고하세요.

사용 가능한 summary 메트릭은 다음과 같습니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Latency	Request Time	`nv_inference_request_summary_us`	엔드투엔드 추론 요청 처리 시간 요약(캐시된 요청 포함)	모델별	요청별
	Queue Time	`nv_inference_queue_summary_us`	요청이 스케줄링 큐에서 대기한 시간 요약(캐시된 요청 포함)	모델별	요청별
	Compute Input Time	`nv_inference_compute_input_summary_us`	요청이 추론 입력을 처리하는 시간 요약(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별
	Compute Time	`nv_inference_compute_infer_summary_us`	요청이 추론 모델을 실행하는 시간 요약(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별
	Compute Output Time	`nv_inference_compute_output_summary_us`	요청이 추론 출력을 처리하는 시간 요약(프레임워크 백엔드, 캐시된 요청 미포함)	모델별	요청별

각 summary는 여러 하위 메트릭으로 구성돼요. 각 quantile의 지연시간을 추적하는 quantile 메트릭 집합이 있고, 카운트·관측값을 합산하는 _count·_sum 메트릭도 있어요. 예를 들어 Inference Queue Summary 메트릭이 노출하는 정보를 보면:

# HELP nv_inference_queue_summary_us Summary of inference queuing duration in microseconds (includes cached requests)
# TYPE nv_inference_queue_summary_us summary
nv_inference_queue_summary_us_count{model="my_model",version="1"} 161
nv_inference_queue_summary_us_sum{model="my_model",version="1"} 11110
nv_inference_queue_summary_us{model="my_model",version="1",quantile="0.5"} 55
nv_inference_queue_summary_us{model="my_model",version="1",quantile="0.9"} 97
nv_inference_queue_summary_us{model="my_model",version="1",quantile="0.95"} 98
nv_inference_queue_summary_us{model="my_model",version="1",quantile="0.99"} 101
nv_inference_queue_summary_us{model="my_model",version="1",quantile="0.999"} 101

위 summary의 count·sum은 161개 요청에 대해 기록됐고 총합 11110 마이크로초가 걸렸다는 뜻이에요. summary의 _count·_sum은 일반적으로 사용 가능할 때 카운터 메트릭과 일치해야 합니다.

nv_inference_request_success{model="my_model",version="1"} 161
nv_inference_queue_duration_us{model="my_model",version="1"} 11110

Triton은 위와 같은 기본 quantile 집합을 추적해요. 커스텀 quantile을 설정하려면 --metrics-config CLI 옵션을 씁니다. 형식은 다음과 같아요.

tritonserver --metrics-config summary_quantiles="<quantile1>:<error1>,...,<quantileN>:<errorN>"

예를 들어:

tritonserver --metrics-config summary_quantiles="0.5:0.05,0.9:0.01,0.95:0.001,0.99:0.001"

각 quantile 계산의 error 값을 어떻게 설정하는지 더 이해하려면 histograms and summaries 모범 사례를 참고하세요.

GPU 메트릭

GPU 메트릭은 DCGM을 통해 수집돼요. --allow-gpu-metrics CLI 플래그로 수집을 켜고 끌 수 있고, Triton을 로컬에서 빌드한다면 TRITON_ENABLE_METRICS_GPU CMake 빌드 플래그로 관련 코드를 아예 빌드할지 정할 수 있습니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
GPU Utilization	Power Usage	`nv_gpu_power_usage`	GPU 순간 전력(와트)	GPU별	구간별
	Power Limit	`nv_gpu_power_limit`	최대 GPU 전력 한도(와트)	GPU별	구간별
	Energy Consumption	`nv_energy_consumption`	Triton 시작 이후 GPU 에너지 소비(줄)	GPU별	구간별
	GPU Utilization	`nv_gpu_utilization`	GPU 사용률(0.0 - 1.0)	GPU별	구간별
GPU Memory	GPU Total Memory	`nv_gpu_memory_total_bytes`	전체 GPU 메모리(바이트)	GPU별	구간별
	GPU Used Memory	`nv_gpu_memory_used_bytes`	사용 중인 GPU 메모리(바이트)	GPU별	구간별

CPU 메트릭

--allow-cpu-metrics CLI 플래그로 CPU 메트릭 수집을 켜고 끌 수 있어요. 로컬 빌드 시 TRITON_ENABLE_METRICS_CPU CMake 빌드 플래그로 관련 코드를 아예 빌드할지 정합니다.

참고

CPU 메트릭은 현재 Linux에서만 지원돼요. /proc/stat·/proc/meminfo 같은 /proc 파일시스템에서 정보를 수집합니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
CPU Utilization	CPU Utilization	`nv_cpu_utilization`	전체 CPU 사용률 [0.0 - 1.0]	마지막 구간 이후 모든 코어 합산	구간별
CPU Memory	CPU Total Memory	`nv_cpu_memory_total_bytes`	전체 CPU 메모리(RAM)(바이트)	시스템 전체	구간별
	CPU Used Memory	`nv_cpu_memory_used_bytes`	사용 중인 CPU 메모리(RAM)(바이트)	시스템 전체	구간별

고정 메모리 메트릭

24.01부터 Triton은 고정(Pinned) 메모리 풀 사용률을 모니터링하는 메트릭을 제공해요.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Pinned Memory	Total Pinned memory	`nv_pinned_memory_pool_total_bytes`	전체 고정 메모리(바이트)	모든 모델	구간별
	Used Pinned memory	`nv_pinned_memory_pool_used_bytes`	사용 중인 고정 메모리(바이트)	모든 모델	구간별

응답 캐시 메트릭

캐시 메트릭은 두 가지 방식으로 보고됩니다.

cache hit/miss 횟수·시간 등 기본 캐시 메트릭 집합은 Triton이 직접 보고해요.
23.03부터 사용 중인 캐시 구현에 따라 Triton의 Metrics API를 통해 추가 캐시 메트릭이 보고될 수 있어요.

Triton이 보고하는 응답 캐시 메트릭

위 추론 요청 메트릭 표의 Compute 지연 메트릭은 모델 추론 백엔드에서 보낸 시간을 기준으로 계산돼요. 특정 모델에 응답 캐시가 켜져 있으면(자세한 내용은 응답 캐시) 전체 추론 시간이 응답 캐시 조회 시간의 영향을 받을 수 있습니다.

캐시 히트 시 "Cache Hit Time"은 응답을 조회한 시간을 의미하고, "Compute Input Time"·"Compute Time"·"Compute Output Time"은 기록되지 않아요.

캐시 미스 시 "Cache Miss Time"은 요청 해시 조회와 계산된 출력 텐서 데이터를 캐시에 삽입하는 시간을 의미해요. 그 외에는 "Compute Input Time"·"Compute Time"·"Compute Output Time"이 평소처럼 기록됩니다.

카테고리	메트릭	메트릭 이름	설명	세분화	빈도
Count	Cache Hit Count	`nv_cache_num_hits_per_model`	모델별 응답 캐시 히트 수	모델별	요청별
	Cache Miss Count	`nv_cache_num_misses_per_model`	모델별 응답 캐시 미스 수	모델별	요청별
Latency	Cache Hit Time	`nv_cache_hit_duration_per_model`	캐시 히트 시 캐시된 응답을 가져오는 시간 누적치(마이크로초)	모델별	요청별
	Cache Miss Time	`nv_cache_miss_duration_per_model`	캐시 미스 시 응답을 조회·삽입하는 시간 누적치(마이크로초)	모델별	요청별

위 추론 요청 메트릭의 Summary 섹션과 비슷하게, 모델별 캐시 히트/미스 지연 메트릭도 Summary를 지원해요.

참고

응답 캐싱이 켜진 모델의 경우 추론 요청 summary 메트릭은 현재 비활성화돼요. 캐시 관리에 내부적으로 보내는 추가 시간이 엔드투엔드 요청 시간에 정확히 반영되지 않기 때문입니다. 다른 summary 메트릭은 영향을 받지 않아요.

커스텀 메트릭

Triton은 사용자·백엔드가 기존 Triton 메트릭 엔드포인트에 커스텀 메트릭을 등록하고 수집할 수 있는 C API를 노출해요. API를 통해 만든 커스텀 메트릭은 사용자가 소유권을 가지며, API 문서에 따라 수명(lifetime)을 관리해야 합니다.

identity_backend는 백엔드에 커스텀 메트릭을 추가하는 실제 예시를 보여줘요.

더 자세한 문서는 tritonserver.h의 TRITONSERVER_MetricFamily*·TRITONSERVER_Metric* API 주석에서 찾을 수 있습니다.

TensorRT-LLM 백엔드 메트릭

TRT-LLM 백엔드는 커스텀 메트릭 API를 사용해 LLM·KV 캐시·Inflight Batching 관련 특정 메트릭을 추적·노출해요: https://github.com/triton-inference-server/tensorrtllm_backend?tab=readme-ov-file#triton-metrics

vLLM 백엔드 메트릭

vLLM 백엔드는 커스텀 메트릭 API를 사용해 LLM 관련 특정 메트릭을 추적·노출해요: https://github.com/triton-inference-server/vllm_backend?tab=readme-ov-file#triton-metrics

출처: 공식 문서 - Metrics (Monitoring Metrics)

더 알아보기 (Learn more)

요청 트레이싱 (Request Tracing)
로깅 확장 (Logging Extension)
응답 캐시
Prometheus 문서