构建大规模的AI/ML数据管道，并依据使用场景选择适合的块存储、文件存储和对象存储方案。如何通过最佳存储方案来优化各类AI/ML工作负载，如数据准备、训练、调优、推理和服务，并轻松集成到Compute Engine、Google Kubernetes Engine或Vertex工作流中。如何利用Cloud Storage和Anywhere Cache优化分析工作负载。主讲嘉宾：
Google Cloud Storage（GCS）在过去的十年里，为数据密集型工作负载提供了高度可扩展、安全可靠的存储解决方案。以往，AI一直是Cloud Storage的核心应用。然而，近年来，随着GenAI和LLM的兴起，存储面临了更多独特的挑战与需求。AI本质上是一个极为数据密集的工作流程，而存储则是运行端到端AI数据管道的关键环节。接下来，我将展示一个典型的AI数据管道，从数据摄入开始，随后进行验证和预处理，确保数据准备就绪，再用于AI模型训练。模型训练和验证后，便可用于推理并服务于最终用户。这通常是一个迭代的过程。客户常常从模型推理中收集反馈，并将这些反馈用于优化数据准备和模型训练，以实现数据管道和模型的持续改进。当然，模型为最终用户提供服务后，众多内容需要被服务并交付给用户，这些内容大多也存储在GCS上。AI数据管道主要包括三个阶段，对存储基础架构提出了独特的挑战：- 数据准备阶段：涉及处理数据以使其适用于训练。客户通常希望获得更高质量的数据以提高模型准确性，这就要求扩大数据范围，从而导致数据集的增大和存储需求的增加。
- 模型新鲜度问题：为确保模型保持最佳状态，存储系统需要提供高吞吐量，以便迅速访问模型。在模型训练方面，存储系统面临的主要挑战是如何让稀缺且昂贵的GPU和TPU保持高效运行。这意味着我们需要最小化训练数据的加载时间，加速存储系统的Checkpoint，以及在节点故障时快速恢复。
- 推理阶段：目标是实现快速的启动时间，最小化模型加载时间，尤其是随着模型规模的不断扩大。
- 存储基础架构需要高性能和可扩展性，能够支持EB级的数据规模，并提供高吞吐量。
- 数据管理要统一，确保所有数据阶段和工作负载都能从同一数据存储库中获取所需数据。
- 数据治理至关重要，需要确保模型的安全性和数据谱系的可追溯性。
- 生态系统支持也不可或缺，存储基础架构应与常用框架、云平台和计算基础架构无缝集成。
我们抓住了这个机会，重新思考了AI工作负载的存储基础架构。我们提出了Cloud AI存储的愿景和具体产品。简而言之，我们希望能够实现“一次存储，随处访问”。这意味着你可以将数据存储在单一目的地，并随时随地以任何性能、接口和规模访问这些数据。这不仅简化了数据管理，降低了存储成本，还提高了工作效率。“任何地方访问”，意味着无论你身处哪个区域，都可以从任何地点访问这些数据，且性能不受限制。“使用任何接口”，则意味着你既可以选择对象接口，也可以选择文件接口来访问数据，完全根据你的偏好和框架、应用程序的需求来定。“以任何规模”，即无论你的数据量是几GB还是几EB，我们的存储系统都能与之同步扩展，满足你的需求。
综上所述，“Cloud AI Storage”是一个集中存放你所有数据的地方。它专为AI训练和AI服务进行了优化，并与生态系统实现了集成。在Cloud Storage的底层，我们利用GCS作为单一数据存储库的对象存储。因此，你可以将所有数据写入GCS，使其成为你的核心数据源。除此之外，我们还提供了一系列针对特定目标和AI训练不同阶段使用的高性能优化存储方案。比如，我们近期宣布了支持缓存的GCS FUSE。这个GCS FUSE为你存储在GCS中的所有对象提供了文件访问的便利。现在，我们还增加了对本地缓存的支持，让你在访问这些数据时能够享受到缓存和性能加速的好处。此外，我们在GCS的基础上还提供了两种功能全面的分布式文件服务：Filestore和Parallelstore。它们不仅提供高性能，还如果你需要使用文件API访问数据，它们还兼容POSIX。同时，我们也刚刚推出了Hyperdisk ML，它支持缓存一些来自GCS的数据，这些数据可以被多个计算节点同时读取和使用。这将大幅减少服务延迟和启动时间。我们一直在努力改进本地SSD，使其更加适用于AI工作负载。今天，我们还发布了“Anywhere Cache”，这是一个位于GCS之上的高性能对象缓存，可以将数据从任何地方快速拉到你附近的计算机和加速器。这一功能与GCS完美集成，实现无缝对接，对应用程序而言是完全透明的。你无需在应用程序中做任何更改，一旦启用，即可享受到所需的性能加速。我向大家介绍五个专门设计用于加速AI/ML工作负载的新产品。为了更好地理解这些产品，我们将以AI数据管道为例，并深入探讨不同阶段：数据准备、训练、Checkpoint和推理阶段，最后通过一个实际用例将这些内容整合起来。
数据准备，对于那些希望利用持续的数据管道来训练和调整模型的客户来说至关重要。如果从客户的角度来考虑，模型有两个方面是大家关心的：模型的时效性和模型的准确性。
模型有多新鲜？我多久能用我的最新数据调整一次这个模型，对吧？这实际上取决于存储吞吐量。我多快能处理这些原始数据，并将其转化为我可以训练的东西？然后是模型准确性，这实际上取决于数据的时间窗口。我是用一天的数据进行训练，还是七天、一个月甚至一年的数据？这真的取决于规模。这正是“Anywhere Cache”产品发挥作用的地方。
“Anywhere Cache”是一种基于本地SSD的区域性缓存，它直接构建在Cloud Storage之上。它的神奇之处在于，它是一种按需产品，它允许你扩展你的吞吐量和存储。"Anywhere Cache"的最初发布可以在单个区域缓存中拥有高达1PB的数据。你将数据从一个区域性存储桶中提取出来，并将其拉到靠近你的存储、你的计算工作负载。同时，它还可以扩展到该单个缓存中的10Tb的带宽。
吞吐量是存储工作负载的一个关键部分，特别是对于AI/ML来说。作为一个典型的例子，你可能在应用程序中部署了模型。不断地从该应用程序中提取原始数据，并将其导入到Cloud Storage的区域性存储桶中，可能是通过数据流。然后你准备将这些原始数据转化为你可以实际训练的东西。你将数据从区域性存储桶中提取到本地缓存中。它就在你的数据处理集群旁边。你能够加速这个数据准备过程。
“Anywhere Cache”另一个真正令人兴奋的用例在于实现了一次存储数据，然后能够在任何地方使用它的愿景。“Anywhere Cache”在这种情况下被证明是非常有益的。我们观察到，尤其是在过去的几天里，加速器方面的连续创新，无论是GPU还是TPU。下一代加速器硬件总是近在咫尺，最多一个月或一周就会到来。
我们与那些渴望在最新一代硬件上持续训练的大型客户合作。随着我们在不同地区部署这些大型实例或重要的硬件，你可能需要在训练模型时从一个地区转移到另一个地区。在“Anywhere Cache”出现之前，你必须跨区域复制训练数据。但我们渴望与你分享的模型涉及将你的数据仅存储一次在多区域存储桶中。然后，无论你需要在哪里进行训练，你都可以使用“Anywhere Cache”将你的训练数据不仅传播到该地区，而且直接传播到你的加速器所在的同一区域。我们对这一发展特别兴奋，尤其是对于那些希望过渡到下一代及以后的客户。
接下来，我们来谈谈训练。我们一直在特别提到我们拥有这些宝贵的GPU和TPU，而整个目的都是为了保持它们的高效运转。你想要避免的是存储I/O瓶颈。
Cloud Storage FUSE local cache：可能你们中的许多人都熟悉Cloud Storage FUSE；它本质上是将你的存储桶挂载为本地文件系统的一种方式。这使你可以通过文件API访问你的GCS对象，这是大多数行业希望消费其存储的方式。我们上个月刚刚宣布了对这种本地缓存能力的GA支持。现在你可以使用存在于你的GPU实例上的本地SSD。硬件的A3版本有高达9TB的本地SSD与之相关联。现在你可以将数据保存在GCS上，然后直接将其缓存到拥有你加速器的VM上。
我们进行了很多基准测试。如果你看右边的图，它只是训练时间的比较。fsspec是基线案例。如果你不熟悉它，你可以将其视为Python与GCS接口的标准方式。这里的水平轴只是训练时间，所以越短越好。不同的颜色代表你训练作业中的不同Epoch。最浅的颜色是第一个Epoch。在两个案例之间，基线和使用GCS FUSE的加速版本，时间大致相同。但在那之后的每个Epoch，你会看到它只需要三分之一的时间。如果你一次进行10、12、20个Epoch，如果你在调整那个模型，你会看到你得到了那个好处。在这个特定的基准测试中，我们看到训练时间提高了2.2倍，这导致了总体TCO节省了60%。这是总体TCO，考虑了你的计算和存储成本。
我们上个月刚刚GA的另一个产品是针对对象存储的针对PyTorch的“Accelerated Dataloader”。该产品真的专注于早期模型开发。在那里，我们看到训练时间提高了3.5倍，这导致了总体TCO提高了70%。
这两个产品只是我们放在Cloud Storage之上的加速器，所以没有额外的存储成本。它们只是为整体工作负载提供节省和性能改进。然而，可能有些情况下你需要更多的性能存储，我们有另外两个我们非常兴奋讨论的产品。
首先是Parallelstore，它今天已经开始了私密预览。这是谷歌首个基于Intel的DAOS技术构建的并行文件系统。如果你熟悉它，它直接与GCS集成。在我们类似的基准测试中，我们看到训练时间提高了3.9倍，所以这是一个巨大的改进。如果你仔细观察，你会发现因为这是一个独立的文件系统，我们可以在你开始训练任务之前将数据从Cloud Storage推送到Parallelstore。因此，每一个Epoch，即使你只进行几个Epoch，你都能获得性能提升的好处。
然而，你可能更倾向于不使用文件系统或将你自己的文件带给我们。在这种情况下，你不必选择Parallelstore。第二个产品是Hyperdisk ML，它是为AI工作负载优化的块存储。它直接与Cloud Storage集成，并提供3.2倍更快的训练时间。这种集成允许在存储解决方案之间轻松传输数据。对于训练数据，你可以从Cloud Storage中提取并提升到Parallelstore。对于持久性检查点，你可以将它们推送到GCS进行长期存储。
最后，我们来谈谈推理。我们的大部分关注点实际上都聚焦在LLM上。很明显，我们所有人都将利用某种形式的LLM来满足业务需求。而且，LLM正变得越来越强大，这也是显而易见的。随着模型参数数量的增加，模型的物理大小也在不断扩大。因此，保持从物理存储到实际用于推理的计算加速硬件的短加载时间至关重要。这正是HdML大显身手的地方，因为它允许你独立于存储扩展吞吐量，专为这一特定用例而设计。在我们的基准测试中，与基线情况相比，使用HdML我们看到了3.7倍的时间改进。对于非常大的模型来说，这可能是最佳选择。因此，如果你处理的模型大小达到或超过20GB，HdML将是加速该工作负载的最佳方式。但你可能会处理一系列模型，并非所有模型都很大。所以，我们还想指出，即使直接在GCS上使用Cloud Storage FUSE，你也能获得3.3倍的基准情况改进。模型大于20GB时，请使用HdML；小于20GB时，Cloud Storage FUSE则是更好的选择。
让我们通过一个端到端的用例来整合整个过程。我们与医疗保健行业合作，深入探讨了他们使用的数据。在这个例子中，我们可以将其视为一种涉及医学图像的病理学用例。我们将贯穿整个模型开发周期。想象一下，你有一位ML科学家，手头有一小部分数据。他们希望构建模型，深入了解这种病理学，并将其引入实践。因此，也许他们会每次进行一两个Epoch，尝试构建模型，直到达到可以发布到生产环境的标准。加速数据加载器就是一个简单有效的方法，能使他们在训练时间上获得3.2倍的改进。但现在，假设这位科学家已经开发出模型，并准备将其投入生产。但他们需要的不仅仅是一个静态模型，对吧？于是，他们将其交给一位ML工程师，后者将接管模型，并根据新数据不断进行调整。因此，这位ML工程师可以选择使用Cloud Storage FUSE，享受连续Epoch带来的所有好处。也许他们每次会进行10或20个Epoch。使用Cloud Storage FUSE，他们将获得2.3倍的提升。很好，现在模型已经投入生产，并在每月基础上进行调整。但他们还想引入更多数据，提升模型性能。也许他们的数据集已经超出限制。也许有些数据集只适合在单个节点上进行训练。但现在，他们需要将其扩展到更大范围。这正是Parallelstore的可扩展性真正发挥作用的地方，单个训练数据集最大可达到100TB。因此，他们基本上会升级到Parallelstore，作为扩展的生产用例。这就是整个模型生命周期的端到端旅程，在这个过程中，无论你处于哪个阶段，这五种不同的存储产品都能用来加速你的工作。接下来演讲的题目是“丰田Woven：如何运行面向用于自动驾驶的大规模ML工作负载”。相信在座的各位，对丰田的众多公司团队和联盟都有所了解。比如，在自动驾驶方面我们有ADAS，在驾驶舱体验方面有Multimedia等等。当然，还有专门负责为城市移动性开发测试的团队。
我们认为，让应用程序开发者能够专注于应用程序开发是非常重要的。因此，我们必须为他们提供一个稳定且易于使用的平台。同时，我们也坚信，领域内部不应该过于封闭，数据或ML模型应该得到适当的共享。我们构建的“企业AI平台”旨在满足各类需求。它不仅在成本方面提供了最佳解决方案，还在GPU充足性方面给出了保证。为了实现这一目标，我们采用了多云技术。通过运用这一技术，我们的目标是将任何云服务商的服务集成到我们的服务中。
我们提供的服务非常便捷，新用户刚加入我们的平台，只需跳转到平台，就能指定数据或ML训练代码。因此，我们提供了多种路径，以支持不同领域的多样化需求。应用层使ML工作得以进行，从而使学习能够在用户指定的任何位置进行。具体来说，这涵盖了多个层面。例如，低抽象层如Kubernetes，以及托管服务如Google的Vertex AI。用户可以在这些平台上顺利执行机器学习任务。过去，我们曾与另一家供应商建立了类似的机制，但最近，我们成功地将基于GCP的平台整合到了我们的多云技术中。在实现这一目标的过程中，我们遇到了不少挑战，特别是在文件访问、成本控制以及速度性能方面。为了克服这些挑战，我们做了很多努力。我想从讨论我们基于先前云服务商的云训练架构的首次迭代开始谈起。
让我们从最底层开始一步步梳理。丰田制造的ML训练数据集存储在云对象存储中，这应该与大多数人的做法相同。这无疑是我们的首选方案，因为它既经济高效又高度可靠。不过，这里也是我们实施数据治理最佳实践的关键所在。因此，我们制定了一系列政策，如数据保留政策、安全访问政策，以及数据分隔方式，以确保满足法律和隐私方面的要求。但实际情况是，我们的训练作业并不直接访问Cloud Storage。相反，我们利用云服务商提供的Lustre服务。如果不了解Lustre，我可以简单介绍一下，它是一款专为超高性能、低延迟和高吞吐量访问设计的开源并行文件系统。它的运作原理是，当你创建一个Lustre驱动器时，你可以选择创建一个空驱动器并从云对象存储中复制数据过来，或者指定某个云对象存储桶的部分内容同步到你的Lustre系统中。在云环境中，Woven运行大规模的Kubernetes集群，利用GPU实例执行分布式训练作业，涉及ADAS、LLM等公司范围内的多种ML训练任务。我们访问数据的方式是将Lustre文件系统挂载为这些训练节点的本地卷。这样，文件就会出现在节点上，看起来就像本地文件一样。当然，在训练作业执行过程中，我们实际上是在读取这些文件，文件内容是通过网络实时从文件系统中流式传输过来的。
这就是我们的第一个架构，它确实有效。这并不是丰田制造公司Woven独有的架构，许多公司都采用这种方案，你们可能也不例外。随着用户开始上传他们的数据，数据量从最初的数百GB增长到现在的TB级别。虽然一切进展顺利，但随着时间的推移，我们逐渐意识到这种方案存在一些问题。首先，Lustre基础设施的性能是需要付费的，而且价格不菲。当然，GPU云实例才是我们支出的大头。但随着时间的推移，我们发现用于支持这些训练作业的Lustre基础设施成本竟然占到了整个平台成本的约40%。这简直让人难以置信，对吧？我们应该把钱花在真正的训练上，而不是花在数据访问这个环节上。其次，最初我们设置了三个Lustre驱动器，数量多少主要取决于需求，对吧？有些公司可能只需要一个大型实例，但对于不同的用例来说，多个实例更为常见。因此，我们从三个驱动器开始，但随着用户数据的不断增加，现在我们已经有大约30个驱动器了。这让我想起几年前，我夫人说服我养了一只小猫，后来觉得它很孤单，于是我们又养了另一只。就在我来拉斯维加斯的前一个周末，我们又迎来了第三只猫。现在情况有点失控，我对我们存储基础设施的发展也感到同样的担忧。此外，这30个额外的驱动器意味着我们有更多的ML数据集副本。因此，所有这些数据治理政策都需要在30个新位置得到遵守。我们意识到这种情况无法持续下去，于是开始寻找长期解决方案，并设计新的架构来解决成本和数据管理问题。
与此同时，我们期望通过多云策略增强GPU的可用性。因此，我们着手向GCP拓展，并与Google团队交流，他们推荐我们尝试一种新型的存储方案：Cloud Storage FUSE。我们的做法是，在Google Cloud Storage中复制了部分核心数据集，并利用Cloud Storage FUSE进行了一系列ML训练实验的尝试。假如你在Kubernetes集群中运行GKE，你需要将CSI驱动安装到集群中。若你仅使用虚拟机，则需将内核模块安装至虚拟机。此后，与Lustre类似，你可以直接从Cloud Storage挂载数据至作业中，访问这些文件时，感觉就像操作本地文件一样。实际上，当你访问这些文件时，它们会通过网络流式传输到文件系统中。令人惊讶的是，我们并未运行Lustre服务，而是使用Cloud Storage，但其性能在丰田制造公司的需求下竟与Lustre不相上下。因此，我们迅速认识到，这能为丰田节省高达40%的培训预算。这对丰田来说，无疑是一笔巨大的节省。此外，我们原本在ML训练作业中拥有的30个数据副本已不复存在。在右侧的图中，黄色表示训练时间。我们有一个特定作业在Cloud Storage中的运行速度甚至超过了基于Lustre服务的旧版本。部分作业的运行速度相近，部分稍慢，但我们的观点是，Cloud Storage FUSE基本上可以立即应用于我们的大多数作业，并展现出可比较的性能。最近我注意到Parallelstore在本周末宣布上线，因此现在Google Cloud实际上提供了一种类似Lustre的服务。如果你有更大规模的需求，这或许是一个不错的选择。然而，对我们来说，Cloud Storage FUSE已经满足了我们的需求。
我们的工作尚未完成。Google团队建议我们尝试他们预览中的另一项功能——Cloud Storage FUSE Cache。因此，我们正在进行实验，但并未亲自编写代码，我们期望从用户那里获得真实的反馈。所以，用户的代码在需要访问文件时，直接从Cloud Storage获取。我们进行称为Epoch的训练轮次，在每个Epoch中，我们都会访问数据。你可以从顶部的图中看到，读取访问的模式在每个训练Epoch中基本一致。当用户再次需要数据时，他们只需从网络中重新获取该文件。你可能会想，在训练的第一个Epoch中，更明智的做法是将数据缓存在节点的本地SSD中，这样就不必反复通过网络获取了。作为一名系统工程师，我一直期望有一个库或系统服务能帮我实现这一点，对吧？我并不希望我的用户，也就是计算机视觉人员，去编写缓存代码。幸运的是，FUSE存储缓存正是这样一个方案。虽然对我们来说，它当时还只是个预览版，但现在应该已经是GA版本了，所以你只需启用它并进行一些简单配置即可。从底部的图中，我们可以看到，在训练的第二个Epoch中，Cloud Storage的读取次数已经降为零。这是因为我们已经访问了所有文件，并且它们已被缓存在本地节点中。训练时间缩短了33%，这意味着在模型中，GPU之前等待从Cloud Storage或类似Lustre服务拉取数据的时间被大大减少了。因此，当我们启用FUSE后，这种延迟被消除，训练速度提高了33%。
--【本文完】---
近期受欢迎的文章：
NVIDIA与4家存储厂商同台讨论：AI存储方案
VAST Data重塑AI时代的存储格局
AWS的AI战略与最新进展（2篇）
微软：AI基础设施（AI Infra）现状报告（2024年）
Meta大规模AI集群内部揭秘：构建60万个H100的强大算力
更多交流，可添加本人微信
（请附姓名/关注领域）