遙測（Telemetry）

3 秒看懂

遙測 = 把遠端系統的”體檢資料”自動、即時、結構化地傳回來。 在 AI 產業語境下，它覆蓋從單顆 GPU 晶片溫度/功耗/錯誤率，到叢集級網路擁塞/作業吞吐，再到模型服務端推論延遲/漂移訊號的全鏈路執行態資料採集與傳輸。沒有遙測，萬卡叢集是盲飛。

3 分鐘產業解釋

為什麼遙測突然變成熱詞？

大型模型時代，訓練一次 GPT-4 量級的模型可能消耗數千塊高階 GPU 執行數月、花費上億美元算力費用。在這個規模下：

故障是常態，不是例外。 一塊 GPU 的視訊記憶體 ECC 錯誤、一根光纜的訊號衰減、一臺交換器的微突發擁塞，都可能導致 checkpoint 浪費數十萬美元。NVIDIA 在技術分享中多次提到，大規模訓練中 GPU 硬體錯誤（XID 錯誤）的頻率遠高於小規模場景 [廠商技術部落格, NVIDIA GTC 演講]。
“看不見”= 無法最佳化。 GPU 利用率到底是 60% 還是 35%？是計算瓶頸還是通訊瓶頸？沒有遙測資料，一切都是猜。
合規與成本管理。 多租戶雲端環境下，按 GPU-seconds 計費需要精確的執行態資料支撐。

一句話定義

遙測（Telemetry） 是指在分散式計算系統中，通過嵌入式感測器、硬體計數器、軟體探針或旁路代理，對系統執行狀態（溫度、功耗、利用率、錯誤碼、網路延遲、I/O 吞吐等）進行週期性取樣，並將資料結構化傳輸至集中式監控/分析平台的技術體系。

它不是”監控”本身（那是視覺化/告警層的事），而是監控的資料供給側。

15 分鐘專家深入

1. 遙測在 AI 基礎設施中的分層架構

從底層到應用，遙測資料可分為四層：

┌─────────────────────────────────────────────────────┐
│  Layer 4: 模型層遙測 (Model Telemetry)               │
│  - 推論延遲 P50/P99、吞吐(tokens/s)                  │
│  - 輸入/輸出 token 分佈、logit 分佈漂移               │
│  - 模型質量指標（人工標註取樣、自動評估分數）          │
├─────────────────────────────────────────────────────┤
│  Layer 3: 應用/編排層遙測 (Orchestration Telemetry)  │
│  - 作業排隊時長、資源分配效率                         │
│  - Checkpoint 寫入/恢復耗時                          │
│  - 架構級 metrics（NCCL 集合通訊耗時、pipeline bubble）│
├─────────────────────────────────────────────────────┤
│  Layer 2: 平台層遙測 (Platform Telemetry)            │
│  - GPU SM 利用率、視訊記憶體頻寬利用率、NVLink/NVSwitch 頻寬│
│  - 網路埠吞吐/丟包/ECN 標記率                      │
│  - 儲存 IOPS、讀寫頻寬                               │
├─────────────────────────────────────────────────────┤
│  Layer 1: 硬體層遙測 (Hardware Telemetry)            │
│  - 晶片結溫、功耗、電壓                              │
│  - ECC 錯誤（單位元/雙位元）、XID 錯誤碼              │
│  - 風扇轉速、PSU 效率、液體冷卻迴路溫度               │
└─────────────────────────────────────────────────────┘

2. 關鍵技術機制

2.1 硬體計數器與嵌入式感測器

現代 GPU（以 NVIDIA 資料中心產品線為例）內建大量硬體效能計數器（Performance Counters）和感測器：

溫度感測器： 通常在 GPU die、HBM 堆疊、供電模組等多處部署，取樣精度在廠商工具鏈中通常可達 [廠商文件, 具體精度未充分公開]。
功耗監控： 通過晶片內建的功率感測器即時採集，精度與取樣率因架構代際而異。
ECC 計數器： 記錄視訊記憶體和 L2 cache 的單位/雙位糾錯/檢錯事件，是判斷 GPU 健康狀態的關鍵訊號。
XID 錯誤： GPU 驅動層報告的硬體/驅動異常編碼，是定位故障 GPU 的核心依據。

