Text Generation InferenceTGIPrometheus 指标全解析/metrics端点、指标语义与监控扩缩容实践【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inferenceText Generation InferenceTGI在启动后会自动暴露一个 Prometheus 格式的/metrics端点用于收集服务运行期间的批处理、队列与请求级观测数据。本文以仓库内 Metrics 参考文档 为核心骨架结合 router 服务端 与 v2/v3 后端 的实际埋点代码逐一解读每个指标的语义、标签与单位并给出基于 Prometheus Grafana 的监控、告警与自动扩缩容落地方案。读完本文你将能够准确理解 TGI 暴露的每一个tgi_*指标知道它们从哪里产生、如何采集、如何解读并据此搭建起可观测、可告警、可扩缩容的 TGI 生产监控体系。一、指标总览TGI 暴露了哪些度量TGI 通过/metricsPrometheus 端点对外暴露多种指标。这些指标可用于监控 TGI 服务的性能表现支撑部署的自动扩缩容autoscale决策帮助定位系统瓶颈。全部指标清单如下单位列中的Count表示计数Seconds表示秒Metric NameDescriptionTypeUnittgi_batch_current_max_tokensMaximum tokens for the current batchGaugeCounttgi_batch_current_sizeCurrent batch sizeGaugeCounttgi_batch_decode_durationTime spent decoding a batch per method (prefill or decode)HistogramSecondstgi_batch_filter_durationTime spent filtering batches and sending generated tokens per method (prefill or decode)HistogramSecondstgi_batch_forward_durationBatch forward duration per method (prefill or decode)HistogramSecondstgi_batch_inference_countInference calls per method (prefill or decode)CounterCounttgi_batch_inference_durationBatch inference durationHistogramSecondstgi_batch_inference_successNumber of successful inference calls per method (prefill or decode)CounterCounttgi_batch_next_sizeBatch size of the next batchHistogramCounttgi_queue_sizeCurrent queue sizeGaugeCounttgi_request_countTotal number of requestsCounterCounttgi_request_durationTotal time spent processing the request (e2e latency)HistogramSecondstgi_request_generated_tokensGenerated tokens per requestHistogramCounttgi_request_inference_durationRequest inference durationHistogramSecondstgi_request_input_lengthInput token length per requestHistogramCounttgi_request_max_new_tokensMaximum new tokens per requestHistogramCounttgi_request_mean_time_per_token_durationMean time per token per request (inter-token latency)HistogramSecondstgi_request_queue_durationTime spent in the queue per requestHistogramSecondstgi_request_skipped_tokensSpeculated tokens per requestHistogramCounttgi_request_successNumber of successful requestsCountertgi_request_validation_durationTime spent validating the requestHistogramSeconds从指标命名上可以清晰看出三类主题tgi_batch_*面向服务端批处理引擎tgi_queue_*面向排队系统tgi_request_*面向单个请求的端到端生命周期。下一节我们从源码出发说明这些指标分别在何处产生、如何打点。二、指标从哪里来Router 与 Backend 的双层埋点TGI 的指标埋点分布在两个层面理解这一点对定位问题至关重要Router 层请求生命周期所有tgi_request_*指标都在 router/src/server.rs 中打点覆盖 HTTP 请求从进入、校验、排队、推理到返回的完整链路。Backend 层批处理引擎所有tgi_batch_*指标与队列指标在 backends/v3/src/backend.rs、backends/v2/src/backend.rs 与 backends/v3/src/queue.rs 等后端实现中打点。在 Router 中一次成功的请求结束时以/generate为例server.rs 会依次记录metrics::counter!(tgi_request_success).increment(1); metrics::histogram!(tgi_request_duration).record(total_time.as_secs_f64()); metrics::histogram!(tgi_request_validation_duration).record(validation_time.as_secs_f64()); metrics::histogram!(tgi_request_queue_duration).record(queue_time.as_secs_f64()); metrics::histogram!(tgi_request_inference_duration).record(inference_time.as_secs_f64()); metrics::histogram!(tgi_request_mean_time_per_token_duration).record(time_per_token.as_secs_f64()); metrics::histogram!(tgi_request_generated_tokens).record(response.generated_text.generated_tokens as f64);其中total_time、validation_time、queue_time、inference_time分别对应请求的总耗时、参数校验耗时、排队耗时与模型推理耗时time_per_token即每个 token 的平均耗时inter-token latencyITL。/generate_stream路径同样在流结束处打点见 server.rs。请求进入时还会累加tgi_request_count见 server.rs失败时则记录tgi_request_failure计数器带err标签区分validation、incomplete等原因。在 Backend 层批处理引擎按prefill预填充与decode解码两种方法分别打点。例如 backends/v3/src/backend.rs 中 prefill 阶段会记录metrics::counter!(tgi_batch_inference_count, method prefill).increment(1); metrics::histogram!(tgi_batch_forward_duration, method prefill).record(...); metrics::histogram!(tgi_batch_decode_duration, method prefill).record(...); metrics::histogram!(tgi_batch_filter_duration, method prefill).record(...); metrics::histogram!(tgi_batch_inference_duration, method prefill).record(...); metrics::counter!(tgi_batch_inference_success, method prefill).increment(1);decode 阶段使用相同的指标名、method decode标签见 backends/v3/src/backend.rsv2 后端结构一致见 backends/v2/src/backend.rs。因此查询时可通过method标签分别观察 prefill 与 decode 两个阶段的性能。为什么文档里写 “per method (prefill or decode)”因为tgi_batch_decode_duration、tgi_batch_filter_duration、tgi_batch_forward_duration、tgi_batch_inference_count、tgi_batch_inference_success这五个指标都携带method标签其取值正是prefill或decode。从源码结构可以推断这是为了精细区分“一次批处理中预填充阶段与解码阶段各自的耗时与成功率”。三、指标分组精读语义、用途与告警建议3.1 请求级指标tgi_request_*端到端体验的镜子指标解读要点tgi_request_count累计收到的请求总数Counter。请求一进入 Router 即累加可与tgi_request_success对比计算成功率。tgi_request_success成功完成的请求数Counter。注意该指标在 Router 描述注册中明确为 “Number of successful requests”server.rs。tgi_request_duration请求端到端总耗时e2e latency即用户感知的完整延迟含校验、排队与推理。tgi_request_validation_duration参数校验阶段耗时帮助判断是否因过重的校验逻辑拖慢请求。tgi_request_queue_duration请求在队列中的等待时间。队列等待过长通常是吞吐瓶颈或扩缩容滞后的信号。tgi_request_inference_duration实际模型推理阶段耗时不含排队与校验。tgi_request_mean_time_per_token_duration每个 token 的平均生成耗时inter-token latency是评估生成流畅度的关键指标数值越小越好。tgi_request_generated_tokens单请求生成的 token 数可用于统计 token 吞吐量tokens/s。tgi_request_input_length单请求输入 token 长度。tgi_request_max_new_tokens单请求允许生成的最大新 token 数即请求参数中的max_new_tokens。tgi_request_skipped_tokens投机解码speculation场景下被跳过的投机 token 数文档描述为 “Speculated tokens per request”。后端在投机验证时记录(n - 1)个被接受跳过的 token见 backends/v3/src/backend.rs。监控建议重点关注tgi_request_duration与tgi_request_mean_time_per_token_duration的 P50/P95/P99 分位数以及tgi_request_queue_duration的上涨趋势tgi_request_generated_tokens与tgi_request_input_length适合做用量统计与容量规划。3.2 批处理级指标tgi_batch_*引擎内部效率的探针指标解读要点tgi_batch_current_size当前批次的请求数Gauge。批处理引擎在每轮迭代前更新批处理结束后归零见 backends/v3/src/backend.rs 与 backends/v3/src/backend.rs。tgi_batch_current_max_tokens当前批次的最大 token 数Gauge反映当前批次在 KV Cache 上的占用上限。tgi_batch_next_size下一批次的大小Histogram用于观察调度器组织的批次规模分布是判断批处理引擎“吃满”程度的重要依据记录点在 backends/v3/src/queue.rs。tgi_batch_inference_count推理调用次数Counter带method标签。tgi_batch_inference_success/tgi_batch_inference_failure推理成功/失败次数Counter带method标签。失败计数在推理异常分支累加见 backends/v3/src/backend.rs 与 backends/v3/src/backend.rs。tgi_batch_forward_duration模型前向forward计算耗时Histogram带method标签。tgi_batch_decode_duration批处理中“解码”环节的总耗时Histogram带method标签即对批内所有请求执行一次生成步骤的时间。tgi_batch_filter_duration过滤批次并把已生成 token 发给客户端所花的时间Histogram带method标签即每轮迭代的收尾开销。tgi_batch_inference_duration一次完整批推理的总耗时Histogram。监控建议tgi_batch_current_size与tgi_batch_current_max_tokens可观察批处理饱和度tgi_batch_next_size的分布能反映并发请求是否足以填满批次tgi_batch_decode_duration与tgi_batch_forward_duration的差距可帮助判断瓶颈在计算还是在其他环节。3.3 队列指标tgi_queue_size负载水位计tgi_queue_sizeGauge表示当前排队中的请求数是判断服务是否过载、是否该扩容的最直接信号。它在队列状态变更时更新请求入队时increment每轮调度后按队列实际条目数set见 backends/v3/src/queue.rs 与 backends/v3/src/queue.rs。该指标与tgi_request_queue_duration配合可以完整刻画排队压力队列长度上升且排队耗时上升说明后端处理速度跟不上请求到达速度。3.4 文档未列出但源码中存在的重要指标除上表外从源码中可以确认 TGI 还打点了以下指标未出现在参考文档表中但对生产排障很有价值tgi_request_failure请求失败计数器带err标签取值包括validation校验失败、incomplete生成不完整、dropped请求被丢弃、generation生成阶段错误等见 router/src/server.rs 与 backends/v3/src/backend.rs。tgi_batch_concat/tgi_batch_concat_duration批次拼接次数与耗时带reason标签backpressure、chunking、wait_exceeded反映动态批处理时批次合并的发生频率见 backends/v3/src/backend.rs。tgi_batch_total_tokens在 Router 的指标注册代码中描述为 “Maximum amount of tokens in total”见 server.rs用于统计 token 总量的上限水位。四、如何采集/metrics端点与 Prometheus 配置4.1 端点与端口Router 在启动时注册了 Prometheus 指标抓取端点/metricsserver.rs处理器直接渲染全局 recorder 的内容async fn metrics(prom_handle: ExtensionPrometheusHandle) - String { prom_handle.render() }Prometheus 抓取端口由启动参数--prometheus-port控制默认值为9000见 launcher/src/main.rs 与 launcher 参考文档。也就是说TGI 的 HTTP 服务端口默认3000与指标端口默认9000相互独立可以直接通过curl 0.0.0.0:9000/metrics验证指标是否正常输出。该参数同样支持环境变量PROMETHEUS_PORT覆盖也支持-p短选项。4.2 在 Prometheus 中配置抓取在 Prometheus 的prometheus.yml中将 TGI 实例加入scrape_configs即可scrape_configs: - job_name: tgi static_configs: - targets: [TGI_HOST:9000]完整的上手流程含 Prometheus 安装、TGI 服务端验证、Grafana 数据源与仪表盘导入可参考仓库内的 监控教程该教程演示了通过 Grafana 仪表盘消费 Prometheus 数据可观测的有效指标包括 TGI 实际使用的批次大小统计、prefill/decode 延迟、生成 token 数等。4.3 开箱即用的 Grafana 仪表盘仓库的 assets/tgi_grafana.json 提供了一份可直接导入 Grafana 的仪表盘模板覆盖本节所述核心指标的常见可视化组合。导入方式在 Grafana 中选择 “Import dashboard”上传或粘贴该 JSON 文件内容并选择已配置好的 Prometheus 数据源即可。五、深入底层直方图桶Bucket是如何定制的TGI 的直方图桶并非使用 Prometheus 默认配置而是在 server.rs 中按指标类型做了定制这对正确解读分位数如 P99至关重要持续时间类指标所有名称以duration结尾的指标通过Matcher::Suffix(duration)匹配采用 35 个桶的几何递增序列从0.0001秒起步、每桶乘以1.5桶边界最终延伸到约 9 秒量级。这种指数型桶布局保证从亚毫秒级到秒级都有足够的分辨率适配 LLM 推理“token 级耗时小、整请求耗时大”的动态范围。tgi_request_input_length按max_input_tokens / 100等间距生成 100 个桶覆盖 0 到最大输入长度。tgi_request_generated_tokens与tgi_request_max_new_tokens按max_total_tokens / 100等间距生成 100 个桶。tgi_batch_next_size从 1 到 1024 每个整数一个桶精确刻画批次规模的分布。了解桶边界后在计算分位数时就不会因桶过粗或过细而产生误读。同时也可以看到tgi_request_skipped_tokens的专用桶配置在当前源码中被注释掉server.rs从源码结构看该指标目前使用默认桶这也解释了为何文档表格中它的描述没有进一步细化。六、指标注册与描述从describe_*看官方语义Router 启动时会通过metrics::describe_*!系列宏为每个指标注册官方描述server.rs这些描述会被 Prometheus 以HELP注释输出。例如metrics::describe_counter!(tgi_request_success, Number of successful requests); metrics::describe_histogram!(tgi_request_mean_time_per_token_duration, metrics::Unit::Seconds, Mean time per token per request); metrics::describe_gauge!(tgi_batch_current_max_tokens, metrics::Unit::Count, Maximum tokens for the current batch);抓取到的/metrics响应中会带有这些HELP文本与本文第一节表格中的 Description 列一一对应。如果你在排查时对某个指标含义有疑问直接查看抓取结果中的# HELP tgi_xxx注释即可无需翻代码。七、实战用指标驱动监控告警与自动扩缩容结合前三节的语义分析可以形成一套实用的监控策略延迟告警对tgi_request_duration、tgi_request_mean_time_per_token_duration的 P99 设置阈值告警若延迟上涨的同时tgi_queue_size同步上涨可判定为后端过载导致排队而非单次请求异常。成功率告警1 - rate(tgi_request_success[5m]) / rate(tgi_request_count[5m])计算请求失败率配合tgi_request_failure的err标签区分失败类型快速定位是校验问题还是生成中断。批处理效率观察tgi_batch_next_size与tgi_batch_current_max_tokens的比值可反映批次利用率若批次长期偏小说明并发不足以填满吞吐可考虑提升并发或降低实例数。自动扩缩容tgi_queue_size是最适合作为扩缩容依据的水位指标——队列持续堆积时扩容队列长时间为空时缩容。官方文档明确说明这些指标可用于 autoscale 部署见 Metrics 参考文档生产环境可将其接入 Kubernetes HPA 或 KEDA 等基于 Prometheus 的扩缩容机制。八、延伸阅读Metrics 参考文档本文核心来源监控教程Prometheus Grafana 完整搭建Grafana 仪表盘模板Router 指标埋点与端点实现v3 后端批处理指标实现 / v2 后端批处理指标实现队列指标实现Launcher 参数文档--prometheus-port【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Text Generation Inference（TGI）Prometheus 指标全解析：`/metrics` 端点、指标语义与监控扩缩容实践
Text Generation InferenceTGIPrometheus 指标全解析/metrics端点、指标语义与监控扩缩容实践【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inferenceText Generation InferenceTGI在启动后会自动暴露一个 Prometheus 格式的/metrics端点用于收集服务运行期间的批处理、队列与请求级观测数据。本文以仓库内 Metrics 参考文档 为核心骨架结合 router 服务端 与 v2/v3 后端 的实际埋点代码逐一解读每个指标的语义、标签与单位并给出基于 Prometheus Grafana 的监控、告警与自动扩缩容落地方案。读完本文你将能够准确理解 TGI 暴露的每一个tgi_*指标知道它们从哪里产生、如何采集、如何解读并据此搭建起可观测、可告警、可扩缩容的 TGI 生产监控体系。一、指标总览TGI 暴露了哪些度量TGI 通过/metricsPrometheus 端点对外暴露多种指标。这些指标可用于监控 TGI 服务的性能表现支撑部署的自动扩缩容autoscale决策帮助定位系统瓶颈。全部指标清单如下单位列中的Count表示计数Seconds表示秒Metric NameDescriptionTypeUnittgi_batch_current_max_tokensMaximum tokens for the current batchGaugeCounttgi_batch_current_sizeCurrent batch sizeGaugeCounttgi_batch_decode_durationTime spent decoding a batch per method (prefill or decode)HistogramSecondstgi_batch_filter_durationTime spent filtering batches and sending generated tokens per method (prefill or decode)HistogramSecondstgi_batch_forward_durationBatch forward duration per method (prefill or decode)HistogramSecondstgi_batch_inference_countInference calls per method (prefill or decode)CounterCounttgi_batch_inference_durationBatch inference durationHistogramSecondstgi_batch_inference_successNumber of successful inference calls per method (prefill or decode)CounterCounttgi_batch_next_sizeBatch size of the next batchHistogramCounttgi_queue_sizeCurrent queue sizeGaugeCounttgi_request_countTotal number of requestsCounterCounttgi_request_durationTotal time spent processing the request (e2e latency)HistogramSecondstgi_request_generated_tokensGenerated tokens per requestHistogramCounttgi_request_inference_durationRequest inference durationHistogramSecondstgi_request_input_lengthInput token length per requestHistogramCounttgi_request_max_new_tokensMaximum new tokens per requestHistogramCounttgi_request_mean_time_per_token_durationMean time per token per request (inter-token latency)HistogramSecondstgi_request_queue_durationTime spent in the queue per requestHistogramSecondstgi_request_skipped_tokensSpeculated tokens per requestHistogramCounttgi_request_successNumber of successful requestsCountertgi_request_validation_durationTime spent validating the requestHistogramSeconds从指标命名上可以清晰看出三类主题tgi_batch_*面向服务端批处理引擎tgi_queue_*面向排队系统tgi_request_*面向单个请求的端到端生命周期。下一节我们从源码出发说明这些指标分别在何处产生、如何打点。二、指标从哪里来Router 与 Backend 的双层埋点TGI 的指标埋点分布在两个层面理解这一点对定位问题至关重要Router 层请求生命周期所有tgi_request_*指标都在 router/src/server.rs 中打点覆盖 HTTP 请求从进入、校验、排队、推理到返回的完整链路。Backend 层批处理引擎所有tgi_batch_*指标与队列指标在 backends/v3/src/backend.rs、backends/v2/src/backend.rs 与 backends/v3/src/queue.rs 等后端实现中打点。在 Router 中一次成功的请求结束时以/generate为例server.rs 会依次记录metrics::counter!(tgi_request_success).increment(1); metrics::histogram!(tgi_request_duration).record(total_time.as_secs_f64()); metrics::histogram!(tgi_request_validation_duration).record(validation_time.as_secs_f64()); metrics::histogram!(tgi_request_queue_duration).record(queue_time.as_secs_f64()); metrics::histogram!(tgi_request_inference_duration).record(inference_time.as_secs_f64()); metrics::histogram!(tgi_request_mean_time_per_token_duration).record(time_per_token.as_secs_f64()); metrics::histogram!(tgi_request_generated_tokens).record(response.generated_text.generated_tokens as f64);其中total_time、validation_time、queue_time、inference_time分别对应请求的总耗时、参数校验耗时、排队耗时与模型推理耗时time_per_token即每个 token 的平均耗时inter-token latencyITL。/generate_stream路径同样在流结束处打点见 server.rs。请求进入时还会累加tgi_request_count见 server.rs失败时则记录tgi_request_failure计数器带err标签区分validation、incomplete等原因。在 Backend 层批处理引擎按prefill预填充与decode解码两种方法分别打点。例如 backends/v3/src/backend.rs 中 prefill 阶段会记录metrics::counter!(tgi_batch_inference_count, method prefill).increment(1); metrics::histogram!(tgi_batch_forward_duration, method prefill).record(...); metrics::histogram!(tgi_batch_decode_duration, method prefill).record(...); metrics::histogram!(tgi_batch_filter_duration, method prefill).record(...); metrics::histogram!(tgi_batch_inference_duration, method prefill).record(...); metrics::counter!(tgi_batch_inference_success, method prefill).increment(1);decode 阶段使用相同的指标名、method decode标签见 backends/v3/src/backend.rsv2 后端结构一致见 backends/v2/src/backend.rs。因此查询时可通过method标签分别观察 prefill 与 decode 两个阶段的性能。为什么文档里写 “per method (prefill or decode)”因为tgi_batch_decode_duration、tgi_batch_filter_duration、tgi_batch_forward_duration、tgi_batch_inference_count、tgi_batch_inference_success这五个指标都携带method标签其取值正是prefill或decode。从源码结构可以推断这是为了精细区分“一次批处理中预填充阶段与解码阶段各自的耗时与成功率”。三、指标分组精读语义、用途与告警建议3.1 请求级指标tgi_request_*端到端体验的镜子指标解读要点tgi_request_count累计收到的请求总数Counter。请求一进入 Router 即累加可与tgi_request_success对比计算成功率。tgi_request_success成功完成的请求数Counter。注意该指标在 Router 描述注册中明确为 “Number of successful requests”server.rs。tgi_request_duration请求端到端总耗时e2e latency即用户感知的完整延迟含校验、排队与推理。tgi_request_validation_duration参数校验阶段耗时帮助判断是否因过重的校验逻辑拖慢请求。tgi_request_queue_duration请求在队列中的等待时间。队列等待过长通常是吞吐瓶颈或扩缩容滞后的信号。tgi_request_inference_duration实际模型推理阶段耗时不含排队与校验。tgi_request_mean_time_per_token_duration每个 token 的平均生成耗时inter-token latency是评估生成流畅度的关键指标数值越小越好。tgi_request_generated_tokens单请求生成的 token 数可用于统计 token 吞吐量tokens/s。tgi_request_input_length单请求输入 token 长度。tgi_request_max_new_tokens单请求允许生成的最大新 token 数即请求参数中的max_new_tokens。tgi_request_skipped_tokens投机解码speculation场景下被跳过的投机 token 数文档描述为 “Speculated tokens per request”。后端在投机验证时记录(n - 1)个被接受跳过的 token见 backends/v3/src/backend.rs。监控建议重点关注tgi_request_duration与tgi_request_mean_time_per_token_duration的 P50/P95/P99 分位数以及tgi_request_queue_duration的上涨趋势tgi_request_generated_tokens与tgi_request_input_length适合做用量统计与容量规划。3.2 批处理级指标tgi_batch_*引擎内部效率的探针指标解读要点tgi_batch_current_size当前批次的请求数Gauge。批处理引擎在每轮迭代前更新批处理结束后归零见 backends/v3/src/backend.rs 与 backends/v3/src/backend.rs。tgi_batch_current_max_tokens当前批次的最大 token 数Gauge反映当前批次在 KV Cache 上的占用上限。tgi_batch_next_size下一批次的大小Histogram用于观察调度器组织的批次规模分布是判断批处理引擎“吃满”程度的重要依据记录点在 backends/v3/src/queue.rs。tgi_batch_inference_count推理调用次数Counter带method标签。tgi_batch_inference_success/tgi_batch_inference_failure推理成功/失败次数Counter带method标签。失败计数在推理异常分支累加见 backends/v3/src/backend.rs 与 backends/v3/src/backend.rs。tgi_batch_forward_duration模型前向forward计算耗时Histogram带method标签。tgi_batch_decode_duration批处理中“解码”环节的总耗时Histogram带method标签即对批内所有请求执行一次生成步骤的时间。tgi_batch_filter_duration过滤批次并把已生成 token 发给客户端所花的时间Histogram带method标签即每轮迭代的收尾开销。tgi_batch_inference_duration一次完整批推理的总耗时Histogram。监控建议tgi_batch_current_size与tgi_batch_current_max_tokens可观察批处理饱和度tgi_batch_next_size的分布能反映并发请求是否足以填满批次tgi_batch_decode_duration与tgi_batch_forward_duration的差距可帮助判断瓶颈在计算还是在其他环节。3.3 队列指标tgi_queue_size负载水位计tgi_queue_sizeGauge表示当前排队中的请求数是判断服务是否过载、是否该扩容的最直接信号。它在队列状态变更时更新请求入队时increment每轮调度后按队列实际条目数set见 backends/v3/src/queue.rs 与 backends/v3/src/queue.rs。该指标与tgi_request_queue_duration配合可以完整刻画排队压力队列长度上升且排队耗时上升说明后端处理速度跟不上请求到达速度。3.4 文档未列出但源码中存在的重要指标除上表外从源码中可以确认 TGI 还打点了以下指标未出现在参考文档表中但对生产排障很有价值tgi_request_failure请求失败计数器带err标签取值包括validation校验失败、incomplete生成不完整、dropped请求被丢弃、generation生成阶段错误等见 router/src/server.rs 与 backends/v3/src/backend.rs。tgi_batch_concat/tgi_batch_concat_duration批次拼接次数与耗时带reason标签backpressure、chunking、wait_exceeded反映动态批处理时批次合并的发生频率见 backends/v3/src/backend.rs。tgi_batch_total_tokens在 Router 的指标注册代码中描述为 “Maximum amount of tokens in total”见 server.rs用于统计 token 总量的上限水位。四、如何采集/metrics端点与 Prometheus 配置4.1 端点与端口Router 在启动时注册了 Prometheus 指标抓取端点/metricsserver.rs处理器直接渲染全局 recorder 的内容async fn metrics(prom_handle: ExtensionPrometheusHandle) - String { prom_handle.render() }Prometheus 抓取端口由启动参数--prometheus-port控制默认值为9000见 launcher/src/main.rs 与 launcher 参考文档。也就是说TGI 的 HTTP 服务端口默认3000与指标端口默认9000相互独立可以直接通过curl 0.0.0.0:9000/metrics验证指标是否正常输出。该参数同样支持环境变量PROMETHEUS_PORT覆盖也支持-p短选项。4.2 在 Prometheus 中配置抓取在 Prometheus 的prometheus.yml中将 TGI 实例加入scrape_configs即可scrape_configs: - job_name: tgi static_configs: - targets: [TGI_HOST:9000]完整的上手流程含 Prometheus 安装、TGI 服务端验证、Grafana 数据源与仪表盘导入可参考仓库内的 监控教程该教程演示了通过 Grafana 仪表盘消费 Prometheus 数据可观测的有效指标包括 TGI 实际使用的批次大小统计、prefill/decode 延迟、生成 token 数等。4.3 开箱即用的 Grafana 仪表盘仓库的 assets/tgi_grafana.json 提供了一份可直接导入 Grafana 的仪表盘模板覆盖本节所述核心指标的常见可视化组合。导入方式在 Grafana 中选择 “Import dashboard”上传或粘贴该 JSON 文件内容并选择已配置好的 Prometheus 数据源即可。五、深入底层直方图桶Bucket是如何定制的TGI 的直方图桶并非使用 Prometheus 默认配置而是在 server.rs 中按指标类型做了定制这对正确解读分位数如 P99至关重要持续时间类指标所有名称以duration结尾的指标通过Matcher::Suffix(duration)匹配采用 35 个桶的几何递增序列从0.0001秒起步、每桶乘以1.5桶边界最终延伸到约 9 秒量级。这种指数型桶布局保证从亚毫秒级到秒级都有足够的分辨率适配 LLM 推理“token 级耗时小、整请求耗时大”的动态范围。tgi_request_input_length按max_input_tokens / 100等间距生成 100 个桶覆盖 0 到最大输入长度。tgi_request_generated_tokens与tgi_request_max_new_tokens按max_total_tokens / 100等间距生成 100 个桶。tgi_batch_next_size从 1 到 1024 每个整数一个桶精确刻画批次规模的分布。了解桶边界后在计算分位数时就不会因桶过粗或过细而产生误读。同时也可以看到tgi_request_skipped_tokens的专用桶配置在当前源码中被注释掉server.rs从源码结构看该指标目前使用默认桶这也解释了为何文档表格中它的描述没有进一步细化。六、指标注册与描述从describe_*看官方语义Router 启动时会通过metrics::describe_*!系列宏为每个指标注册官方描述server.rs这些描述会被 Prometheus 以HELP注释输出。例如metrics::describe_counter!(tgi_request_success, Number of successful requests); metrics::describe_histogram!(tgi_request_mean_time_per_token_duration, metrics::Unit::Seconds, Mean time per token per request); metrics::describe_gauge!(tgi_batch_current_max_tokens, metrics::Unit::Count, Maximum tokens for the current batch);抓取到的/metrics响应中会带有这些HELP文本与本文第一节表格中的 Description 列一一对应。如果你在排查时对某个指标含义有疑问直接查看抓取结果中的# HELP tgi_xxx注释即可无需翻代码。七、实战用指标驱动监控告警与自动扩缩容结合前三节的语义分析可以形成一套实用的监控策略延迟告警对tgi_request_duration、tgi_request_mean_time_per_token_duration的 P99 设置阈值告警若延迟上涨的同时tgi_queue_size同步上涨可判定为后端过载导致排队而非单次请求异常。成功率告警1 - rate(tgi_request_success[5m]) / rate(tgi_request_count[5m])计算请求失败率配合tgi_request_failure的err标签区分失败类型快速定位是校验问题还是生成中断。批处理效率观察tgi_batch_next_size与tgi_batch_current_max_tokens的比值可反映批次利用率若批次长期偏小说明并发不足以填满吞吐可考虑提升并发或降低实例数。自动扩缩容tgi_queue_size是最适合作为扩缩容依据的水位指标——队列持续堆积时扩容队列长时间为空时缩容。官方文档明确说明这些指标可用于 autoscale 部署见 Metrics 参考文档生产环境可将其接入 Kubernetes HPA 或 KEDA 等基于 Prometheus 的扩缩容机制。八、延伸阅读Metrics 参考文档本文核心来源监控教程Prometheus Grafana 完整搭建Grafana 仪表盘模板Router 指标埋点与端点实现v3 后端批处理指标实现 / v2 后端批处理指标实现队列指标实现Launcher 参数文档--prometheus-port【免费下载链接】text-generation-inferenceLarge Language Model Text Generation Inference项目地址: https://gitcode.com/GitHub_Trending/te/text-generation-inference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
