应对生成式AI的复杂性：HPE如何简化AI平台的构建与运维

生成式AI的挑战

1. 数据准备和管理：生成式AI的训练需要整合分散在多个系统中的数据，数据格式复杂，常包含缺失值和噪声，影响模型的训练效果。企业需高效收集、清洗、转换这些数据，并且要满足大规模数据处理和高速存储需求。同时，必须确保数据的安全和隐私合规。
2. 模型训练和部署：训练生成式AI模型需要大量计算资源和长时间的训练，硬件成本高且训练周期长。选择合适的模型架构和超参数至关重要，并且需要有效的版本控制来管理多个模型版本。将模型部署到生产环境时，需考虑其性能、可扩展性和可靠性。
3. 人才和技能：生成式AI的开发要求具备数据科学、机器学习和软件工程等多方面技能，但这类专业人才短缺。项目通常需要跨团队协作，且技术更新迅速，人员需不断学习和更新技能，才能跟上技术发展。
4. 其他挑战：生成式AI项目成本高，企业必须评估投资回报率。技术的伦理问题，如虚假信息传播和算法偏见，需要企业在项目实施前制定应对策略。对于一些应用场景，模型的可解释性和持续监控也是不可忽视的挑战。

HPE Private Cloud AI

核心组件：

• HPE GreenLake云平台：作为HPE混合云战略的核心，HPE GreenLake云平台提供了按需消费、弹性扩展和统一管理的云计算服务，为Private Cloud AI解决方案提供了灵活可扩展的基础设施，并简化了AI平台的部署和管理流程。
• HPE AI Essentials：专门为Private Cloud AI定制的软件平台，包含预装、预配置和预连接的AI工具和框架，例如Apache Airflow、Spark和Jupyter Notebook，以及NVIDIA AI Enterprise软件栈。
• NVIDIA AI Enterprise：NVIDIA AI Enterprise软件栈提供了GPU加速计算技术和AI软件库，用于优化AI模型的训练和推理性能。
• 解决方案加速器（Solution Accelerators）：即将推出的功能，将提供预配置的AI解决方案，涵盖数据、模型和应用程序，用户可以通过简单的点击操作即可部署特定类型的AI应用。

关键特性和优势：

• 简化的AI平台部署：将复杂的AI基础设施和软件栈整合到一个易于部署和管理的平台中，使企业能够快速构建AI平台并开始进行AI模型的开发和部署。
• 灵活可扩展的基础设施：HPE GreenLake云平台为Private Cloud AI解决方案提供了按需消费和弹性扩展的基础设施，以满足生成式AI应用对计算、存储和网络资源的需求。
• 统一的云平台管理：HPE GreenLake云平台提供了统一的管理控制台，用于管理Private Cloud AI解决方案和其他云计算资源，简化IT运维并提高AI平台的管理效率。
• 增强的安全性：提供了多层次的安全措施，例如数据加密、访问控制和安全监控，确保企业数据的安全性和合规性。
• 全面的AI工具和框架支持：HPE AI Essentials整合了各种开源和商业AI工具和框架，为数据科学家、数据工程师和AI开发人员提供了一个完整的AI开发环境。
• 与NVIDIA的深度合作：HPE与NVIDIA的合作确保了Private Cloud AI解决方案能够充分利用NVIDIA的GPU加速计算技术和AI软件库，优化AI模型的训练和推理性能。
• 抽象化和自动化：将AI应用开发和部署过程中复杂的技术细节抽象化，并提供自动化工具来简化工作流程，使不同技术背景的用户都能轻松使用AI技术。

目标用户：

• 数据科学家：提供了一个完整的AI开发环境，包括数据准备、模型训练、模型评估和模型部署等工具和框架。
• 数据工程师：提供了强大的数据处理和分析能力，例如数据采集、数据清洗、数据转换和数据存储等。
• AI开发人员：提供了一个平台，用于构建、部署和管理各种AI应用，例如聊天机器人、推荐系统和欺诈检测系统。
• IT管理员：提供了一个统一的管理控制台，用于管理AI平台的资源、用户和安全策略。

应用场景：

• 生成式AI应用开发：开发各种生成式AI应用，例如文本生成、图像生成、代码生成和聊天机器人。
• 预测性分析：构建预测模型，用于预测未来趋势、识别潜在风险和优化业务决策。
• 数据分析和洞察：从大量数据中提取有价值的洞察，帮助企业更好地了解客户、市场和运营情况。

首先分享对企业基础设施行业的观察。在传统讨论框架中，我们的焦点主要落在现有客户群体上。这些客户通常会采购硬件设备，有时会将其与合作伙伴的软件集成，以构建完整的解决方案。然而，以往的讨论往往止步于此，最终用户往往被排除在决策过程之外。

然而，这一状况正在发生转变。特别是随着软件即服务（SaaS）的蓬勃发展，以及像HPE这样的公有云和混合云供应商对基础设施进行抽象化处理，我们观察到越来越多的终端用户开始积极参与相关讨论。近年来，这一趋势尤为显著——参与机器学习运维（MLOps）工作流的从业者，即那些负责推动生成式AI应用落地的人员，已不再仅仅作为被咨询的对象，而是主动提出他们对基础设施的具体需求。

这些需求正在迅速增长。今天，我想具体分析这些需求的本质、成因，以及为何过分追求快速达成最终目标可能并非最优策略。

