控與云原生鏈路追蹤實踐（TaoToken 統(tǒng)一 Key 接入篇）)
1. 從一次慢推理請求說起AI 推理可觀測性到底要解決什么如果你正在維護一套跑在 Kubernetes 上的 LLM 推理服務大概率遇到過這種場景用戶反饋“回答變慢了”你打開 Grafana 看 CPU 和內存一切正常再跑一下nvidia-smiGPU 利用率 90% 以上看起來“很忙”。但用戶的實際體驗就是慢而且時快時慢毫無規(guī)律。這就是 AI 推理可觀測性要解決的核心問題——GPU 忙不等于推理快請求慢不等于模型差。AI 推理全?？捎^測性指的是把一次推理請求從進入網關、經過調度、落到 GPU 執(zhí)行、再返回結果的完整鏈路用指標Metrics、鏈路追蹤Traces、日志Logs三種數據形態(tài)串起來。它適合三類人一是 ML 平臺工程師需要給推理集群做容量規(guī)劃和 SLO 治理二是推理服務 SRE需要在延遲抖動時快速定位根因三是 AI 基礎設施開發(fā)者需要把推理調用納入已有的云原生監(jiān)控體系。傳統(tǒng) APM 在 LLM 場景里會系統(tǒng)性失效。CPU 利用率在 GPU 推理時基本是 idle 的顯存HBM才是真正的瓶頸請求延遲如果不拆成排隊、Prefill、Decode 三段你根本不知道慢在哪錯誤率只看 HTTP 狀態(tài)碼模型 OOM 表現為 500但根因在顯存分配。更麻煩的是當你的服務里 80% 是短請求、20% 是長請求時平均延遲這個數字對兩類用戶都沒有意義你需要的是按 Token 長度分桶的直方圖。這篇文章我會以 TaoToken 統(tǒng)一 Key/API 通道作為接入起點把 GPU 透視、LLM 請求級監(jiān)控、云原生鏈路追蹤三層串起來交付可復制的 OpenTelemetry Collector 配置、GPU 指標采集腳本以及端到端排查一次慢推理請求的實操動作。你不需要一開始就搭全套可以按層逐步接入。2. TaoToken 統(tǒng)一 Key 接入把推理調用納入可觀測體系的前置準備在講監(jiān)控配置之前得先解決一個現實問題你的推理調用入口是否統(tǒng)一。很多團隊的可觀測性做不起來不是因為工具不夠而是因為調用入口太散——有的服務直連自建 vLLM有的走第三方 API有的用不同廠商的 Key導致 Trace 的起點五花八門指標口徑對不齊。TaoToken 在這里的作用是提供一個統(tǒng)一的 Key/API 通道讓所有推理調用從同一個入口出去這樣鏈路追蹤的根 Span 才有統(tǒng)一的注入點。TaoToken 是一個面向開發(fā)者的 AI 模型 API 聚合通道官網是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端點是 https://taotoken.net/api 。它的核心價值在于你用一套 Key 就能調用多種模型Base URL 統(tǒng)一Model ID 統(tǒng)一管理這樣在 OpenTelemetry 里注入gen_ai.system和gen_ai.request.model屬性時標簽維度是干凈的不會出現同一個模型在監(jiān)控里被拆成五六個不同名字的情況。前置準備分三步。第一步拿到 Key。訪問 https://taotoken.net/api-keys 創(chuàng)建你的 API Key建議按環(huán)境dev/staging/prod分別創(chuàng)建這樣在監(jiān)控里可以通過 Key 前綴區(qū)分流量來源。第二步確認 Base URL 和 Model ID。Base URL 是https://taotoken.net/apiModel ID 用你實際要調用的模型名比如claude-sonnet-4-5或gpt-4o這類。第三步在你的推理客戶端里把這三件套配好Base URL、API Key、Model ID。這里要強調一個監(jiān)控設計原則統(tǒng)一入口是為了統(tǒng)一 Trace 上下文。當你的所有推理調用都經過同一個 Base URL 時你可以在客戶端 SDK 層統(tǒng)一注入 W3C Trace Context讓traceparent頭一路透傳到推理引擎。如果你的調用入口是散的每個服務各自直連那你就得在每個服務里重復實現上下文注入邏輯維護成本極高而且很容易漏。對于長期做編碼和 Agent 場景的團隊可以考慮 Coding Plan它適合需要持續(xù)調用、多模型切換的開發(fā)工作流配合統(tǒng)一 Key 能讓你的調用量統(tǒng)計和成本歸因更清晰。但如果你只是先驗證監(jiān)控鏈路用按量計費的 API Key 就夠了。配置好之后先別急著上監(jiān)控用一次最簡單的請求確認通道是通的。你可以用 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 是接入起點不是監(jiān)控工具本身它的作用是讓你的推理調用有一個統(tǒng)一、可追蹤的出口。3. 可復制配置OpenTelemetry Collector 與 GPU 指標采集這一節(jié)是全文的技術核心我會給出可以直接復制粘貼的配置。整體架構分三層GPU 硬件層用 DCGM Exporter 采集指標推理引擎層用 vLLM 的/metrics端點應用層用 OpenTelemetry Collector 接收 Trace 和 Metric。三層的數據最終匯到 Prometheus 和 Jaeger。先看 OpenTelemetry Collector 的 Gateway 配置。這個配置的關鍵點是tail_sampling策略——生產環(huán)境不可能保留 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 節(jié)點跑一個實例。如果你用 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會記錄模型前向傳播時間生產環(huán)境建議就用這個級別。all模式會記錄每個 TP rank 的獨立耗時額外開銷 1% 到 3%只在排查多卡通信問題時臨時開。--kv-cache-metrics-sample 0.01表示 1% 的 KV Block 會被采樣追蹤生命周期這個采樣率對大多數場景夠用調高會增加內存開銷。最后是 Prometheus 的抓取配置通過 ServiceMonitor 自動發(fā)現 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 匹配這是最常見的失敗原因。第二步發(fā)一次真實推理請求確認 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 里發(fā)現某次請求的gen_ai.prefill耗時 2.4 秒明顯異常。這時候切到 Grafana查同一時間窗口的DCGM_FI_PROF_DRAM_ACTIVE和vllm:kv_cache_usage_perc。如果看到 KV Cache 使用率飆到 94%同時顯存帶寬利用率接近 98%那根因就很清楚了KV Cache 接近耗盡頻繁觸發(fā) 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 報錯配置過程中最容易卡住的不是監(jiān)控本身而是接入環(huán)節(jié)的認證和網絡問題。這一節(jié)我列幾個真實遇到過的報錯給出排查路徑。報錯一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 轉發(fā)數據時。檢查 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 相關錯誤。這個報錯一般出現在客戶端解析響應時說明請求發(fā)出去了但響應格式不對。檢查你的 Model ID 是否拼寫正確有些模型名有版本后綴寫錯了會返回錯誤結構。另外確認max_tokens參數沒有超過模型上限超限時部分通道會返回非標準錯誤體。報錯四OAuth 或 token 過期。如果你用的是需要 OAuth 刷新的通道檢查 token 刷新邏輯是否在并發(fā)場景下重復刷新導致競爭。建議在客戶端加一個單飛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 能不能串。不要一上來就懷疑監(jiān)控配置八成問題出在接入層。6. 語義一致 CTA把推理調用接入統(tǒng)一可觀測體系走到這里你的可觀測性鏈路應該已經能跑通了GPU 指標在 Prometheus 里LLM 請求級指標在 Grafana 上Trace 在 Jaeger 里三者通過時間窗口和 trace ID 關聯。接下來要做的是把這套體系固化下來讓它成為團隊的標準接入方式。如果你還在用散落的 Key 和直連方式調用模型建議先把入口統(tǒng)一到 TaoToken。統(tǒng)一 Key 之后你的 Trace 根 Span 有了穩(wěn)定的注入點指標口徑也能對齊。具體操作是訪問 https://taotoken.net/api-keys 創(chuàng)建 Key把 Base URL 設為https://taotoken.net/api然后在你的推理客戶端里配置 Model ID。接入文檔在 https://taotoken.net/doc 里面有各語言的示例代碼。對于需要長期跑編碼和 Agent 工作流的團隊Coding Plan 提供了更穩(wěn)定的調用配額和多模型切換能力配合統(tǒng)一 Key 能讓你的成本歸因和調用量統(tǒng)計更清晰。如果你只是想先驗證監(jiān)控鏈路用按量計費的 API Key 就夠了等鏈路跑通再考慮升級。驗證模型調用是否正常可以用模型對話頁面快速測一下確認通道和模型 ID 都沒問題。排障和接入過程中遇到問題優(yōu)先查接入文檔大部分認證和參數問題那里都有說明。最后給一個實用建議不要一次性把三層監(jiān)控全上齊。先上 GPU 指標確認能抓到再上 vLLM 的/metrics確認延遲指標有數據最后上 OpenTelemetry Trace確認鏈路能串起來。每上一層都做一次端到端驗證這樣出問題時你能快速定位是哪一層的配置錯了。我見過太多團隊一次性堆完所有配置結果某個環(huán)節(jié)斷了排查了三天才發(fā)現是 ServiceMonitor 的 label 寫錯了。分層驗證步步為營這才是可觀測性落地的正確姿勢。 AI 推理全棧可觀測性深度解析：GPU 透視、LLM 監(jiān)控與云原生鏈路追蹤實踐（TaoToken 統(tǒng)一 Key 接入篇）
1. 從一次慢推理請求說起AI 推理可觀測性到底要解決什么如果你正在維護一套跑在 Kubernetes 上的 LLM 推理服務大概率遇到過這種場景用戶反饋“回答變慢了”你打開 Grafana 看 CPU 和內存一切正常再跑一下nvidia-smiGPU 利用率 90% 以上看起來“很忙”。但用戶的實際體驗就是慢而且時快時慢毫無規(guī)律。這就是 AI 推理可觀測性要解決的核心問題——GPU 忙不等于推理快請求慢不等于模型差。AI 推理全?？捎^測性指的是把一次推理請求從進入網關、經過調度、落到 GPU 執(zhí)行、再返回結果的完整鏈路用指標Metrics、鏈路追蹤Traces、日志Logs三種數據形態(tài)串起來。它適合三類人一是 ML 平臺工程師需要給推理集群做容量規(guī)劃和 SLO 治理二是推理服務 SRE需要在延遲抖動時快速定位根因三是 AI 基礎設施開發(fā)者需要把推理調用納入已有的云原生監(jiān)控體系。傳統(tǒng) APM 在 LLM 場景里會系統(tǒng)性失效。CPU 利用率在 GPU 推理時基本是 idle 的顯存HBM才是真正的瓶頸請求延遲如果不拆成排隊、Prefill、Decode 三段你根本不知道慢在哪錯誤率只看 HTTP 狀態(tài)碼模型 OOM 表現為 500但根因在顯存分配。更麻煩的是當你的服務里 80% 是短請求、20% 是長請求時平均延遲這個數字對兩類用戶都沒有意義你需要的是按 Token 長度分桶的直方圖。這篇文章我會以 TaoToken 統(tǒng)一 Key/API 通道作為接入起點把 GPU 透視、LLM 請求級監(jiān)控、云原生鏈路追蹤三層串起來交付可復制的 OpenTelemetry Collector 配置、GPU 指標采集腳本以及端到端排查一次慢推理請求的實操動作。你不需要一開始就搭全套可以按層逐步接入。2. TaoToken 統(tǒng)一 Key 接入把推理調用納入可觀測體系的前置準備在講監(jiān)控配置之前得先解決一個現實問題你的推理調用入口是否統(tǒng)一。很多團隊的可觀測性做不起來不是因為工具不夠而是因為調用入口太散——有的服務直連自建 vLLM有的走第三方 API有的用不同廠商的 Key導致 Trace 的起點五花八門指標口徑對不齊。TaoToken 在這里的作用是提供一個統(tǒng)一的 Key/API 通道讓所有推理調用從同一個入口出去這樣鏈路追蹤的根 Span 才有統(tǒng)一的注入點。TaoToken 是一個面向開發(fā)者的 AI 模型 API 聚合通道官網是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端點是 https://taotoken.net/api 。它的核心價值在于你用一套 Key 就能調用多種模型Base URL 統(tǒng)一Model ID 統(tǒng)一管理這樣在 OpenTelemetry 里注入gen_ai.system和gen_ai.request.model屬性時標簽維度是干凈的不會出現同一個模型在監(jiān)控里被拆成五六個不同名字的情況。前置準備分三步。第一步拿到 Key。訪問 https://taotoken.net/api-keys 創(chuàng)建你的 API Key建議按環(huán)境dev/staging/prod分別創(chuàng)建這樣在監(jiān)控里可以通過 Key 前綴區(qū)分流量來源。第二步確認 Base URL 和 Model ID。Base URL 是https://taotoken.net/apiModel ID 用你實際要調用的模型名比如claude-sonnet-4-5或gpt-4o這類。第三步在你的推理客戶端里把這三件套配好Base URL、API Key、Model ID。這里要強調一個監(jiān)控設計原則統(tǒng)一入口是為了統(tǒng)一 Trace 上下文。當你的所有推理調用都經過同一個 Base URL 時你可以在客戶端 SDK 層統(tǒng)一注入 W3C Trace Context讓traceparent頭一路透傳到推理引擎。如果你的調用入口是散的每個服務各自直連那你就得在每個服務里重復實現上下文注入邏輯維護成本極高而且很容易漏。對于長期做編碼和 Agent 場景的團隊可以考慮 Coding Plan它適合需要持續(xù)調用、多模型切換的開發(fā)工作流配合統(tǒng)一 Key 能讓你的調用量統(tǒng)計和成本歸因更清晰。但如果你只是先驗證監(jiān)控鏈路用按量計費的 API Key 就夠了。配置好之后先別急著上監(jiān)控用一次最簡單的請求確認通道是通的。你可以用 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 是接入起點不是監(jiān)控工具本身它的作用是讓你的推理調用有一個統(tǒng)一、可追蹤的出口。3. 可復制配置OpenTelemetry Collector 與 GPU 指標采集這一節(jié)是全文的技術核心我會給出可以直接復制粘貼的配置。整體架構分三層GPU 硬件層用 DCGM Exporter 采集指標推理引擎層用 vLLM 的/metrics端點應用層用 OpenTelemetry Collector 接收 Trace 和 Metric。三層的數據最終匯到 Prometheus 和 Jaeger。先看 OpenTelemetry Collector 的 Gateway 配置。這個配置的關鍵點是tail_sampling策略——生產環(huán)境不可能保留 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 節(jié)點跑一個實例。如果你用 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會記錄模型前向傳播時間生產環(huán)境建議就用這個級別。all模式會記錄每個 TP rank 的獨立耗時額外開銷 1% 到 3%只在排查多卡通信問題時臨時開。--kv-cache-metrics-sample 0.01表示 1% 的 KV Block 會被采樣追蹤生命周期這個采樣率對大多數場景夠用調高會增加內存開銷。最后是 Prometheus 的抓取配置通過 ServiceMonitor 自動發(fā)現 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 匹配這是最常見的失敗原因。第二步發(fā)一次真實推理請求確認 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 里發(fā)現某次請求的gen_ai.prefill耗時 2.4 秒明顯異常。這時候切到 Grafana查同一時間窗口的DCGM_FI_PROF_DRAM_ACTIVE和vllm:kv_cache_usage_perc。如果看到 KV Cache 使用率飆到 94%同時顯存帶寬利用率接近 98%那根因就很清楚了KV Cache 接近耗盡頻繁觸發(fā) 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 報錯配置過程中最容易卡住的不是監(jiān)控本身而是接入環(huán)節(jié)的認證和網絡問題。這一節(jié)我列幾個真實遇到過的報錯給出排查路徑。報錯一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 轉發(fā)數據時。檢查 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 相關錯誤。這個報錯一般出現在客戶端解析響應時說明請求發(fā)出去了但響應格式不對。檢查你的 Model ID 是否拼寫正確有些模型名有版本后綴寫錯了會返回錯誤結構。另外確認max_tokens參數沒有超過模型上限超限時部分通道會返回非標準錯誤體。報錯四OAuth 或 token 過期。如果你用的是需要 OAuth 刷新的通道檢查 token 刷新邏輯是否在并發(fā)場景下重復刷新導致競爭。建議在客戶端加一個單飛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 能不能串。不要一上來就懷疑監(jiān)控配置八成問題出在接入層。6. 語義一致 CTA把推理調用接入統(tǒng)一可觀測體系走到這里你的可觀測性鏈路應該已經能跑通了GPU 指標在 Prometheus 里LLM 請求級指標在 Grafana 上Trace 在 Jaeger 里三者通過時間窗口和 trace ID 關聯。接下來要做的是把這套體系固化下來讓它成為團隊的標準接入方式。如果你還在用散落的 Key 和直連方式調用模型建議先把入口統(tǒng)一到 TaoToken。統(tǒng)一 Key 之后你的 Trace 根 Span 有了穩(wěn)定的注入點指標口徑也能對齊。具體操作是訪問 https://taotoken.net/api-keys 創(chuàng)建 Key把 Base URL 設為https://taotoken.net/api然后在你的推理客戶端里配置 Model ID。接入文檔在 https://taotoken.net/doc 里面有各語言的示例代碼。對于需要長期跑編碼和 Agent 工作流的團隊Coding Plan 提供了更穩(wěn)定的調用配額和多模型切換能力配合統(tǒng)一 Key 能讓你的成本歸因和調用量統(tǒng)計更清晰。如果你只是想先驗證監(jiān)控鏈路用按量計費的 API Key 就夠了等鏈路跑通再考慮升級。驗證模型調用是否正常可以用模型對話頁面快速測一下確認通道和模型 ID 都沒問題。排障和接入過程中遇到問題優(yōu)先查接入文檔大部分認證和參數問題那里都有說明。最后給一個實用建議不要一次性把三層監(jiān)控全上齊。先上 GPU 指標確認能抓到再上 vLLM 的/metrics確認延遲指標有數據最后上 OpenTelemetry Trace確認鏈路能串起來。每上一層都做一次端到端驗證這樣出問題時你能快速定位是哪一層的配置錯了。我見過太多團隊一次性堆完所有配置結果某個環(huán)節(jié)斷了排查了三天才發(fā)現是 ServiceMonitor 的 label 寫錯了。分層驗證步步為營這才是可觀測性落地的正確姿勢。