AI Fabric 可观测性与可靠性：从 CUDA 时间线到 NIC、交换机与光模块

1. 先定义 AI fabric：它不是“网络”的同义词

这里的 AI fabric 是完成一次跨设备数据依赖所经过的整条路径：GPU 上的 CUDA kernel 和 stream、NCCL 或等价通信库、GPU 内存与 DMA 引擎、PCIe/NVLink/NVSwitch、NIC 的 RDMA 队列、交换芯片及其缓冲、光模块与光纤、远端 NIC，最后到达远端 GPU 或内存。它也包含控制面：拓扑发现、路由、QoS、故障域、软件版本和变更流程。

这一定义很重要。若只观察交换机端口利用率，看到的是已经送进网络的字节；若只看 GPU 利用率，看到的是结果而不是等待来源。推理服务对 依赖完成时间敏感：TP 的 collective、MoE 的 all-to-all、P/D 的 KV 传输，都会被最慢参与者决定。平均吞吐很好时，单个局部故障仍能破坏请求 P99。

通信和放置的基础机制见 07 通信拓扑；算子及 CUDA 层依赖见 03 GPU 算子；跨 worker KV 的数据语义见 08 数据中心 KV 与 P/D。本页只处理一个问题：这些机制在真实集群中变慢、丢失或悄悄出错时，怎样识别与处置。

2. 把“网络正常”换成可检验的服务目标

端口未 down、链路平均利用率低，都不是推理可用性的定义。应用 SLO 应从用户体验开始，例如交互请求的 TTFT、稳定生成期的 TBT、流式中断率、工具调用恢复成功率，以及大 prompt 或 MoE 请求的完成率。随后把它们分解为每层可归因的预算。

因此 SLO 需要按请求类别切分。短 decode、小 batch 的 TP collective 更怕几十微秒的抖动；长 prompt 的 P/D 更怕带宽、incast 和排队；MoE 的 all-to-all 还要按 expert 热度分桶。把所有请求混成一个“GPU 集群平均带宽”会把最需要优先保护的路径淹没。

3. 没有共同身份，跨层数据只是四份无关日志

每个可观测对象必须能向上关联。请求有 request_id；一次 decode iteration 有 step_id；communicator 有拓扑与成员版本；collective 有 sequence number、算法、协议、字节数和 rank；RDMA work request 有 QP、队列和 completion；物理路径有 source/destination port、lane 与 optics serial。它们不需要都永久存储，但必须在故障窗口内可 join。

correlation key = request_id / model_replica_epoch / step_id
                   / communicator_epoch / collective_seq / flow_or_QP

拓扑快照 = GPU UUID → NIC PCIe BDF → leaf port → spine port → remote NIC → remote GPU

特别要记录 epoch。一次滚动升级、NCCL communicator 重建、GPU reset 或路由收敛都可能改变成员和路径。若指标只写“rank 3 变慢”，却不知道那一刻 rank 3 对应哪块卡、哪张 NIC 和哪一代 communicator，事后无法区分硬件问题、拓扑变化和软件回退。

4. 从 CUDA/NCCL 时间线开始，而不是从交换机仪表盘开始

用户看到的是 token 慢，GPU timeline 则给出最贴近模型执行路径的证据。针对一个异常请求，应能看到 kernel launch、stream wait、event dependency、collective kernel、pack/unpack、DMA 与下一 kernel 的开始时间。单个 kernel 耗时长未必导致端到端延迟，只有位于关键依赖链上的事件才会直接阻塞请求。

• GPU compute：GEMM/attention 的持续时间、SM occupancy、HBM 吞吐、是否发生频率/功耗降档。
• 通信库：collective 类型、bytes、algorithm、protocol、rank 完成时间分布、每个 rank 的 launch 到 completion。
• 重叠：计算和通信是否原本应 overlap；异常时是通信变慢，还是通信 kernel 抢占 SM 使计算变慢。
• 框架层：continuous batching 的 batch shape、expert token histogram、KV block 数量、P/D 目的地和 admission 决策。

一个典型误判是：NCCL collective 变长，所以归因网络。实际上 collective kernel 可能没被及时 launch，因为前一段 pack kernel、页面迁移、CPU 调度或别的 stream 等待。反过来，GPU 利用率低也不等于 GPU 坏了，它可能正在等待远端 completion。时间线的目的是确认“第一个变慢的事件”，而不是挑选最显眼的曲线。

5. collective 的正确观测单位是最慢 rank，而不是平均链路

all-reduce、all-gather、reduce-scatter 与 all-to-all 都是群体操作。只要一个 rank 在某轮落后，其他 rank 会在同步点等待。监控应保存每个 collective 的 min / median / max rank completion、慢 rank 集合、参与 GPU 的拓扑域、消息大小和算法选择；只保存 communicator 总时间不能说明是全局带宽下降还是一个点状异常。