我拥有机器人学工程学士学位。机器人学不仅涉及机器学习（ML）的应用,还包括控制算法的运用 - 后者本质上是简化版的机器学习算法。在机器人学领域,核心目标是根据指令实现物理执行。系统需要解读传感器输入和环境数据,据此执行特定动作,最终为用户交付预期结果。

这个过程越自动化越好。举例来说,如果能让机器人在酒店内自主导航,到达指定房间并送上饮品,这将是一项非常实用的服务。也许到2025年,"Toby"这样的服务机器人就能为希尔顿酒店提供客房服务！

分享这个例子是为了说明我对应用机器学习的理解。当我进入企业基础设施领域后,我发现基础设施的购买方与使用方之间经常存在术语理解上的差异。这种混淆通常源于定义不够清晰。因此,在深入讨论之前,我想明确今天我们将使用的术语,特别是在探讨GenAI和AI时。

AI描述了模仿人类行为或决策过程的技术与行为。虽然机器学习通常用于实现AI,但两者并非同义词。机器学习是AI的一个子集,其核心是分析数据集以识别模式并作出预测。通过这一过程构建的模型通常被称为神经网络。

2017年,Google通过引入Transformer模型彻底改变了这一领域。这项创新使大型模型能够生成实时预测,通过逐个token生成响应。Transformer模型成为了众多现代生成式AI工具的基础。它的工作原理是预测序列中的下一个片段,例如句子中的下一个词。比如在"迅速的棕色狐狸跳过懒狗"这个短语中,模型会根据上下文预测每个后续词。

通过在海量数据集上预训练这些模型,产生了生成式预训练变换器(Generative Pre-trained Transformer, GPT)。当这些模型经过优化以适应对话式输入输出时,便发展成了像ChatGPT这样的工具,后者于2022年问世。这标志着大型语言模型(LLM)的崛起,它是Transformer的一个子集,并迅速成为主流AI应用。

分享这些背景是因为,传统上基础设施团队无需过多关注AI抽象层面的具体细节。然而,LLM工作流的需求正在重塑基础设施的范围、设计、部署和服务方式。支持LLM的需求与其他机器学习技术有着显著差异。在探讨对企业基础设施的影响时,理解这一区别至关重要。

Camberley Bates：在深入探讨这个技术栈 - 或者说这些层级时,你如何看待不同角色在其中的作用？特别是考虑到我大致了解你计划在这个产品中关注的方向。

Alexander Ollman：这个问题切中要害,是个很好的引子。因为在接下来的讨论中,我特别想与大家一起探讨并描述那些通常需要处理数据传输到神经网络、进行大数据集预测AI和向生成式AI应用进行向量化的角色。

这些角色通常包括数据工程师(Data Engineer)、数据科学家(Data Scientist)、机器学习工程师(ML Engineer)、AI工程师(AI Engineer)和应用开发人员(Application Developer)。他们不仅在这一领域工作,而且贯穿整个基础设施技术栈。如果可以的话,我想暂时搁置这个问题,因为接下来的讨论将包括一个实际演示,展示如何通过底层基础设施赋能这些角色。

这些应用之间存在显著差异。目前,当我们谈论AI这一术语时,通常指的是预测模型。

例如：

• 预测：预测未来两个季度的房价或股票价格。在机器人学等领域,时间序列估算等时间相关的用例非常普遍。
• 填补缺失值：在数据集中补充缺失项。比如在缺乏大规模数据集的情况下,利用小样本民意调查数据来推断整体群体的观点。
• 检测：物体检测模型得到广泛应用,尤其在医疗领域。

这些都是较小规模神经网络模型的典型应用,它们的性能会随着输入数据量的增加而提升。然而,这些模型通常是为特定用例设计的。例如,每次打开Spotify时,多个数据流水线会触发模型,实时生成个性化推荐。

相比之下,生成式模型规模庞大且计算密集。原因在于它们在海量通用数据集上训练,且本质上设计为通用型模型。

对于特定任务,小型模型配合较小的数据集就能达到相同的准确度。而通用型大模型在处理通用应用时则需要显著更多的计算资源。这种区别对基础设施设计者来说极其重要,因为运行通用模型与特定模型的资源需求有着本质区别。

这正是当前市场的主要需求 - 在过去两年中,它已成为每月的热点话题。如果从股市表现来看,这种热度可能会持续五年之久。

那么,在实践中具体需求是什么呢？

• 希望立即部署代码生成器,使团队在代码项目部署效率提升70-80%
• 希望通过自动从现有组织文档生成报告来提高工作效率
• 希望为新闻通讯生成相关图片,同时规避版权问题
• 希望部署对话式聊天机器人(Conversational Chatbot),能够即时从组织数据中检索答案

在实际应用中是什么样子？它表现为一个已部署的应用程序。

这正是现代AI的魅力所在 - 它是一个针对特定用例定制的ChatGPT。这也解释了为什么2022年11月打开了潘多拉魔盒。并非因为技术本身是新的(ChatGPT背后的模型早在2020年就已公开),而是因为用户首次能够将复杂的处理过程简化为问答式交互这样的简单形式。

每个客户、合作伙伴和利益相关者都迫切希望尽快实现这一目标。众多软件供应商也通过承诺快速部署来迎合这种需求。

要部署这样的应用程序,需要完成以下关键步骤：

