为大模型工程提效，基于阿里云 ACK 的云原生 AI 工程化实践

2024-01-21
浙江
本文字数：9007 字
阅读完需：约 30 分钟

作者：张凯

背景

以 GPT（Generative Pre-trained Transformer）和 Diffusion model 为代表的大语言模型（Large language model，LLM）和生成式人工智能（Generative artificial intelligence，GAI）在过往两年，将人们对 AI 的梦想与期待推向了一个新高峰。这一次，AI 带来的“智能”效果和“涌现”能力，吸引着千行百业都在积极思考如何在业务中利用大模型。即便训练一次千亿参数量模型的成本可能就高达百万美元，依然有很多企业希望拥有自己的专属大模型。

今天的云计算已经承载了从业务应用，到数据库、大数据、机器学习和高性能计算等大多数计算负载。面对 LLM 和 GAI 这类对算力和数据都有极高量级需求的新负载，云计算也迎来了“智算”时代。 一方面以服务化资源池的方式提供千 GPU 卡，甚至万卡的算力，PB 级存储和单机 TB 级高性能网络互联，另一方面以云原生标准化交付算力给大模型的生产者和使用者。

阿里云云原生容器服务借助容器、Kubernetes、微服务等云原生技术，在阿里云弹性计算、存储、网络和灵骏智算服务基础之上，推出了 ACK 云原生 AI 套件产品和解决方案， 帮助企业在“智算”时代，更快、更高效地落地云原生 AI 系统。

此次云栖大会的分享共分三部分，介绍云原生 AI 领域的基础知识。首先，解析云原生 AI 所遇到的技术挑战和应对方案，随后介绍云原生 AI 领域的关键技术与架构细节，最后分享我们在 ACK 的相关经验及工程实践。

大模型带来的技术挑战

近年来，深度学习引领 AI 的再次快速发展，并已成为主流方向。其中涉及到多种技术，包括有监督学习、强化学习、无监督学习等。以深度学习为代表的技术已在计算机视觉、语音识别等领域取得巨大进展，推动了许多行业的创新。通过云化服务的方式，交付 AI 能力也成为一种趋势。

总结深度学习任务的特性包括：

首先， 它是一种端到端的工作流程，旨在从大量原始数据中提取特征，进而创建可执行模型。
其次， 通常需要长时间的训练，任务运行时间可能以小时，甚至以月为单位。在训练过程中，需反复迭代优化，不断调整参数，以使模型能够更好地接近真实数据特征分布。这会导致算力资源和数据的巨大消耗。

理解了深度学习为代表的 AI 工作负载特性后，我们可以发现在实际生产和应用中，AI 和深度学习工程会面临几个主要挑战，尤其是在效率、性能和成本方面。

例如，管理 GPU 集群是一项非常复杂的工作。只有少量 GPU 机器时，个人数据科学家或计算工程师可以独立操作和维护。然而，随着 GPU 数量增长到数十台甚至数百台，形成大规模 GPU 集群时，环境一致性、版本依赖性、配置多样性、效率提升以及运维生命周期复杂度等问题将变得尤为突出。许多算法工程师不得不花费大量时间和精力解决 GPU 集群管理和资源分配等基础问题，从而拖延真正用于深度学习模型开发和训练的工作。

另一方面，即使解决了 GPU 管理问题，AI 工程效率仍然受到生命周期复杂性的限制。整个流程，从开发环境搭建、数据准备到模型开发、模型训练、优化、可视化控制、错误处理等，直到模型推理上线和运维，每一个环节都可能导致 AI 模型的开发周期延长且效率低下。

而且这些环节大多需要手动操作或使用各种脚本串联，开发效率较低，协同难度大。因此，提高 AI 的工程效率是另一个亟待解决的问题。

当面对 LLM 和 AIGC 等新领域，AI 对基础设施服务能力提出了更多挑战。主要体现在规模、性能和效率三个方面。

在规模上， 要训练出具有广泛知识和专业领域理解及推理能力的大语言模型，往往需要高达万卡级别的 GPU 集群和 PB 级的数据存储以及 TB 级的数据吞吐。此外，高性能网络也将达到单机 800Gbps 甚至 3.2Tbps 的 RDMA 互联。

