指标#

Triton 提供 Prometheus 指标，指示 GPU 和请求统计信息。默认情况下，这些指标可通过 https://127.0.0.1:8002/metrics 访问。指标仅通过访问端点可用，不会推送或发布到任何远程服务器。指标格式为纯文本，因此您可以直接查看它们，例如

$ 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 和指标端点绑定到同一特定地址。如果未启用 http 服务，则指标地址默认绑定到 0.0.0.0。要唯一指定指标端点，可以使用 --metrics-address 选项。有关这些 CLI 选项的更多信息，请参阅 tritonserver --help 输出。

要更改指标轮询/更新的间隔，请参阅 --metrics-interval-ms 标志。标记为“按请求”更新的指标不受此间隔设置的影响。此间隔仅适用于在下面每个部分的表格中指定为“按间隔”的指标

推理请求指标#

计数#

对于不支持批处理的模型，请求计数、推理计数 和 执行计数 将相等，表明每个推理请求都是单独执行的。

对于支持批处理的模型，可以解释计数指标以确定平均批大小，即 推理计数 / 执行计数。以下示例说明了计数指标

  • 客户端发送单个批大小为 1 的推理请求。请求计数 = 1，推理计数 = 1，执行计数 = 1。

  • 客户端发送单个批大小为 8 的推理请求。请求计数 = 1，推理计数 = 8，执行计数 = 1。

  • 客户端发送 2 个请求：批大小为 1 和批大小为 8。模型的动态批处理器未启用。请求计数 = 2，推理计数 = 9，执行计数 = 2。

  • 客户端发送 2 个请求：批大小为 1 和批大小为 1。模型的动态批处理器已启用，并且服务器动态批处理了这 2 个请求。请求计数 = 2，推理计数 = 2，执行计数 = 1。

  • 客户端发送 2 个请求：批大小为 1 和批大小为 8。模型的动态批处理器已启用，并且服务器动态批处理了这 2 个请求。请求计数 = 2，推理计数 = 9，执行计数 = 1。

类别

指标

指标名称

描述

粒度

频率

计数

成功计数

nv_inference_request_success

Triton 收到的成功推理请求数（每个请求计为 1，即使请求包含批次）

按模型

按请求

失败计数

nv_inference_request_failure

Triton 收到的失败推理请求数（每个请求计为 1，即使请求包含批次）

按模型

按请求

推理计数

nv_inference_count

执行的推理次数（批大小为 “n” 的批次计为 “n” 次推理，不包括缓存的请求）

按模型

按请求

执行计数

nv_inference_exec_count

推理批次执行次数（请参阅 推理请求指标，不包括缓存的请求）

按模型

按请求

待处理请求计数

nv_inference_pending_request_count

等待后端执行的推理请求数。当请求排队到服务器 (TRITONSERVER_ServerInferAsync) 时，此数字会递增；当后端即将开始执行请求时，此数字会递减。更多详细信息可以在下面找到。

按模型

按请求

失败计数类别#

失败请求原因

描述

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 的请求此时失败的具体原因这一事实。

按模型划分的待处理请求计数（队列大小）#

待处理请求计数 反映了 Triton 核心通过 TRITONSERVER_InferAsync 接收但尚未由后端模型实例 (TRITONBACKEND_ModelInstanceExecute) 开始执行的请求数。

对于所有意图和目的，“待处理请求计数” 和按模型划分的 “队列大小” 可以互换使用，并且指标中反映的数字应直观地表示当前未被任何模型实例执行的请求数。简而言之，如果您向只能同时处理 5 个请求的模型发送 100 个请求，那么在大多数情况下，您应该看到该模型的待处理计数为 95。

对于那些对更多技术细节感兴趣的人来说，“待处理请求计数” 术语比 “队列大小” 更准确，因为 Triton 是高度可配置的，并且在 Triton 中有很多地方可以将请求视为待处理而不是单个队列。下面将列出一些最常见的

  • 默认调度器积压任何当前未执行的请求。

    • 假设 1 个可用模型实例具有默认调度器设置，并且快速连续发送了 10 个请求。

    • 第 1 个请求应立即被拾取以进行执行，其余 9 个请求应被视为此模型的待处理请求，直到第 1 个请求完成。之后，应拾取下一个请求，待处理计数应递减为 8，依此类推，直到所有请求完成且待处理计数为 0。

  • 动态批处理器队列，用于从请求中动态创建批次。

    • 假设 1 个可用模型实例，动态批处理调度器配置为 max_batch_size: 4 和足够大的 max_queue_delay_microseconds（或请求队列），并且快速连续发送了 10 个请求。

    • 前 4 个请求，或调度器可以形成的最大批次，应立即被拾取以进行执行，其余 6 个请求应被视为待处理。批次完成后，应拾取下一个批次，将待处理计数再次递减为 2 个待处理。然后，由于只剩下 2 个请求，最后的 2 个请求将被批处理并由后端拾取，将待处理计数递减为 0。

  • 序列批处理器队列和积压，用于正在进行的序列请求，有些可能已分配序列槽，有些可能没有。

    • 两种策略（直接和最旧）的序列批处理器都将具有待处理计数，这些计数通常遵循与上述动态批处理描述相同的趋势。序列批处理器将根据模型/调度器配置设置立即执行批次中尽可能多的请求，并且任何进一步的请求将被视为待处理，直到先前的批次完成并且可以开始下一个批次。

  • 速率限制器队列，用于准备好的请求批次。

    • 启用速率限制后，可以阻止请求执行，以满足配置的速率限制约束。

