到 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 的影響，另一方面也學到了更多開源方面的知識和先進經驗。在年初召開的啟智開發者大會上，CubeAI 還有幸榮獲了啟智社區頒發的優秀開源項目獎，我們的開發團隊成員也榮獲了啟智社區的優秀開發者稱號。最近一段時間社區搞的“我為開源打榜狂”活動也很有意思。我覺得所有這些都是對開源開發者很好的鞭策和鼓勵，促使大伙能夠更好地投入到開源事業的建設和發展中來。

InfoQ：之后對 CubeAI 智立方平臺的發展有何規劃？

霍博士：作為一個平臺型的開源軟件，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 框架，編程和計算設備都還沒有解耦，這似乎在目前還不太好解決。

另外，開源是解決這些問題所需要借助和依賴的一個非常必要的機制和手段，但是光靠開源可能也是不行的，還是得多措并舉。?

編輯：黃飛