在性能方面， 随着模型体积和参数量的增长，单张显卡已无法承载完整的模型。因此需要使用多张显卡进行分布式训练，并采用各种混合并行策略进行加速。这些策略包括数据并行、模型并行、流水线并行以及针对语言模型的序列并行等，以及各种复杂的组合策略。

在推理阶段， 模型需要提供高效且稳定的推理服务，这需要不断优化其性能，并确保服务质量（QoS）得到保证。

在此基础上，最重要的目标是提高资源效率和工程效率。 一方面，持续提高资源利用效率，并通过弹性扩展资源规模，以应对突发的计算需求。另一方面，要最优化算法人员的工作效率，提高模型迭代速度和质量。因此，资源效率和工程效率成为了最优先考虑的优化目标。

随着云原生技术和架构发展，我们明显观察到 IT 架构的变化。传统的企业级应用、Web 应用、微服务等领域都在从传统架构转向云原生架构。互联网应用大多是基于容器、Kubernetes，Prometheus 等云原生技术实现的，追求弹性、灵活性以及最佳性价比。同时，通过标准化交付，提升生产流程的高效闭环。

在标准 API 和标准架构的指导下，进一步提高多角色之间的协作和迭代效率。同样地，为了获得更多弹性算力供给、更高稳定性保证以及更快的交付，越来越多 AI 和大数据工作负载也运行在云原生架构上。

右图清晰地显示了这一趋势：最早是从可水平扩展的无状态应用程序（如 Web 应用、移动后端应用）开始；然后是 NoSQL 数据库、关系数据库、TensorFlow、PyTorch、Spark、Flink 等大数据和典型机器学习的 AI 计算任务。都能够在 Kubernetes 容器集群上大规模运行。

三方研究机构的预测，显示出同样的趋势。早在 2019 年，Gartner 就曾预测，到 2023 年，70% 的人工智能应用程序将基于云原生等技术进行开发。IDC 的研究则预测，到 2025 年，接近 50% 的企业内部的数据密集型或性能密集型计算工作负载都将迁移到基于云的架构上，而基于云的架构正是典型的 Cloud Native 云原生架构。

此前概述了传统的机器学习、深度学习以及目前流行的 LLM 和 AIGC ，带来了一些技术上的挑战，和对基础设施造成的压力。为了应对这些挑战，我们期待借助云原生 AI 来找到解决方案。那么，什么是云原生 AI 呢？

云原生 AI 是指利用云计算的弹性资源、异构算力以及容器、自动化、微服务等云原生技术，提升 AI/ML 的工程效率，降低整体成本，提高可扩展性，并实现端到端的解决方案。在这其中，我们尤为注重工程效率、成本效益、可扩展性和可复制性等因素。

云原生 AI 最核心的两个应用场景：

统一管理异构资源，提升资源利用率。

对 IaaS 云服务或者客户 IDC 内各种异构的计算（如 CPU，GPU，NPU，VPU，FPGA，ASIC）、存储（OSS，NAS， CPFS，HDFS）、网络（TCP， RDMA）资源进行抽象，统一管理、运维和分配，通过弹性和软硬协同优化，持续提升资源利用率。

通过统一工作流和调度，实现 AI、大数据等多类复杂任务的高效管理。

兼容 Tensorflow，Pytorch，Horovod，ONNX，Spark，Flink 等主流或者用户自有的各种计算引擎和运行时，统一运行各类异构工作负载流程，统一管理作业生命周期，统一调度任务工作流，保证任务规模和性能。一方面不断提升运行任务的性价比，另一方面持续改善开发运维体验和工程效率。

围绕这两个核心场景，可以扩展出更多用户定制化场景，比如构建符合用户使用习惯的 MLOps 流程；或者针对 CV 类（Computer Vision,计算机视觉）AI 服务特点，混合调度 CPU，GPU，VPU（Video Process Unit）支持不同阶段的数据处理流水线；还可以针对大模型预训练和微调场景，扩展支持更高阶的分布式训练框架，配合任务和数据调度策略，以及弹性、容错方案，优化大模型训练任务成本和成功率。

