AI Fabric 拓扑与 QoS：从 GPU-NIC 亲和性到多机架 SLO

1. 问题定义：拓扑和 QoS 是模型执行图的一部分

多 GPU 模型不只运行在“若干台机器”上。TP 每层的 collective、MoE 的 token dispatch/combine、PP activation、P/D 之间的 KV 转移、checkpoint 和权重装载都有不同的方向、突发性、消息大小和 deadline。若网络不知道这些差异，或 runtime 不知道真实拓扑，最慢的队列会成为整个模型 step 或用户请求的关键路径。

所以设计目标应写成服务目标：在给定模型、batch、上下文长度与故障条件下，TP/EP 的 P99 通信时间是多少，TTFT/TBT 能否达标，后台训练/存储是否会抢占在线请求，单条链路或单个 NIC 故障后的降级行为是否可预测。设备端口数只是实现这些目标的约束之一。

2. 流量分类：不要把所有字节放进同一个队列

QoS 不是给每种流量贴一个优先级就结束。每种 class 还需要明确拥塞时的行为：等待 credit、降速、改路、重试、丢弃预取、停止 admission，还是重新建立 communicator。没有这些语义，优先级只会把延迟从一个工作负载转移给另一个工作负载。

3. 先画硬件层级：GPU、NIC、交换机与故障域

一个可用的 fabric inventory 至少记录 GPU 到 PCIe root complex、GPU 到 NIC、NIC 到 leaf、leaf 到 spine、rack、PDU、机柜冷却与管理网的映射。尤其是 GPU-NIC 亲和性不能通过 GPU 编号猜测：同一主机里的两张 GPU 可能跨不同 PCIe switch，实际 DMA 路径和可用带宽差异很大。

实际调度器应直接使用这张图。它要选择满足模型容量与并行要求的 GPU，核对相关 NIC/rail 的剩余预算，并把 replica 分散到不同电源、ToR 或 spine 故障域。

4. 拓扑：Clos、rail 与多平面各解决什么

leaf-spine Clos 提供可横向扩展的多路径网络；一个平面可以让每个 GPU-affinitized NIC 进入统一 fabric，多平面可以隔离流量和增加容错。rail-optimized 的意图是让同一逻辑 rank 或 GPU 的外部流量尽可能稳定地关联到特定 NIC/rail，从而避免无意的跨 PCIe 跳转和不透明的路径偏载。

“无阻塞”也需要说明口径：对所有端口无超售、对某类 AI 流量无超售，还是在某个小 scale-up 域内无阻塞。EP all-to-all 需要高双向 bisection bandwidth，TP 更在意短同步路径，存储更需要持续吞吐和隔离。不能用一个收敛比代替这些不同需求。

5. 放置：模型并行、NIC 亲和性和路由必须共同求解

TP group 最好处于一个低延迟、强互联域；EP group 则要看专家实际激活是否会使某些 NIC 接收远多于其他 NIC 的 token；DP replica 最适合跨更远的故障域；P/D 分离需要将 KV locality、目标 decode 队列和可用链路容量一起纳入选择。只按 GPU utilization 调度，很容易将网络变成隐藏的排队系统。

对于在线模型，placement 也不是一次性的。模型版本、KV 热度、expert histogram、NCCL/通信库健康和 rack 维护状态都会改变可行解。生产系统可以渐进地改变 replica 数、P/D 比例和 admission，而不应在请求执行中随意拆掉一个 TP communicator。

6. QoS：从优先级到端到端背压

端到端 QoS 要贯通 runtime queue、GPU stream、NIC queue、交换机 buffer 和接收端资源。decode critical 的 TP/EP traffic 可以优先于 checkpoint；KV transfer 在接收端缺少 HBM page 或 KV table slot 时应受 credit 限制；后台模型加载则可限速，并在高峰时暂停。

这不意味着将所有在线流量标为最高优先级。若 EP 的 burst 永远压过 TP，TP 仍会产生 token 间隔尖峰；若 PFC 或暂停类机制跨 class 扩散，所有流量都会受影响。QoS 设计要有每类 buffer 预算、速率上限、持续时间与下降策略，并由 telemetry 验证其没有造成 starvation。

7. 控制面状态机：拓扑变化不能静默进入数据面

fabric 控制面持续维护 topology epoch、设备健康、communicator membership、rail 状态、路由策略和维护窗口。数据面使用的 descriptor、KV block 和 queue pair 应携带所依赖的 epoch；当 NIC、switch 或模型版本变化时，系统先停止向旧状态注入新请求，再进行 drain、重建或回滚。

HEALTHY → DEGRADED → DRAINING → ISOLATED → RECOVERING → HEALTHY

请求决策：
topology_epoch matches
AND selected rail is healthy
AND destination has credit
AND predicted queue delay < deadline
→ admit; otherwise defer / reroute / reject

