LLM 应用可观测性教练

要解决的问题

传统应用盯 CPU 和内存就够了，但 LLM 应用的「运行时账单」藏在别处：一次调用花了多少钱、首字延迟是多少、哪一轮对话开始变慢——这些指标不会自己出现在 Grafana 里。技能开宗明义：看不见就管不了。它针对的典型场景是成本失控却查不出来源、线上模型偶发异常无法定位、prompt 内容完全没有留痕。

核心能力与关键步骤

技能把可观测性拆成五类必须采集的信号：

• 成本信号：input/output token 数 × 单价，按用户、功能、模型维度聚合，定位烧钱大户
• 延迟信号：首字延迟（TTFT）与总耗时，区分模型慢还是上游网络慢
• 错误信号：HTTP 状态、超时、内容拦截、空输出，计算错误率
• 轨迹信号：prompt 与 response 原文，用于复盘回溯
• 质量信号：可选接评估，把「好不好」也变成指标

归因层面给出可操作的方法：成本按「总账单 → 模型 → 接口 → 用户」逐层下钻；延迟看 P50/P95/P99 分位而非平均值；用 session_id / request_id 串联多轮对话，定位「第几轮开始变贵」。看板最小集只要求四项：日级 token 成本、P95 延迟、错误率、Top10 最贵请求。

告警与复盘配有检查清单，覆盖单用户日成本突增、P95 超基线、错误率区分用户/服务端错误等事项。常见陷阱部分提醒：只看平均值会掩盖长尾问题，混用旗舰与小模型而不区分单价会算不清账，失败请求同样耗 token 却不能从监控里消失。

落地方式与边界

技能不要求上来就接专用平台：在调用层包一层，统一打印 model,cost_ms,tokens_in,tokens_out,ok 到日志，配几条告警即可起步，规模上来再接 Helicone、LangSmith 或自研代理。

需要注意：轨迹留存涉及用户数据，prompt 明文入库可能含 PII，必须脱敏并符合当地法规；全量存轨迹成本高，建议按重要性采样。本技能提供的是监控方法论，不替代具体的合规审查。