面板全绿，AI 却在自信满满地瞎编：用 Grafana 盯 AI 的三条路线，从显卡电费到 Token 账单

这两天，Grafana 圈子里同时冒出了三条信息量很大的内容。8 月 10 日，InfoQ 发出《可观测性厂商 AI 大战开始》，这句话在知乎被转了出来：“可观测性厂商AI大战开始：Grafana、Datadog、Splunk全部入场”。知乎同一天，B 站有 UP 主上线了一条标题叫《表面HTTP200稳如老狗，实际AI瞎编慌得一批？》的视频，演示用 Grafana 智能体可观测性去抓生产环境里摸鱼的 Agent。哔哩哔哩再加上昨天知乎刚更新的《4GB 显存极限下，从零搭建 AI 推理可观测性系统》踩坑实录，三条信号摆在一起，结论很清楚：Grafana 用户的主战场，已经从"监控服务器"悄悄换成了"监控 AI"。

为什么老监控思路，盯不住 AI

监控了多年服务器的人，第一次盯 AI 会很不适应。传统可观测体系围绕指标、链路、日志三根支柱搭起来，OpenTelemetry Collector 负责统一采集，Grafana 负责最终展示，它盯的是管道：延迟、错误率、吞吐量。但 LLM 驱动的应用，核心风险不在管道，而在内容——模型有没有幻觉、有没有把敏感信息说出去、有没有自作主张去调了不该调的工具，这些 HTTP 状态码一个都反映不了。这不是个别抱怨，模型可以一路返回自信满满的错误答案，而你的监控面板依然全绿。知乎

也正因为旧眼睛看不清新问题，资本和厂商才一起涌了进来。全球 LLM 可观测平台市场 2026 年规模约 26.9 亿美元，正以 36.2% 的年复合增速向 2030 年的 92.6 亿美元冲刺。知乎对普通用户来说，不用管厂商怎么打，但有三条已经跑通的路线，值得按自己的情况抄作业。

路线一：盯显卡，本地推理党的生命线

最先痛的是本地推理党：Ollama 跑着、模型挂着，但 GPU 到底是在满载干活还是空转发热，没人知道。GPU 监控这条链路其实不长：DCGM 负责懂 GPU，Exporter 负责翻译，Prometheus 负责记账和查询，Grafana 负责展示。知乎核心就看四个量：GPU 利用率（DCGM_FI_DEV_GPU_UTIL）、显存占用、温度（DCGM_FI_DEV_GPU_TEMP）和功率，利用率长期 0 说明请求没进来，显存打满说明该换量化或拆模型，温度压线就该查散热了。

坑不多，但全是实坑。DCGM Exporter 默认监听 9400 端口，这周那篇踩坑实录里，作者一开始按别的端口去 curl，半天没数据，查了 NVIDIA 官方文档才确认默认就是 9400。知乎WSL2 环境下推理节点拿的是 NAT 地址，监控节点够不着，还得在 Windows 宿主机上做一层端口转发；SM、Tensor 这类 profiling 指标默认不采，需要在采集器配置里显式打开。还有个更隐蔽的：某些 DCGM PCIe 字段本身已经是 Bytes/s 的 Gauge，再机械套 rate() 算出来的就是"每秒速率的变化率"，面板好看但含义全错。知乎

路线二：盯账单，API 党的成本仪表盘

第二种痛是钱。跑 Agent 应用的人，最怕月底不知道钱被谁烧了。LiteLLM 的 spend log 其实记录了每一次调用的模型、Token 和费用，但靠翻日志是查不出来的，成本治理的最后一步是可见性。知乎做法是现成的：一个 50 行以内的 Python 脚本把 spend log 转成 Prometheus 指标，注意用 Counter 记累计值，趋势交给 rate() 去算，语义才稳定。

面板不用多，四个就够：成本趋势折线（每分钟成本速率）、按模型成本占比饼图、请求失败率单值、Top 5 模型成本表格。告警要盯"增长速率"而不是瞬时总量——你要回答的是"是不是在持续烧钱"，超标就让 Alertmanager 直接推飞书或 Slack。如果不想搭全家桶，同一位作者的建议很实在：先上 crontab，费用破 ¥50/天再升到 Grafana。知乎半小时能搭完的东西，换来的是每天扫一眼就知道钱花在哪。

路线三：盯行为，抓住摸鱼的 Agent

第三条路线最新，也最接近"Grafana 本色"：盯 Agent 的行为本身。今年 6 月知乎《Agent 可观测性工程：给 AI 装上仪表盘》系列用一张图把 Agent 版三支柱摆得很清楚：Metrics 层看任务完成率、Token 消耗和 p50-p99 延迟，是"系统脉搏"；Traces 层把 Goal→Plan→Build→Review 拆成父子 Span，哪一步慢了一目了然，是"执行电图"；Logs 层带 TraceID、AgentID 存决策快照，是"行为记录"。三层最后汇到 OpenTelemetry Collector，展示层依然是统一的 Grafana Dashboard。

同一系列里给出的告警配置也值得直接抄：第一层静态安全网，error_rate 超 15% 直接 critical、日 Token 消耗超 200 万 warning；第二层动态基线，用 7 天指数加权移动平均做基准，2 倍标准差突破才报；第三层异常模式检测，像"skill 自进化后完成率反而下降""Token 消耗持续漂移"这类模式单独抓。先兜底、再基线、后抓模式，这个顺序比一上来就堆阈值稳得多。

说实话，这条路线目前工具最深的还是专用 LLM 可观测产品，Grafana 生态的优势在通用：只要按 OpenTelemetry GenAI 语义约定把追踪写进 gen_ai.* 命名空间，采集和后端就解耦了，今天存 Tempo、明天换 ClickHouse 都不动采集层。质量评估方面，2026 年的业界共识是 LLM-as-Judge：用一个独立的 LLM 在后台对生产流量中的 10-20% 进行质量评分（幻觉检测、毒性检测、任务完成度等），将评分作为 Span 属性写回追踪数据。知乎自建玩家建议先把路线一、二搭起来，路线三先埋好 OTel 采集，等需求明确了再补评估层。

三条路线怎么选，以及接下来盯什么

接下来值得持续盯的信号也有三个：一是 Grafana 13.x 的 AI 功能节奏，13.1.3 里 GitSync 增强和 Assistant 扩展已经落地，AI 进面板的速度在加快；二是 OpenTelemetry GenAI 语义约定的迭代，它决定了你的采集层会不会被锁死；三是大厂动作，Gartner 预测到 2028 年，LLM 可观测将覆盖 50% 的 GenAI 部署，而 2026 年初这个比例只有约 15%。知乎窗口期就这两三年，先上车的人到时候不用换车。

最后说个彩蛋：前几天 B 站有人翻出来，NASA 把用在航天器上的监控框架 Hermes 也开源了，还自带 Grafana 集成。想想挺有意思的——盯航天器的和你盯 Ollama 的，是同一个 Grafana。三条路线，你准备先上哪条？评论区聊聊你现在是怎么盯 AI 的。