OpenTelemetry加持AI项目：监控不再是摆设，实测有坑也有甜头

说真的，你这篇帖子看得我挺有共鸣的，尤其是“坑也不少”那几个字，简直像在说我自己的经历。我在团队里负责AI基础设施的观测体系搭建，从去年下半年开始全面推OpenTelemetry，到现在快一年了，中间踩的坑、绕的路，说起来都能写个小册子了。但反过来，一旦把那些坑填平，确实能感觉到OpenTelemetry在AI场景下的价值是实打实的，不是那种“为了观测而观测”的表面文章。

先回应你第一个问题，关于模型推理的trace上下文传播。这个其实是我踩得最深的坑之一。你想想，LLM推理服务通常不是单体，而是由多个组件拼起来的：请求先经过网关，然后到推理引擎，推理引擎内部又有prefill、decode这些阶段，同时可能还会调用embedding服务、reranker服务，甚至还会去查知识库做检索增强生成。传统RESTful调用的上下文传播，用W3C trace context header就能搞定，但到了模型推理这一步，问题就来了。很多推理框架，比如vLLM、TGI，它们内部是异步的、基于队列的，请求进来后会被拆成多个微批次，然后交给GPU并行计算，最后再合并结果。这个过程中，你原始的trace span怎么跟GPU上的计算任务关联起来？我一开始天真地以为只要在调用推理API的地方加个span就完事了，结果发现根本对不上号。后来我查了OpenTelemetry的社区讨论，发现大家普遍的做法是：在推理框架的调度层手动注入context。具体来说，就是重写推理框架里的请求处理回调，在每次批处理任务创建时，把当前线程的trace id和span id传给任务对象，然后在GPU计算完成、结果返回时，用这些id重新激活父span。这听起来简单，但实现起来很痛苦，因为不同的推理框架内部机制差异极大。我团队用vLLM，它的底层是基于Python的异步调度，我不得不写了一个自定义的instrumentation hook，用OpenTelemetry的Context API把trace context绑定到每个请求的coroutine上。核心代码大概长这样：在请求进入AsyncLLMEngine的add_request方法时，用opentelemetry.context.attach(span_context)设置当前context，然后把这个context作为参数传给生成器。生成器每次yield新的token时，再从中取出context来创建子span。这样一来，每个token的生成耗时都能精确追踪到对应的trace上。当然，性能开销是有的，主要是context切换的Python层开销，实测在高并发下会导致推理延迟增加3%-5%，但为了能定位到prefill和decode阶段的瓶颈，这个代价我们觉得值得。如果你的推理服务是用C++写的，比如TensorRT-LLM，那情况更复杂，因为OpenTelemetry的C++ SDK还不算特别成熟，我见过有人用Zig或者Rust写桥接层，把C++的span数据通过gRPC转发到OpenTelemetry Collector。说实话，这已经有点“为观测而重构”的味道了，不是每个团队都能接受。

再说你第二个问题，OpenTelemetry的metrics在AI场景下要不要自定义一套。我的观点是：必须自定义，而且不能只盯着token消耗和模型幻觉。token消耗是典型的业务指标，OpenTelemetry的metrics体系里虽然有counter和histogram，但它默认的instrumentation包不会给你发token_count这种数据，因为模型服务商不会把业务语义写进通用SDK里。所以你得自己写一个自定义的metrics exporter，在推理请求完成时，从响应中提取usage信息，然后通过OpenTelemetry的Prometheus exporter暴露出去。我们就是这么干的，而且我还进一步把token消耗拆成了input_tokens和output_tokens两个维度，分别打上模型名、模型版本、部署环境这些标签。这样做的好处是，你能在Grafana上直接对比不同模型版本的token产出效率，比如同样是GPTQ量化后的7B模型，v1版本比v2版本多消耗了15%的output tokens，那就能反推是不是v2的采样参数变了，或者解码策略有bug。至于模型幻觉，这个指标更难量化。我们尝试过用LLM-as-judge的方式，在推理完成后，让另一个小模型（比如LLaMA-3-8B）对输出做事实性评分，然后把评分结果作为gauge指标暴露出去。这个做法的问题在于，它引入了额外推理成本，而且评分模型本身也有延迟。所以我们只在10%的采样请求上做这个评估，然后通过OpenTelemetry的exemplar机制，把评分结果关联到对应trace上。这样在排查问题时，你可以直接点开一个trace，看到这个请求的幻觉分数是多少，再结合prompt和输出文本做分析。这套方案跑下来，效果还不错，至少我们内部已经靠它发现了好几次因为RAG检索质量下降导致的幻觉飙升事件。

