AI原生网络与企业级LLM Serving：决定AI Infra集群吞吐的关键

上周我处理了一个挺典型的报警一套8机64卡的训练集群GPU利用率平均只有55%任务直接慢了快一倍。起初大家怀疑是模型代码写崩了查了两天毫无头绪最后定位到网络层——RDMA链路上那0.1%的丢包硬生生把整个训练节奏拖垮了。这是我这两年做AI Infra平台支撑以来最深的感受大模型进入企业级部署阶段后AI原生网络和企业级LLM Serving早就不是两条独立的线它们互相纠缠共同决定集群的真实吞吐。这期Brief想围绕AI Infra里最容易被低估、但最近讨论度不断上升的两个关键词——AI原生网络、企业级LLM Serving——展开。不卖概念主要讲清楚为什么网络会成为训练和推理的共同瓶颈企业级Serving架构里有哪些真正影响性能的取舍以及从单机不成规模到小集群落地时有哪些用真金白银换来的经验。适合正在搭推理平台、维护训练集群或者准备从单机走向多机的同学参考。1. 为什么“AI Infra”的讨论绕不开网络1.1 从单机8卡到集群瓶颈从算力转移到通信做Infra的人都有一个直觉单卡时代看算力多卡时代看通信。模型规模过了一个阈值之后整卡集群的效率天花板往往不是FLOPS而是数据搬移的速度。举个例子。一个70B参数量的模型用Adam优化器训练每轮迭代结束要做全局梯度同步。参与同步的梯度数据量大约是模型参数量乘以优化器状态系数轻松超过一两百GB。在千卡集群上这意味着一两百GB的数据要在所有GPU之间做一次完整的AllReduce。就算跑在800Gbps的RDMA网络上纯传输时间也要几秒——而一个step可能总共才十几秒。通信一旦站上这个比例算力利用率就怎么也打不上去。推理侧更明显。用张量并行Tensor ParallelismTP把模型拆到多张卡上每过一个Transformer层就要做一次AllReduce/AllGather同步。这可不是偶尔一次而是每个token、每一层都来一遍。网络时延会直接叠加到用户的感知延迟上逃都逃不掉。所以这两年“AI Infra”这个词频繁和网络绑在一起出现不是概念包装是物理规律使然。做平台支撑久了你会发现算法决定模型能不能train起来网络决定集群能不能跑快。1.2 “AI原生网络”到底“原生”在哪里很多人第一次听“AI原生网络”会觉得玄乎觉得不就是把网络调快一点嘛。其实不是。传统网络的目标是连通性和通用性路由可达、ACL生效、高可用设计什么业务来了都能跑。AI原生网络的目标完全不同——它围绕AI流量特征来设计集合通信模式固定、带宽需求量级大、延迟敏感、流量突发性强。我自己的理解是传统网络像城市公共道路什么车都能走堵不堵看命AI原生网络更像是工厂里的自动化传送带为固定的生产流程量身定制。具体到落地通常体现在四件事上无损网络基础设施RoCE或InfiniBand配合流控和拥塞控制保证RDMA不丢包GPU Direct RDMA数据从GPU显存直通网卡绕开CPU内存拷贝拓扑感知调度知道每张卡物理上在哪台机器、哪个交换机下分配任务时让通信量尽量局域化精细化QoS与拥塞规避训练、推理、存储各走各的队列谁高优先谁低优先说得清清楚楚。这四件事单拎出任何一件都不算新技术但组合起来就是一套为AI工作负载服务的网络体系。它的价值不在“通了”在于“确定性”——该快的时候快该稳的时候稳。2. 训练侧的网络账本NCCL集合通信的物理现实2.1 一次AllReduce要烧掉多少带宽先说结论在NCCL里跑Ring AllReduce数据量大约会是原始数据的两倍。原因很简单——环形结构下数据要沿环流动一圈每个节点既要传自己的一份又要转发别人的一份最终每个数据块都相当于被传输了两次。公式是2 * (N-1) / N * data_sizeN非常大的时候通信总量趋近2 * data_size。这个比例对规划集群很关键。假设你的梯度张量是100GB那张口就是200GB的传输量。100Gbps网卡理论传完要16秒200Gbps网卡要8秒。如果训练脚本里一个step本来就只有10秒你算算这带宽还够不够用——不够的话就得考虑梯度压缩FP16/BF16混合精度、梯度分桶bucketting、或者通信与计算重叠overlap这些手段。实际规划时更要注意不同并行策略的通信画像数据并行DP每步一次全量梯度同步频率高数据量取决于模型大小张量并行TP通信频率极高每个Layer都同步数据量相对小但对延迟极其敏感流水线并行PP阶段间通信频率低数据量小但会引起流水线气泡影响效率。很多团队喜欢一头扎进模型并行配置而忽略背后NCCL的通信路径。我的建议是上手先用nccl-tests里的all_reduce_perf把你这套拓扑的底线带宽测出来再对照模型的通信画像做并行规模决策比凭感觉分配TP和DP靠谱得多。2.2 RoCE与InfiniBand的选型账本企业级AI集群网络选型绕不开两个方案InfiniBandIB和RoCE。我把常用对比放在一起方便照着选维度InfiniBandRoCE v2无损机制硬件级端到端无损依赖ECNPFC组合调优相对成本高专用交换机/线缆低复用以太网生态运维复杂度相对低硬件自身保证质量高整网参数都要对齐生态开放性相对封闭厂商绑定明显开放工具链丰富典型场景超大规模、严格SLA绝大多数企业集群我接触的企业里RoCE v2是绝对主流原因很朴素——便宜且能复用已有以太网运维体系。但RoCE有个致命前提必须无损。一旦出现拥塞丢包NCCL性能会断崖式下跌而且这个下跌不是线性的是雪崩式的。后面第五章我会专门讲这个坑。另外还有一个必须提的关键技术GPU Direct RDMAGDR。它让数据从GPU显存经PCIe直通网卡根本不需要进CPU内存。不夸张地说GDR开关前后多机通信延迟可能差一个数量级。但这个功能依赖驱动、固件、BAR映射、IOMMU配置全部对齐非常容易踩坑后面实操部分会提到。如果你问我选型建议8卡以内一条NVLink就够用别折腾外部网络16到64卡上一套RoCE很合理再到更大规模就要看预算和SLA要求认真评估要不要上IB了。2.3 拓扑感知调度别让数据流硬闯物理结构训练集群最常见的物理结构是Leaf-Spine两层架构。一个Leaf交换机下面挂若干台GPU服务器Spine交换机把多个Leaf连起来。同一Leaf下的两台机器通信带宽很足跨Leaf就要占用Leaf上联端口遇到网络重负载就会被拖慢。所以分配训练任务时最忌讳的是随便把GPU撒给任务用。两个TP8的并行组一个组集中在两台机器上另一个组被拆到四台机器上实际性能差距可能高达20%。原因就在跨Leaf通信挤占带宽还叠加传播延迟。实践中的做法是三层配合NCCL自己会做拓扑探测通过NCCL_DEBUGINFO能看到它选了怎样的Tree/Ring路径用NCCL_TOPO_DUMP_FILE/path/topo.txt导出拓扑文件分析卡的实际物理位置在调度层尽量让同一个并行组落在同一机架甚至同一台Leaf之下。K8s和Ray这类平台其实都支持GPU拓扑调度扩展就是把GPU所在PCIe Switch、NUMA节点、网络位置上报给调度器。关键是平台团队要真去开这个能力否则任务放置就是随缘性能自然随缘。3. 企业级LLM Serving的架构解剖3.1 从“用户提问”到“Token流式返回”的完整链路企业级的LLM推理服务和玩具Demo完全是两码事。Demo是启动一个vLLM进程开个HTTP接口完事。生产环境里请求要经过一条完整的链路用户请求 → 负载均衡 → API网关 → 服务路由 → 推理调度器 → 推理实例组 → 流式Token返回每一层都有它存在的意义负载均衡处理TLS和南北向流量API网关承载鉴权、配额、限流服务路由根据模型类型把请求导到对应的推理实例池调度器则要实时知道每个推理实例的负载、KV Cache余量和健康状态把新请求投递到最合适的Worker上。调度器这一步很多团队容易低估。推理实例能接多少并发不是看CPU核数而是看显存里KV Cache还剩多少、当前有多少请求在排队、GPU的算力是否还有余量。KV Cache满了性能再好的卡也接不下新请求。所以企业级Serving里调度器本质是一个“显存算力网络”三维感知的资源管理器。3.2 PD分离为什么Prefill和Decode必须分开管很多人最开始把所有推理请求混在同一个实例池里跑结果就是互相拖累。原因在于Prefill和Decode这两个阶段对资源的需求画像完全不同Prefill阶段处理的是用户输入的Prompt计算量大、爆发性强需要GPU算力快速把KV Cache计算出来Decode阶段逐个生成Token每次只算一个Token主要开销是读KV Cache和权重瓶颈在显存带宽而且延迟直接暴露给用户。混跑时最典型的场景一个系统提示词特别长的请求进入Prefill占住GPU密集计算几秒钟同时在线用户的Decode请求TPOTToken间延迟直接从80毫秒被拉到800毫秒体验直接崩盘。PD分离架构的核心思路是Prefill池和Decode池独立部署、独立扩缩容。Prefill完成后把算好的KV Cache传输给Decode池的实例由后者继续生成。好处是两类负载各跑各的互不干扰代价是引入KV Cache跨机传输也就是新增了网络通信量PD池之间链路压力反而变高了——这又是一个网络在Serving里被放大的例子。3.3 Continuous Batching与KV Cache企业级的算账方法再往引擎内部看决定单卡吞吐的机制主要是两个Continuous Batching连续批处理和KV Cache管理。早期做推理用的是静态Batch攒够一批请求再一起算慢了就空转快了就空等。Continuous Batching的关键改进是“随时上下客”——某个请求在Decode中走完了新请求立刻补进当前StepGPU不闲着尾部延迟也平稳很多。如今vLLM、SGLang、TGI这些框架都已经把Continuous Batching变成默认能力。但Batching调得再好也绕不开显存里的KV Cache。一个长上下文的请求KV Cache占用随Token数和层数线性增长可能轻松占用上百MB到GB级显存。以前的做法是预分配一大块连续显存碎片化严重导致大批请求并发时OOM。PagedAttention的思路借鉴操作系统分页把KV Cache切成分块按需分配碎片问题基本解决。企业里做容量规划时我习惯用一个粗糙但有效的公式单卡可用KV显存 ÷ (平均并发数 × 单个Token平均KV占用) ≈ 支撑的并发数再把模型权重占用、推理引擎框架开销都算进去之后你才能回答一个最现实的问题这卡到底能同时给多少用户用。模型能不能扛不是显卡厂商说了算是你把账算明白才能拍板。4. 当网络进入推理路径延迟敏感下的服务化部署4.1 流式返回背后的网络质量细节训练对网络要求是“大水管灌水”推理对网络的要求更高也更微妙——它要求“低延迟、小抖动、不断流”。用户感知的三个核心指标首Token延迟TTFT、Token间延迟TPOT、整体吞吐。这三个指标任何一项都不只是GPU算出来的而是“计算网络”的共同结果。TTFT受调度和Prefill影响TPOT受GPU访存和网络传输共同影响。很多团队在做TPOT日志分析时会犯一个错误只记录模型推理引擎内部的耗时完全忽略从引擎到用户之间的网络链路。于是每次排查“为什么用户说慢”时都找不到真正根因。正确的做法是在API网关层记录每个Token的接收时间戳再和推理引擎侧的时间戳对账一看就能分清是GPU慢还是网络慢。流式返回还有一个隐藏问题连接数。每条活跃请求一条SSE长连接网关和负载均衡要同时维持成千上万条连接。TIME_WAIT堆积、TCP重传、连接数打满这些听起来很传统的词到了LLM Serving时代照样是事故元凶。4.2 多节点分布式推理的流量模式不是所有模型都能塞进单机8卡。模型一大就要把TP、PP、EP这些并行策略组合起来用网络就会进入推理的关键路径。张量并行TPTF每层都要做AllReduce/AllGather。跨节点时网络延迟直接叠加到每一步前向计算上。NVLink单机内带宽可能到600GB/s级别RoCE的100Gbps/200Gbps与之相比差距明显所以跨节点TP要控制规模至少别让通信把计算收益吃光流水线并行PP阶段间传输的是中间激活值频率较低但会放大流水线不平衡问题网络时延也会加重BubbleMoE类模型的Expert Parallel每个Token要路由到可能位于不同节点的专家通信变成高频、随机、小包的交换模式特别考验网络的单包延迟和并发处理能力。这带来的思维转变是为训练设计的网络规划核心指标是“总带宽”为推理设计核心指标是“延迟”“抖动”“并发性”。一条充满背景流量的万兆网络训练任务也许能忍在线推理绝对会哭着跑。4.3 企业网络里的优先级与隔离策略既然训练和推理的特征差异这么大那它们最好别挤在同一条无损队列里。我见过不少集群把训练AllReduce和在线推理放在同一个ROCE网络里没有任何隔离结果训练一个峰值通信就把推理TPOT顶上去。排序建议很简单推理流量最优先延迟敏感任何排队都不能忍训练流量次之带宽敏感但可以容忍秒级波动存储、日志、同步等普通流量最后跑传统TCP就行。操作层面至少要做到VPC或网段隔离、独立的RDMA队列、PFC/ECN的参数按队列差异化配置。比如推理队列用较小的Buffer和较低的ECN阈值让拥塞尽早反馈训练队列用大Buffer换带宽效率。另外要有“快速失败优雅降级”的预案。训练网络出现短暂抖动顶多慢几秒推理网络出现抖动用户直接流失。节点异常时应该主动摘除不要带着病硬扛让请求一直卡到超时。5. 落地中的坑与经验从“能通”到“稳定”5.1 案例复盘0.1%丢包如何拖垮训练回到开头那个报警。现象老规矩GPU利用率在50%到90%之间反复波动任务训练速度只有预期的六成但GPU本身没有任何报错驱动和SM健康状态都正常。我们第一反应是看日志没发现异常。第二反应查NCCL的DEBUG输出发现通信时间站step总时长的比例异常高。最后用网络工具逐一验证才发现真相# 测试RDMA带宽 ib_write_bw -d mlx5_0 -i 1 # 测试RDMA延迟 ib_read_lat -d mlx5_0 -i 1 # 查看网卡统计关注丢包和CRC错误 ethtool -S enp8s0f0 | grep -E tx_dropped|rx_errors|rx_crc_errors # 查看RDMA资源状态 rdma resource showping不丢包但RDMA层面已经出了重传和CRC错误。根因是一对Leaf交换机间的哈希不均几个大流被挤进同一条上联链路拥塞时PFC的配置阈值又太高ECN还没来得及响应包先丢了。修复方案不外乎这几类调整PFC队列配置、调低ECN阈值、检查链路聚合的哈希方式是否均衡。改完之后跑了三轮all_reduce_perf做基线对比训练速度恢复到原来的95%以上。这个案例最值得说的不是修复动作而是排查链路先确认应用层无异常再看NCCL通信占比最后落到RDMA计数器和链路细节。没有这条清晰的打怪路径你只会被一堆不痛不痒的表象带偏。5.2 从单机8卡到多机集群的最小路径很多小团队是这么翻车的单机8卡调得好好的直接扩到两机16卡结果性能不升反降然后开始互相甩锅。我的建议是严格按照下面几步走第一步单机NVLink验证。先把nccl-tests的all_reduce_perf跑一遍确认单机内的通信带宽和延迟满足预期。这一步主要排除驱动、固件、NCCL版本这类底层问题。第二步加一台机器验证RoCE链路。两台机器之间先跑ib_write_bw和ib_read_lat确认RDMA能跑通、能跑满、延迟正常再把NCCL测试扩展到两机。你会发现很多问题在这一步就暴露了——比如网卡没有开启GDR或者PFC配置没对齐。第三步部署调度器时强制拓扑感知。把同一个TP组的卡尽量放在同一台或同机架机器里验证不同放置策略下的all_reduce_perf差异记录下来作为后续调度的基准。第四步加推理负载。引入PD分离和QoS队列把训练和推理隔开再压测TTFT/TPOT。每完成一步都保存一份网络基线和NCCL基线数据。以后每一次变更或者每一条可疑报警都先拿基线对比能省下大把深夜排查时间。5.3 重要但常被忽略的监控与团队分工最后再说两个容易被忽视但影响极大的点监控清单和团队分工。监控清单建议至少包含这几类指标类别关键指标说明GPUSM利用率、显存占用、温度不能只看利用率SM利用率更能反映计算饱和通信NCCL通信等待占比、AllReduce带宽直接用nccl-tests的perf结果做参考线网络RDMA丢包、CRC错误、PFC/ECN计数这类指标一出问题性能必崩ServingTTFT、TPOT、KV Cache余量按模型维度拆分看不要只看平均值团队分工方面我的体会是Infra平台团队至少要有一两个人对NCCL和RDMA有实际操作经验而不是把网络问题一股脑丢给传统网络团队。算法团队也要理解物理拓扑对并行策略的约束。两个团队之间要有一个共同的“变更管理”机制——网络策略改了、NCCL版本升了都要同步通知否则谁都查不出根因。这期Brief越往里聊我越觉得“AI原生网络”和“企业级LLM Serving”本质上是一件事的两面网络质量决定上游训练的效率和下游推理的延迟Serving架构的每一次演进又反过来给网络提出新的要求。我个人在实操中最大的体会是做AI Infra的人一定要养成存基线的习惯——每次网络变更、每次NCCL升级都先跑一轮all_reduce_perf存个档。我踩过太多次“明明没改什么”的锅最后发现就是基线没留无从对比。最后再分享一个小技巧把NCCL的调试日志和监控指标集中收集到一个地方每次报警直接把NCCL_DEBUGINFO输出和RDMA计数器拉出来比对能快速定位90%的通信类问题。这条我在好几个集群上反复验证过值得一试。