AI 工作负载为何推动可观测性标准扩展

AI 工作负载把“服务是否在线”这个问题，扩展成了“模型是否按预期工作、一次请求花了多少 token、GPU 队列是否拥堵、回答质量是否下降”。因此，可观测性标准的扩展并不是为了给监控面板增加几个字段，而是要让一次模型调用、一次工具调用和一次跨服务协作能够放进同一条可关联的证据链。

官方地址：https://opentelemetry.io/

AI 观测的核心变化，是把传统的请求延迟、错误率和资源使用，与模型、token、推理队列、工具调用、输出事件及成本上下文关联起来。OpenTelemetry 正在提供这套共同语义，但 GenAI 相关约定和 Profiles 仍有部分处于演进或 Alpha 阶段，生产团队应分层采用，不要把草案当成稳定契约。

AI 工作负载改变了可观测性问题

传统 HTTP 服务通常可以用请求量、P95 延迟、错误率、CPU 和内存回答大部分运行问题。AI 推理服务仍然需要这些指标，但它们无法单独解释“为什么同样返回 200，用户体验却明显变差”。

一次生成请求可能经过网关、提示词组装、检索、模型推理、工具调用和结果后处理。模型还会以流式方式返回内容，首 token 延迟与完整响应耗时并不等价；输入和输出 token 数又会影响费用、吞吐和上下文窗口。CNCF 对云原生 AI 平台的梳理已经把 tokens per second、time to first token、queue depth、cache hit rates 列为需要与传统基础设施遥测并存的指标。

为什么需要共同的语义约定

如果每个平台都用自己的字段记录 model、token 或 tool call，跨模型、跨供应商和跨后端比较时，团队仍然会被字段映射拖住。OpenTelemetry 的 Semantic Conventions 通过统一属性名称、类型、含义和取值，让不同代码库、采集链路和后端更容易关联数据。

GenAI 语义约定的方向，是把模型请求的通用信息、响应元数据和 token 使用量放进可理解的遥测结构中；针对用户提示和模型响应，相关设计还使用 Logs API 规范承载事件，并明确标注这部分仍在开发、稳定性有限。供应商专属属性可以补充平台差异，但不应取代通用字段，否则迁移和横向比较会重新变成定制工程。

这也是“标准扩展”的实际含义：不是把所有模型内部细节强行做成同一个接口，而是先约定哪些事实应该能被跨工具理解，再允许实现方补充自己的属性。

Profiles 补上资源消耗的代码视角

日志告诉我们发生了哪些离散事件，指标描述系统层面的变化，链路追踪展示请求怎样穿过分布式组件，而 Profiles 更接近“究竟是哪段代码消耗了资源”。OpenTelemetry 官方文档把 Profiles 描述为正在形成的第四类观测信号，并强调它可以与 trace 或 span 关联。

对 AI 服务而言，这个视角很有价值：当首 token 延迟上升时，指标可以先显示现象，trace 可以定位到模型服务或队列，但 profile 才可能进一步帮助团队判断 CPU 代码、内存分配、锁等待或 I/O 是否构成瓶颈。不过 Profiles 当前标为 Alpha，具体 profile 类型和采集能力还依赖语言运行时与 profiler，不能直接当作所有环境都具备的生产标准。

平台团队和应用团队要观察什么

我更倾向于把 AI 观测拆成两张责任表。应用团队负责让业务语义进入 trace 和事件：例如一次回答对应的会话、检索范围、模型调用、工具调用和业务结果；平台团队负责让这些信号稳定经过采集、采样、脱敏、路由和存储，并把 GPU、队列和实例资源放回同一条关联链路。

治理角色则需要补上成本、隐私和质量边界。提示词和响应内容可能包含敏感数据，默认采集正文并不等于默认安全；事件保留周期、脱敏策略、供应商字段和采样比例都应该成为明确的策略。CNCF 关于 agentic standards 的讨论也把性能、成本、可靠性、安全与输出质量放在同一个评估框架中，这说明“有 trace”只是起点。

分阶段采用比一次性铺满字段更稳

第一阶段先保证关联关系：给网关、检索、模型和工具调用建立统一 trace context，记录服务、模型和部署资源等低敏元数据。第二阶段再补 AI 专用指标，例如首 token 延迟、完整响应耗时、token 吞吐、队列深度、缓存命中率和失败类型。第三阶段引入语义约定与事件，明确哪些模型属性、响应事件和供应商字段可以跨系统消费。

当数据链路稳定后，再把质量评估、成本核算和 Profiles 纳入持续反馈。对于还处于开发或 Alpha 的约定，可以在内部先建立版本化映射层，避免把实验字段直接写死在业务代码里；等规范稳定后再逐步收敛到正式语义。

几个容易混淆的判断

标准扩展不等于所有字段已经稳定。Semantic Conventions 的总体框架成熟，并不意味着每一项 GenAI 约定都已经冻结；阅读具体字段时仍要看稳定性说明。

采集更多内容不等于观测更好。提示词、响应和工具参数要按敏感性分级，能用哈希、摘要或业务标签表达的，不必默认保存原文。

Profiles 也不是 metrics 的替代品。它回答的是代码级资源消耗问题，仍然需要和请求、资源、日志、指标及链路上下文建立关联。

AI 观测不是单独的 AI 面板。如果模型服务、网关、检索库和 GPU 资源没有共同上下文，面板越多，定位一次异常反而越慢。

结语

AI 工作负载推动可观测性标准扩展，根本原因不是模型名字更多，而是系统行为变成了“请求链路、模型行为、资源成本和输出质量”共同作用的结果。OpenTelemetry 提供了跨工具的共同语言，GenAI 语义约定和 Profiles 则把新问题逐步纳入这套语言。

实际落地时，先做上下文关联，再补性能指标和事件，最后把质量、隐私、成本与 profile 关联纳入治理，会比一次性复制一整套实验字段更容易维护。

相关问题

AI 服务为什么不能只监控 GPU 利用率？GPU 利用率只能说明资源忙不忙，不能解释首 token 延迟、token 吞吐、队列等待或一次回答经过了哪些服务。

OpenTelemetry 的 GenAI 事件能不能直接永久依赖？应先查看具体语义约定的稳定性状态。处于开发中的事件可以通过版本化适配层使用，不要未经评估就把字段当作永久契约。

Profiles 适合什么时候引入？当 trace 和基础指标已经能够稳定关联，且团队需要定位 CPU、内存、锁或 I/O 的代码级消耗时，再引入更合适。