分享嘉宾：王元 星云数字 公共技术中心总监

文章编辑：Hoh

出品平台：DataFunTalk

导读： 人工智能，在2021年已经不是一个新词，在金融科技、大数据分析等多个领域已有很多实际落地的应用。作为承载人工智能算法的平台技术，受到的重视日渐增多。

人工智能平台技术有很多种称谓：机器学习平台、深度学习平台、AI操作系统、算法平台、分析平台、计算平台等等。不同的称谓，反映的是各家厂商对此技术的不同的理解和差异化的设计侧重点。

由于篇幅有限，我们今天就来探讨其中的3个设计维度，展望新一代人工智能平台的技术思路与架构。

01 编程语言

编程语言，本质是一种人机交互的终极方式。一个编程语言普及和流行的背后，往往标志着一种新的软件生产方式，随之带来的是产业的生产规模和效率的宏观趋势巨变。

回顾计算机行业发展史，可以清晰的看到编程语言变化带来的威力：

• 从汇编语言，到C语言的普及，造就了现代化的操作系统（Windows、Mac、Linux）；
• 从C语言，到Java的普及，成就了各式各样的互联网和移动服务。

那么，近10年，编程语言中的超级明星是谁呢？我们认为是Python语言。Python经过最近10年的飞速发展和普及，如今可以已可以与C语言、Java平起平坐，成为了世界3大编程语言之一，看看以下最新的TIOBE排行就可以很明显的感知到这一变化：

在人工智能领域，Python更是一枝独秀，已成为事实上的行业标准。这种变化，深刻影响着人工智能算法平台的设计。主要有2点：

1. 代码运行环境

Python之所以在人工智能领域流行，很大一个原因是多样的生态，即多种优秀的第三方库。人工智能本身，又是一个高速发展的领域，不同的模型和算法被不同的研究机构研发出来，这些算法和模型，源代码中使用着不同的开源库包，致使产业界在商业化这些研究成果时，不同项目间很难统一到一套标准的软件环境。

同时，很多组件，为了解决python这类解释性语言本身的执行效率问题，往往会与C语言混合编程，这种托管代码（managed code）与非托管代码（unmanaged code）的混合，使软件环境管理的复杂性大幅提升。

因此，人工智能算法平台第一个要解决的问题，就是需要支持项目级的软件环境隔离和生命周期管理，仅仅只支持软件环境全局配置的计算平台，将很难支撑一个企业多个场景或者业务线的人工智能算法应用。

从目前技术发展趋势来看，运行环境问题的解决方案主要涉及3个层面，分别人机交互层面、托管型代码层面和非托管代码层面，如下图所示。

具体来说，纯托管代码的应用，可以使用诸如conda-pack这样的python库包管理及虚拟环境，动态下载和自动分发相应的库包到各个节点，以实现运行环境的动态配置。

此方法的局限，在于其底层的二进制程序运行环境和工具链是共享的，对于这类涉及到非托管代码的依赖，需要更加完整的环境隔离技术，最有潜力的就是K8S容器技术。通过容器化，非托管代码涉及的不同依赖可以使用不同的镜像解决，同时，当应用程序被销毁时，容器将被回收，对物理节点上的环境不会造成污染。

可以预见，面向未来的算法平台将基于K8S容器技术作为资源管理器，对应用程序进行全生命周期管理。在此基础上，平台同时支持上层纯托管代码的库包管理和自动分发，实现轻量级的环境隔离。

2. 代码运行效率

除了软件运行环境，代码运行开销同样深受编程语言的影响。

一个应用程序，它所依赖的平台本质上是另一个程序，如果应用和平台使用的是同一种编程语言编写而成，那么这2个程序的交互成本是最低的。计算机科学把这种现象称为“原生语言（Native Language）的效率优势”。

然而，在人工智能领域，我们恰恰在丧失这种优势：

• 从人工智能应用角度，业务决策由人工智能算法和模型计算得出，Python是第一语言；
• 从人工智能算法平台角度，目前平台类研发使用的编程语言，大多数却是Java类语言；
• 底层算力是异构资源，即我们处在CPU/GPU/FGPA/ASIC多种异构硬件作为计算资源的时代，面向硬件的原生语言是C/C++。

以上这种业务第一语言与IT第一语言不统一的现实，对人工智能算法平台的架构设计本身提出了更高的要求，那就是如何以最低的开销来承载业务应用，使其Python编写的模型成为“一等公民”，达到或逼近平台原生语言的性能。这一点，恰恰是现有很多人工智能平台所欠缺的。

目前常用做法是使用共享存储的方式，即一个进程将数据写入诸如HDFS或者OSS存储中，另一个进程再读出。这样做的最大的问题是通信效率低下。

跨语言本质上跨进程间通信（IPC），也就是同一个数据在不同语言（进程）中的使用，因此，更高效的做法是实现内存层面的数据交换。为了减少进程间数据交换时产生的序列化和反序列化操作，尤其是同一物理节点上的不同进程，采用共享内存（shared memory）可大幅减少同一数据的拷贝，这需要一个公认的内存格式标准。笔者注意到，分布式内存列存储Apache Arrow格式标准从2020年发布v1.0版本后，发展迅速，如今已经到v6.0。不同的软件栈，不同的语言，不同的硬件设备，对此标准的支持逐渐成熟，这将件显著提升人工智能应用程序的执行效率。