MoE all-to-all 还要同时记录每个目标 expert 的 token bytes。一个 GPU 接收大量 token 时，局部 grouped GEMM 变慢、发包突发和接收队列堆积可能同时出现。把 per-rank send/receive histogram 和 expert load 放进同一 trace，才能分清问题来自模型侧负载不均衡，还是 fabric 侧路径不均衡。

6. NIC 与 RDMA：把排队、拥塞反馈和重传分开

RDMA 减少 CPU 拷贝，并没有消除协议状态。发送端要有 work queue，接收端要有 buffer 和 completion queue；RoCE 还会受 ECN 标记、CNP、PFC、速率调节及链路重试影响。诊断时至少拆成：应用发起到 NIC doorbell、NIC 排队、线上传输、远端落地、CQ completion。

高优先级指标包括每 QP 或 flow 的 send/receive rate、completion latency、retry/timeout、RNR 或资源不足、ECN mark/CNP、PFC TX/RX、port XOFF 时间、PCIe replay/error、DMA 映射失败。它们要配合基线而非只看绝对阈值：某个 NIC 的 retry 从零升到持续非零，通常比“未达到厂商上限”更有诊断价值。

在 P/D KV 传输里，NIC 还要与接收端 HBM credit 对齐。目标 worker 没有可提交的 KV 页、版本不匹配或 CQ 被堵时，盲目继续发送只会把问题扩大。数据面应由 credit、超时和幂等 abort 控制；控制面记录 transfer 的 PREPARED → COPYING → VERIFIED → COMMITTED 状态，只有 committed 对象才能被 decode 引用。

7. 交换机队列：PFC storm、ECN 与 microburst 的因果链

AI 通信的负载经常是同步 burst：很多 GPU 同时完成 pack，很多 sender 同时向一个 receiver 或同一上行端口发包。平均利用率即使很低，微秒到毫秒级 queue 仍可能到达阈值。RoCE 常用 ECN/CNP 让端点降速；无损优先级也可能用 PFC 暂停上游。这些机制需要端到端联动，否则一个局部拥塞会演化成更大的暂停域。

PFC storm不是“某条线带宽不够”的同义词。它可能源于错误的 priority 映射、队列阈值、lossless class 与后台流量混跑、接收端持续慢、拥塞控制参数不匹配，或路径意外汇聚。监控需要按 priority 和 port 记录 pause duration、pause frame、queue watermark、ECN mark、CNP rate、drop 与无损类以外流量，才能看见暂停传播方向。

8. incast 与 bad path：为什么“有一条慢路径”足以打坏 P99

incast是多个发送者在短窗口内向同一 receiver、同一 leaf egress 或同一 NIC 入向资源聚集；all-to-all、KV 批量迁移和 checkpoint 都能触发。bad path则是逻辑上可达但性能或可靠性明显较差的路径，例如一组 ECMP hash 长期落到劣化链路、某个 spine port FEC 高、某个 optics 的 BER 边缘、某张卡的 PCIe lane 反复 replay，或路由收敛后出现不对称路径。

定位原则是比较同一 workload 的等价路径：同样 message size、同样并发、相同 rank 角色下，对照不同 GPU → NIC → leaf → spine → leaf → NIC → GPU。如果异常固定绑定物理路径，应做 path pinning 或避让来验证；如果随机迁移，重点看 hash、拥塞与多路径分布。不能直接根据“某台机器跑慢”换机，因为计算、NIC、交换和光链路可能共享同一症状。

9. 光模块、线缆与 FEC：物理层会以“偶发尾延迟”出现

物理层故障不总是 link down。光功率边缘、连接器污染、弯折、温度、模块兼容性、lane 不平衡或 FEC 纠错压力，都可能形成间歇性 symbol error、CRC、重传或 link flap。上层看到的是某些 collective 偶尔很慢，甚至只是某个请求偶发失败。

每条链路的资产信息应可回溯到端口：optic serial、固件、速率、lane、线缆长度、两端温度/电压、Rx/Tx optical power、pre-FEC 与 post-FEC error、FEC corrected/uncorrectable、link state 变更和最近维护记录。趋势比单点更可靠：稳定上升的 corrected error 是更早的告警，而等到 uncorrectable 才处理通常已影响业务。

硬件隔离也要避免误伤。可以用低流量 probe 或 canary 复现问题，随后 drain 单端口或单路径；确认故障后，再替换、清洁并重新认证模块和线缆。直接重启整机或整个交换域会暂时掩盖证据，并扩大故障域。

10. Silent data corruption：成功完成不等于结果正确