NVIDIA 提供 DCGM（Data Center GPU Manager） 作為資料中心級 GPU 遙測的官方工具庫，支援對上述計數器的採集、健康檢查和診斷 [NVIDIA DCGM 文件]。AMD 的 ROCm 生態中有 rocm-smi 及相關監控工具；Intel 的 oneAPI 生態中也有 GPU 監控介面。

2.2 傳輸協議與採集模式

遙測資料從產生到被消費，典型鏈路為：

硬體計數器/感測器
       │
       ▼
  端側採集 Agent（如 DCGM Exporter、node_exporter、nvidia-smi daemon）
       │
       ▼  通常為 pull（HTTP /metrics 端點）或 push（gRPC/OTLP）
  訊息佇列 / 時序資料庫（如 Prometheus、InfluxDB、VictoriaMetrics）
       │
       ▼
  視覺化 / 告警 / 分析層（Grafana、Datadog、自研平台）

採集模式分類：

模式	描述	典型場景
輪詢（Pull）	監控平台定期向 Agent 拉取指標	Prometheus 生態最常見
推送（Push）	Agent 主動將指標推至收集端	短生命週期任務、邊緣場景
旁路映象（Tap/Mirror）	網路交換器映象流量至分析端	網路層流量分析
帶內遙測（In-band Telemetry）	在資料包頭嵌入交換器狀態資訊（如 INT, iOAM）	高精度網路診斷

2.3 帶內網路遙測（In-Network Telemetry, INT）

在 AI 叢集的 RoCE/InfiniBand 網路中，帶內遙測是一個前沿方向：

原理： 在資料包（或 probe 包）中插入特定 header，沿途交換器在轉發時將自身狀態（佇列深度、埠利用率、時間戳、ECN 標記等）寫入該 header。到達目的端後，接收方可解析出完整路徑的狀態快照。
標準： ONF 的 INT 規範、IETF 的 iOAM（In-situ Operations, Administration, and Maintenance）架構。
AI 叢集價值： 大型模型訓練中集合通訊（AllReduce、All-to-All 等）對尾延遲極敏感。INT 可精確定位哪一跳交換器的哪個端口出現了擁塞，將故障定位時間從小時級縮短到分鐘級。

2.4 採集開銷與折衷

遙測本身消耗資源——CPU 週期、網路頻寬、儲存空間。在萬卡叢集中需要精心設計：

取樣頻率 vs 精度： 功耗監控每秒 1 次即可滿足趨勢分析，但網路微突發檢測可能需要亞毫秒級取樣。
聚合策略： 端側先做 10s/60s 視窗聚合（min/max/avg/percentile），再傳輸聚合結果，大幅降低頻寬消耗。
選擇性採集： 正常狀態下低頻採集，異常觸發時自動切換到高頻診斷模式（“錄製-回放”範式）。

公開文獻中，遙測採集對 GPU 計算效能的影響通常被控制在較低水平（通常 < 1-2%），但具體數值取決於採集頻率和工具實現 [行業共識, 未見統一基準測試釋出]。

技術原理（深度）

核心機制拆解

A. GPU 硬體遙測的實現原理

以 NVIDIA 資料中心 GPU 為例，硬體遙測依賴以下機制：

板載管理控制器（BMC/Baseboard Management Controller）： 獨立於主 GPU die 的低功耗微控制器，持續採集溫度、電壓、風扇轉速等模擬/數字訊號，即使 GPU 主體掉電也可工作。
GPU 內部 PMU（Performance Monitoring Unit）：
- 提供數百個硬體效能計數器（Performance Counters），覆蓋 SM 活動週期、視訊記憶體事務、Tensor Core 利用率、NVLink 流量等。
- 通過 NVPMI（NVIDIA Performance Monitoring Interface） 或 perf 子系統暴露給使用者態工具。
- 計數器通常有位寬限制（如 32/48 bit），溢位時需軟體層處理翻轉。
NVSwitch/NVLink 遙測：
- NVLink 鏈路級錯誤計數（CRC 錯誤、重試計數）可通過 NVLink 驅動介面查詢。
- NVSwitch 的頻寬利用率、埠擁塞狀態通過 NVSwitch 管理介面暴露（具體 API 細節見廠商文件）。

