干网络这行十来年最怕听到的不是“网络又断了”而是“来了个新概念”。因为你得花一个周末搞清楚它到底是真需求还是换皮包装。最近圈子里“推理网络”这个词被反复提起我一开始也以为是厂商造词结果认真扒了一圈发现还真不是炒作——它是大模型推理服务跑起来之后网络侧实打实暴露出来的新瓶颈。什么算推理网络简单说就是专门承载大模型推理流量的网络方案。过去我们做数据中心网络主要服务的是Web业务、数据库、分布式存储流量特征是“高并发、小报文、长连接居多”。后来做AI训练网络核心诉求是“高带宽、低丢包、大规模集合通信”。但推理服务一上来网络压力又变了一个画风既要扛住突发又要保证极低时延还要在链路抖动时不影响线上服务的P99延迟。这篇文章我想从通信模式出发把“推理网络”到底对网络提出了哪些新要求讲透同时给出一套可以直接参考的组网和调优思路适合正在做大模型推理服务、AI Infra或者数据中心网络的工程师看。1. 推理网络到底是什么先把它和训练网络分清楚1.1 我理解的“推理网络”很多人第一次听到“推理网络”会以为是什么新协议、新设备。其实不是。它更像是一个“场景化网络设计”的统称针对大模型推理服务的流量特征把物理拓扑、拥塞控制、QoS策略、可观测性体系重新做了一遍定制。它依然跑在以太网或InfiniBand之上但很多参数和策略跟传统网络完全不是一个调法。打个比方训练网络像跑货车——货物量大路线固定在乎的是总吞吐偶尔晚点没关系。推理网络像跑网约车——乘客要实时响应线路随机最怕堵车和红绿灯哪怕只有一次大堵车乘客体验就崩了。所以同样是高速公路货车的车道设计和网约车的调度策略肯定不一样。推理网络就是这么个“为了实时响应而重新设计”的网络。1.2 为什么以前没人单独提推理网络传统推理比如老式的图像分类、语音识别模型小、并发低一张GPU卡就能扛住网络基本无感。但大模型不一样。一个70B参数的模型单卡放不下必须做张量并行把模型切到多张GPU上。多张GPU之间每个token生成都要做同步通信网络就从“可选项”变成了“关键路径”。再加上服务化部署多实例并发、输入输出都是大Token序列流量模型极其复杂。还有一个现实原因AI训练集群出问题最多是“这次训练任务慢一点”推理集群出问题就是“线上服务超时、报错、客户投诉”。服务等级协议SLA直接压在网络上以前在传统网络里可以睁一只眼闭一只眼的长尾时延问题在推理场景会被无限放大。所以推理网络被单独拎出来讨论不是概念创新是需求逼出来的。2. 从大模型推理的通信模式推导出网络需求2.1 三种并行三种通信胃口大模型推理常见的并行方式有三种张量并行、流水线并行、数据并行。三种并行对网络的诉求完全不同这也是推理网络有别于传统网络的根源。张量并行是把一个Transformer层切开比如把注意力头的计算分到8张卡上每张卡算一部分然后通过all-reduce汇总结果。这种通信是“每层都要做每步都要做”频率极高单次数据量跟序列长度和隐藏层维度强相关。它在网络里跑的是典型的集合通信流量对带宽和时延都敏感属于最挑网络的一类。流水线并行是把模型按层切开卡之间传的是激活值和梯度。推理时主要是中间激活的传递单次量不大但是串行依赖强每一跳都落在关键路径上。如果网络时延抖动整个流水线都会被拖慢。数据并行在推理中的角色比较微妙它更多用于承载多路请求副本或者做KV Cache的广播和同步、专家并行里的路由分发。这类通信是“一次大批量、然后空闲一阵”对突发带宽要求高对平均带宽要求反而不高。实操中一个推理服务往往是三种并行混着用的所以网络要把这三种流量同时伺候好。2.2 预填充和解码完全不同的流量画像大模型推理一个请求分两个阶段预填充和解码。预填充阶段要处理整个输入Prompt计算量大但要传输的数据量也大——所有层的激活、KV Cache在并行卡之间的同步都集中在这个阶段。这个阶段的网络流量是“洪峰式”的像水库泄洪短时间把大量数据推出去。解码阶段是一个token一个token生成每生成一个token张量并行卡之间就要做一次同步。这个阶段的流量是“小步高频”的包不大但次数极多而且对时延的忍耐度极低。如果一次同步因为网络排队多花了几毫秒用户感知到的就是打字机输出突然卡顿。这就让网络很难办既要给预填充的大突发留足带宽又要给解码的小报文保证低时延。传统网络里“大流优先、小流靠边”的策略在这个场景下会翻车。2.3 把通信量算出来一个70B模型的实际例子光说抽象你很难有体感我拿一个典型配置算笔账。假设70B模型隐藏层维度819280层Transformer8个KV头bf16精度。输入序列长度2048张量并行度8。单个Transformer层做一次all-reduce通信量大约是2倍隐藏层维度乘序列长度乘精度字节数。代入就是2 × 8192 × 2048 × 2字节 67MB。80层下来光是预填充阶段一个请求在张量并行上的通信量就是5.2GB以上。如果线上有几十个并发请求网络瞬间要扛的流量非常可观。这也解释了为什么现在推理集群里200G/400G网卡都快成标配了100G在这种负载下很容易被顶到瓶颈。解码阶段单次token的all-reduce数据量小很多约32KB但问题是它高频且强同步。假设单卡解码速度是每token 50毫秒这32KB通信如果因为网络排队从50微秒涨到2毫秒解码时间直接多4%而且这是每层都有的等待累计放大之后P99会非常难看。3. 新要求之一带宽门槛大幅提高且分布要看“局部”3.1 峰值带宽不再是“够用就行”传统业务网络规划经常说“峰值带宽够用就行超卖一点没关系”。推理集群不能这么算。预填充阶段的通信是瞬时洪峰交换机缓存有限如果接入带宽不足丢包就会直接转化成重传和延迟拖慢整个请求。更关键的是这里看的不是整机带宽而是“每个张量并行组内的收敛带宽”。举例来说一张4090的PCIe带宽是64GB/s两张卡之间走PCIe Switch直连很快但一旦跨服务器通信就要走网卡和交换机。如果8卡张量并行被拆到了两台服务器上那么服务器之间的链路带宽就直接决定了通信耗时。我见过不少方案训练集群用得很好但推理部署时为了让多路请求共享GPU把同一个张量并行组拆到了不同的ToR交换机下结果单请求时延暴涨。3.2 推理网络里的“局部带宽规划”所以落地推理网络时第一件事不是看核心交换机带宽而是规划好“最热路径”。最热路径就是张量并行组内部的通信路径。理想情况是同一个张量并行组的8张卡落在同一台交换机的端口下甚至同一台服务器内。如果规模大了必须跨Leaf也要确保跨Leaf链路有足够的余量且不能过度超售。KV Cache的传输也吃带宽。预填充完成后KV Cache需要分发到解码实例。按前面那个70B模型的参数算每生成一个token的KV Cache大约是0.33MB2048个token就是0.67GB。如果希望这个分发在几百毫秒内完成网络至少要提供十几Gbps的有效带宽。这类流量平时不起眼但一旦并发上来对网络带宽的消耗远高于你的直觉。4. 新要求之二时延敏感度极高长尾抖动是头号敌人4.1 为什么张量并行经不起“慢”网络张量并行是同步模型每层计算完都要all-reduce所有参与卡必须等最慢的那张卡到齐才能进入下一层。这意味着网络时延不是“分摊”到每个请求上而是“加”在每一步上而且是乘法放大网络多出的每一微秒都会乘以层数和token数。比如解码阶段每生成一个token80层网络每层都可能有一次小同步如果每次同步因为网络抖动多等100微秒单个token就多出8毫秒。用户能看到的就是生成速度从每秒20token掉到每秒10token以下。这不是理论分析我实际调优时见过类似案例最终排查下来就是交换机上某条链路的ECMP哈希冲突导致偶发排队。4.2 长尾时延比平均时延更重要传统网络监控喜欢看平均时延推理网络必须盯P99、P99.9。因为推理服务往往是多路并发请求共享同一批卡任何一个请求的网络时延异常都会波及同组的其他请求。一次微小的队列拥塞可能让几十个用户同时感知到卡顿。所以推理网络的时延优化策略不是“把平均时延降低”而是“把所有抖动来源掐死”。具体要做的事包括关闭不必要的巨型帧分段、避免流表老化、关掉可能触发重路由的协议频繁震荡、把拥塞控制参数调得足够激进。一句话追求的是“稳”而不是“快”或者说稳定的快。4.3 实测时延的误区我自己踩过的坑是拿ping和iperf3测时延觉得网络很好一上推理就慢。后来才意识到传统测速只能反映端到端连通性和TCP带宽测不出集合通信场景下的真实表现。现在我做基线测试都会跑nccl-tests重点关注all-reduce在各种消息大小下的带宽和时延特别是8字节、32字节这种小消息的时延对推理解码阶段的流量模型很有参考意义。网络测速在线测网速那种页面真的也就是看看家里宽带的水平。5. 新要求之三突发流量和拥塞控制必须调到“AI模式”5.1 Incast拥塞推理集群里的隐形杀手多路并发推理请求同时触发张量并行的all-reduce会出现典型的Incast流量多个发送端同时向一个接收端灌数据接收端交换机的缓存瞬间被打满。传统TCP在丢包后靠重传恢复但AI集合通信对时延极敏感等不到TCP重传系统就已经慢了一截。RoCE网络里通常会开PFC优先级流控来保证无损但PFC是一把双刃剑。它能让交换机不丢包却可能引发“队头阻塞”一个队列暂停整个端口的其他流量全被堵住。这是推理网络最典型的问题也是网络上讨论最多的话题之一。5.2 从TCP到RoCE拥塞控制要分层调推理网络如果跑RoCEv2建议的拥塞控制组合是ECN加DCQCN而不是单纯依赖PFC。ECN能在交换机队列变深之前给发送端打标记发送端主动降速属于“温柔地避免拥塞”PFC只是最后一层兜底防止真的丢包。把这两层的关系理解成红绿灯和交警ECN是红绿灯提前疏导PFC是交警堵死了才上手指挥。只靠交警不设红绿灯整个城市交通都会乱套。具体调参要分几个层面交换机的ECN阈值要往低调让标记更敏感网卡的DCQCN参数要根据网络规模调整太激进了带宽上不去太保守了时延下不来PFC的无损队列要尽量只给RDMA流量用不要把存储流量和推理流量混在一个队列里。6. 新要求之四网络可靠性直接决定推理服务可用性6.1 一条链路抖动整组卡陪跑推理服务的可用性对网络可靠性的依赖远远高于传统Web服务。Web服务有负载均衡和重试机制后端挂一台机器用户几乎无感。但大模型推理的分布式状态是强耦合的一个张量并行组里的8张卡必须保持同步任何一张卡因为网络故障卡住整个组都会等它最终表现为服务超时。我见过一次线上事故一台服务器网卡因为固件问题出现周期性CRC错误链路并没完全断开交换机也没告警但业务方反馈推理延迟忽高忽低。排查了很久才发现是网卡在秒级内反复重训链路每次重训期间该卡所在的张量并行组全部停顿。这种“半死半活”的链路故障比完全断掉更难发现也更伤害推理服务。6.2 故障域设计宁可慢不能断推理网络的可靠性设计核心是控制故障爆炸半径。建议把一个张量并行组的通信尽量收敛在同一台交换机或同一个故障域内这样即使某台交换机出问题受影响的也只是局部请求。跨故障域的张量并行虽然灵活但一旦网络抖动影响面会扩大到一个Pod甚至整个集群。还要注意网络变更对推理服务的影响。传统网络里做链路聚合、BGP调整、交换机版本升级可以趁业务低峰期操作。推理服务往往是全天候的变更前一定要做流量模拟或者灰度切流最好配合业务方做语音延迟测试。线上直接操作导致推理卡顿的案例我身边发生过不止一次。7. 新要求之五可观测性必须有“推理视角”7.1 传统网络监控在推理集群里不够用传统网络监控看的是带宽利用率、丢包率、错包率这些指标在推理集群里只能算入门。推理集群更关心的是集合通信的单次时延有没有劣化、特定路径上有没有发生Incast、PFC暂停帧是不是频繁触发、ECN标记比例是不是异常升高。因为这些指标直接对应服务延迟。PFC暂停帧计数飙升说明有队列在反复拥塞对应的推理请求很可能在变慢。ECN标记比例突然从1%涨到5%说明网络已经进入持续高负载状态要不了多久P99就会崩溃。这些监控项以前运维不太关注现在都是推理集群网络巡检的必看项。7.2 一套可落地的监控组合我的习惯是三层监控配合。第一层是交换机侧Telemetry重点看端口丢包、PFC计数、队列深度、ECN标记计数第二层是网卡侧计数器看RDMA重传、CRC错误、链路重训次数第三层是业务侧探针定期用NCCL测试跑一轮all-reduce的带宽和时延记录基线。三层数据交叉验证才能快速定位问题。比如业务侧反馈推理慢交换机侧看到PFC计数高网卡侧看到多个端口同时暂停基本就能锁定是Incast拥塞问题如果交换机侧没异常但网卡侧CRC错误多就要怀疑物理链路或者光模块。8. 一个可以抄的推理集群网络落地方案8.1 物理拓扑怎么选规模不大的推理集群两层Spine-Leaf就够了不需要三层。Leaf交换机负责接入GPU服务器Spine负责横向流量互访。关键是让张量并行组尽量落在同一个Leaf交换机下面。以一台Leaf48端口为例如果每台服务器8张卡跑400G单Leaf可以承载25台左右的服务器一个张量并行组8卡放同一Leaf下完全没问题。跨Leaf的流量留给流水线并行和数据并行用这两类对时延的敏感度相对低一点。如果集群规模大到必须跨Leaf做张量并行建议在Leaf之间预留足够带宽并且开启自适应路由或者动态负载均衡尽量避免静态ECMP哈希导致的大象流踩踏。8.2 RoCE配置要点以下配置基于常见RoCEv2无损网络实践假设网卡是Mellanox系列操作系统Ubuntu Server。第一步确认网卡支持RoCE并启用相关模式。在BIOS和驱动层面把RDMA打开然后确认 roce 模式rdma link show第二步配置PFC。建议只在承载RDMA流量的优先级队列上开PFC其他队列不要开# 以将优先级3设为无损队列为例 mlnx_qos -i eth0 --pfc0,0,0,1,0,0,0,0第三步配置ECN。需要同时设置交换机侧和网卡侧交换机侧进入全局配置开启ECN网卡侧通过如下命令确认echo 1 /proc/sys/net/ipv4/tcp_ecn网卡侧的DCQCN参数用官方调优脚本mlnx_tune -p HIGH_THROUGHPUT第四步验证无损网络的可靠性。用ib_write_bw测试RDMA带宽用ib_write_lat测试时延重点观察是否有重传ib_write_bw -d mlx5_0 --report_gbits ib_write_lat -d mlx5_0最后跑NCCL测试验证集合通信all_reduce_perf -b 8M -e 1G -f 2 -g 8这个命令做8卡的all-reduce带宽测试如果带宽接近理论值且波动小说明网络基本到位。8.3 QoS和负载均衡的取舍推理网络的QoS策略要比传统网络精细。核心思路是给不同类型的推理流量分优先级张量并行的集合通信流量优先级最高KV Cache分发次之管理面和监控流量最低。优先级队列可以用DSCP映射来做但要控制高优先级队列的总量避免所有流量都挤进最高优先级反而失去QoS的意义。负载均衡方面ECMP虽然简单但对大流容易哈希冲突。有条件的话建议开启交换机侧的自适应路由或者加权负载均衡让大流能动态分散到不同路径上。如果交换机不支持至少在服务器侧把多网卡的流表尽量打散减少同一个张量并行组的流量长期绑定在同一条链路上。9. 推理网络的常见问题与排查实录9.1 网速测试正常但推理时延很高这个场景我遇到太多次了。iperf3测带宽能跑满但一上线推理服务就慢。原因是iperf3是TCP长流测的是吞吐上限根本不会暴露集合通信小报文的时延抖动。建议用sockperf测UDP时延用nccl-tests测all-reduce小消息性能。常见根因是ECMP哈希冲突导致某个流长期占不满带宽或者PFC暂停帧在连锁传导。9.2 PFC计数持续升高但没丢包PFC计数升高说明链路反复进入暂停状态虽然没丢包但所有受影响的流量都被阻塞了。这不是物理问题是拥塞控制策略问题。优先检查和调整ECN阈值让发送端在队列变深之前就降速而不是等PFC触发。另外看看是不是有多个大流同时突入同一个接收端如果是就要考虑在业务侧错开各个请求的预填充时间或者在网络侧做流量的动态负载均衡。9.3 推理服务P99突然恶化但没有告警这通常是最头疼的。交换机没有丢包带宽也没跑满但业务P99涨了。后来发现是网卡固件升级后RoCE的拥塞控制参数被重置了DCQCN的默认参数在低延迟场景下过于保守导致时延升高。所以每次固件升级、驱动升级、交换机配置变更后一定要做一轮NCCL基线回归测试把变更前后的all-reduce时延对比一下几秒钟就能发现问题。9.4 多路并发时偶尔出现请求超时这种偶发超时多数是Incast导致的。多路推理请求同时进入预填充阶段同时触发多个all-reduce网络在某个瞬间被打穿。排查时先在交换机上抓ECN标记和队列深度确认是否在固定时间段内出现高水位。缓解手段包括修改业务侧的请求调度避免同时突发调整ECN阈值让降速更早或者在网络侧给集合通信流量单独开一条无损队列和其他流量隔离。9.5 一张速查表现象可能原因优先排查项常用手段推理慢但带宽测速正常小报文时延劣化 / 流哈希冲突nccl-tests小消息时延、ECMP分布动态负载均衡、调整哈希算法PFC计数高拥塞控制过弱 / 队列配置不当ECN标记比例、PFC计数调低ECN阈值、分队列隔离P99恶化无告警隐性拥塞 / 参数重置网卡计数器、固件版本基线回归测试、重置DCQCN参数偶发请求超时Incast突发交换机队列深度、ECN标记错峰调度、调整QoS映射周期性延迟抖动网卡链路重训 / 光模块故障CRC错误、链路重训次数更换光模块或网线、升级固件我个人在实际操作中的体会是推理网络调优没有一劳永逸的银弹它更像是一个持续的基线管理过程。每次变更不管是业务侧新上了并发策略、还是网络侧改了QoS配置都要跑一遍集合通信基线盯着P99的变化。只要把“时延基线”这个概念刻进团队的日常流程里推理集群的网络问题大多数都能在用户感知之前被发现和处理。