LLM 可观测性工程实战 2026：从 OpenTelemetry GenAI 语义约定到生产级 trace 架构

导言：LLM 应用进入"黑盒生产期"

2026 年,大模型已经走出 demo 阶段。当你的产品里跑了 ChatCompletion、Embedding、Tool Call、Rerank 多链路混合,当 token 计费按输入输出分别定价、当 P95 延迟从 200ms 跳到 12 秒、当用户开始投诉"AI 给的答案不一致",传统的 APM(Datadog/New Relic)在 LLM 应用里几乎失效。原因有四:非确定性输出(同一 prompt 多次返回不同)、Token 计费模型(与 HTTP 请求无关)、Agent 多步链路(一次用户请求展开成 5-50 个 LLM call)、质量与成本的张力(温度从 0 调到 0.7,成本涨一倍,质量未必涨)。

LLM 可观测性(LLM Observability)不是 APM 的子类,而是一套独立的工程学科。本文从 8 个 GitHub 仓库的实时数据(2026-06-15 拉取)出发,拆解 LLM 可观测性的工程地基、信号模型、OpenTelemetry 标准化进程与生产级选型决策。

一、可观测性的三个支柱在 LLM 语境下如何重新定义

经典可观测性=Metrics+Logs+Traces。在 LLM 应用里,这三者都要重新翻译:

• Traces:一次用户请求展开成"trace tree",根 span 是入口,叶子是单次 LLM call。关键差别:LLM trace 是非树状回放(prompt/completion 必须 1:1 对应),不是简单的"调用堆栈"。
• Metrics:除了 QPS/P95/ErrorRate,新增Token 吞吐(tok/s)、$/1k tokens(按模型/供应商分桶)、Cache Hit Ratio(prompt cache 命中)。
• Logs:prompt/completion 是 PII 重灾区,采样+脱敏成硬约束;结构化字段(模型名、温度、tool_call、usage)比纯文本日志更有价值。

根据 Langfuse 官方文档(Langfuse Observability Overview,2026),LLM 应用的 trace 核心是 application tracing——结构化记录每个请求的"完整生命周期",包括 LLM call、retrieval step、tool execution 与业务自定义逻辑,保留因果关系(causal relationships)与时序(timing)。这个定义比 OpenTelemetry 通用 trace 更严格,因为它要求prompt 与 completion 的 1:1 配对与token usage 的精确记录。

二、LLM 可观测性的 5 个核心信号

成熟的 LLM 观测平台在 trace 之上抽离出 5 类信号,任何缺失都会导致生产事故:

2.1 Token Usage(按模型/供应商分桶)

不能只记"总 token"——必须按 model × provider × feature × user_tier 四元组分桶。原因:同一应用可能调用 GPT-4o、Claude Sonnet、本地 Qwen3 三套模型,定价模型完全不同。按 token 维度的成本归因才能回答"哪个产品线烧钱最多"。

2.2 Cost(美元/人民币)

把 token 数 × 单价实时换算。建议在 SDK 层做,避免事后 ETL 漂移。注意:Anthropic、OpenAI、Google 三家的 prompt cache 定价不同(写收费 1.25× vs 读免费),计费逻辑必须跟供应商账单对得上。

2.3 Latency(TTFT + TPOT)

Time To First Token(首字延迟)与 Time Per Output Token(生成吞吐)是两个独立指标。Streaming 场景下,P50 TTFT 200ms 但 P95 4 秒是常见现象,根因往往是上游 rate limit 或 KV-cache miss,不是模型本身慢。

2.4 Quality(LLM-as-Judge + 人工反馈)

仅靠 latency/成本不能判断"答案好不好"。生产级实践是双轨:离线 LLM-as-Judge 跑批量回归 + 在线抽样给人工标注。Langfuse 把这个叫 "scores",可以挂在 trace/observation 任一层级上。

2.5 Retrieval Recall(RAG 应用)

RAG 类应用必须追踪"检索召回质量":recall@K、MRR、上下文相关度。同一 query 改 prompt 模板,召回从 0.72 跌到 0.41 是常态,而 LLM 输出端看不出问题。

三、OpenTelemetry GenAI 语义约定:从厂商混战到标准收敛

2024-2025 年,LangeTrace/OpenLLMetry/Langfuse/Phoenix 各自定义了一套 span attribute 命名(如 llm.request.model vs gen_ai.request.model),给 APM 集成商带来灾难。2024 年底,OpenTelemetry 启动了 GenAI 语义约定专项(gen-ai semantic conventions),并于 2025 年正式合并 Traceloop 的 OpenLLMetry 贡献(Traceloop README 明确写了"Our semantic conventions are now part of OpenTelemetry!")。

截至 2026 年 6 月,OTel Semantic Conventions 已升至 1.42.0 版本,GenAI 字段独立成册,涵盖:

• gen_ai.system:openai/anthropic/vertex_ai/azure_ai_inference 等
• gen_ai.request.model / gen_ai.response.model:实际路由到的模型
• gen_ai.usage.input_tokens / gen_ai.usage.output_tokens:token 用量
• gen_ai.request.temperature / gen_ai.request.top_p:生成参数
• gen_ai.response.finish_reasons:stop/length/tool_calls/content_filter