在某些情况下，请求不会被视为待处理

  • 集成调度器

    • 集成调度器几乎立即将其收到的任何请求排队到集成中第一步的组成模型调度器中。因此，请求可以被组成模型调度器视为待处理，但从集成的角度来看，这些请求已被调度。

  • 前端（HTTP/GRPC 服务器）

    • 从客户端发送到 Triton 前面的前端服务器的任何请求都可能在相应服务器的代码中花费一些时间，将协议特定的元数据映射到 Triton 元数据。尽管此时间通常很短，但在 Triton 核心从前端收到请求之前，它不会被 Triton 视为待处理。

延迟#

从 23.04 开始，Triton 公开了通过 --metrics-config CLI 选项选择发布的指标类型的功能。

计数器#

默认情况下，以下 计数器 指标用于延迟

类别

指标

指标名称

描述

粒度

频率

延迟

请求时间

nv_inference_request_duration_us

端到端推理请求处理的累积时间（包括缓存的请求）

按模型

按请求

队列时间

nv_inference_queue_duration_us

请求在调度队列中等待的累积时间（包括缓存的请求）

按模型

按请求

计算输入时间

nv_inference_compute_input_duration_us

请求在处理推理输入时花费的累积时间（在框架后端中，不包括缓存的请求）

按模型

按请求

计算时间

nv_inference_compute_infer_duration_us

请求在执行推理模型时花费的累积时间（在框架后端中，不包括缓存的请求）

按模型

按请求

计算输出时间

nv_inference_compute_output_duration_us

请求在处理推理输出时花费的累积时间（在框架后端中，不包括缓存的请求）

按模型

按请求

要专门禁用这些指标，您可以设置 --metrics-config counter_latencies=false

直方图#

注意

以下直方图功能目前为实验性功能，可能会根据用户反馈进行更改。

默认情况下，以下 直方图 指标用于延迟

类别

指标

指标名称

描述

粒度

频率

模型类型

延迟

从请求到首次响应的时间

nv_inference_first_response_histogram_ms

从端到端推理请求到首次响应的时间的直方图

按模型

按请求

解耦

要专门启用这些指标，您可以设置 --metrics-config histogram_latencies=true

上面的每个直方图都由几个子指标组成。对于每个直方图指标，都有一组 le（小于或等于）阈值，用于跟踪每个桶的计数器。此外，还有 _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

摘要#

注意

以下摘要功能目前为实验性功能，可能会根据用户反馈进行更改。

为了获得滑动时间窗口上的可配置分位数，Triton 还支持一组用于延迟的 摘要 指标。这些指标默认禁用，但可以通过设置 --metrics-config summary_latencies=true 来启用。

有关如何计算分位数的更多信息，请参阅 此说明。

以下摘要指标可用

类别

指标

指标名称

描述

粒度

频率

延迟

请求时间

nv_inference_request_summary_us

端到端推理请求处理时间的摘要（包括缓存的请求）

按模型

按请求

队列时间

nv_inference_queue_summary_us

请求在调度队列中等待的时间的摘要（包括缓存的请求）

按模型

按请求

计算输入时间

nv_inference_compute_input_summary_us

请求在处理推理输入时花费的时间的摘要（在框架后端中，不包括缓存的请求）

按模型

按请求

计算时间

nv_inference_compute_infer_summary_us

请求在执行推理模型时花费的时间的摘要（在框架后端中，不包括缓存的请求）

按模型

按请求

计算输出时间

nv_inference_compute_output_summary_us

请求在处理推理输出时花费的时间的摘要（在框架后端中，不包括缓存的请求）

按模型

按请求

上面的每个摘要实际上都由几个子指标组成。对于每个指标，都有一组 quantile 指标，用于跟踪每个分位数的延迟。此外，还有 _count 和 _sum 指标，用于聚合每个指标的计数和观察值。例如，请参阅推理队列摘要指标公开的以下信息

# 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

上面摘要的计数和总和表明已记录了 161 个请求的统计信息，总共花费了 11110 微秒。_count 和 _sum 摘要通常应与适用的计数器指标等效项匹配，例如

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

Triton 有一组默认分位数来跟踪，如上所示。要设置自定义分位数，可以使用 --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"`

要更好地理解设置用于计算每个分位数的误差值，请参阅 直方图和摘要的最佳实践。

GPU 指标#

GPU 指标通过使用 DCGM 收集。可以使用 --allow-gpu-metrics CLI 标志切换 GPU 指标的收集。如果在本地构建 Triton，则可以使用 TRITON_ENABLE_METRICS_GPU CMake 构建标志来完全切换相关代码的构建。

类别

指标

指标名称

描述

粒度

频率

