人工智能开发领域的发展呈现出数据量和模型规模越来越大、模型训练速度要求越来越快的特点。然而训练和推理任务速度慢、资源利用率、应用成本高等工程化问题阻碍了人工智能应用的落地。
据Gartner预测，到年70%的AI应用会基于容器和Serverless技术开发。实际生产中，越来越多的AI业务比如自动驾驶、NLP等也正在转向容器化部署。
近期IDC发布的《云原生AI-加速AI工程化落地》报告指出，云原生AI是连接AI应用和IaaS的桥梁，是加速AI工程化落地的关键。
云原生AI不是简单的“云原生+AI”，除了涵盖容器、K8s等云原生的通用能力之外，面向AI工作负载，如何支持GPU等异构资源，如何提升资源效能，如何支持超大模型的预训练等，都需要对应的配套技术和长期工程实践，才能真正满足AI业务落地的场景。
基于国内顶级AI业务锤炼出的深厚经验以及丰富的技术积累，百度智能云正式发布云原生AI2.0方案。
01融合大模型落地经验，云原生AI2.0重磅发布
自从年深度学习在图像和语音方面产生重大突破后，人工智能便真正具备了走出实验室步入市场的能力。
千亿级甚至万亿级参数的超大规模模型的出现，如百度发布的“文心”等，向深度学习框架的算力调度、调优算法等提出了更高的要求。
百度智能云将超大模型训练（文心等）的经验，资源管理和资源利用率优化的经验，以及多场景工程实践的经验充分融合进云原生AI2.0方案，用标准化的能力帮助企业应对缺乏大模型训练经验而导致的资源利用率低等问题，加速AI应用落地。
此次云原生AI2.0版本在资源弹性、跨节点架构感知、训练推理效率等方面做了重点升级。
02剑指工程化问题，助力AI应用落地
那么，百度智能云的云原生AI2.0方案解决了AI应用落地过程中的哪些工程化问题呢？
2.1超大模型的预训练如何落地？
虽然大模型有诸多优势，但具体预训练过程却很难：比如有亿条词语，需要亿的参数，这样的模型计算量大概是ZFlops，其中1ZFlops是EFlops，1EFlops又是PFlops，这是一个非常大的数量级。相关论文指出，如此的参数和样本量级，用张A卡，也需要月级别才能完成训练，这对整个训练和技术架构的挑战都非常大。
模型预训练需要这么多的参数，也需要很多的计算资源，因此需要搭建一个集群来支撑整个预训练。搭建一个集群并非易事，这个过程会有很多不同的选择，比如单机如何选择，训练卡如何选择，训练卡内部的互联方式如何选择，多机之间又该如何架设网络保证它们之间能高效通信，网络规模又是怎样的。如何保证在有故障发生的情况下，模型能持续稳定的预训练，这些都是在集群建设中很关键的问题。
具体而言，大模型通常是指拥有复杂网络、稠密参数特点的模型，集合通信模式可以很好的支持这类模型的训练。为了更有针对性的建设支撑大模型预训练，云原生AI2.0方案支持了支持了PaddlePaddle和Pytorch+DeepSpeed两种框架：
百度自研的PaddlePaddle框架，早在年4月份就推出业内首创的4D混合并行策略：数据并行、张量模型并行、分组参数切片并行、流水线并行。针对性能优化和显存优化，这几种策略相互组合，取长补短，能够在训练大模型时发挥各自的优势。
Pytorch原生混合并行能力欠缺，针对大模型场景混合并行场景，微软推出的DeepSpeed开源库，做为Pytorch框架在大模型训练方向上的补充。
此外，业界还在GPT-3基础上进一步提出混合专家模型(MixtureOfExpert,MoE)，使得计算量不增加的情况下，参数量可以扩大到万亿，如Switch-Transformer。MoE模式最大的特点是单个样本不再激活模型的所有参数，从而可以在控制计算量相对固定的情况下，极大程度的扩展模型参数容量。
在MoE模式下，可以将Transformer结构中的FeedForward部分看做一个专家，MoE结构由多个专家共同组成，并通过路由（router）的方式将信息分发给不同的专家，最终对专家的输出结果在进行聚合，并最终产出模型推理的结果。深度学习框架会引入专家并行策略，来存放如此巨大的Expert参数。
我们将上述相关模式进行仔细分析后的结论如下表（以0亿参数模型为例）：
很多企业因为缺乏上文提及的大规模集群实践经验而无法顺利完成超大模型的预训练，百度拥有8年多的万卡规模EFlops算力最佳实践的能力和积累，等效算力高达50%以上，数千卡并发训练线性加速比90%，整体大模型预训练的集群利用率高达95%。
在年6月30日最新发布的MLPerfTrainingv2.0榜单里，百度使用飞桨（PaddlePaddle）框架和百舸异构计算平台提交了BERTLarge模型的GPU性能结果，在同等机器条件下性能排名世界第一，向全世界展现了百度智能云的性能领先性。借助这些经验积累，百度智能云的云原生AI2.0方案针对超大模型的预训练提供了以下特色能力：
网络：全IB网络，盒式组网最大规模，单机转发延迟ns，千卡通信近线性扩展。
通信库：自研的异构集合通信库ECCL。由于业务会面临很多不同代的GPU，不同的异构芯片，如何把所有的芯片都高效使能起来，是要解决的一个关键问题。同时，在大规模上还需要解决一些拓扑探测、拓扑感知的问题，也会放在通信库中解决。结合上面的分析，我们知道混合并行模式下，不同并行模式对网络通信的需求是不同的。而集群中的硬件在机内和机间的不同层次，提供的通信能力也是不同的，通常情况下机内通信带宽最高，而机间同号卡通信效率最高（在8导轨优化网络拓扑下）。为了更好地使二者结合，就需要在调度及框架侧做好任务分配。而任务分配的前提是让训练任务知道集群硬件连接方式，也就是拓扑感知能力（如下图所示）。硬件拓扑感知需要同时感知单机硬件连接方式与集群网络连接方式，其中涉及PCIe、网络探测等诸多细节，我们将硬件拓扑感知的能力封装到ECCL通信库中，并作为集群标准的基础接口提供给上层的调度器和训练框架，从而联动配合地使能最高训练效率。
调度：跨节点架构感知高性能调度，支持通过慢节点感知发现分布式训练节点的性能瓶颈。在千卡规模的弹性训练的场景下，调度结合框架，能够提供容错功能，保证大规模训练的稳定性。
可观测：自研面向模型并行的多机调优profile工具，能够发现任务/数据分配不均等问题，经过优化的最终端到端吞吐可提升1倍以上。
实际上，不仅仅是超大模型预训练实际场景沉淀出的特色能力，云原生AI2.0还对资源弹性、训练推理效率、易用性等通用能力做了全面升级。
2.2如何保证资源的弹性？
GPU、NPU作为主要的AI算力资源，品牌型号多种多样且价格昂贵**，**如何有效的让这些算力资源充分发挥作用、提高资源利用效率，是资源管理层面需要解决的问题。
借助以容器为代表的云原生技术能够对CPU进行有效的虚拟化进而提升资源的利用率，但是容器技术不能直接被应用到GPU等算力上，需要做一定的技术升级和改造。
改造之后就可以将GPU等AI算力作资源虚拟化以及资源池化，能够将AI应用和GPU服务器硬件解耦，实现虚拟GPU资源的动态伸缩和灵活调度。百度智能云针对以上关键技术也实现了如下能力：
**GPU容器虚拟化**：2.0版本提供了用户态和内核态两种实现，用户态能够实现进程融合、显存交换、编解码实例等，性能更好；内核态隔离性强，可以实现算力隔离以及显存隔离，用户可以根据自己的需求灵活选择。
用户态方案：通过拦截DriverAPI进行资源隔离或限制操作，实现显存隔、算力隔离基础隔离功能及显存超发、高优抢占等高级功能。
内核态方案：内核态方案主要由拦截接口跟拦截驱动两部分组成。
下图中分别使用了单内核态GPU容器与单GPU容器直通跑任务测试（测试环境与模型：resnet50，batchsize=32，在v-32GB），可以看出内核态GPU容器几乎没有性能损失。
分别使用用户态GPU容器与内核态GPU容器跑任务测试（测试环境与模型：resnet50，batchsize=32，在v-32GB），从下图中的数据结果（单位：平均吞吐(Img/sec)）可以看到用户态方案性能比内核性能高8%-10%；而内核方案隔离性更强，几乎没有性能损失。
调度策略：支持共享混部，拓扑感知以及亲和调度。
资源管理：池化架构，资源被统一动态管理，避免资源浪费，实时调度减少资源碎片。
国产化适配：支持昆仑芯等国产芯的虚拟化和调度。
实践中，上述能力给业务带来了真金白银的实际收益。
比如，百度商业广告模型迭代经过多年的发展，广泛使用GPU等异构硬件进行预估和训练加速，以支持更加复杂的点击率、转化率、相关性等模型的创新和发展，直接驱动大商业的收入增长和用户体验改善，收益显著。
这带来了GPU需求的不断增长。但是存量GPU资源使用率低是一直存在的问题，导致了资源的浪费。当时采用粗暴单实例独占GPU卡的使用方式，加上流量呈高低峰态、模型复杂度不一、业务模块使用异构计算资源的限制等问题，导致了整体GPU资源利益率也仅13%。
面对这种情况我们上线了基于GPU容器虚拟化的在离线业务混部方案来提升GPU的整体资源利用率，优化后的商业在线业务GPU共享部署的占比90%+，整体GPU利用率高达50%左右，在线业务LatencyP97性能保持不变。
2.3如何提升训练、推理任务的效率？
为了更好地加速训练和推理任务，在训练场景下如何实现分布式训练的加速以及数据的加速？AI镜像会有复杂的CUDA依赖，甚至会有一些驱动和镜像本身比较大，严重影响启动的速度，如何针对性进行优化？
云原生AI2.0推出了AI加速套件AIAccelerateKit（简称AIAK），该套件基于百度智能云IaaS资源推出的AI加速能力，用来加速Pytorch、TensorFlow等深度学习框架的AI应用，能极大提升分布式训练和推理的性能。
分布式训练加速：AIAK-Training是基于Horovod深度定制优化的分布式训练框架（Horovod是TensorFlow、Pytorch等的分布式深度学习训练框架），在保留Horovod已有功能特性的基础上，增加了新的通信优化特性，完全兼容Horovod原有API，经典模型的训练效率提升50%以上。
推理加速：AIAK-Inference通过图优化、算子融合和自研高性能算子库来提升推理效率，ResNet、Bert等经典模型时延降低40%~63%。
I/O加速：通过并行文件系统和分布式缓存技术，与对象存储数据双向流动，实现数据集的管理和读写加速。并行文件存储PFS提供完全托管、简单可扩展的并行文件存储服务，针对高性能计算场景提供亚毫秒级的访问能力、高IOPS及高吞吐的数据读写请求能力；分布式缓存加速RapidFS是由百度智能云推出的高可靠、高可用、弹性的数据加速服务，以对象存储作为数据湖存储底座，为计算应用提供统一的数据入口、命名空间及访问协议，加速海量数据分析、机器学习、AI训练等业务访问存储的性能，方便用户在不同的存储系统管理和流转数据。
在4v-32g机型ImageNet1K训练中，PFS+BOS和RapidFS+BOS效果和本地SSD持平，比直接基于对象存储BOS训练提升5倍以上。
镜像加速：通过容器镜像按需加载技术，缩短镜像下载时间，实现容器冷启动加速。百度智能云容器镜像服务CCR提供的镜像加速功能，可在用户推送镜像时自动生成符合OCI镜像规范的加速格式的镜像。加速版本的镜像为镜像层中的每个文件和数据块建立索引，配合镜像仓库的HTTPRangeRequest的特性，使单机侧支持按需下载部分镜像层的文件。CCE提供的镜像加速组件可一键为K8s集群开启/关闭镜像加速能力，并在容器调度前自动为容器”换装“加速镜像。
在基于内容生成视频的业务场景中，镜像按需加载将容器冷启动速度提升6-20倍。
2.4如何加速AI作业开发，降低人力成本？
AI任务可视化：针对工作流做可视化的封装，内置PytorchOperator、TensorflowOperator、PaddleOperator等主流的深度学习框架支持分布式作业以云原生的方式提交，用户只要关心自己的镜像是哪一个，数据集是哪一个，点选填的方式就可以提交一个分布式训练的作业。用户也可以通过前端渲染的界面，可查看运行的历史，以及每个DAG的结构展示。同时，用户通过表单的方式更改DAG节点的输入、输出就可以提交一个新的工作流，操作简单，降低学习门槛。
工作流编排：实际的AI训练过程包含数据处理、模型训练、模型评估、模型部署和发布等一系列过程，每个AI算法工作者针对每个步骤都会用自己的方式去临时管理，这样会导致代码和模型管理混乱，难以追踪和复现结果，也无法进行高效分享和代码复用。为了解决这些问题，集成了KubeFlow和PaddleFlow来做AI作业编排，其中，PaddleFlow定位为AI训练的最小资源内核，提供以ML/DL作业的编排为核心的工作流调度等能力，模板化作业的数据处理、训练以及部署过程，并提供Cache、Artifact管理能力使得实验过程可复用可重现。同时，对用户屏蔽多样的计算和存储类型，透明化资源管理与调度细节。具体包括：
强大的AI编排能力，让实验更轻松。
支持通过YAML静态定义以及PythonDSL动态定义以及界面定义，用户接口简单，易于上手。
抽象节点的输入Parameters和输出Artifacts以及运行环境Env，并以文件的方式做快照，方便追踪训练过程，为实验过程可复现和AI编排可视化打下基础。
内置丰富的PaddlePaddle的套件，如PaddleDetection、PaddleNLP、PaddleOCR等，可以满足许多产业实践的AI训练需求。
DAG调度功能丰富，满足AI训练的调度需求。
支持复杂的定义，如循环、递归、条件分支、节点屏蔽、定时和周期调度等，以满足大部分AI场景的调度需求。
通用的架构设计，PaddleFlow工作流亦可支持运行在云原生DAG调度Argo、Airflow等其他主流DAG调度上，满足更多企业内部定制化需求。
针对DAG运行全方面优化，提升DAG执行效率。
通过节点产出数据统一管理，自动跳过未发生变化的节点，缩短DAG运行时间。
通过感知节点产出临时数据位置，减少中间数据读写的频率和远程访问频率。
通过AI资源调度的异构能力，检测节点的运行环境（CPU、GPU等）按需调度不同节点，降低算力占用成本。
03总结
作为国内人工智能的「头雁」，百度正通过自身的经验和技术输出来不断降低AI技术开发和应用的门槛。
目前，云原生AI2.0已经融合进百度百舸·AI异构计算平台，大家可以在百度智能云