VAST Data: 探索AI的未来

目前，AI领域的焦点主要集中在GPU上，大家热衷于讨论GPU的性能、相关知识和技能储备。然而，随着对AI的深入研究，我们发现数据才是AI发展的关键所在，而非GPU。这一观点其实并不难理解。将神经网络视为大脑的模拟，我们可以看到，我们的大脑正是通过观察外部世界来学习的，通过不断测试和执行其它操作来提升认知能力。同样地，AI也需要大量的数据来训练和学习。现如今，数据形式多种多样，在AI的训练过程中，需要对这些数据进行大量的处理和运算。

VAST是一个功能强大的数据台，其核心是一个名为DataStore的数据持久化层，可用于存储各种类型的数据。与其它厂商相比，VAST的一大优势在于其支持多种数据访问协议，包括NFS、GPUDirect Storage和S3等。这使其成为AI领域理想的数据管理解决方案，因为在AI应用中，数据捕获通常使用对象协议，而训练和推理则使用NFS等协议。VAST可以将数据存储在原生格式中，并通过多种协议无缝访问，满足AI应用对灵活数据访问的需求。

VAST不仅提供数据存储和访问功能，还拥有诸多超越其它平台的强大功能。

表格式数据存储：VAST支持将数据存储在表格式中，并可以使用SQL、Spark和Trino等多种工具进行交互，方便数据分析和处理。

数据引擎：VAST内置数据引擎（DataEngine），支持使用Kafka等协议进行数据流式传输，并根据特定模式对数据进行实时处理。

DataSpace概念：VAST DataSpace旨在消除数据迁移需求，通过共享元数据层，使所有VAST集群能够同时了解相同的数据，无论它们位于何处。数据本身并不需要全部复制，但每个集群都能够访问完整的数据信息。这意味着，在进行分布式计算时，只需要移动需要处理的部分数据，而不是像传统方式那样将所有数据预先复制到指定位置，大大提高了数据利用效率。

VAST DataSpace对于AI领域尤为重要，因为AI应用通常需要大量的数据和分布式计算资源。GPU作为AI计算的主力，往往分散部署在不同的位置。VAST DataSpace能够有效地整合这些分散的GPU资源，并提供统一的数据访问和管理能力，帮助AI应用发挥最大效能。

依托与超微的合作以及首个平台的迭代开发，我们成功将逻辑功能和持久化功能融合至同一技术架构。这项技术最初应用于超大规模计算中心，现已扩展至本地化部署环境。

在AI管道领域，我们已取得骄人成绩，并向市场交付了多个重要项目，已部署数据量超过10EB。今年初，我们开始深入思考VAST的应用障碍。尽管拥有数据平台和正在使用平台的客户，但还有哪些因素阻碍着客户从AI工作负载中挖掘业务价值？我们的结论是，客户需要更全面的堆栈解决方案。仅拥有数据或GPU服务器是不够的。那么，如何将这些要素整合在一起？

今年二月，我们与Run:AI达成合作关系，其在平台运营方面为我们提供了强有力的支持。企业环境与HPC环境截然不同，有非常大量的并行作业和资源争用，多个团队同时执行AI管道不同环节。因此，HPC环境常用传统工作流管理方法（如Slurm）并不适用于企业环境。我们一直与NVIDIA保持密切合作，并成功将NVIDIA AI Enterprise整合至系统中。然而，NVIDIA AI Enterprise在DataOps和MLOps方面尚有不足，这也是我们与Run:AI建立合作关系的重要原因。

这张复杂图生动展现了当前AI工作负载环境的现状，尤其是在服务商领域。从底部的EBox平台开始，HGX、OVX、MGX等多种平台。HGX用于模型训练，OVX用于模型数据准备，MGX则用于模型服务。这些平台不仅硬件配置各异，且操作环境也存在差异。在企业层面，Kubernetes已成为标准化部署，并结合NVIDIA的BCM进行管理。对于采用NVIDIA标准的客户，他们可以使用基本命令管理器和BCM管理的Kubernetes。接下来，我们将深入探讨MLOps和DataOps领域，并带来两个精彩演示：一是利用自然语言查询在视频中识别有趣时刻的视频时刻检测应用；二是基于NVIDIA NeMo框架的模型服务演示。

谈谈数据准备环节。这一环节至关重要，因为它涉及大量数据的处理，是许多工作的核心。我们需要准备好用于训练模型的数据，并确保这些模型能够随着时间推移不断更新。

