Google Cloud 7 月 AI 基础设施更新：托管 Lustre 与 C4N 落地

Google Cloud 7 月 AI 基础设施更新：托管 Lustre 与 C4N 落地

在智能体时代，AI 正在从"回答问题"走向"推理并采取行动"，对基础设施的要求也随之改变。Google Cloud 在 7 月密集发布了多轮 AI 基础设施与编排更新，覆盖高性能存储、网络优化计算、大规模集群编排和 AI 供应链安全。对正在规划服务器选型或迁移 AI 工作负载的团队，这些变化直接影响架构决策与成本结构。

高性能存储：Managed Lustre 正式可用

Google Cloud Managed Lustre 本月正式 GA，提供四个性能档位，每 TiB 容量吞吐分别为 125 MB/s、250 MB/s、500 MB/s 和 1000 MB/s，单集群可扩展到 8 PB 存储容量。它基于 DDN 的 EXAScaler 构建，把 DDN 在 HPC 存储领域的积累与 Google Cloud 的云基础设施能力结合起来。对需要高吞吐、低延迟并行文件系统的大模型训练与推理场景，这是一个值得关注的选项。

四个档位放在一起对比，便于按训练集规模与吞吐需求做初步选型：

选档位时不要只看峰值吞吐，更实用的做法是先估带宽需求：把训练集大小除以目标训练窗口，得到"至少多快的读带宽"，再留出 2-3 倍余量给 checkpoint 写入与数据混洗。比如 40 TB 训练集要在 6 小时内跑完一轮 epoch，平均读带宽约 1.9 GB/s，用 500 MB/s 档位就至少需要约 4 TiB 容量才能撑起带宽，而不是"买 1 TiB 最便宜的试试看"。

参考：Google Cloud Managed Lustre 官方文档 https://cloud.google.com/managed-lustre

网络与存储优化：C4N 实例 GA

C4N 是 Google Cloud 首个网络和块存储优化型 Compute Engine 实例，基于第五代 Intel Xeon 可扩展处理器和自研 Titanium 卸载架构，提供最高 400 Gbps 网络带宽、95 MPPS 包处理能力，配合 Hyperdisk Extreme 最高可达 25 GiB/s 块存储吞吐和近 1M IOPS。它的定位是消除 I/O 瓶颈，特别适合虚拟网络设备、大规模数据分析、电信应用与 CPU 型 AI/ML 负载，细节可以参考我们此前的C4N 详解。

与上一代通用型 C4 对比，C4N 的网络与存储指标几乎翻倍：

需要注意的是，这些上限要实例规格、Hyperdisk 类型与可用区三者匹配才能拿到。比如想跑满 25 GiB/s，就得把 Hyperdisk Extreme 与 C4N 放在同一个可用区并预留足量的 vCPU 配额，否则实际吞吐会被虚拟机规格卡住。

参考：C4N 机器类型说明 https://cloud.google.com/compute/docs/general-purpose-machines#c4n

集群编排：更大规模与更高利用率

编排层同样有明显进展。GKE Dataplane V2 现已支持标准集群扩展到 15,000 节点并保持完整网络策略强制执行，满足大型企业与 AI/ML 客户的海量基础设施需求。针对强化学习负载，llm-d 引入协作式时间切片，可以把独立 RL 任务交错到共享物理硬件上，把加速器总占空比从约 40% 基线提升到 70%，同时不影响模型收敛与精度——这对算力紧张、追求成本控制的团队尤其实用。

AI 供应链安全：k8s-aibom 开源

Google Cloud 开源了 k8s-aibom，一个轻量、无特权权限的 Kubernetes 控制器，持续监控容器集群，自动检测正在运行的 AI 运行时（如 vLLM、Triton），并生成标准的 CycloneDX 机器学习物料清单（ML-BOM）。它可以帮助团队保障 AI 工作负载安全、减少影子 AI 风险，并自动化 AI 供应链的可观测性。

前沿模型与加速器生态

Google Cloud 在模型与加速器层面也动作不断：7 月 27 日宣布对 Moonshot AI 的 Kimi K3（2.8 万亿参数开源权重模型）提供 Day 0 支持，权重发布当天即可在 Model Garden、自定义编排或 GKE 上评估与试点；工程团队还在 Ironwood（TPU v7x）上优化了 Mistral 3 Large 的 MoE 推理，通过混合分片、树形归约与异步调度实现约 1.5 倍性能提升、吞吐最高提升 48%。

一个具体的迁移案例

假设你的团队在 GKE 上微调一个 700 亿参数的 MoE 模型，训练数据放在普通 zonal SSD 上。一开始 GPU 利用率只有 55%，问题出在数据加载：训练读与 checkpoint 写共用同一块盘，I/O 排队把训练拖慢了。

把训练数据迁到 Managed Lustre 的 250 MB/s 档位、checkpoint 单独走 1000 MB/s 档位后，读写不再互相抢占，GPU 利用率升到 80% 以上，单轮训练时间缩短约三分之一。这个案例想说明的是：AI 存储选型的关键不是"买最贵"，而是把读、写、缓存三类流量拆开，各自匹配档位——这也正是 Cloud Storage FUSE 之类方案在特定场景下仍有价值的原因。

对选型的影响

综合来看，7 月更新的关键词是"为 AI 工作负载做减法"：用专用存储、专用网络和更高效的编排，减少数据搬运与算力闲置。如果你的团队正在部署 AI 模型或运行大规模数据管道，建议把 C4N、Managed Lustre 与 GKE 的大规模能力放进同一个评估清单，结合自身负载特征做一轮成本与性能测算，再决定迁移节奏。

原文来源：https://cloud.google.com/blog/topics/ai-infrastructure/whats-new-in-ai-infrastructure-this-month

16IDC 观察

Google Cloud 这轮更新延续了云厂商"AI 基础设施军备竞赛"的路径，但方向更务实：不是堆更多 GPU，而是把存储、网络、编排的每一层都针对 AI 负载重新设计。对中小团队来说，这类能力往往"用得上但不是标配"，关键是要看清自己的负载是否真的卡在 I/O 或利用率上，避免为用不上的高端特性买单。