AI到底适不适合开源？

到 2022 年，人工智能已经发展几十年，如今我们再谈论人工智能已不再局限于理论。工业界需要应用人工智能去解决问题，学术界也需要得到相关模型在大规模应用场景下的反馈。然而随着技术的演进，我们发现，基于开源算法的人工智能项目陷入了“落地难”的困境，“从 98% 到 99.9% 精度”的这个过程尤其困难，所以业内就有了“人工智能或许不适合开源”的声音出现。

于是，本期“InfoQ 极客有约”与“OpenI 启智社区”联合推出的系列直播栏目便邀请到了联通研究院的教授级高级工程师、启智社区开源项目“CubeAI  智立方”的负责人霍龙社博士，听他给我们分析一下当下人工智能开源项目的现状与未来，共同探讨下“人工智能到底适不适合开源”，并一起了解下，为推动 5G 与 AI 融合创新，中国联通在 2019 年发布 CubeAI 智立方平台后的技术演进与思考。

以下为直播内容整理：

InfoQ：AI 到底适不适合开源？您觉得为何会有“开源不适合 AI”的声音出现？您如何评价当下 AI 技术的“开源”？

霍博士：从普通开发者的角度来看，开源本质上是一种促进技术进步、促进科技创新的手段。所谓站在巨人的肩膀上，开源使得普通的软件开发者一上来就能够有一个较高的起点，而不像我们在几十年前开发软件一样，每一个项目都得从零开始，从最底层开始，一行行的来积攒代码。现在不一样了，在开始一个项目之前，首先上网找找有没有合适的开源代码来打底子，搭建基础的代码框架，基础的架子搭起来之后，只需要在上面专心实现自己特有的功能模块就可以了。即使找不到非常合适的基础代码，类似的东西也可以拿过来作为参考，启发自己的开发思路。从这个角度来说，开源确实是一个好东西，不论什么技术都应该开源，没有什么适合不适合的。

从公司的角度来说，开源又是一把双刃剑。开源的历史发展其实也说明了这个问题。最开始商业公司开发的软件基本都是闭源的，不仅闭源，而且可能还有着一些非常严格的防止外泄的管理制度。也就是最近这些年来，开源才逐渐形成了一种潮流。因为对于公司来说，考量是否适合开源的一个重要因素可能主要还是利益，对公司的营销收益以及长期发展能有多大的正面或负面的影响。之前之所以对代码严格管理，就是怕泄露之后被别人抄袭，影响自己的生意。现在又把部分代码拿出来开源，部分原因也是为了能够营造自己的技术生态环境，把大量开发者收拢到自己的开发生态圈之内，同样可以达到挤压竞争对手的目的。而在当今世界开源已被广大开发者所期待和习惯的形势下，开源开放必将成为不可逆转的世界潮流。因为对于某项技术来说，如果你不开源，但是周围有很多别的竞争对手选择开源，广大开发者和使用者必然会逐渐选择加入到别的开源创新的队伍中去，从而慢慢挤压掉你的市场份额。当然，除非你有非常独特的技术优势，但是这种优势随着时间的流逝可能也会慢慢丧失掉的。至于说到 AI 技术，从开源的角度我认为跟别的技术也没有什么特别的区别，所以它的发展趋势也必然是应该全面走向开源的。

至于说有“开源不适合 AI”的声音出现，其实有点以偏概全。AI 的开源应该是包含了很多层面上的，例如基础设施、软件环境、框架、算法、应用等等，而不仅仅是一个模型的训练。就算是训练一个模型，模型的规模也是有大有小的，并不见得都是超大模型。就算是超大模型，你开源出来我训练不了，我看看总还是可以吧？说不定从中能吸取点什么思路，给你提点什么好的意见？而且既然别人都用不了你的模型，你开源出来你又吃不了什么亏，那又为什么不可以开源呢？