1. 数据上下文化(Data Contextualization)：

   应用程序需要组织特定的数据。数据可能存在于：

   - 包含历史记录的结构化SQL数据库

   - 非结构化文档,如PDF或分散存储在多处的对象存储中

   数据收集并非易事,需要合适的访问控制和准备工作。

2. 数据准备(Data Preparation)：

   - 结构化数据(如包含数百万行的表格)需要查询以提取相关子集

   - 非结构化数据(如对象存储中的文件)必须经过筛选以确定相关性

Brian Booden：这是首次区分结构化与非结构化数据。结构化数据来自数据库(行与标准格式),而非结构化数据包括PDF、Word文档和PowerPoint文件。你说的是哪种数据？

Alexander Ollman：两种都包括。非结构化数据可能是存储为对象的文件,如数据湖(Data Lake)中的PDF或JSON文件。结构化数据则涉及查询数据库获取相关信息。获取数据后,还需要进一步处理才能被大型语言模型(LLM)或类似生成式模型使用。

3. 数据选择(Data Selection)：

   数据准备完成后,需要为特定用例选择适当的数据。

4. 模型选择或训练：

   - 选择现成模型

   - 必要时对现有基础模型进行微调(Fine-tuning)

   这一步骤需要软件和硬件基础设施支持。

5. 验证(Validation)：

   验证模型是否适合预期用例,可能包括：

   - Beta测试

   - 用户反馈

   - 法律合规性检查

只有完成这些步骤,组织才能部署应用程序并开始获取收益。

这些步骤都不简单,需要细致规划。尽管像HPE这样的供应商在不断抽象化和简化这些流程,但理解和重视其中的复杂性仍然至关重要。

这些抽象化是如何实现的？从这些步骤来看,它自动化了数据准备工作。它能够简化多数据源的连接过程。它能够创建数据流水线(Data Pipeline),使我能够针对任何特定用例自动启动数据流程。这些流水线可以基于事件或特定时间点触发 - 每周一次、每季度一次 - 而这一切都可以自动化。这样一来,这些工作就不再需要我手动执行了。

这还可能包括模型编排的自动化。例如,系统可以根据自然语言用例从模型库中选择合适的模型,为我启动它,并确保选择了正确的模型,让我无需为此操心。

也许我们根本不需要这么复杂。或许我们可以通过一些预打包的LLM应用程序来实现更高层次的抽象,只需将数据传递给它们即可。这些抽象的效果取决于实施人员对系统的理解程度。这个概念贯穿各个层级的角色,不仅包括数据工程(Data Engineering)和数据科学(Data Science)领域的专家,还包括基础设施层面的工作人员。

这一点极其重要,因为如果缺乏对数据的深入理解 - 确保数据经过精心策划并遵循所有必要的准备步骤 - 输入生成式模型的数据有时可能会产生偏离预期的结果。对某些场景这可能无关紧要,但对于大型跨国公司、银行、航空公司或任何需要日常与客户互动的组织来说,这种偏差是绝对不能接受的。

举例来说,假设你是一家大型航空公司,需要安抚一位因模型错误解读政策而受到误导的客户。这种错误源于模型接收的上下文数据未经充分训练,是急于求成的结果。如果没有适当的保障措施,或者对训练、构建和验证过程重要性缺乏理解,模型可能会造成严重损害。

比如,一个实施不当的模型可能会建议客户购买竞争对手的汽车,或者提供完全不相关的信息,如制作鸡蛋沙拉三明治的方法。这些不可预测的结果源于数据或实施错误,在企业环境中是难以接受的。特别是在昂贵的基础设施上运营时,仅仅生成响应就需要承担可观的成本。

我们该如何应对这个挑战？抽象化固然重要,但我们还需要加速AI投资(无论是预测型还是生成型)的价值实现。然而,这必须建立在充分理解底层过程的基础之上。

让我举个例子,我的第一台3D打印机是大约十年前购买的Robo 3D。它最初是一个Kickstarter项目,旨在成为首批商用家用3D打印机之一。不幸的是,这台打印机75%的时间都无法正常工作 - 要么无法正确启动、无法在打印床上附着,要么在完成第一层后就失去精度。这通常是由于水平校准不当、温度问题或环境因素导致的。

经过多个不眠之夜的故障排查后,我的搭档下了最后通牒："要么选我,要么选打印机。"时光快进到今天,我拥有了一台Bamboo X1 Carbon,这是一款经过显著改进的型号,开箱即可使用。我不再需要手动拼接耗材或解决琐碎问题。这台打印机成功将复杂性抽象化,同时提供了流畅可靠的使用体验。

然而,这种抽象化之所以有效,是因为我能够理解它所简化的复杂性。当出现问题时,我知道该预期什么,也知道如何与Bamboo的支持团队沟通。这种理解对提升用户体验和故障排除至关重要。

这引出了生成式AI应用程序的七个步骤及其抽象化的具体实现。底层基础设施需要几个关键组件：

• GPU加速计算：现代模型规模已不再是几十或几百MB,而是以十GB计。例如,NVIDIA最强大的GPU拥有80GB显存,仅能容纳ChatGPT模型大约四分之一的规模。
• 高速存储访问和网络：这些组件对于将模型高效传输到GPU显存中至关重要。
• 基础设施抽象化：多年来,基础设施领域一直致力于抽象化技术复杂性。通过虚拟化软件和资源调配,为不同角色提供支持,使他们能够有效执行机器学习运维(MLOps)中的每个步骤。