接下来探讨支持这些场景，云原生 AI 所需的主要功能。

首先，从异构资源管理的角度，需要一键部署和运行的能力，能够统一管理和操作各种类型的异构资源，如 CPU、GPU 以及各种虚拟化的设备和专业存储、网络设备。在运维过程中，需要多维度的异构资源可观测性，包括监控、健康检查、告警、自愈等自动化运维能力。对于“宝贵”的计算资源，如 GPU 和 NPU 等加速器，需要通过各种调度、隔离和共享的方法，最大限度地提高其利用率。在存储和网络方面，通过统一接口和方式供给上层工作负载。在此过程中，我们还将利用云资源的弹性特征，持续提高资源的交付和使用效率。

另一个主要能力是能够在分钟级内准备好开发环境和集群测试环境，帮助算法工程师开始执行深度学习任务。把端到端的 AI 生产过程通过相同的编程模型、运维方式进行交付。在整个流水线执行过程中，天然支持主流计算框架，如 TensorFlow、PyTorch、Deepspeed 等。

对于大规模分布式 AI 任务，提供丰富的任务调度策略，如 Gang scheduling、Capacity scheduling、Topology aware scheduling、优先级队列等。并使用工作流或数据流的方式串联起整个任务流水线。

此外，在计算框架与算法层面适配资源弹性能力，提供弹性训练和弹性推理服务，优化任务整体运行成本。除了计算任务优化，还应关注数据使用效率的优化。为此，需要统一的数据集管理、模型管理和访问性能优化等功能，并通过标准 API 和开放式架构使其易于被业务应用程序集成。

随着 AI 和 LLM 的不断发展，我们还将面临一些新的挑战和需求。例如，如何快速适应新的开源大模型训练方法（无论是预训练、监督微调还是强化学习），以及如何提高大模型推理性能并确保其质量和稳定性。同时，也需要关注一些前沿技术和创新能力，通过标准化和可编程的方式来集成，不断迭代业务应用，形成 AI+ 或 LLM+ 的新应用开发模式和编程模型。

例如 AutoGPT、多智能体任务等，这些都是我们需要快速掌握、理解，并应用于应用智能化升级的重要工具。

云原生 AI 支持大模型生产的关键技术

前述详细分析了云原生 AI 领域的发展历程、现状以及未来趋势，帮助大家更好地理解这一交叉技术领域。后续我们将转向更为具体的技术层面，介绍已经落地并相对成熟的一些云原生 AI 关键技术。

首先，介绍整个云原生 AI 的系统架构，这是一个典型的分层架构。最底层是云资源服务或数据中心的线下资源，由容器服务平台进行统一的封装和管理。在这一层之上，又分为几个层面来构建云原生 AI 系统。

第一层是高异构资源管理层，包括对 AI 计算、存储和网络资源的统一管理和运维。
第二、三层负责 AI 任务的调度和流水线的构建，支持各种计算框架和训练、推理运行时。
第四、五层是任务性能优化和 AI 作业生命周期管理。
最后一层是通过统一的工具链和标准 API 向上提供所有这些能力，并与内外部生态集成，包括开源模型、数据，私有业务系统或服务，以及第三方生态系统。

在整个系统中，弹性、运维和安全贯穿于各个层面。此外，我们还注重数据、模型和实验等各种制品的统一管理，以及安全性和隐私性的保障。

在阿里云的容器服务（ACK）之上，我们提供了云原生 AI 套件的产品，以此作为上述系统架构的一种参考实现。帮助大家更容易理解云原生 AI 系统分层架构的构建方式以及每层的关键技术点。

右图展示了基于 ACK 的云原生 AI 套件产品的系统架构。每个方块代表一层的关键技术组件，整个架构是可以组件化拼装、交付和扩展的。用户可以通过组件插拔组合的方式来定制自己的云原生 AI 平台。

我们将自底向上地阐述每一层的关键技术点。

