1. 从一次慢推理请求说起AI 推理可观测性到底要解决什么如果你正在维护一套跑在 Kubernetes 上的 LLM 推理服务大概率遇到过这种场景用户反馈“回答变慢了”你打开 Grafana 看 CPU 和内存一切正常再跑一下nvidia-smiGPU 利用率 90% 以上看起来“很忙”。但用户的实际体验就是慢而且时快时慢毫无规律。这就是 AI 推理可观测性要解决的核心问题——GPU 忙不等于推理快请求慢不等于模型差。AI 推理全栈可观测性指的是把一次推理请求从进入网关、经过调度、落到 GPU 执行、再返回结果的完整链路用指标Metrics、链路追踪Traces、日志Logs三种数据形态串起来。它适合三类人一是 ML 平台工程师需要给推理集群做容量规划和 SLO 治理二是推理服务 SRE需要在延迟抖动时快速定位根因三是 AI 基础设施开发者需要把推理调用纳入已有的云原生监控体系。传统 APM 在 LLM 场景里会系统性失效。CPU 利用率在 GPU 推理时基本是 idle 的显存HBM才是真正的瓶颈请求延迟如果不拆成排队、Prefill、Decode 三段你根本不知道慢在哪错误率只看 HTTP 状态码模型 OOM 表现为 500但根因在显存分配。更麻烦的是当你的服务里 80% 是短请求、20% 是长请求时平均延迟这个数字对两类用户都没有意义你需要的是按 Token 长度分桶的直方图。这篇文章我会以 TaoToken 统一 Key/API 通道作为接入起点把 GPU 透视、LLM 请求级监控、云原生链路追踪三层串起来交付可复制的 OpenTelemetry Collector 配置、GPU 指标采集脚本以及端到端排查一次慢推理请求的实操动作。你不需要一开始就搭全套可以按层逐步接入。2. TaoToken 统一 Key 接入把推理调用纳入可观测体系的前置准备在讲监控配置之前得先解决一个现实问题你的推理调用入口是否统一。很多团队的可观测性做不起来不是因为工具不够而是因为调用入口太散——有的服务直连自建 vLLM有的走第三方 API有的用不同厂商的 Key导致 Trace 的起点五花八门指标口径对不齐。TaoToken 在这里的作用是提供一个统一的 Key/API 通道让所有推理调用从同一个入口出去这样链路追踪的根 Span 才有统一的注入点。TaoToken 是一个面向开发者的 AI 模型 API 聚合通道官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。它的核心价值在于你用一套 Key 就能调用多种模型Base URL 统一Model ID 统一管理这样在 OpenTelemetry 里注入gen_ai.system和gen_ai.request.model属性时标签维度是干净的不会出现同一个模型在监控里被拆成五六个不同名字的情况。前置准备分三步。第一步拿到 Key。访问 https://taotoken.net/api-keys 创建你的 API Key建议按环境dev/staging/prod分别创建这样在监控里可以通过 Key 前缀区分流量来源。第二步确认 Base URL 和 Model ID。Base URL 是https://taotoken.net/apiModel ID 用你实际要调用的模型名比如claude-sonnet-4-5或gpt-4o这类。第三步在你的推理客户端里把这三件套配好Base URL、API Key、Model ID。这里要强调一个监控设计原则统一入口是为了统一 Trace 上下文。当你的所有推理调用都经过同一个 Base URL 时你可以在客户端 SDK 层统一注入 W3C Trace Context让traceparent头一路透传到推理引擎。如果你的调用入口是散的每个服务各自直连那你就得在每个服务里重复实现上下文注入逻辑维护成本极高而且很容易漏。对于长期做编码和 Agent 场景的团队可以考虑 Coding Plan它适合需要持续调用、多模型切换的开发工作流配合统一 Key 能让你的调用量统计和成本归因更清晰。但如果你只是先验证监控链路用按量计费的 API Key 就够了。配置好之后先别急着上监控用一次最简单的请求确认通道是通的。你可以用 curl 测一下curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: ping}], max_tokens: 16 }如果返回了正常的 JSON 响应说明通道没问题。接下来才是把这套调用接入可观测体系。记住TaoToken 是接入起点不是监控工具本身它的作用是让你的推理调用有一个统一、可追踪的出口。3. 可复制配置OpenTelemetry Collector 与 GPU 指标采集这一节是全文的技术核心我会给出可以直接复制粘贴的配置。整体架构分三层GPU 硬件层用 DCGM Exporter 采集指标推理引擎层用 vLLM 的/metrics端点应用层用 OpenTelemetry Collector 接收 Trace 和 Metric。三层的数据最终汇到 Prometheus 和 Jaeger。先看 OpenTelemetry Collector 的 Gateway 配置。这个配置的关键点是tail_sampling策略——生产环境不可能保留 100% 的 Trace否则存储成本会失控。我的策略是保留所有错误 Trace 和超过 3 秒的长延迟 Trace正常 Trace 采样 10%。配置文件路径建议放在/etc/otelcol/config.yamlreceivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: memory_limiter: limit_mib: 2048 spike_limit_mib: 512 check_interval: 5s batch: send_batch_size: 512 timeout: 5s tail_sampling: decision_wait: 10s num_traces: 100000 policies: - name: errors type: status_code status_code: status_codes: [ERROR] - name: slow-requests type: latency latency: threshold_ms: 3000 - name: baseline-sample type: probabilistic probabilistic: sampling_percentage: 10 exporters: otlp/jaeger: endpoint: jaeger-collector.observability:4317 tls: insecure: true prometheusremotewrite: endpoint: http://prometheus.observability:9090/api/v1/write service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, batch, tail_sampling] exporters: [otlp/jaeger] metrics: receivers: [otlp] processors: [memory_limiter, batch] exporters: [prometheusremotewrite]再看 GPU 指标采集。DCGM Exporter 在 Kubernetes 里以 DaemonSet 部署每个 GPU 节点跑一个实例。如果你用 Helm 部署values 文件里要显式开启 ServiceMonitor并配置自定义指标。下面这段配置我实测下来覆盖了推理场景最关键的十几个指标image: repository: nvcr.io/nvidia/k8s/dcgm-exporter tag: 4.2.0-ubuntu22.04 resources: limits: memory: 256Mi cpu: 200m arguments: - --devices-enabledall - --kubernetes-gpu-id-typedevice-name serviceMonitor: enabled: true interval: 15s additionalLabels: release: kube-prometheus-stack customMetrics: DCGM_FI_DEV_GPU_UTIL: gpu_utilization DCGM_FI_PROF_SM_OCCUPANCY: sm_occupancy DCGM_FI_PROF_DRAM_ACTIVE: dram_active DCGM_FI_DEV_FB_USED: fb_used DCGM_FI_DEV_FB_FREE: fb_free DCGM_FI_DEV_POWER_USAGE: power_usage DCGM_FI_DEV_GPU_TEMP: gpu_temp DCGM_FI_DEV_XID_ERRORS: xid_errors DCGM_FI_DEV_ECC_DBE_VOL_TOTAL: ecc_dbe_total DCGM_FI_DEV_CLOCK_THROTTLE_REASONS: clock_throttle_reasons这里有个坑要提醒DCGM_FI_PROF_SM_OCCUPANCY这类 Profiling 指标需要 DCGM 以 profiling 模式运行在 T4/V100 等旧卡上会引入 5% 到 8% 的性能扰动。如果你的集群是 H100影响小于 3%可以放心开如果是旧卡建议只在排障时临时开启。vLLM 侧的配置相对简单启动参数里加上 OTel 端点和 KV Cache 采样率python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-70B-Instruct \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.92 \ --max-model-len 8192 \ --enable-prefix-caching \ --oltp-traces-endpoint http://otel-collector-agent.observability:4317 \ --collect-detailed-traces model \ --kv-cache-metrics-sample 0.01--collect-detailed-traces model会记录模型前向传播时间生产环境建议就用这个级别。all模式会记录每个 TP rank 的独立耗时额外开销 1% 到 3%只在排查多卡通信问题时临时开。--kv-cache-metrics-sample 0.01表示 1% 的 KV Block 会被采样追踪生命周期这个采样率对大多数场景够用调高会增加内存开销。最后是 Prometheus 的抓取配置通过 ServiceMonitor 自动发现 vLLM 的 metrics 端点apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: vllm-inference namespace: inference labels: release: kube-prometheus-stack spec: selector: matchLabels: app: vllm endpoints: - port: http interval: 15s path: /metrics metricRelabelings: - sourceLabels: [__name__] regex: vllm:(time_to_first_token|inter_token_latency|e2e_request_latency|kv_cache_usage_perc|num_requests_running|num_requests_waiting).* action: keepmetricRelabelings这段很重要。vLLM 暴露的指标有几十个全量抓取会让 Prometheus 的时序基数cardinality快速膨胀。我建议只保留延迟、队列、KV Cache 这几类核心指标其余按需开启。4. 验证请求与成功结果从 Trace 到 GPU 指标的端到端确认配置写完不代表链路通了必须做端到端验证。我一般分三步先确认指标能抓到再确认 Trace 能串起来最后确认 GPU 指标和推理指标能关联。第一步验证 Prometheus 抓到了 DCGM 指标。用 port-forward 把 Prometheus 暴露到本地然后查一下kubectl port-forward -n monitoring svc/kube-prometheus-stack-prometheus 9090:9090 curl -s http://localhost:9090/api/v1/query?queryDCGM_FI_DEV_GPU_UTIL | jq .data.result | length如果返回的数字大于 0说明 GPU 指标已经进来了。再查一下 vLLM 的指标curl -s http://localhost:9090/api/v1/query?queryvllm:kv_cache_usage_perc | jq .data.result你应该能看到每个 vLLM Pod 的 KV Cache 使用率。如果这里是空的检查 ServiceMonitor 的 label 是否和 Prometheus 的 selector 匹配这是最常见的失败原因。第二步发一次真实推理请求确认 Trace 生成。用 curl 打你的推理服务请求头里带上traceparentcurl -X POST http://vllm-inference.inference:8000/v1/chat/completions \ -H Content-Type: application/json \ -H traceparent: 00-$(openssl rand -hex 16)-$(openssl rand -hex 8)-01 \ -d { model: meta-llama/Llama-3.1-70B-Instruct, messages: [{role: user, content: 解释一下什么是 KV Cache}], max_tokens: 256 }然后打开 Jaeger UI搜索这个 trace ID。你应该能看到一棵 Span 树顶层是gen_ai.request下面挂着gen_ai.prefill和gen_ai.decode两个子 Span每个 Span 上有gen_ai.usage.input_tokens和gen_ai.usage.output_tokens属性。如果只看到顶层 Span 没有子 Span说明--collect-detailed-traces参数没生效检查 vLLM 启动日志里有没有 OTel 相关的报错。第三步也是最关键的一步把 Trace 和 GPU 指标关联起来。假设你在 Jaeger 里发现某次请求的gen_ai.prefill耗时 2.4 秒明显异常。这时候切到 Grafana查同一时间窗口的DCGM_FI_PROF_DRAM_ACTIVE和vllm:kv_cache_usage_perc。如果看到 KV Cache 使用率飙到 94%同时显存带宽利用率接近 98%那根因就很清楚了KV Cache 接近耗尽频繁触发 eviction新请求的 Prefill 需要重新计算被驱逐的 prompt block导致 Prefill 阶段膨胀。这个关联动作是可观测性的价值所在。没有它你只能看到“Prefill 慢”但不知道为什么慢有了它你能从用户感知延迟一路穿透到显存带宽这个硬件级原因。验证成功后你的 Grafana 上应该有三块核心面板GPU Fleet Overview 显示所有卡的利用率和显存热力图LLM Inference SLO 显示 TTFT、TPOT、e2e 延迟的 P50/P95/P99Request Trace Explorer 嵌入 Jaeger 视图支持从 PromQL 点直接跳转到 Trace。5. 本篇常见错排查401、local proxy failed 与 OAuth 报错配置过程中最容易卡住的不是监控本身而是接入环节的认证和网络问题。这一节我列几个真实遇到过的报错给出排查路径。报错一401 Unauthorized。这个最常见通常是 API Key 没配对。检查三件事Key 是否复制完整有没有多余空格、请求头是否是Authorization: Bearer $KEY格式、Base URL 是否写成了https://taotoken.net/api而不是带/v1的完整路径。如果你在 OpenTelemetry 的 exporter 里配置了自定义 header确认 header 名大小写正确有些 HTTP 客户端对 header 名大小写敏感。报错二local proxy failed 或 connection refused。这个报错通常出现在 OTel Collector 转发数据时。检查 Collector 的 exporter endpoint 是否可达比如jaeger-collector.observability:4317这个地址在你的集群 DNS 里能不能解析。用kubectl exec进到 Collector Pod 里跑一下nc -zv jaeger-collector.observability 4317。如果连不上检查 NetworkPolicy 是否拦截了跨 namespace 的流量。另一个常见原因是 Collector 的memory_limiter配置太小导致 OOM 后重启表现为间歇性连接失败。报错三reading choices 相关错误。这个报错一般出现在客户端解析响应时说明请求发出去了但响应格式不对。检查你的 Model ID 是否拼写正确有些模型名有版本后缀写错了会返回错误结构。另外确认max_tokens参数没有超过模型上限超限时部分通道会返回非标准错误体。报错四OAuth 或 token 过期。如果你用的是需要 OAuth 刷新的通道检查 token 刷新逻辑是否在并发场景下重复刷新导致竞争。建议在客户端加一个单飞singleflight机制确保同一时间只有一个刷新请求。对于 TaoToken 的 API Key本身是长期有效的不存在 OAuth 刷新问题但如果你在网关层做了 Key 轮换要确保轮换期间新旧 Key 有重叠有效期。报错五Trace 断链。表现为 Jaeger 里只看到 API Gateway 的 Span看不到下游推理引擎的 Span。根因通常是 W3C Trace Context 没有透传。检查你的 HTTP 客户端是否把traceparent头带上了以及推理引擎是否配置了 OTel 端点。如果中间有消息队列比如 Kafka需要手动在消息头里注入和提取上下文这部分 OpenTelemetry SDK 有现成的 propagator 可以用。排查这类问题的通用思路是先确认单点连通性curl 能不能通再确认认证Key 对不对最后确认上下文透传Trace 能不能串。不要一上来就怀疑监控配置八成问题出在接入层。6. 语义一致 CTA把推理调用接入统一可观测体系走到这里你的可观测性链路应该已经能跑通了GPU 指标在 Prometheus 里LLM 请求级指标在 Grafana 上Trace 在 Jaeger 里三者通过时间窗口和 trace ID 关联。接下来要做的是把这套体系固化下来让它成为团队的标准接入方式。如果你还在用散落的 Key 和直连方式调用模型建议先把入口统一到 TaoToken。统一 Key 之后你的 Trace 根 Span 有了稳定的注入点指标口径也能对齐。具体操作是访问 https://taotoken.net/api-keys 创建 Key把 Base URL 设为https://taotoken.net/api然后在你的推理客户端里配置 Model ID。接入文档在 https://taotoken.net/doc 里面有各语言的示例代码。对于需要长期跑编码和 Agent 工作流的团队Coding Plan 提供了更稳定的调用配额和多模型切换能力配合统一 Key 能让你的成本归因和调用量统计更清晰。如果你只是想先验证监控链路用按量计费的 API Key 就够了等链路跑通再考虑升级。验证模型调用是否正常可以用模型对话页面快速测一下确认通道和模型 ID 都没问题。排障和接入过程中遇到问题优先查接入文档大部分认证和参数问题那里都有说明。最后给一个实用建议不要一次性把三层监控全上齐。先上 GPU 指标确认能抓到再上 vLLM 的/metrics确认延迟指标有数据最后上 OpenTelemetry Trace确认链路能串起来。每上一层都做一次端到端验证这样出问题时你能快速定位是哪一层的配置错了。我见过太多团队一次性堆完所有配置结果某个环节断了排查了三天才发现是 ServiceMonitor 的 label 写错了。分层验证步步为营这才是可观测性落地的正确姿势。