┌───────────────────────────────────────┐
│            GPU Die                     │
│  ┌─────────┐  ┌──────────────────┐    │
│  │  PMU    │  │ 內部溫度感測器陣列│    │
│  │ 計數器  │  │ (多點分佈)       │    │
│  └────┬────┘  └────────┬─────────┘    │
│       │                │              │
│       └────────┬───────┘              │
│                ▼                      │
│       驅動層採集介面                    │
│       (libdcgm / nvidia-smi / ...)    │
│                │                      │
└────────────────┼──────────────────────┘
                 ▼
         Host CPU 上的採集 Agent
         (DCGM Exporter / Prometheus exporter)
                 │
                 ▼
         集中監控平台

B. 時序資料的儲存與查詢最佳化

AI 叢集遙測產生的時序資料量巨大。以萬卡叢集、每張卡 100 個指標、10 秒取樣間隔估算：

每秒資料點 ≈ 10,000 × 100 / 10 = 100,000 points/s
每天 ≈ 86.4 億資料點

時序資料庫（TSDB）在此場景下需具備：

高壓縮比： 針對浮點型時序資料的專用編碼（如 Gorilla 編碼、delta-of-delta 時間戳編碼），壓縮比通常可達 10:1 以上。
高效聚合查詢： 按時間視窗和標籤維度快速計算 percentiles。
資料分層儲存： 熱資料（近 24h）保留高精度，冷資料自動降取樣或遷移至物件儲存。

典型方案：Prometheus + Thanos/Cortex（水平擴充套件）、VictoriaMetrics、InfluxDB、TimescaleDB。

C. 模型層遙測的特殊機制

模型層遙測與傳統基礎設施遙測有本質不同——它關注的是語義級訊號：

輸入/輸出分佈監控： 記錄每個請求的 token 數、token 頻率分佈，檢測 distribution shift。當生產流量的 token 分佈與訓練資料顯著偏離時，模型輸出質量可能下降。
Logit 分佈取樣： 對模型輸出層的 logit 向量進行取樣，監控熵值（entropy）變化——熵值異常升高可能意味著模型”不確定”。
延遲分解： 將推論延遲拆分為 prefill 階段（受序列長度和計算量影響）和 decode 階段（受 KV cache 命中率和訪存頻寬影響），分別追蹤。
安全過濾訊號： guardrail 模組的攔截率、分類置信度分佈。

這些資料的採集通常嵌入在推論服務架構（如 vLLM、TensorRT-LLM、Triton Inference Server）內部或通過 sidecar proxy 實現。

技術演進史

時期	核心特徵	代表技術/事件
1950s-1960s	起源於航天：火箭/衛星通過無線電將感測器資料傳回地面站	阿波羅計劃遙測系統
1970s-1990s	工業 SCADA 系統：電力、石化等行業的遠端監控	Modbus、DNP3 協議
2000s	網際網路運維：SNMP、syslog 時代，伺服器級監控	Nagios、Zabbix、Cacti
2010-2015	雲端運算催生指標/日誌/追蹤三大支柱（Metrics/Logs/Traces）	Prometheus 開源（2012 SoundCloud）、OpenTelemetry 草案
2016-2019	GPU 虛擬化與容器化推動資料中心 GPU 遙測標準化	NVIDIA DCGM 釋出、Kubernetes device plugin 生態
2020-2022	大型模型訓練規模躍升至千卡級，故障管理成為剛需	NCCL profiling、叢集級 GPU 遙測成為 MLOps 核心元件
2023-至今	萬卡叢集常態化，帶內網路遙測、晶片級遙測深度整合	INT/iOAM 在 AI 叢集落地；GPU 遙測與排程器深度耦合

技術路線對比