在预处理阶段，我们将进行一系列操作，包括初始数据的获取和提取，这是项目启动的基础。随后，我们将对数据进行一系列处理，以准备训练所需的部分。这些处理包括常规的去重操作、语言处理（例如句子检测、拼写检查、分块和最终的标记化）。整个处理流程会根据工作负载的不同而有所调整。

我们将使用Apache Spark作为主要工具，因为它支持丰富的机器学习库生态系统。同时，我们将利用Spark-NLP进行大部分自然语言处理工作，并充分发挥Spark内置的MLLib库的强大功能。虽然我个人更倾向于使用熟悉的Python语言，但我们也将充分利用RAPIDS和VAST DataBase这两个重要工具。

在这张幻灯片中，我们将概述RAPIDS和VAST DataBase的应用场景。为了更清晰地理解该物理架构，我们首先介绍DataStore，这是一个广为人知的非结构化数据存储解决方案。原始数据，例如来自S3、NFS和SMB的数据，都存储在DataStore中。DataStore的一大关键特性是其支持这些协议的单一命名空间，这在当前环境中极为便利。这意味着数据可以经由S3进入，但通过NFS进行处理，同时它们都位于相同的命名空间中。

在DataStore之上，我们部署了一个Spark集群，该集群将运行GPU、Spark以及所有相关的Spark库。Spark集群将通过NFS和S3与DataStore交互，并与VAST DataBase建立joins。VAST DataBase是VAST Data Platform上的表格数据存储解决方案，它采用了一种独特的协议，使Spark能够快速访问数据进行scan、filter和project。这使得Spark可以将更多时间用于计算任务，而VAST则专注于数据查找工作。在这个工作负载阶段，我们将对数据进行处理、分割并存储到数据库中，为后续的工作负载阶段做好准备。

谈到此处所应用的技术，首先让我们聚焦于RAPIDS。在该场景下，RAPIDS可视为Python或PySpark与CUDA之间的桥梁，它本质上意味着可以对现有的Spark工作负载进行加速，而无需修改任何代码。因此，对于那些使用数据框架接口或Spark SQL的Spark或PySpark工作负载，RAPIDS可以显著提升其处理速度，这种加速效果实际上非常显著。

需要注意的是，RAPIDS的加速效果仅适用于涉及数据框架和Spark SQL层面的工作负载。如果仅在RDD层面进行编程，则无法显著感受到加速效果。然而，一旦工作负载涉及数据框架、Spark SQL和Spark，RAPIDS的加速优势便会充分展现。

该方法的优势在于，只需有GPU和Spark环境，即可通过加载RAPIDS加速器的jar文件立即启动工作。在许多超大规模计算中心，包括VAST，这种环境配置都十分常见。

这是超微的NVIDIA认证的OVX服务器。这款服务器在同一机箱内配置了10颗强大的GPU。

在这一页上，让我们见证VAST DataBase与NVIDIA GPU支持之间的完美协作。左侧展示的是基准测试结果，右侧则是图表，清晰地呈现了它们各自的优势领域。NVIDIA GPU在joins、aggregations和任何计算任务方面都表现卓越，而右侧的VAST则擅长scan、filter和project操作。因此，当Spark节点访问VAST DataBase时，它们会发送查询计划，并仅获取少量精确数据，这对于这类工作负载至关重要。

另一方面，NVIDIA则专注于joins、aggregations以及集群中发生的计算任务。这就实现了双赢局面：NVIDIA无须耗费时间于scan、filter和project，而VAST也不必处理joins和aggregations，因为这些任务正是GPU的优势所在。

右侧展示的是基于TPC-DS基准测试的测试结果。TPC-DS基准测试极具挑战性，因为它包含窗口函数和SQL查询，这些查询可能导致整个集群因等待单个线程完成排序而陷入困境。我们将未加速的Spark和Hive工作负载进行了对比。此处“Hive”指的是Hive Metastore及其Parquet格式存储的数据。我们使用RAPIDS加速了Parquet Hive Metastore工作负载，并结合了VAST DataBase和RAPIDS。在TPC-DS基准测试中，我们的性能提升超过一倍。但这并非全部，这只是整个基准测试的平均结果。

深入分析前10或前8个查询的性能，我们可以发现结合VAST DataBase和RAPIDS带来了显著的加速效果。例如，第42个查询的执行时间从79秒缩短至几乎可以忽略不计的2秒，这仅仅是启动查询所需的时间。这种卓越的加速效果正是得益于VAST（负责查询的选择性部分）和NVIDIA/GPU（负责计算、aggregations和joins等任务）的强强联合。

