企业官网建设流程全解析

1. 写在前面：算力正在变成“卡”的问题，网络才是“系统”的问题

1.1 云栖大会这一场，为什么大家都不聊单卡了

这几天行业技术会议最火的分论坛，不是又发布了什么新模型，而是AI基础设施相关的专场。云栖大会里讨论AI系统网络架构的场次，座位早早被占满，过道站了一圈人，讲师PPT一翻页，底下手机举成一片。到场的人很多不是传统网络工程师，而是做模型训练、推理平台、集群调度的一线工程团队。大家关心的问题出奇一致：GPU买了那么多，集群怎么就是跑不满？

这其实是过去一年AI基础设施领域最明显的变化。早些年我们拼单卡，比算力峰值；现在拼的是集群，比有效算力。所谓有效算力，就是算力在真实训练任务中真正发挥出来的比例。你会发现单卡算力已经很强，但训练过程中大量时间花在卡与卡之间的数据交换上，网络一旦跟不上，GPU就在空转。云栖大会把AI系统网络架构单独立题，本质上是在告诉全行业：大模型的天花板，已经从单颗加速卡，转移到了卡与卡之间的那条路上。

1.2 单机性能再强，多机协作这道坎绕不过去

为什么明明单卡性能一路飙升，大家反而越来越焦虑网络？这个问题的答案藏在模型规模的增长曲线里。模型参数的膨胀速度，一直快于单卡显存和带宽的增长速度。一个千亿级参数的模型，仅仅是完整放进显存就需要几十张卡协同，更不用说训练过程中每轮都要做梯度同步、中间结果交换、Checkpoint落盘。

打个比方。一支施工队每个人都搬砖飞快，但脚手架通道只有一条，材料从A点运到B点要排队，这时候单人体力再强，整体出货速度也被运输环节死死锁住。训练过程也一样：当通信耗时占单次迭代的三成甚至五成时，算力再富余，总训练时长依然下不来。因此现在评估一个AI集群，最务实的做法不是只统计总算力，而是先把通信账算清楚：模型多大、并行策略怎么切、每轮同步多少数据、带宽能不能兜住。把这些数据列完，网络架构的关键位置自然浮现。

下面分享的内容，不是官方会议纪要，而是我从现场讨论和多次实战排查里沉淀下来的一些思路，不一定放之四海皆准，但大概率能给同行提供参考。

2. 先别急着买交换机，把AI流量特征吃透再动手

2.1 AI流量和传统服务的流量，根本不在一个维度

网络架构设计最忌讳“经验复用”。做过传统云网络的人，如果直接把Web流量模型套到AI集群上，大概率会被现实教育。传统业务流量以南向北为主，用户请求进来、后端处理完返回，单连接时长短、数据量小，即使偶发丢包，TCP重传也能兜底，用户感知非常有限。

AI训练流量完全相反：东西向流量占绝对主导，计算节点之间为了同步梯度、交换中间结果，会产生大量持续的大象流。这种流不是偶尔来一股，而是每个训练迭代周期都会规律性爆发。我见过不少集群，平均带宽利用率看起来不高，可一旦查看交换机端口缓存，经常发现被打满，原因就是流量的周期性微突发。瞬时流量和均值流量能差出数倍，这是AI网络区别于普通业务最核心的一点。

2.2 流特征直接决定拥塞控制方案

既然流量是“持续大流加周期性突发”的组合，那么常规网络里的慢启动、拥塞窗口慢慢爬升就完全不适用。可能窗口刚爬上去，这轮通信已经结束；下一轮同步开始又重新从低窗口往上爬，链路利用率自然是上不去的。

在真实项目里，我会先做一轮流量特征梳理，再对照方案：

这张表不是理论推演，是踩过坑才总结出来的。早期我们按传统集群方式搭了一套RoCE网络，没有针对流特征做专门调整，结果一到大规模全量梯度交换阶段就出现端到端时延抖动，训练进度条从几分钟一次暴退到几十分钟一次，整个团队被迫停机查网络。所以做AI网络架构，第一步不是画拓扑，而是先把流量读明白：谁是主要通信模式、突发能打到多高、业务能否容忍抖动。这些答案出来，后面所有选型才有依据。

3. 拓扑设计：从无收敛CLOS起步，真正难的是“局部性”取舍

3.1 CLOS/胖树为什么能成为事实标准

