推理服务分布式追踪：从 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 创建
在推理引擎内部，为每个子步骤创建子 Span：
func (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.request | http.method, http.status_code, model.name |
| inference.predict | model.version, request.batch_size |
| inference.compute | gpu.device, model.latency_ms |
| inference.postprocess | output.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 秒内定位瓶颈在哪一层、哪一步。这才是分布式追踪在生产环境存在的意义。