只有在这些层次就位后,软件应用层才能管理内部训练、数据准备工具和最终用户应用程序。即便如此,我们仍需要高效地部署和推理模型。

抽象化这些层次一直是我们努力的方向,这不仅是为了减少痛点,更是为了实现平台级能力。基础设施仍对专业人员开放,同时将工具和资源交付给需要的角色。这种方法使数据科学家、工程师和其他专家能够专注于自己的任务,而无需过多关注底层的计算和存储系统。

在了解机器学习运维(MLOps)工作流程的所有步骤时，有一个关键点我们尚未涉及，那就是实现这七个步骤所需的底层基础设施的重要性。

接下来我们将聚焦于底层基础设施，以及HPE Private Cloud AI提供的解决方案。我将通过一个实际案例并现场演示Private Cloud AI平台来详细说明。这不仅展示了HPE在私有云产品上的投入，更重要的是体现了我们与各类群体的深入互动——不仅包括基础设施管理员和数据库管理员，还包括那些致力于打造下一代企业创新的专业人才：数据科学家(Data Scientists)、数据工程师(Data Engineers)、机器学习工程师(ML Engineers)、AI工程师(AI Engineers)和应用开发人员(Application Developers)。

与HPE的众多深入交流一样，这次讨论也是通过HPE GreenLake进行的。Private Cloud AI这款产品集中体现了HPE自近十年前从惠普公司分拆后确立的愿景。该愿景包含两个核心目标：

1. 突破传统基础设施供应商的角色定位——不再局限于提供客户自行管理的硬件和软件，而是致力于为复杂场景提供定制化解决方案。

2. 认识到尽管公有云服务能带来初期价值，但客户越来越看重数据主权和基础设施全生命周期的完整控制权。

Private Cloud AI正是这一愿景的具体实现。它提供真正的云计算体验，通过基础设施抽象化简化最终用户操作，同时保障客户对网络、存储和计算资源的完全控制权和定制能力——这一切都在客户自有数据中心内实现。

Private Cloud AI是一个面向数据工程、数据科学和机器学习的基础设施技术栈，以设备形式交付，专门服务于GenAI时代。它简化了工作流程，就像微波炉几十年前简化了食物加热过程一样。这个技术栈整合了硬件、软件、网络、存储和计算资源，具备以下功能：

• 在基础设施上自动部署和扩展容器化(Containerized)应用程序
• 通过统一的管理控制台，根据不同角色需求集中管理应用程序和用户

系统定义了三类主要角色：

1. 云管理员(Cloud Administrator)：负责管理基础设施访问权限，如私有云解决方案，快速为用户分配所需资源。

2. AI管理员(AI Administrator)：负责用户接入管理，控制跨应用程序的身份和访问权限，确保数据源无缝集成——全部通过统一界面操作。

3. AI开发人员(AI Developer)：专注于其专业工作（如运行查询、构建模型），无需关注基础设施管理细节。

例如，开发人员可以直接使用Jupyter Notebook、Apache Airflow或Spark等工具，而无需手动配置虚拟机或编排Spark节点。

系统的用户管理非常直观。管理员可以通过统一界面实现：

• 在Private Cloud AI实例中为团队或个人分配角色
• 设定基础设施和数据访问权限，精确到结构化和非结构化数据源中的具体表格或存储桶级别

举例来说，我可以将用户Abby指定为Private Cloud AI管理员，并设置具体的访问限制。这些限制可能包括CPU、GPU或内存配额，以及特定数据资源的访问权限，如PostgreSQL数据库中的特定表格或存储中的对象。

这种精细化的控制确保了数据访问的安全性和效率，无需手动管理凭证——有效避免了诸如将AWS私钥存储在不安全位置等问题。

这种控制对于涉及结构化和非结构化数据的应用场景尤为重要。例如：

• 数据工程师登录平台查询银行交易相关的PostgreSQL表格
• AI管理员与数据库管理员协作，验证并连接各类数据源，如Snowflake、Oracle、MySQL或Microsoft SQL Server，实现无缝集成

需要注意的是，并非每个团队成员都需要完全的数据库访问权限——只有负责管理连接的管理员才需要这些权限。

对于特定的数据格式，如Delta Lake和Iceberg表——这些通常用于大规模数据处理。Delta Lake类似于Parquet文件格式，常用于大规模数据集查询。Iceberg则是另一种优化查询性能的结构化数据格式。在连接数据库时，Private Cloud AI需要进行身份验证，确保只有获得授权的用户和角色能够访问特定资源。这种机制既保护了细粒度数据安全，又使组织能够充分利用这些数据来推动AI驱动的业务洞察。

现在我们可以建立数据连接。以这个PostgreSQL服务器为例，连接建立后，平台上的所有用户都能使用相同的身份验证访问此数据源。

最便捷的是：作为用户，我可以通过同一个连接器访问该数据源，对特定表格执行SQL查询。我可以生成SQL查询并将结果以CSV文件、Parquet文件或其他任意格式保存到本地。

此外，这个数据连接器还支持将数据源与HPE Private Cloud AI的软件平台AI Essentials中的各种工具集成。

进入工具和框架界面后，我可以看到各种应用程序。稍后我会详细介绍NVIDIA AI Enterprise技术栈，这些都是在AI Essentials中预装、预打包、预连接并预配置的应用程序，专门用于Private Cloud AI。

