关于kubernetes:摆脱-AI-生产小作坊如何基于-Kubernetes-构建云原生-AI-平台

简介：本文将介绍和梳理咱们对云原生 AI 这个新畛域的思考和定位，介绍云原生 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 平台。把数据科学家和算法工程师从繁冗低效的环境治理、资源分配和任务调度工作中解放出来，把他们更多的精力留给“脑洞”算法和“炼丹”。

图 0：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 互联带宽对训练性能晋升成果会更加显著。

图 10：GPU 拓扑感知调度 vs 一般多卡 GPU 调度的训练性能

2、AI 任务调度（Cybernetes）

AI 分布式训练是典型的批量工作类型。用户提交的一个训练任务（Job），在运行时个别会由一组子工作（Task）独特运行能力实现。不同 AI 训练框架对子工作分组有不同的策略，比方 Tensorflow 训练任务能够采纳多个 Parameter Servers 子工作 + 多个 Workers 子工作的分组，Horovod 运行 Ring all-reduce 训练时，采纳一个 Launcher + 多个 Workers 的策略。

在 Kubernetes 中，一个子工作个别对应一个 Pod 容器过程。调度一个训练任务，就转化为对一组，或多组子工作 Pod 容器的独特调度。这相似 Hadoop Yarn 对 MapReduce，Spark 批量作业的调度。Kubernetes 默认调度器只能以单个 Pod 容器为调度单元，无奈满足批量任务调度的需要。

ACK 调度器（Cybernetes[7]）扩大 Kubernetes 原生调度框架，实现了很多典型批量调度策略，包含 Gang Scheduling（Coscheduling）、FIFO scheduling、Capacity Scheduling、Fair sharing、Binpack/Spread 等。还减少了新的优先级工作队列，反对自定义的工作优先级治理和租户弹性资源配额管制；也能够集成 Kubeflow Pipelines 或 Argo 云原生工作流引擎，为简单的 AI 工作提供工作流编排服务。由“工作队列 + 任务调度器 + 工作流 + 工作控制器”组成的架构，为基于 Kubernetes 构建批量工作零碎提供了根底撑持，同时也显著晋升集群整体资源利用率。

目前，云原生 AI 套件环境里不仅能够反对 Tensorflow，Pytorch，Horovod 等各种深度学习 AI 工作训练，也能够反对 Spark，Flink 等大数据工作，还可能反对 MPI 高性能计算作业。咱们也将局部批量任务调度能力，奉献给了 Kubernetes 调度器上游开源我的项目，并继续推动社区向云原生工作零碎基础架构演进。可返回 Github 理解相干我的项目详情：https://github.com/kubernetes…

图 13：ACK Cybernetes 调度器

ACK 调度器反对的典型批量任务调度策略举例如下：

图 14：ACK 反对的典型任务调度策略

• Gang Scheduling

集群可能满足一个工作的所有子工作的需要时才为工作整体分配资源，否则不为其调配任何资源。防止因为资源死锁，导致大工作挤占小工作。

• Capacity Scheduling

通过提供弹性配额和租户队列的设置，确保在满足租户最低资源需要调配的根底上通过弹性配额共享来晋升整体资源利用率。

• Binpack Scheduling

作业优先集中调配在某个节点，当节点资源有余时，顺次在下一节点集中调配，适宜单机多 GPU 卡训练任务，防止跨机数据传输。也能够避免大量小作业带来的资源碎片。

• Resource Reservation Scheduling

为特定作业预留资源，定向分配或者重复使用。既保证了特定作业取得资源的确定性，也减速了资源分配速度，还反对用户自定义预留策略。

3、弹性 AI 工作

弹性是云原生和 Kubernetes 容器集群最重要的根底能力。综合思考资源情况、利用忙闲水平和老本束缚，智能伸缩服务实例数和集群节点数，既要满足利用的根本服务质量，也要防止适度的云资源生产。云原生 AI 套件别离反对弹性模型训练任务和弹性模型推理服务。

弹性模型训练（Elastic Training）

