作為當(dāng)前兩大核心IT發(fā)展趨勢(shì)，AI/ML與容器已經(jīng)被企業(yè)廣泛應(yīng)用。各個(gè)團(tuán)隊(duì)不斷尋求將人工智能與機(jī)器學(xué)習(xí)工作負(fù)載良好結(jié)合的方法，而二者之間愈發(fā)緊密的結(jié)合也讓企業(yè)不得不向各類商業(yè)及開源技術(shù)發(fā)出求助請(qǐng)求。 

[[434556]]

ISG公司企業(yè)技術(shù)分析師Blair Hanley Frank表示，“對(duì)IT領(lǐng)導(dǎo)者們來說，最好的消息莫過于過去幾年來，在容器當(dāng)中大規(guī)模運(yùn)行機(jī)器學(xué)習(xí)的工具與流程都得到了顯著改善。豐富的開源工具、商業(yè)產(chǎn)品及教程正在幫助數(shù)據(jù)科學(xué)家和IT團(tuán)隊(duì)啟用并運(yùn)行這類復(fù)雜系統(tǒng)。”

但在IT領(lǐng)導(dǎo)者與團(tuán)隊(duì)深入研究容器化AI/ML工作負(fù)載的基礎(chǔ)技術(shù)之前，不妨先認(rèn)真考慮以下幾項(xiàng)原則。打好基礎(chǔ)，未來的道路才能走得平穩(wěn)而輕盈。

AI/ML工作負(fù)載代表的是工作流

根據(jù)Red Hat技術(shù)布道師Gordon Haff的觀點(diǎn)，與其他各類工作負(fù)載一樣，AI/ML工作負(fù)載的本質(zhì)也可以被視作工作流。從工作流的角度加以審視，有助于闡明在容器內(nèi)運(yùn)行AI/ML的一些基本概念。

在AI/ML領(lǐng)域，工作流的起點(diǎn)始于數(shù)據(jù)收集與準(zhǔn)備。沒有這一步，模型不可能走得太遠(yuǎn)。

Haff強(qiáng)調(diào)，第一步就是數(shù)據(jù)的收集、清潔與處理。完成了這些環(huán)節(jié)，“接下來才是模型訓(xùn)練，即根據(jù)一組訓(xùn)練數(shù)據(jù)調(diào)整參數(shù)。模型訓(xùn)練完成后，工作流中的下一步就是部署至生產(chǎn)環(huán)境。最后，數(shù)據(jù)科學(xué)家們需要監(jiān)控模型在生產(chǎn)中的性能，跟蹤各類預(yù)測及性能指標(biāo)。”

Haff用高度簡化的方式描述了整個(gè)工作流，但其中仍然充斥著巨大的人員、流程及環(huán)境等相關(guān)工作量。為了提高一致性與可重復(fù)性，我們需要容器化工具協(xié)助簡化整個(gè)流程。

Haff解釋道，“在傳統(tǒng)上，這樣的工作流往往需要跨越不同環(huán)境、在兩到三位負(fù)責(zé)人之間往來交接。但基于容器平臺(tái)的工作流能夠支持自助服務(wù)，幫助數(shù)據(jù)科學(xué)家輕松將開發(fā)好的模型集成到應(yīng)用場景當(dāng)中。”

與其他容器化工作負(fù)載相似的收益

Autify公司AI與ML負(fù)責(zé)人Nauman Mustafa認(rèn)為，容器化技術(shù)在AI/ML工作流場景下?lián)碛腥罂傮w優(yōu)勢(shì)：

• 模塊化：讓工作流中的各個(gè)重要組成部分(例如模型訓(xùn)練與部署)高度模塊化。這種收益在整個(gè)軟件開發(fā)領(lǐng)域也有鮮明體現(xiàn)，即容器化支持下的高度模塊化微服務(wù)架構(gòu)。
• 速度：容器化還能“加速開發(fā)/部署與發(fā)布周期”。
• 人員管理：容器化還能“降低跨團(tuán)隊(duì)依賴性，讓團(tuán)隊(duì)管理更簡單。”與其他IT領(lǐng)域一樣，工作內(nèi)容會(huì)在不同職能團(tuán)隊(duì)間往來交換，而容器化有助于減少“交出去就算結(jié)束”的消極心態(tài)。

雖然機(jī)器學(xué)習(xí)模型與其他應(yīng)用或服務(wù)有著完全不同的技術(shù)要求與考量因素，但容器化能夠帶來的好處仍然高度共通。

