1. 从一场大会聊起AI系统网络架构到底在解决什么问题如果你最近两年一直在做后端或者基础设施相关的工作大概率会有一种很强烈的体感以前我们聊网络架构聊的是“三高”——高并发、高可用、高吞吐而现在再聊网络架构绕不开的一个词变成了“AI系统”。这两个词放在一起并不是简单的叠加而是整个设计范式的一次重构。我先把结论摆在前面AI系统的网络架构和传统互联网业务的网络架构本质上不是同一类问题。传统业务里网络是“通道”你把请求送进去把响应取回来网络本身是相对被动的。但在AI系统里网络变成了“参与者”——它直接决定了训练任务能不能跑满GPU、推理服务的首token延迟能不能压到可接受范围、多机多卡之间的梯度同步会不会成为瓶颈。换句话说网络架构设计得好不好直接反映在账单和用户体验上。这篇文章想做的事情很具体把“AI系统网络架构”这个听起来有点虚的概念拆成能落地、能对照、能抄作业的工程细节。我会从整体设计思路讲起然后深入到训练网络、推理网络、存储网络这几个核心场景再补充参数计算、实操要点、常见坑和排查方法。适合正在做AI平台基础设施的工程师、准备把业务往AI方向迁移的架构师以及单纯想搞明白“为什么大模型训练要专门搞一套网络”的技术爱好者。需要提前说明的是文中涉及的具体产品型号、参数配置我会尽量用通用描述和常见实践来补全因为不同团队、不同规模、不同预算下的选型差异非常大。但底层的逻辑和取舍原则是相通的这部分才是真正值钱的东西。2. AI系统网络架构的整体设计思路拆解2.1 为什么传统网络架构直接搬过来会翻车先讲一个我亲眼见过的场景。某团队早期做模型训练用的是公司现成的通用云主机集群网络是普通的万兆以太网走的是标准的TCP/IP协议栈。单机单卡跑小模型没问题一旦扩展到多机多卡训练效率直接断崖式下跌。8卡扩展到64卡理论算力提升8倍实际只提升了不到3倍剩下的全耗在等梯度同步上了。问题出在哪传统网络架构的设计目标是“公平地服务大量小请求”它的优化方向是连接数、并发处理、负载均衡。而AI训练的网络需求恰恰相反它需要的是少数几条连接上跑满带宽、极低延迟、极低抖动。这两者的优化目标几乎是正交的。具体来说传统架构在AI场景下会暴露三个致命问题。第一TCP协议栈的拥塞控制机制在高带宽长距离场景下效率很低丢包重传带来的延迟抖动会被放大。第二通用交换机的缓冲区设计是为了应对突发流量但在AI训练这种持续满带宽的场景下缓冲区反而会引入额外的排队延迟。第三传统网络的多跳转发路径不确定而AI训练对路径对称性和延迟一致性有极高要求。所以你会看到真正做AI基础设施的团队几乎都会单独规划一套网络平面而不是和业务网络混在一起。这不是为了显得高级而是被实际需求逼出来的。2.2 三个网络平面训练、推理、存储的分工逻辑一个成熟的AI系统网络架构通常会拆成三个相对独立的平面我习惯把它们叫做训练平面、推理平面、存储平面。这三个平面的流量特征完全不同混在一起就是互相伤害。训练平面的核心特征是东西向流量为主带宽需求极高延迟敏感流量模式规律但突发性强。多机多卡训练时梯度同步、参数广播这些操作会在极短时间内产生巨大的东西向流量。这个平面通常会用RDMA over Converged Ethernet或者InfiniBand这类技术绕过内核协议栈直接把数据从一台机器的内存搬到另一台机器的内存。推理平面的特征则完全不同南北向流量为主单次请求数据量不大但对首token延迟和尾延迟极其敏感。用户发来一个请求系统要在几百毫秒内返回第一个token这个过程中涉及模型加载、KV Cache管理、批处理调度等一系列操作。推理平面的网络设计重点不是峰值带宽而是稳定性和可预测性。存储平面的需求又不一样它要处理的是海量小文件的随机读写和大文件的顺序读写混合场景。模型checkpoint动辄几十上百GB训练数据可能是几百万个小文件。这个平面需要的是高IOPS和足够的带宽同时对延迟的容忍度相对高一些。把这三个平面分开最大的好处是故障隔离和性能可预测。训练任务把网络跑满的时候不会影响推理服务的响应存储节点做checkpoint的时候不会拖慢梯度同步。这个思路和传统架构里“读写分离”“动静分离”是一脉相承的只是AI场景把这种分离推到了更极致的程度。2.3 选型背后的核心权衡带宽、延迟、成本的不可能三角做AI网络架构本质上是在带宽、延迟、成本这三个维度之间做权衡。想要高带宽低延迟成本就上去了想要控制成本就得在带宽或延迟上做妥协。没有银弹只有取舍。我整理了一个常见的选型对照表方便你快速定位自己团队可能适合的方向场景规模推荐网络技术带宽量级延迟量级成本量级适用阶段单机单卡/小规模实验普通万兆以太网10Gbps百微秒级低验证阶段单机多卡/小集群25G/100G以太网 RoCEv2100Gbps十微秒级中小规模训练多机多卡中等集群200G/400G RoCEv2400Gbps微秒级中高正式训练大规模训练集群InfiniBand NDR/XDR400G-800Gbps亚微秒级高大模型训练推理服务集群25G/100G以太网25-100Gbps十微秒级中在线服务这张表不是绝对的很多团队会在中等规模时选择RoCEv2而不是InfiniBand核心考量就是成本和运维复杂度的平衡。RoCEv2能在以太网上跑RDMA虽然性能和稳定性略逊于InfiniBand但生态更开放运维人员更容易上手硬件成本也低不少。提示选型时不要只看理论峰值带宽要关注“有效带宽”和“尾延迟”。很多标称400G的网卡在实际AI训练场景下的有效带宽可能只有60%到70%这个折扣率在规划容量时必须考虑进去。3. 训练网络把梯度同步的瓶颈打掉3.1 梯度同步为什么是训练网络的命门要理解训练网络的设计得先理解训练过程本身。数据并行训练时每张卡用不同的数据算梯度然后需要把所有卡的梯度汇总求平均再广播回每张卡更新参数。这个“汇总再广播”的过程就是AllReduce操作。AllReduce的通信量有多大假设模型有10亿参数用FP16存储那就是2GB。每次迭代都要做一次AllReduce如果batch size是32那每处理32个样本就要传输2GB的数据。按每秒处理1000个样本算每秒需要传输约62GB的数据换算成带宽就是约500Gbps。这还只是一个中等规模的模型。所以训练网络的第一要务就是让AllReduce尽可能快。这里有两个优化方向一是提高单次传输的效率二是减少传输的次数或数据量。提高传输效率的核心手段是RDMA。传统TCP/IP传输需要经过内核协议栈数据从用户态到内核态再到网卡多次拷贝CPU占用高延迟大。RDMA允许网卡直接访问远端内存绕过内核零拷贝CPU几乎不参与。实测下来同样硬件条件下RDMA能把AllReduce的效率提升3到5倍。减少传输次数的手段包括梯度压缩、梯度累积、混合并行策略等。梯度压缩是把梯度量化成更低的精度再传输比如从FP16压到INT8通信量直接减半。梯度累积是攒几个batch的梯度再同步一次减少同步频率。混合并行则是把数据并行、流水线并行、张量并行结合起来让通信和计算更好地重叠。3.2 RoCEv2和InfiniBand的实战对比这是训练网络选型时绕不开的一个话题。我尽量客观地讲一下两者的实际差异不吹不黑。InfiniBand是专为高性能计算设计的网络技术从协议到硬件都是为低延迟高带宽优化的。它的优势很明显延迟极低且稳定拥塞控制机制成熟大规模组网经验丰富。缺点是贵网卡、交换机、线缆都比以太网贵一大截而且运维体系和传统以太网不兼容需要专门的人才。RoCEv2是在以太网上实现RDMA的技术它保留了RDMA的内存直接访问能力但底层跑在以太网上。优势是成本相对低可以复用现有的以太网运维体系生态更开放。缺点是对网络配置要求极其严格尤其是无损网络的配置一旦配置不当性能会大幅下降甚至出现丢包。我踩过的一个坑早期用RoCEv2时没有正确配置PFC和ECN结果训练任务跑着跑着就出现性能抖动排查了很久才发现是某个交换机的缓冲区溢出导致PFC反压进而影响了整条链路。后来把PFC配置细化到优先级队列ECN阈值调优之后才稳定下来。注意RoCEv2的无损网络配置是门手艺活。PFC配置过松会导致丢包配置过紧会导致反压扩散。ECN的阈值设置需要根据实际流量特征反复调优。如果团队没有这方面的经验建议先用小规模集群做充分验证。3.3 参数计算到底需要多大带宽很多人在规划训练网络时对带宽需求是拍脑袋决定的。我分享一个简单的估算方法能帮你快速算出大概需要多大的网络带宽。核心公式是所需带宽 模型参数量 × 2梯度参数 × 同步频率 × 并行度系数举个例子。假设模型参数量是70亿用FP16存储梯度也是FP16。每次AllReduce需要传输的数据量是 7B × 2字节 × 2梯度参数 28GB。如果每秒做10次迭代那就是280GB/s换算成带宽是2240Gbps。这是单机内部的通信量如果是多机还要除以节点数再乘以跨节点通信系数。当然这是极端情况实际中会用梯度累积、混合并行等手段来降低同步频率和通信量。但通过这个计算你能看出来为什么大模型训练必须用400G甚至800G的网络为什么InfiniBand在大规模训练场景下几乎是标配。对于中小规模训练我的经验值是每张GPU配100G到200G的网络带宽是比较舒服的区间。低于这个值通信容易成为瓶颈高于这个值除非模型特别大或者并行策略特别复杂否则利用率上不去钱花得有点冤。3.4 拓扑设计胖树、轨道优化与实战选择网络拓扑决定了数据包从一张卡到另一张卡要经过几跳。跳数越少延迟越低但成本和布线复杂度越高。最常见的拓扑是胖树。它的思路是把交换机分成多层每一层的带宽都收敛到上层保证任意两个节点之间的带宽是对称的。胖树的好处是扩展性好坏处是交换机数量多成本高。另一种思路是轨道优化。这种拓扑把同一轨道上的节点用一条高速链路连起来跨轨道的通信走上层交换机。它的优势是在做AllReduce时如果通信模式能匹配拓扑效率会非常高。但缺点是灵活性差一旦通信模式不匹配性能会下降。实际选择时我的建议是中小规模集群用胖树大规模集群可以考虑轨道优化或混合拓扑。胖树的通用性更好运维简单不容易出幺蛾子。轨道优化适合通信模式非常固定的场景比如固定并行策略的大模型训练。还有一个容易被忽视的点是布线。大规模集群的线缆数量是惊人的一个千卡集群可能需要上万根线缆。布线的质量直接影响信号完整性和误码率。我见过因为一根线缆接触不良导致整个训练任务频繁中断的案例排查起来极其痛苦。所以布线一定要规范标签要清晰最好有自动化的线缆检测工具。4. 推理网络延迟、吞吐与成本的三角博弈4.1 推理场景的网络特征与训练的本质差异训练网络和推理网络虽然都叫“AI网络”但设计思路几乎是相反的。训练追求的是极限吞吐可以容忍一定的延迟抖动因为训练任务通常跑几个小时甚至几天偶尔的抖动对整体影响不大。推理追求的是稳定低延迟因为用户就在屏幕前等着首token延迟超过一秒体验就崩了。推理场景的流量特征也很不一样。训练是持续的大流量推理是突发的小流量。用户请求可能集中在某个时间段爆发也可能长时间没有请求。这种突发性对网络的弹性提出了很高要求。另外推理场景通常涉及多模型协同。一个完整的AI应用可能包含意图识别、实体抽取、知识检索、答案生成等多个模型这些模型可能部署在不同的节点上请求需要在它们之间流转。这种链式调用对网络的端到端延迟影响很大。所以推理网络的设计重点不是峰值带宽而是延迟的确定性和稳定性。你需要保证99分位的延迟在可接受范围内而不是只看平均延迟。4.2 首token延迟的构成与网络优化点首token延迟是推理服务最核心的指标之一。它由几个部分组成请求排队时间、模型加载时间、prefill计算时间、网络传输时间。网络传输时间通常只占一小部分但在某些架构下会被放大。比如如果推理服务用了KV Cache分离的架构prefill阶段和decode阶段在不同的节点上执行那KV Cache的传输就会成为首token延迟的一部分。KV Cache的大小和序列长度成正比长序列场景下可能达到几百MB甚至GB级别。这部分数据的传输时间必须算进首token延迟里。优化首token延迟的网络手段包括就近部署把prefill节点和decode节点放在同一台机器或同一机架内协议优化用gRPC over HTTP/2或者自定义的二进制协议替代HTTP/1.1连接复用避免每次请求都建立新连接。我实测过一个案例同样的模型和硬件把推理服务从HTTP/1.1换成gRPC之后首token延迟从380毫秒降到了210毫秒降幅超过40%。原因就是HTTP/1.1的队头阻塞和连接建立开销在推理场景下被放大了。4.3 批处理调度与网络拥塞的联动关系推理服务为了提高吞吐通常会做动态批处理把多个用户请求攒在一起一次性送给模型计算。批处理能显著提高GPU利用率但也会引入额外的延迟——用户请求需要等待攒批。批处理的大小和网络拥塞之间存在微妙的联动关系。批处理越大单次传输的数据量越大网络拥塞的风险越高。一旦网络出现拥塞批处理的响应时间就会变长进而导致更多请求积压形成正反馈循环。解决这个问题的思路是把批处理调度和网络状态感知结合起来。具体来说调度器需要知道当前网络的负载情况如果网络已经比较拥塞就适当减小批处理大小避免雪上加霜。这需要网络监控数据和调度器之间有实时的数据通道。提示批处理大小不是越大越好。我见过为了追求吞吐把批处理开到很大的配置结果尾延迟飙升用户体验反而变差。建议根据实际流量特征和延迟要求找到一个平衡点并且这个点应该随着流量变化动态调整。4.4 多模型编排下的网络路径优化现代AI应用很少是单个模型打天下更多是多个模型协同工作。比如一个智能客服系统可能先经过意图分类模型再经过知识检索模型最后经过答案生成模型。每个模型可能部署在不同的节点上请求需要在它们之间跳转。这种多模型编排对网络路径优化提出了新要求。传统的做法是每个模型暴露一个API编排层依次调用。这种方式的缺点是网络跳数多每跳都有额外的序列化/反序列化开销。更优的做法是把编排逻辑下沉到网络层。比如用服务网格来做模型间的流量管理把多次调用合并成一次网络往返。或者用共享内存的方式让同一台机器上的多个模型直接通信完全绕过网络。还有一个思路是模型融合。把多个小模型合并成一个大模型或者用同一个模型完成多个任务。这样能从根本上减少网络调用次数。当然这需要模型层面的改造不是纯网络架构能解决的。5. 存储网络被低估的隐形瓶颈5.1 训练数据加载与checkpoint的网络开销存储网络在AI系统里经常被忽视但它对整体性能的影响可能超出你的想象。我见过一个案例训练任务本身的计算效率很高但整体吞吐上不去最后排查发现是数据加载成了瓶颈。训练数据存在远程存储上每个batch都要从网络拉取数据网络带宽不够GPU经常处于饥饿状态。Checkpoint是另一个存储网络的重灾区。大模型训练每隔一段时间就要保存一次checkpoint动辄几十上百GB。如果存储网络带宽不足保存一次checkpoint可能要几分钟甚至十几分钟这段时间训练是暂停的GPU在空转。按每小时保存一次、每次暂停5分钟算一天就有2小时是浪费的相当于8%的算力被白白烧掉。所以存储网络的规划必须把数据加载带宽和checkpoint写入带宽都算进去。数据加载的带宽需求取决于训练数据的读取速度和batch sizecheckpoint的带宽需求取决于模型大小和保存频率。5.2 并行文件系统的选型与调优AI场景下的存储通常会用并行文件系统来满足高吞吐和低延迟的需求。常见的选型包括基于NVMe的分布式文件系统、对象存储网关、以及一些专为AI优化的存储方案。选型时我关注几个核心指标顺序读带宽、随机读IOPS、元数据操作延迟、以及扩容的线性度。顺序读带宽决定了数据加载的速度随机读IOPS决定了小文件场景下的性能元数据操作延迟影响文件创建和查找的效率扩容线性度决定了集群规模上去之后性能能不能同步上去。调优方面有几个实操经验可以分享。第一调整预读大小。并行文件系统通常有预读机制预读大小设置得当能显著提升顺序读性能。第二合并小文件。训练数据如果有大量小文件最好在预处理阶段合并成大文件减少元数据操作。第三分离元数据和数据流量。如果文件系统支持把元数据操作和数据传输走不同的网络平面避免互相干扰。5.3 存储与计算分离架构的网络考量现在很流行存储计算分离的架构计算节点不存数据所有数据都从远程存储拉取。这种架构的优点是弹性好计算节点可以随时扩缩容数据是共享的。但缺点是网络压力大所有数据都要走网络。做存储计算分离时网络规划要特别注意几点。带宽要留足余量因为所有计算节点的数据请求都会汇聚到存储集群峰值带宽可能是平均带宽的好几倍。延迟要可控存储访问的延迟会直接叠加到训练或推理的延迟上如果存储网络延迟高整体性能就会受影响。要有缓存层在计算节点本地加一层缓存把热点数据缓存在本地减少对远程存储的访问。我个人的经验是存储计算分离适合数据量特别大、计算任务弹性需求高的场景。如果数据量不大或者计算任务比较固定本地存储加网络备份的方案可能更简单、更高效。不要为了架构而架构。6. 常见问题与排查技巧实录6.1 训练性能不达预期的排查路径训练性能不达预期是最常见的问题。我的排查路径通常是这样的第一步确认瓶颈在计算还是通信。用性能分析工具看GPU利用率和网络带宽利用率。如果GPU利用率高但网络带宽低说明瓶颈在计算如果GPU利用率低但网络带宽高说明瓶颈在通信如果两者都不高说明瓶颈在数据加载或调度。第二步如果瓶颈在通信看是带宽不够还是延迟太高。带宽不够的表现是网络利用率持续接近100%延迟太高的表现是网络利用率不高但通信等待时间很长。前者需要扩容带宽或优化通信量后者需要检查网络配置和拓扑。第三步检查RDMA是否正常工作。用ibstat或类似工具确认RDMA链路状态用perftest工具做带宽和延迟基准测试。如果RDMA性能远低于预期检查PFC、ECN配置检查网卡固件版本检查交换机配置。第四步检查是否有网络抖动。用ping或专用工具做长时间延迟监测看是否有周期性的延迟尖峰。如果有检查是否有其他流量干扰检查交换机的缓冲区统计。6.2 推理服务尾延迟飙升的典型原因推理服务的尾延迟飙升通常有以下几个原因批处理大小设置不当。批处理太大单个请求的等待时间变长尾延迟自然上去。解决方法是根据延迟要求动态调整批处理大小或者用更细粒度的调度策略。KV Cache管理效率低。KV Cache的分配和回收如果不够高效会导致内存碎片和频繁的分配操作进而影响延迟。解决方法是预分配KV Cache池用更高效的内存管理策略。网络拥塞。推理服务之间的调用如果走同一条网络路径高峰期可能出现拥塞。解决方法是用服务网格做流量管理或者把相互调用的服务部署在更近的位置。模型加载慢。如果推理服务需要频繁加载模型模型加载时间会直接体现在尾延迟上。解决方法是做模型预热或者用常驻内存的方式避免重复加载。6.3 网络配置的常见坑与速查表网络配置的坑非常多我整理了一个速查表覆盖最常见的几类问题问题现象可能原因排查方法解决方向RDMA带宽远低于预期PFC/ECN配置不当检查交换机PFC统计和ECN标记调整PFC优先级和ECN阈值训练任务随机中断线缆或光模块故障检查网卡误码统计和链路状态更换线缆或光模块推理延迟周期性抖动其他流量干扰抓包分析流量模式隔离网络平面或限流存储访问延迟高元数据操作瓶颈检查文件系统元数据节点负载优化元数据操作或扩容多机通信效率低拓扑不匹配分析通信矩阵和拓扑结构调整并行策略或拓扑注意网络问题的排查最重要的是有基线数据。平时就要做好网络性能的基准测试和监控出问题的时候才能快速对比定位是配置变更导致的还是硬件故障导致的。没有基线数据排查就是盲人摸象。6.4 几个我踩过的坑和独家经验第一个坑过度追求理论峰值带宽。早期规划网络时我按理论峰值带宽来算容量结果实际跑下来有效带宽只有60%左右。后来学乖了规划时直接按70%的有效带宽来算留足余量。第二个坑忽视网卡固件版本。不同版本的网卡固件在RDMA性能和稳定性上差异很大。我有一次升级固件后RDMA性能反而下降了回滚后才恢复。所以固件升级一定要先在测试环境验证。第三个坑PFC配置一刀切。PFC的优先级配置需要根据实际流量特征来定不能所有流量都用同一个优先级。我把训练流量和存储流量配了不同的PFC优先级之后互相干扰的问题才解决。第四个坑监控指标不全面。早期只监控了带宽利用率没有监控延迟分布和丢包率。结果出现性能问题时只能看到带宽没跑满但不知道是延迟高了还是丢包了。后来把延迟分位数、PFC反压次数、ECN标记数都纳入监控排查效率大幅提升。7. 从架构到落地一些务实的建议聊了这么多技术细节最后我想从更务实的角度给一些建议。AI系统网络架构这件事技术选型只是一部分更重要的是匹配团队的实际阶段和需求。如果你还在验证阶段模型不大数据量也不大那就别折腾RDMA和InfiniBand了普通万兆以太网足够用。把精力放在模型和业务逻辑上网络架构等规模上来了再优化也不迟。如果你在做中等规模的训练RoCEv2是性价比比较高的选择。但一定要找有经验的网络工程师来配置无损网络否则性能可能还不如普通以太网。如果你在做大规模训练InfiniBand几乎是绕不开的选择。虽然贵但稳定性和性能确实值这个价。组网时建议找有大规模集群经验的团队合作自己摸索的成本太高。推理网络的优化优先级应该是先优化模型和调度再优化网络。很多时候尾延迟高不是网络的问题而是批处理策略或KV Cache管理的问题。网络优化是最后一步不是第一步。存储网络我的建议是宁可多花点钱也不要让它成为瓶颈。存储网络的瓶颈往往很隐蔽排查起来很痛苦而且对整体性能的影响很大。在预算允许的情况下存储网络的带宽和IOPS都留足余量。还有一个容易被忽视的点是人才储备。AI网络架构涉及网络、存储、AI框架、调度系统等多个领域对工程师的综合能力要求很高。如果团队里没有这样的人要么培养要么招要么找外部支持。不要指望用传统网络工程师直接顶上知识结构差异太大。我个人在实际操作中的体会是AI系统网络架构没有标准答案只有适合当前阶段的答案。今天的最优解明天可能就过时了。保持对新技术和新方案的关注但不要盲目追新。每次架构调整之前先想清楚要解决什么问题预期收益是什么成本是什么。想清楚了再动手比什么都重要。