升级你的AI游戏：用Kubernetes打造云端原生AI平台，告别‘小作坊’时代
作者：张凯
前言
云原生（Cloud Native）[1]是云计算领域过去 5 年发展最快、关注度最高的方向之一。CNCF（Cloud Native Computing Foundation，云原生计算基金会）2021年度调查报告[2]显示，全球已经有超过 680 万的云原生技术开发者。同一时期，人工智能 AI 领域也在“深度学习算法+GPU 大算力+海量数据”的推动下持续蓬勃发展。有趣的是，云原生技术和 AI，尤其是深度学习，出现了很多关联。
大量 AI 算法工程师都在使用云原生容器技术调试、运行深度学习 AI 任务。很多企业的 AI 应用和 AI 系统，都构建在容器集群上。为了帮助用户更容易、更高效地在基于容器环境构建 AI 系统，提高生产 AI 应用的能力，2021 年阿里云容器服务 ACK 推出了云原生 AI 套件产品。本文将介绍和梳理我们对云原生 AI 这个新领域的思考和定位，介绍云原生 AI 套件产品的核心场景、架构和主要能力。
AI 与云原生极简史
回顾 AI 的发展历史，我们会发现这早已不是一个新的领域。从 1956 年达特茅斯学术研讨会上被首次定义，到 2006 年 Geoffery Hinton 提出了“深度信念网络”(Deep Believe Network），AI 已历经 3 次发展浪潮。尤其是近 10 年，在以深度学习（Deep Learning）为核心算法、以 GPU 为代表的大算力为基础，叠加海量生产数据积累的推动下，AI 技术取得了令人瞩目的进展。与前两次不同，这一次 AI 在机器视觉、语音识别、自然语言理解等技术上实现突破，并在商业、医疗、教育、工业、安全、交通等非常多行业成功落地，甚至还催生了自动驾驶、AIoT 等新领域。
然而，伴随 AI 技术的突飞猛进和广泛应用，很多企业和机构也发现想要保证“算法+算力+数据”的飞轮高效运转，规模化生产出有商业落地价值的 AI 能力，其实并不容易。昂贵的算力投入和运维成本，低下的 AI 服务生产效率，以及缺乏可解释性和通用性的 AI 算法，都成为横亘在 AI 用户面前的重重门槛。
与 AI 的历史类似，云原生领域的代表技术 —— 容器（container），也不是一个新的概念。其最早可追溯到 1979 年诞生的 UNIX chroot 技术，就开始显现出容器的雏型。接下来又出现了 FreeBSD Jails，Linux VServer，OpenVZ，Warden 等一系列基于内核的轻量级资源隔离技术。直到 2013 年 Docker 横空出世，以完善的容器对象封装、标准的 API 定义和友好的开发运维体验，重新定义了使用数据中心计算资源的界面。随后的故事大家都知道了，Kubernetes 在与 Docker Swarm 和 Mesos 的竞争中胜出，成为容器编排与调度的事实标准。Kubernetes 和容器（包括 Docker，Containerd，CRI-O 等多种容器运行时和管理工具）构成了 CNCF 定义的云原生核心技术。经过 5 年高速发展，云原生技术生态已经覆盖了容器运行时、网络、存储和集群管理、可观测性、弹性、DevOps、服务网格、无服务器架构、数据库、数据仓库等 IT 系统的方方面面。
为何出现云原生 AI
据 CNCF 2021 年度相关调查报告显示， 96% 的受访企业正在使用或评估 Kubernetes，这其中包括了很多 AI 相关业务的需求。Gartner 曾预测，到 2023 年 70% 的 AI 应用将基于容器和 Serverless 技术开发。
现实中，在研发阿里云容器服务 ACK[3]（Alibaba Container service for Kubernetes）产品过程中，我们看到越来越多用户希望在 Kubernetes 容器集群中管理 GPU 资源，开发运行深度学习和大数据任务，部署和弹性管理 AI 服务，且用户来源于各行各业，既包括互联网、游戏、直播等快速增长的公司，也有自动驾驶、AIoT 这类新兴领域，甚至不乏政企、金融、制造等传统行业。
用户在开发、生成、使用 AI 能力时碰到很多共性的挑战，包括 AI 开发门槛高、工程效率低、成本高、软件环境维护复杂、异构硬件管理分散、计算资源分配不均、存储接入繁琐等等。其中不少用户已经在使用云原生技术，并成功提升了应用和微服务的开发运维效率。他们希望能将相同经验复制到 AI 领域，基于云原生技术构建 AI 应用和系统。
在初期，用户利用 Kubernetes，Kubeflow，nvidia-docker 可以快速搭建 GPU 集群，以标准接口访问存储服务，自动实现 AI 作业调度和 GPU 资源分配，训练好的模型可以部署在集群中，这样基本实现了 AI 开发和生产流程。紧接着，用户对生产效率有了更高要求，也遇到更多问题。比如 GPU 利用率低，分布式训练扩展性差，作业无法弹性伸缩，训练数据访问慢，缺少数据集、模型和任务管理，无法方便获取实时日志、监控、可视化，模型发布缺乏质量和性能验证，上线后缺少服务化运维和治理手段，Kubernetes 和容器使用门槛高，用户体验不符合数据科学家的使用习惯，团队协作和共享困难，经常出现资源争抢，甚至数据安全问题等等。
从根本上解决这些问题，AI 生产环境必然要从“单打独斗的小作坊”模式，向“资源池化+AI 工程平台化+多角色协作”模式升级。为了帮助有此类诉求的“云原生+AI”用户实现灵活可控、系统化地演进，我们在 ACK 基础上推出云原生 AI 套件[4]产品。只要用户拥有一个 ACK Pro 集群，或者任何标准 Kubernetes 集群，就可以使用云原生 AI 套件，快速定制化搭建出一个自己的 AI 平台。把数据科学家和算法工程师从繁杂低效的环境管理、资源分配和任务调度工作中解放出来，把他们更多的精力留给“脑洞”算法和“炼丹”。
如何定义云原生 AI
随着企业 IT 架构逐步深入地向云计算演进，以容器、Kubernetes、服务网格等为代表的云原生技术，已经帮助大量应用服务快速落地云平台，并在弹性、微服务化、无服务化、DevOps 等场景中获取很大价值。与此同时，IT 决策者们也在考虑如何通过云原生技术，以统一架构、统一技术堆栈支撑更多类型的工作负载。以避免不同负载使用不同架构和技术实现，带来“烟囱”系统、重复投入和割裂运维的负担。
深度学习和 AI 任务，正是社区寻求云原生支撑的重要工作负载之一。事实上，越来越多深度学习系统、AI 平台已经构建在容器和 Kubernetes 集群之上。在 2020 年，我们就明确提出“云原生 AI”的概念、核心场景和参考技术架构，以期为这个全新领域提供具象的定义，可落地的路线图和最佳实践。
阿里云容器服务 ACK 对云原生 AI 的定义 - 充分利用云的资源弹性、异构算力、标准化服务以及容器、自动化、微服务等云原生技术手段，为 AI/ML 提供工程效率高、成本低、可扩展、可复制的端到端解决方案。
核心场景
我们将云原生 AI 领域聚焦在两个核心场景：持续优化异构资源效率，和高效运行 AI 等异构工作负载。
图1：云原生 AI 的核心场景
场景 1、优化异构资源效率
对阿里云 IaaS 或者客户 IDC 内各种异构的计算（如CPU，GPU，NPU，VPU，FPGA，ASIC）、存储（OSS，NAS， CPFS，HDFS）、网络（TCP， RDMA）资源进行抽象，统一管理、运维和分配，通过弹性和软硬协同优化，持续提升资源利用率。
场景 2、运行 AI 等异构工作负载
兼容 Tensorflow，Pytorch，Horovod，ONNX，Spark，Flink 等主流或者用户自有的各种计算引擎和运行时，统一运行各类异构工作负载流程，统一管理作业生命周期，统一调度任务工作流，保证任务规模和性能。一方面不断提升运行任务的性价比，另一方面持续改善开发运维体验和工程效率。
围绕这两个核心场景，可以扩展出更多用户定制化场景，比如构建符合用户使用习惯的 MLOps 流程；或者针对 CV 类（Computer Vision, 计算机视觉）AI 服务特点，混合调度 CPU，GPU，VPU（Video Process Unit）支持不同阶段的数据处理流水线；还可以针对大模型预训练和微调场景，扩展支持更高阶的分布式训练框架，配合任务和数据调度策略，以及弹性、容错方案，优化大模型训练任务成本和成功率。
参考架构
为了能支撑上述核心场景，我们提出了云原生 AI 参考技术架构。
图 2：云原生 AI 参考架构图
云原生 AI 参考技术架构以组件化、可扩展和可组装的白盒化设计原则，以 Kubernetes 标准对象和 API 暴露接口，支持开发运维人员按需选择任意组件，进行组装和二次开发，快速定制化构建出自己的 AI 平台。
参考架构中以 Kubernetes 容器服务为底座，向下封装对各类异构资源的统一管理，向上提供标准 Kubernetes 集群环境和 API，以运行各核心组件，实现资源运维管理、AI 任务调度和弹性伸缩、数据访问加速、工作流编排、大数据服务集成、AI 作业生命周期管理、各种 AI 制品管理、统一运维等服务。再向上针对 AI 生产流程（MLOps）中的主要环节，支持 AI 数据集管理，AI模型开发、训练、评测，以及模型推理服务；并且通过统一的命令行工具、多种语言 SDK 和控制台界面，支持用户直接使用或定制开发。而且通过同样的组件和工具，也可以支持云上 AI 服务、开源 AI 框架和第三方 AI 能力的集成。
企业需要什么样的云原生 AI 能力
我们定义了云原生 AI 的概念、核心场景、设计原则和参考架构。接下来，需要提供什么样的云原生 AI 产品给用户呢？通过对 ACK 上运行 AI 任务的用户调研，对云原生、MLOps、MLSys 等社区的观察，结合业界一些容器化 AI 产品的分析，我们总结出一款云原生 AI 产品需要具备的特征和关键能力。
图 3：企业需要什么样的云原生 AI 能力
- 效率高
主要包括：异构资源使用效率，AI 作业运行和管理效率，租户共享和团队协作效率等三个维度
- 兼容性好
兼容常见的 AI 计算引擎和模型。支持各类存储服务，并能提供通用的数据访问性能优化能力。可以与多种大数据服务集成，并能被业务应用方便地集成。特别地，还要符合数据安全与隐私保护的要求。
- 可扩展
产品架构实现可扩展、可组装、可复现。提供标准API和工具，便于使用、集成和二次开发。同样的架构下，产品实现尽量适配公共云，专有云，混合云，以及边缘等多种环境的交付。
阿里云容器服务 ACK 云原生 AI 套件
基于云原生 AI 参考架构，面向上述核心场景和用户需求，阿里云容器服务团队在 2021 年正式发布了 ACK 云原生 AI 套件产品[5]，已经在全球 27 个区域同步上线公测，帮助 Kubernetes 用户快速定制化构建自己的云原生 AI 平台。
ACK 云原生 AI 套件主要面向 AI 平台开发运维团队，帮助其快速、低成本地管理 AI 基础设施。同时将各组件功能封装成命令行和控制台工具，供数据科学家和算法工程师直接使用。用户在 ACK 集群中安装云原生 AI 套件后，所有组件开箱即用，快速实现统一管理异构资源和低门槛运行 AI 任务。产品安装和使用方式，可以参考产品文档[6]。
架构设计
图 4：云原生 AI 套件架构大图
云原生 AI 套件的功能从底向上分为：
- 异构资源层，包括异构算力优化和异构存储接入
- AI 调度层，包括各种调度策略优化
- AI 弹性层，包括弹性 AI 训练任务和弹性 AI 推理服务
- AI 数据加速与编排层，包括数据集管理，分布式缓存加速，大数据服务集成
- AI 作业管理层，包括 AI 作业全生命周期管理服务和工具集
- AI 运维层，包括监控、日志、弹性伸缩、故障诊断和多租户
- AI 制品仓库，包括 AI 容器镜像，模型和 AI 实验记录
下文将简要介绍云原生 AI 套件产品中异构资源层，AI 调度层，AI 弹性任务层，AI 数据加速与编排层和 AI 作业管理层的主要能力和基本架构设计。
1、异构资源统一管理
云原生 AI 套件在 ACK 上，增加了对 Nvidia GPU，含光 800 NPU，FPGA，VPU，RDMA 高性能网络等各种异构资源的支持，基本覆盖了阿里云上所有设备类型，使得在 Kubernetes 中使用这些资源的方式和使用 CPU、内存一样简单，只要在任务参数中声明需要的资源数量即可。针对 GPU，NPU 这类比较昂贵的资源，还提供了多种资源利用率优化方法。
图 5：异构资源统一管理
GPU 监控
针对 GPU 提供了多维度监控能力，使得 GPU 的分配、使用和健康状态一目了然。通过内置Kubernetes NPD（Node Problem Detector）自动检测和告警 GPU 设备异常。
图 6：GPU 监控
GPU 弹性伸缩
结合 ACK 弹性节点池提供的多种弹性伸缩能力，对 GPU 在资源节点数和运行任务实例数两层都可以按需自动伸缩。触发弹性的条件既有 GPU 的资源使用指标，也支持用户自定义指标。伸缩节点类型支持普通 EGS 实例，也支持 ECI 实例，Spot 实例等。
图 7：GPU 弹性伸缩
GPU 共享调度
原生 Kubernetes 仅支持以 GPU 整卡粒度为单位调度，任务容器会独占 GPU 卡。如果任务模型比较小（计算量、显存用量），就会造成 GPU 卡资源空闲浪费。云原生 AI 套件提供了 GPU 共享调度能力，可以按模型的 GPU 算力和显存需求量，将一块 GPU 卡分配给多个任务容器共享使用。这样理论上就能够用更多任务最大限度地占满 GPU 资源。
同时，为了避免共享 GPU 的多个容器之间相互干扰，还集成了阿里云 cGPU 技术，确保共享使用GPU的安全性和稳定性。容器间使用 GPU 资源是相互隔离的。不会出现超用，或者发生错误时彼此影响。
GPU 共享调度还支持多种分配策略，包括单容器单 GPU 卡共享，常用于支持模型推理场景；单容器多 GPU 卡共享，常用于开发环境中调试分布式模型训练；GPU 卡Binpack/Spread 策略，可以平衡 GPU 卡的分配密度和可用性。类似的细粒度共享调度能力也适用于 ACK 集群中的阿里自研含光 800 AI 推理芯片。
图 8：GPU 共享调度
GPU 共享调度和 cGPU 隔离对 GPU 资源利用率提升是显而易见的，已经有很多用户案例。比如某客户将数百台不同型号 GPU 实例，以显存维度统一划分池化，利用 GPU 共享调度和显存自动弹性伸缩，部署了上百种 AI 模型。既大幅度提高资源利用率，也显著降低运维复杂度。
GPU 拓扑感知调度
随着深度学习模型复杂度和训练数据量提升，多 GPU 卡分布式训练已经很非常普遍。对于使用梯度下降优化的算法，多 GPU 卡之间需要频繁传输数据，数据通信带宽往往成为限制 GPU 计算性能的瓶颈。
GPU 拓扑感知调度功能，通过获取计算节点上所有 GPU 卡间连接拓扑结构，调度器为多卡训练任务选择 GPU 资源时，根据拓扑信息考虑 NVLINK，PCIe Switch，QPI 以及 RDMA 网卡等所有互联链路，自动选择出能够提供最大通信带宽的 GPU 卡组合，避免带宽限制影响 GPU 计算效率。开启 GPU 拓扑感知调度完全是可配置的工作，对模型和训练任务代码都是零侵入的。
图 9：GPU 拓扑感知调度
通过与普通 Kubernetes 调度和运行多卡 GPU 分布式训练任务的性能对比，可以发现对于同样的计算引擎（如 Tensorflow，Pytorch 等）和模型任务（Resnet50， VGG16等），GPU 拓扑感知调度可以零成本带来效率提升。相较于较小的 Resnet50 模型，由于 VGG16 模型训练过程引入的数据传输量较大，更优的GPU 互联带宽对训练性能提升效果会更加明显。
上一篇：
大中小项目的分类方法是什么？