当然了，AI 的模型训练确实也还是有跟别的技术不太一样的东西的，那就是需要大规模甚至超大规模的数据。对于学术界来说，往往使用一些网上公开的数据集就可以了。而对于工业界来说，数据的保密性可能就存在一定的问题。数据的无法开源也会影响到开源模型的有效性和实用性，这方面是值得注意和研究的。总之，个人认为并不存在什么适合不适合开源的问题，而主要是愿意不愿意开源，以及开源到什么程度的问题。

InfoQ：依赖开源算法，AI 技术是否可以完成深度落地？

霍博士：这个问题不好回答，但如果能改成“借助开源算法，是否可以促进 AI 技术高效落地”，那这个答案就是比较肯定的了。

开源只是一个能够促进协作创新、提高开发效率的手段，而并不是一个无所不能、能够包打天下的东西。不同的群体对于开源的贡献和索取的期望值不尽一致，导致开源内容的品种和质量也是五花八门、良莠不齐的。比如学术界开源的项目可能更倾向于一些理论、算法的验证，距离实际生产应用会较远一些。工业界对于开源的态度，出于利益竞争的考虑，可能也会有一些掐头去尾，不太可能把自己的老底完全兜出来的；有些企业拿出来用于开源的代码和自己在现网生产系统中使用的代码可能是两套完全不同的东西，从算法和系统运行的性能、安全性、可靠性、稳定性、适用环境等方面都会打一定的折扣。所以，要完成 AI 技术的深度落地，可能并不能完全依赖开源算法。

但是，不完全依赖开源并不是说就完全不依赖开源，AI 技术的落地还是要而且必须要借助于开源算法的。借助开源的效果，最主要的就是提高开发和生产效率。对于一个面向实际生产运营的项目，拿一个开源代码过来不加修改直接运行几乎 99% 是不太可能成功的，但是利用现有的开源代码进行二次开发，通过采取扩展功能、改善性能、增强安全性可靠性等措施，或者仅把开源代码当做参考原型，借助其工作原理来重新进行代码设计和开发，与完全不参考开源代码自己一切从头开发比起来，其开发效率都必然会大大提高，达到事半功倍的效果。

InfoQ：2019 年，中国联通为推动 5G 与 AI 融合创新，发布了 CubeAI 智立方平台，当初为什么选择开源？

霍博士：关于 CubeAI 智立方这个平台的开发和开源，其实也并不是一开始就规划好要做开源，而是有一个逐渐演进和发展的过程的。CubeAI 智立方是中国联通研究院自主研发的集 AI 模型自动化服务封装、发布、共享、部署和能力开放等功能于一体的开源 AI 算能服务平台，其核心作用在于打通 AI 模型开发至实际生产应用之间的壁垒，加速 AI 创新和应用进程，促进 AI 应用从设计、开发直到部署、运营整个生命周期的自动化快速迭代和演进。

CubeAI 其实主要实现了以下三个功能：AI 模型的自动化服务封装、自动化模型发布和自动化模型部署。所谓自动化服务封装，就是将原先只能在本地调用的模型推理程序通过简单的代码模板套用自动封装成为可通过网络远程访问的 API 服务。所谓自动化模型发布，就是将经服务化封装的模型推理程序自动打包成微服务容器，一键发布至 CubeAI 提供的模型共享托管平台，供用户进行浏览、评价、交易和部署。所谓自动化模型部署，就是将 CubeAI 模型共享平台中的模型推理微服务一键部署至 k8s 等云原生算力平台，部署之后直接向用户提供基于 API 接口的 AI 能力开放服务。

最开始我们想要做这个平台的时候，主要是基于内部项目的一些需要。刚开始并没有想要完全自己做，而是打听到有一个叫做 Acumos 的开源项目，能够提供类似的一些功能。Acumos 是 Linux foundation 下面的一个深度学习基金会立项的一个开源项目，但它的开发者主要来源于 AT&T 公司，跟我们联通一样都属于电信运营商。刚开始我们是想直接利用 Acumos 的代码，希望能够直接把它跑起来，最多是在它的基础上根据我们的需求改吧改吧，来满足我们的应用。但在实际使用过程中，我们发现这样的做法并不太行得通。首先下载下来的代码在我们的机器上就跑不起来，好容易想尽各种办法把它勉强跑起来了，好多功能调用的时候又出错，几乎无法使用。其次发现他们的代码过于庞杂，而且不是我们想要的微服务架构，二次开发和代码维护的难度都非常大。

