遥测（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、自研平台）

采集模式分类：

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 为例，硬件遥测依赖以下机制：

1. 板载管理控制器（BMC/Baseboard Management Controller）： 独立于主 GPU die 的低功耗微控制器，持续采集温度、电压、风扇转速等模拟/数字信号，即使 GPU 主体掉电也可工作。

2. GPU 内部 PMU（Performance Monitoring Unit）：

   • 提供数百个硬件性能计数器（Performance Counters），覆盖 SM 活动周期、显存事务、Tensor Core 利用率、NVLink 流量等。
   • 通过 NVPMI（NVIDIA Performance Monitoring Interface） 或 perf 子系统暴露给用户态工具。
   • 计数器通常有位宽限制（如 32/48 bit），溢出时需软件层处理翻转。

3. 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 实现。

技术演进史

技术路线对比

上下游

上游（遥测依赖什么）

下游（遥测数据喂给谁）

关键指标

供需与市场数据

需求侧驱动力

1. AI 训练集群规模持续膨胀： 从千卡到万卡再到十万卡（如报道中 xAI Memphis 集群、Meta 训练集群规模），遥测复杂度与数据量非线性增长。
2. GPU 资产高价值化： 单块高端 GPU 价格在数万美元量级 [供应链估算]，任何故障导致的计算浪费成本高昂。
3. 多租户云 GPU 服务： 精确的运行态数据是计费和 SLA 保障的基础。
4. 推理服务规模化： 从实验室部署到大规模线上服务，需要生产级的可观测性。

供给侧格局

• 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 基础设施监控是其中增速最快的细分之一。

代表公司与资本映射

注意： 以上公司信息基于公开报道，具体融资额/估值随时间变化，以最新公开披露为准。

投资逻辑

核心观点

1. “卖铲子的卖铲子”——遥测是 AI 基础设施的基础设施。 GPU 算力越扩张，对遥测的需求越刚性。类比淘金热中卖铲子的赚钱，卖铲子的维护工具也赚钱。

2. 数据引力效应。 遥测数据天然具有高频率、高基数、时序特征，这类数据一旦沉淀到某个平台，迁移成本很高，形成客户粘性。Datadog 的高 NDR（Net Dollar Retention）部分源于此。

3. GPU 厂商的平台化延伸。 NVIDIA 通过 DCGM 将遥测能力嵌入其生态，这是一种”锁客”策略——遥测数据格式和接口与 NVIDIA 硬件深度绑定，增加用户迁移成本。

4. AI 特化监控的空白与机会。 通用可观测性工具在模型层（语义漂移、输出质量）的覆盖仍然不足，为 AI-native 监控创业公司提供了窗口期。但这类公司的独立生存能力取决于其能否在通用平台（Datadog 等）的功能追赶上之前建立足够的壁垒。

5. 风险点： 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 天）

1. 在单机 GPU 环境中运行 nvidia-smi -l 1，观察输出中的温度、功耗、利用率、ECC 计数器。
2. 安装 Prometheus + Grafana，配置 DCGM Exporter，在 Grafana 中建立 GPU 监控仪表盘。
3. 阅读 NVIDIA DCGM 官方文档的概述部分。

进阶（1-2 周）

1. 学习 OpenTelemetry 规范（指标/日志/追踪三大信号类型），理解其在 AI 系统中的适用性。
2. 实践：在 Kubernetes 集群上部署 GPU 节点 + DCGM Exporter + Prometheus + Grafana 的完整监控栈。
3. 阅读论文或技术博客：大规模分布式训练中的故障管理（如微软的 “Failure Tolerance for Petascale Systems” 系列、Google 的 TPU 集群运维实践）。
4. 了解 NCCL 集合通信的 profiling 工具。

专家级（持续跟进）

1. 研究 INT/iOAM 带内网络遥测规范及交换芯片实现。
2. 关注 NVIDIA 每代架构的新增遥测能力（新计数器、新接口）。
3. 构建端到端的 AI 系统可观测性方案，覆盖从硬件到模型质量的全栈。
4. 探索 AIOps 在遥测数据上的应用：异常检测、根因分析、预测性维护。

推荐资源

• NVIDIA DCGM 官方文档：https://docs.nvidia.com/datacenter/dcgm/
• OpenTelemetry 官方文档：https://opentelemetry.io/docs/
• Prometheus 官方文档：https://prometheus.io/docs/
• Grafana Labs 博客中关于 GPU 监控的实践文章
• 各大厂商 GTC/re:Invent/KubeCon 演讲中关于 AI 集群运维的 Session

一句话总结

遥测是 AI 基础设施的”神经系统”——在万卡集群时代，没有高质量、全链路、结构化的遥测数据，训练效率优化、故障快速定位和推理服务保障都无从谈起；它是连接物理硬件与上层智能运维的关键数据管线。

延伸阅读与来源

1. NVIDIA DCGM 官方文档 — GPU 遥测的事实标准参考 [厂商文档]
2. OpenTelemetry 规范 — 统一的可观测性数据采集框架 [开源规范]
3. Prometheus + DCGM Exporter GitHub 仓库 — 最广泛的 GPU 遥测开源实现 [开源项目]
4. “Reliability challenges in large-scale GPU clusters”（相关技术分享） — 大规模 GPU 集群运维实践 [行业技术分享]
5. IETF iOAM 工作组文档 — 带内网络遥测标准化进展 [标准组织]
6. ONF INT 规范 — 带内遥测参考架构 [标准组织]
7. “TPU v4: An Optically Reconfigurable Supercomputer…” (Google, 2023) — 其中提及了大规模集群的故障率与管理挑战 [学术论文]
8. Datadog State of Observability 报告 — 可观测性行业趋势 [行业报告]
9. 各厂商 GTC/re:Invent/KubeCon 演讲 — 最新的工程实践分享 [会议演讲]

本文基于公开资料和行业共识撰写。涉及具体性能数据的引用已在文中标注来源口径；未标注具体数字的部分为定性描述或行业估算，读者应以各厂商最新官方文档和财报为准。