2026年开春AI圈子里讨论最密集的一个词变了不再是“又买了几千张卡”而是“AI Infra”。这词听起来像基础设施玩家的黑话但你只要真正跑过千卡训练或者在线上部署过大模型服务就会明白它有多关键。AI Infra 的内核不是堆卡而是让卡真正转起来的那一层AI 原生网络、存储、调度、LLM Serving。尤其是 AI 原生网络和企业级 LLM Serving这两块正成为拉开团队差距的分水岭。这篇文章我就围绕这两个方向把我最近半年在真实项目中踩过的坑、验证过的方案、梳理出的判断标准一次性讲透。适合正在做大模型训练或推理基础设施的工程团队也适合那些刚准备从单机实验走向集群部署的算法工程师参考。1. AI Infra 全景为什么“拼网络”比“堆卡”更决定下限1.1 AI Infra 到底包含什么AI Infra 这个概念外延很大但如果从工作负载视角拆开核心就四块算力池、存储池、网络池、服务化层。算力池是 GPU 集群本身存储池承担数据集、模型权重和 checkpoint 的读写网络池负责把这堆计算资源连接成一个整体而服务化层则把训练好的模型封装成稳定、高吞吐、低延迟的在线服务。很多人一上来就盯着算力池看实际上后三者的配置水平决定了集群在真实业务中的表现下限。我见过一个很典型的案例某个团队采购了同等规格的 GPUA 队用默认配置直接开跑B 队花了一周时间专门调网络和 serving 参数结果在同样的训练任务上B 队有效吞吐高出 A 队 30% 以上。这不是个别硬件差异而是网络拥塞控制、数据加载管线、Serving 框架参数的综合结果。AI Infra 的价值不是让某一块硬件跑满而是让所有环节的损耗降到最低。这四块之间的关系有点像城市的交通系统算力池就是各个功能片区存储池是仓库和物流中心网络池是道路与立交桥服务化层是面向市民的办事窗口。道路设计不合理片区再繁华也堵成一锅粥窗口服务跟不上再宽的马路也转化不成好体验。2026 年分布式训练动辄千卡万卡推理集群同时服务成百上千路并发请求网络和服务化已经不是配菜而是主菜。1.2 AI 原生网络到底“原生”在哪“AI 原生网络”这个词听起来像营销概念但背后有实打实的技术内涵。传统企业网络处理的是南北向流量为主、偶发东西向流量的 Web 业务特征是“尽力而为”丢包了 TCP 重传就好延迟偶发波动用户感知不明显。AI 负载则完全不同分布式训练里每个 step 都需要 GPU 之间做全局梯度同步这涉及密集的 all-to-all 通信任何一次丢包或拥塞都被无限放大要么拖慢集合通信要么直接触发超时导致训练中断。AI 原生网络要解决的核心矛盾就是“无损、低时延、高吞吐”三者兼得。具体来说它需要具备几个特征一是无损传输通过 RoCEv2 配合 PFC/ECN 机制避免丢包二是确定性低时延不能像传统网络那样频繁出现毫秒级抖动三是故障感知与快速切换交换机端口或者光模块出问题时能快速重路由而不是让整个训练 job 挂掉四是要与上层的调度器、通信库联动比如拓扑感知调度让通信量大的 job 尽量落在同一网络交换域内。用一个生活类比来解释传统网络像普通城市道路车多了就堵堵了就等没有谁为某辆货车担保时间AI 原生网络则更像专用的高速公路加智能红绿灯系统为每一次通信预留带宽、控制拥塞并且当某条车道出事故时自动引导车流绕行而不让我们察觉。这种“原生”不是换一台更高端的交换机就能得到的需要从网卡、交换机、通信库、调度器做端到端的协同设计。2. AI 原生网络的架构设计与关键决策2.1 拓扑与无损网络RoCE 不是装完就能用的先回答一个最基础的问题AI 集群用 InfiniBand 还是 RoCEv2如果预算充足、团队运维能力强InfiniBand 当然更省心它的无损机制是原生设计的。但现实中绝大多数企业会选 RoCEv2因为可以复用现有以太网生态成本相对可控。只是很多人以为“换上支持 RoCE 的网卡和交换机开启 PFC无损网络就搞定了”这其实是个大坑。RoCEv2 要真正跑出性能至少需要同时处理好 PFC 和 ECN 的关系。PFC 的作用是当接收端 buffer 快满时给发送端发暂停帧从物理上避免丢包但 PFC 是逐跳流控一旦触发范围过大会造成线头阻塞也就是某一条流把整个队列堵死其他流全部跟着遭殃。ECN 则是在交换机队列深度超过阈值时给报文打上标记接收端感知后通过 DCQCN 协议反馈给发送端让发送端主动降速。我的实践结论是ECN 为主PFC 作为最后兜底。让 ECN 标记阈值先介入通过主动降速避免队列打满这样既不会丢包也不会出现 PFC 引发的连锁阻塞。具体配置时要给不同优先级的队列设置差异化的 buffer 阈值建议从交换机 buffer 的 20% 到 50% 之间开始调观察 ECN 标记率和实际吞吐再做微调。这个参数没有标准答案取决于交换机型号、流量模型和 RDMA 网卡实现。2.2 集合通信优化与故障域设计网络层再稳如果集合通信库和网络拓扑不匹配性能也会大打折扣。分布式训练里最常用的集合通信操作是 AllReduce它的带宽利用率取决于通信算法怎么走环状 AllReduce 适合中小规模集群树状和分块式 AllReduce 适合大规模集群。更关键的是通信路径要尽量短。英伟达的 NCCL 引入了拓扑感知能力会自动识别 GPU 之间的 NVLink 连接、跨节点经过哪台交换机从而选择最优的通信路径。但在真实集群里拓扑感知并不是总能生效。我遇到过一个情况Kubernetes 调度 GPU 任务时没有把同一训练任务的所有 Pod 放在同一个网络 Pod 内导致 NCCL 检测出的拓扑是跨 spine 通信。虽然也能跑但 AllReduce 带宽比优化后低了接近一半。解决办法是让调度器感知网络拓扑尽量把同一个 job 的节点分配在同一叶交换机下跨叶通信实在躲不开时至少保证路径数少且均衡。故障域设计同样重要。千卡级训练节点故障其实是常态关键是故障的影响半径有多大。无状态的数据加载 worker 挂了可以自动重启但 AllReduce 过程中任何一张卡掉线整个 job 都可能崩溃。我们现在的做法是控制每个训练任务的计算节点数为最少必需的规模同时在作业调度层做“故障快速换卡”而不是等用户手动介入。此外把模型权重定期做轻量级 checkpoint 到分布式存储恢复时间可以控制在分钟级而不是小时级。2.3 可观测性从丢包计数到集群健康度AI 原生网络最容易被忽略的是可观测性。网络设备不像 GPU跑慢了不一定报警丢包也不会直接体现在 GPU 利用率上很多人发现网络问题时已经严重影响业务了。我的建议是至少要采集四类信号RoCE 拥塞窗口发送端主动降速的幅度、ECN 标记率交换机队列压力的早期预警、PFC 暂停帧计数无损网络是否在“兜底”、以及端到端的通信时延和吞吐曲线。这些数据不只是给网络工程师看的训练平台和推理平台都应该接入。举个例子如果检测到某个节点的 ECN 标记率持续偏高在用户还没察觉性能下降之前就可以提前排查是不是某条链路流量不均或某台交换机 buffer 配置过小。我们后来做了一套很简单的健康度打分把 GPU 利用率、通信时延、丢包率、ECN 标记率加权汇总成一个 0 到 100 的分值低于阈值就触发自动巡检。这套体系比单纯盯着 GPU 利用率有效得多。3. 企业级 LLM Serving 的关键指标与框架选择3.1 Serving 不是“起一个模型接口”那么简单很多团队从单机 PyTorch 代码迁到在线服务时最初都以为写个 FastAPI 接口把模型包一层就行。等并发一上来就发现显存爆了、首 token 延迟涨到几秒、吞吐低得离谱。企业级 LLM Serving 需要一套完整的组件来支撑高并发和低延迟请求网关负责流量接入和负载均衡推理引擎负责动态批处理、显存管理、量化计算调度层负责把不同请求分配到合适的 GPU 实例还有指标采集和弹性伸缩系统。其中比较核心的机制是连续批处理continuous batching它把每一个 token 的生成当作独立的调度单元而不是像传统批处理那样等整个序列生成完再释放显存。这样当一个请求的 decode 阶段还在等待生成时另一个请求的 prefill 阶段就可以插入进来填充 GPU 算力。连续批处理对吞吐的提升非常明显但它的实现复杂度也高不同的 Serving 框架在这里拉开差距。3.2 核心指标与 SLOTTFT、TPOT 与吞吐评价一个 LLM Serving 系统好不好不能只看“整体吞吐高不高”要看三个关键指标。第一个指标是 TTFT首 token 时延。用户发出请求到看到第一个 token 生成出来的时间。这个指标决定了交互的“第一印象”在线聊天场景下如果 TTFT 超过 2 秒用户明显会觉得卡顿。第二个指标是 TPOT每 token 生成时间也就是 decode 阶段的单 token 延迟。它决定了生成速度体验好的服务要控制在 40ms 到 100ms 以内。第三个指标是吞吐单位是 tokens/s衡量整个系统每秒能生成的 token 总量直接关联成本效率。这三个指标是互相制约的关系。盲目提升吞吐可能牺牲 TTFT 和 TPOT。我给一个比较实用的 SLO 设计思路先定义在线业务容忍的 P95 TTFT 和 TPOT然后反推单实例最大并发数再根据总请求量规划 GPU 数量。举个例子对于 200 路并发的客服机器人允许 P95 TTFT 为 1.5 秒、TPOT 为 50ms那么单张 A100 大约能支撑 20 到 30 路并发整个集群至少需要 8 到 10 张卡才能稳得住。先定 SLO再谈优化否则后面所有调优都会失去方向。3.3 Serving 框架选型对比vLLM、TensorRT-LLM 与 SGLang2026 年主流的开源 Serving 框架主要就几个vLLM、TensorRT-LLM、SGLang。它们是同一类东西但设计取向差异很大。vLLM 最大的优势是生态成熟、上手快。它的 PagedAttention 机制把显存利用率提得很高连续批处理实现也稳定还支持 OpenAI 兼容接口社区贡献了大量模型适配基本主流的开源模型都能直接跑。适合大多数团队的默认选择。TensorRT-LLM 强在极致延迟优化和量化支持。它由 NVIDIA 主导对自家 GPU 的特性挖得最深配合 FP8/INT4 量化能明显降低单 token 延迟。但代价是编译和部署流程复杂模型需要做 engine 构建动态形状处理也有不少坑。适合对延迟和吞吐要求极高、且愿意投入工程精力的团队。SGLang 的杀手锏是 RadixAttention它自动缓存请求中的公共前缀在多轮对话、few-shot 提示词复用的场景下可以跳过重复的 prefill 计算大幅降低 TTFT 和显存占用。如果你的业务大量存在相似前缀这套机制能带来意想不到的收益。选型没有绝对最优我的建议是默认用 vLLM跑通全部功能如果量化需求重再评估 TensorRT-LLM如果业务前缀复用特征明显考虑 SGLang。有时候同一集群里按业务类型混合用两个框架也是一个务实的方案。4. 从网络到 Serving 的协同优化PD 分离、缓存与弹性调度4.1 PD 分离架构与流量模型变化传统上LLM 推理把 prefill处理输入并生成第一个 token和 decode逐 token 生成放在同一个 GPU 上完成。这种做法实现简单但存在天然的资源错配prefill 是计算密集型特别消耗算力和显存带宽decode 是访存密集型主要瓶颈是显存带宽和 KV cache 的读写。两者混跑时prefill 的突发计算会拖慢 decode 期间的 token 生成导致用户体感变差。PD 分离就是把 prefill 和 decode 拆到不同的 GPU 实例上这也是 2026 年大规模 LLM Serving 的主流架构。prefill 实例专门负责快速吸收请求并生成完整的 KV cachedecode 实例负责持续的 token 生成。这个架构带来的直接收益是TTFT 更稳定TPOT 不再被突发 prefill 干扰调度也更灵活。但代价是网络中需要传输 KV cache 数据从 prefill 节点迁移到 decode 节点。这就回到网络了。KV cache 的传输量不是个小数目。粗略估算一下8K 上下文、每层 hidden size 为 8192、40 层的模型单个请求的 KV cache 大小在 8 × 8192 × 40 × 2K 和 V再乘以精度字节数大约是 2GB 级别的数据。如果一批并发请求同时从 prefill 节点涌向 decode 节点瞬间的流量会非常高。所以规划网络的带宽时不能只按 token 吞吐算要考虑 KV cache 迁移的峰值。4.2 KV cache、前缀缓存与长上下文的工程解法KV cache 不仅是 PD 分离的传输负担也是显存消耗的大头。长上下文场景下比如一次处理 128K token 的文档分析KV cache 可能占掉数 GB 显存直接挤占 batch size 的空间。工程上常见的解法有几个方向。一是前缀缓存。多轮对话里每轮请求都带有之前的历史消息这些消息对应的 KV cache 其实是可以复用的。SGLang 的 RadixAttention 就是把共享前缀做成树状缓存新请求只需要计算新增的那一小部分。在客服和 Agent 类场景中前缀缓存的收益非常明显有时能把 TTFT 降低一半以上。二是 KV cache 分层存储。把热点请求的 KV cache 放在 GPU 内部的高带宽显存中冷门前缀放到 CPU 内存甚至 SSD 上配合调度器做预取。这套思路类似传统的缓存体系但落到推理场景里需要处理显存和 CPU 内存之间的带宽瓶颈。三是请求亲和性调度。如果调度器能把共用同一前缀的请求调度到同一个 decode 实例上前缀缓存命中率会大幅上升。这要求网关或调度器感知每个实例上已经缓存的 KV 前缀而不是简单做轮询或随机分发。实施起来有一定复杂度但在高并发 Agent 场景回报很高。4.3 弹性调度与成本控制企业做推理服务成本压力始终在。弹性调度的目标很简单流量低时把算力缩下来流量高时及时扩出去。但在 GPU 集群里“弹性”比普通容器要难得多因为 GPU 资源冷启动时间长模型加载到显存需要几十秒到几分钟缩容也不是简单删 Pod 就完事。我的经验是两个层面同时抓。一个是预测式扩缩容根据历史流量曲线在晚高峰之前就把推理实例扩容好提前预热模型在低谷期用 CronJob 或自定义控制器把多余的实例回收拆给训练任务。另一个是训练与推理混部时要注意隔离。训练任务里的 AllReduce 是突发的、海量的通信推理任务里的 PD 分离流量是持续的、时延敏感的两者必须放在不同的网络租户或 QoS 队列里否则训练在跑数据同步时会直接把推理的尾延迟打崩。我们做过的验证是给推理流量单独划分一个网络切片设置更高的优先级并限制带宽上限即使集群同时跑着千卡训练推理 P95 TTFT 依然稳定。这个优先级配置在网络设备上只是几行 QoS 命令但对业务稳定的价值巨大。5. 常见问题与排查实录5.1 问题速查表现象、可能原因与检查点现象可能原因检查点TTFT 频繁飙到 2s 以上prefill 实例过载、前缀缓存命中率低、队列堆积查看请求队列深度、prefill GPU 利用率、缓存命中率TPOT 波动明显decode 实例显存带宽饱和、KV cache 换入换出频繁检查 decode 实例的显存带宽指标、KV cache 命中率训练 AllReduce 变慢ECN 标记率过高、DCQCN 降速、网络路径不均查看交换机 ECN 计数、RoCE 拥塞窗口曲线偶发通信超时PFC 风暴、交换机丢包、光模块故障检查 PFC 暂停帧计数、丢包统计、光模块告警大规模训练频繁中断单节点故障触发 AllReduce 全局失败检查节点心跳、故障卡片日志、checkpoint 恢复点5.2 实战案例TTFT 突增不一定是 GPU 的问题我们曾经遇到一个很典型的排障经历。线上客服机器人的 P95 TTFT 从平时的 500ms 突增到 2.5s一开始所有人的第一反应都是 GPU 资源不够准备临时扩容。但我打开指标看了一眼GPU 利用率并不高反而是请求队列的深度一直在涨。继续查发现导致排队的原因不是算力而是 prefill 实例处理得慢。进一步排查发现当时集群里还有另一个业务在做批量离线批量推理任务把大量短小请求打到了同一组 prefill 实例上批量离线任务的请求和线上实时请求混在一起每个实时请求的前置排队时间被拉长了。把离线任务迁到独立实例后TTFT 立刻恢复到正常水平。这件事给我的教训是推理服务的问题先看排队再看算力最后才看网络排查顺序弄反了会浪费大量时间。5.3 实战案例ECN 标记率为什么能拖垮训练另一个印象深刻的案例是千卡训练集群性能只有平时的 70%。所有 GPU 利用率都很高NCCL 的 AllReduce 带宽却明显低于预期。起初怀疑是网线或光模块有问题花了半天排查物理层一无所获。后来从交换机的 Telemetry 数据里看到某个 spine 交换机对应端口的 ECN 标记率持续高达 8% 以上触发 DCQCN 持续降速。问题根源是当时批量调度了一批训练 job多个 job 的通信流量都集中经过同一台 spine 交换机且流量是突发的交换机 buffer 根本兜不住。我们调整了作业调度策略把多个大 job 分散到不同的网络域同时调大了交换机的动态 buffer 阈值。第二天训练性能就恢复了。这类问题的教训是网络拥塞并不总是表现为丢包也可能是“标记后降速”这种隐性性能杀手必须靠 ECN 指标才能捕捉到。我个人这两年做 AI Infra 最深的体会是这个方向的复杂度不在单个组件而在端到端的协同。网络、存储、调度、Serving 每一层都有大量参数任何一个环节不匹配都会让整个集群的表现大打折扣。建议刚开始搭建的同学不要急着把集群规模拉得太大先拿一个小规模集群比如 16 到 32 卡把 RoCE 无损参数调稳、把 Serving 的指标监控接好、把训练和推理的网络隔离做好跑熟之后再往大规模扩展。如果你已经在大集群上踩过坑欢迎交流各自是怎么定位和排除隐性瓶颈的。