Red Hat公司數(shù)據(jù)科學(xué)家Audrey Reznik還提到，容器化在增強(qiáng)AI/ML工作負(fù)載或解決方案的可移植性與可擴(kuò)展性(例如混合云環(huán)境)方面同樣功效卓著，同時(shí)有望降低運(yùn)營開銷。

Reznik強(qiáng)調(diào)，“容器使用的系統(tǒng)資源要低于裸機(jī)或者虛擬機(jī)系統(tǒng)。”這又能進(jìn)一步加快部署速度。“我很喜歡問「你的編碼速度能有多快」，因?yàn)樵皆缤瓿删幋a、就能先一步使用容器部署解決方案。”

各團(tuán)隊(duì)仍須保持一致

雖然工作流程的模塊化程度更高，但各團(tuán)隊(duì)、各成員仍然需要保持密切的協(xié)同關(guān)系。

ISG公司的Frank表示，“要保證參與容器化環(huán)境下機(jī)器學(xué)習(xí)工作負(fù)載構(gòu)建與運(yùn)行的每位員工都能相互理解。運(yùn)維工程師雖然熟悉Kubernetes的運(yùn)行需求，但往往不了解數(shù)據(jù)科學(xué)工作負(fù)載的具體特性。另一方面，數(shù)據(jù)科學(xué)家對(duì)機(jī)器學(xué)習(xí)模型的構(gòu)建與部署流程也許了然于胸，但卻不擅長把模型遷移進(jìn)容器、或者保持模型的穩(wěn)定運(yùn)行。”

容器化當(dāng)然能夠提高一致性與協(xié)作水平，但這些增益絕不會(huì)憑空而來。

Red Hat公司全球軟件工程總監(jiān)Sherard Griffin指出，“如今這個(gè)時(shí)代高度強(qiáng)調(diào)結(jié)果的可重復(fù)性，所以企業(yè)可以使用容器來降低AI/ML技術(shù)的準(zhǔn)入門檻，幫助數(shù)據(jù)科學(xué)家輕松共享并重現(xiàn)實(shí)驗(yàn)結(jié)果，同時(shí)始終遵循最新的IT與信息安全標(biāo)準(zhǔn)。”

運(yùn)營要求其實(shí)并沒有變

容器化技術(shù)的各項(xiàng)優(yōu)勢(shì)對(duì)AI/ML的幫助與其他工作負(fù)載類型基本相同，這一點(diǎn)在運(yùn)營中也有體現(xiàn)。因此在實(shí)際運(yùn)營過程中，我們也需要像對(duì)待其他容器化應(yīng)用一樣認(rèn)真思考以下三項(xiàng)運(yùn)營要求：

• 資源分配：Mustafa指出，隨著時(shí)間推移，資源分配是否合理將直接決定成本優(yōu)化與性能表現(xiàn)。如果資源分配過量，那么我們必然浪費(fèi)掉大量資源和資金;如果分配不足，肯定會(huì)遇上性能問題。
• 可觀察性：看不見問題，絕不代表問題就不存在。Frank建議“應(yīng)保證部署必要的可觀察性軟件，更全面地理解多容器應(yīng)用的實(shí)際運(yùn)作方式。”
• 安全性：Positive Technologies公司機(jī)器學(xué)習(xí)工程師Alexandra Murzina認(rèn)為，“從安全的角度來看，在容器中啟用AI/ML類解決方案跟使用其他解決方案并沒有多大區(qū)別。”所以我們?nèi)匀粦?yīng)該把最低權(quán)限原則(包括對(duì)員工和對(duì)容器本身)、僅使用經(jīng)過驗(yàn)證的受信容器鏡像、定期運(yùn)行漏洞掃描以及其他安全策略放在工作清單的前列。

容器不可能解決一切潛在問題

如同自動(dòng)化沒辦法改善天然存在缺陷的流程，容器化也不可能解決AI/ML工作負(fù)載中的那些根本問題。例如，如果機(jī)器學(xué)習(xí)模型里存在偏見/偏差，那在容器中運(yùn)行也絲毫不會(huì)改善產(chǎn)出效果。

誠然，容器化有著自己的獨(dú)特優(yōu)勢(shì)，但這些優(yōu)勢(shì)絕非萬金油、不可能解決一切潛在問題。面對(duì)數(shù)據(jù)錯(cuò)誤或者是偏見/偏差，容器化唯一能做的就是加快工作流中的各個(gè)環(huán)節(jié)，也僅此而已。

