企业官网建设流程全解析

干网络这行十来年，最怕听到的不是“网络又断了”，而是“来了个新概念”。因为你得花一个周末搞清楚它到底是真需求还是换皮包装。最近圈子里“推理网络”这个词被反复提起，我一开始也以为是厂商造词，结果认真扒了一圈，发现还真不是炒作——它是大模型推理服务跑起来之后，网络侧实打实暴露出来的新瓶颈。

什么算推理网络？简单说，就是专门承载大模型推理流量的网络方案。过去我们做数据中心网络，主要服务的是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模型，隐藏层维度8192，80层Transformer，8个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.33MB，2048个token就是0.67GB。如果希望这个分发在几百毫秒内完成，网络至少要提供十几Gbps的有效带宽。这类流量平时不起眼，但一旦并发上来，对网络带宽的消耗远高于你的直觉。

4. 新要求之二：时延敏感度极高，长尾抖动是头号敌人

4.1 为什么张量并行经不起“慢”网络

张量并行是同步模型，每层计算完都要all-reduce，所有参与卡必须等最慢的那张卡到齐才能进入下一层。这意味着网络时延不是“分摊”到每个请求上，而是“加”在每一步上，而且是乘法放大：网络多出的每一微秒，都会乘以层数和token数。

比如解码阶段每生成一个token，80层网络每层都可能有一次小同步，如果每次同步因为网络抖动多等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 --pfc=0,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 一张速查表

我个人在实际操作中的体会是：推理网络调优没有一劳永逸的银弹，它更像是一个持续的基线管理过程。每次变更，不管是业务侧新上了并发策略、还是网络侧改了QoS配置，都要跑一遍集合通信基线，盯着P99的变化。只要把“时延基线”这个概念刻进团队的日常流程里，推理集群的网络问题大多数都能在用户感知之前被发现和处理。