摘要

Sally O’Malley解释了大型语言模型（LLM）独特的可观测性挑战，并提供了一个可复现的开源监控栈来监控AI工作负载。她演示了在Kubernetes上部署Prometheus、Grafana、OpenTelemetry和Tempo与vLLM和Llama Stack的过程。学习如何监控业务关键AI应用的成本、性能和质量信号。

为什么LLM带来独特挑战

LLM驱动的应用程序与传统微服务有根本区别：

• 速度较慢且可变
• 非均匀性能特征
• 成本高昂
• 复杂的工作流程模式

AI应用模式

1. RAG模式：包含文档检索和生成阶段
2. 代理模式：多轮对话，上下文不断累积
3. 代码生成：类似的多轮模式

部署开源可观测性栈

技术栈组成

• Prometheus：指标后端
• OpenTelemetry Collector：追踪收集
• Tempo：追踪后端
• Grafana：可视化

部署步骤

1. 在配备4个GPU的EC2实例上运行MiniKube
2. 安装NVIDIA驱动和容器工具包
3. 部署AI工作负载：llm-d（vLLM模型服务器）和Llama Stack框架

ServiceMonitor配置

在Kubernetes中，为每个需要抓取指标的服务创建ServiceMonitor：

1
2
3
4
5
6
7
8

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
spec:
  endpoints:
  - port: http-metrics
  selector:
    matchLabels:
      app: example-service

追踪配置

Llama Stack主要基于追踪生成遥测数据，需要配置：

• OpenTelemetry追踪接收器
• OTel Collector边车容器
• Tempo数据源集成到Grafana

监控信号分类

性能信号

• 延迟指标：首令牌时间、端到端延迟
• 处理时间：输入处理vs预填充vs答案生成
• 网络通信时间
• 缓存使用率

质量信号

• 响应合理性
• 工具使用情况
• 文档检索准确性（通过追踪查看）

成本信号

• 基于令牌的计费
• GPU利用率
• 令牌小时数估算

实际监控演示

vLLM指标监控

• 使用llm-d快速启动器内置的Grafana仪表板
• 导入NVIDIA DCGM-Exporter仪表板监控GPU使用情况
• 利用Grafana新的下钻功能深入分析

Llama Stack追踪分析

• 查看完整提示和响应
• 监控RAG中使用的文档
• 跟踪工具调用情况
• 代理会话管理

实战演示

测试脚本执行

运行包含多个工具的测试脚本来生成有趣的追踪数据。

成本监控示例

查询GPU每小时使用率，估算运行成本：

• 实例类型：g6.12xlarge（4个L4 GPU）
• 成本：5美元/小时，超过100美元/天

追踪数据查看

通过Tempo数据源搜索Llama Stack追踪，查看：

• 模型信息
• 代理会话
• 工具使用详情
• 文档检索记录

问答环节要点

成本监控

• 开源模型无每令牌成本
• 商业API（如OpenAI、Anthropic）需要监控令牌使用量

技术架构澄清

• llm-d：模型服务器，运行vLLM
• Llama Stack：AI应用框架，连接模型端点

工具选择

除了开源栈，还讨论了专用LLM可观测性工具如Langfuse和Dynatrace。

可操作性洞察

不同角色关注不同指标：

• 开发者：预填充与解码间的延迟
• SRE：系统可靠性和资源使用
• 业务方：成本和质量指标

模型正确性

通过追踪日志监控工具使用情况，使用MCP（Model Context Protocol）使AI应用更确定性。

总结

LLM应用具有非均匀、非确定性特点，需要专门的可观测性方法。通过Prometheus、Grafana、OpenTelemetry Collector和Tempo构建的监控栈，结合vLLM和Llama Stack，能够有效监控AI工作负载的关键信号。