你提到的tail-based sampling，我深有感触。高并发下span的存储压力是个实实在在的工程问题。我们刚开始用OpenTelemetry时，默认是head-based sampling，也就是在服务端按照固定比例采样，比如10%。结果发现，那些真正有价值的慢请求或者错误请求，因为采样比例低，经常漏掉。后来换成了tail-based sampling，用OpenTelemetry Collector的tail_sampling processor，配置规则是：只要请求的延迟超过P99阈值，或者返回了错误码，或者包含特定的prompt关键词（比如“请解释XXX”这类高风险提示），就强制保留整个trace。这个方案的好处是，存储量从每天几个TB降到了几百GB，而且我们还能保证对异常请求的100%覆盖。但坏处也很明显：它要求你有一个中心化的Collector集群来做决策，因为tail-based sampling需要在所有span到达后再决定是否保留，这意味着你不能在服务端本地就做drop。我们因此不得不把Collector从无状态改为有状态，并且做了水平扩展，用Kafka来缓冲span数据，避免Collector重启导致丢数据。这个架构改动花了我们整整两周时间。另外，还有一个容易被忽视的点：tail-based sampling对内存要求极高。Collector需要把每个未完成的trace的所有span都暂存在内存里，直到trace结束或者超时。我们线上一个高流量模型服务，每秒产生几十万个span，Collector的内存一度飙到50GB。后来我们优化了规则，只对特定服务（比如embedding和推理）启用tail-based sampling，而日志收集这类低价值服务仍然用head-based sampling，才把内存控制住。

关于你提到的行业空白，我完全同意。OpenTelemetry的生态目前确实缺少针对AI workload的成熟Exporter和Dashboard。我们团队现在用的Dashboard，是自己用Grafana的变量模板手写的，把模型延迟、token消耗、GPU利用率、队列深度这些指标拼在一起。但说实话，这个Dashboard的维护成本很高，因为每次新增一个模型版本，都要手动更新变量。我理想中的状态是，OpenTelemetry能出一个类似opentelemetry-collector-contrib的AI扩展包，里面包含针对vLLM、TGI、TensorRT-LLM、SageMaker等主流推理框架的自动instrumentation，以及一个标准的LLM metrics定义集，比如ttft（time to first token）、tpot（tokens per output token）、输入输出token比例、缓存命中率等等。这些指标如果能统一成OpenTelemetry的semantic convention，那以后跨团队、跨工具的对比就容易多了。我注意到OpenTelemetry社区已经在讨论这件事，有个提案叫“Generative AI Semantic Conventions”，但进度比较慢。我猜是因为AI领域变化太快，今天大家还在用GPTQ量化，明天可能就全面转向Mamba架构了，标准化确实很难跟上。

另外，我还想补充一个你可能没提到的点：OpenTelemetry在AI场景下的成本问题。很多人只关注存储和采样的成本，但忽略了instrumentation本身对模型推理性能的影响。我们曾经在一台A100上跑推理服务，同时启用OpenTelemetry的自动instrumentation，结果发现GPU利用率下降了5%，推理延迟增加了8%。排查后发现，是自动instrumentation在每次模型调用时都额外做了一次Python层面的hook，这个hook虽然轻量，但在高并发下会跟CUDA的流调度产生竞争，导致GPU资源利用率下降。后来我们不得不把instrumentation改成了异步模式，用单独的线程来发送span数据，才把性能损失控制在2%以内。所以我的建议是，如果你在GPU资源紧张的环境下跑推理，一定要先做性能压测，确认instrumentation的开销在可接受范围内。另外，可以考虑用eBPF来做更底层的监控，绕过应用层的SDK，直接从内核层面捕获GPU调用。我们团队正在实验一个基于eBPF的方案，用Pixie或者Cilium的Tetragon来监控GPU显存分配和kernel launch事件，然后把数据转成OpenTelemetry格式。这个方案的好处是零侵入，对推理性能几乎没有影响，但缺点是eBPF程序本身需要针对不同的GPU驱动做适配，维护成本不低。

最后，我想说，OpenTelemetry在AI场景下确实不是银弹，但它提供了一个足够好的框架，让我们能把模型推理、向量检索、RAG pipeline这些原本黑盒的环节变成可观测、可调试的透明系统。我见过最惊艳的一个案例是，同事用OpenTelemetry的trace发现，一个看似稳定的推理服务，其实每隔几分钟就会有一次长达5秒的延迟抖动，原因不是模型推理，而是因为embedding服务在重建索引时占满了CPU，导致请求排队。如果没有trace，这种问题可能永远都定位不到。所以我觉得，虽然现在生态还不完善，但方向是对的。你提到的Exporter和Dashboard空白，我觉得接下来半年到一年内，会有创业公司或者开源项目来填补。比如我最近在关注一个叫“Arize AI”的项目，它就是在OpenTelemetry基础上做AI可观测性，已经支持了prompt注入检测和幻觉评分，虽然还没开源，但思路挺对的。另外，Honeycomb和Datadog也在推AI specific的观测功能，不过它们都是商业产品。如果你有精力，其实可以自己写一个轻量级的Exporter，专门把LLM的token消耗、延迟分布、错误分布等指标暴露成Prometheus格式，然后配合Grafana的AI dashboard模板，效果不会比商业产品差太多。我们就是这么干的，代码也就几百行，核心是用OpenTelemetry的metrics API定义好counter和histogram，然后在推理请求的回调里手动记录。如果你感兴趣，我可以把我们在GitHub上开源的版本链接发给你，虽然是草稿级别的代码，但至少能跑起来。