反对弹性调度分布式深度学习训练任务。训练过程中能够动静伸缩子工作 worker 实例数量和节点数量，同时根本维持整体训练进度和模型精度。在集群资源闲暇时，减少更多 worker 减速训练，在资源缓和时，能够开释局部 worker，保障训练的根本运行进度。这样能够极大晋升集群的总体利用率，防止计算节点故障影响，同时显著缩小用户提交作业之后期待作业启动的工夫。

值得注意的是，弹性深度学习训练除了须要资源弹性能力外，还须要计算引擎和分布式通信框架的反对，还要算法、数据切分策略、训练优化器等多方面独特配合优化（找到最佳的办法保障 global batch size 和 learning rate 的适配），能力保障模型训练的精度指标和性能要求。目前业界还没有通用的伎俩，在广泛的模型上实现强复现的弹性训练。在肯定束缚下（模型特色，分布式训练方法，资源规模以及弹性幅度等），比方 32 卡 GPU 以内的 ResNet50，BERT 应用 Pytorch 和 Tensorflow 都有稳固的办法实现称心的弹性训练收益。

图 15：弹性 AI 训练

弹性模型推理服务（Elastic Inference）

联合阿里云丰盛的资源弹性能力，充分利用包含停机不回收、弹性资源池、定时弹性、竞价实例弹性、Spotfleet 模式等各种资源类型，主动扩缩容 AI 推理服务。在服务性能和老本之间维持较优化的均衡。

事实上，AI 模型在线推理服务的弹性，以及服务化运维，与微服务和 Web 利用是比拟相似。很多云原生已有技术都能够间接用在在线推理服务上。然而 AI 模型推理仍然有很多非凡之处，模型优化办法、流水线服务化、精细化的调度编排、异构运行环境适配等等方面都有专门诉求和解决伎俩，这里不再开展。

4、AI 数据编排与减速（Fluid）

在云上通过云原生架构运行 AI、大数据等工作，能够享受计算资源弹性的劣势，但同时也会遇到，计算和存储拆散架构带来的数据拜访提早和近程拉取数据带宽开销大的挑战。尤其在 GPU 深度学习训练场景中，迭代式的近程读取大量训练数据办法会重大拖慢 GPU 计算效率。

另一方面，Kubernetes 只提供了异构存储服务接入和治理标准接口（CSI，Container Storage Interface），对利用如何在容器集群中应用和治理数据并没有定义。在运行训练任务时，数据科学家须要可能治理数据集版本、管制拜访权限、数据集预处理、减速异构数据读取等。然而在 Kubernetes 中还没有这样的规范计划，这是云原生容器社区缺失的重要能力之一。

ACK 云原生 AI 套件对“计算工作应用数据的过程”进行形象，提出了弹性数据集 Dataset 的概念，并作为“first class citizen”在 Kubernetes 中实现。围绕弹性数据集 Dataset，ACK 创立了数据编排与减速零碎 Fluid，来实现 Dataset 治理（CRUD 操作）、权限管制和拜访减速等能力。

Fluid 能够为每个 Dataset 配置缓存服务，既能在训练过程中将数据主动缓存在计算工作本地，供下轮迭代计算，也能将新的训练任务调度到已存在 Dataset 缓存数据的计算节点上运行。再加上数据集预热、缓存容量监控和弹性伸缩，能够大大降低工作近程拉取数据的开销。Fluid 能够将多个不同类存储服务作为数据源（比方 OSS，HDFS）聚合到同一个 Dataset 中应用，还能够接入不同地位的存储服务实现混合云环境下的数据管理与拜访减速。

图 16：Fluid Dataset

算法工程师在 AI 工作容器中应用 Fluid Dataset 与在 Kubernetes 中应用 PVC（Persistent Volume Claim）的形式相似，只需在工作形容文件中指定 Dataset 的名字，并作为 volume 挂载到容器中工作读取数据的门路即可。咱们心愿为训练任务减少 GPU 资源，能近乎线性地放慢模型的训练速度。但往往受限于更多 GPU 并发拉取 OSS bucket 的带宽限度，单纯减少 GPU 并不能无效提速训练。通过应用 Fluid Dataset 的分布式缓存能力，无效化解了近程并发拉数据的性能瓶颈，使得分布式训练扩大 GPU 取得更好的减速比。

图 17：Fluid 分布式缓存减速模型训练性能比照