让我们以数据工程师的日常工作为例。作为新团队成员，我首先需要与经理确认以下事项：

• 是否有权限访问所需的客户数据表
• 结构化数据源是否可用
• 身份验证是否已完成配置
• 所有相关文件是否已存储并更新在我们的存储卷中（无论是在云服务商环境还是S3存储桶中）

获得访问权限后，我需要构建数据流水线(Data Pipeline)。这涉及从数据源实时提取数据，进行转换（如筛选出相关客户数据），并将其加载到大型语言模型(LLM)可访问的系统中。这就是经典的ETL过程。

Apache Airflow多年来一直是最受欢迎的开源工具。每个数据工程专业的研究生都熟悉它的使用。但通常需要联系IT管理员来部署必要的基础设施。需要注意的是，身份验证不仅对工程师和Airflow必要，对所有访问数据源的用户同样重要。

另一个关键需求是开发环境，用于编写数据流水线，无论是使用R还是Python。Jupyter Notebook是最流行的开发环境。传统上，部署这个环境需要向IT提交申请来启动Jupyter Notebook服务器，随后还需要将服务器节点与Airflow实例和其他数据源连接。

而在HPE Private Cloud AI中，用户可以直接登录并访问Jupyter Notebook环境。例如，在这个Notebook中，我可以使用内部Token进行身份验证，该Token能在Private Cloud AI平台的所有容器间无缝传递信息和认证信息。

接着，我可以连接到S3实例，比如存储层上的本地S3存储。这种连接是预配置并预认证的，允许查看环境中所有有权限的存储桶。如果存储桶访问权限变更，重新执行相同请求会自动返回更新后的列表。

作为数据工程师，我无需关注底层基础设施，登录即可开始工作。

这种便利性不仅限于数据工程。比如，在处理大型表格查询时，我可以将查询分布到多个计算节点上。就像在超大Excel文件上运行VLOOKUP一样，这类操作在普通笔记本上可能需要数分钟甚至数小时。对于包含数百万行和数百列的数据集，处理时间可能长达一天。

通过HPE Private Cloud AI，我们可以在基础设施层面将工作负载分布到高性能计算节点上。这是通过分布式大数据查询引擎Apache Spark实现的。Spark采用主从架构(Master-Worker Architecture)，主节点与工作节点协同执行分布式任务。传统上，部署这类基础设施需要安装主节点、连接工作节点并处理作业认证。

在我的Jupyter Notebook环境中，可以无缝编写和管理Spark查询。使用Spark内核，我能直接从Notebook执行分布式查询。例如，可以像更新Token一样简单地管理Spark作业。

我们的目标不是省略部署大型语言模型的必要步骤，而是简化终端用户的基础设施配置过程。终端用户希望专注于自身任务，而不必操心基础设施管理。同时，组织内的基础设施专家仍保持对硬件和软件架构的完全控制。

这种简化方法同样适用于数据科学领域。假设我想基于聊天机器人(Chatbot)交互中发现的模式分析客户数据。例如，测试可能显示某些查询经常出现。我可以请数据工程师提供一个匿名化数据集，去除客户ID但保留交易模式。

利用这些数据，我可以构建一个预测模型(Prediction Model)，用于处理自然语言查询并预测最相关的字段或交易类型。

在模型存储方面，传统方法可能简单地将其保存为文件。但现代机器学习工作流程(ML Workflow)是迭代式的。模型会持续优化，通常涉及数十个甚至上百个版本。多个团队成员可能同时处理同一个模型。

这个迭代过程通常通过实验管理来实现。即使有模型在生产环境运行，也会同时进行多个实验，以确保新数据的引入不会导致模型漂移(Model Drift)或准确度下降。这些实验还有助于验证模型的无偏性(Unbiased)及长期准确性。

在这种情况下，我们需要将模型存储在模型注册表(Model Registry)中，以追踪所有版本的多个实验。当选定某个模型用于生产环境时，需要一个集成注册表的跟踪平台，如MLflow。在这个环境中，MLflow通过身份验证与每个数据源和应用程序连接。例如，这里可以看到MLflow用于存储模型和训练运行日志的存储空间。

Max Mortillaro：组织如何使用这个系统？有什么门槛吗？并非所有组织都是HPE客户，也不一定愿意签订多年合同。如果他们想要开始某些操作，能否避免冗长的谈判过程？

Alexander Ollman：你说的是这里展示的软件和编排系统吗？

Max Mortillaro：不，我指的是你展示的这个产品。这些大多是开源工具，但如果想采用你提出的集成方案，HPE在其中扮演什么角色？

Alexander Ollman：明白了。你看到的这些是HPE Esmeral的专有技术，是HPE AI Essentials技术栈的基础。这个技术栈是专门为HPE Private Cloud AI定制的。需要说明的是，你不必作为产品的一部分购买底层基础设施。AI Essentials也可以部署在现有的基础设施上。

Max Mortillaro：你是说采购本地基础设施。通过GreenLake是否可以使用类似的产品？

Alexander Ollman：是的。你看到的这种编排系统——连接和身份验证软件——是由HPE Esmeral技术栈提供的。即使没有这个技术栈，你也可以手动部署Airflow或Spark等组件，并通过GreenLake合同使用这些资源。