超时和丢包容易被监控捕获；更危险的是数据被错误写入或读出后仍产生 completion。来源可包括 DMA/IOMMU 映射、固件、内存、链路、NIC/交换硬件、kernel 或量化/转换路径中的缺陷。模型输出轻微漂移时，用户未必立即报错，因此不能仅靠请求成功率。

对通信 buffer 或 KV 不能在每轮都做昂贵全量 checksum，但可以采用分层策略：发布模型权重与固件 hash；对 canary 的固定输入做 deterministic 或容差范围比较；对 KV/object transfer 用版本、长度、页边界与抽样校验；对出错高风险路径增加端到端 checksum；将 ECC、Xid、PCIe AER、FEC uncorrectable 与输出异常关联。发现疑似静默损坏时，应隔离该 device/path、使相关 cache epoch 失效，并重算而非继续复用旧对象。

验证的目标不是证明“模型每次 token 完全相同”。采样、浮点归约顺序与不同 kernel 可让输出有差异。应定义与工作负载匹配的 oracle：确定性 decode 的 token 一致性、logits/embedding 的容差、固定模型小集上的质量阈值，以及 KV 恢复后与从头 prefill 的一致性。

11. 告警设计：先检测用户伤害，再定位根因

告警应分层，并避免直接把每个计数器都 page 给值班人员。第一级是用户 SLO：某个模型/region/tenant 的 TTFT 或 TBT 错误预算燃烧；第二级是请求关键路径：collective straggler gap、KV commit timeout、通信 retry 突增；第三级是资源健康：PFC、ECN、FEC、CRC、GPU Xid、PCIe error。三层一起触发时，定位才具有证据链。

阈值必须按端口速率、流量类别、模型工作负载与时间窗口建立基线。一天一次的大训练 checkpoint 与在线 decode 的十秒 P99 不属于同一种异常。报警规则也要把“变更中”作为维度，否则滚动升级产生的预期短暂停顿会淹没实际故障信号。

12. Canary：用少量真实依赖验证 fabric，而不是只 ping

ICMP、端口 up 和单向带宽测试只能证明基础连通。AI fabric canary 应用真实的 GPU memory、RDMA/NCCL/collective 路径和代表性消息大小，覆盖节点内 scale-up、同 rack scale-out、跨 rack 以及 P/D KV 传输。它不应制造大流量，而要持续检测关键路径的延迟分位、completion 正确性和路径稳定性。

canary pool 需要跨故障域抽样，并按日轮转 endpoint 组合，避免恰好永远绕过坏路径。发布前 canary 则应绑定变更：NIC firmware、switch NOS、cable replacement、NCCL/CUDA 版本、ECN/PFC policy、路由配置和模型 runtime。若 canary 不通过，自动停止扩大 rollout；若通过但用户 SLO 变坏，说明测试覆盖不够，应把真实的失败形状加入测试集。

13. 故障注入与恢复演练：不要把首次验证留给事故

演练应在隔离环境完成首轮验证，再移到生产低优先级容量，并准备明确的 rollback。每次只注入足以检验检测、隔离、降级和恢复机制的故障。例如限制单条流带宽以模拟拥塞，让一台 worker 失联，使 P/D transfer 在 commit 前超时，让一个 expert rank 变慢，在可控条件下错误标注一个 cache directory entry，或执行单条链路的 drain，检查路由和流量迁移是否符合预期。

1. 写下假设、影响面、成功判据和停止条件。
2. 确认告警是否先从用户 SLO 触发，并能下钻到预期设备/路径。
3. 验证路由是否停止分配新请求，in-flight 请求是否安全重试或降级。
4. 验证 KV 是否以版本和 completion gate 防止脏读，恢复后是否能重建目录。
5. 记录恢复时间、人工步骤与遗漏遥测，把 case 固化成回归测试。

特别是 PFC 与交换策略，不能在生产通过随意制造 pause frame 来试验。应该使用受限端口、仿真/实验 fabric 或厂商认可的测试机制，并提前协调网络和服务负责人。

14. 容量回归：新增 GPU、模型或租户后，为什么 P99 反而更差

AI cluster 的瓶颈会随规模移动。增加 GPU 可能提高 compute capacity，却让 leaf/spine oversubscription、NIC PCIe 根复合体、光纤布线、buffer headroom、control-plane 规模或 P/D 目的地形成新瓶颈。升级模型也会改变 MoE token 分布、KV bytes/token、通信 message shape 与 batch policy。因此容量评审必须既测稳态也测同步 burst。

不要把单流 iperf 或线速 RDMA benchmark 当作上线准入。更有价值的是记录需求侧 trace，回放真实的 all-to-all、不均匀 expert、长 KV transfer 及并发峰值；同时跑容量对照组，观察 network queue、CNP/PFC、GPU idle 和完成时间如何随负载陡增。回归必须在配置、拓扑和软件版本发生变化时持续执行。