代码运行效率提升，还有一个发展是算力的迁移，逐渐从CPU到计算性能更加强大的GPU及特殊硬件设备如ASIC或者FPGA。这意味着，GPU这类设备的使用范围开始从深度学习，发展到机器学习和数据处理ETL阶段。如何充分利用新的硬件计算能力提升执行速度，将是平台系统需要优化的。值得注意的是，由于底层硬件的原生驱动和算子库是基于C/C++语言的，很多高性能计算领域的生态也都是基于CUDA、MPI编程范式，因此，底层采用C/C++实现的计算引擎，配以CPython绑定的上层Python编程API，将比目前基于Java类语言的计算引擎，通过py4j实现Python编程API的技术架构更具优势和扩展性。

02 调度器

模型研发离不开数据，模型上线后的监控和效果评估也同样需要数据。因此，人工智能算法平台，与大数据平台的互联互通同样是一个设计重点。

回顾过去10年，模型与数据的互联互通，是有欠缺的。实际上，在很多情况下，数据与模型是割裂开的，这体现在2个系统使用各自独立的物理集群，有各自独立的研发和上线流程，一些企业，组织架构和团队管理上也是分开的，这不可避免的造成了数据交互的成本。

前文说到，底层资源调度平台统一使用K8S集群，可以解决资源调度孤岛化的情况。但是，从进程级的计算调度角度出发，计算引擎如果不能将模型建模所需的计算进程，尽可能的分配到大数据处理进程所在的同一节点时，序列化和反序列化无法避免，依然造成了不必要的数据交换。对此类问题，需要解决4个技术问题：

第一点，是计算引擎需要支持数据本地化调度机制。该技术的实现，可基于Arrow项目的Plasma Object Store机制，即通过记录数据的所有者信息，系统可以在分配计算资源时，查看数据依赖图（DAG图），从而在保证计算资源的情况下，将计算进程分配至数据处理进程所在的节点上。

第二点，是内存共享机制。这一点前文所述的Arrow项目，基本已得到解决。通过采用分布式Arrow架构的设计，可以为每一个节点创造一个内存缓存，使处在该节点上的进程间通信尽可能使用零拷贝（zero copy）。

第三点，是数据所有权转移机制。通常情况下，大数据处理，是模型建模的前置步骤，因此从资源占用角度，大数据处理进程所占用的资源，理论上可以在其处理完数据，将数据存入所在节点的共享内存后，就可以释放掉。但是从目前实现情况下，暂时还无法实现。这是因为Arrow定义的数据所有者，是该数据的原始创造者，如果创造者进程被销毁，数据即使在共享内存池中，也无获取。因此，需要数据所有权转移机制，来解决该约束。

第四点，计算调度需要同时支持有状态和无状态的任务。无状态的任务，已经有很多实践经验，有状态任务的调度、生命周期管理和资源使用情况，比无状态任务复杂，但是在深度学习领域更具有普遍性。

03 模型部署

人工智能应用的生产部署，至今仍在发展，究其原因，主要是现有的解决方案依然不够通用和高效。对模型部署的支持，是算法平台的一个必要功能之一。我们对此来重点剖析一下，引起人工智能应用的部署复杂性的重要3个方面：

1. 算法多样性

即使不算上学术界的前沿算法，产业界使用的算法和模型的种类也是异常丰富和多样的：机器学习模型族、深度学习模型族、混合集成模型、运筹和优化算法模型、强化学习模型、图网络模型等等，数不胜数。一个好的算法平台，不应该成为瓶颈，致使好的已成功研发出来的业务级算法，因为平台不支持而上不了生产。

对于这个问题，业界大家常用的解决方案就是将算法模型简单封装成微服务，最常用的就是以Rest API的形式与其余的系统组件进行交互。这样是否就可以了？要回答这个问题，我们再来分析一下模型部署的资源使用特性。

2. 资源使用特性

同样是HTTP微服务，传统的网页微服务与将算法模型简单封装的微服务在底层资源使用特性上相差巨大：

• 网页微服务：性能瓶颈通常在I/O，即网络、数据库交互的等待与阻塞情况，CPU计算负载很少。因此，通常一个微服务进程，服务1千-1万个请求是正常水平。
• 算法模型微服务：主要是数值计算。在计算期间，CPU负载近乎100%。因此，一个微服务进程只能服务10-100个请求。更糟糕的是，如果计算期间出现异常，整个微服务将停止响应。
• 网页微服务：对于每个请求，其处理逻辑是一样的，因此负载均衡十分简单；
• 算法微服务：对于每个请求，可能会需要访问不同的模型，而由于模型动辄上百兆、上G的内存大小，将这些模型同时载入到内存中又不可行，这使得负载均衡的复杂度明显上升。

由于上述差异，很明显简单将模型“嵌入”到微服务里并不是一个可持续的解决方案。在这个领域，行业领头羊如谷歌、亚马逊都提出了给自的方案，这些方案的共同点是将微服务的HTTP服务器与模型分离，并构建一个独立的计算集群用于模型计算，这种架构成为外部（External）微服务后端。但是，这又引起了另一个需要解决的问题：微服务架构的通用性。

3. 架构通用性

模型部署采用外部微服务后端是一个较好的解决方案，但是需要解决一个遗留问题，那就是通用性：如前文所述，算