不使用GPU的AI：VMware + Intel
演讲人：Earl Ruby，VMware
大约一年前，我开始深入研究Intel的硬件技术，并探索其在vSphere上的应用潜力，力求实现无缝集成，充分发挥Intel硬件与vSphere的全部优势。
今天，我将简要介绍与Intel合作的Private AI项目，讨论Intel AMX CPU的性能特点，并介绍如何配置vSphere以运用这些CPU指令集。之后，将演示在仅使用CPU的情况下运行大型语言模型，全程无需GPU参与。同时，我还会为大家提供一些相关资源。
几个月前在巴塞罗那，VMware宣布了与Intel合作的Private AI，这充分展现了VMware在vSphere上利用Intel硬件运行AI工作负载的决心。我们的目标是用户能在自己的数据中心内部安全、私密地运行这些工作负载，确保数据不会外泄，不与第三方API共享，所有数据都严格保留在你的数据中心内，来保障数据隐私。这样，可以将知识产权风险降到最低，防止外部数据共享，并实现对AI模型在数据中心内的完全控制。
Private AI的愿景以及我们即将推出的相关产品的核心要素，如隐私、数据保护、安全性和韧性，对于Private AI至关重要。
借助vSphere，我们可以访问到一系列可信的安全工具，确保AI工作负载的安全性。此外，vSphere还提供了诸如安全引导、虚拟TPM、vSphere Trust Authority、VM加密以及与主流身份管理产品兼容的丰富功能。网络安全方面，我们依托NSX提供的微分段和高级威胁保护技术。
在CPU上部署AI工作负载的一大优势在于CPU集群的预存性。Intel提供了专门为Intel CPU硬件优化的AI软件套件。他们整合了已经在使用的安全开源工具，并针对Intel CPU进行了深度优化。这些优化已经直接集成到工具的开源库中。因此，你可以利用这些针对性能进行优化的Intel技术，同时保持与熟悉的开源工具的兼容性，无需进行任何修改。
大约一年前，我开始负责评估新的Intel硬件，特别是新发布的Sapphire Rapids CPU。我的工作重点是一项名为AMX（Advanced Matrix Extensions）的功能。AMX引入了一组全新的指令，直接集成到芯片中，旨在通过矩阵运算来大幅提升AI和ML工作负载的性能。这些先进的矩阵乘法器已经集成到每个核心中，使得AI工作负载能够在CPU上高效运行，无需依赖单独的GPU加速器，特别是在采用Sapphire Rapids或Emerald Rapids的服务器上表现尤为出色。
目前，诸如PyTorch、TensorFlow、PaddlePaddle、OpenVINO和vSphere 8等主流框架均支持Intel AMX。原本专为图形处理设计的GPU已逐渐发展成为高效的矩阵处理器，能够并行执行数字矩阵的数学运算，这对于AI/ML任务至关重要。
Intel于2020年6月正式推出了AMX技术，并由Sapphire Rapids微架构首次在Xeon服务器上得到支持。AMX引入了名为TILES的三维寄存器，作为执行操作的加速器。这种架构设计极具扩展性，其初始加速器是矩阵乘法单元（Tile-Matrix Multiply），简称TMUL。
数据直接输入至TILES中，而主机则负责预期并分派工作负载给TILES。一旦数据准备就绪，TMUL便会立即处理数据。每完成一轮乘法运算后，TILES会进行缓存移动，执行单指令多数据（SIMD）后处理，并存储结果。SIMD使得单个指令能够同时处理多个数据，从而大大增强了并行处理能力。
软件经过精心优化，确保主机和AMX单元能够协同工作，从而最大化吞吐量和性能。
该架构的创建者之一Bob Valentine曾表示：“我们在Sky Lake上已经取得了不错的进展，而在Cooper Lake、Ice Lake以及Cascade Lake上又增加了新的指令，但AMX无疑是一个巨大的飞跃，特别是在训练方面。”
随着客户逐步将基于Sapphire Rapids或Emerald Rapids的新主机替换旧主机，他们不仅能享受到传统计算性能的提升，还能获得AMX带来的AI/ML功能。这意味着，你可以在同一硬件上并行执行各种AI和非AI工作负载，极大地提高了硬件的利用率。在虚拟化环境中，你可以根据实际需求灵活地调整IT基础架构，将其重新用于AI和非AI用途，无需额外的投资。
由于Xeon和VMware在云环境中非常普及，并且搭配了优化的AI软件栈，这使得在混合环境中快速扩展计算资源变得轻而易举。客户可以在CPU上运行完整的端到端AI管道，包括数据准备、训练、优化、推理等各个环节，无需依赖单独的GPU加速器。而且，由于运行在vSphere上，可以获得与裸金属相似的出色性能。
借助vSphere，用户能够实现接近裸金属配置的高性能。Intel的开源AI软件为这些工作负载提供了加速功能，并且拥有一个统一的软件堆栈，支持CPU和GPU，被称为oneAPI。因此，如果正在使用oneAPI堆栈，并决定加入GPU，可以无缝运行相同的软件和工作负载，但加速效果更为显著。大多数开源数据准备、ML和DL框架已经针对Intel CPU进行了优化，允许用户继续使用熟悉的工具，无需进行任何修改。
观众：运行这些AI工作负载是否都需要vSphere 8呢？
由于AMX引入了新的指令集，而vSphere运行在虚拟化环境中，我们采用了一个称为硬件版本的概念。在回答你的问题之前，我将先介绍一下这个概念。硬件版本决定了哪些指令将被虚拟化，而vSphere 7最高支持到硬件版本19。AMX包含在硬件版本20中，因此需要升级到vSphere 8。
要在环境中运行AMX，需要配备Sapphire Rapids或Emerald Rapids CPU。虚拟机必须运行Linux系统，并建议使用5.16或更高版本（如5.19）的内核。此外，还需要vSphere 8.0.2和vCenter 8.0.2，并确保虚拟机使用硬件版本20。一旦满足这些要求，AMX指令将在虚拟机中生效，从而可以执行利用AMX的AI工作负载。
观众：你是否发现应用程序的性能有所下降？在启用AMX的情况下，应用程序是如何利用vCPU的？你是否观察到，在启用AMX时，存在不同的工作负载限制？在真实的硬件环境中，最多可以运行多少个应用程序？
我后面有几张幻灯片，展示了我们的工作内容、尝试过的测试，以及为此取得的进展。目前，我正在一个集群上进行工作，实际上我即将进行大规模测试。这样我就能告诉大家：“如果我用这么多vCPU来运行这个工作负载，它的性能会如何？如果我同时运行100个副本，性能又会如何呢？”我会逐步扩展规模，并进行尝试，看看性能何时开始下降。性能肯定会在某个点下降，只是我们目前还不太清楚具体在哪里。事实上，我们还没有进行大规模的测试，但稍后我会展示一些我们之前做过的演示，让大家有个初步的了解。
通过点击这个链接，大家可以访问Intel网站上精选的Intel AI工具。他们已经针对这项技术优化了所有工具，并将这些改进提交到Upstream。如果他们对PyTorch进行了优化，以提升在PyTorch上的工作负载性能，大家可以在Intel网站上找到最新版本的工具。不过请放心，这些改进正在逐步整合到Upstream，最终它们将成为所有开源软件包的一部分。因此，如果想要体验AMX的最新工具，请访问Intel网站。
下面是一张实际工具选择页面的截图，大家可以在这里下载所有流行的AMX工具。
当我刚开始涉足这个领域时，我想：“好吧，让我们试着在这个平台上运行一些LLM。”随后我们进行了比较测试。于是，我拿了一台旧的Ice Lake系统出来，这台机器四年前就进入了我们的AI实验室，运行的是Ice Lake CPU，并不支持AMX。我启动了一个虚拟机，并在那个虚拟机上加载了一个容器。那个容器里装着一个LLM，具体来说是一个拥有70亿参数的Hugging Face模型。
正如我所说，Ice Lake在四年前购买时算是中高端服务器，但你可以看到，整个加载过程显得非常缓慢。这是完全不能接受的。延迟太长，无法满足实际需求。如果您想在生产环境中使用它，显然这样的速度是不够的。
这也是为什么几年前，大家都想使用GPU的原因，因为对于大多数应用来说，CPU的性能是远远不够的。
我刚刚在Sapphire Rapids上启动了，用的可是完全相同的容器、相同的模型、一切都一样，已经准备就绪了。它已经完成了初始化，随时准备为您服务。我说啊，这可比Ice Lake强太多了。就像我前面说的，完全相同的70亿参数模型，完全相同的容器，一切都一样，只是硬件不同，而且全程都没有用到GPU。
观众：在这种情况下，CPU需要以多高的利用率运行才能正常运行？比如，如果我们查看活动监视器或类似的东西，CPU是不是会达到100%的负载，才能产生Sapphire Rapids这样的性能水平？
我认为我们当时使用了56个vCPU和64GB的RAM，但那只是我们随便设置的。可能还可以用得更少，我也不太确定。
观众：明白了，但要达到那种推理水平，它是否占用了所有这56个CPU核心？同时，内存使用情况又是怎样的呢？你有这些数据吗？
这次演示的具体数据我手里没有。我可以找一下。
我现在真正喜欢做的是进行规模测试和类似的测试，正在着手进行，就是想确定运行这些模型需要多少硬件，这对了解可扩展性可是至关重要。我后面还有个演示，我大幅度缩减了规模，就想看看硬件需求能有多低，结果低得让我都惊讶了。
观众：在之前的演示中，谈到了针对Intel扩展和Intel工具的Upstream更新。在这个解决方案中，你们是否使用了任何扩展或工具，还是只是在这个解决方案中使用了Upstream支持？
模型本身已经针对AMX优化过了。它是通过OpenVINO运行来优化为AMX的，但模型是直接从Hugging Face下载的。所以在这个实现里，我们没用到任何特殊的扩展。模型就是直接从Hugging Face拿的。
接下来，我来谈一下LLM微调。在上一个演示中，那只是现成的模型，没有进行微调或其他操作。再次选用了搭载AMX的Sapphire Rapids CPU的vSphere 8环境。使用Converge.io来管理、构建和自动化ML工作流。在一个4节点的Kubernetes集群上运行这个环境。
我们选取了一个70亿参数的LLM模型和一个Finance Alpaca数据集，该数据集包含大约17500个金融数据查询。我们基本上选择了一个通用的现成语言模型，它可以处理英语，并希望用一个Finance Alpaca数据集来对其进行微调。仅使用CPU，没有涉及GPU，大约需要3小时33分钟进行微调。这是在一个4节点集群上进行的。所以，如果你有相应的计算机资源，并且想要对模型进行微调，你完全可以按照这样的流程来操作。
然后，一旦我们微调好了模型，我们就可以运行它。
现在，我们实际上正在运行这个微调后的模型。这些操作都是在一个4节点系统的单个节点上完成的。你现在看到的是3个聊天机器人在这里运行。我们使用了刚刚用金融数据微调过的语言模型。所有3个聊天机器人都在一个单独的Sapphire Rapids主机上运行。现在你可以问一些问题，比如“什么是IR？”它会开始解释“IRR”和“NPV”这些概念。IRR和NPV有什么区别？
观众：在这种情况下，这并不是一个RAG解决方案；它只是基于金融模型微调过的基本LLM？
是的，基本上，在短短三个半小时内，我们就利用现成的组件创建了一个能够进行金融讨论的聊天机器人。一旦微调完成，它就可以立刻投入使用。而且，我们全程都没有使用GPU，全部是通过CPU实现的。
观众：这些聊天机器人是在一个节点上进行通信的，还是一对一的呢？
实际上，它们是在集群的一个节点上运行的。虽然我们在训练时使用了4节点集群，但真正运行时，它们是在单个节点上工作的。
目前看，性能并没有达到饱和。
接下来，我们谈谈GPU和CPU的选择。我一直都建议大家，能用CPU的地方尽量用CPU，真的需要GPU时再使用。比如，如果推理性能对于你的应用场景来说已经足够好，那么使用CPU就足够了。而如果你正在处理批量的ML工作负载，比如我们刚才完成的微调，对于参数少于150亿至200亿的LM，其实CPU也是能胜任的。
在选择使用GPU还是CPU时，运营成本也是一个重要的考虑因素。如果你更注重成本控制而不是即时响应，那么CPU可能是个更好的选择。电力成本正在成为制约因素，可持续性也变得越来越重要。在这些情况下，CPU确实是个合适的选择。
另外，我还想补充一点，即使GPU处于闲置状态，它们也仍然会消耗电力。只有在充分利用的情况下，GPU的能效才会高于CPU。但如果GPU经常处于空闲状态，那么它们可能比CPU更耗电。
观众：我们之前的一些演示中提到了这个问题，但没有深入探讨从CPU过渡到GPU的运营影响。之前的演讲中提到过训练模型所需的强大且持续的计算资源，这通常意味着需要构建专门的GPU集群。如果不这样做，通用的CPU就会成为制约因素。那次讨论主要关注的是计算层面，而网络、存储和充分利用GPU环境所需的其他要素并没有涉及。那么，你们有没有对构建这种极端应用场景的操作影响进行过研究或收集数据，以与一般计算进行对比呢？
是的，这实际上非常依赖于具体的应用场景。我们的客户也经常提出类似的问题。你的应用场景是什么？涉及多少数据？多少网络？由于应用场景的变化非常大，因此很难给出一个通用的答案。
我有个想法。为什么我们不建立一个集群，然后在其中运行模型，设置不同的参数，测量延迟、吞吐量和所有你想自动测量的指标呢？基本上，你只需启动一个容器，让它运行，收集所有的测量数据。然后，我们可以改变一些参数，再次运行它，看看性能如何变化。通过进行一系列这样的实验，我们就可以通过建模来确定，根据应用程序和扩展需求，需要多少硬件来有效地运行它。
观众：在这个领域，似乎有很多研究机会，可以帮助客户了解从CPU到GPU的过渡在实际部署推理到生产环境时的TCO。这是一个经常出现的问题。
但实际上我们并没有太多可靠的数据来支持决策。很多时候，这仍然是一个试错的过程。很多时候，你只能尝试一下，看看它是否适用于你的应用场景。我们真的很希望能有更具体的数据来指导决策。
观众：你提到了微调和推理，并试图理解如何将其应用于生成类似RAG的东西。你在跟踪企业语料库，并通过嵌入等方式构建向量数据库。一旦构建完成，你将使用向量数据库为LLM提供上下文。你认为这对CPU可能适用吗？
是的，我认为这对CPU是适用的。
观众：你有关于这方面的尝试或细节吗？
我知道某个同事正在研究这个问题，但我还没有看到他的结果。我们正在密切关注RAG的发展。一旦RAG数据进入向量数据库，其实它只是在CPU上运行和存储的数据库。
观众：最大的挑战在于将数据放入向量数据库中...
对我们来说，这仍然是一个早期阶段的研究，但请保持关注，我们会在未来发布更多的研究成果。
我们之前也聊到了延迟的问题。我们探讨了CPU和GPU在响应速度上的显著差异。使用GPU确实可以获得更低的延迟。如果应用场景对低延迟和即时响应有严格要求，那么GPU无疑是你的首选。但如果你对延迟有一定容忍度，那么CPU也完全可以胜任。
另外，如果你需要微调参数超过150到200亿的模型，或者经常进行大型模型的微调或构建，那么GPU将是你不可或缺的工具。当然，如果你追求比CPU更高的性能，GPU也是不二之选。正如我所说，我们正在努力为大家提供一些具体的数据，以便你能够更准确地判断何时使用哪种方式。一旦我们有了明确的结论，会及时发布相关信息。
从今天的演讲中，我们可以提炼出几个要点：一是可以考虑将VMware Private AI与Intel结合作为企业解决方案。现在的CPU已经具备了AI能力，大家可以通过Sapphire Rapids和Emerald Rapids CPU完成以前需要GPU才能完成的任务。二是Private AI能够确保你的数据知识产权留在本地。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）