凱捷工程技術(shù)總監(jiān)Raghu Kishore Vempati表示，“容器特別適合用來運(yùn)行AI/ML工作負(fù)載，但單靠容器化沒辦法提高這類模型的效率。容器化只是提供了一種能夠提高模型訓(xùn)練與模型推理生產(chǎn)力的方法，但顯然還有其他問題需要解決。”

自建還是采購，哪種方式更好?

與大多數(shù)技術(shù)選擇一樣，AI/ML工作負(fù)載的容器化領(lǐng)域也會(huì)帶來“該這樣，還是該那樣”的困擾。而且這個(gè)問題并沒有簡單直觀的答案。

目前市面上有著眾多用于容器化運(yùn)行AI/ML負(fù)載的開源項(xiàng)目選項(xiàng)。

Autify公司的Mustafa表示，“機(jī)器學(xué)習(xí)工作流的容器化進(jìn)程會(huì)帶來新的成本，而且這部分成本很可能超出小型團(tuán)隊(duì)的承受范圍。但對(duì)大型團(tuán)隊(duì)來說，收益卻可能遠(yuǎn)高于成本。”

所以，IT領(lǐng)導(dǎo)者及團(tuán)隊(duì)必須帶著明確的目標(biāo)或者理由推動(dòng)容器化工作。Frank坦言，“總之，別讓本就復(fù)雜的情況變得更加復(fù)雜。除非容器化機(jī)器學(xué)習(xí)負(fù)載能夠帶來超越精力投入的業(yè)務(wù)價(jià)值，否則最好別亂折騰。”

但這種價(jià)值已經(jīng)滲透到越來越多的企業(yè)當(dāng)中，也隨著AI/ML的總體普及而不斷增加。所以當(dāng)“我們應(yīng)該選擇容器化嗎?”的問題獲得了肯定的答案，接下來要考慮的則是自建還是采購。

好消息是，各類容器化平臺(tái)、工具與服務(wù)正在不斷涌現(xiàn)，目前市面上有著眾多用于容器化運(yùn)行AI/ML負(fù)載的開源項(xiàng)目選項(xiàng)。比如Kubeflow就專門負(fù)責(zé)在Kubernetes上編排機(jī)器學(xué)習(xí)類工作負(fù)載。

這里分享一條普適標(biāo)準(zhǔn)，除非AI/ML工作流的容器化、部署與管理事務(wù)就是企業(yè)的業(yè)務(wù)核心，否則千萬別在這方面耗費(fèi)太多精力。Haff表示，“與云原生領(lǐng)域的情況類似，當(dāng)團(tuán)隊(duì)過度專注于組裝平臺(tái)與工作流、卻忽視了處理手頭的實(shí)際業(yè)務(wù)問題時(shí)，也就離失敗不遠(yuǎn)了。很多團(tuán)隊(duì)在平臺(tái)構(gòu)建完成之后，才意識(shí)到自己需要使用的是GPU資源，這時(shí)候再要調(diào)整已經(jīng)來不及了。”

一旦遇到這種狀況，團(tuán)隊(duì)只能把大量時(shí)間浪費(fèi)在補(bǔ)救和處理設(shè)計(jì)失誤當(dāng)中，根本沒工夫思考真正重要的模型開發(fā)、訓(xùn)練與推理工作。

Haff強(qiáng)調(diào)，“作為一種可行的辦法，我們不妨選擇統(tǒng)一的自助服務(wù)平臺(tái)，例如OpenShift Data Science。它既能提供集成化工作流，也允許用戶根據(jù)實(shí)際需求添加額外的開源和專有工具。”

另外，無論大家走的是商業(yè)路線、開源路線還是二者兼有，請(qǐng)務(wù)必為未來發(fā)展預(yù)留回旋空間。AI/ML生態(tài)系統(tǒng)每分每秒都在迅猛發(fā)展，我們自己的戰(zhàn)略也隨時(shí)可能有所變化，必須提前做好規(guī)劃。

Reznik最后總結(jié)道，“別把自己綁在一家供應(yīng)商身上。我們應(yīng)該充分發(fā)揮各類開源解決方案的優(yōu)勢(shì)，不要滿足于供應(yīng)商擺在面前的那少數(shù)幾種選項(xiàng)。方案的多樣性越強(qiáng)，我們的團(tuán)隊(duì)就將擁有更多的創(chuàng)新可能性。”