LLMOps 可观测性总览

摘要：本文面向需要为 LLM / Agent 应用搭建可观测性体系的 SRE 与平台工程师。传统 APM（延迟、错误率、吞吐）对 LLM 系统必要但不充分——一次返回 200 且延迟正常的请求，仍可能输出幻觉、格式错误或不安全内容。本文给出 LLMOps 可观测性的三大信号（Trace / Metric / Eval）、分层参考架构、主流工具对比，以及一条"先结构化日志、再评估采样"的渐进落地路线。适用模型/栈：OpenAI gpt-4o、Anthropic claude-sonnet 系列、自托管 vLLM 等；语义约定以 OpenTelemetry GenAI Semantic Conventions 为准（[版本相关]：该规范在 2026 年仍处于 experimental，属性名可能随发布变动）。

为什么传统监控不够

传统应用监控假设"相同输入稳定产生相同输出"，靠异常、超时、状态码判断健康。LLM 系统在四个维度打破了这个假设：

维度	传统应用	LLM 应用
延迟驱动	CPU / I/O / 网络	token 数、KV cache、推理并发
成本单位	请求数 / 秒	token 数（输入 + 输出分别计费）
失败模式	异常 / 超时	幻觉、格式漂移、拒答、Prompt 注入
调试产物	堆栈	完整 prompt / completion 内容

最危险的信号是 finish_reason: length 与"语义失败"：模型因 max_tokens 被截断（用户只看到半句答案），传统监控图上全是绿色；或是输出 200 但内容事实错误，用户实际已"信任"了错误答案。这类问题传统 APM 完全不可见。

一个被低估的高价值信号

finish_reason 字段（stop / length / tool_calls / content_filter）是 LLM 生产环境里最可操作、也最常被忽略的遥测。高 length 占比意味着用户正在收到不完整输出，而你的系统状态灯仍是绿的。务必把它作为指标单独统计。

三大信号：Trace / Metric / Eval

LLMOps 可观测性由三类信号组成，缺一不可：

• Trace（追踪）：单次请求的完整调用链——每个 LLM 调用、检索、工具调用、中间状态。回答"这次请求发生了什么"。
• Metric（指标）：聚合后的趋势——错误率、P95 延迟、token 吞吐、成本。回答"现在是否异常"。
• Eval（评估）：对输出的语义质量打分——忠实度（faithfulness）、答案相关性、幻觉率。回答"输出到底对不对"。

观测 vs 监控

可观测性（Observability）是遥测层：trace、span、属性。监控（Monitoring）是趋势层：聚合后的 dashboard 与告警。平台如 Langfuse、Phoenix、LangSmith、Datadog 通常两层都提供。只选观测层，你需要自己搭 dashboard；只选监控层，你无法下钻到单次 trace。

分层参考架构

一个生产可用的 LLMOps 可观测性栈通常分为六层。下图为数据流与分层关系：

分层说明：

1. 埋点层：在 LLM 调用入口用 OTel GenAI 约定或框架 auto-instrumentation 产出 span；在网关/包装层用 Prometheus client 记录 token 与成本。
2. 采集层：OpenTelemetry Collector 统一接收 OTLP，做采样、脱敏、路由。
3. 存储层：Trace 存 Langfuse / Phoenix / Tempo；Metric 存 Prometheus / VictoriaMetrics；评估与审计日志存 PostgreSQL 等。
4. 计算层：评估管线对抽样流量跑 Ragas / LLM-as-judge，分数写回指标。
5. 展示层：Grafana 统一 dashboard（延迟、token、成本、质量四分区）。
6. 响应层：Alertmanager 多级告警 + runbook。

主流工具对比

能力	Langfuse	Arize Phoenix	OpenTelemetry + Prometheus	Datadog
定位	开源 LLM 工程平台（MIT）	开源 LLM 观测 + 评估（OTel 内核）	标准协议 + 自搭	商业 SaaS
追踪	✅ 原生	✅ 基于 OpenInference	✅ 需自搭后端	✅
成本	✅ Spend 看板	部分（需接 OTel）	✅ 自算	✅
评估	✅ 内置 + 集成	✅ 内置 LLM-as-judge	❌ 自搭	✅
自托管	✅ Docker / K8s	✅ 单容器	✅ 完全自控	❌
合规	SOC2 / ISO27001，EU/US 区域	自托管数据不出域	完全自控	商业

选型的合规红线

涉及 PII、商业秘密或受监管行业（金融、医疗、欧盟 AI Act / 瑞士 FADP）时，优先自托管开源方案（Langfuse / Phoenix），不要把 prompt 与 completion 发往境外 SaaS。这是合规底线，不是性能取舍。

渐进落地路线（建议优先级）

不要试图一次建全栈。按信号价值排序：

1. 第 1 周：结构化日志。为每次 LLM 调用记录 model / workflow / tokens / latency / finish_reason / est_cost，路由到现有日志系统。这一步单独就能暴露大部分结构性问题。
2. 第 2 周：格式校验。在 LLM 调用包装层加规则检查（JSON schema / 必填字段），校验失败率 > 3% 即告警。
3. 第 3 周：基础 dashboard。展示错误率、P95 延迟、finish_reason 分布，建立 7 天基线。
4. 第 2 月：5% 抽样评估。选最重要的 workflow，定义 rubric，跑模型评分，跟踪趋势。

评估不必每条请求都跑

5% 抽样的模型评分 + 趋势跟踪，足够在用户投诉前发现质量回归。同步跑评估会为每个请求增加 2–5s 延迟，必须异步（队列 worker）。

安全与合规（贯穿全栈）

• 敏感数据：trace 可能包含用户 PII、商业机密。对 gen_ai.input.messages / gen_ai.output.messages 默认脱敏，或在受监管场景 gate 在开关后。
• PII 泄漏率：建议作为独立指标，目标 0（检出即拦截）。
• 审计覆盖：受监管场景要求 100% 推理调用留痕（EU AI Act Art. 12）。
• Prompt 注入：约 0.3% 请求带注入特征，需检测 + 拦截率指标。

成本视角

LLM 成本按 token 计，且单次请求可能触发 5 次 LLM 调用 + 3 次工具调用。成本监控要点：

• 多维归因：按 model / feature / user / tenant 切分，而非只看总额。
• token 预算告警 是性价比最高的手段：prompt 膨胀或上下文窗口过大，会在账单前就被抓到。
• 缓存命中（cache_read / cache_creation 输入 token）可显著降低输入成本，需单独观测。

成本失控的典型路径

"重试循环 + 上下文膨胀"会在数小时内烧掉一周预算。务必对"每分钟 token 数 > 基线 3 倍持续 5 分钟"设置自动限流/降级告警。

参考资料

• Langfuse 官方文档 - Observability & Tracing
• Arize Phoenix 官方文档 - What is Phoenix
• OpenTelemetry Semantic Conventions for GenAI
• DevOps.com - What You Cannot See Will Break Your LLM App
• FutureAGI - What is LLM Monitoring? Alerts, SLOs, Dashboards in 2026
• mazdek - LLM Observability 2026 (瑞士部署参考架构与 14 指标)