Google Cloud Filestore 接入 Colossus：共享存储面向 AI 升级

Google Cloud Filestore 接入 Colossus：共享存储面向 AI 升级

Google Cloud 在 2026 年 8 月 31 日发布的 AI 基础设施与编排月度更新中，再次列出 Filestore 的关键变化：这一托管 NFS 文件服务已加入直接构建在 Colossus 之上的云原生后端存储层。原始产品文章发布于 8 月 5 日，月末汇总使该变化进入当月基础设施更新主线。它不是新的虚拟机套餐，也不代表所有用户会自动获得相同表现；更准确的理解是 Google 正在重构 Filestore 的底层扩展方式。

Colossus 承担什么角色

Colossus 是 Google 的分布式存储系统，也是 Google File System 的后继者。Google 公开资料称，它支撑 Cloud Storage、Firestore、Cloud SQL、Filestore 等服务，并为 YouTube、Gmail 等大规模产品提供基础存储能力。Filestore 将新后端层直接建立在这套基础设施上，目标是减少传统、与单个虚拟机架构绑定的扩展限制。

对用户最直接的产品含义，是容量和性能可以更独立地配置。官方文章表示，用户能够通过 Custom Performance 独立调整 IOPS，而不必为了更多性能一并过量配置容量。这种解耦有助于数据集规模与访问强度不成比例的工作负载，但实际服务层级、区域和配额仍应在控制台与产品文档中确认。

共享文件存储与块存储的选择逻辑不同。比较虚拟机磁盘资源时，可阅读 Google Compute Engine 停止与磁盘计费；Filestore 更偏向多个客户端通过 NFS 访问同一文件系统。

GKE 与并行 AI 任务为何被强调

Google 将更新重点放在 Filestore CSI 驱动、GKE multishares 和并发工作空间。容器集群可把持久文件存储挂载给多个工作负载，multishares 则允许从较大的 Filestore 实例划分出更小、按项目隔离的共享空间。官方认为，这能让团队从较小数据集起步，并在不重建整个集群的情况下调整存储能力。

在 agentic workflow 中，多个并行执行单元往往需要共享模型、上下文、检查点或中间结果。NFS 文件语义和文件锁可提供统一视图。Google 将其描述为高并发 agent swarm 的公共工作区。不过，架构描述不能替代用户自己的容量规划；并发上限、锁竞争、吞吐和故障恢复时间必须按所在区域与访问模式确认。

一般 VPS 用户不必因此立刻迁移。单机网站、轻量 API 和仅由一台服务器读取的数据，通常不需要托管共享文件系统。多节点容器、共享训练数据、模型分发以及大量并发读取，才更可能受益。若工作负载仍在单台服务器上，先完善 VPS 备份与恢复流程 往往比增加组件更重要。

迁移前应确认哪些边界

首先确认协议与应用语义。Filestore 提供 NFS 接口，但应用是否正确处理文件锁、权限、UID 和 GID，不能只看能否挂载。其次检查网络路径、VPC 设计、区域可用性和故障域，避免共享存储成为新的单点。第三，应以代表性目录结构和小文件比例进行容量验证；AI 数据集、构建缓存和传统共享目录的访问模式可能完全不同。

安全方面，Google 提到 IAM、NFS 用户与组标识以及 IP ACL。团队仍需建立最小权限、挂载范围、密钥管理、审计和备份策略。共享存储让更多计算节点访问同一份数据，也会扩大错误删除、凭据泄露和错误权限配置的影响面。

容量和 IOPS 解耦提供了新的调优空间，但不自动意味着更低成本。迁移前应记录当前容量、峰值吞吐、IOPS、客户端数量和恢复目标，用小规模副本确认兼容性，再决定是否切换生产数据。保留回退路径和独立备份，能避免把底层平台升级误解成无需演练的一键迁移。

这项变化意味着什么

更新反映出计算与存储继续解耦：容器和 AI 任务可快速增加或退出，而共享数据层需要在不跟随单个节点生命周期的情况下扩展。Google 选择把 Filestore 更深地接入 Colossus，说明传统 NFS 接口仍可通过云原生后端服务现代工作负载。

新闻结论也应保持边界。官方没有为所有用户承诺统一提升比例，本文没有提供任何 GSNode 数据。可以确认的是后端架构、独立性能配置和 GKE 集成方向；无法从公开信息推导任意区域的实际表现、成本收益或迁移收益。