GPU 利用率

功耗

nv_gpu_power_usage

GPU 瞬时功耗，单位为瓦特

按 GPU

按间隔

功率限制

nv_gpu_power_limit

最大 GPU 功率限制，单位为瓦特

按 GPU

按间隔

能耗

nv_energy_consumption

自 Triton 启动以来 GPU 的能耗，单位为焦耳

按 GPU

按间隔

GPU 利用率

nv_gpu_utilization

GPU 利用率 (0.0 - 1.0)

按 GPU

按间隔

GPU 内存

GPU 总内存

nv_gpu_memory_total_bytes

GPU 总内存，单位为字节

按 GPU

按间隔

GPU 已用内存

nv_gpu_memory_used_bytes

GPU 已用内存，单位为字节

按 GPU

按间隔

CPU 指标#

可以使用 --allow-cpu-metrics CLI 标志切换 CPU 指标的收集。如果在本地构建 Triton，则可以使用 TRITON_ENABLE_METRICS_CPU CMake 构建标志来完全切换相关代码的构建。

注意

CPU 指标目前仅在 Linux 上受支持。它们从 /proc 文件系统（例如 /proc/stat 和 /proc/meminfo）收集信息。

类别

指标

指标名称

描述

粒度

频率

CPU 利用率

CPU 利用率

nv_cpu_utilization

总 CPU 利用率 [0.0 - 1.0]

自上次间隔以来在所有核心上聚合

按间隔

CPU 内存

CPU 总内存

nv_cpu_memory_total_bytes

CPU 总内存 (RAM)，单位为字节

系统级

按间隔

CPU 已用内存

nv_cpu_memory_used_bytes

CPU 已用内存 (RAM)，单位为字节

系统级

按间隔

固定内存指标#

从 24.01 开始，Triton 提供固定内存指标来监控固定内存池的利用率。

类别

指标

指标名称

描述

粒度

频率

固定内存

总固定内存

nv_pinned_memory_pool_total_bytes

总固定内存，单位为字节

所有模型

按间隔

已用固定内存

nv_pinned_memory_pool_used_bytes

已用固定内存，单位为字节

所有模型

按间隔

响应缓存指标#

可以通过两种方式报告缓存指标

  1. 一组基本缓存指标将由 Triton 直接报告，例如下面描述的缓存命中/未命中计数和持续时间。

  2. 从 23.03 开始，可能会报告其他缓存指标，具体取决于通过 Triton 的 指标 API 使用的 缓存实现。

Triton 报告的响应缓存指标#

上面 推理请求指标表 中的计算延迟指标是针对模型推理后端中花费的时间计算的。如果为给定模型启用了响应缓存（有关更多信息，请参阅 响应缓存 文档），则总推理时间可能会受到响应缓存查找时间的影响。

在缓存命中时，“缓存命中时间” 指示查找响应所花费的时间，“计算输入时间”/“计算时间”/“计算输出时间” 不会记录。

在缓存未命中时，“缓存未命中时间” 指示查找请求哈希并将计算出的输出张量数据插入缓存所花费的时间。否则，“计算输入时间”/“计算时间”/“计算输出时间” 将照常记录。

类别

指标

指标名称

描述

粒度

频率

计数

缓存命中计数

nv_cache_num_hits_per_model

每个模型的响应缓存命中数

按模型

按请求

缓存未命中计数

nv_cache_num_misses_per_model

每个模型的响应缓存未命中数

按模型

按请求

延迟

缓存命中时间

nv_cache_hit_duration_per_model

在缓存命中时，每个模型检索缓存响应所花费的累积时间（微秒）

按模型

按请求

缓存未命中时间

nv_cache_miss_duration_per_model

在缓存未命中时，查找响应并将响应插入缓存所花费的累积时间（微秒）

按模型

按请求

与上面推理请求指标的摘要部分类似，按模型划分的缓存命中/未命中延迟指标也支持摘要。

注意

对于启用响应缓存的模型，推理请求摘要指标当前已禁用。这是因为内部在缓存管理上花费了额外的时间，而这些时间不会正确地反映在端到端请求时间中。其他摘要指标不受影响。

自定义指标#

Triton 公开了一个 C API，允许用户和后端使用现有的 Triton 指标端点注册和收集自定义指标。用户拥有通过 API 创建的自定义指标的所有权，并且必须按照 API 文档管理其生命周期。

identity_backend 演示了向后端添加自定义指标的实际示例。

更多文档可以在 tritonserver.h 中的 TRITONSERVER_MetricFamily* 和 TRITONSERVER_Metric* API 注释中找到。

TensorRT-LLM 后端指标#

TRT-LLM 后端使用自定义指标 API 来跟踪和公开有关 LLM、KV 缓存和 Inflight Batching 的特定指标到 Triton：https://github.com/triton-inference-server/tensorrtllm_backend?tab=readme-ov-file#triton-metrics

vLLM 后端指标#

vLLM 后端使用自定义指标 API 来跟踪和公开有关 LLM 的特定指标到 Triton：https://github.com/triton-inference-server/vllm_backend?tab=readme-ov-file#triton-metrics

在本页中