-----

问题：数据是在哪里被处理的？VAST在处理或预处理AI数据时，是直接将数据保存在其集群中并就地处理，还是将数据保存在外部服务器后再进行处理？这种处理具体发生在哪里呢？

VAST可以被视为一个黑匣子或表格格式的数据存储系统，类似于Iceberg。在这种架构下，用户可以利用外部Spark集群进行数据处理，该集群可以直接访问存储在VAST集群中的VAST数据库。这两种系统实际上构成了两个独立的层次。

通过结合外部基于GPU的集群和RAPIDS技术，查询的计算部分可以得到显著加速，这意味着VAST集群自身无需配备GPU。同时，我们也意识到许多客户只需要进行简单的操作，他们可能并不需要外部计算集群。因此，我们将更深入地探讨DataEngine功能，以帮助用户在平台内部和外部运行之间找到平衡，这在工作流程层面具有重要意义。

传统上，数据处理操作大多采用批处理模式，数据管道按照从左到右的顺序执行。然而，VAST采用现代方法，并行处理这些操作，而非顺序执行。因此，当数据进入系统时，平台会立即触发预处理和处理过程。大型任务会被分批发送到计算集群，而中小型任务则直接在线处理。与传统的顺序和批处理方式相比，这种并行多进程方法能够显著加快科学研究的速度。

为了加速查询，如果使用GPU处理这些操作，我们需要确保GPU的利用率最大化，避免其空闲等待数据。由于GPU成本高昂，因此最有效的方法是让查询尽可能高效地执行。这正是VAST平台通过其表格格式功能所实现的。 

-----

问题：VAST DataEngine是否利用了VAST平台内部的计算资源呢？

目前，VAST主要利用平台内部的计算资源，并不负责管理外部计算资源。在解决方案开发、系统工程和架构设计等方面，一个核心挑战是如何在VAST平台上合理地运行部分操作和数据处理流程，并确定哪些操作适合在外部环境中执行。

为了澄清一些常见疑问，我想强调一下，当我们谈到“计算”时，主要指的是基于英特尔的计算技术。这意味着VAST使用英特尔芯片在英特尔服务器上执行计算任务，并通过高速后端网络访问数据。从本质上讲，我们的计算方法与其它解决方案并无太大差异。

-----

模型训练一直是许多用户关注的重点话题。市场上充斥着各种专业术语，许多用户可能并不了解这些组件如何协同工作。因此，我们将深入探讨模型训练流程，并揭秘VAST架构的强大优势。在模型训练环节，我们将重点介绍超微HGX服务器。该服务器是NVIDIA DGX的OEM版本，配备了NVIDIA H100 GPU，提供强大的算力。为了进一步提升数据处理能力，我们于本周早些时候推出了Bluefield-3的集成。这标志着VAST架构在扩展数据处理或处理层方面取得了重大进展。

Bluefield-3的集成是VAST架构的典范。通过将DPU直接嵌入服务器，我们实现了数据处理能力的显著提升。每个配备H100的HGX服务器都将搭载一到两个Bluefield-3，负责处理所有数据处理需求。与依赖外部计算层的传统方案不同，VAST架构将Bluefield-3与外部计算、存储引擎和高性能文件访问需求相结合，打造了一个极为强大的动态环境。该环境能够在VAST DataBase、VAST DataEngine和高性能文件访问需求之间实现完美平衡。

Bluefield集成将Bluefield DPU引入HGX服务器，使其能够直接访问我们的持久性数据层。这不仅带来了显著的性能提升，还提供了独特的安全优势。每个DPU都专为与其服务的HGX服务器上的相同租户提供服务。这意味着无论是在多租户环境中还是在不同工作负载相互竞争的环境中，每个租户或工作负载都能拥有自己的隔离环境，确保数据安全性和隐私性。VAST Data Platform则为这些工作负载提供了一个统一的平台， 支持多租户、多工作负载的灵活部署和管理。

模型训练离不开数据，而数据来源多种多样，可以存储在公有云中、由SaaS提供商管理或驻留在本地传统数据存储系统中。对于AI模型而言，融合来自多个不同来源的数据能够带来最佳训练效果。因此，获取新鲜数据成为了AI模型训练面临的最大挑战之一。在许多实际场景中，大家经常讨论的最大问题是反复使用相同的数据训练模型，这会导致模型结果质量难以提升。除非能够持续为模型提供新数据，否则模型质量将始终受限。