維度	傳統輪詢式遙測 (Pull)	推送式遙測 (Push)	帶內網路遙測 (INT)	晶片級嵌入式遙測
資料粒度	秒級	秒~亞秒級	逐包/逐流級	硬體時鐘級（ns~μs）
部署複雜度	低	低-中	高（需交換器支援）	低（晶片內建）
對業務影響	極低	低	極低（旁路或 probe 包）	零（硬體獨立）
覆蓋範圍	主機/裝置級	主機/容器/函式級	網路路徑級	晶片內部級
典型延遲	採集週期內（10-60s）	即時	即時	即時
適用場景	通用基礎設施監控	短生命週期任務、邊緣	AI 叢集網路診斷	GPU 故障預測/健康檢查
標準化程度	高（Prometheus/OpenMetrics）	高（OTLP/OpenTelemetry）	中（INT/iOAM 規範，實現碎片化）	低（廠商私有 API 為主）

上下游

上游（遙測依賴什麼）

層級	關鍵依賴	代表供應商/技術
晶片	硬體感測器、PMU、管理控制器	NVIDIA、AMD、Intel、Broadcom（交換晶片）
互聯	NVLink/NVSwitch 狀態介面、InfiniBand/RoCE 網路管理介面	NVIDIA、Broadcom、Marvell
作業系統/驅動	核心 perf 子系統、GPU 驅動的遙測介面	Linux kernel、NVIDIA 驅動
容器/編排	K8s device plugin、cAdvisor、node_exporter	Kubernetes 生態

下游（遙測資料餵給誰）

層級	消費方式	代表方案
視覺化	儀表盤、拓撲圖	Grafana、Datadog、自研平台
告警	閾值/異常檢測觸發通知	Alertmanager、PagerDuty、自研
自動化運維	故障自愈、GPU 隔離、作業遷移	Slurm/K8s 排程器 + 自動化 playbook
容量規劃	資源利用率趨勢分析、採購決策支撐	歷史資料分析、自研容量模型
成本最佳化	GPU 利用率低的作業識別、閒置資源回收	FinOps 工具鏈
AIOps	基於 ML 的異常檢測、根因分析、預測性維護	Datadog Watchdog、BigPanda、自研

關鍵指標

指標	定義	AI 場景參考範圍 [行業估算]
GPU SM 利用率	流式多處理器活躍週期佔比	訓練良好時 > 70-85%，低於 50% 通常需排查
視訊記憶體頻寬利用率	實際頻寬 / 峰值頻寬	LLM 訓練 decode 階段通常 > 80%
GPU 功耗 / TDP 比	實際功耗 / 額定功耗	訓練時通常 60-80% TDP
ECC 錯誤率	單位元/雙位元錯誤次數 / 時間	短期零為佳；持續單位元錯誤需關注
網路丟包率	丟包數 / 總包數	RoCE 叢集應 < 10⁻⁶
集合通訊尾延遲	AllReduce 等操作的 P99 延遲	超過平均值 2x+ 通常指示網路問題
Checkpoint 寫入耗時	模型狀態持久化所需時間	隨模型引數量和儲存頻寬變化巨大
推論延遲 P50/P99	請求端到端延遲	取決於模型大小和硬體配置
tokens/s/GPU	單卡推論吞吐	因模型和硬體代際差異極大
作業等待時間	提交到實際執行的排隊時長	大型叢集高峰期可能達小時級

供需與市場資料

需求側驅動力

AI 訓練叢集規模持續膨脹： 從千卡到萬卡再到十萬卡（如報道中 xAI Memphis 叢集、Meta 訓練叢集規模），遙測複雜度與資料量非線性增長。
GPU 資產高價值化： 單塊高階 GPU 價格在數萬美元量級 [供應鏈估算]，任何故障導致的計算浪費成本高昂。
多租戶雲端 GPU 服務： 精確的執行態資料是計費和 SLA 保障的基礎。
推論服務規模化： 從實驗室部署到大規模線上服務，需要生產級的可觀測性。

供給側格局

GPU 廠商原生工具： NVIDIA DCGM、AMD ROCm-SMI、Intel GPU Top。這些工具提供底層能力，但通常不足以覆蓋企業級監控需求。
通用可觀測性平台： Datadog（市值數百億美元級別，已整合 GPU 監控）、Grafana Labs、New Relic、Dynatrace。
AI 特化監控： Weights & Biases（訓練實驗追蹤，含硬體指標）、Arize AI、Arthur AI、WhyLabs（模型層遙測）。
網路遙測： Arista（支援 INT 的交換器）、Cisco、各網路裝置廠商。
開源生態： Prometheus + DCGM Exporter 是當前最廣泛的 GPU 遙測開源方案。