ACK 团队联结南京大学、Alluxio 公司，独特发动了 Fluid 开源我的项目[8]，并托管为 CNCF 沙箱我的项目，心愿能与社区一起推动云原生数据编排和减速畛域的倒退和落地。Fluid 的架构能够通过 CacheRuntime plugin 的形式，扩大兼容多种分布式缓存服务。目前曾经反对了阿里云 EMR 的 JindoFS，开源的 Alluxio，Juicefs 等缓存引擎。无论在开源社区共建，还是云上用户落地都获得了不错的停顿。

图 18：Fluid 零碎架构

Fluid 云原生数据编排和减速的次要能力包含：

• 通过数据亲和性调度和分布式缓存引擎减速，实现数据和计算之间的交融，从而减速计算对数据的拜访。
• 将数据独立于存储进行治理，并且通过 Kubernetes 的命名空间进行资源隔离，实现数据的平安隔离。
• 将来自不同存储的数据联结起来进行运算，从而有机会突破不同存储的差异性带来的数据孤岛效应。

5、AI 作业生命周期治理（Arena）

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

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

对于 AI 服务的生产过程，次要蕴含数据筹备与治理、模型开发构建、模型训练、模型评测、模型推理服务上线运维等阶段。这些环节以循环迭代的形式，依据线上数据变动，继续优化更新模型，通过推理服务将模型公布到线上，收集到新的数据，进入下一轮迭代。

图 19：深度学习 AI 工作生命周期

云原生 AI 套件将这个生产过程中的次要工作环节进行形象，并以命令行工具 Arena[9] 实现治理。Arena 齐全屏蔽了底层资源和环境治理，任务调度，GPU 调配和监控的复杂性，兼容支流 AI 框架和工具，包含 Tensorflow, Pytorch, Horovod, Spark, JupyterLab, TF-Serving, Triton 等。

除了命令行工具，Arena 还反对 golang/java/python 语言 SDK，便于用户二次开发。另外，思考到不少数据科学家习惯应用 Web 界面治理资源和工作，云原生 AI 套件也提供了简略的运维大盘和开发控制台，满足用户疾速浏览集群状态、提交训练任务的须要。这些组件独特造成了云原生 AI 作业管理工具集 Arena。

Kubeflow[10] 是 Kubernetes 社区中反对机器学习负载的支流开源我的项目。Arena 曾经内置 Kubeflow 的 TensorflowJob，PytorchJob，MPIJob 工作控制器，以及开源的 SparkApplication 工作控制器，也能够集成 KFServing，Kubeflow Pipelines 我的项目。用户在 ACK 集群中无需独自装置 Kubeflow，只须要应用 Arena 即可。

值得一提的是，ACK 团队晚期也将 arena 命令行和 SDK 工具奉献到了 Kubeflow 社区，有很多企业用户通过扩大、封装 arena，构建了本人的 AI 平台 MLOps 流程和体验。

图 20：Arena 架构

云原生 AI 套件次要为以下两类用户解决问题：

• AI 开发人员，如数据科学家和算法工程师
• AI 平台运维人员，如 AI 集群管理员

AI 开发人员能够应用 arena 命令行或者开发控制台 Web 界面，创立 Jupyter notebook 开发环境，提交和治理模型训练任务，查问 GPU 分配情况，实时查看训练任务日志、监控和可视化数据，比照评测不同模型版本，并将选出的模型部署到集群，还能够对线上模型推理服务进行 AB 测试、灰度公布、流控和弹性伸缩。

# 提交 Tensorflow 分布式训练任务
arena submit mpijob
    --name=tf-dist-data --workers=6 --gpus=2 --data=tfdata:/data_dir \
    --env=num_batch=100 --env=batch_size=80 --image=ali-tensorflow:gpu-tf-1.6.0 \ 
    "/root/hvd-distribute.sh 12 2”

# 查看训练任务状态
arena get tf-dist-data
NAME          STATUS       TRAINER  AGE  INSTANCE                              NODE
tf-dist-data  RUNNING        tfjob       3d     tf-dist-data-tfjob-ps-0        192.168.1.120
tf-dist-data  SUCCEEDED  tfjob       3d     tf-dist-data-tfjob-worker-0   N/A
tf-dist-data  SUCCEEDED  tfjob      3d     tf-dist-data-tfjob-worker-1     N/A

