OpenTelemetry GenAI 可观测性：LLM 调用慢到底慢在哪里？

用户说“AI 应用很慢”，运维不能只看接口平均延迟。一次 LLM 调用背后可能包含模型请求、工具调用、检索、重试、上下文拼接、token 生成。如果没有可观测性，你只能猜：是模型慢、网络慢、工具慢，还是 prompt 太长。

OpenTelemetry 在 2026 年发布了关于 GenAI Observability 的实践文章，介绍了生成式 AI 语义约定如何记录模型名、输入输出 token、结束原因、工具调用和延迟指标。对 AI 应用运维来说，这会成为新的基础能力。

GenAI 可观测性看什么

传统服务看：

• 请求数。
• 错误率。
• 延迟。
• CPU、内存。

AI 应用还要看：

• 调用了哪个模型。
• 输入 token 数。
• 输出 token 数。
• 首 token 或总响应时间。
• finish reason。
• tool call 次数和耗时。
• prompt 是否异常变长。
• 重试次数。

如果只看 HTTP 200，根本不知道一次回答为什么花了 45 秒。

OpenTelemetry 提供什么

OpenTelemetry GenAI 语义约定把 AI 调用中的关键字段标准化。例如：

• gen_ai.request.model：调用的模型。
• gen_ai.usage.input_tokens：输入 token。
• gen_ai.usage.output_tokens：输出 token。
• gen_ai.response.finish_reasons：模型停止原因。
• gen_ai.client.operation.duration：调用耗时。
• gen_ai.client.token.usage：token 使用指标。

这些数据可以进入 trace 和 metrics。trace 用来定位单次请求链路，metrics 用来看趋势、成本和异常。

运维落地步骤

第一，先明确链路。一次请求经过哪些组件：网关、应用、向量数据库、工具服务、模型网关、模型服务。

第二，接入 SDK 或框架 instrumentation，把 trace 贯穿起来。

第三，配置 Collector：

receivers:
  otlp:
    protocols:
      http:
      grpc:
exporters:
  otlp:
    endpoint: <backend-endpoint>
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]

第四，建立关键看板：

• 模型调用延迟。
• token 使用量。
• 错误率。
• 工具调用耗时。
• 不同模型的成本和性能对比。

第五，注意敏感内容。prompt、completion、tool 参数可能包含用户数据，生产环境默认不建议随意采集全文。

告警怎么做

建议先做这些：

• P95 模型调用延迟升高。
• input token 突然增大。
• output token 异常增大。
• tool call 错误率上升。
• 某个模型超时或限流错误上升。

AI 应用的成本也可以进入监控。token 使用异常，可能意味着 prompt 设计问题、循环调用或攻击。

常见问题 FAQ

AI 应用只看日志行不行？

不够。日志适合记录事件，trace 更适合串起一次完整调用链路，metrics 更适合做趋势和告警。

Prompt 内容要不要采集？

生产环境要谨慎。内容对调试有价值，但也可能包含隐私和敏感数据。建议默认只采元数据，必要时按环境和权限开启。

运维为什么要懂 token？

token 直接影响延迟和成本。输入过长、输出失控都会拖慢系统并增加费用。

OpenTelemetry 是不是只适合云原生？

不是。它适合统一采集和传输 telemetry 数据，云原生只是最常见场景之一。

参考资料

• OpenTelemetry GenAI Observability: https://opentelemetry.io/blog/2026/genai-observability/