2026 年 8 月 17 日，SIGCOMM 2026 在丹佛开会的第一天，第三届 Networks for AI Computing workshop（NAIC '26）上出现了一篇只有 6 页的论文。作者名单几乎全是 Meta 的生产工程师与网络研究员：Prankur Gupta、Miao Xu、Maxim Samoylov、Prashanth Kannan、Rajiv Krishnamurthy，加上 CMU 的 Theophilus A. Benson。论文标题平实，《RDMATracer: A scalable eBPF-based framework for tracing RDMA syscalls》，讲的是一个已经在线上连续运行多年的 eBPF 工具。
它要回答的问题一点也不平实：当十万卡规模的 AI 训练集群任务崩溃时，为什么有一类故障在所有现成的监控系统里都看不到？
先看论文给出的数字。在 Meta 的生产环境里，5–20% 的 AI 任务失败源自 NIC 驱动层的内核 bug；在 2025 年 10 月到 2026 年 2 月的研究窗口内，syscall 相关失败占总失败的 4–15%。这类失败在 12 个月窗口里有 96% 不伴随任何应用层或网络层信号——没有异步事件、没有端口闪断、没有传输超时，关联的 GPU 小时浪费同样有 96% 无伴随信号。它们沉默地发生，沉默地浪费 GPU 小时：仅 syscall 一类，12 个月归因浪费 7,065 个 GPU 小时，而且占比曲线在观察窗口内持续上升，同期其他失败类别都在趋平。
更麻烦的是，即使失败被应用层捕获，也会被分错类。Meta 内部的 NCCL 日志分类器 ALPS 把约 25% 携带 syscall 失败证据的尝试（按浪费 GPU 小时加权）误标为「网络事件」。工单被路由到错误的 on-call 团队，框架、RDMA 栈、硬件三个团队十几个工程师卷入一场数周的诊断。论文引用的 HPCA 2025 大规模 ML 集群可靠性研究观察到同类现象：NCCL 超时经常被归到网络这类邻近原因头上，真正的元凶（比如死锁）反而被跳过。
RDMATracer 做的事情，用一句话概括：在 RDMA 控制路径的内核函数里挂 13 个 eBPF 探针，只在函数返回非零值的时刻写一条记录，用每 5 秒一次的批量快照把失败上下文送进观测数据库，与任务级元数据关联。它的生产开销是每主机 0.0000024% 颗 CPU、12 个月全集群约 41 GB 存储。常规问题的诊断从十多分钟压到秒级（LPC 演讲口径），需要数周多团队 triage 的事故诊断被显著加速（论文口径），部分案例里它的信号甚至提前数周预警了后续的正式故障。
这篇文章拆解这篇论文：问题为什么结构性难解，13 个探针怎么选出来，fexit 为什么赢过 kretprobe，73% 的覆盖率为什么是一个诚实的取舍，它在业界观测版图上的坐标与算法进展，以及它对大规模 AI 集群可观测性这件更大的事意味着什么。
一、kernel bypass 之后，可观测性留在了原地
RDMA 的价值主张很直接：绕过内核网络栈，网卡直接读写内存。要理解它在大规模训练里的位置，可以先看 Meta GPU 主机的网络结构，FOSDEM 演讲里讲得清楚：每台 GPU 主机通常配 8 张 GPU，挂在三类网络上——scale-up 网络负责机内或超节点内 GPU 直连；front-end 网络承载控制面与数据加载；scale-out 后端网络把数千乃至更多 GPU 拉进同一个集合通信域。后端网口与 GPU 配对、带宽极高，常规内核网络栈追不上这个速率，而绕开 CPU 的数据搬运还能同时降低延迟、提高带宽，这就是数据面必须走 RDMA 的原因。Meta 的 RoCE 实践（SIGCOMM 2024 的《RDMA over Ethernet for Distributed AI Training at Meta》）已经把这条路线在生产上走通。
但「绕过内核」经常被误解成「内核不再参与」。论文专门用一节纠正这个印象，这也是全文的逻辑起点。一个训练任务的 RDMA 生命周期分三步：
第一步是 server coordination。各节点通过前端网络交换队列对（QP）编号和全局标识符（GID）。与 TCP 世界「连个 IP 就行」不同，RDMA 建连要求两端事先知道对方的 QP 编号，拓扑信息要靠协调步骤显式交换。
第二步是 server configuration。内核通过 uverbs 接口和厂商驱动编程网卡、创建对象、分配并注册内存，把 QP 在状态机里逐步推进到可用状态，再把这些控制面映射进用户态。
第三步才是数据交换，应用直接经用户态 verbs 接口收发，内核不再过问每笔数据。
论文的关键观察是：绝大多数可靠性问题发生在第二步。连接一旦建立并成功跑通一次数据，通常会稳定到任务结束，除非真的出现硬件或网络故障。FOSDEM 演讲里对此有个经验性的总结：初始化阶段是故障聚集区，而这恰恰是内核深度参与的阶段。有一种故障形态尤其折磨人：主机进入某种持久的错误状态，任务启动即失败，反复重试反复浪费，进入崩溃循环。flagship 模型训练被这类循环拖住时，动员规模和关注度都会迅速升级。
第二步恰恰是观测工具最稀薄的地方。现状是一个三层断链。
入口塌缩成一个 ioctl。 所有 ibverbs 交互都收敛到 uverbs 的单一 ioctl 入口，一次调用在内核里穿过 20–30 个函数，途经设备无关的 verbs 层和厂商专有的驱动层。停在入口处，你只能看到一个模糊的错误码，同一个错误码对应多种完全不同的底层状况。坏消息是只有一个入口，好消息也是同一个入口：只要在正确的深度上布点，全部流量都可见。
错误直达应用层，但已经面目全非。 用户态的 rdma-core（libibverbs 是其核心库，uverbs 是这套接口进入内核的对应入口）做参数校验和传递，没有任何重试逻辑，内核侧任何错误立即上抛。NCCL 的重试逻辑同样有限：大多数底层 RDMA 错误触发通信立即中止、communicator 销毁，应用随即崩溃退出。于是应用日志里留下的是最顶层那句翻译过的报错，比如一句笼统的 NVSHMEM initialization failure，原始的层级信息在传播路径上已经丢失。
工具够不着。 传统诊断靠 ftrace 手工抓函数轨迹，但 ftrace 不暴露函数返回值。工程师只能对比一次成功调用和一次失败调用的轨迹，靠「坏轨迹在哪一步变短」来猜出错位置——这要求两次调用可比，而复现还看运气，故障常常换个节点才现身。更根本的是 ftrace 属于事后工具：任务得停下来，装上 tracer，重新触发故障。论文描述一次典型事故的动员规模：框架、RDMA 栈、硬件三个团队，十名以上工程师卷入；在此期间 GPU 空转，浪费按集群速率累积。
把三层断链合起来，就得到论文 §3 那张失败面画像：一类占总失败 4–15% 的故障，96% 的情况下无任何伴随遥测，被现有分类器以四分之一概率标错类别，唯一可靠的观测位置在内核深处，而常规工具进不去也待不住。这是一个结构性盲区，多加几个 dashboard 解决不了。
二、13 个探针：观测系统的核心是决定不装哪些探针
论文 §4 从失败面的三个特性推出三条设计需求：不可见性要求内核侧捕获；误归因要求在失败点携带跨层上下文；复现代价要求 always-on，故障必须在第一次出现时就被记录，不能等人工介入。
剩下的核心问题是：钩哪里。答案最能体现这篇论文的工程味道。候选集由静态分析生成：对 RDMA 子系统做调用图分析，列出每个 ioctl 入口可达的内核函数，再按规则剪枝。全量追踪不可行：naive 地追踪每个内核函数，在典型内核调用率下开销约 50% 颗 CPU；就算收窄到 drivers/infiniband/ 目录下全部约 2,000 个函数，每主机也要约 5% 颗 CPU。RDMATracer 最终只挂 13 个函数，开销 0.0000024% 颗 CPU。从 2,000 到 13，靠的是四条启发式规则，由静态分析和生产调试经验共同导出：
排除只读操作。 查询和枚举类函数只导出内核状态、不修改状态，极少直接导致任务失败。其中一类还会规律性返回 ENOENT 这类预期内的错误，比如查询一个未启用的功能，追踪它们只会制造噪声。
排除通用内核内部。 锁、分页、RB 树这类同步原语与数据结构操作出了问题，症状会出现在整个系统而不仅限于 RDMA，它们不提供 RDMA 特异的诊断信息。
排除清理和引用计数路径。 这是最有意思的一条。清理路径上的失败通常表现为 kernel panic，调用根本没有正常返回，return-value 追踪在原理上就捕不到。panic 有独立的诊断通道处理，硬要覆盖它们只会白付开销。
聚焦关键对象的创建与更新。 队列对（QP）、内存区域（MR）、保护域（PD）、完成队列（CQ）是 RDMA 的四个核心对象，再加上发起硬件通信的路径。同时要求 verbs 层和厂商驱动层双层布点，让每次调用从入口到驱动分发全程可见。
四条规则应用到单一调用图上，ib_modify_qp 从约 40 个可追踪函数缩到 7 个（论文口径）。LPC 演讲展示过这条路径的符号清单：modify_qp、rdma_lookup_get_uobject、_ib_modify_qp、ib_resolve_eth_dmac.isra.0、rdma_lag_get_ah_roce_slave、rdma_get_gid_attr、alloc_and_bind、rdma_counter_bind_qp_auto。按符号名计 8 项，其中 ib_resolve_eth_dmac.isra.0 的后缀是编译器优化派生的标记，源码函数层面与论文的 7 个口径对应。清单里的函数一眼可见都在做状态转换或资源绑定，没有一个是纯粹的查询或清理。13 个探针的最终构成是：5 个设备无关的上游 verbs 处理器（如 ib_uverbs_modify_qp），6 个 Mellanox 驱动及核心助手（如 mlx5_ib_create_qp），2 个 OFED 衍生的 peer-memory 助手。
这个构成里藏着一段值得展开的工程判断：探针怎么跨厂商存活。5 个上游 verbs 钩子位于内核的 verbs 核心层，天然设备无关；厂商驱动侧实现的是同一套 ib_device_ops 内核接口，verbs 回调在每个厂商命名空间里都有等价物，Broadcom 的 bnxt_re_ 前缀、Intel 的 irdma_ 前缀，启发式的命名空间门能自动恢复这些等价物。真正不可移植的只有 2 个 OFED 衍生的 peer-memory 钩子，在 vanilla 上游内核上需要按路径替换。换句话说，13 个探针里 11 个具备跨厂商的结构性可移植性，这份性质由选择标准本身保证。
三、机制三件套：fexit、失败才发射、双平面
选好钩子之后，论文对 eBPF 机制的选择同样值得逐条看。
为什么选 eBPF，放弃 ftrace 与 perf。 论文的论证落在成本结构上：ftrace 和 perf 缺少内核内的过滤与聚合，每个事件都要搬运到用户态，成本按调用率线性放大，而 RDMA 热路径的调用率比失败率高 3 到 4 个数量级。eBPF 把判断放进内核态：BTF（BPF Type Format）提供类型化的参数访问，maps 承载内核内状态，verifier 保证探针与同主机的其他 BPF 程序互不干扰。论文对「安全」给出了脚注级别的严格定义：独立程序之间不因共享系统资源而产生意外干扰。这个定义看似学究气，实际关系到探针能不能铺到数万台主机而不出事故，毕竟同一台主机上还跑着网络栈等其他 BPF 程序。
为什么选 fentry/fexit，放弃 kretprobe。 两者都能取函数入参和返回值，差异在挂钩机制：kprobe 家族靠运行时打断点，每次命中走陷入处理；fentry/fexit 基于 BTF 与内核版本校验，经 trampoline 直连函数边界。差多少？论文给了两组实测：in-tree kernelbench 的 rename() 微基准上，fexit 达到 3.2M ops/s，kretprobe 为 2.5M ops/s，吞吐差约 28%；在真实 RDMA 钩子上执行 nccl-tests，ib_uverbs_modify_qp 与 rdma_fill_sgid_attr 两个探针的每次 BPF 运行时间，kretprobe 是 78–81 纳秒，fexit 是 46–69 纳秒，低 11–43%。对单个探针这是几十纳秒的差距，乘以每秒数万次的调用率、再乘以数万台主机，就是 always-on 可行与不可行的分界。论文的测试层部署（20 台后端主机，跑 AI 训练负载与 nccl-tests）给出了同场对比：RDMATracer 探针的单次调用成本 P50 56 纳秒、P99 79 纳秒，比同一主机上其他追踪类 BPF 程序低 18 倍（P50）到 46 倍（P99）；LPC 演讲的自评是它「大概是全集群最轻的 BPF 程序」。
失败才发射。 探针逻辑一句话讲完：返回值非零才写记录，成功路径一个字节都不产生。RDMA 控制面的失败事件率本身就低，论文测得平均每主机每秒约 3 次，数据量天然受控。这也是整个设计里最体现「观测哲学」的一条：always-on 的前提是让常态零成本，否则任何常驻观测都会在生产评审里活不下来。
数据通路是双平面的。一块 ring buffer 承载每条失败记录的完整上下文（LPC 演讲披露容量约 256 KB、约 8K 条），一块 per-CPU 计数器 map 维护三类计数：每个 syscall 被调用的次数、失败的次数、失败返回的 errno 分布。三类计数导出到时序数据库后承担告警与统计，成为比逐条记录更轻的常态信号。双平面的意义在爆发场景：fleet 级事故时事件洪峰会冲爆 ring buffer，计数器不丢，聚合计数始终精确，事后再从快照中还原细节。
控制面同样在做减法。用户态采集线程每 5 秒轮询一次 ring buffer，把这一批记录打包成 per-host 快照，作为单条样本写进观测数据库（Meta 的 Scuba 体系），再与任务级元数据关联。生产上平均每个快照约 200 条记录，fleet 事故峰值数千条。内核只做逐事件的 ring buffer 写，传输与存储成本随快照数扩展，与事件数脱钩；5 秒的间隔同时约束了下游写入率和从检测到导出的延迟上限。这是典型的摊销设计。上线前的部署验证也做得到位：LPC 演讲的回归数据显示，功能开启前后主机 CPU 利用率无可见变化，工作负载 QPS 不受影响，这才有了铺满 fleet 的资格。
四、73% 覆盖率：一个把取舍摆在明面上的验证
任何「精选 13 个」的方案都绕不开一个问题：剩下的呢？论文用一组回验回答，这是全文我最欣赏的部分。
Meta 内部有一个独立的应用层分类器 ALPS，基于 NCCL 日志的正则解析构建，与 RDMATracer 无共享代码、无共享设计，是一个天然的交叉验证源。对 12 个月窗口回验的结果：ALPS 标记的 syscall 失败中，约 73% 落在 RDMATracer 所钩系统调用的内核对应面上；其余约 27% 是启发式有意排除的部分，清理路径约 21%（由 ibv_dealloc_pd 主导），只读路径约 3%（由 ibv_query_gid 主导），各分项均为论文近似口径。
论文没有停在这里，而是接着论证那 21% 为什么比看起来无害。其一，ALPS 会把一次尝试浪费的全部 GPU 小时记到任何拆除期出现的 syscall 错误头上，所以清理路径的错误与浪费只是相关关系，够不上因果，数字本身高估了这类失败的影响。其二，清理失败的真实出口是 kernel panic，走独立诊断流，return-value 追踪本来就无能为力。按 GPU 小时重新归因（论文 Table 2）：12 个月 syscall 归因浪费总计 7,065 GPU 小时，13 个探针覆盖约 5,227（73%），有意排除约 1,959（约 27%）。总行与分项之和 7,186 存在约 120 GPU 小时的出入，百分比与分项口径一致，本文按论文原表引用。
这套验证的可贵之处在于它把「没覆盖什么」变成了设计陈述的一部分，取舍被明确写进了论文。73% 这个数字无需辩解，它是「清理类失败另有出口、只读类失败几乎无害」两条领域判断的直接后果。观测系统的覆盖边界，本质上是维护者对故障分类的理解边界。
部署侧的数字补完了故事：连续生产多年，近期多月窗口捕获超过 10 亿条 syscall 失败记录，覆盖数万台后端主机；整个 12 个月窗口全集群存储成本约 41 GB。效果层面论文的表述克制但有分量：诊断在「过去需要数周多团队 triage」的事故上被显著加速，部分案例里 RDMATracer 的信号提前数周预警了后续的正式故障，早期信号本身成了故障预测的数据源。
五、两个案例：层级证据如何定位根因
论文的两个生产案例把方法论讲透了：错误在哪一层出现、在哪一层消失，本身就是定位信息。
案例一（论文 §5.1）是配置类问题的典型。一次面向 GB200 系统（Linux 内核 6.16）的 NVIDIA 软件包 rollout 中，NVSHMEM 启用 dmabuf 支持所需的编译标志被漏掉，推理负载随即进入崩溃循环。应用层只看得到一句笼统的 NVSHMEM 初始化失败，没有任何指向。RDMATracer 的系统调用轨迹显示：NVSHMEM 的设备发现路径回退到了私有的 nv_peer_mem 机制，没有走预期的 dmabuf 路径，而 nv_peer_mem 在这批硬件上不支持 NVSHMEM 需要的 IBGDA 能力。内核侧的这一处分歧，把根因钉在那个缺失的编译标志上。这是一类应用层信号原理上无法分辨的失败：错误存在，方向不存在。
案例二（论文 §5.2）是 fleet 级事故。单日之内，数千台后端主机上的内存注册路径 ibv_reg_mr 高频返回 EFAULT（Bad address）。NCCL 只把最顶层那句 ibv_reg_mr 失败报给应用。RDMATracer 在注册级联的全部四层，ib_uverbs_reg_mr、mlx5_ib_reg_user_mr、__ib_umem_get、ib_peer_umem_get，捕获到同一个 EFAULT，每一层约 1,900 万次。四层同错说明错误发生在比 Mellanox 驱动更深的公共路径上，层级证据把根因定位到 GPU peer-memory 子系统，与一句含糊的「NIC 驱动故障」完成了决定性的区分。
同一团队在 LPC 2025 与 FOSDEM 2026 的演讲里还补了论文未收的两个案例，以下细节以演讲幻灯片为准。一起是新部署厂商 NIC 驱动后，NCCL 报 ibv_reg_dmabuf_mr 返回 EPERM（Operation not permitted），RDMATracer 导出的 syscall 链与返回值错位把问题定位为一个溢出缺陷；另一起是整个项目的起源案例，ibv_reg_mr 返回 ENOMEM，表象完全像内存压力，实际是厂商闭源代码里 64 位到 32 位整型转换的缺陷，而后来一次同样症状的事故根因又完全不同，出在 GPU 驱动与大页配置的交互上。同一句报错、不同根因，恰好标出了没有内核侧证据时应用层日志的信息量上限。
演讲还披露了一个论文篇幅所限没有展开的机制：周期性审计用「好轨迹」做基线。系统定时捕获返回成功且 50 毫秒内完成的调用轨迹存档，故障出现时对比好坏轨迹，找分叉点。挑战在于「预期的错误」：有些失败是正常的，比如查询未启用功能返回的 ENOENT，基线得学会不把它们当异常。这套基线目前还没能自动化，内核演进之后探针集的扩展仍靠人工审计，论文与演讲都把它列为明确的后续方向。
六、业界坐标：观测栈的四层图谱与两条收敛线
RDMATracer 不是孤例。业界观测版图上，它有一个明确的坐标：一个正在成形的四层栈，和两条清晰的技术收敛线。
框架层：黑匣子范式确立。 PyTorch 的 Flight Recorder 是这一层的代表。它在 c10d 通信层内建每个 rank 一个 CPU 侧环形缓冲，跨进程组共享，记录每次集合通信与点对点操作的起止时间、CPU 入队时间、进程组、源与目标 rank、张量尺寸和调用栈；NCCL watchdog 超时触发自动落盘。采集能力自 PyTorch 2.4 起可用，Llama 3 的训练报告用过它；TorchTitan 论文（arXiv:2410.06511）把它列为生产级预训练的标配，专门对付集合通信挂起：流水线并行的调度缺陷、某个 rank 没有进入集合通信这类问题，靠跨 rank 对齐记录就能定位。配套的 fr_trace 分析工具按序号对齐所有 rank 的记录、按进程组聚合、枚举不匹配项（缺失 rank、状态分歧、调用栈分叉），再把不匹配映射到根因类别：CPU 侧卡顿、变慢或跨 rank 分歧，GPU 计算核挂起，集合通信参数配错，网络或硬件故障。2026 年 3 月 PyTorch 官方博客给出了完整方法论；同年 6 月的 @Scale 演讲上，团队展示了把 LLM agent 接在 Flight Recorder 之上，把「跨 rank 遥测分析」自动化，从不匹配到代码级根因的桥接正在被模型接管。
与 RDMATracer 对照能看出一条正交关系。同一场 NCCL 崩溃，Flight Recorder 回答「哪个 rank 在哪次集合通信上掉队」，RDMATracer 回答「内核里哪一层的系统调用失败」。一个对齐 rank 维度，一个对齐调用深度；两条证据线合在一起，才够拼出完整的故障现场。
内核层：eBPF 生态的通用与专精。 内核侧的同题工具是 retsnoop，作者 Andrii Nakryiko 是 Meta 杰出工程师、eBPF 指导委员会成员。它的设计初衷与 RDMATracer 一致：复杂 syscall 深处返回 -EINVAL 这类通用错误，难以猜出来源；默认只捕获以错误码或 NULL 收尾的调用栈，并尽力取最深栈帧，Kernel Recipes 2024 专门讲过。retsnoop 证明这个问题形态有通用解；RDMATracer 证明通用解在数万台主机的生产 fleet 上要让位于领域专精：13 个精选探针、失败才发射、双平面导出，每一件都是 RDMA 领域知识换来的成本削减。两者的作者群同在 Meta，是同一问题的两条路线，也侧面说明为什么这篇论文出自这里。
更广的 eBPF 观测生态在横向铺开：Tetragon 与 Pixie 面向 Kubernetes 的安全观测与通用追踪（论文相关工作一节已给过定位）；持续剖析线上，Parca 与 Grafana Pyroscope 用 eBPF 对主机全部进程采样，零应用改动，常态开销压在约 1% 的量级；OpenTelemetry 正把 eBPF profiler 纳入标准管道，剖析数据可以经 OTLP 协议直接送入 Pyroscope，剖析标准化在 CNCF 有专门工作组推进。通用生态覆盖任何进程、任何容器、任何集群，但没有一个通用方案替你建模某个子系统的故障语义。RDMATracer 的四条启发式在通用平台上没有对应物，这正是专精层的生存空间。
网络与硬件层：厂商把观测做成了商品。 NVIDIA 在 GTC 2025 起交付的 Mission Control 是代表：AI 工厂的集成软件栈，其中遥测与观测组件的采集并行铺到数千张 GPU、Spectrum-X 以太网与 Quantum InfiniBand 交换机、NVLink 交换机，底层由 UFM 与 NMX 驱动，官方口径是 always-on resilience，外加一个自主恢复引擎。Dynatrace 这类观测厂商把全栈监控写进 NVIDIA AI Factory 的交付方案，从 GPU 到 Kubernetes 再到推理服务一层不落，观测本身成了 AI 工厂的售卖项。网络侧的遥测（RoCE 拥塞信号、交换机计数）我们在 MetaRoCE 深度拆解 里展开过，此处不赘述。厂商栈的视野止于自家硬件边界，跨层的失败（内核驱动与 GPU 对等内存的交互）仍需要 RDMATracer 这类系统级探针。
算法层：从正则到执行重现再到 agent。 诊断算法的四代脉络清晰。第一代是规则与正则：本文 §四 拆过的 ALPS 用精选正则给 NCCL 日志分桶，快且可解释，代价是约 25% 的误标。第二代是结构化对齐与枚举：fr_trace 按序号跨 rank 对齐，不匹配即线索；RDMATracer 的层级证据（错误在哪层出现、在哪层消失）是同一思想在调用深度维度的应用。第三代是执行重现与因果推断：Anduril（SOSP 2024）用静态因果分析加反馈驱动的搜索在故障空间里定位根因并注入复现，对五个大规模分布式系统的 22 个真实故障全部复现；ExChain（NSDI 2024）做异常依赖分析，DejaVu（FSE 2022）对复发故障做可执行定位，诊断从看数据走向重放因果。第四代是 agent 化：LLM agent 接进 Flight Recorder 管道，把跨 rank 分析自动化，就是前面提到的 2026 年动向。这条线的前提是采集端先交出结构化证据：没有环形缓冲里的序列号和失败记录里的返回值，任何算法都只能面对非结构化日志打转。观测栈的下半场竞争在证据格式。
四层栈合成一句话：框架层有了黑匣子，内核层有了 eBPF，网络与硬件层有了商品化遥测，算法层正从规则走向 agent。两条收敛线也清晰可见：采集端走向 always-on、零常态开销、结构化；诊断端走向对齐、重现、自动化。RDMATracer 恰好落在两条线的交点上，用 0.0000024% 颗 CPU 的代价把内核驱动层接进了这条管道。
七、更大的图：AI 集群可观测性的地板在哪里
把 RDMATracer 放回行业语境，它的意义超出一个 Meta 内部工具。
可观测性的地板被推到了内核驱动层。 过去两年，AI 集群的可观测性建设集中在两端：应用与框架侧有 PyTorch flight recorder、NCCL 调试日志这类结构化记录；网络侧有交换机遥测与端口级计数；硬件侧有 DCGM 这类 GPU 监控。论文 Intro 的判断很准确：现有诊断工具要么面向高层框架、要么面向底层硬件遥测，内核里驱动执行路径恰好是中间的空白带。RDMATracer 证明这条空白带可以用两位数个探针、约 0.0000024% 颗 CPU 的占用补上。对任何一家万卡以上规模的集群运营方，这是一个可以直接复用的配方：精选探针、失败才发射、批量导出、好轨迹基线。除 2 个 OFED 衍生钩子在 vanilla 内核需按路径替换外，其余件件都在 Linux 发行版自带的 eBPF 能力之内。
「observability-first」是比工具本身更值得记住的词。 论文摘要自述的贡献不只是一个 tracer，而是一条 observability-first 的管道，用额外的用户态上下文富化内核记录。翻译成操作语言：先保证故障现场的内核证据 always-on 地留下来，再谈怎么把它和任务、模型、团队工作流关联。这与「事后装 tracker 重新复现」的旧范式是方向性的区别。6 页篇幅里没有展开的部分，富化管道的细节、Scuba 之上的分析层，反而说明了重点所在：证据采集是地基，地基决定上层一切分析的响应速度。
通用 eBPF 观测与子系统专精的分野会长期存在。 论文相关工作一节把 Tetragon、Pixie 这类通用方案的位置标得很清楚：Tetragon 的 TracingPolicy 能在 kprobe/tracepoint/uprobe 上做内核内过滤，包括按返回值匹配，但它面向 Kubernetes 的安全观测与运行时执行，不为任何内核子系统做深度建模。RDMATracer 的价值恰恰在不可通用的那部分：四条启发式是 RDMA 领域知识，QP/MR/PD/CQ 的对象模型、清理路径与 panic 的关系、verbs 与厂商驱动的分层，73% 的覆盖验证和跨厂商命名空间门都建立在这套知识上。这个判断可以推广：每一个性能关键、故障语义复杂的内核子系统，存储栈、GPU 驱动、未来可能还有 CXL，都值得一条专精的观测路径，而通用平台的角色是把这类探针安全地编排起来。
盲区清单仍然很长。 论文自己划出的边界值得敬重。RDMATracer 只覆盖控制路径，数据面的失败有自己的盲区：QP 转入 error 态的通告可能只到达用户态，内核里无迹可寻，FOSDEM 演讲提到这类问题需要转向 uprobes，而用户态插桩面对大量函数内联还要另闯一关。13 个探针面对内核版本演进需要持续维护，好轨迹基线与探针集扩展的自动化都还是未竟事项。还有一个数据层面的注意：论文的失败分类建立在 Meta 自家生产集群、5 个月窗口、正则分桶的遥测之上，数字的量级可信，但边界，比如那个 4–15% 区间的宽度，在不同集群形态与软件栈版本下会移动。把 Meta 的数字直接搬到自己的集群上做预算，需要谨慎。
总结与判断
这篇 6 页的 workshop 论文没有提出新算法，也没有新的系统范式。它做的事情是把一类被整个工具生态错过的故障，RDMA syscall 失败，从不可见变成 always-on 可见，并用可核查的数字（73% 回验覆盖、0.0000024% CPU、10 亿条生产记录）把代价与收益一起摆在桌面上。配套的 LPC 与 FOSDEM 演讲补齐了论文之外的工程细节，三个信源互相咬合，这本身就是工业系统论文一种健康的发表形态。
三个判断。
第一，内核驱动层会成为 AI 集群可观测性的下一个竞争点。 应用层和网络层的观测已趋同质化，故障归因的瓶颈正在向中间层转移。RDMATracer 的 96% 无伴随信号与 25% 误归因说明，谁先补上这一层，谁就能砍掉一类从起点就路由错误的动员。HPCA 2025 的集群可靠性研究从故障统计侧给出了同样的征兆，两条证据线正在合流。
第二，「精选探针 + 失败才发射」会成为内核观测的默认形态。 在 fleet 规模下，全量追踪输给结构化裁剪是成本上的必然。RDMATracer 用 2,000 到 13 的缩减证明，领域知识才是观测系统的护城河。这个模式不依赖 Meta 的基础设施规模，中小集群的 SRE 团队可以直接落地。
第三，跨厂商驱动观测需要一个上游标准。 现在 13 个探针里 11 个可移植，靠的是 verbs 核心层与 ib_device_ops 接口的分层统一性，但 2 个 OFED 衍生钩子的路径替换提醒我们，观测能力仍部分绑定在发行版内核之外的世界里。RDMA 核心社区若能把 verbs 层的观测点标准化为稳定的 tracepoint，这类系统的维护成本会再降一个台阶：论文与演讲都把内核演进下的探针维护列为明确的后续方向，指向一致。
后继值得盯住三件事。Min Si 等人的《Collective Communication for 100k+ GPUs》（arXiv:2510.20171）落地后，十万卡级别集合通信的故障语义会不会反过来驱动观测需求升级；eBPF 社区在 uprobes 与内联函数追踪上的进展，能否把 RDMA 数据面盲区也纳入 always-on；以及 NAIC 这个 workshop 本身，网络研究的顶会体系正在把 AI 基础设施的可运维性当成一等公民议题，这类生产系统论文的持续出现，比任何基准测试都更能说明 AI 集群的工程重心已经转移到可靠性上。
本文事实均出自 RDMATracer 论文（NAIC '26，DOI 10.1145/3789240.3828742）及作者团队的 LPC 2025、FOSDEM 2026 演讲材料；§六 业界坐标一节另据公开信源（PyTorch 官方博客、@Scale 2026 演讲材料、NVIDIA 开发者博客、SOSP/NSDI/FSE 论文等）。数字口径在正文逐一标注；数据整理截至 2026-09-08。