看到这个主题，我第一反应就是想起自己去年在生产环境接入OpenTelemetry（以下简称OTel）的经历。AI项目跟普通微服务最大的区别在于：推理链路过长、依赖GPU资源、模型版本管理复杂，这些在OTel的标准实现里几乎都没现成答案。
先说技术核心：OTel在AI场景的关键在于分布式追踪（Distributed Tracing）和指标聚合（Metrics Aggregation）。比如用Span记录模型推理的完整链路——从数据预处理、模型加载、GPU计算到后处理，每个阶段都要打上自定义属性（Attributes），比如模型版本、batch size、推理耗时。但实际落地时，最头疼的是GPU资源的监控。标准OTel Exporter只暴露CPU和内存，要获取GPU利用率、显存占用，必须自己写Collector扩展或集成nvidia-smi的Prometheus Exporter。我个人建议用OpenTelemetry Collector的hostmetrics receiver配合自定义Gauge，但注意采样频率别太高，否则Collector本身会成为性能瓶颈。
另一个容易被忽略的点是：AI服务经常用异步推理或批处理（Batching），这会导致传统基于HTTP请求的追踪语义失效。比如一个Batch请求包含10条输入，Span该如何关联？我的做法是在Span里加入batch_id和input_index作为标签，再通过Metrics记录每个batch的吞吐和延迟分布。
质疑一下：社区现在主推的自动Instrumentation（如OpenLLMetry）对复杂Pipeline支持很差，遇到自定义算子或动态图基本只能手动打点。所以我的建议是：不要过度依赖自动注入，针对关键环节（如模型推理、特征工程）手动编写Instrumentation代码，灵活性和可观测性都更好。
讨论问题：1）大家在AI推理链路里，如何统一追踪异步任务和批处理请求？2）对于GPU之外的NPU（如华为昇腾），OTel的适配目前有成熟方案吗？
行业视野上，OTel正在吞噬可观测性市场，但AI领域的标准化还差得远。谁能解决模型版本与追踪数据的关联（类似MLflow的Lineage），谁就能在MLOps下一波竞争中占优。