存储瓶颈与 GPU 利用率
我们最近的研究问到，过去一年里，基础设施配置在多大程度上拖慢了开发者效率。21% 的受访者认为这是严重瓶颈，也就是说，开发者经常要等上几周，云基础设施或数据库才能配置好。我叫 Paul Nashawaty，是负责实践领域的首席分析师，欢迎收看《AppDevANGLE》。今天请到 Ronen Schwartz，他是 Google 的 Google Cloud Storage 产品副总裁。Ronen 所在团队直接负责这套解决方案的一部分，而这正是当下企业 AI 领域一个讨论不足的问题：存储跟不上 GPU 的速度。Ronen，很高兴你今天来节目，欢迎。
Paul，你好。谢谢邀请，也谢谢你选了这么令人兴奋的话题。正如你提到的，我在 Google 负责存储产品团队。现在对我们来说是非常令人兴奋的时期，对基础设施行业和数据行业的每个人来说也是如此。加速器和智能体领域正在发生的变化，都让存储行业迎来了创新时刻。
Ron，谢谢你介绍这些情况，也印证了我们今天想讨论的重点。但行业里有个令人不安的事实：过去两年，企业都在争相获取 GPU 算力。他们搭建集群、签下基础设施协议、建设机器学习平台，现在许多企业才发现，存储层正悄悄限制那些好不容易争取到的加速器。瓶颈并没有转移到计算端，它其实一直在存储端。我们的研究显示，29% 的受访者把高昂的维护成本挤占新开发预算，列为传统核心系统的主要运营风险。这个问题也直接体现在这里：企业不断投入现代 AI 基础设施，存储底座却悄悄把预算推到上限。团队开始感受到压力，I/O 成了问题，GPU 利用率也达不到目标。好消息是，这个问题可以解决。存储供数不够快，加速器就会吃不饱，GPU 利用率下降，训练时间拉长，AI 的经济账很快就算不过来。你在企业客户那里看到的情况如何？存储瓶颈有多严重？AI 项目进行到什么阶段，企业才会发现这是个大问题？是在实施之前，还是之后？
我笑着说，存储刚刚升了职。它不再只是后台的支撑角色，而是走到了前台，成为加速器执行任务的关键组成部分。加速器是企业最昂贵的成本项目。它们每空等一秒数据，都意味着巨大的资金损失。存储已经升格为关键组件，支撑 TPU 运转。好的基础设施能显著提高 TPU 的生产效率、缩短处理时间。
存储架构如何影响 AI 成本
虽然存储在账单中占比可能较小，但正因为它是瓶颈，正在成为影响 TPU 或 GPU 性能和利用率的关键部分。存储因此升格为架构中的重要组成。更成熟的组织会尽早考虑这个问题，但我也遇到一些客户，直到瓶颈真正出现、TPU 闲置、利用率不达标时才意识到。随着 AI 项目推进，瓶颈也会变化：训练、推理和智能体的阻塞点各不相同。存储升格，就是要为每一种场景提供支持。
这很合理。找出不同挑战之后，问题才会凸显出来。Google 多年来一直用自己的基础设施运行超大规模 AI 工作负载，Colossus 文件系统也是内部实践的核心。把这套架构带给企业客户，是很有分量的差异化优势，值得具体谈谈。与竞争对手的方案相比，它在实践中究竟意味着什么？技术细节很重要，因为文件系统会影响总体拥有成本。我们最近的研究中，32% 的受访者说总体拥有成本是供应商选择中权重最大的因素，47% 则看重开发者效率和集成便利性。能同时提供吞吐能力和运维简便性的存储架构，正是企业需要的组合。Ronen，企业客户获得 Colossus 衍生架构后，究竟能得到什么？与其他 AI 存储方案相比，可衡量的差异在哪里？市场选择很多，但其中的技术细节会直接影响加速器表现，听众也想了解这些差异。
这是个好问题。每个 TPU 或 GPU 用户都应该认真考虑。市场上有很多性能说法，但实际情况是：Google 提供市场上最高的性能，而且这些数字可以测量。我来 Google 还不到六个月，所以我既能从内部验证，也能从外部视角验证我现在说的内容。Rapid 对象存储每秒可达 15 TB，Google Cloud Managed Lustre 每秒可达 10 TB；这已被验证为行业领先的性能。这并非偶然，它建立在 Google 的基础设施之上，而这套基础设施比其他任何基础设施都更早、更久地用于支持加速器性能。
数据位置、吞吐与训练检查点
Google 正与全球十大前沿 AI 模型中的九个合作。我们为它们提供支持，这已经持续多年。通过内部实践、与行业领军者合作，我们实现了几项技术突破。传统上，存储做成多可用区、多区域是好事，能提高韧性；但要发挥加速器性能，数据必须尽可能靠近 GPU 或 TPU 集群。我们率先推出可用区级共置（zonal colocation），确保数据离 TPU 或 GPU 很近，直接影响数据送达加速器所需的时间。
我们还优化了整个存储层，借助 Rapid Bucket 技术减少处理步骤，降低延迟、提高吞吐量。这背后有多年精细的工程工作，单个存储桶的吞吐量就能超过每秒 15 TB，并支持每秒 2,000 万次查询，延迟低于一毫秒。这需要大量工程投入、提前布局，以及强大的基础设施。再补充一个数据点：无论是训练、推理还是 KV 缓存，有些客户都会选择 Lustre。它是领先的开源存储系统之一。Google 深入优化了底层基础设施，发布了新型实例来支持并提升其性能，还与 DDN 深度合作。我们非常重视如何交付最佳性能，真正提高 TPU 和 GPU 的利用率。
你刚才提了很多内容。训练和推理面对的存储问题不同，我们先从这里说起。模型微调和训练会产生具体而且往往很棘手的检查点问题。如果一个任务在运行数小时后失败，丢掉这些计算成果的代价非常高。与此同时，推理工作负载对延迟、内存架构和 token 吞吐量也有完全不同的要求。如今大家都在关注 token 成本。这些问题并不相同，用同一种方式处理会留下缺口，处理错了，运营风险会迅速累积。企业应该如何看待训练与推理各自的存储需求？试图同时处理两者时，常见的架构错误又有哪些？
训练、推理和智能体的不同节奏
Paul，这个问题我可以讲一小时。正如你说的，不能把所有东西都塞进一个“AI 工作负载”桶里。AI 并不是一种工作负载。数据流动的方式完全不同，就像不同的心跳：处于生命周期的不同阶段，就有不同的节奏、需求和需要解决的潜在瓶颈。
再深入一层，训练需要大规模顺序读取，但这不是唯一的瓶颈。大约每 15 分钟，集群就要暂停，把数 TB 的检查点写入存储，以便发生故障时能够恢复，不丢掉已经完成的工作。存储太慢会让整支 GPU 集群停摆。前面提到 Rapid 技术，在检查点写入上速度超过标准对象存储三倍，恢复速度超过五倍，差异非常大。这不只对训练前沿模型重要，对其他公司也重要。比如我们合作的自动驾驶客户 Touring，他们有数百万份传感器数据，要把数据导入 Lustre 来训练车辆。这样的训练应用还有很多。
再说推理，它的节奏和训练很不一样。推理是实时交互过程，对延迟非常敏感；每个提示都要尽快得到回应。我们每个人都和聊天机器人、智能体交互过，本质上那都是推理。我不知道你怎么样，Paul，但我对回复速度很敏感。
完全同意。等太久的话，人就去做别的事了。
Ronen，智能体 AI 正在快速发展。企业正在研究多智能体流水线：多个模型协作、交接上下文、暂停并恢复任务、动态检索信息。这些在演示里能跑通，但要投入生产，需要能支持共享工作区、低延迟检索和智能体间状态持久化的存储架构，同时避免形成数据孤岛。我们在 Kubernetes、容器化以及其他领域都见过类似问题。现在进入 AI 时代，也得确保这些基础能力真正可用。我们的研究也发现，
让智能体读懂非结构化数据
18% 的受访者认为，开发、运维和安全团队之间各自为政，是统一应用安全态势的最大障碍之一。所以安全也与此相关。这不只是延迟和架构问题，还关系到安全以及整个方案的性能。智能体架构规模扩大后，数据基础设施的碎片化会成为更大的问题。你应该也同意。面向智能体的数据基础究竟是什么样？企业愿意把共享存储工作区推进到什么程度，才能让多智能体系统在生产环境中可靠运行？
我们聊了训练、推理，智能体显然也是当下的重要领域。我希望大家充分认识到，智能体不能只用来浏览网页。它们需要先做出智能的数据决策。Google 很重视这一点：智能体除了浏览和查询，也需要充分访问非结构化数据，这正是存储发挥作用的地方。存储里有大量非结构化数据，包括图片、视频、文档和 PDF。我们的“智能存储”计划投入很多精力来丰富这些非结构化数据。
我们最近推出了 Object Enrichment，可以调用 Google AI 模型，在几秒内以很低的成本自动提取内容。文件或图片一进入存储桶，系统就会根据内容给对象附上相关元数据。这样一来，智能体就能理解过去所谓的“非结构化数据”。关键在于，存储已全面融入 Google 的智能体数据云，以及跨界数据湖仓架构。于是，AI 智能体现在能够理解存储在 Google 内部、也能理解存储在 Google 之外的数据。
这很有意思。现在我们谈的是需要共享数据基础的多智能体和 AI 系统，而许多企业还没有这样的基础。智能体存储意味着什么？
智能体确实是许多企业重点关注的新变化。它们对存储的要求和传统工作负载不同。部署智能体时，必须考虑规模问题：可能是几千、几百万，甚至上亿个智能体；有的运行时间很短，有的则持续很久……
智能体规模化与存储路线图
……有的则持续很久；有的处理少量数据，有的要处理更大的数据集；有的智能体处于活跃状态，有的则休眠，等用户需要时再恢复运行。为此，存储和基础设施必须专门设计，才能支撑智能体。我们在这方面投入了很多。具体来说，我们关注智能体规模化后的成本、响应速度，以及智能体之间共享数据的能力。因此我们推出了文件存储 Agent Volumes，直接集成到 GKE 的 Agent Sandbox，也就是我们的 Kubernetes 环境中。我鼓励大家试用，亲自看看高效存储在智能体环境中的价值。
Ronen，我也得问问：你们的存储路线图上有什么值得客户和听众关注的内容？
我先说有很多，不过有些即将推出的内容我还不能透露。我想非常概括地讲讲我们重点投入的领域。我们谈了不少 AI 和支持 AI 训练、推理的存储。推理方面我们可能讲得少一些，但那里也有很多新能力，性能不断刷新纪录，我们也在改进对推理不同环节的支持，重点优化关键领域的推理性能。我们刚才谈到智能体，你们会看到我们在智能体存储方面有很多创新，包括为智能体群、大小不同的智能体优化的存储，也会持续优化整体的智能体存储。你们还会看到存储管理自动化水平大幅提升，让企业客户更好地使用存储。
除了 AI，我还想说，AI 是重点领域，但它也在推动数据迁移上云，EDA 等流程正在上云，HPC 也在上云。因此，我们很关注基础能力，让各种工作负载都能在云端高效、安全地大规模运行。
是的。我自己读过你们网站上不少相关博客，讲的也是这个方向，我也鼓励听众去看看。Ron，感谢你今天做客节目。这次谈了很多，听众还有不少内容可以思考和消化。谢谢你来到《AppDevANGLE》。
谢谢你给我机会，能和你共度这段时间……
节目收尾
……也和所有听众交流。就像我之前说的，存储刚刚升职了。去 Google Cloud Storage 网站看看，就能陆续看到这些新消息。也可以在 LinkedIn 上关注我，我会分享不少令人兴奋的消息。我觉得现在正是大家创新的好时候。
没错，我们也这么认为。感谢大家收看《AppDevANGLE》。本期到此结束。下周三我们会带来另一场对话，继续聊塑造应用开发未来的工具、趋势和人才。无论你是在边缘部署、用 AI 构建产品，还是现代化云技术栈，我们都会带来相关内容。欢迎在社交媒体上关注我们，有想法、问题，或只是想交流，都可以联系我们。下次再见，保持好奇，继续创造。