推理服务分布式追踪从 HTTP 入口穿透 gRPC 到模型调用一、背景与问题AI 推理服务的调用链路正在变得越来越复杂。一个典型的请求从用户端 HTTP 入口到达 API Gateway再经 gRPC 调用内部推理引擎最后抵达模型执行层。这条链路跨越三种协议、两个网络边界任何一个环节的延迟抖动都会直接影响用户体验。传统监控手段只能看到各组件的独立指标——Gateway 响应时间、gRPC 服务吞吐量、模型推理延迟——但无法回答最关键的问题一个具体请求从入口到返回结果到底在哪一步卡住了这不是运维的奢侈需求而是生产环境故障定位的基本要求。分布式追踪的价值在于把离散的指标串联成一条完整的请求链路让HTTP→gRPC→Model的调用关系可观测、可度量、可回溯。对于 AI 推理服务这层追踪还必须穿透模型内部的子步骤预处理、推理、后处理才能真正定位瓶颈。二、追踪架构设计在推理服务的场景下分布式追踪架构需要解决两个核心问题跨协议的 Trace Context 传播和模型内部子步骤的 Span 拆分。flowchart LR A[HTTP Client] -- B[API Gateway] B -- C[gRPC Inference Service] C -- D[Model Runner] D -- E[Preprocess Span] E -- F[Inference Span] F -- G[Postprocess Span] style A fill:#e1f5fe style B fill:#bbdefb style C fill:#90caf9 style D fill:#64b5f6 style E fill:#42a5f5 style F fill:#2196f3 style G fill:#1976d2上图展示了完整链路。关键设计点如下跨协议 Context 传播。HTTP 层使用 W3C Trace Context 标准traceparent/tracestate头gRPC 层使用 OpenTelemetry 定义的 binary propagator 通过 metadata 传递。两者之间的转换由 Gateway 负责——这是最容易出错的地方必须确保trace-id和span-id的编码格式在 HTTP text format 和 gRPC binary format 之间无损转换。模型内部 Span 拆分。推理不是单一操作。将模型执行拆分为 Preprocess输入序列化、tokenization、Inference模型计算、Postprocess输出解码、格式化三个子 Span每个 Span 记录独立的耗时和资源占用。这样当推理延迟飙升时你能立即区分是输入处理慢还是模型计算慢。三、实现细节3.1 HTTP→gRPC Trace Context 转换以 Go OpenTelemetry 为例Gateway 层的转换逻辑// 从 HTTP 请求提取 Trace Context propagator : otel.GetTextMapPropagator() ctx : propagator.Extract(r.Context(), propagation.HeaderCarrier(r.Header)) // 注入到 gRPC metadata md : metadata.New(nil) propagator.Inject(ctx, propagation.MetadataCarrier(md)) ctx metadata.NewOutgoingContext(ctx, md) // 发起 gRPC 调用 resp, err : inferenceClient.Predict(ctx, req)核心只有三步Extract→Inject→Call。但要注意propagation.MetadataCarrier的实现——它必须正确处理 gRPC metadata 的 key 格式小写否则 Trace Context 会丢失。3.2 模型内部 Span 创建在推理引擎内部为每个子步骤创建子 Spanfunc (s *InferenceService) Predict(ctx context.Context, req *pb.PredictRequest) (*pb.PredictResponse, error) { ctx, preprocessSpan : tracer.Start(ctx, inference.preprocess) tokens : s.preprocess(req.Input) preprocessSpan.End() ctx, inferSpan : tracer.Start(ctx, inference.compute) result : s.model.Run(tokens) inferSpan.End() ctx, postSpan : tracer.Start(ctx, inference.postprocess) output : s.postprocess(result) postSpan.End() return pb.PredictResponse{Output: output}, nil }每个 Span 自动继承父 Span 的trace-id并生成新的span-id。在 Trace Viewer 中这三个子 Span 会嵌套在 inference.predict 父 Span 下形成清晰的层级结构。3.3 关键属性标注为每个 Span 添加业务属性让追踪数据可检索Span 名称关键属性gateway.requesthttp.method, http.status_code, model.nameinference.predictmodel.version, request.batch_sizeinference.computegpu.device, model.latency_msinference.postprocessoutput.token_count属性设计的原则只记能帮助定位问题的数据不要堆砌。GPU 设备型号和 batch size 直接影响推理延迟必须记录而客户端 IP 在追踪层面意义不大交给日志处理。四、生产实践与踩坑Span 爆炸问题。一个批量推理请求可能包含多个样本如果为每个样本都创建子 Span单次请求会产生数百个 Span。生产环境的做法是单样本请求拆子 Span批量请求只在父 Span 上记录batch_size和avg_latency_ms避免 Span 数据量失控。gRPC metadata 大小限制。gRPC 默认限制单个 metadata entry 为 8KB。Trace Context 通常不会超过这个限制但如果你在tracestate里塞了大量自定义 KV就可能触发截断。规范做法tracestate只放关键的推理上下文model_id、pipeline_id其余属性放在 Span 上。采样策略。推理服务的 QPS 通常不高几百到几千建议全量采集而非概率采样。原因很简单每个推理请求的延迟分布差异大采样会丢失尾部延迟数据而尾部延迟正是需要追踪定位的目标。如果 QPS 过高必须采样优先保留错误请求和超慢请求latency P99。Collector 部署拓扑。推理服务通常 GPU 节点和 CPU 节点分离部署。OTel Collector 应在每个节点组部署 Sidecar统一汇聚到中心的 Collector 再写入后端Jaeger / Tempo。不要让 GPU 节点直接往中心发数据GPU 节点的网络带宽是推理服务的资源不应被追踪数据挤占。五、总结推理服务的分布式追踪不是简单地在 HTTP 层加一个 Trace ID而是要完整穿透三层协议、拆分模型内部子步骤、标注业务属性最终形成可检索、可回溯的请求链路。三个关键实践跨协议 Context 传播Gateway 负责 HTTP→gRPC 的 Trace Context 转换确保trace-id无损传递。模型内部 Span 拆分Preprocess/Inference/Postprocess 三步独立计时定位瓶颈到具体子步骤。全量采集优先推理请求的尾部延迟比平均延迟更有诊断价值采样会丢掉最需要的数据。基础设施不需要漂亮话。追踪数据的价值不在于图表好看在于故障发生时能 30 秒内定位瓶颈在哪一层、哪一步。这才是分布式追踪在生产环境存在的意义。