AI集群网络拓扑绕不开CLOS架构，也就是常说的胖树。它的核心思想是把原来一台性能怪兽交换机做的事，拆成大量小设备协同完成：服务器接接入层，接入层往上全互联到Spine层，每层带宽等比放大，最终形成一张无收敛或低收敛的网络。

物理实现上，小规模集群两层CLOS就够用，接入交换机直接上联核心层；大规模集群需要三层CLOS，中间加一级Spine节点做横向扩展。选CLOS不是因为它名字好听，而是它规则性强、容易维护、扩展路径清晰。AI集群动辄上百张卡跑训练，需要的是“任意节点到任意节点都有基本一致的带宽和时延”，CLOS恰好用规则化的多路径满足了这一点。

3.2 拓扑规划里容易翻车的三个细节

第一，收敛比不能按传统云业务的习惯留余量。普通业务集群为了省钱，接入上联带宽打个五六折很常见，用户几乎无感；AI集群这么干，训练效率直接被腰斩。我在模拟项目X里做过对照，同一套训练负载，从无收敛改成2比1收敛，单次迭代时间增长接近四成，而且规模越大差距越明显。

第二，局部性必须提前规划。CLOS名义上全互联，但如果所有通信都跨Spine转发，核心层压力会很快顶到天花板。能在机柜内部完成的通信尽量留在接入层，能在Pod内部完成的不要跨核心，所有交换都强调全局反而会让全局变慢。这个道理很多团队规划时才想起来，但这时机柜、走线、设备角色已经定了，想改代价很大。

第三，扩展空间要留够余量。AI集群今天可能几百卡，明年就要扩到几千卡，选型时建议按未来一到两年的规模预留端口、光模块和机架位置。计算节点还可以热插拔平滑扩容，网络不行，改拓扑等于重建机房。我见过不止一个项目前期省了几个端口，后期扩容时被迫重新走线，成本多了好几倍。

综合来看，拓扑设计的核心不是追求某个“最优架构”，而是守住两条底线：无收敛带宽，以及可预见的局部性。满足这两条，后面调参才有意义。

4. 无损网络不是开关：RDMA落地的三大暗坑

4.1 选型先算账：InfiniBand和RoCEv2怎么权衡

深度学习通信模式对时延和丢包极其敏感，传统TCP/IP协议栈显然不够用。目前主流就是两条路：专用无损网络和基于以太网的RDMA方案。两条路都能做到高带宽低时延，但落地路径差别非常大。

InfiniBand的优势在于从物理层到协议栈都为高性能计算和AI设计，流控内建、可靠性高、生态完善，性能上限最容易做高；劣势也明显，设备和后续扩容成本偏高，与既有以太网运维体系不兼容。RoCEv2的优势是跑在标准以太网上，可以复用已有交换设备和技术积累，成本可控、工具链通用；劣势是它需要底层提供无损保障，而以太网原生机制天然“有损”，必须靠额外手段兜底。

从我的实际经验看，预算充足且追求极致稳定，选前者；想兼容现有基础设施、控制综合成本，选后者。没有绝对优劣，只有匹配度差异。大多数中型集群，基于以太网的方案已经完全够用，没有必要为极致的理论性能付出过高成本。

4.2 PFC不是开个开关那么简单

在以太网上跑RDMA，第一步是让网络“无损”。这里的主角叫优先级流控，PFC：交换机发现出端口拥塞时，向对端发送暂停帧，让对端暂时停止发送该优先级的数据，从而避免丢包。

听起来很理想，实际部署却像驯一匹烈马。PFC的暂停动作会逐跳传递，配置不当的话，一个端口拥塞能把暂停信号扩散到整个网络，引发队头阻塞，甚至造成循环等待死锁。我见过一个集群因为优先级映射配置错误，训练任务反复出现莫名其妙的超时，排查了两周才发现是一场PFC风暴。

经验是：PFC必须限制作用域。只对承载RDMA流量的队列开启，其他业务流量不要纳入暂停范围；同时配合ECN显式拥塞指示，让网卡侧主动降速，而不是让交换机的暂停帧硬扛一切。ECN阈值同样需要精细调节：设得太浅，正常抖动都会被标记，链路利用率持续打折；设得太深，真正拥塞发生时反馈来不及，报文已经丢失。通常需要结合真实流量模型反复试，不存在一劳永逸的参数。

4.3 队列映射与QoS策略