首先，在统一资源管理这一层，实现对各类异构资源（如 GPU、NPU）进行统一运维、多维度监控和健康检查，并具备自动异常发现和告警功能。此外，还需要追求性价比、弹性交付能力和自动弹性伸缩能力，充分利用云计算的价格优势和技术优势。

其次，使用阿里云提供的竞价实例、按需服务等弹性资源，以降低成本并提高性价比。

在高性能网络方面，采用 KBS 集群统一调度和管理 RDMA 和 GPU 等高性能设备，进行资源抽象与运维屏蔽，实现网络与计算的高效协同工作。

再次，我们需要对 Nvidia GPU 进行全方位精细化支持，包括对 NVIDIA Direct 和 NCCL 的支持，以及针对多 GPU 设备场景的网络拓扑感知调度策略，优化通信效率，加速分布式训练。

在 GPU 资源利用率优化方面，提供 GPU 共享调度方案，使得多个容器可以在同一张 GPU 卡上共享显存和算力，显著提升 GPU 利用率。同时，我们还将结合阿里云 cGPU 技术实现轻量级设备资源隔离化，确保显存、算力和错误隔离，并最大限度地节省虚拟化开销。

通过以上关键技术点提供坚实的基础支撑，不断优化高性能资源的成本效益，最终提升整体训练效率。

上升到 AI 任务调度层。如果我们理解 AI 或大数据作业的特征，就会发现它们不是简单、独立的多副本组合，而是相互依赖、有拓扑关联的批量任务。然而，Kubernetes 原生调度器支持批量任务的能力相对缺乏，例如复杂的任务调度与抢占、资源额度分配、优先级管理和调度性能优化。

Kubernetes 调度器框架已经发展成一个可插拔式的体系结构，允许我们通过 Plug-ins 进行扩展，以实现更复杂的任务级调度能力。ACK 团队已经在 Kubernetes 调度器中贡献了多个 Plug-ins，如 gang scheduling、弹性容量调度、优先级队列、公平调度、拓扑感知调度等，以最大化满足复杂的训练或推理任务的整体调度效率和成功率。

这些调度能力可以有效解决复杂任务编排和不合理的资源分配导致的资源浪费，以及不同租户作业之间的资源争抢等问题。此外，我们也扩展了数据亲和性的调度策略，让数据与计算更加紧密耦合，减少数据传输的带宽压力和延迟。

阿里云还在 Kubernetes 社区推动成立 Batch Job 工作组，致力于制定标准规范，定义标准 API，以便能够高效结合这些复杂的任务管理和调度功能。同时，我们将一些主要的批量调度或任务级别调度策略插件贡献给上游开源社区，并已被众多社区用户使用。例如 Open AI 在其高达 7500 节点的模型训练集群中使用了 Co-scheduling 调度功能。

总的来说，在调度方面，仍有许多更复杂、更高级的功能需要继续加强，如租户间的公平性、虚拟配额管理、任务级抢占等。这些能力将通过 ACK 云原生 AI 套件持续提供给用户和社区。

在解决了任务调度的问题后，我们将探讨如何将训练任务或推理服务与云资源的弹性相结合，从而使训练过程和推理服务能够伸缩自如。

我们可以通过自动或手动方式，在有更多资源闲置的情况下，将这些资源动态添加到训练任务中。在资源紧张时，则可以出让一些资源供给其他高优先级的任务使用。同时确保运行中的任务不被打断，并且其执行效率和模型性能不受影响。

我们通过结合 K8S 任务管理和调度、Pytorch、Horovod 等计算框架，实现对常见的 CV 模型、NLP 模型和推荐类模型的支持，使训练任务可以使用从几张 GPU 卡动态扩展到几十张、上百张 GPU 卡，同时也可以反向缩容。确保任务在整个过程中不中断，并保持收敛性能。

弹性训练的收益会相对明显，尤其是在使用竞价实例的场景下。虽然竞价实例的优势在于可以用较低的价格获取 GPU 或其他高性能计算资源，但也存在每小时就会回收的风险。如果运行中的任务无法在此时间段内结束，则可能会面临缩容问题。