所以我们就决定不直接基于 Acumos 代码进行二次开发，而是重起炉灶搭建我们自己的代码框架，然后参考和部分借用 Acumos 的代码来进行开发。也就是说，我们不直接使用 Acumos 已经编好的筐，而是新编一个我们自己的筐，然后把 Acumos 筐中觉得好用的蛋拿到我们的筐中来，实现我们需要的功能。

基于这个思路，我们很快就完成了 CubeAI 平台第一个版本的开发，并在 2019 年的世界移动通信大会进行了发布。考虑到它并不是一个单一的产品或平台，而是需要与产业界各方进行交流合作，共同来构建产业合作生态环境，于是我们在发布这个版本的同时就决定将其同步进行开源。当然在决定开源的时候，除了面向产业链生态合作方面的因素之外，我们也考虑了其他的一些理由。首先我们的这个 CubeAI 最初是在参考开源软件 Acumos 的基础上进行开发的，虽然后来我们实际上已经完全脱离了 Acumos 的体系，但最初毕竟还是受到了它的影响，既然来源于开源，也就应该回馈于开源，这是其中一个考虑因素。另外就是我们觉得我们刚开始参考的这个 Acumos 开源软件做的并不太好，而且不太适用于我们中国人使用，而我们自主开发的这个 CubeAI 从好几个方面都比外国人做的东西更好用，我们就希望能把它开源出去来向外界进行展示，也算是一种宣传吧。

InfoQ：从目前人工智能行业发展来看，AI 模型开发与实际生产应用之间有哪些壁垒？作为开源 AI 算能服务平台，CubeAI 智立方是如何打通这些壁垒的？

霍博士：大家都知道 AI 的使用主要包括模型训练和模型推理两大步骤。模型开发者首先使用大量数据训练出一个模型来，然后模型使用者调用这个预训练好的模型，输入自己的数据来执行模型推理，计算出自己的预测结果来。现在 AI 方面大量的工作主要集中在模型训练方面，而对于如何将训练后的模型交付给最终用户进行使用关注得并不多。究其原因，可能主要是因为模型训练过程本身就包含了模型推理，大多数模型开发者并没有觉得调用和执行模型推理是一件什么难事。而实际上，在真实的行业应用中，广大的模型使用者可能对 AI 模型训练和推理的具体技术细节并不是太了解，让他们直接使用与模型开发者一样的编程环境来进行模型推理实在就有点勉为其难了。

举个例子，现在学校里的研究生发表 AI 相关的论文，一般都还同时把自己的源码上传到类似 Github 这样的开源托管平台上；审稿人在阅读论文的时候，如果想亲自核实一下论文算法的运行效果，就需要先把作者开源的代码下载到本地，然后根据 README 指示在自己的电脑上从头配置一套运行环境，然后再在这个环境中运行模型推理代码。由于每个作者每个模型的运行环境千差万别，这个从头配置环境并运行代码的过程有时是十分困难的，没有非常熟练的 AI 模型开发经验的人员一般很难轻松搞定。当然，在这个例子中的审稿人通常是行业专家，完成这些工作也许不是什么大的问题，但也会浪费很多时间。而对于像我这样的对于什么是神经网络、什么是张量等等都搞不懂的普通人来说，如果也想去试试，就不是那么简单的了。而在其他的行业应用中，真正的用户其实大部分就是类似我们这样的普通人，而不个个是 AI 和编程专家。