在数据科学领域，工作流程类似。我只需要存储和使用模型，而不必联系IT部门来配置虚拟机(VM)、连接存储桶或启动MLflow。登录后，即可打开MLflow，通过其用户界面查看实验，并管理所有保存的模型及其版本。

例如，我可以查看生产环境中模型的归档版本。在Notebook环境中，仍需通过导入MLflow、更新身份验证Token并实例化MLflow客户端来建立MLflow连接。完成这些后，就可以立即开始运行训练作业并使用模型。

Camberley Bates：看来你们主要是利用开源工具为客户提供解决方案。

Alexander Ollman：是的，这是我们的基础服务。采用这种方法是为了能够立即为客户创造价值。

Camberley Bates：在这个技术栈中，除了集成工作，HPE的知识产权(IP)包括哪些内容？

Alexander Ollman：这是个复杂的问题，尤其是在软件层面。HPE的知识产权主要体现在基础设施方面——包括支撑上层应用程序的硬件和软件。

Camberley Bates：你提到的Esmeral是从收购BlueData和MapR后开发的。这些产品的哪些部分被整合到了这个技术栈中？

Alexander Ollman：以BlueData产品为例，它是一个容器编排平台，现已发展超越基础设施层面，提供了出色的用户界面体验。它还集成了Kubeflow等工具，用于部署Jupyter Notebook服务器。

虽然模型注册功能并非BlueData的专有技术，但它展示了将开源组件整合成一个无缝平台的价值。

我们提供的是一个基础设施平台——包含软件和硬件——用户可以在其中使用自己的工具，只要这些工具支持容器化部署。这种方式确保了应用程序的认证和互操作性。

我们构建这个平台时充分考虑了机器学习运维工作流。由于终端用户已经在使用开源工具，我们的重点是将这些工具高效地整合到平台中。

Camberley Bates：关于数据，假设我的数据存储在文件系统或Nimble存储设备的结构化数据库中，我是否需要先迁移或进行ETL处理才能在系统中使用？然后，你们会对这些数据进行分类并管理隐私，对吧？

Alexander Ollman：这属于数据工程工作流程的一部分。

Camberley Bates：我是否必须将所有数据集中在这个环境中，而不是使用数据湖(Data Lake)持续导入数据？

Alexander Ollman：不必如此。对于大型现有数据库，我们可以创建连接器(Connector)。

Camberley Bates：你们有连接器？

Alexander Ollman：是的，确实如此。这些数据连接器支持与结构化数据库和对象存储的集成。除非必要，数据本身不会导入平台。相反，我们只会引入与特定用例相关的数据。数据可以临时存储用于查询，或进行缓存以减少重复处理。

从数据工程的角度看，一旦创建了与结构化数据源的连接器，就可以执行实时SQL查询。为了高效完成这一过程，需要一个经过训练的模型来处理和解释查询结果。

例如，数据科学家可能会创建一个模型，用于解释SQL查询结果并将其上下文传递给大型语言模型(LLM)等系统。然而，我的应用程序可能需要两个生成式模型：一个用于对话任务（如Meta的Llama 3.2），另一个如SQLCoder，用于将自然语言查询和数据库架构转换为SQL查询。

这些模型可以部署为端点(Endpoint)。传统上，这涉及手动步骤，如从Hugging Face或NVIDIA等模型注册表获取模型，通过VLLM或FastLLM等推理引擎处理，并将其加载到GPU内存中。

然而，最终用户应用程序通常通过API连接。为简化这个过程，我们可以将推理过程封装在REST API服务器中，并作为容器部署。在基于Kubernetes平台运行的HPE Private Cloud AI中，这些容器可以动态扩展。无论是支持单个用户还是10万用户，基础设施都能自动配置资源，并无缝扩展到多个私有云实例。

这种方法通过允许私有云实例共享基础设施来保护AI投资。统一的控制平面使扩展突破单个集群的限制，确保资源高效利用。

从最终用户角度看，一切都是透明的。例如，启动LLM非常简单。

使用Kubeflow等工具及其原生扩展KServe（预装在AI Essentials中），我可以通过运行Kubernetes命令并使用配置文件部署容器化模型。这个配置文件指导Kubernetes如何部署，包括容器的扩展方式。

为优化性能，模型文件（可能有几GB大小）在Private Cloud AI中本地存储。这避免了从远程存储库获取文件时的延迟，特别是在部署多个容器实例时。

HPE与NVIDIA AI Enterprise的合作进一步优化了这个过程。NVIDIA提供用于模型推理的框架和库，而HPE专注于企业级可扩展性。我们共同设计了易于快速扩展的大型企业工作负载容器化应用。

这种联合工程努力持续推进，将NVIDIA在AI工具方面的专长与HPE在基础设施方面的能力相结合，为企业提供强大且可扩展的AI解决方案。

在部署Llama 3等模型时，我可以展示端点的实际样子。我想快速展示查看模型端点的方法——包括我正在使用的端点、我有权限访问的端点，或我同事的端点。

对于那些已经构建了使用云服务提供商托管的LLM生成式AI应用的开发者——可能使用OpenAI、Microsoft、Google或Anthropic的服务——通常会获得指向LLM实例的端点。这正是我这里展示的内容。我可以复制这个URL，查看运行的模型及其当前资源使用情况。

以我启动的LLM为例，我快速对其格式化并以表格形式显示。我可以查看每个模型实例。如果需要扩展，完全可以实现。例如，当前扩展设置为1，但我可以轻松调整。这是我的端点，我可以识别具体模型，然后将其集成到Notebook环境或应用程序中。