市場規模方面，遙測屬於更廣泛的 可觀測性（Observability） 市場的一部分。全球可觀測性市場據行業分析師估算已達數百億美元量級且持續增長 [行業報告估算, 具體數字因口徑而異]，AI 基礎設施監控是其中增速最快的細分之一。

代表公司與資本對映

公司	角色	與遙測的關係	公開市場/融資資訊
NVIDIA	GPU 廠商，原生遙測能力提供者	DCGM、NVSwitch 遙測介面、NVLink 錯誤監控	NASDAQ: NVDA
Datadog	通用可觀測性平台	已整合 GPU/ML 模型監控模組，DDTrace 覆蓋推論鏈路	NASDAQ: DDOG
Grafana Labs	開源可觀測性棧	Grafana + Prometheus + Loki 組合，大量 AI 團隊使用	私有公司，估值曾報道達 60 億美元量級 [媒體估算]
Weights & Biases	ML 實驗追蹤平台	訓練過程硬體指標 + 模型指標一體化採集	私有公司，據報道獲多輪融資 [媒體估算]
Arista Networks	網路裝置供應商	資料中心交換器支援 INT/帶內遙測，AI 叢集網路方案	NYSE: ANET
Elastic	搜尋與可觀測性平台	Elastic Observability 覆蓋指標/日誌/追蹤	NYSE: ESTC
ServiceNow	IT 運維管理平台	事件管理、告警聚合，收購了 Loom Systems 等 AIOps 資產	NYSE: NOW
BigPanda	AIOps 平台	基於遙測資料的事件關聯與根因分析	私有公司

注意： 以上公司資訊基於公開報道，具體融資額/估值隨時間變化，以最新公開揭露為準。

投資邏輯

核心觀點

“賣鏟子的賣鏟子”——遙測是 AI 基礎設施的基礎設施。 GPU 算力越擴張，對遙測的需求越剛性。類比淘金熱中賣鏟子的賺錢，賣鏟子的維護工具也賺錢。
資料引力效應。 遙測資料天然具有高頻率、高基數、時序特徵，這類資料一旦沉澱到某個平台，遷移成本很高，形成客戶粘性。Datadog 的高 NDR（Net Dollar Retention）部分源於此。
GPU 廠商的平台化延伸。 NVIDIA 通過 DCGM 將遙測能力嵌入其生態，這是一種”鎖客”策略——遙測資料格式和介面與 NVIDIA 硬體深度繫結，增加使用者遷移成本。
AI 特化監控的空白與機會。 通用可觀測性工具在模型層（語義漂移、輸出質量）的覆蓋仍然不足，為 AI-native 監控創業公司提供了視窗期。但這類公司的獨立生存能力取決於其能否在通用平台（Datadog 等）的功能追趕上之前建立足夠的壁壘。
風險點： GPU 廠商可能將遙測功能免費整合到管理平台中，壓縮第三方空間；開源 Prometheus + DCGM 方案已能滿足大量基礎需求。

常見誤讀糾偏

誤讀 1：“遙測 = 監控（Monitoring）”

糾偏： 遙測是監控的資料採集與傳輸層，監控是包含遙測資料消費（視覺化、告警、分析）的更上層概念。一個類比：遙測是體溫計的測量功能，監控是你看到體溫數字後決定是否吃藥。業界常將兩者混用，但在架構討論中區分清楚很重要——你可以有很好的遙測基礎設施但沒有好的告警規則（資料豐富但洞察貧乏），也可以有精巧的告警邏輯但資料採集不全（策略好但資料差）。

誤讀 2：“nvidia-smi 看一眼就夠了”

糾偏： nvidia-smi 是單機診斷工具，輸出的資訊有限且以人類可讀文本格式呈現，不適合大規模自動化。生產環境中需要：

