ReelOS.AI 禅定｜一句话看懂本文
AI Fabric 团队不是把网络搭通，而是把 GPU 集群跑稳。
- GPU 很贵。
- 但 GPU 集群不是插上线就能高效训练。
- 训练性能取决于拓扑、RoCE / IB、RDMA、NCCL、GPU-NIC 亲和性、监控和交付流程。
- 网络通了，不代表 NCCL 快。
- NCCL 快了，不代表真实训练 step time 稳。
- step time 一抖，GPU 就等待。
- GPU 等待，就是算力浪费。
- 所以团队不能只懂交换机。
- 还要懂 GPU 拓扑、NCCL、RDMA、PFC / ECN / DCQCN、压测、监控和客户验收。
- 最小团队要有架构负责人、RoCE / IB 网络工程师、GPU / NCCL 性能工程师、自动化可观测性工程师和测试交付工程师。
- 真正的壁垒不是“这次能跑通”。
- 而是把每次交付沉淀成模板、脚本、Dashboard、报告、Runbook 和案例库。
- AI Fabric 工程团队的本质，是把 GPU 网络能力变成可复制的有效算力交付能力。
AI 基础设施的竞争，正在从“谁有更多 GPU”，转向“谁能让 GPU 稳定、高效、可规模化地协同工作”。
这背后真正缺的，不只是 GPU，也不只是交换机，而是一支能把 GPU 集群网络做成工程系统的小队。
我建议把这支小队命名为：
ReelOS AI Fabric 工程团队
它不是传统网络运维团队，也不是单纯的机房布线团队，而是面向 GPU 集群、AI Factory 和大规模训练推理任务的高性能网络工程团队。
它要解决的问题不是“网络通不通”，而是：
这套 GPU 集群能不能稳定跑大模型任务，能不能压出性能，能不能定位瓶颈，能不能交付给客户，能不能形成可复制的工程资产。
一、为什么需要 AI Fabric 工程团队？
传统数据中心网络团队主要回答三个问题：
| 问题 | 典型关注点 |
|---|---|
| 网络通不通 | 连通性、路由、ACL、VLAN |
| 网络稳不稳 | 丢包、延迟、链路故障 |
| 网络够不够快 | 带宽、端口速率、收敛比 |
但 GPU 集群网络要回答的问题完全不同。
它要回答的是：
| AI 集群问题 | 真实含义 |
|---|---|
| NCCL AllReduce 稳不稳 | 多卡训练是否被通信拖慢 |
| step time 是否抖动 | 是否存在尾延迟、慢 rank、链路异常 |
| GPU 利用率能不能上去 | 网络、通信库、拓扑是否匹配任务 |
| 256 卡到 1024 卡能不能线性扩展 | Fabric 是否具备规模化能力 |
| 链路故障是否可降级 | 集群是否有工程韧性 |
| 客户能不能验收 | 是否有测试报告、监控面板、Runbook |
所以，AI Fabric 团队不能只懂交换机。
它必须同时懂：
- GPU 拓扑；
- NCCL / RCCL 通信库；
- RoCE / InfiniBand；
- RDMA 与 GPUDirect；
- PFC / ECN / DCQCN；
- 交换机与 NIC；
- 训练任务性能指标；
- 监控、压测、调优和交付。
一句话：
AI Fabric 团队的目标，不是把网络搭起来，而是把 GPU 集群的有效算力交付出来。
二、团队定位：不是网络团队，而是 AI Compute Fabric 工程团队
这支团队的定位可以这样定义：
面向 GPU 集群和 AI Factory 的高性能网络工程团队，负责 RoCE / InfiniBand Fabric 的架构设计、构建、压测、调优、可观测性和客户交付。
它服务的不是普通业务系统，而是大模型训练、推理、微调、AI 视频、Agent 工作负载和 GPU Cloud。
它的能力栈不是单层网络，而是一条从任务到物理链路的完整路径：
GPU / 训练任务
↓
NCCL / RCCL / 分布式通信库
↓
RDMA / RoCE / InfiniBand
↓
交换机 / NIC / QoS / PFC / ECN
↓
自动化 / 监控 / 测试 / 交付 / Runbook这也是为什么我更倾向叫它 AI Fabric 工程团队，而不是网络团队。
“网络团队”容易让人误以为它只负责连接。
“AI Fabric 工程团队”强调的是：
- 它面向 AI workload；
- 它负责 GPU 集群协同；
- 它要交付有效算力；
- 它要形成可复制的工程资产；
- 它要把基础设施能力变成产品交付能力。
三、最小可行团队：5 人小队
如果要从 0 开始搭建一支 AI Fabric 工程团队，我建议最小可行团队是 5 个人。
1. AI Fabric 架构负责人
这是团队的核心角色。
他不一定亲自写所有配置，但必须能做整体判断。
主要职责包括：
- 定义 GPU 集群网络架构；
- 选择 RoCE、InfiniBand 或混合方案；
- 设计 Spine-Leaf、Rail-Optimized、双平面或多平面网络；
- 定义 PFC、ECN、DCQCN、QoS 策略；
- 制定 NCCL 性能验收标准；
- 协调 GPU、网络、存储、调度和客户交付团队。
这个人需要同时懂网络、GPU 集群和客户交付。
如果没有这个角色，团队很容易变成“谁声音大听谁的配置团队”。
2. RoCE / InfiniBand 网络工程师
这是网络侧主力。
主要负责：
- 交换机配置；
- NIC 配置；
- VLAN、BGP、ECMP、ACL；
- PFC、ECN、QoS；
- MTU、GID、RDMA 参数；
- 链路、光模块、FEC、队列和端口状态；
- 网络故障定位。
如果走 RoCE，这个角色尤其重要。
因为 RoCE 的难点不是“能不能跑 RDMA”，而是：
在真实拥塞、多租户、多任务、故障和规模化条件下，能不能稳定跑。
3. GPU / NCCL 性能工程师
这是很多团队容易忽略，但非常关键的角色。
网络配置看起来没问题，不代表 GPU 集群性能就好。
必须有人能看懂：
- NCCL tests；
- all_reduce_perf；
- bus bandwidth；
- algorithm bandwidth；
- rank mapping；
- GPU-NIC affinity；
- PCIe / NUMA 拓扑；
- GPUDirect RDMA；
- 多机多卡训练 step time。
这个角色负责把“网络指标”翻译成“训练性能”。
如果没有他，团队很容易陷入一个误区：
网络工程师说网络没问题，但训练团队说任务还是慢。
AI Fabric 团队必须有人能跨过这条沟。
4. 自动化 / 可观测性工程师
GPU 集群网络不能靠手工排查。
这个角色负责把工程能力沉淀成系统。
主要职责包括：
- Ansible / Terraform / GitOps 配置自动化；
- 交换机和 NIC 配置模板；
- Prometheus / Grafana 监控；
- GPU、NIC、Switch、NCCL、Job 指标采集；
- 拓扑和端口资产管理；
- 告警规则；
- 日志关联；
- 自动生成测试报告。
这个角色决定团队能不能从“高手救火”变成“系统交付”。
5. 测试交付工程师
AI Fabric 最终不是实验室项目，而是要交付。
这个角色负责：
- RDMA 压测；
- NCCL 压测；
- 故障注入；
- burn-in；
- 客户验收报告；
- 部署文档；
- Runbook；
- 交付 checklist；
- 问题复盘。
如果没有测试交付角色，团队很容易只停留在“我们觉得可以”的状态，而不是“客户能验证、能复盘、能接手”的状态。
四、如果只能先组 3 人，先组哪 3 个？
如果资源有限，可以先从 3 个人开始。
优先顺序是：
AI Fabric 架构负责人
RoCE / IB 网络工程师
GPU / NCCL 性能工程师原因很简单：
- 架构负责人决定方向；
- 网络工程师把 Fabric 搭起来；
- GPU / NCCL 工程师证明它真的服务训练效率。
自动化和交付可以先由三人兼任，但不能长期缺位。
一旦进入真实客户项目，就必须补上自动化和测试交付。
否则团队会变成手工作坊：
- 每个项目都重新摸索；
- 每个问题都靠个人经验；
- 每次交付都不可复用；
- 每次故障都重新定位。
这不适合 AI Infra 公司。
五、团队工作流：设计、构建、压测、调优、交付、复盘
AI Fabric 团队的工作不应该是“客户说慢了再排查”。
它应该有一套标准工作流：
设计 → 构建 → 压测 → 调优 → 监控 → 故障注入 → 交付 → 复盘
1. 设计阶段
设计阶段要输出完整方案，而不是只输出拓扑图。
至少包括：
- GPU 集群规模；
- 训练还是推理；
- 前端网络、后端网络、存储网络、管理网络；
- Spine-Leaf 拓扑；
- Rail-Optimized 拓扑；
- IP / VLAN / QoS 规划；
- 端口规划；
- GPU-NIC Affinity；
- RoCE / IB 选择；
- PFC / ECN / DCQCN 策略；
- 故障域设计；
- 验收指标。
这里最重要的是先定义验收标准。
不要等系统搭完再问“算不算好”。
2. 构建阶段
构建阶段要尽量模板化。
包括：
- 交换机配置；
- NIC 配置；
- 固件版本；
- 驱动版本；
- CUDA / NCCL / OFED 版本；
- MTU；
- GID；
- TC / DSCP；
- cabling；
- 连通性测试报告。
原则是：
所有配置都应该可模板化，所有版本都应该可追踪，所有变更都应该可回滚。
3. 压测阶段
压测不能只测一个 ib_write_bw。
至少分三层：
| 层级 | 测试内容 |
|---|---|
| RDMA 基线 | ib_write_bw、ib_read_bw、ib_send_lat、perftest |
| NCCL 集合通信 | all_reduce_perf、all_gather_perf、reduce_scatter_perf、alltoall |
| 真实训练负载 | step time、p99、GPU util、MFU、checkpoint 影响 |
RDMA 测试只能说明链路基础能力。
NCCL 测试才能说明 GPU 集群通信能力。
真实训练任务才能说明业务有效算力。
4. 调优阶段
调优不是到处复制环境变量。
调优应该从问题表开始。
| 现象 | 可能问题 |
|---|---|
| RDMA 带宽低 | MTU、GID、PCIe、NUMA、网卡模式 |
| NCCL busbw 低 | GPU-NIC affinity、rank mapping、拓扑不匹配 |
| step time 抖动 | 拥塞、慢 rank、链路错误、后台流量 |
| 某些节点拖慢整体 | firmware、驱动、光模块、端口、温度 |
| 多机扩展效率差 | 拓扑、ECMP、PFC、NCCL 算法 |
| PFC pause 高 | 队列配置、拥塞控制、流量模型不匹配 |
| 链路 flap | 光模块、线缆、FEC、温度、交换机端口 |
调优的正确方式是：
问题类型 → 指标证据 → 假设 → 实验 → 结果 → 模板沉淀不是“改一个参数试试看”。
5. 监控阶段
AI Fabric 监控不能只看交换机端口。
必须打通五层：
- GPU 层：利用率、显存、温度、功耗；
- NCCL 层：busbw、algbw、rank、错误日志；
- NIC / RDMA 层：retransmission、CNP、ECN、queue、drop；
- Switch 层：PFC pause、buffer、FEC error、link flap；
- Task 层：step time、checkpoint time、job failure、restart。
真正有价值的是跨层关联。
例如：
step time 抖动
→ NCCL busbw 下降
→ 某一 rail 流量不均
→ leaf uplink PFC pause 升高
→ 某条光模块 FEC error 增加这种能力才是 AI Fabric 团队的壁垒。
6. 故障注入阶段
如果一个 GPU 集群没有做过故障注入，就不能算真正交付。
至少要测试：
- 单个 NIC port down；
- 单条 leaf uplink down；
- 某条光纤拔掉；
- 某台交换机端口 flap；
- 某台节点降速；
- 某个 optics error；
- 背景流量干扰；
- PFC pause 异常；
- 某条上行关闭后的重路由。
目标不是证明系统不会坏。
目标是证明：
系统坏的时候，性能如何降级，任务是否可恢复，监控是否能发现，Runbook 是否能指导处理。
7. 交付阶段
交付不应该只交机器。
应该交一套可验证资产：
- 拓扑图；
- 端口表；
- IP / VLAN / QoS 规划；
- 交换机配置；
- NIC 配置；
- 固件和驱动版本；
- RDMA 测试报告；
- NCCL 测试报告；
- 故障注入报告；
- Burn-in 报告；
- Grafana Dashboard；
- Runbook；
- Troubleshooting Guide；
- 风险清单。
客户真正需要的不是“你说能跑”，而是“我知道如何验证、如何监控、如何接手、如何排障”。
8. 复盘阶段
每次项目交付后，都应该进入案例库。
复盘至少记录：
- 客户环境；
- GPU / NIC / Switch 型号；
- 拓扑；
- 软件版本；
- 初始性能；
- 调优动作；
- 性能变化；
- 故障案例；
- 可复用配置；
- 不可复用风险。
长期看，AI Fabric 团队的护城河，不是某一次配置经验，而是不断积累的工程案例库。
六、团队应该沉淀的 8 类工程资产
AI Fabric 团队真正值钱的不是“人会调”，而是团队能把经验沉淀成资产。
至少应该沉淀 8 类资产。
1. 架构模板
包括：
- 8 卡单机模板；
- 32 卡小集群模板；
- 64 卡集群模板；
- 256 卡 RoCE 模板；
- 1024 卡 Rail-Optimized 模板；
- B200 / B300 集群模板；
- 训练集群模板；
- 推理集群模板。
模板不只是图，而是带端口规划、拓扑约束、风险说明和适用场景。
2. 配置模板
包括：
- 交换机 QoS；
- PFC；
- ECN；
- BGP / ECMP；
- NIC sysctl；
- NCCL 环境变量；
- RoCE GID；
- MTU；
- DSCP / TC；
- buffer profile。
配置模板要按场景组织，而不是堆成一个大文件。
3. 测试脚本
包括：
- RDMA baseline；
- NCCL all-reduce；
- NCCL all-gather；
- 多任务并发测试；
- 故障注入测试；
- burn-in；
- 单节点异常检测；
- 拓扑一致性检查。
测试脚本最好能自动生成报告。
4. 监控面板
至少包括：
- GPU Dashboard；
- NIC Dashboard；
- RDMA Dashboard；
- Switch Dashboard；
- NCCL Dashboard；
- Training Job Dashboard；
- Fabric Symmetry Dashboard。
最关键的是能按 job、rank、node、rail、port 做联动。
5. 验收报告模板
包括：
- 测试环境；
- 硬件配置；
- 软件版本；
- 测试方法；
- 指标结果；
- 风险说明；
- 结论；
- 后续建议。
这决定客户能不能理解你交付的结果。
6. 故障案例库
典型案例包括：
- NCCL hang；
- 某节点慢；
- busbw 下降；
- PFC storm；
- FEC error；
- 光模块异常；
- 端口丢包；
- rank mapping 错误；
- GDR 不生效；
- 多任务互相干扰。
案例库要记录“现象、指标、定位过程、解决方案、复盘”。
7. 选型数据库
包括：
- NIC 型号；
- Switch 型号；
- Optics；
- Cable；
- GPU 平台；
- OFED 版本；
- Driver 版本；
- Firmware 版本；
- 已验证组合；
- 不推荐组合。
AI Fabric 是强工程领域，选型数据库非常重要。
8. Runbook
Runbook 是团队工程化水平的最终体现。
至少包括：
- 新集群部署；
- 新节点加入；
- 网络扩容；
- NCCL 性能下降；
- RDMA 异常；
- 链路故障；
- 光模块替换；
- PFC pause 异常；
- 客户验收；
- 重大故障处理。
七、90 天构建计划
如果从 0 开始，我建议用 90 天搭出第一版能力。
第 1 阶段：0–30 天，定方向和实验室设计
目标不是马上交付客户，而是建立基本方法。
要完成：
- AI Fabric 技术路线判断；
- RoCE / IB 方案对比；
- Lab 拓扑设计；
- 测试工具选型；
- 监控指标定义；
- 第一版交付 checklist；
- 第一版 Runbook 框架。
交付物：
- AI Fabric 架构白皮书 v0.1；
- Lab 拓扑图；
- 测试设备 BOM；
- 指标体系；
- Runbook 目录。
第 2 阶段：31–60 天，搭建 Lab 和基线测试
这一阶段要让团队真正跑起来。
要完成：
- 小规模 RoCE / IB Lab；
- RDMA baseline；
- NCCL tests；
- GPU-NIC affinity 验证；
- PFC / ECN 参数实验；
- Grafana Dashboard；
- 故障注入第一版；
- baseline report。
交付物：
- 交换机配置模板；
- NIC 配置模板；
- NCCL 测试脚本；
- Prometheus / Grafana Dashboard；
- RDMA 测试报告；
- NCCL 测试报告。
第 3 阶段：61–90 天，形成可交付版本
这一阶段要从实验室走向客户交付。
要完成：
- 标准交付流程；
- 验收报告模板；
- 故障注入 checklist；
- 典型问题案例库；
- 客户交付文档；
- 性能调优 Runbook；
- 选型建议；
- 复盘机制。
交付物：
- AI Fabric Delivery Handbook v1.0；
- AI Fabric Tuning Runbook v1.0；
- AI Fabric Acceptance Template；
- Dashboard v1.0；
- 故障案例库 v1.0。
八、团队招聘画像
AI Fabric 架构负责人
关键词：
- 大规模 GPU 集群；
- HPC / AI Networking；
- InfiniBand / RoCE；
- NCCL；
- 分布式训练；
- 客户交付；
- 方案架构。
这个人最好既做过工程，又做过客户场景。
RoCE / IB 网络工程师
关键词：
- Ethernet / InfiniBand；
- BGP / ECMP；
- PFC / ECN；
- RDMA；
- Mellanox / NVIDIA Networking；
- Arista / Cisco / H3C / Huawei；
- 光模块和链路排障。
GPU / NCCL 性能工程师
关键词：
- CUDA；
- NCCL；
- PyTorch Distributed；
- DeepSpeed；
- Megatron；
- GPU topology；
- PCIe / NUMA；
- GPUDirect RDMA；
- performance profiling。
自动化 / 可观测性工程师
关键词：
- Prometheus；
- Grafana；
- Ansible；
- Python；
- GitOps；
- Telemetry；
- log correlation；
- CMDB；
- topology inventory。
测试交付工程师
关键词：
- 性能测试；
- 压测；
- burn-in；
- 故障注入；
- 客户验收；
- technical documentation；
- Runbook；
- support escalation。
九、团队的关键 KPI
AI Fabric 团队不能只看“完成了多少配置”。
更适合看这些指标：
| KPI | 含义 |
|---|---|
| 架构设计能力 | 能否为不同规模集群设计合理 Fabric |
| 性能交付能力 | NCCL、RDMA、训练 step time 是否达标 |
| 稳定性能力 | 故障注入后是否可降级、可恢复 |
| 可观测性能力 | 是否能跨 GPU、NCCL、NIC、Switch 定位问题 |
| 交付效率 | 新项目从设计到验收需要多久 |
| 资产沉淀 | 是否形成模板、脚本、报告、Runbook、案例库 |
| 客户价值 | 客户是否能接手、能复盘、能扩容 |
最关键的 KPI 是：
是否把一次性的项目经验，沉淀成下一次可以复用的工程能力。
十、常见误区
误区一：把 RoCE 团队理解成网络团队
RoCE 团队不是普通网络团队。
它要服务的是 GPU 通信、NCCL 和训练效率。
如果只懂交换机，不懂 GPU workload，做不好 AI Fabric。
误区二：以为调优就是改 PFC / ECN
PFC / ECN 很重要，但不是全部。
很多问题来自：
- GPU-NIC affinity；
- PCIe / NUMA；
- NCCL 算法；
- rank mapping；
- firmware；
- 光模块；
- 后台任务；
- job scheduler。
AI Fabric 调优必须跨层。
误区三：只测 ib_write_bw
ib_write_bw 只能说明 RDMA 基线。
它不能说明真实训练是否快。
必须结合：
- NCCL tests；
- 真实训练 step time；
- 多任务并发；
- 故障注入；
- 长时间 burn-in。
误区四：没有故障注入
AI 集群一定会坏。
区别不是坏不坏，而是：
- 坏的时候能不能发现；
- 能不能降级；
- 能不能恢复；
- 客户知不知道怎么处理。
误区五：交付后没有复盘
如果交付后没有复盘，团队永远只是在做项目。
复盘才会形成产品化能力。
十一、最终组织形态
早期 5 人团队可以这样：
1 个 AI Fabric 架构负责人
1 个 RoCE / IB 网络工程师
1 个 GPU / NCCL 性能工程师
1 个自动化 / 可观测性工程师
1 个测试交付工程师中期可以扩展到 8–10 人：
- 增加供应链 / 硬件选型；
- 增加 K8s / Slurm 平台工程；
- 增加客户解决方案架构师；
- 增加 SRE / 运维服务；
- 增加文档和标准化。
长期可以形成三条线：
方案架构线
测试调优线
交付运维线最终目标不是做一个临时项目组，而是形成：
AI Compute Fabric 工程能力中心。
结语
AI Infra 公司的真正竞争力，不只是能不能拿到 GPU，也不只是能不能采购交换机。
真正稀缺的是：
能不能把 GPU、NIC、交换机、通信库、训练任务、监控、测试和客户交付组织成一套稳定工程系统。
这就是 AI Fabric 工程团队的价值。
它交付的不是一张网络拓扑图，而是：
- 可验证的性能；
- 可观察的系统；
- 可复用的配置；
- 可复盘的案例；
- 可交接的文档；
- 可规模化的交付能力。
一句话总结：
ReelOS AI Fabric 工程团队，不是为了让网络跑通，而是为了让 GPU 集群持续交付有效算力。