模型推理指标标准化延迟、吞吐、Token 耗用统一口径一、背景与问题AI 推理服务的监控指标目前处于混乱状态。不同框架的指标定义不一致vLLM 报iteration_latencyTGI 报time_per_token Triton 报inference_time。同一个延迟指标有的从请求入口计时有的从模型计算开始计时有的只算 GPU 执行时间不算预处理。这种不一致带来的后果很直接当你说推理延迟 P99 是 200ms时听众必须追问你说的延迟从哪一步开始计时这不是学术讨论是生产环境里的沟通成本。跨团队、跨服务的 SLO 定义因为口径不同无法对齐告警阈值也因为基线不统一而难以设定。标准化不是追求完美定义是消除歧义。推理服务的核心指标只需要三类延迟时间维度、吞吐量维度、Token 耗用资源维度。每类指标明确计时起点、计量单位、统计方法就够了。二、指标分类与定义graph LR A[推理指标体系] -- B[延迟指标] A -- C[吞吐指标] A -- D[Token 耗用指标] B -- B1[请求延迟 E2E] B -- B2[推理延迟 Compute] B -- B3[首 Token 延迟 TTFT] C -- C1[请求吞吐 RPS] C -- C2[Token 吞吐 TPS] D -- D1[输入 Token 数] D -- D2[输出 Token 数] D -- D3[Token 耗用率] style A fill:#1b5e20,color:#fff style B fill:#2e7d32,color:#fff style C fill:#388e3c,color:#fff style D fill:#43a047,color:#fff2.1 延迟指标三个口径三个用途指标名计时范围单位用途request_latency_e2eHTTP 请求到达→响应返回ms用户体感的 SLO 基线inference_latency_compute模型计算开始→计算结束ms模型性能的 SLO 基线time_to_first_token请求到达→首个 Token 生成ms流式场景的用户体感三个延迟指标必须同时存在。request_latency_e2e是用户看到的全链路延迟包含预处理、排队、推理、后处理。inference_latency_compute只算模型计算用于衡量模型本身的性能。两者差值就是非推理开销——当差值突增时问题不在模型而在基础设施排队、预处理。time_to_first_tokenTTFT是流式推理的关键指标。用户在流式场景下对首 Token 延迟的感知远强于总延迟。一个推理服务总延迟 2s 但 TTFT 200ms 的体验明显优于总延迟 1s 但 TTFT 800ms 的体验。2.2 吞吐指标指标名计量方式单位用途request_throughput完成请求数/时间req/s容量规划基线token_throughput生成 Token 数/时间token/sGPU 利用率评估request_throughput和token_throughput是两个独立的指标不能混用。短请求10 token 输入/输出的 RPS 可能很高但 TPS 很低长请求1000 token 输入的 RPS 低但 TPS 可能不低。容量规划必须看 TPS因为 GPU 的计算量由 Token 数决定不由请求数决定。2.3 Token 耗用指标指标名计量方式单位用途input_token_count单次请求输入 Token 数token成本核算output_token_count单次请求输出 Token 数token成本核算token_utilizationTPS / GPU 最大 TPS%GPU 利用率Token 耗用直接关联计费。推理服务的成本模型是每 Token 多少钱input_token_count和output_token_count的分布决定了服务的成本结构。如果 80% 的请求 input 只有 50 token 但 output 有 500 token优化方向是降低 output 的生成成本量化、KV cache不是降低 input 的处理成本。三、Prometheus 指标实现3.1 延迟指标Histogram延迟必须用 Histogram 采集不要用 Gauge 记录平均值。平均值掩盖尾部延迟而 P99 才是 SLO 的考核点。var requestLatency prometheus.NewHistogram(prometheus.HistogramOpts{ Name: inference_request_latency_e2e_ms, Buckets: []float64{50, 100, 200, 500, 1000, 2000, 5000}, }) var inferenceComputeLatency prometheus.NewHistogram(prometheus.HistogramOpts{ Name: inference_latency_compute_ms, Buckets: []float64{10, 20, 50, 100, 200, 500, 1000}, }) var timeToFirstToken prometheus.NewHistogram(prometheus.HistogramOpts{ Name: inference_time_to_first_token_ms, Buckets: []float64{50, 100, 200, 500, 1000, 2000}, })Bucket 设计原则覆盖从正常值到异常值的完整范围。推理服务的 E2E 延迟正常值在 100-500ms异常值可能到 5000msbucket 要覆盖两端。不要用 Prometheus 默认的 exponential bucket它们是为通用场景设计的推理服务需要自定义边界。3.2 吞吐指标Counter rate吞吐用 Counter 记录累计值查询时用rate()计算瞬时值var requestCount prometheus.NewCounterVec(prometheus.CounterOpts{ Name: inference_request_total, }, []string{model_name, status}) var tokenCount prometheus.NewCounterVec(prometheus.CounterOpts{ Name: inference_token_total, }, []string{model_name, direction}) // direction: input/output查询示例# 请求吞吐 rate(inference_request_total{statussuccess}[5m]) # Token 吞吐输出 rate(inference_token_total{directionoutput}[5m])3.3 指标命名规范所有推理指标统一前缀inference_后缀带单位_ms,_total,_bytes。不要出现model_latency和infer_time这种命名不一致的情况。命名规范如下inference_{类别}_{具体名称}_{单位}类别request请求级、compute计算级、tokenToken 级。这样inference_request_latency_e2e_ms和inference_compute_latency_ms的命名关系一目了然。四、SLO 定义与告警规则基于标准化指标定义 SLO告警才有基线。4.1 推理服务 SLO 示例SLO指标目标告警条件E2E 延迟 P99 1srequest_latency_e2e99% 1000msP99 1500ms 持续 5m首Token延迟 P95 300mstime_to_first_token95% 300msP95 500ms 持续 3m请求成功率 99.5%request_total(success/total)99.5%成功率 99% 持续 5mGPU Token 利用率 60%token_utilization60%利用率 40% 持续 15m告警条件比 SLO 目标宽松一些。原因SLO 是对外承诺告警是内部响应信号。如果告警阈值设成 SLO 目标本身每次微小波动都会触发告警噪声太多。留 50% 的缓冲区间让告警触发在即将违反 SLO的时机而不是已经违反 SLO的时机。4.2 跨服务 SLO 对齐标准化指标的最大收益是跨服务对齐。当 Gateway 和推理服务都用request_latency_e2e_ms定义延迟时SLO 的口径一致。Gateway 的 SLO P99 200ms 和推理服务的 P99 1000ms 加上网络开销可以推导出端到端 SLO 是否可达。如果口径不一致Gateway 用 HTTP 延迟推理用 GPU 计算时间这个推导就不成立。五、总结推理服务指标的混乱不是技术问题是定义问题。延迟从哪一步计时、吞吐用请求数还是 Token 数、Token 耗用怎么分类——这些定义不一致监控数据就无法跨服务对比、SLO 就无法对齐、告警阈值就无法设定。三个关键定义三个延迟口径E2E用户体感、Compute模型性能、TTFT流式体感同时存在差值定位瓶颈。吞吐用 TPS 不用 RPSGPU 计算量由 Token 数决定RPS 不能反映真实负载。统一命名前缀和单位inference_{类别}_{名称}_{单位}消除命名歧义。基础设施不需要漂亮话。指标标准化不是追求完美是消除歧义——让推理延迟 P99 是 200ms这句话不需要追加 5 分钟的定义讨论就能被理解。能被直接理解的指标才能被直接用于决策。