我可以在这里快速安装它，将其命名为虚拟助手。我会将其分配到"AI数据基础设施工作日"项目，并归类到"数据科学"类别下。

Brian Booden：这是端点的模板结构吗？根据构建的容器，它是否只是重用该容器的端点，为GET、PUT、DELETE等操作创建唯一的端点？

Alexander Ollman：没错。我们与NVIDIA的合作涉及所有必要组件，用于提取模型、封装便于使用，并支持可扩展性。NVIDIA已完成这些基础工作，而我们确保其能大规模部署。

Brian Booden：回到容器化讨论，你是说一个容器的属性可以传递到另一个容器吗？能否扩展现有容器——例如，基于它建立基准，然后在此基础上扩展？

Alexander Ollman：不完全是。无法动态管理容器资源，超出增减资源的范围。例如，如果模型需要更多计算能力，我可以分配更多资源，或根据需要减少。但我可以复制容器。最好的是，复制的容器会保持相同的端点。

Brian Booden：所以你是将底层基准数据架构作为模板？你复制容器并在此基础上扩展？

Alexander Ollman：是的。所有内容都扩展到Pod级别。虽然Pod会被复制，但Pod内的容器端点保持一致。

让我展示一个例子。在Kubernetes环境中部署容器时，通过蓝图提供说明——通常是Helm图表(Helm Chart)。大多数软件供应商的云原生应用，无论是在AWS、GCP还是其他Kubernetes平台上，通常都带有Helm图表。你可以在这里导入这些图表，拖放它们，并指定命名空间(Namespace)。例如，我将它放入我的命名空间，并修改图表以引用正确的容器。我将其命名为"虚拟助手"。

这是在Kubernetes中部署应用程序的典型过程。重要的是，这个应用程序——与其他应用一样——代表了HPE在这领域收购的成果。它是经过精心设计的用户体验，旨在简化操作。虽然在Kubernetes上部署应用程序确实有学习曲线，但大多数Helm图表都是预打包的，只需少量调整就能与HPE AI Essentials中的连接器本地集成。

随着平台的持续发展，这些过程将被抽象为点击式UI。很快，部署应用程序和LLM将变得像点击几下那样简单。例如，NVIDIA提供了他们的NeMo推理服务器(NeMo Inference Server, Nim)。这个设置不仅支持LLM，还支持嵌入模型(Embedding Models)，这些模型将文本和图像转换为向量——这种格式非常适合LLM使用。随着联合工程努力的继续，支持的模型目录将不断扩展。

现在我已经将端点和应用程序连接起来。让我导入一些库——这里有很多，因为我在这个Notebook中实验了一些额外功能。例如，我计划从S3存储桶提取数据，如PDF文件，并创建向量数据库(Vector Database)。不过，现在我要展示如何在这个Notebook环境中使用相同的端点。

这个Notebook是一个容器。我刚初始化的应用应该已经就绪。刷新后它会立即显示。通过这个环境，我可以从LLM端点进行推理(Inference)。我确保Notebook内核在运行，更新Token以实现容器间通信，并将请求指向正确的模型端点。

这个过程使用了持久卷声明(PVC, Persistent Volume Claim)，这是一种与HPE Private Cloud AI中底层GreenLake for File相关联的临时存储。访问权限决定了哪些用户可以共享文件并有效协作。例如，这些共享文件夹使团队成员能够访问相同资源。

对于模型推理，NVIDIA的集成简化了这一过程。他们与LangChain等开源工具的合作使单个对象实例能够处理LLM的交互。例如，我们定义端点、模型和认证Token，通过API服务器发起请求。结果以JSON格式返回，然后解析为可用格式。

这个框架不仅局限于Notebook环境。例如，您可以开发一个支持实时拖放上传功能的终端用户应用程序。上传的内容可以被向量化并进行嵌入，为LLM提供响应所需的上下文。这种被称为RAG的方法通过从向量数据库中检索并整合相关数据，显著提升了模型回答查询的能力。

Andy Banta：在基础设施方面，诊断能力和可审计性是至关重要的。尽管这对数据科学家很有吸引力，但管理者需要能够有效监控并排除环境中的故障。

Alexander Ollman：在报告功能方面，HPE AI Essentials 提供了全面的资源管理视图。管理员可以接收各类通知和日志。通过与 OpsRamp 的集成，我们进一步增强了基础设施的可观察性和报告能力。

Andy Banta：诊断能力是另一个需要关注的问题。当环境出现故障时，问题定位的难度如何？您的快速应用部署运行良好，但这种效果能否在整个技术栈中得到同样的实现？

Edward Holden：为应对这些挑战，我们已经为Private Cloud AI建立了卓越中心（CoE）。客户可以通过单一支持联系人获取服务，避免了需要与多个供应商沟通的困扰。如果NVIDIA的NIM或其他组件出现问题，我们会直接与NVIDIA协作解决。卓越中心统一处理所有问题，确保支持服务的无缝衔接。

Andy Banta：VMware Cloud Foundation在其中担任什么角色？

Edward Holden：它是控制节点的组成部分。私有云控制平面运行在虚拟机（VM）上，并与GreenLake平台实现互联。基础设施充分利用了Private Cloud Business Edition的自动化功能，包括OneTouch升级功能，可用于补丁更新和基础设施增强。这些操作都在后台自动完成，大大简化了客户的使用体验。

