KServe 中实现运行时特定指标监控的技术方案

背景介绍

在基于 KServe 部署推理服务时，开发者经常需要监控模型运行时的特定指标，例如首字节时间(TTFT)、每令牌输出时间(TPOT)、KV缓存利用率等。这些指标对于优化模型性能和资源利用率至关重要。然而，KServe 默认提供的 queue-proxy 指标并不包含这些运行时特定的监控数据。

技术挑战

传统上，KServe 通过 ServiceMonitor 来暴露监控指标，但这种方式存在以下限制：

1. 默认服务只暴露 queue-proxy 的指标端口(9091)
2. 运行时容器的自定义指标无法通过标准服务端口访问
3. 缺乏统一的指标聚合机制

解决方案

方案一：使用 qpext 容器聚合指标

KServe 提供了 qpext 容器组件，能够将 queue-proxy 和 kserve 容器的指标聚合到一个端点上。开发者可以通过以下步骤验证指标是否正常工作：

1. 在本地转发 InferenceService 的 Pod 端口
2. 使用 curl 命令测试指标端点
3. 确认自定义指标是否包含在聚合输出中

方案二：采用 PodMonitor 替代 ServiceMonitor

由于 Service 资源无法直接暴露聚合指标端口(9088)，推荐使用 Prometheus Operator 提供的 PodMonitor 资源来直接监控 Pod 级别的指标。典型配置如下：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: model-monitor
spec:
  namespaceSelector:
    any: true
  selector:
    matchLabels:
      serving.kserve.io/inferenceservice: model-name
  podMetricsEndpoints:
  - port: user-port
    interval: 5s

端口映射说明

KServe 为每个推理服务创建的服务资源会暴露多个端口：

• 9091: http-usermetric (queue-proxy 指标)
• 9088: aggr-metric (聚合指标，通过 qpext)
• 8000: user-port (运行时容器原始指标)

开发者可以根据监控需求选择合适的端口进行采集。

最佳实践建议

1. 对于只需要运行时特定指标的场景，直接使用 user-port(8000)
2. 需要综合监控 queue-proxy 和运行时指标时，部署 qpext 并使用 aggr-metric(9088)
3. 保持监控采集间隔合理(建议5-15秒)，避免对服务性能产生影响
4. 为不同的监控目的创建独立的 PodMonitor 资源

总结

通过合理利用 KServe 提供的指标聚合机制和 Prometheus Operator 的监控资源，开发者可以构建完整的推理服务监控体系，覆盖从基础设施到模型运行时的全栈指标。这种方案既保持了灵活性，又能满足生产环境对监控的严格要求。