以下为直播内容整理：
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 框架。
霍博士：作为一个平台型的开源软件，CubeAI 要真正发挥作用主要还是在于运营，特别是面向公众互联网的运营，潜在用户目前来看主要应该是广大的 AI 个体开发者或中小型开发团队。目前互联网上应该还没有类似的平台。但是很遗憾 CubeAI 项目现在还只是处于开源孵化阶段，还没有得到实际的应用。所以对于它的发展规划，我们最希望的就是有人能够把它真正投入运营，真正的应用起来。大家都知道开源的东西跟实际真正运营的产品之间还是有一定差距的，目前的开源系统最多可以看做是一个原型产品。如果要实际投入运营的话，还是需要根据真实的运营需求对这个开源平台进行适当的功能扩展和优化开发的。
InfoQ：如今开源 AI 平台越来越多，AI 技术应用门槛不断降低，“人人都可以做 AI 开发”，您怎么看待这个技术应用趋势？
霍博士：从某种意义上来讲，我是同意这种说法的。之所以出现这种趋势，我觉得大致主要得益于以下几方面的因素。
第一，人工智能技术的发展，特别是这些年来基于神经网络的深度学习技术的突破和流行。与传统机器学习相比，深度学习的最大优势之一就是可以进行端到端的学习，而不需要人工进行特征提取，这就在模型算法研究和设计的层面降低了技术门槛。
第二，各类开源 AI 框架的出现和普及。深度学习中的神经网络层次多、网络结构复杂、参数数量庞大，这样就会导致模型训练和推理的程序代码结构复杂，普通开发者很难搞定。特别是神经网络模型训练中的反向传播算法，需要一层层的计算梯度，也就是针对各类函数求偏导数，不仅公式复杂，而且数量庞大，这就更不是一般人能够搞得明白的了，更不用说编程实现了。而 AI 框架的出现就解决了这个问题，它把各类虽然复杂但是可规律性重复使用的代码封装起来，并且自动实现了计算图构建、偏导计算等复杂操作，这样就使得模型开发者只需要使用若干比较有限的通用 API 接口就能够构建神经网络，执行模型训练和模型推理等操作，从而大大降低模型开发的难度和复杂度，在 AI 模型开发这个层面降低了技术门槛。
第三，各类增强型开源框架或平台的出现。它们首先开发一些通用模型，利用大量通用数据集训练出一些预训练模型出来，把它发布到网上。然后不同应用领域的模型开发者可以在这些预训练模型参数的基础上，使用自己拥有的部分领域数据集来进行增强和优化训练，得到更加适合于自己领域的模型参数。这样就进一步降低了应用型 AI 模型开发的技术门槛。
第四，各类开源 AI 集成或应用服务平台的出现。这些平台直接提供面向各类应用的训练好的模型，应用开发者只需要从中选择合适的模型，进行简单的参数配置或者编排组装之后就可以直接调用。这样就大大降低了各类需要用到 AI 技术的应用开发者的技术门槛，他们可以基本上不用学习和掌握 AI 的理论和编程知识，就可以进行应用开发了，从而真正实现“人人都可以做 AI 开发”。
总之，一个技术要想营造良好的应用生态环境就必须吸引更多的人来参与，要想吸引更多的人就必须降低技术门槛，而开源正是降低技术门槛的最有效的手段之一。
InfoQ：国内的公司关于 AI 的开源项目并不少，基本上大厂都开源了自己的 AI 框架，有的还不止一个，但是后续维护和推广做得好的并不多，产生这种现象的原因是什么？您又是如何看待国内厂商争相构建 AI 开源框架这件事的？
霍博士：确实，国内目前做 AI 开源项目的很多，特别是开源 AI 框架，好多公司还有一些大学等研究机构也都在做，但是在业界有比较大名气和影响力的，目前似乎只有 PaddlePaddle 和 MindSpore。出现这种情况的原因主要有以下几个：
首先，用户的使用习惯、学术生态和对国外主流的依赖心理的因素。普通的 AI 研究和开发者，最早接触和使用的是国外的 TensorFlow 和 PyTorch 等知名的主流框架，在国际上发论文、学术交流等也都普遍采用这些主流框架，这就使得一方面使用习惯了不太愿意去换新的工具，毕竟任何新的东西也都还是有一定的学习成本的；另一方面使用新的东西可能会失去与他人特别是国际上一些学术圈子交流的机会，因为一个新的东西要想混入圈子是会遭到当前圈子里主流的排斥的。至于像 PaddlePaddle 和 MindSpore 这两个现在之所以能够搞出点名气来，本身产品过硬是一方面，我觉得最主要的还是靠着公司的财大气粗硬挺出来的，而且主要还是在面向产业应用的领域，在学术界还是不太流行。
第二，做开源并不是一件轻松的事情，还是需要有相当大的人力物力财力来支持的。比如说要有雄厚的技术储备，要有强大、持续的创新开发人才队伍，要建设和运营社区，要有强大的算力和网络资源，要持续进行大规模布道、宣传、推广等等，所有这些都不是一般的财力不足的小公司能够长久持续应付得了的。这可能也是一些开源项目后续维护和推广做得不太好的一个原因吧。
第三，持续的创新能力。有些开源项目可能刚开始做得很好，但是后续时间长了如果不能持续推出新的东西，自然也就会逐渐失去人们的关注，自己也失去信心，无法再坚持做下去了。
当然，这里说的只是开源项目可能做不好的部分原因，并不表示我国的大多数 AI 开源项目就都做得不好。事实上我觉得我们国内有些名气不是太大的开源项目做的可能还是非常好的。所谓的专尖特精，有些公司或团队只是在 AI 相关的部分领域有自己独到的创新之处，由于方向相对比较窄，受众范围比较小，再加上宣传力度跟不上，所以开源之后就只能在自己特定专业领域的部分小圈子内进行传播，而无法在更大的范围内引起轰动。
所以说对于目前国内厂商都在争相构建 AI 开源框架这件事，我认为这其实是件好事。因为不同的厂商必定都有各自独到的创新之处，争相开源的话就会形成一种百花齐放的局面，在这个基础上大家通过相互学习借鉴、取长补短、竞争融合，最后可能就会打造出几个集大成者的优秀项目出来，成为带动我国 AI 开源蓬勃发展领头雁。当然要造就这种局面，是需要一定的政策和市场融合竞争机制的，使得参与开源的不同的企业和团队之间能够友好合作、互相促进，而不是勾心斗角、恶性竞争。我相信这种局面是会出现的。
InfoQ：目前行业里存在哪些技术挑战？在未来，是否可以通过“开源”得到解决？为什么？
霍博士：从 AI 技术的应用这方面来说，将来 AI 模型部署和运行的形态到底应该呈现个什么样子，我不是太有把握。现在大家谈起来，一般都有云边端这样的说法，但是到底什么情况下应该布到云、什么情况下应该布到边、什么情况下应该布到端，这里边都还是有一个技术、人力、财力等方面的成本和收益的考虑和权衡的。现在算力网络这个概念比较火，利用算力网络是否能解决这个问题？在算力网络中又如何去实现 AI 模型的最优化部署和算力调度以使得模型的开发者、运营者和使用者都能够得到最大的实惠和便利呢？我想这些问题可能现在都还没有一个比较好的现成的答案，是值得去挑战挑战的。
举个例子，就像 GPU 算力设备的使用和调度，目前做得好像都还不是太理想，还不能像使用 CPU 那样随心所欲。一方面，对于开发者来说，编程时还需要考虑不同的驱动版本、需要指定将数据复制到哪一个 GPU 板卡上去，简直是太不友好了。另一方面，GPU 等 AI 计算设备在各类云环境中的虚拟化和共享技术目前也还不成熟，无法做到真正的按需调度和使用。我觉得在理想的算力网络中，模型开发者应该对算力设备不感知才对，不管你有没有 CPU、GPU 或者“其他什么 PU”，更不管你这些有多少或者放在什么地方，开发者只关注于写算法就行了，至于在“哪个 PU”上计算，那应该是算力网络来完成的事情。但现在不论哪个 AI 框架，编程和计算设备都还没有解耦，这似乎在目前还不太好解决。
另外，开源是解决这些问题所需要借助和依赖的一个非常必要的机制和手段，但是光靠开源可能也是不行的，还是得多措并举。