为了解决这个问题，一个办法就是把 AI 模型服务化，把它部署到云端，然后用户不需要在自己的本地电脑上安装配置运行环境，而是直接通过调用云端提供的服务化 API 接口来获取模型推理结果就可以了。这种方式现在已经大量存在，好多商业化的网站和生产应用系统也都采用的是这种模式。但是，这种模式虽然方便了使用者，但却给普通的模型开发者带来了麻烦。因为在这种模式下，要想把一个模型推理程序变成云端服务器上的服务化 API 接口，是需要由网站运营者针对每一个模型程序专门进行服务化定制开发和部署的，不仅流程繁琐、工作量大，而且对于普通的模型开发者也是可望而不可及的，只有那些实力雄厚、拥有自己服务器和网站的企业才可能做到。以上面提到的论文审稿为例，一个研究生可以很轻松把自己的模型代码放到 github 等代码托管平台上，但是却很难有渠道将其服务化部署到一个大家都可以访问的网站上去。

我们做的这个 CubeAI 智立方，刚好就可以解决这个问题，打破模型开发者到模型使用者之间的这个障碍，使得模型开发者不需要了解云端网站开发和服务化封装的基本原理和编程知识，只需要简单套用一下 CubeAI 提供的模板程序，就可以将自己的模型程序一键发布和部署至云端网站，以服务化 API 的方式对所有用户提供模型推理服务；而模型使用者也不需要了解和掌握任何 AI 编程和运行环境配置等知识，只需要使用经 CubeAI 封装的非常简单的方式调用网络 API 接口就可以了。

InfoQ：CubeAI 智立方由 AI 建模、AI 模型共享（AI 商城）和 AI 能力开放三大平台组成。分别解决了 AI 模型使用者的哪些问题？

霍博士：在最初的规划中，CubeAI 是打算由 AI 模型训练、AI 模型共享和 AI 能力开放这 3 个平台组成。在实际做的过程中，我们实际上没有自己去做模型训练这一块。当然这样说也不太准确，我们曾经自己也开发过一个模型训练平台的，但做出来后发现做的并不太好，跟目前市场上已经有的一些模型训练平台相比，采用的技术和实现的功能都大同小异，但好用性和可用性等方面都不是太好，所以后来就决定放弃这一块，不再自己做，而是直接使用现成的训练平台。不论用哪一家训练平台训练出来的模型，都可以与我们的模型共享平台进行对接。例如，百度的 AI-Studio 就是一个很好的 AI 训练平台，从界面友好性等方面都比我们当初自己做的那个要好用得多。启智社区的 AI 协作平台功能就更加强大了。

AI 模型共享平台可以看作是一个经服务化封装的 AI 模型推理程序运行体的托管仓库。这个经服务化封装的 AI 模型推理程序运行体的具体表现形式目前就是一个 Docker 容器。把每一个模型推理程序封装成一个 Docker 容器，这样就实现了云原生，可以随时随地将其部署至任何可以运行 Docker 的环境中运行并提供模型推理服务。打个比方，跟 GitHub 等传统的静态代码托管平台相比，我们可以把 CubeAI 的模型共享平台看作是一个可以运行的“活体程序”的托管平台。通过平台提供的界面，用户可以浏览、搜索自己感兴趣的模型，也可以像市场中的商品一样对模型进行评价、收藏、交易、分享，对于已购买的模型，可以将它部署至任意云平台或者本地电脑。目前，因为还没有商业化运行，我们暂时还没有实现模型交易这个功能，所有模型都还是免费的，所以我们暂时还把这个平台叫做 AI 模型共享平台，而没有叫做 AI 商城。

在 AI 模型训练平台到 AI 模型共享平台之间，实际上还是有一个 AI 模型服务化的过程的。在这里我们主要是开发了一个叫做 ServiceBoot 的 AI 模型服务化引擎，还有一个模型服务化程序模板。模型开发者只需要套用这个程序模板对他开发好的模型推理程序进行非常简单的代码封装，就可以达到模型服务化的效果，利用 ServiceBoot 引擎以网络 API 接口的形式对外提供模型推理服务。封装好的模型服务器程序，再经过一键发布操作，就可以将其发布至 AI 模型共享平台。在模型发布过程中，AI 模型共享平台会自动将经服务化封装的 AI 模型推理程序打包成微服务形式 Docker 容器镜像，模型运行所需要的 Python 环境、AI 框架等等都会被自动选择并打包进去，而不需要用户的手动干预。

