2026 年 5 月至 7 月，Google Cloud 的 AI 基础设施更新呈现出一个清晰趋势：竞争重点已经从“能不能运行模型”转向“能否在大规模、低延迟、可观测且可控成本的条件下持续运行模型和智能体”。
这组更新覆盖存储、网络、TPU/GPU 编排、推理网关、AI 供应链安全以及智能体运行时。它们共同指向一个现实问题：Agentic AI 不只是调用一次模型 API，而是会持续推理、访问工具、读取数据并执行动作，因此对集群密度、冷启动、网络策略和故障恢复提出了更高要求。
变化一：基础设施瓶颈从算力扩展到数据通路
模型训练和推理的瓶颈并不总在 GPU 或 TPU。模型权重、KV cache、训练样本、检查点和工具上下文都需要在计算节点与存储系统之间高效移动。
7 月 GA 的 Managed Lustre 提供四档吞吐能力：每 TiB 容量对应 125 MB/s、250 MB/s、500 MB/s 或 1000 MB/s，并可扩展到 8 PB。它适合需要高并行文件访问的训练、检查点和数据预处理任务。与只看容量的对象存储相比，这类文件系统更关注并发访问和稳定吞吐。
C4N 网络和块存储优化型虚拟机则从另一侧减少数据搬运瓶颈。该系列最高提供 400 Gbps 网络带宽、每秒 9500 万个数据包处理能力，并在搭配 Hyperdisk Extreme 时提供最高 25 GiB/s 的块存储吞吐。对于高吞吐推理、分布式缓存和数据密集型服务，网络与块存储配置需要和加速器一起评估，不能只比较 vCPU 数量。
可以这样做容量评估：先记录单个请求的输入输出 token、KV cache 增长速度、模型权重加载时间和网络传输量，再分别计算算力、网络和存储的上限。如果 GPU 利用率不高，但网络带宽或存储队列已经饱和，继续增加加速器通常只会放大成本。
变化二：编排系统开始为大规模 AI 工作负载定制
GKE Dataplane V2 现在支持最多 15,000 个节点的标准集群，同时保持 Network Policy 强制执行能力。这一点对企业 AI 平台很关键：规模扩大后，安全策略不能靠关闭网络隔离来换取性能和运维简单度。
对于强化学习任务，llm-d 新增 cooperative time-slicing，可以把相互独立的 RL 作业交错调度到共享物理硬件上。摘要给出的结果是，聚合加速器 duty cycle 可从约 40% 提升到 70%，同时不影响模型收敛和精度。这里的核心不是简单超卖，而是让调度器理解作业的时间片和资源使用阶段。
GKE Agent Sandbox 与 Pod snapshots 解决的是智能体密度和启动效率问题。一个智能体可能需要多轮推理、工具调用和临时执行环境。如果每次任务都从完整容器启动，启动延迟和基础设施开销会迅速累积。快照可以把可复用的运行状态保存下来，再按需恢复，从而在固定计算资源上容纳更多并发智能体。
一个可改造的 GKE 示例
下面的 YAML 是一个简化的实践模板，展示了如何为 AI 推理工作负载配置资源、网络策略和优先级。示例中的镜像、命名空间和资源值需要根据实际模型与集群规格调整；它不是 Google Cloud 产品的完整部署清单。
apiVersion: v1
kind: Namespace
metadata:
name: ai-inference
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: model-serving
value: 100000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "Keep latency-sensitive model serving ahead of batch jobs"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: inference-ingress
namespace: ai-inference
spec:
podSelector:
matchLabels:
app: inference
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: gateway
ports:
- protocol: TCP
port: 8000
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ai-inference
ports:
- protocol: TCP
port: 6379
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: inference
namespace: ai-inference
spec:
replicas: 2
selector:
matchLabels:
app: inference
template:
metadata:
labels:
app: inference
spec:
priorityClassName: model-serving
containers:
- name: server
image: vllm/vllm-openai:latest
args: ["--model", "YOUR_MODEL_ID", "--port", "8000"]
ports:
- containerPort: 8000
resources:
requests:
cpu: "8"
memory: 32Gi
nvidia.com/gpu: "1"
limits:
cpu: "8"
memory: 32Gi
nvidia.com/gpu: "1"
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 20
periodSeconds: 5
部署前需要准备带 GPU 的节点池、可拉取模型的凭据，并把 YOUR_MODEL_ID 替换为实际模型。应用清单后，可以用下面的命令检查调度与网络策略是否生效：
kubectl apply -f inference.yaml
kubectl -n ai-inference get pods -o wide
kubectl -n ai-inference describe pod -l app=inference
kubectl -n ai-inference get networkpolicy
生产环境还应补充 PodDisruptionBudget、拓扑分布约束、模型缓存、滚动升级策略以及服务级别的 token 延迟指标。
变化三：可观测性和供应链安全成为 AI 平台的必选项
新的 OpenTelemetry-Based TPU AI Telemetry Collector Agent 可以把高保真 TPU 硬件遥测发送到 Cloud Monitoring、Google Managed Prometheus 或自建 Grafana。这意味着团队可以将设备利用率、内存、温度、错误和作业指标放在同一套观测体系中，而不是只依赖应用层的请求数和延迟。
TPU microbenchmark suite 也有类似价值。理论峰值并不等于实际业务性能，微基准测试可以帮助开发者确认设备是否接近理论规格，并定位架构特定的瓶颈。模型迁移到 TPU 或更换 GPU 型号时，应先建立可重复的基准，再判断是否值得调整并行策略或内核实现。
AI 供应链方面，开源的 k8s-aibom 是一个轻量、无特权的 Kubernetes controller。它能够持续扫描集群中运行的 AI runtime，例如 vLLM 和 Triton，并生成符合 CycloneDX 的 ML-BOM。对于存在 shadow AI 的组织，这类清单可以回答几个基础问题：哪些模型运行时正在生产集群中出现？它们来自哪些镜像？对应的版本和依赖是否经过审核？
建议把 ML-BOM 生成和镜像签名、漏洞扫描、命名空间准入策略结合起来。单独生成清单只能提供可见性，不能自动证明模型、运行时或数据来源是可信的。
性能调优正在深入模型内核和调度器
7 月关于 Mistral 3 Large MoE 在 Ironwood TPU 上的优化案例，说明大模型性能调优已经进入系统协同阶段。优化措施包括混合分片、用树形归约替代线性 VPU 求和、优化 GMM/MLA 内核，以及采用异步调度。结果是性能提升约 1.5 倍，吞吐最高提升 48%，同时保持基准精度不变。
这类结果很难通过单个参数获得。MoE 模型需要同时考虑专家路由、通信模式、内存布局和 kernel 融合；线性归约在设备数量增加后可能造成等待和通信热点；异步调度则需要确保计算、通信和数据准备之间有足够的重叠空间。
6 月的 GKE Inference Gateway 更新也强调了推理路径优化。独立基准报告显示，它相较另一项领先的托管 Kubernetes 服务，吞吐高 15.7%，等待时间缩短 92.8%，inter-token latency 降低 62.6%。摘要将这一表现与 prefix caching 联系起来：重复的长提示词可以复用 KV cache，减少重复计算。
需要注意的是，缓存收益取决于请求前缀的重复程度、缓存容量、租户隔离和失效策略。多租户场景必须评估缓存键设计与数据隔离，不能为了降低延迟而牺牲隐私边界。
采用建议：按工作负载而不是产品名做决策
这批更新可以归纳为一份面向平台团队的检查清单：
- 训练或批处理大量依赖并行文件访问时，评估 Managed Lustre 等高性能文件存储，并测量检查点恢复时间。
- 推理服务出现 GPU 空闲但请求延迟升高时，同时检查网络、块存储、KV cache 和调度等待。
- 集群规模扩大后，保留 Network Policy、命名空间隔离和准入控制，不要把安全策略当成可选开关。
- 强化学习和批处理任务使用时间片共享前，验证作业对暂停、恢复和 GPU 状态的容忍度，并持续观察收敛指标。
- 智能体数量快速增长时，测试 Agent Sandbox、Pod snapshot、模型缓存和冷启动优化的组合效果。
- 在生产启用新模型或 runtime 前，生成 ML-BOM，固定镜像版本，并接入漏洞和签名检查。
- 任何宣称的性能提升都要用自己的输入长度、并发度、模型量化方式和 SLA 重新测量。
AI 基础设施的下一阶段，不只是购买更大的加速器，而是让存储、网络、编排、观测、安全和模型内核共同工作。能够把这些层面纳入同一套容量模型和发布流程的团队，才更有机会把智能体从演示环境稳定推进到生产规模。