我们可以结合弹性训练和弹性推理等能力，充分利用像 spot instance 和 ECI 这样的高性价比资源。同时，由于大模型训练任务（如 175B 参数级别的 GPT3）需要近千张 GPU 卡并训练近一个月的时间。任何一张 GPU 卡都可能出现故障，这会导致任务失败，造成极大的损失和资源浪费。

可以结合弹性训练的能力，构建容错场景，即使部分资源失效或计算任务出错，整体任务仍然可以通过缩容形式继续进行训练，以最大化容错。并确保计算资源的投入和计算过程都不会被浪费。这是一种非常有趣且富有挑战的技术问题，即如何利用云的弹性资源来适应算法和计算过程的弹性伸缩。

我们之前提到了任务调度和如何更好地使用弹性资源。其中，计算效率最大化和减少数据读取的时间是非常关键的问题。云计算中，存储和计算分离是一种常见架构，它可以提供更大的灵活性，但也带来了远程访问延迟和带宽限制的问题。

为了解决这些问题，我们通过开源项目 Fluid，结合分布式缓存技术，将数据缓存能力内置到数据集对象中，并将其作为有生命周期的对象进行管理。这样，数据集可以根据应用程序的需求进行缓存数据的亲和性调度，最大程度地减少远程数据访问延迟。还能够在自定义监控的情况下，进行缓存数据的自动弹性伸缩，缓解高并发计算任务访问远程存储的聚合带宽压力。

Fluid 弹性数据集编排和加速项目已经在 ACK 云原生 AI 套件中有相应的产品实现，一些功能子集也已开源至 CNCF 社区，目前正在积极向孵化阶段推进。

通过分布式缓存加速技术，我们可以显著提高分布式训练的效率，如右下角所示的 ResNet-50 训练效果示例。当我们不断增加 GPU 卡的数量时，如果不使用缓存加速，性能加速比并趋于平坦（蓝色线条），不会得到很好的提升。而通过 Fliud 的弹性分布式缓存加速后，随着 GPU 资源的增加，训练性能加速比基本保持线性增长（绿色线条），大幅度地提高了 GPU 计算效率。

我们不仅将 Fluid 弹性数据集加速的能力应用于分布式训练场景，也可以将其应用大模型的推理服务。在大模型推理服务中存在一个问题，即随着模型体积的增长（现在模型常常达到几 GB 或几十 GB），首次创建，或在运行过程中动态扩容这样的模型服务的冷启动延迟问题会变得非常严重。

这是因为我们需要从远程对象存储或 HDFS 中拉取大模型参数，而这种操作往往具有较高的延迟。我们测试过，在一个 165GB 的大模型情况下，拉取所有参数可能需要近一个小时的时间，这在生产环境中是无法接受的，因为它不能提供在线服务。

为了解决这个问题，我们为 Fluid 缓存加速功能扩展了数据预取、并发加载、 Pagecahce 预热等优化手段，并应用到模型服务冷启动的优化中。结果表明，对于 Llama 30B 等流行的大模型，可以实现 70% 至 80%，甚至更高的加速启动效果。

ACK 云原生 AI 套件提供的所有组件都以 Kubernetes 标准接口（CRD）和 API 形式，交付给 AI 平台开发运维人员调用。这对基于 Kubernetes 构建云原生 AI 平台来说是非常方便和易用的。

但对于数据科学家和算法工程师开发训练 AI 模型来说，Kubernetes 的语法和操作却是一种“负担”。他们更习惯在 Jupyter Notebook 等 IDE 中调试代码，使用命令行或者 Web 界面提交、管理训练任务。任务运行时的日志、监控、存储接入、GPU 资源分配和集群维护，最好都是内置的能力，使用工具就可以简单操作。

为此，我们创建了一款名为 Arena 的工具，来屏蔽底层资源、Kubernetes、运行环境等各种复杂度的能力，以统一的方式来管理系统、任务、模型开发、分布式训练、模型评估推理、循环迭代等全生命周期。它可以自动化处理复杂的任务，包括调度、Kubernetes 管理和实时监控。此外，Arena 还支持 Go、Java 和 Python SDK，支持二次开发和封装。