15. 运行手册：一次 P99 回归的最短证据路径

1. 确认范围：按模型、版本、rack、租户、请求类型和时间窗口看 TTFT/TBT/错误率，先排除单一前端或排队事故。
2. 固定样本：抽取慢请求 trace，列出其 model step、communicator、rank、QP/flow 和拓扑快照。
3. 找第一个慢点：比较 CUDA event、collective launch、CQ completion 与后续 kernel，确认是 launch 前、网络中还是 completion 后。
4. 横向比对：比较慢 rank 与正常 rank 的 GPU、NIC、port、queue、ECN/PFC、FEC 和路径；同时查看 expert/KV 负载是否偏斜。
5. 安全缓解：停止把新请求送往可疑故障域，限制后台大流，触发缓存重算或把 EP/TP 组缩到健康域；不破坏 in-flight 数据语义。
6. 证伪后修复：以 canary 和同形 workload 验证路径恢复，再逐步解除 drain。事后将缺失指标、错误告警与手工步骤写回 runbook。

重启有时必要，但必须等 trace、counter snapshot 和 topology/version 证据保存完成后再执行。否则现场被清掉，下一个相同事件仍然无法归因。

16. 2026 OCP 状态：参考架构把可运维性写进 fabric，而不是替代验证

截至 2026 年 7 月，OCP 已公开发布面向 AI training 与 inference 的 Open Cluster Designs aligned fabric reference architectures。推理文档面向 64–1,024 xPU 集群，描述基于 OCP switch、SONiC 数据平面和 Kubernetes-native 控制面的推理 fabric；它区分无独立后端网的最小推理形态与带 lossless RDMA 后端的分布式推理形态，并将 Day-0/Day-1/Day-2 的配置、持续 reconciliation 和可观测性纳入设计。它是可采用的开放参考架构，不是替代厂商互操作验证、SLO 压测或你的故障演练的通用标准。

同年 OCP ESUN 1.0 把 Ethernet scale-up 的 operator requirements 放进公开规范，包括可靠/无损传输、小消息开销和多 hop 拥塞控制等方向；SUE-T 仍作为 endpoint/XPU transport 的工作流推进。对运行团队的实际含义是：将 topology、rail/dual-plane、priority、配置版本、GitOps/CRD 意图与 telemetry 作为同一份可审计配置，而非把它们分散在 GPU、网络和平台三个独立团队的手册里。

采用这些参考架构时仍应明确边界：哪些网络是 converged，哪些是 isolated；哪些流量允许 lossless；ECN/PFC 阈值、buffer 分配、host/NIC firmware、光模块认证、Kubernetes reconciliation 与模型 runtime 的版本如何共同变更。参考设计提供骨架，生产可靠性来自对自身拓扑和工作负载的实测。

17. 公众号选题映射：本页从哪些网络问题展开

以下只把公开目录中的文章标题用作选题导航与延伸阅读，不复制或替代原文。它们之所以适合本页，是因为分别覆盖可靠传输、软件定义可靠性、AI 芯片与光互连、以及 128 卡基础设施；完整目录和证据等级见 相关公众号内容目录。

相关基础页：03 GPU 算子、07 通信与拓扑、08 数据中心 KV 与 P/D、18 训练与推理共用集群。这些页面解释系统为什么需要 fabric；本页解释怎样把它运行成可诊断、可验证、可恢复的服务。

18. 一手来源与阅读边界

• OCP Open Cluster Designs Aligned AI Inference Fabric Reference Architecture, April 2026：推理 fabric、64–1,024 xPU 范围、SONiC/Kubernetes-native 控制面和 Day-0 至 Day-2 运行机制。
• OCP Open Cluster Designs Aligned AI Training Fabric Reference Architecture, April 2026：训练 fabric 的对应参考设计。
• OCP ESUN 1.0 Specification release, March 2026：Ethernet scale-up 的公开 operator requirements 与工作范围。
• OCP SUE-T workstream：endpoint/XPU transport 的工作流状态与公开文档入口。
• NCCL User Guide：collective、debug 与通信语义的实现参考。
• NVIDIA Cloud Accelerator Documentation, Telemetry and Observability：OpenTelemetry、node/DCGM、gNMI/OpenConfig 与 hot/cold telemetry path 的官方架构例子。
• Mainline 总来源表与相关文章索引：本项目的来源边界、目录覆盖和人工映射状态。

本文把公开规格、运行机制与工程经验组织为解释，不把任何单一论文、厂商文档或公众号文章的 benchmark 数字外推为通用承诺。上线前仍需在目标 GPU、NIC、交换芯片、光模块、软件版本和真实请求 trace 上复现。