没有 epoch 的控制面会出现“设备已经被隔离，但旧 communicator 仍向它发数据”的竞态。没有 drain 的热升级则可能让正在进行的 KV transfer 或 collective 失去一半参与者。可用性来自可见的状态转换，而非事后查看日志。

8. 性能模型：从链路容量推导 SLO，而不是反过来解释

对一个网络段，持续负载可用下面的近似容量模型评估；同步 workload 的完成时间仍由最慢 rank、路径和队列决定。总交换容量无法单独预测模型并行性能，还要检查每个参与者能否在规定时间窗口内拿到所需的有效带宽。

对于 EP，应额外测 token count 的分布，而不是只测均匀 synthetic all-to-all。对于 KV transfer，应同时测多个长 prompt 完成的 burst。对于训练/推理混用，应将 checkpoint 和模型加载作为 background class 加入同一实验。

9. 部署例子：128 卡推理 pod 的可操作分层

考虑 16 个 8-GPU 节点，总计 128 GPU。第一步先让 TP8 留在节点/强互联域。若模型使用 EP16，则每两个节点形成一个 EP group，并为该组在 leaf-spine fabric 上保留对称的 NIC 与 rail。八个 EP group 通过 DP 扩出多个 replica，并跨 rack 分布；P/D 通过受 credit 控制的点对点 KV 传输连接两个服务池。

此设计应明确四个预算：EP all-to-all 的每节点峰值、P/D KV 的接收端 bytes/s、background storage 的上限、故障后剩余 rail 的降级容量。假如一条 spine 或一张 NIC 失效，router 不继续向受影响 group 分派新请求，通信库按既定策略重建或缩容，checkpoint 降速，decode traffic 保留优先级。这样“128 卡”才是一个具有 SLO 的系统，而非一个静态数量。

10. 可观测性：从用户的 TBT 一直追到交换机端口

• 用户层：TTFT、TBT、超时、降级、重路由、重试。
• 模型层：每层 collective/all-to-all 时长、expert histogram、KV transfer deadline。
• GPU/NIC：stream wait、SM 竞争、DMA、queue depth、retry、ECN/CNP、PFC pause。
• 交换网络：端口利用率、buffer watermark、丢包/标记、rail/ECMP 不均衡、光链路错误。
• 控制面：topology epoch、成员变动、路由选择、健康状态和维护事件。

所有事件至少按 request、collective group 或 transfer id 关联。否则每个团队都能证明自己那一层平均健康，却无法解释某一次 token 延迟为何高出十倍。

11. 故障与隔离：性能退化必须有边界

网络故障并不总是 link down。慢速光模块、单方向错误、拥塞控制失稳、错误的 ECMP 哈希、NIC queue 卡死、部分 rank hang 都会形成“看起来可达但很慢”的故障。应区分可快速迁移的无状态请求、需要等待 collective 失败的 TP group、可重传的 KV block 和必须保持持久性的一致性写入。

隔离策略也应避免扩大爆炸半径：一个 rack 的 background 任务不应因其 ToR 异常把全局 fabric pause 掉；一个坏 expert 或 NIC 不应让所有 MoE replica 同时重试；拓扑不确定时，router 宁可保守地拒绝一部分 admission，也不要将未知路径塞满关键队列。

12. 2026 公开状态：AI fabric 已有参考架构，但不是现成配置

OCP 在 2026 年公开的 Aligned AI Inference Fabric Reference Architecture 将 scale-up、scale-out、存储、管理、资源对象和 SLI/SLO 放进同一参考设计；OCP 的网络教育资料也讨论了基于 Ethernet 的训练/推理网络参考架构。ESUN 1.0 进一步将 scale-up Ethernet 的网络侧可靠性、拥塞与多跳需求公开化。

这些资料适合作为设计语言与验收清单，不应被当成对某一台交换机或某一个模型的性能承诺。具体集群仍须按 NIC/ASIC、通信库、模型并行、租户隔离和实际机房布线验证；尤其是 power、cooling 与可用 rack 容量也会限制可以同时运行的 GPU 数。

13. 实施检查表：把拓扑、QoS 和服务共同交付

1. 自动发现并版本化 GPU-NIC-switch-rack 图，设计变更必须可审计。
2. 为 TP、EP、KV、storage、control 定义流量 class、SLO、队列/credit 和降级动作。
3. 让并行 placement 使用实际亲和性和故障域，而不是仅按 GPU id 打包。
4. 压测真实 token histogram、长 prompt burst、混合训练/推理和单链路故障。
5. 将 trace id 打通 runtime、NIC、交换机和请求指标。
6. 做 rollout、drain、回滚、容量保护和维护窗口演练。

14. 与 Mainline 和相关文章索引的连接

15. 来源与版本边界