我们还为运维人员和开发者提供了可视化的控制台，使他们在不同终端上都能实现统一的任务管理。只需使用 Arena 的一条命令，就可以将分布式的任务提交到 Kubernetes 集群中，自动运行，并保存训练结果。另一条命令则可以用于创建模型推理服务，也包括发布、A/B 测试、流量管理等运维操作。

目前我们也为 Arena 扩展了对大模型的支持，兼容了主流的 LLM/ AIGC 模型和训练、推理框架。例如，用户可以通过两条命令快速训练和推理 ChatGLM，Llama，Bloom，Baichuan，Qwen 等模型。

ACK 云原生 AI 套件工程实践

前述所有这些关键技术，我们需要考虑如何将它们应用起来，怎样将它们快速应用于用户的生产环境中，以启动用户的第一个 AI 训练和推理任务。为此，在阿里云的容器服务（ACK）上，我们提供“云原生 AI 套件”，旨在将上述所有技术及架构在一个完整的产品中提供给我们的客户和合作伙伴。

云原生 AI 套件完全遵循之前介绍的分层参考架构进行实现和交付。用户可以根据自己的需求，在其中选择所需的组件。例如，如果用户对 GPU 管理有特殊要求，则可以利用异构算力中的调度、共享、隔离等能力。如果对任务管理有很多需求，可以利用我们的高级调度策略。如果您需要一个方便快捷的 AI 生产流程管线管理工具，那么 Arena 等套件的能力也可以迅速为您提供帮助。

借助这些功能，可以帮助用户实现 AI 训练速度提高 20％以上，数据访问效率提高 30％以上，而 GPU 利用率则可提高 100％以上。

ACK 的云原生 AI 套件能够带来什么效果？

这里有两个案例来说明。

首先，任意门是一个需要大量用户多模态数据进行人工智能驱动的社交平台。客户需要一个能够充分利用云计算弹性资源并具有快速迭代和扩展能力的 AI 平台。借助 ACK 的云原生 AI 套件，任意门构建了一个定制化的基于容器的 AI 平台。现在，该平台已经承载了客户的语音合成、人脸匹配、图像识别和智能聊天等业务场景。

第二个案例是小米的机器学习平台。

客户采用混合云方式，既使用自有 IDC 中的 GPU 资源，又使用阿里云的弹性 GPU 资源，构建 AI 平台。由于跨地域，使得计算存储分离的架构，在数据复制延迟和聚合带宽的问题非常突出。通过使用 Fluid 的分布式缓存加速和数据统一管理方案，解决了线下自建 StarFS 存储的标准化接入和管理问题，并增加了分布缓存线下数据能力，以解决数据加载性能问题。帮助小米构建了一个高效混合云架构下的分布式 AI 平台。

如何使用 ACK 的云原生 AI 套件？只需在阿里云创建一个 ACK 集群，无论是否添加 GPU 节点。一键安装即可将整个云原生 AI 套件部署到集群中。用户可以根据需求选择所需组件，以定制自己的基础 AI 平台。在该平台上进行二次开发和扩展后，开发人员可以通过 Arena 或 Jupyter Notebook 进行模型开发，并向 GPU 集群提交模型训练任务。同时，AI 平台的运维人员可以通过 AI 套件中的运维控制台和运维命令进行模型生产和线上推理服务的便捷运维。

AI 平台或 AI Infra 运营人员如何使用 ACK 云原生 AI 套件进行工作的流程：首先，创建 ACK 集群，接着配置调度策略、创建训练数据集或模型集，并通过 AI 运维控制台监控集群运行状况、GPU 分配情况和健康状况等。

作为开发团队的数据科学家和算法工程师，则通过 Arena 命令行或 SDK 进行模型开发、训练的迭代实验。最后通过评测和压测，选择出符合预期的模型版本，通过 Arena 创建推理服务，将其发布到生产集群中。我们还提供了 AI 开发控制台，以便于不习惯使用命令行或无需二次开发需求的用户，在可视化界面上完成所有开发、训练任务的操作。