这套约定让 LLM 观测数据可以直接灌入现有的 OTel Collector,复用 Datadog/Honeycomb/Grafana Tempo/SigNoz 的存储与告警链路,不必为 LLM 再造一套后端。对企业用户,这是决定性优势。

注意 OTel 也为 Agent 场景定义了 Agent spans 与 MCP spans(Model Context Protocol),呼应了 2026 年 Agentic 应用爆发的趋势(参考 MCP 协议事实库)。

四、五大主流平台横向对比(2026-06 实时数据)

以下是 8 个项目的实时 Star 数(2026-06-15 拉取 api.github.com):

选型决策关键点:

1. 如果你已经在用 Datadog/Honeycomb/Grafana:选 OpenLLMetry 或 OpenLIT,把 trace 灌进现有 OTel Collector,复用既有告警与仪表盘,避免数据孤岛。
2. 如果你需要 prompt 版本管理 + dataset 管理 + LLM-as-Judge 一站式:选 Langfuse。它是当前 GitHub Star 最高的 LLM 工程平台,功能最完整,文档最详尽(自带 Interactive Demo 与 Cookbooks)。
3. 如果你是 RAG/Agent 重度用户:选 Opik 或 Phoenix。Opik 对 RAG pipeline 有专门 trace 类型(retrieval → rerank → generation),Phoenix 的实验对比 UI 在 Agent eval 场景很好用。
4. 如果你的核心诉求是"零代码接入 + 1 行 proxy":选 Helicone。它在 OpenAI SDK 兼容层做透明代理,改动最小,但灵活性也最低,无法追踪 agent 多步链路。
5. 如果你是企业级 + 合规要求自托管:Langfuse、Opik、Phoenix 都提供 self-hosted Docker Compose,优先 Langfuse(社区最大、文档最全)。

五、五个生产级工程模式

5.1 Gateway 旁路模式(Zero-code Proxy)

通过反向代理(LiteLLM Proxy、Portkey、Helicone)拦截所有 LLM HTTP 请求,在代理层注入 trace。不改业务代码,适合存量系统快速接入。代价:streaming 场景下首字延迟增加 5-30ms;tool call 与多模态支持的覆盖度看代理实现。

5.2 SDK 异步批处理模式

直接在应用代码里用 SDK(Langfuse SDK、OpenLLMetry SDK),trace 事件入本地队列,后台批量 flush 到远端。Langfuse 官方明确说明:SDK send 是异步的,trace events 在本地排队批 flush,不会影响应用响应时间。生产部署务必配 flush_at 与 flush_interval,避免进程崩溃丢 trace。

5.3 环境隔离模式

用 environment=production/staging/dev 标签或 trace metadata 隔离。生产环境的 trace 是合规与计费依据,dev 环境可能含 PII,必须硬隔离。Langfuse 把这个做成了一级 feature:split traces into environments。

5.4 Distributed Tracing 模式

跨服务 trace 透传(traceparent header),让一次"用户请求 → RAG 服务 → LLM 服务 → 向量库"的链路在 Jaeger/Tempo 里能拼成完整一棵 trace 树。前置依赖:你的应用已经在用 OTel,否则要先把 HTTP/gRPC instrumentation 加上。

5.5 Red-team + Eval 集成模式

把可观测性平台和 eval/red-team pipeline 打通:线上抽样 trace → 自动跑 LLM-as-Judge → 评分回写到 trace。Langfuse 把它叫"online evaluation",OpenLLMetry 通过 OTel metrics 出口对接。这种模式让"质量回归"从离线周报变成实时告警。

六、选型决策树

你的 LLM 调用量?
├─ < 1M req/月 → Helicone(免费层) / 直接 Langfuse Cloud
└─ ≥ 1M req/月 → 进入下一题
    │
    已用 Datadog/Honeycomb/Tempo?
    ├─ YES → OpenLLMetry(纯 SDK,无 lock-in)
    └─ NO → 进入下一题
        │
        需要 prompt 版本管理 + dataset?
        ├─ YES → Langfuse(功能最全)
        └─ NO → Opik / Phoenix(更轻量,开源友好)

七、未来 12 个月的三个趋势

1. OTel GenAI 语义约定 GA:1.42.0 已经合并,预计 12 个月内会有完整 SDK 支持(目前 Python/JS 覆盖度仍滞后)。届时自建 trace 后端的成本会大幅下降。
2. Agent trace 标准化:随着 MCP 协议、Claude Agent SDK、OpenAI Agents SDK 的普及,Agent 多步链路 trace 会成为新刚需。OpenTelemetry 已经定义了 gen_ai.agent.* 与 mcp.* 命名空间,2027 年前会有成熟工具链。
3. Process supervision 与 cost-aware eval:传统 eval 只评"答案对不对",未来会加入"成本是否合理""latency 是否达标""是否走了不必要的 tool call"等多目标优化。这把 LLM 可观测性从"事后审计"推到"在线调优"。

七点五、生产事故案例:三类典型故障的可观测性诊断