最后再来解释一下这个 AI 能力开放平台。本质上来说，用户可以将从 AI 模型共享平台购买的 AI 模型部署至任何可以运行 Docker 容器的环境中进行运行，例如各类云平台、本地电脑等等。但是考虑到很多用户自己并没有合适可用的云平台，所以我们就开发了这样一个 AI 能力开放平台，用于进行模型的部署和运行管理。我们目前采用 k8s 来搭建 AI 能力开放平台。模型部署至 k8s 之后，通过 AI 能力开放平台提供的用户界面，用户可以查看模型的运行状态；还可以对模型运行的生命周期状态进行管理，例如执行实例扩缩容等操作；还可以使用模型提供的 API 接口进行模型推理测试；甚至还可以利用模型开发的 Web 界面进行可视化模型演示。

InfoQ：经历 3 年的发展，CubeAI 智立方在技术方面实现了怎样的突破？在 5G 与 AI 融合方面有怎样的探索？目前在攻克的技术难题是什么？

霍博士：CubeAI 从 2019 年开始做，到现已经断断续续开发了不短的时间，也迭代了不少的版本。这个过程中还是做了一些比较有价值的事：

第一个就是 AI 模型服务化引擎的开发。模型服务化其实可以算作是 CubeAI 中最核心最关键的一个东西，与普通的 Web 框架相比，关键是要能够实现对普通的模型推理程序进行自动化服务封装，还有就是要实现模型加载和模型推理两个过程的分离，以便提升模型推理的性能。刚开始我们直接使用 Acumos 提供的一个叫做 acumos-model-runner 的服务化引擎，但在使用过程中发现它这个东西仅仅对 TensorFlow 等少数 AI 框架有效，连对 PyTorch 这样主流的框架都不支持。于是我们就经过分析之后对 acumos-model-runner 进行了改造，基本能够支持对所有 AI 框架开发的模型进行服务化封装。再后来我们进一步研究，发现 acumos-model-runner 的实现原理和使用方式都非常别扭，有把简单问题复杂化的倾向，导致开发效率、运行性能和用户体验等方面都不是很友好。于是我们就又彻底抛弃 acumos-model-runner，完全重新设计和开发了一个全新的服务化引擎，不论从技术原理、开发效率、运行性能还是用户友好性等方面，都取得了超越 acumos-model-runner 的非常好的效果。我们最开始给这个服务化引擎起了个名字叫作 iBoot。

第二个是基于微服务框架的平台开发和重构。前面说过，CubeAI 最初是参考开源项目 Acumos 开发的。但是由于我们对 Acumos 的代码结构不是很满意，所以一开始我们选择了采用基于 SpringCloud 的开源微服务框架来搭建代码主体框架，仅仅是参考 Acumos 的部分代码来实现平台功能，这样就形成了 CubeAI 的最初版本。在使用 SpringCloud 微服务框架的开发过程中，我们也遇到了一些问题，促使我们决定试着开发一个自己的微服务框架。首先是这个框架非常庞大，调用关系非常复杂，虽然号称是开源的，但有些组件深入 debug 之后发现还是找不到源码，从而导致对有些功能的实现知其然不知其所以然，有些不符合自己使用习惯的东西想改又不知道该怎么改，有些搞不清的东西也不知道到底敢不敢用。其次是这个框架只支持 java 编写的微服务，不支持其他语言开发微服务的接入，不利于微服务的兼容扩展。再次是 Java 编程的学习和调试难度较高，而我们的开发力量和水平有限，导致开发效率不太高。考虑到现在绝大多数 AI 模型都是基于 Python 进行开发的，大多数 AI 开发者对它都比较熟悉，而且 Python 也相对比较容易学习，能够大大提高开发效率，所以我们就试着使用 Python 对整个 CubeAI 平台代码进行了重写，包括其中的微服务框架部分。

