1. AI Infra 这个圈子里最近都在卷什么先说结论AI InfraAI 基础设施这两年已经从“给机器学习跑个训练脚本”这种小打小闹变成了一个横跨硬件、网络、调度、推理引擎的系统工程。你光有 GPU 已经不够了还得让 GPU 之间、GPU 与存储之间、训练任务与推理服务之间的数据流动足够快、足够稳这背后就是AI 原生网络和企业级 LLM Serving这两个热词的主战场。简单说AI Infra 解决的是三件事算力怎么组织、数据怎么流动、模型怎么高效地对外服务。算力组织是集群调度平台的事情数据流动是网络的事情而对外服务就是把训练好的大模型跑起来以 API 或者其他形式稳定地响应业务请求——这就是 LLM Serving。今天这篇主要聊聊后面两件事尤其是它们之间的联动关系。这篇内容适合谁看如果你正在搭 GPU 集群、负责推理服务的性能优化、或者准备把大模型接入生产环境那这篇文章基本就是照着你的日常工作痛点写的。哪怕你目前只是做应用开发也想了解一下“为什么一个简单的大模型接口到了高并发下延迟会飙得离谱”那这篇也能给你一个全景式的答案。我自己在过去的项目里踩过不少坑网络配置不对导致训练效率直接腰斩、推理服务在流量高峰时批量策略没调好导致 GPU 利用率上不去、跨机张量并行的时候通信开销吃掉了一大截收益……这些都是文档里很少写清楚的细节。今天一次性把这些经验拆开讲。2. AI 原生网络为什么 AI 集群不能直接用传统数据中心网络2.1 传统网络“尽力而为”的模型在 AI 场景下撑不住传统数据中心网络的设计目标是通用性网页请求、视频流、数据库事务、虚拟机迁移同时跑在一张网上流量模型五花八门网络设备只需要做到“尽力而为”的转发就行丢包了靠 TCP 重传延迟高一点也能接受毕竟应用层大多不敏感。但 AI 训练和推理的流量特征完全不一样。大模型训练用的是all-reduce这类集合通信模式每算完一小步几千张卡就得把梯度全部同步一遍。这个模式对网络的要求极其苛刻一是大流量突发——所有 GPU 同时往外发数据瞬间把带宽打满二是对丢包零容忍——一个包丢了整个集合通信就得等重传而这个等待造成的延迟是全集群同步叠加的几百微秒的延迟波动会被放大成秒级的训练停滞。我打个比方你就懂了传统网络像一条双向八车道的城市主干道什么车都跑堵车了大家就等一下最多晚几分钟到。AI 网络则是工厂里的传送带所有工位必须同步运转某一个环节慢半拍整条流水线就得停下来等。所以 AI 原生网络的设计目标不是“尽力而为”而是确定性——让每一次通信都在可预期的时间内完成不丢包、不乱序、延迟极低。2.2 RDMA 与无损网络AI 网络的基石为了实现这种确定性传输AI 集群普遍引入RDMARemote Direct Memory Access技术。RDMA 的核心思想是绕过 CPU 和操作系统内核让网卡直接读写远端内存。传统 TCP 通信中数据要经过“应用→内核→网卡→网络→网卡→内核→应用”的漫长路径数据拷贝好几次CPU 还得参与协议处理而 RDMA 借助硬件卸载数据从一台机器的 GPU 显存直接传输到另一台机器的 GPU 显存延迟能压到微秒级CPU 几乎不参与。RDMA 有三种主流实现InfiniBand专用网络性能最好但成本高典型的有 NVIDIA 的 Quantum 系列交换机、RoCEv2跑在以太网上的 RDMA成本和性能均衡是目前绝大多数 AI 集群的选择、以及 iWARP性能一般基本没在 AI 场景落地。这里必须多说一句 RoCE 的“痛点”它依赖以太网而传统以太网是会丢包的。为了让 RoCE 跑得稳网络必须改造成无损以太网。所谓无损核心机制是PFCPriority Flow Control优先级流量控制——当接收端的缓冲区快满时会向发送端发暂停帧让发送端暂时别发防止数据丢失。同时还有ECNExplicit Congestion Notification显式拥塞通知 DCQCN数据中心量化拥塞通知这套机制让发送端动态调整发送速率避免网络拥塞。我实际配置过几个 RoCE 集群最大的体会就是PFC 是保底方案但不能依赖它当主要流量控制手段。如果拥塞控制没调好PFC 会不停触发结果就是“拥塞蔓延”——一个端口的暂停帧可能引发连锁反应整个网络吞吐骤降。很多团队以为把网卡配成 RDMA 模式就完事了结果训练一跑起来性能远低于预期查了半天才发现是 DCQCN 参数没调对。这个后面在问题排查章节细说。2.3 AI 集群组网拓扑从 Fat-Tree 到 Rail-Optimized有了 RDMA 和无损网络组网拓扑也得为 AI 流量重新设计。传统数据中心用Spine-Leaf脊叶架构或者Fat-Tree胖树目标是任意两点之间带宽均衡、故障冗余好。但 AI 集群的流量不是任意的它有明确的“流向偏好”同一个 GPU 服务器内部的 8 张卡先通信NVLink/NVSwitch 搞定然后跨服务器的通信遵循某种固定的集合通信算法模式。这时候就出现了Rail-Optimized轨道优化拓扑——把分布在多台服务器上的同一位置的 GPU 连到同一个交换机上形成一个“rail”。比如 8 台服务器组成一个集群每台服务器有 8 张 GPU那么所有服务器的第 3 号 GPU 就连接到同一台交换机第 3 号 GPU 之间的跨机通信全部走这台上联交换机不绕路。这样集合通信的流量模式与物理拓扑完全对齐一跳到达延迟最低。实际部署中绝大多数团队没有条件自建大规模专用集群用的都是云厂商的裸金属 GPU 实例或者托管集群。云厂商的物理网络通常是 Spine-Leaf 结构但对上层做了一定程度的拓扑感知或者提供Elastic Fabric AdapterEFA这类特殊网卡来优化 RDMA 路径。所以在公有云上做 AI Infra核心是学会利用云平台提供的网络加速能力而不是自己折腾物理交换机。3. 企业级 LLM Serving把大模型跑成稳定服务有多难3.1 LLM 推理为什么和传统推理不一样传统深度学习推理比如图片分类、目标检测输入输出都是固定尺寸的向量计算模式是一次前向传播延迟可以控制在几十毫秒内批量处理也很容易。但大语言模型的推理是一个自回归autoregressive过程每生成一个 token都要把之前的 token 重新塞进模型算一遍也就是“一次请求多次前向”。这个特性带来两个致命的问题KV Cache 的显存消耗每个请求的中间计算结果Key 和 Value都要缓存下来随着生成长度线性增长。一个 70B 参数模型如果并发请求多、生成长度大KV Cache 可能吃掉比模型权重还要多的显存。Prefill 和 Decode 的计算特征差异极大处理输入阶段Prefill是计算密集GPU 利用率可以打满矩阵乘法生成阶段Decode则是内存带宽密集因为每个 token 只做一次小规模矩阵运算GPU 算力大量闲置瓶颈在显存带宽和 KV Cache 的读取速度。这就解释了为什么很多团队在部署 LLM 服务时会发现一个奇怪的现场GPU 利用率看着很高但每秒处理的请求数却很低。因为 Decode 阶段的大多数线程其实在等 KV Cache 从显存搬到计算单元的路上计算的空闲时间被“看起来忙碌”掩盖了。3.2 主流 LLM Serving 引擎对比与选型现在企业界最常用的开源推理引擎有vLLM、SGLang、TensorRT-LLM商业方案有 NVIDIA NIM 等。我按照实际使用体验列个对比引擎核心技术亮点适合场景不擅长的地方vLLMPagedAttention 显存管理Continuous Batching 连续批处理通用开源首选社区活跃部署简单复杂多模态支持弱于 TensorRT-LLMSGLangRadixAttention 前缀缓存更灵活的调度控制OpenAI 兼容 API 做得好高并发、长上下文、结构化输出相对年轻周边生态还在长TensorRT-LLMNVIDIA 深度优化的 TensorRT 内核精度和性能天花板高需要极限压榨单卡性能、量化部署配置复杂模型编译时间长调参门槛高我自己在不同项目里三个都用过说点真实体会vLLM 是零到一最快的选择pip install 之后基本能跑PagedAttention 对显存的节省非常显著长上下文场景下能把 OOM 的概率降低一个数量级。SGLang 在需要打磨延迟表现的时候值得切过去它的 RadixAttention 对多轮对话场景的命中率提升立竿见影实测相同模型和负载下P99 延迟能比 vLLM 低 20% 到 30%。TensorRT-LLM 我只建议在固定模型、长期不换版本、追求极致吞吐的生产环境用毕竟每次换模型都要重新编译优化迭代效率是个问题。3.3 分布式 Serving单机放不下模型怎么办当模型大到单张 80G 显存放不下参数量超过 70B即使 FP16 也要 140G 以上显存或者并发需求太高压垮了单节点就需要把模型切到多张卡甚至多台机器上。这就有两条路张量并行Tensor ParallelismTP——把模型的每一层权重拆到多张卡上每张卡只计算自己负责的那部分矩阵乘法然后通信合并结果。这个方案通信量大每层都要做两次 all-reduce所以 TP 最好只在单机 NVLink 互联范围内做跨机做 TP 会因为通信延迟把推理速度拖垮。流水线并行Pipeline ParallelismPP——把模型按层切成几段不同的卡负责不同层段。这个方案通信量小但会引入流水线气泡bubble问题GPU 利用率打不满。生产上结合 PP 和 TP 的混合并行是标配即机内用 TP机间用 PP。这里有个关键点很多人忽略企业在大部分场景下不需要分布式 Serving。因为中等规模的模型7B、13B、甚至 70B 量化后单机就能跑分布式 Serving 引入的复杂度和故障面远大于收益。我见过一个项目为了“架构先进”上了 8 卡 TP结果模型只有 13B通讯开销让延迟比单卡跑还差。先算清楚显存再谈并行这是铁律。4. AI 原生网络与 LLM Serving 的联动优化4.1 网络决定了 Serving 集群的“吞吐天花板”很多人把 LLM Serving 的优化焦点放在引擎参数上忽略了网络这一层。实际上一旦进入多节点 Serving 集群网络就是吞吐量的隐形天花板。举个实际例子你部署了一个 8 节点的推理集群每个节点 8 卡用 TP8 跑 70B 模型这意味着一个请求的推理计算要横跨 8 个节点、每层都要经过网络做通信。这时候每个请求的耗时由两部分组成计算时间 网络通信时间。如果网络带宽不够或者拥塞控制不生效通信时间可能占到总延迟的 40% 以上——你换再快的 GPU 都没用。另外Serving 集群的流量模型和训练集群不一样。训练是同步的、有规律的集合通信而 Serving 的通信是离散的、异步的来自不同请求的数据包在网络里互相穿插更容易造成微突发microburst。处理微突发恰恰是无损网络的难点普通交换机缓冲区很快被打满PFC 连环触发延迟抖动直接体现到用户可感知的 P99 延迟上。所以我在做企业级 LLM Serving 方案时会要求网络团队提供PFC 触发次数、ECN 标记率、丢包率三个指标任何一个异常都优先于应用层去排查。这三个指标正常了推理服务的延迟曲线才可能平稳。4.2 推理引擎与网络参数怎么协同调具体到参数层面有几组联动关系值得背下来动态批处理Continuous Batching的 batch size 越大显存压力越大但对网络带宽的需求不变模型参数还是要同步因此大 batch 会使通信占比下降延迟效率更高。这就是为什么企业生产环境倾向于拉大 batch 来冲吞吐而不是无限堆并发请求。TP 度数越高网络通信量越大。TP 度数 × 模型规模基本决定了交换机带宽需求。一个粗略的经验公式8 节点 TP8 跑 70B 模型单次推理的通信量大约在几百 MB 到 1GB 级别取决于上下文长度千兆网络根本跑不动至少需要 100Gbps 的 RDMA 网络并尽量让 TP 组内的节点落在同一个 leaf 交换机下面。上下文长度context length越长KV Cache 越大响应变慢。如果你服务的是多轮对话业务建议对 max_tokens 做限制并且用 SGLang 的前缀缓存命中来避免重复计算长上下文。4.3 一个实际部署方案的参数参考下面是我搭建一个 GPT 类 13B 模型 Serving 集群的实际配置给大家一个可以直接抄的参考模型规模13BFP16约 26GB 权重 8GB KV Cache / 请求 GPU 配置8 × A100 80G单机 8 卡 NVLink 互联 引擎选型vLLMv0.6 并行策略单机 TP8不上跨机并行 网络需求单机内部 NVLink 600GB/s跨机不参与推理通信 启动参数 tensor-parallel-size8 max-model-len8192 gpu-memory-utilization0.9给 KV Cache 预留到 90% 显存 max-num-seqs256动态批处理的并发上限 enable-prefix-cachingtrue启用前缀缓存这个配置下实测单请求的首 token 延迟在 120ms 左右不含排队稳定吞吐约 1500 tokens/s 左右也就是每秒能生成约 1500 个 token换算成一次 500 token 的回复大约每秒处理 3 个并发请求。如果你需要把吞吐再往上推我会把模型量化到 INT8吞吐可能再提升 20% 到 30%但需要接受一点精度损失。有人会问为什么不上跨机的张量并行把模型切到多个节点来支持更大的并发答案很简单——13B 模型单机完全够用跨机带来的网络通信延迟反而会拉低首 token 延迟。在 Serving 场景下单机能解决的问题不要轻易跨机这是我在多个生产项目里反复验证过的原则。5. 常见问题与排查技巧实录5.1 网络层RoCE 集群的性能黑洞问题一训练/推理任务一跑网络的丢包率开始飙升。排查思路先看是不是 PFC 风暴。PFC 风暴的典型症状是某个端口持续收到暂停帧网络吞吐骤降但交换机 CPU 利用率正常。解决办法是检查 DCQCN 相关参数——重点是alpha 值拥塞窗口减少的比例和rtt 因子拥塞反馈的响应时间。默认值在很多厂商的设备上偏保守导致拥塞反应过度。我通常会把 alpha 的初始值调大一点比如 0.5 而不是默认的 0.1让发送端对拥塞的响应更平缓。另外务必开启ECN 显式拥塞通知让接收端把拥塞信息反馈给发送端而不是直接丢包。很多团队的交换机上 ECN 默认是关闭的这一步没做后面的 RDMA 优化全白搭。问题二跨机通信延迟波动大训练步时间不稳定。这类问题多数是网络拓扑没有做到 “rail-aware” 调度。如果你用的是云上裸金属尽量让同一个分布式训练任务的所有 GPU 实例落在同一个“高带宽域”内。如果自建集群用上面说的 Rail-Optimized 拓扑并且把集合通信的通信组communicator顺序与物理拓扑对应起来。5.2 Serving 层延迟与吞吐的经典矛盾问题一GPU 利用率很高但 QPS 上不去。这个前面提到过——Decode 阶段是内存带宽密集不是算力密集。解决办法不是加卡而是优化批量策略。把 max-num-seqs 调大让更多请求挤进动态批处理复用内存带宽。我见过一个项目把 max-num-seqs 从 64 调到 256 之后QPS 直接翻了 2.5 倍GPU 利用率从 30% 升到 70%。问题二长上下文请求把显存打爆。这是 KV Cache 管理问题。第一开启 PagedAttentionvLLM 默认或者 RadixAttentionSGLang 默认来减少显存碎片第二对 max-model-len 做硬限制不要无限放大第三如果业务确实需要长上下文考虑 KV Cache 量化或者离屏缓存offloading但后者会显著增加延迟不建议频繁启用。问题三并发升高后响应时间抖动剧烈。首先排查排队延迟——引擎的调度器是否在 batch 满的时候把新请求挂起。通常你需要把max-num-seqs和max-waiting-tokens配合调整不要让请求无限排队。其次检查是否是网络微突发导致通信延迟升高——回到前面的指标PFC 触发次数、ECN 标记率。5.3 排查工具箱最后分享几个我常用的命令和工具都是命令行直接能用的# 查看 RDMA 网卡状态 rdma link show # 测试 RoCE 网络带宽需要安装 perftest 包 ib_write_bw -d mlx5_0 --report_gbits # 查看交换机端口 PFC 计数NVIDIA/Mellanox 交换机 show interface priority-flow-control # 查看 GPU 显存和利用率 nvidia-smi -l 1 # vLLM/SGLang 的监控指标用 Prometheus 抓取 /metrics 端点如果ib_write_bw测试的带宽远低于预期比如 100G 网卡只跑到 40G基本可以断定是流控参数问题优先检查 DCQCN 和 PFC 配置不要先怀疑硬件。写在最后的一点心里话做 AI Infra 这几年最大的感悟是这个领域的坑往往是跨层的——你以为在优化模型性能后来发现瓶颈在网络你以为在调网络参数最后发现是推理引擎的调度策略导致的流量模型不好。所以我现在的习惯是任何性能问题都从三个层面同时看GPU 利用率、网络核心指标、推理引擎的排队和批处理状态三者对齐了才能定位问题。最后再分享一个小技巧把网络监控指标接入你现有的可观测性系统和推理服务的延迟、吞吐日志放在同一个 dashboard 里。很多团队的监控体系里网络归网络、应用归应用出了事两边互相甩锅。合在一起之后你大概率会发现不少“应用性能问题”的真相在网络上。这个改动成本不高但排查效率能提升一个量级。做 Infra 的人最重要的是建立端到端的视图而不是局限于自己的那一亩三分地。