数据分散存储往往带来数据传输效率低下的问题，制约了AI模型训练的效率。VAST DataSpace应运而生，为AI模型训练提供高效解决方案。我们将以一个实际案例来展现VAST DataSpace的强大功能。假设数据同时存储在AWS云端和本地，而需要对这些数据进行模型训练。VAST DataSpace可以轻松实现这一目标。

为了直观展示VAST DataSpace的优势，我们将展示可以通过自然语言查询，指示AI寻找特定场景，例如某人进球的瞬间、某人去拿咖啡的地方、或某人走向收银机的画面。无论想要寻找哪种场景，AI都能快速准确地定位。实现这一功能的关键在于，AI需要访问分布在不同位置的数据。VAST DataSpace支持跨地域数据访问，能够轻松整合和利用分散的数据资源。这也是我们选择VAST DataSpace来展示其在AI模型训练方面价值的原因之一。此外，VAST DataSpace还具有极快的缓存读取速度。当开始训练模型时，VAST DataSpace会预先获取部分数据，能够像访问本地数据一样快速访问这些数据，显著提升模型训练效率。

然而，全局命名空间和分布式数据方法一直面临着一致性写入速度慢的问题。这是因为在进行有效写入时，需要进行大量的协调和同步操作，导致效率低下。

我们通过在元数据层进行创新，成功解决了比较慢的一致性写入问题。我们采用了多种技术，包括数据切块和细分以及分布式锁管理，引入了所有权、借贷和共享锁的概念，并能够在文件、对象、表，甚至大文件的子文件级别进行锁的灵活管理。这种细粒度的租约管理能力使我们无需预先准备和移动数据，就能对多种环境下的数据进行AI训练，显著提升了写入速度。

简而言之，位于本地的HGX服务器不仅可以训练本地数据，还可以训练存储在AWS上的数据，无需预先复制或移动所有数据。这对我们的客户来说是一个巨大的优势，可以节省大量的时间和成本。

在AI领域，一个备受关注的案例是《纽约时报》起诉OpenAI擅自使用其数据进行模型训练。这一事件也凸显了数据合规在AI建模中的重要性。对于客户而言，在使用数据进行模型构建时，应重点关注以下三个方面：

数据来源：确保数据来源合法合规，并拥有使用该数据的授权。

数据处理方式（数据谱系）：明确记录数据处理过程，形成完整的数据谱系，以便追溯数据来源和流向。

数据起源和谱系与模型创建历史的结合：将数据来源、处理方式等信息与模型创建过程关联起来，形成完整的模型可解释性链条。

这三个方面不仅在法律层面至关重要，也是确保AI模型合规和可信的基础。即使数据主要来源于内部，也需确保数据获取和使用符合相关法律法规，并能够为模型的合法性提供有力证据。

为应对数据合规挑战，我们引入“数据集”概念，它是一个全面的容器，包含原始数据（带来源信息）、注释、修改后的数据及模型迭代过程。实现这一功能，我们认为需具备三个要素：

结构（Structure）管理，建立清晰的数据流转链条，确保数据来源可追溯、各环节衔接顺畅；

完整目录（Catalog），记录所有数据集相关信息，便于查询和审计；

强大的报告（Reporting）能力，生成详细的数据来源报告，满足法律合规要求，并为模型的可解释性提供有力证据。随着数据规模增长，数据集功能将变得更加重要，为客户提供高效的数据管理和合规保障。

目前，市场上虽有第三方工具提供类似功能，但我们认为将整个流程整合到VAST Data Platform内能够提供更高的效率和一致性，无论数据和模型位于本地还是AWS云端。

那么，结构究竟指的是什么呢？它实质上是一个数据集的概念，包含了数据的跟踪和谱系信息，类似于Git的版本控制功能。当需要使用数据时，可以将其检出、处理并检入，但由于数据量庞大，需要采用不同于Git的方式进行操作。这种结构可以通过API访问，并支持AI在NFS、SMB、S3等多种存储系统上高效运行。此外，我们还在VAST DataBase中实现了目录功能，将所有文件信息存储在同一系统中，这在业界是独一无二的。这意味着我们可以立即访问系统中任何文件的元数据，构建一致且准实时的目录。最后，我们通过MPP、Trino、Spark等客户端和图形界面，支持用户与目录交互并生成各种报告。