DCGM Exporter 將指標以 Prometheus 格式暴露，才能接入時序資料庫和視覺化平台。
結構化、機器可消費的格式（而非文本解析）。
長週期儲存與歷史分析能力（nvidia-smi 僅顯示當前瞬時值）。
關聯分析能力（GPU 指標需與網路、儲存、作業排程資料聯動分析）。

誤讀 3：“GPU 遙測資料量很小，不值得專門最佳化”

糾偏： 單卡維度看似不大，但在萬卡叢集 × 數百指標 × 高頻採集的乘數效應下，遙測資料的儲存和查詢成為顯著的技術挑戰。時序資料庫的選型、資料分層策略、降取樣策略都需要工程投入。一些大型 AI 訓練團隊報告稱，其遙測系統的儲存和運維本身就需要專門的工程資源 [行業經驗分享]。

誤讀 4：“遙測對效能影響可以忽略”

糾偏： 在大多數常規採集頻率下，遙測開銷確實很小。但以下場景需要警惕：

高頻 GPU 效能計數器採集（如每毫秒級別）可能導致可測量的 overhead。
全量網路流量映象消耗交換器埠和頻寬。
模型層日誌（如記錄每個請求的完整輸入/輸出）對 I/O 和儲存壓力顯著。因此需要在採集粒度和系統開銷之間做工程折衷。

學習路徑

入門（1-2 天）

在單機 GPU 環境中執行 nvidia-smi -l 1，觀察輸出中的溫度、功耗、利用率、ECC 計數器。
安裝 Prometheus + Grafana，配置 DCGM Exporter，在 Grafana 中建立 GPU 監控儀表盤。
閱讀 NVIDIA DCGM 官方文件的概述部分。

進階（1-2 周）

學習 OpenTelemetry 規範（指標/日誌/追蹤三大訊號型別），理解其在 AI 系統中的適用性。
實踐：在 Kubernetes 叢集上部署 GPU 節點 + DCGM Exporter + Prometheus + Grafana 的完整監控棧。
閱讀論文或技術部落格：大規模分散式訓練中的故障管理（如微軟的 “Failure Tolerance for Petascale Systems” 系列、Google 的 TPU 叢集運維實踐）。
瞭解 NCCL 集合通訊的 profiling 工具。

專家級（持續跟進）

研究 INT/iOAM 帶內網路遙測規範及交換晶片實現。
關注 NVIDIA 每代架構的新增遙測能力（新計數器、新介面）。
建置端到端的 AI 系統可觀測性方案，覆蓋從硬體到模型質量的全棧。
探索 AIOps 在遙測資料上的應用：異常檢測、根因分析、預測性維護。

一句話總結

遙測是 AI 基礎設施的”神經系統”——在萬卡叢集時代，沒有高質量、全鏈路、結構化的遙測資料，訓練效率最佳化、故障快速定位和推論服務保障都無從談起；它是連線物理硬體與上層智慧運維的關鍵資料管線。

延伸閱讀與來源

NVIDIA DCGM 官方文件 — GPU 遙測的事實標準參考 [廠商文件]
OpenTelemetry 規範 — 統一的可觀測性資料採集架構 [開源規範]
Prometheus + DCGM Exporter GitHub 倉庫 — 最廣泛的 GPU 遙測開源實現 [開源專案]
“Reliability challenges in large-scale GPU clusters”（相關技術分享） — 大規模 GPU 叢集運維實踐 [行業技術分享]
IETF iOAM 工作組文件 — 帶內網路遙測標準化進展 [標準組織]
ONF INT 規範 — 帶內遙測參考架構 [標準組織]
“TPU v4: An Optically Reconfigurable Supercomputer…” (Google, 2023) — 其中提及了大規模叢集的故障率與管理挑戰 [學術論文]
Datadog State of Observability 報告 — 可觀測性行業趨勢 [行業報告]
各廠商 GTC/re:Invent/KubeCon 演講 — 最新的工程實踐分享 [會議演講]

本文基於公開資料和行業共識撰寫。涉及具體效能資料的引用已在文中標註來源口徑；未標註具體數字的部分為定性描述或行業估算，讀者應以各廠商最新官方文件和財報為準。