Your tensorboard will be available on:
192.168.1.117:32594

图 21：Arena 开发控制台

AI 集群管理员能够应用 Arena 运维大盘理解和治理集群资源、工作，配置用户权限、租户配额以及数据集治理等。

图 22：Arena 运维大盘

用户案例

云原生 AI 套件在晚期公测时曾经取得不少用户的趣味和测试。用户行业包含了互联网、在线教育、主动驾驶等 AI 重度用户。这里分享两个代表性用户案例。

• 微博

微博深度学习平台 [11] 借助 Kubernetes 混合星散群，对立治理阿里云上的 GPU 实例和 IDC 内的资源。

通过异构资源调度、监控和弹性伸缩能力，对立治理大量 GPU 资源。利用 GPU 共享调度能力，在 AI 模型推理服务场景大幅晋升 GPU 利用率。

通过封装 Arena，定制开发了微博本人的 AI 工作治理平台，将所有深度学习训练任务集中管理，工程效率取得 50% 晋升。
通过应用 AI 任务调度器，实现大规模 Tensorflow 和 Pytorch 分布式训练任务的高效调度。

通过应用 Fluid + EMR Jindofs 分布式缓存能力，尤其是针对 HDFS 中的海量小文件缓存优化，把 Pytorch 分布式训练任务端到端速度晋升了数倍。用户测试极其状况下，训练时长从两周缩短到 16 小时[12]。

• 毫末智行

毫末智行是长城汽车投资的智能驾驶明星守业公司。毫末很晚期就启动了基于云原生技术构建对立 AI 工程平台的工作。毫末首先应用 Kubeflow，arena 工具集，GPU 对立调度等能力构建起本人的机器学习平台。进而集成了 Fluid+JindoRuntime，显著晋升了云端训练和推理的效率，尤其是一些小模型，在云端做训练和推理 JindoRuntime 能够无效解决 IO 瓶颈问题，训练速度最高可晋升约 300%。同时也大幅度晋升云端 GPU 应用效率，减速了在云端数据驱动的迭代效率。

图 23：毫末智行 AI 平台应用 Fluid 数据集减速分布式 GPU 训练

毫末智行不仅分享了基于 ACK 的云原生 AI 在主动驾驶畛域的利用摸索与落地实际[13]，也会和 Fluid 等云原生 AI 社区一起共建，打算进一步增强：

• 反对定时工作反对动静扩缩容
• 提供性能监控控制台
• 反对规模化 Kubernetes 集群中多数据集的全生命周期治理
• 反对对缓存数据和缓存元数据的动静删减

瞻望

企业 IT 转型大潮中对数字化和智能化的诉求越来越强烈，最突出的需要是如何能疾速、精准地从海量业务数据中开掘出新的商业机会和模式翻新，以更好应答多变、不确定性的市场挑战。AI 人工智能无疑是当下和将来帮忙企业实现这一指标最重要的伎俩之一。显然，如何继续晋升 AI 工程效率，优化 AI 生产成本，一直升高 AI 门槛，实现 AI 能力普惠，具备很大的事实价值和社会意义。

咱们清晰地看到，云原生在分布式架构、标准化 API 和生态丰盛度上的劣势，正在迅速成为用户高效应用云计算的新界面，来帮忙业务晋升服务敏捷性和可扩展性。越来越多用户也在积极探索如何基于云原生容器技术，晋升 AI 服务的生产效率。进而利用同一套技术堆栈撑持企业外部各种异构工作负载。

阿里云 ACK 提供云原生 AI 套件产品，从底层异构计算资源，AI 任务调度，AI 数据减速，到下层计算引擎兼容和 AI 作业生命周期治理，全栈撑持 AI 生产和运维过程。以简洁的用户体验，可扩大的架构，和对立优化的产品实现，减速用户定制化构建云原生 AI 平台的过程。咱们也将局部成绩分享到社区，以独特推动云原生 AI 畛域的倒退和落地。

原文链接
本文为阿里云原创内容，未经容许不得转载。