云原生 AI 的下一个战场：不是 GPU，是网络和存储
一、GPU 不再是唯一瓶颈：网络和存储正在成为新的木桶短板
2026 年的 AI 基础设施讨论，80% 的注意力还在 GPU 上——H200 还是 B200、SXM 还是 PCIe、NVL72 机柜的互联拓扑。但生产环境的实际数据正在揭示另一个事实：当 GPU 的计算能力以每年 2-4 倍的速度增长，网络和存储的带宽增长是线性的，这个剪刀差正在让网络和存储成为新的瓶颈。
一组实际数据能说明问题。GPT-5.2 级别的模型训练需要 10 万张以上的 GPU 全互联，每张 GPU 的梯度同步带宽需求约 50GB/s。如果网络只能提供 10GB/s，梯度同步就占据了 80% 的训练时间——GPU 不是在计算，而是在等待。存储侧同样严峻：一个 15TB 的模型 checkpoint 写入 100GB/s 的存储集群需要 150 秒，而训练迭代间隔可能只有 30 秒——checkpoint 保存正在成为训练暂停的罪魁祸首。
这不是未来的问题，这是现在就在发生的事情。Meta 的 24000 GPU 训练集群中，网络拥塞导致的 GPU 空闲时间占比在高峰期超过 35%。Google 的 TPUv5p 集群中，数据加载管线的 I/O 延迟贡献了 15% 的端到端训练时间。云的 GPU 集群因为有成熟的网络和存储基础设施加持，这个问题没那么严重，但对于自建 AI 基础设施的企业来说，GPU 买回来只是第一步。
二、AI 网络的特殊需求：东西向流量的极端形态
传统数据中心的网络设计（Spine-Leaf、Clos）对 Web 服务的东西向流量已经优化得很成熟。但 AI 工作负载的网络模式是另一个物种。
AI 网络有三个与传统流量完全不同的特征。第一，流量的突发性极强——AllReduce 操作在毫秒级内将网络带宽拉到上限，然后瞬间归零，如此循环。这对交换机的缓冲区管理和拥塞控制协议（DCQCN、Swift）提出了极端要求。第二，流量模式是完全对称的——每个 GPU 发送和接收的数据量完全相等，传统网络中"上行:下行 = 3:1"的假设不适用。第三，对丢包零容忍——一个 TCP 重传在网络层可能只增加 1ms 延迟，但对于同步梯度通信来说，最慢的一个 GPU 决定了整体速度——一个重传可能导致整个 AllReduce 操作延迟翻倍。
技术栈的选择也因此需要重新审视。RoCEv2（RDMA over Converged Ethernet）正在成为 AI 训练网络的事实标准，因为它提供了 GPU 到 GPU 的直接内存访问，消除了 TCP/IP 协议栈的软件开销。但在大规模部署中，RoCE 的无损网络要求（PFC、ECN）会引入新的问题——PFC 死锁（PFC Deadlock）和 PFC 风暴可以瞬间让整个集群的网络瘫痪。2026 年，Ultra Ethernet Consortium 正在推动的 UET（Ultra Ethernet Transport）协议试图从协议层解决这个问题——用端到端的拥塞控制替代交换机端的 PFC，从根本上消除死锁风险。
三、AI 存储的三个层次与各自挑战
AI 工作负载的存储需求可以清晰分为三个层次，每个层次的技术要求截然不同。
训练数据存储（容量层）：多 PB 级的文本、图像、视频数据，需要高吞吐的顺序读。这里的主要矛盾不是延迟，而是带宽和成本。AWS S3 的带宽上限是 100GB/s，对于 10 万卡级别的训练，这个带宽严重不足。解决方案通常是在计算集群旁边放置一个本地的分布式缓存层（Alluxio、JuiceFS），做数据的预取和缓存。
Checkpoint 存储（可靠性层）：一个 10 万卡集群的训练 Checkpoint 可能在 10TB-50TB 级别，写入带宽需求 200GB/s+。分布式文件系统（Lustre、GPFS/Storage Scale）是目前的主流选择，但扩展性和维护成本非常高。2026 年的新趋势是使用对象存储 + 并行写入（通过 S3 Express One Zone 或类似方案），牺牲一部分写入延迟换取无上限的扩展性。
推理 KV Cache 存储（延迟层）：推理场景中，KV Cache 的重用可以避免重复的 Prefill 计算。但 KV Cache 的读写延迟必须在微秒级——任何毫秒级的延迟都会直接影响用户的端到端延迟。分布式共享内存（如 InfiniBand + GPU Direct Storage）是目前的最优解，但成本极高。一些团队在尝试用本地 NVMe + RDMA 的组合方案，把 KV Cache 存储在推理节点的本地 NVMe 上，通过 RDMA 让其他节点远程读取——这比全分布式共享内存便宜，但增加了网络拓扑的复杂性。
四、对云原生工程师的直接影响
网络和存储成为瓶颈，意味着云原生工程师不能再把"网络就是 K8s CNI、存储就是 PVC"当作全部认知。
网络侧，理解 RDMA 和 GPU Direct 的基本原理——不是要成为网络工程师，而是要做调度决策时知道"这些 GPU 放到同一个 NVSwitch 域内还是跨域"对训练性能有多大影响。CNI 插件（Calico、Cilium）在 AI 场景中会遇到新的问题——Gang Scheduling 的 Pod 同时启动要求网络就绪时间同步，传统 CNI 的逐个 Pod 分配 IP 的模式可能成为瓶颈。
存储侧，了解 AI 训练数据的缓存策略——什么时候需要数据预取层，什么时候对象存储直读就够了。PVC 的 ReadWriteMany vs. ReadWriteOnce 在分布式训练中的实际影响是什么。Checkpoint 的频率和存储介质之间怎么 trade-off。
这不是"多学一点"的建议，而是"不学这些，调度器就会做出错误的决策"的现实。一个把 4 个分布式训练 Pod 调度到跨 NVSwitch 域节点上的调度器，和"调度失败"相比，前者更危险——因为它看起来"成功了"，实际性能大打折扣。
五、总结
云原生 AI 的下一个战场不在 GPU 厂商的发布会上，在网络交换机的缓冲区里和存储集群的 I/O 栈中。三个正在发生的变化值得关注。网络侧，RoCE 从实验走向大规模部署，UET 协议试图解决 PFC 死锁这一工程噩梦。存储侧，分层缓存架构（本地 SSD -> 分布式缓存 -> 对象存储）成为 AI 训练的标配，Checkpoint 的写入性能成为训练效率的隐形瓶颈。调度侧，网络拓扑和存储亲和性正在成为比 CPU/内存更重要的调度维度。
对云原生工程师而言，2026-2027 年的核心竞争力不再只是"会用 K8s API"，而是理解这些 API 之下的物理资源——GPU 的 NVLink 拓扑、交换机的 buffer 深度、存储集群的 stripe 大小。基础设施不需要漂亮话，但需要理解每一层木桶的短板在哪里。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0730 资料来源索引，并在发布前将具体来源贴到对应断言之后。