在生产中跑过 LLM 应用的团队都会遇到这三类典型事故,可观测性平台的核心价值在于缩短 MTTR(平均修复时间):

事故一:成本一夜翻 3 倍

现象:某 SaaS 平台周一早晨发现 Anthropic 账单从日均 $800 飙到$2400,持续 18 小时。

诊断路径:

1. 在 Langfuse/Opik 按 usage.cost 分桶排序,定位 top-10 高成本 trace
2. 发现异常集中在 claude-opus-4-7 调用(单价比 Sonnet 贵 5×)
3. 追到 root cause:某用户上传了 200KB 简历 PDF,触发长上下文路由规则错误地切到了 Opus
4. 修复方案:在 SDK 层加 if context_tokens > 50k → switch to sonnet 的 cost guard

没有可观测性的话——团队至少要 2-3 天才能定位根因,因为账单系统的归因粒度只到 customer_id,不会告诉你"哪条 prompt"。

事故二:P95 延迟从 1.2s 涨到 8s

现象:周四下午告警群收到 P95 latency 翻倍,业务侧开始投诉"AI 回复慢"。

诊断路径:

1. 在 Tempo/Datadog 看 P95 分布,定位到 95% 集中在 embeddings.create 调用
2. 检查 OpenAI API status:正常
3. 查自己的 trace:发现 latency 飙高的请求全部集中在 vector_store.search 后置的 rerank 调用
4. 根因:Cohere rerank v3 API 在亚洲时段延迟波动,无 fallback
5. 修复方案:rerank 加 timeout 500ms + 失败时降级到 score-based 排序

事故三:线上答案质量突然下降

现象:客服团队反馈"AI 给的退款政策建议开始瞎编",但 error rate 没变化、latency 没变化。

诊断路径:

1. 这种事故只有 trace 能救:error rate 与 latency 都不会变化,因为 HTTP 层面一切正常
2. 抽样 100 条近期 trace,人工评估质量 → 发现 73% 不合格
3. 查 prompt version:发现 6 小时前一次 prompt 模板更新,把 system prompt 里的"必须引用条款原文"删掉了
4. 修复:回滚 prompt 版本 + 加 LLM-as-Judge 自动 eval 拦截,质量分 < 0.7 的 trace 自动告警到 Slack

这三个案例的共同教训:error rate + latency 不是 LLM 应用的充分信号,必须把 cost、quality、retrieval 三类信号都纳入观测平台,才能在第一时间发现"silent degradation"。

八、工程团队的落地建议

• 不要从零自建。GitHub 上 5 个 5000+ Star 的开源项目已经覆盖 80% 场景。优先 Langfuse(功能完整)+ OpenLLMetry(OTel 兼容)的组合。
• trace schema 优先选 OTel GenAI 语义约定。即使短期不接入完整 OTel Collector,也要让自己的 trace JSON 字段命名与之对齐,避免未来迁移成本。
• 采样策略按"成本与质量分桶":高成本请求(大模型、长 prompt)全量采样,低价值请求按 1-10% 采样。同时对质量评分低 + 成本高的 trace 反向 100% 采样。
• PII 脱敏必须在 SDK 层完成。prompt/completion 是 LLM 应用的最大 PII 雷区,事后 ETL 清洗风险远大于源头拦截。
• 告警不要只设 error rate。要按"成本突增 50%"、"P95 latency 翻倍"、"质量分跌 0.1"三个维度分别告警——单看 error rate 会错过大部分 LLM 特定故障。

总结

LLM 可观测性是一套独立的工程学科,核心信号是 token × cost × latency × quality × retrieval 五个维度。OpenTelemetry GenAI 语义约定在 2025-2026 年快速收敛,正在从"厂商混战"走向"标准化"。Langfuse、OpenLLMetry、Opik、Phoenix、Helicone 五大开源项目(合计 GitHub 74,000+ Stars)覆盖了从"零代码代理"到"OTel 原生 SDK"的全谱系场景。生产落地时,优先 OTel-native 方案以保留厂商可迁移性,在 SDK 层做 PII 脱敏与异步批处理,并把 trace 后端与现有 APM 后端打通。LLM 可观测性不是"装个面板",而是 AI 产品走向严肃工程的入场券。

参考资料

1. Langfuse Observability Overview — https://langfuse.com/docs/observability/overview
2. OpenTelemetry GenAI Semantic Conventions(Registry) — https://opentelemetry.io/docs/specs/semconv/attributes-registry/gen-ai/
3. OpenTelemetry Semantic Conventions 1.42.0 — https://opentelemetry.io/docs/specs/semconv/
4. OpenLLMetry GitHub Repo — https://github.com/traceloop/openllmetry
5. Arize Phoenix GitHub — https://github.com/Arize-ai/phoenix
6. Helicone GitHub — https://github.com/Helicone/helicone
7. Comet Opik GitHub — https://github.com/comet-ml/opik
8. OpenLIT GitHub — https://github.com/openlit/openlit
9. GitHub API(实时 Star 数据) — https://api.github.com/repos/<org>/<repo>(2026-06-15 拉取)