另一个常见的坑在队列设计。RoCE流量和普通TCP流量共享同一个优先级队列，很容易互相干扰：TCP的突发流量把队列塞满，RoCE报文的低时延承诺立刻失效；反之，RoCE大流长期占队列，普通业务的请求响应也被拖慢。

合理的做法是把流量划分为明确的服务等级，RoCE高优先级独占队列，普通业务走默认队列，控制面流量再单独分队列。每一跳交换机都要保持一致的映射规则，不能接入层一套、核心层另一套，否则报文优先级在中间被改写，全链路无损就变成一句空话。测试时一定要用多对多的并发同步场景做验证，单独跑两条流的时延数据很好看，并发放大后才会暴露出队列资源不足的问题。

5. 运维视角：架构图再美，也要能定位那些“看不见的丢包”

5.1 一次训练中断的完整排查链路

架构设计是纸面功夫，真实集群跑起来才是考验。模拟项目X的一次例行训练里，某个区段的任务每隔几小时就中断一次，日志报“远端通信超时”。一线同事第一反应就是查物理链路，我们第一轮排查也确实从物理层开始。

第一步，检查两端网卡的物理链路状态，链路UP，没有闪断记录。第二步，看交换机的端口统计，发现丢包计数在持续增长，但增长节奏不均匀。第三步，打开RDMA的拥塞事件计数器，重传事件和拥塞通知集中指向某两台交换机之间的互联链路。第四步，把这两台设备的镜像流量拉出来分析，发现当几条高优先级流同时经过这条链路时，瞬间流量直接打满端口容量。

最终定位不是设备故障，而是该链路承载的几条大流在时间轴上撞在一起，拥塞信号还没来得及反馈，丢包已经发生。真正的问题不是硬件，是流量调度和QoS策略没有覆盖到这台边缘交换机，等于说架构图上这里是通的，实际流量路径上这里却是窄道。事后我们在核心链路调整了缓存策略区间并重新设置ECN阈值，训练恢复稳定。整个过程看起来顺理成章，但每一步都依赖准确的可观测数据，没有观测手段就是在黑夜里大海捞针。

5.2 监控系统必须看到的指标清单

吃一堑长一智，现在评估一个AI集群是否健康，我不只看GPU利用率，会固定检查一组网络侧指标：

这套指标覆盖了物理层、链路层和传输层，才算得上端到端可见。很多团队把监控只做到网卡层，交换机策略一变，故障定位直接抓瞎。AI网络架构的运维复杂度和成本明显高于普通业务网络，这也是我坚持要把监控诊断预算放进架构总盘里的原因，省掉这笔钱的团队，几乎都会在后面用几倍的人工成本补回来。

6. 下一站：DPU下沉、端到端调度与算力网络化

6.1 网络职能从交换机延伸到端点

AI网络架构下一步的趋势，是把更多网络能力下沉到节点侧。CPU处理报文、中断、协议栈的代价太高，在AI集群这种高吞吐场景下尤其不划算，这些活正在逐步转移到专用硬件上。新集群里连RDMA控制、拥塞管理、流量过滤都开始前置到加速卡，目的只有一个：把宝贵的计算资源让给真正的业务计算。

这不是追热点，而是网络可编程化发展的必然结果。网络不再是一根固定宽度的管道，而是一块可以按任务切割、按流调度的资源。云端多租户共享集群时，谁能更精细地控制网络路径和优先级，谁就能保障各自训练任务的稳定性。把端点硬件的网络能力打开，拥塞控制才能真正摆脱交换机侧的单点决策。

6.2 算力与网络的边界正在消失

这两年团队的设计习惯也在变化：从“先布算力、再配网络”，慢慢变成“算力和网络一起画”。原因很实际，训练任务的通信模式反过来影响拓扑选型，网络能力反过来限制并行策略的选择。带宽不足时，并行策略得切得更细来降低单次通信量，可这又增加了通信次数，对时延提出更高要求。算力和网络已经变成一张图里的两条互相牵制的曲线。

个人在这个方向上的体会是：别指望一次性把架构定死。AI系统网络架构是一条需要持续迭代的线，第一次搭建保证规范，后续根据流量监控、故障记录和新的模型规模不断做演进。把这个底线守住，比迷信任何一套现成方案都靠谱。技术会变，设备会换代，但“先看懂流量、再做无损、最后搞清故障到底发生在哪一跳”这个思路，在接下来几年里大概不会过时。