介绍自 2016 年 Uber 首次使用基于规则的复杂机器学习模型为司机-乘客匹配和定价团队服务以来，机器学习 (ML) 已迎来 8 周年。从那时起，我们取得了长足的进步，转向将深度学习模型作为当今大多数业务关键型应用程序的核心，同时积极探索生成式 AI 模型提供的可能性。随着 AI/ML 模型的复杂性和规模不断激增，对高效基础设施的需求也日益增长，以有效支持这些模型。在过去几年中，我们战略性地实施了一系列以 CPU 和 GPU 为中心的基础设施解决方案，以动态扩展我们的系统并满足不断变化的 ML 用例格局。这一演变涉及定制的硬件 SKU、软件库增强、各种分布式训练框架的集成以及对我们端到端 Michaelangelo 平台的持续改进。这些迭代改进源于我们一路走来的学习成果以及对行业趋势和 Uber 发展轨迹的持续调整，目的都是为了满足我们合作伙伴和客户不断变化的需求。
目标和关键指标当我们于 2023 年 2 月宣布从本地向云基础架构过渡时，我们跨团队的硬件/软件共同设计和协作由以下具体目标驱动：
最大限度地利用现有基础设施为新兴工作负载（如生成式人工智能）建立新系统为了实现这些目标，我们概述了指导我们进展的不同关键成果和指标。
可行性和可靠性：机器学习用户希望在预期的时间范围内（根据复杂程度，可能是几周或几个月）成功收敛训练任务，且不会出现错误。例如，训练更大、更复杂的模型（如 Falcon 180B™）可能需要数月时间，而较长的训练时间会增加出现可靠性问题的可能性。因此，我们的目标是为所有训练依赖项实现 99% 的正常运行时间 SLA，以确保一致且可靠的结果。
效率：我们注重效率，包括对各种 GPU 配置进行全面的基准测试，并评估针对特定工作负载定制的本地和云 SKU 的性价比。我们使用模型浮点利用率 (MFU) 等指标来衡量训练效率，以确保最佳 GPU 利用率。我们的目标是防止 GPU 闲置，通过反应性扩展在服务的非高峰时段适时使用训练作业，并保持高利用率以最大限度地提高资源效率。我们希望在做到这一点的同时，保持不同用户之间资源共享的公平性。
开发人员速度： 此指标通过我们的工程师在特定时间范围内可以进行的实验数量来量化。我们优先考虑成熟的生态系统来提高开发人员的速度，确保我们的团队高效工作以提供最佳解决方案。这种方法不仅简化了我们最先进的模型到生产的流程，还缩短了这一转变所需的时间。
接下来是我们为使培训和服务部署在本地和云基础架构中高效且可扩展而采取的各项举措的成果总结：
优化现有的本地基础设施批处理作业联合：我们的 GPU 资产分布在各个可用区和地区的多个Kubernetes ™ 集群中。这种分布主要是由于 GPU 可用性和单个 Kubernetes 集群内的节点数限制。这种安排带来了两个主要挑战：
向机器学习工程师展示基础设施的具体细节。由于静态分配，集群间资源利用率不一致。虽然我们在每个集群内都有有效的资源共享系统，但我们缺乏集群间调度的能力。为了解决这些问题，我们为我们的批处理工作负载（包括Ray ™ 和 Apache Spark ™）创建了一个统一的联合层，称为Michelangelo Job Controller。该组件充当所有工作负载调度的集中接口，隐藏底层 Kubernetes 集群，并根据各种策略（负载感知、装箱打包）分配工作负载，包括计算和数据亲和性考虑。我们计划在后续博客文章中分享更多有关此方面的技术细节。
图 1：用于 ML 工作负载分配的统一联合层。
网络升级提高法学硕士培养效率在扩展基础设施以适应生成式 AI 应用程序并提高分布式训练效率的同时对开源 LLM 进行微调时，重要的是要关注在纵向扩展和横向扩展配置中扩展网络带宽。这需要实现关键功能，例如 GPU 之间的全网状NVlink ™ 连接、网络链路速度升级、熟练的拥塞控制管理、QoS 控制以及建立专用机架和网络拓扑等其他基本功能。
图2：通过网络链路容量升级提高训练效率。
我们概述了大型语言模型 (LLM) 案例研究的结果，强调了增强的网络带宽和拥塞控制机制对训练效果和性价比的重大影响。我们的观察表明，与现有的网络互连相比，当采用更高的网络带宽和更好的拥塞控制机制时，训练速度几乎提高了两倍，训练时间大幅缩短。在多节点训练期间，跨节点复制数据会增加本地内存需求并增加 IO 工作负载。我们的分析促使我们建议将每个 GPU 服务器的网络链路容量增加 4 倍（从 25GB/s 到 100GB/s），从而使可用的训练容量翻倍。在构建这些时，我们还需要通过适当的隔离和 QoS 控制确保大型训练运行产生的“大流”不会对其他高优先级服务产生负面影响。
升级内存以提高 GPU 分配率较新的 AI/ML 工作负载要求每个 GPU 工作器拥有比我们设计时更多的系统内存。固有的物理限制（例如每台服务器上有限的内存通道数量以及 NPI（新产品推出）期间部署的 DIMM 容量）限制了我们扩大 GPU 分配的能力。为了提高我们的 GPU 分配率，我们已开始努力将这些服务器上的内存量增加一倍（每个 DIMM 通道从 16GB 增加到 32GB）。此外，我们还在构建一个框架，以便在旧机架退役时重新利用和重复使用 DIMM。此类优化使我们能够最大限度地利用现有的 ML 基础设施，并充分利用我们当前的资源。我们将在即将发布的文章中详细介绍通过这一举措实现的效率提升。与此同时，我们已经开始努力帮助调整训练作业的资源需求。正如其他人所证明的那样 [参考]，手动请求最佳资源是一个难题，而自动化将有助于提高分配效率。
建设新基础设施各种云 SKU 的性价比评估2022 年末，当我们开始向云过渡时，我们评估了不同云提供商提供的各种 CPU 和 GPU 模型。我们的目标是使用成熟的基准来比较它们的性价比，这些基准包括基于树的深度学习、大型语言模型以及专有数据集和 Uber 的模型（如 deepETA 和 deepCVR）。这些评估既用于训练也用于服务，使我们能够选择针对特定工作负载优化的最合适的 SKU，同时考虑可行性、成本、吞吐量和延迟等因素。在整个 2023 年，我们广泛测试了 17 种不同的 GPU 和 CPU SKU，采用了各种库和优化器，包括 Nvidia 的TensorRT ™(TRT) 和 TRT-LLM 优化。例如，如图 4 和图 5 所示，我们发现虽然 A10 GPU 可能无法为训练任务提供最具成本效益的吞吐量，但它们被证明是我们服务用例的最佳选择，在使用 TRT 时提供最佳吞吐量的同时保持可接受的 SLA。
图3：深度学习训练和服务性价比评估。
图 4：有和没有 TensorRT 优化的深度学习服务延迟。
Uber 的众多生成式 AI 应用程序都需要使用 Nvidia 最新的 H100 GPU 来满足其严格的延迟要求。这一要求源于 H100 GPU 的功能，与上一代 A100 GPU 相比，它包括高达 4 倍的 TFlops 和两倍的内存带宽。在试验 Meta™ Llama2 ™ 模型系列时，涉及各种批次大小、量化和模型参数，我们评估了各种开源和闭源框架，以进一步优化 LLM 服务性能。在图 6 和图 7 中，我们展示了一个特定案例，其中我们使用两个指标：每个令牌延迟（ms/token）和令牌/秒/gpu，以评估和比较模型在两个性能最佳的框架（TRT-LLM 和当前保密的框架）中的性能，保持所有其他参数不变并使用 FP16 量化。
图 5：按框架（H100）比较 LLM 服务延迟。
图 6：使用相同延迟预算和所需最少 GPU 数量（H100）的框架的 LLM 服务吞吐量比较。
这些实验结果清楚地表明，与 TRT-LLM 相比，框架 B 的延迟增加了两倍，吞吐量提高了六倍。这进一步强调了硬件/软件协同设计的重要性，并且要充分利用硬件功能，必须在整个堆栈中拥有正确的解决方案。
通过内存卸载提高 LLM 培训效率在本节中，我们概述了针对大型语言模型将优化器状态、参数和梯度从 GPU 内存放置到 CPU 内存或 NVMe 设备的设计和实验框架。我们的目标是评估这种卸载如何影响 GPU 可扩展性、训练效率和一系列系统指标。
图7：内存卸载实验的设计框架。
我们的实验结果表明，我们训练扩展模型的能力得到了显著增强，而此前受限于 GPU 内存，这种能力一直受到阻碍。将内存从 GPU 内存卸载到系统内存甚至 NVMe 设备有助于提高训练效率，因为这样可以在相同数量的 GPU 上使用更大的批处理大小。这种转变使 MFU（模型浮点数利用率）提高了 2 倍，同时将 GPU 使用率降低了 34%。然而，值得注意的是，这种改进也伴随着网络吞吐量的相应降低。有关此主题的详细开放计算机项目 ( OCP ) 会议演讲可在此处找到。
图 8：实现 deepspeed 内存卸载优化的训练效率。
结论最后，我们想给您留下三个关键见解。在从 XGboost 到深度学习推荐模型和大型语言模型的快速应用和模型进步中，设计一个单一的 AI/ML 系统带来了相当大的挑战。例如，虽然 LLM 需要高 TFlops，但深度学习模型可能会遇到内存限制。为了提高这些系统的成本效益，在给定的 SLA 内，基于服务成本和每美元性能等效率指标探索工作负载优化的解决方案变得势在必行。最大限度地提高基础设施效率需要在系统的所有层面上采用协作的硬件和软件设计方法。在此背景下，我们在本文中展示了各种示例，说明了如何有效利用现有基础设施，同时构建新功能以有效扩展基础设施。最后，我们发出邀请，促进行业伙伴关系，敦促参与开源优化以提高效率，并就有效扩展基础设施以应对 AI 领域不断变化的需求交换想法和经验。
致谢非常感谢 UBER AI 基础设施、OCI、GCP 和 Nvidia 团队成员对上述工作的合作。
Apache®、Apache Kafka、Kafka、Apache Spark、Spark 和星形徽标是 Apache 软件基金会在美国和/或其他国家/地区的注册商标或商标。使用这些标志并不表示 Apache 软件基金会对其的认可。
Kubernetes® 及其徽标是 Linux Foundation® 在美国和其他国家/地区的注册商标。使用这些商标并不代表 Linux Foundation 对其的认可。
Falcon 180B® 及其徽标是 Technology Innovation Institute™ 在美国和其他国家/地区的注册商标。使用这些标志并不代表 Technology Innovation Institute 对其的认可。
LLaMA 2® 及其徽标是 Meta® 在美国和其他国家/地区的注册商标。使用这些商标并不代表 Meta 对其表示认可。
作者:
Nav Kankani
Nav is a Platform Architect on Uber's infrastructure team. He has been working in the areas of AI/ML, hyperscale cloud platforms, storage systems, and the semiconductor industry for the past 21 years. He earned a Master’s degree in electrical and computer engineering from the University of Arizona and an MBA from Hamline University. He is also named inventor on 21+ US patents.
Rush Tehrani
Rush is an Engineering Manager on the AI Platform Team at Uber. He supports the teams responsible for deployment and serving ofical, deep learning, and generative AI models, machine learning on mobile, and generative AI API gateway. Before joining Uber, he was the founder of Onepanel, an open source, Kubernetes native computer vision platform.
Anant Vyas
Anant is the tech lead of AI Infrastructure at Uber, where his focus is on maximizing the performance and reliability of their extensive computing resources. Prior to this role, he contributed to the Compute Platform team, specializing in the development of resource scheduling systems.
出处:https://www.uber.com/en-JP/blog/scaling-ai-ml-infrastructure-at-uber/
