一、前言过去几年，以容器技术为代表的云原生领域得到了极大的关注和发展。实施容器化是企业降本增效的重要手段。至此，得物基本完成了全域的容器化。在容器化过程中，一方面，服务部署和运维模式已经从之前的ECS模式平滑切换到容器化模式；另一方面，公司在资源利用和研发效率方面获得了很多收益。得物是新一代时尚网购社区。基于人工智能和大数据技术的搜索引擎和个性化推荐系统是业务发展的有力支撑。因此，算法领域的应用在业务应用中占据了很大的比重。在容器化过程中，针对算法应用服务研发过程与普通服务的差异，在充分调研算法领域研发同学需求的基础上，构建了云原生AI平台—KubeAI平台—面向算法领域的研发场景。经过功能的不断迭代和支持场景的不断扩展，KubeAI目前已经支持CV、搜索推荐、风控算法、数据分析等涉及AI能力的业务领域，并成功完成了容器化，提高了资源利用率和研发效率。上述改进取得了较好的效果。本文将带你了解KubeAI的实现过程。2.AI业务容器化推进2.1AI算法模型开发过程AI业务更多的是模型的迭代开发过程。通常，模型开发过程可以概括为以下几个步骤：确定需求场景：这个过程要明确解决什么问题，提供的功能是针对什么场景，功能/服务的输入是什么，是什么是输出？例如：用什么牌子的鞋子做鉴定或质检，该品牌的产品特点是什么，样品的尺寸是多少，特点的种类等等。不同场景对样本数据的要求不同，处理算法也不同。数据准备：根据场景需求分析结果，通过各种方式（在线/离线/mock等）获取样本数据，对数据进行必要的清洗和标注操作。这个过程是AI业务发展的基础，因为后面的所有过程都是以数据为基础的。确定算法，编写训练脚本：算法同学基于对业务目标的理解，根据以往的经验，或者场景的研究、实验结果，选择合适的算法，编写模型训练脚本。模型训练：对于算法模型，我们可以理解为一个复杂的数学公式，有很多参数，就像f(x)=wx+b中的w和b。训练是利用大量样本数据寻找最优参数以使模型具有较高识别率的过程。模型训练是AI业务发展过程中的重要一环。可以说，业务目标的达成取决于模型的准确性。因此，该环节比其他环节花费更多的时间、精力和资源，需要反复进行实验训练，才能达到最好的模型精度和预测精度。这个过程不是一次性的，而是周期性的。根据业务场景的更新，需要周期性的进行数据的更新。对于算法模型的开发和训练，业界有一些主流的AI引擎可以选择，比如TensorFlow、PyTorch、MXNet等，这些引擎可以提供一定程度的API支持，方便算法开发者分发复杂的models训练，或者对硬件做一些优化，提高模型训练的效率。模型训练的结果就是得到模型文件。这个文件的内容可以理解为保存了模型的参数。模型评价：为了防止模型因偏差过大而欠拟合或因方差过大而过拟合，通常需要一些评价指标来指导开发者评价模型的泛化能力。一些常用的评估指标，如：准确率、召回率、ROC曲线/AUC、PR曲线等。模型部署：经过反复训练和评估，可以得到一个理想的模型，帮助业务处理线上/生产数据。这需要以服务或任务的形式部署模型，以便接受输入数据并提供推理结果。我们称此服务为模型服务。模型服务是在线服务脚本，加载模型并在准备好后对预处理后的数据进行推理计算。模型服务上线后，由于数据特征变化、算法升级、在线推理服务脚本升级、推理指标新业务需求等，需要对模型服务进行迭代。需要注意的是，这个迭代过程可能需要对模型进行再训练和重新评估；也可能是推理服务脚本的迭代升级。2.2容器化迁移如火如荼从去年开始，我们逐步在各个领域推进容器化业务服务的落地。为了减少容器化过程中部署方式的改变而导致的用户操作习惯的改变，我们继续沿用发布平台的部署流程来屏蔽容器部署和ECS部署的差异。在CI过程中，根据不同的开发语言类型，定制不同的编译构建模板。从源码编译到容器镜像制作，由容器平台层完成，解决了普通研发同学无法将工程代码制作成容器镜像的问题。在CD过程中，我们在应用类型级别、环境级别、环??境组级别进行配置分级管理。在进行部署时，我们将多层配置合并到HelmChart的values.yaml中，并将编排文件提交给容器集群。用户只需根据自己的实际需要设置相应的环境变量，然后提交部署，即可获取应用集群实例（容器实例，类似于ECS服务实例）。针对应用集群的运维，容器平台提供WebShell登录容器实例，就像登录ECS实例一样，方便排查应用进程相关问题；容器平台还提供文件上传下载、实例重启重构、资源监控等运维功能。AI业务（CV、搜索推送、风控算法服务等）作为一个比较大的业务，和普通业务服务一起参与到容器化过程中。核心场景服务迁移。容器化之后，测试环境的资源利用率有了很大的提升，生产环境也有了很大的提升，运维效率成倍提升。2.3算法容器化的进程伴随着公司技术体系的快速发展，使得最初不成熟的AI服务研发过程对容器化提出了更多的要求，使得原本专注于在线推理服务的容器化，我们有了看到了算法同学在模型开发过程中的痛点和难点。痛点一：模型的管理和推理服务的管理不连贯。大部分CV模型都是在桌面上训练，然后手动上传到OSS，然后将OSS上模型文件的地址配置到onlineinferenceservice。大部分搜索和推送模型都是在PAI上训练的，但是也是手动存储在OSS上的，发布的时候和CV类似。可以看出模型的产品在模型训练和发布过程中的管理是不连贯的。无法跟踪模型部署在哪些服务上，无法直观地看到某个服务部署在哪些服务上。或者多个机型，机型版本管理不便。痛点二：模型开发环境准备时间长，资源申请使用缺乏弹性机制。在容器化之前，资源一般以ECS实例的形式提供。必须要经过申请资源的过程。应用后各种初始化任务、软件安装、依赖安装、数据传输（算法研究工作用到的软件库大多比较大，安装比较复杂）。一个ECS做好后，如果资源不够用，需要重新申请，重复同样的流程，效率低下。同时，资源申请受配额（预算）约束，没有自主管理、灵活申请、按需释放的机制。痛点三：一些云原生支持的模型方案难以尝试。随着云原生技术在各个领域的不断落地，Kubeflow、ArgoWorkflow等解决方案为AI场景提供了很好的支持。例如：tfjob-operator可以以CRD的形式管理基于TensorFlow框架的分布式训练任务。用户只需设置相应组件（Chief、PS、Worker等）的参数，即可向Kubernetes集群提交训练任务。在容器化之前，算法的同学如果想尝试这个方案，必须要熟悉和掌握Docker、Kubernetes等容器相关的知识，不能以普通用户的身份使用这个能力。痛点四：非算法部门想要快速验证一个算法时，找不到一个支撑良好的平台。AI的能力显然在各个业务领域都有应用，尤其是一些成熟的算法，可以很方便的被业务团队用来做一些基线指标预测或者分类预测的工作，从而帮助业务取得更好的效果。这时候就需要有一个平台能够提供AI相关的能力，满足这些场景对异构资源（CPU/GPU/存储/网络等）和算法模型管理的需求，为用户提供现成的-使用功能。基于以上痛点和难点问题的梳理和分析，以及基于算法同学在容器化过程中对容器平台提出的其他需求（如：模型统一管理需求、日志采集需求、资源池化等）需求，数据持久化需求等），我们一一讨论，一一突破。在解决当前问题的同时，我们也考虑了平台长远的功能规划，逐步构建了基于容器平台、面向AI服务的KubeAI平台解决方案。3、KubeAI平台解决方案基于充分研究学习业界AI平台的基本架构和产品形态，围绕AI业务场景及其周边业务需求，由容器技术团队设计和在容器化过程中逐步实现云原生AI平台——KubeAI平台。KubeAI平台专注于解决算法同学的痛点需求，提供必要的功能模块，贯穿模型开发、发布和运维全流程，帮助算法开发者快速、低成本获取和使用AI基础设施资源，快速并高效地实施算法模型设计、开发和实验。3.1总体架构KubeAI平台围绕模型的整个生命周期提供了以下功能模块：数据集管理：主要兼容不同数据源，同时提供数据缓存加速能力。模型训练：不仅提供Notebook进行模型开发训练，还支持一次性/周期性任务的管理；这个过程中异构资源（CPU/GPU/存储）的弹性申请和释放。模型管理：模型元数据（模型基础信息、版本列表等）统一管理，与模型服务发布、运维流程无缝衔接。推理服务管理：模型与推理代码解耦，不将模型封装到图像中，提高推理服务的更新效率；支持在线服务升级机型。AI-Pipeline引擎：支持以流水线方式编排任务，满足数据分析、模型周期性例行训练任务、模型迭代等场景需求。KubeAI平台不仅支持个人用户，也支持平台用户。个人开发者和学生使用KubeAI的Notebook开发模型脚本。较小的模型可以直接在Notebook中训练，复杂的模型可以通过任务进行训练。模型生产出来后，在KubeAI上进行统一管理，包括作为推理服务发布和新版本的迭代。第三方业务平台通过OpenAPI获取KubeAI的能力，进行上层业务创新。下面重点介绍数据集管理、模型训练、模型服务管理和AI-Pipeline引擎四个模块的功能。3.2数据集管理算法同学使用的数据经过整理后要么存入NAS，要么从ODPS读取，要么从OSS拉取。为了统一数据管理，KubeAI基于KubernetesPVC（PersistentVolumeClaim）资源，为用户提供数据集的概念，兼容不同的数据源格式。同时，为了解决计算存储分离架构带来的数据访问开销大的问题，我们使用Fluid为数据集配置缓存服务，可以在本地缓存数据，用于下一轮迭代计算，或者scheduletasksto数据集已经缓存在计算节点上。3.3模型训练对于模型训练，我们主要做了三个方面的工作：(1)基于JupyterLab，提供了Notebook功能，用户可以通过shell或者WebIDE以等同于本地的开发方式开发算法模型.（2）模型训练以任务的形式进行，可以更加灵活的申请和释放资源，提高资源的利用率，大大降低模型训练的成本。基于Kubernetes良好的扩展性，可以轻松对接业界各种TrainingJobCRD，支持Tensorflow、PyTorch、xgbost等训练框架。任务支持批量调度和任务优先级队列。(3)与算法团队合作，对Tensorflow训练框架进行部分优化，在批量数据读取效率和PS/Worker之间的通信速率上取得一定的提升；一些解决方案。3.4模型服务管理与普通服务相比，模型服务最大的特点是服务需要加载一个或多个模型文件。在容器化初期，由于历史原因，大部分CV模型服务直接将模型文件和推理脚本打包到容器镜像中，导致容器镜像比较大，模型版本更新繁琐。KubeAI改变了上述问题。基于模型的标准化管理，模型服务通过配置与模型关联。发布时，平台根据模型配置拉取对应的模型文件，供推理脚本加载。这种方式减轻了算法模型开发者管理推理服务镜像/版本的压力，减少了存储冗余，提高了模型更新/回滚的效率，提高了模型重用性，帮助算法团队更方便快捷地管理一个模型及其关联的在线推理服务。3.5AI-Pipeline引擎的实际业务场景不会是单个任务节点。例如，一个完整的模型迭代过程大致包括数据处理、模型训练、使用新模型更新在线推理服务、小流量验证和官方发布链接。KubeAI平台提供了基于ArgoWorkflow的工作流编排引擎。工作流节点支持自定义任务、平台预设模板任务、各种深度学习AI训练任务（TFJob、PyTorchJob等）。4、在KubeAI上实现AI业务场景的典型案例4.1CV算法模型开发过程CV算法模型的开发模式一般是研究理论算法，开发工程实践算法模型，随时调试。因为模型一般比较小，相对于search和push模型，训练成本更低，所以CV同学更习惯在notebook中开发好训练脚本后，直接在notebook中训练。用户可以自主选择为Notebook配置CPU、GPU卡、网络存储盘等资源。通过开发调试，训练脚本满足需求后，用户可以使用KubeAI提供的任务管理功能，将训练脚本配置为单机训练任务或分布式训练任务，提交至KubeAI平台进行执行。平台会调度任务在资源充足的资源池中运行，运行成功后将模型推送到模型仓库，注册到KubeAI的模型列表中；或将模型保存在指定位置，供用户选择确认。模型制作完成后，用户可以直接在KubeAI的模型服务管理中将模型部署为推理服务。当以后有新版本的模型产生时，用户可以为推理服务配置新的模型版本。然后，根据推理引擎是否支持模型热更新，可以通过重新部署服务或创建模型升级任务来完成推理服务中的模型升级。在机器识别业务场景中，通过AI-Pipeline工作流对上述流程进行编排，周期性进行模型迭代，模型迭代效率提升约65%。CV场景接入KubeAI平台后，摒弃了之前的本地训练方式，在平台上灵活按需获取资源的方式大大提高了资源利用率；在模型管理、推理服务管理、模型迭代等方面，提升研发效率。约50%。4.2搜索推送模型训练任务从PAI迁移到KubeAI平台相比CV模型，搜索推送模型训练成本更高，主要体现在数据样本大、训练时间长、资源量大需要一个单一的任务。在KubeAI落地之前，因为我们的数据存储在ODPS（阿里通用计算平台提供的数据仓库解决方案，现更名为MaxCompute）上，搜索和推送算法基本都在Dataworks（基于ODPS的大数据）。开发管理平台）在控制台构建数据处理任务，同时向PAI平台提交模型训练任务。但由于PAI是公有云产品，提交给它的单个任务的成本要高于任务本身所需的资源成本，高出的部分其实可以理解为技术服务费；也无法满足企业内部的成本控制需求。在KubeAI逐步落地之后，我们会通过两种方式，逐步将PAI上的搜索和推送场景的模型训练任务迁移到我们的平台上。方法一是保持用户在Dataworks中工作的习惯，将一些SQL任务放在Dataworks中完成，然后通过shell命令将任务提交到KubeAI平台；方式二是直接将任务提交到KubeAI平台。我们预计随着数据仓库基础设施的完善，未来会逐渐完全切入第二种方式。搜推模型训练任务的开发过程充分利用了KubeAI提供的开发环境和工具。通过自研训练项目Framwork，在只使用CPU的情况下，训练时间可以与PAI上使用GPU的训练时间匹配；训练引擎端也提供对大模型训练和实时训练场景的支持，配合多类存储（OSS/文件存储）方案、模型分发方案，保证大模型训练任务的成功率，高效完成在线服务的模型更新。在资源调度和管理方面，KubeAI充分利用集群联邦、超卖机制、任务绑定等技术手段，逐步改变训练任务使用专用资源池的方式，为任务Pod分配弹性资源，并调度到在线资源库和公共资源。水池。充分利用生产任务的周期性执行和白天开发任务的特点，实行错峰调度和差异化调度（如：小规模使用弹性资源，大范围使用常规资源等）。战略）。从近几个月的数据来看，我们继续承接了比较大的任务增量，而总的资源增量变化不大。4.3基线指数预测场景这是一个典型的使用AI能力的非算法业务场景。比如用Facebook的prophet算法来预测某个业务指标的基线。KubeAI针对这些场景的需求提供了基础AI能力，解决了他们“成熟算法难以快速验证”的问题。用户只需通过工程化（利用现有最佳实践，或二次开发）实现算法模型，然后制作容器镜像，在KubeAI上提交任务，开始执行，即可得到想要的结果；或者定期进行训练和推理以获得基线预测。可按需配置用户任务所需的计算资源或其他异构资源。目前，以某线上业务场景的12个指标为例，每天执行近2万个任务。与以往类似需求的资源成本相比，KubeAI帮助其节省了近90%的成本，研发效率提升了3倍左右。5、展望得物在较短的时间内成功实现了业务的容器化。一方面得益于云原生技术本身的日益成熟，另一方面也得益于我们对自身业务场景需求的深入理解，并能提供有针对性的解决方案。KubeAI平台是基于如何在深入分析算法业务场景痛点需求后，持续提升AI业务场景工程效率，提高资源利用率，降低AI模型/服务开发门槛，逐步落地迭代地。未来，我们将在训练引擎优化、细粒度AI任务调度、弹性模型训练等方面继续发力，进一步提升AI模型训练和迭代效率，提高资源利用率。