第三个是微服务引擎和微服务框架的抽象和重构。最开始用 Python 重写的 CubeAI 平台，其代码结构还是比较繁琐的，特别是涉及到网络并发处理等操作，其中的异步编程机制不仅编程麻烦，而且一般人很难理解和学习。正在为这个问题犯愁的时候，突然想起来们的 iBoot 既然可以用来对 AI 模型程序进行服务化封装，那是不是也可以用来开发普通的微服务程序呢？于是我们就参考 iBoot 又开发了一套通用的微服务引擎，起名叫作 ServiceBoot。ServiceBoot 对微服务访问的各类异步并发操作以及 API 接口映射、参数处理机制等等进行了统一的抽象和封装，提供了一套简单易懂的函数式网络编程接口，能够大大简化编程复杂度，提高微服务开发的效率。在这个基础上，我们又把整个平台中提供微服务框架的基础组件抽象出来，使用 ServiceBoot 重新编写，这样就构成了一套独立的通用微服务框架基础组件，我们给它起了个名字叫作 CubePy。CubePy 是一套通用的微服务框架，包括微服务注册和发现、API 网关、用户认证授权、应用管理、文件和镜像管理、前端微服务模板等基础组件，它不仅可以用于开发 CubeAI，而且可以用于开发其他任意的云原生微服务类应用。CubePy 的基础组件虽然是使用 Python 和 ServiceBoot 写的，但是它并不限于仅支持 Python 微服务接入，用其他语言写的微服务，只要符合 CubePy 的相关接口要求，也都是可以接入到 CubePy 框架来进行管理的。

因为历史的原因，之前 iBoot 和 ServiceBoot 一直是按照两个产品来进行开发和维护的，一个专门用于 AI 模型的开发和服务化封装，一个专门用于 CubePy 微服务的开发。前一段时间我们刚刚对这两个东西进行了融化整合，把它们整合成了一个产品，名字定为 ServiceBoot。这样对内对外都比较方便。对外便于用户理解和使用，对内便于开发团队的开发和维护。也就是说，以后不论是开发普通的微服务应用，还是开发 AI 模型推理服务，都使用这个统一的 ServiceBoot 就行了。而且，ServiceBoot 不仅仅可以用来对 AI 模型进行服务化封装的，实际上它可以用来对任意的 Python 程序进行服务化封装，在开发和部署效率、服务性能和用户友好性等方面都明显好于其他的 Python Web 框架。

InfoQ：CubeAI 智立方进入 OpenI 项目培育管道后，有怎样的体验？获得了哪些助力？您如何评价 OpenI？

霍博士：CubeAI 大概是在去年 7 月份，经过启智社区严格的评审流程，正式被社区采纳，作为重点开源项目贡献至启智社区并进入社区项目孵化管道的。进入社区这一年多来，在社区的支撑和培育之下，我们的项目得到了良好的发展，取得了显著的进步，总体感觉是非常不错的。

我们以单位名义、以会员方式正式加入了社区，并且在社区正式立项了开源项目，所以就可以光明正大地来搞开源，不再受制于一些条条框框的约束和限制了。

其次社区提供了 AiForge 这样一个非常好的代码托管协作开发平台。在加入启智社区之后，经过一段时间的试用，我们就喜欢上了这个平台，并且把 CubeAI 项目的所有代码开发活动都切换到了这个平台之上。主要原因就是因为它的好用，一个是速度快，浏览、提交、合并代码都非常流畅，几乎没有什么卡顿；二是用户界面友好、操作简单方便，没有太多啰嗦和看不懂的地方；再就是它本身也是一个持续迭代开发的开源项目，你可以在线看到它的持续更新，而且每次都是向着更好的用户体验。不仅如此，在使用过程中如果遇到什么问题，都可以及时提出并得到反馈，好的修改建议会很快出现在下一个发布的版本之中。这些都是以前用其他代码托管平台和工具时所无法体验到的。

还有就是在加入社区之后，社区给我们提供了很多展示和宣传项目的机会和平台，例如 EngineClub 论坛讲座、启智校园行、苏州智博会、启智开发者大会、中国开源大会等等。通过参与这些活动，一方面宣传和扩大了 CubeAI 的影响，另一方面也学到了