HPE Private Cloud AI产品是我们混合云愿景的集大成之作。我们不仅抽象化底层基础设施(包括硬件和软件),还将各个组件整合起来,提供统一的使用体验。我们的目标是在与这些基础设施协同工作的同时,保持对基础设施及其相关数据的完全控制权。

关于将基础设施与终端用户抽象化的重要性,这值得我们深入探讨。我们演示了如何使用部署在Private Cloud AI之上的HPE AI Essentials,以及它如何通过GreenLake Cloud平台作为机架设备运行。GreenLake Cloud平台,尤其是Private Cloud Enterprise商业版,能够连接并自动配置整个机架系统。

我们的首席技术官和首席执行官Antonio Neri在今年早些时候的HPE Discover大会上,在拉斯维加斯Sphere现场承诺,只需三次点击就能完成基础设施的部署。在完成基础设施搭建后,我们希望能够抽象化MLOps工作流所需的各个组件。在我今天的第一个演讲中,我强调了理解和重视这个过程中每个步骤的重要性。

在软件层面,抽象化可以采取多种形式。我们希望确保不削弱那些已经在数据工程(Data Engineering)和数据科学(Data Science)领域使用数据和相关工具的专业人员的权限和自主性。虽然他们具备这样的专业知识,但现在我们有了能够自动完成所有工作的工具,这可能会使某些工作显得多余。这就像是在没有充分理解各个步骤的情况下使用快捷方案。

我会将其比作80年代的微波炉食谱——虽然这些食谱能快速完成烹饪,但成品的口感不一定理想。即便大部分繁重工作是由同样的设备完成的,理解整个过程中的每个步骤仍然至关重要。

如前所述,我们希望在HPE Private Cloud AI产品中抽象化的底层基础设施包括GPU加速计算、模型存储(显然,这些存储需要具备高速度和足够大的容量,以支持网络中其他节点上的GPU)以及高速网络。

我们需要通过虚拟化软件层来访问这些资源。直接连接这些资源可能比较耗时,因此如果能够通过应用程序和管理功能进一步实现抽象化会更好。这正是我们希望通过HPE Private Cloud AI实现的目标：从基础设施角度实现抽象化并简化使用过程。

在HPE Private Cloud AI中,从软件角度来看,我们能够实现以下功能：借助HPE AI Essentials工具集,用户和其他软件供应商可以安装、部署并创建自己的自动化方案,针对其组织的特定数据架构进行定制。这使得自动化成为可能,消除了对数据源互连性的顾虑,并能自动检索、收集和选择特定用例的数据。我们正在迈向这样一个世界：未来某天,基于我们平台开发的软件应用程序可以通过简单的提示来执行任务。

我们现在已经处于这样的世界,而且距离这一目标可能已经不远了。无论是第三方供应商提供的软件,还是基于组织特定数据特征的内部开发项目,我们都有相应的平台来部署和构建。

我们与NVIDIA的合作伙伴关系也体现了这一点。我们致力于将大型语言模型(LLM)的开发和部署抽象化,这不仅包括基于文本的模型,还包括嵌入模型和代码生成模型。NVIDIA与我们的合作进展顺利,共同致力于使这些组件能够扩展到企业级别。NVIDIA的核心优势一直在于与库和框架的协同,特别是在其GPU和硬件领域。目前,他们正在向软件领域扩展。众所周知,在基础设施层面扩展软件并非易事。幸运的是,他们选择了最佳的合作伙伴。

通过这个应用程序,我们可以将所有这些内容整合起来,借助HPE Private Cloud推出的解决方案加速器(Solution Accelerators)来实现流程自动化。通过解决方案加速器,我可以利用已连接的数据源,选择特定的文件或表格,选择大型语言模型或其他生成模型,并将它们预配置且与终端用户应用程序预先连接。所有这些都可以通过一次点击来部署。这就是HPE Private Cloud AI即将推出的解决方案加速器所带来的功能。

虽然目前的设计可能会有所调整,因为我们正在实施新的前端开发标准,但统一性正在不断加强,这对于我们这样规模的企业来说确实充满挑战。这是我们计划在今年年底前正式发布的目标。

我们的目标是抽象化流程,同时保持您对所有底层组件的操作能力。您仍然可以获取数据、创建向量数据库,并自动化构建一个利用这些数据的用户界面。这确实可以实现,但不仅仅是简单地拖放PDF文件。这还涉及管理包含数百万行的表格,或处理成千上万的文件,并从中选择适用于特定用例的内容。我们希望能够将这一工作流程扩展到企业级别,同时保持简单直观的用户体验。

参考资料：

1. Ollman, A. (2024, October 2). A Step-by-Step Guide to Build Robust AI with Hewlett Packard Enterprise [Video]. YouTube. https://www.youtube.com/watch?v=1FglwbpS_Ys
2. Ollman, A. (2024, October 2). Building a Generative AI Foundation with HPE [Video]. YouTube. https://www.youtube.com/watch?v=AIG4-O9ZVRY
3. Ollman, A. (2024, October 2). Streamline AI Projects with Infrastructure Abstraction from HPE [Video]. YouTube. https://www.youtube.com/watch?v=5WXEBdGFDQI

本文转载自 ​​Andy730​​，作者： 常华Andy