在AI领域，我们通常将注意力集中在传统数据平台的前三个环节：数据采集、数据清洗和转换（ETL）。传统上，我们在ETL阶段投入了大量时间，数据清理工作极其耗时，而这些经过清理的数据却经常无法得到有效利用。随后，我们购置了由GPU驱动的巨型机器，如果能够利用GPU来构建模型，那么一切努力都只为构建一个模型服务。但问题在于，构建这个模型的全部意义难道不是为了使用它吗？作为一名AI从业者，我发现前三个环节吸引了过多的关注，而最后的模型服务阶段则显得相对被忽视。值得关注的是，当涉及到推理阶段时，其规模可能是深度学习阶段的10到100倍。现在，我们会说模型本身并不大，但与深度学习所需的数据量相比，模型就显得微不足道了。然而，所有的推理操作都需要在CPU或GPU等设备上执行。

单个查询、提示和响应看似微不足道，但随着规模的扩大，它们会变得极为庞大。尤其是在需要保留不同模型存储库的情况下，因为永远不会只有一个模型，而且模型会不断更新。我们必须为每个模型的不同版本存储所有相关的提示和响应，以备不时之需。与此相关的审计日志和所有围绕推理的机器设备，使得推理成为一个比标准深度学习更大的基础设施问题。

现在，让我们探讨行业如何应对这一挑战。随着更新、更节能的GPU和CPU的发布，我们正与超微等公司展开合作，MGX也在积极利用NVIDIA的GH200等技术。此外，我们还有其它选择来支持推理操作。

在讨论模型时，我们不仅要考虑为LLM模型提供服务，还要考虑为多个不同类型的模型（如视觉、语音、自然语言等）提供服务。因此，一个全面的平台至关重要。如何利用Triton等工具进行MLOps，为模型提供服务、部署、扩展和缩减，以及如何利用公有云或私有云中的基础设施支持这些模型，都是我们需要考虑的问题。此外，我们还需要考虑将哪些AI开发环节纳入模型服务，以及期望模型服务的规模。当模型准备就绪后，如何在生产环境中实际执行这些操作？如何将模型创建、模型优化中的数据管道与模型服务相结合？

以Netflix为例，随着其用户规模的不断增长，他们不得不为全球不同地区的客户提供数千种不同版本的服务。在模型方面，我们也面临着类似的情况，因为我们需要为不同的地理位置和本地敏感性提供不同的模型版本。因此，我们需要像Triton这样的平台来全面了解这个问题。

模型是如何工作的呢？经过大量优化后，模型会被创建并进一步完善，然后存储在模型仓库中。该仓库用于存储所有模型。一些模型可能非常庞大，例如GPT和LLM等，但也存在很多更小但同样重要的模型，它们在视觉处理或视频文本检索方面表现出色。为了支持推理实例的扩展，我们可以根据手头的资源利用GPU或CPU。在某些情况下，某些模型在CPU上运行更高效，而在其它情况下，GPU则更为高效。这取决于模型的特性和我们希望用它们做什么。最后，我们还需要考虑边缘情况，因为最终用户会使用多种不同的平台来访问需要利用这些模型的应用程序。

我们以VAST Data Platform为基础，构建了所有推理操作的基础架构，但请注意，这只是VAST平台的扩展功能。我们已经在数据采集、ETL、数据准备和深度学习等阶段应用了该平台。现在，在数据层面，我们无需单独搭建推理平台，而是可以利用现有平台满足需求。在演示中，我们使用了基于Python的示例，但还有其它框架可以直接集成到我们的平台中。此外，我们还可以再次运行Run:AI MLOps，以及其它可直接集成的平台。我们可以使用MGX来扩展和缩减私有云、DGX或CPU资源。

我们的演示是在AWS上进行的，以展示其运作方式：提示输入，响应输出，这些响应被存储在VAST系统的数据存储中。同时，VAST系统还在进行其它演示，包括数据采集、数据准备和深度学习等。所有这些都是在云端进行，实际运行在VAST软件上。可以看到它如何运行。简而言之，推理是深度学习之后需要关注的下一个重要问题。我们需要了解如何处理它，如何掌握它，以及在推理阶段我们想要做什么。推理的结束并不意味着模型训练的终点，那只是我们努力完成的第一步。

-----

Source:Exploring the Future of AI at NVIDIA GTC; Mar 16, 2024

--【本文完】---

近期受欢迎的文章：

更多交流，可添加本人微信

（请附姓名/单位/关注领域）