容器運行AI應(yīng)用需要了解的6個原則
作為當(dāng)前兩大核心IT發(fā)展趨勢，AI/ML與容器已經(jīng)被企業(yè)廣泛應(yīng)用。各個團(tuán)隊不斷尋求將人工智能與機(jī)器學(xué)習(xí)工作負(fù)載良好結(jié)合的方法，而二者之間愈發(fā)緊密的結(jié)合也讓企業(yè)不得不向各類商業(yè)及開源技術(shù)發(fā)出求助請求。
ISG公司企業(yè)技術(shù)分析師Blair Hanley Frank表示，“對IT領(lǐng)導(dǎo)者們來說，最好的消息莫過于過去幾年來，在容器當(dāng)中大規(guī)模運行機(jī)器學(xué)習(xí)的工具與流程都得到了顯著改善。豐富的開源工具、商業(yè)產(chǎn)品及教程正在幫助數(shù)據(jù)科學(xué)家和IT團(tuán)隊啟用并運行這類復(fù)雜系統(tǒng)。”
但在IT領(lǐng)導(dǎo)者與團(tuán)隊深入研究容器化AI/ML工作負(fù)載的基礎(chǔ)技術(shù)之前，不妨先認(rèn)真考慮以下幾項原則。打好基礎(chǔ)，未來的道路才能走得平穩(wěn)而輕盈。
AI/ML工作負(fù)載代表的是工作流
根據(jù)Red Hat技術(shù)布道師Gordon Haff的觀點，與其他各類工作負(fù)載一樣，AI/ML工作負(fù)載的本質(zhì)也可以被視作工作流。從工作流的角度加以審視，有助于闡明在容器內(nèi)運行AI/ML的一些基本概念。
在AI/ML領(lǐng)域，工作流的起點始于數(shù)據(jù)收集與準(zhǔn)備。沒有這一步，模型不可能走得太遠(yuǎn)。
Haff強調(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用高度簡化的方式描述了整個工作流，但其中仍然充斥著巨大的人員、流程及環(huán)境等相關(guān)工作量。為了提高一致性與可重復(fù)性，我們需要容器化工具協(xié)助簡化整個流程。
Haff解釋道，“在傳統(tǒng)上，這樣的工作流往往需要跨越不同環(huán)境、在兩到三位負(fù)責(zé)人之間往來交接。但基于容器平臺的工作流能夠支持自助服務(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)勢：
• 模塊化：讓工作流中的各個重要組成部分（例如模型訓(xùn)練與部署）高度模塊化。這種收益在整個軟件開發(fā)領(lǐng)域也有鮮明體現(xiàn)，即容器化支持下的高度模塊化微服務(wù)架構(gòu)。
• 速度：容器化還能“加速開發(fā)/部署與發(fā)布周期”。
• 人員管理：容器化還能“降低跨團(tuán)隊依賴性，讓團(tuán)隊管理更簡單。”與其他IT領(lǐng)域一樣，工作內(nèi)容會在不同職能團(tuán)隊間往來交換，而容器化有助于減少“交出去就算結(jié)束”的消極心態(tài)。
雖然機(jī)器學(xué)習(xí)模型與其他應(yīng)用或服務(wù)有著完全不同的技術(shù)要求與考量因素，但容器化能夠帶來的好處仍然高度共通。
Red Hat公司數(shù)據(jù)科學(xué)家Audrey Reznik還提到，容器化在增強AI/ML工作負(fù)載或解決方案的可移植性與可擴(kuò)展性（例如混合云環(huán)境）方面同樣功效卓著，同時有望降低運營開銷。
Reznik強調(diào)，“容器使用的系統(tǒng)資源要低于裸機(jī)或者虛擬機(jī)系統(tǒng)。”這又能進(jìn)一步加快部署速度。“我很喜歡問「你的編碼速度能有多快」，因為越早完成編碼、就能先一步使用容器部署解決方案。”
各團(tuán)隊仍須保持一致
雖然工作流程的模塊化程度更高，但各團(tuán)隊、各成員仍然需要保持密切的協(xié)同關(guān)系。
ISG公司的Frank表示，“要保證參與容器化環(huán)境下機(jī)器學(xué)習(xí)工作負(fù)載構(gòu)建與運行的每位員工都能相互理解。運維工程師雖然熟悉Kubernetes的運行需求，但往往不了解數(shù)據(jù)科學(xué)工作負(fù)載的具體特性。另一方面，數(shù)據(jù)科學(xué)家對機(jī)器學(xué)習(xí)模型的構(gòu)建與部署流程也許了然于胸，但卻不擅長把模型遷移進(jìn)容器、或者保持模型的穩(wěn)定運行。”
容器化當(dāng)然能夠提高一致性與協(xié)作水平，但這些增益絕不會憑空而來。
Red Hat公司全球軟件工程總監(jiān)Sherard Griffin指出，“如今這個時代高度強調(diào)結(jié)果的可重復(fù)性，所以企業(yè)可以使用容器來降低AI/ML技術(shù)的準(zhǔn)入門檻，幫助數(shù)據(jù)科學(xué)家輕松共享并重現(xiàn)實驗結(jié)果，同時始終遵循最新的IT與信息安全標(biāo)準(zhǔn)。”
運營要求其實并沒有變
容器化技術(shù)的各項優(yōu)勢對AI/ML的幫助與其他工作負(fù)載類型基本相同，這一點在運營中也有體現(xiàn)。因此在實際運營過程中，我們也需要像對待其他容器化應(yīng)用一樣認(rèn)真思考以下三項運營要求：
• 資源分配：Mustafa指出，隨著時間推移，資源分配是否合理將直接決定成本優(yōu)化與性能表現(xiàn)。如果資源分配過量，那么我們必然浪費掉大量資源和資金；如果分配不足，肯定會遇上性能問題。
• 可觀察性：看不見問題，絕不代表問題就不存在。Frank建議“應(yīng)保證部署必要的可觀察性軟件，更全面地理解多容器應(yīng)用的實際運作方式。”
• 安全性：Positive Technologies公司機(jī)器學(xué)習(xí)工程師Alexandra Murzina認(rèn)為，“從安全的角度來看，在容器中啟用AI/ML類解決方案跟使用其他解決方案并沒有多大區(qū)別。”所以我們?nèi)匀粦?yīng)該把最低權(quán)限原則（包括對員工和對容器本身）、僅使用經(jīng)過驗證的受信容器鏡像、定期運行漏洞掃描以及其他安全策略放在工作清單的前列。
容器不可能解決一切潛在問題
如同自動化沒辦法改善天然存在缺陷的流程，容器化也不可能解決AI/ML工作負(fù)載中的那些根本問題。例如，如果機(jī)器學(xué)習(xí)模型里存在偏見/偏差，那在容器中運行也絲毫不會改善產(chǎn)出效果。
誠然，容器化有著自己的獨特優(yōu)勢，但這些優(yōu)勢絕非萬金油、不可能解決一切潛在問題。面對數(shù)據(jù)錯誤或者是偏見/偏差，容器化唯一能做的就是加快工作流中的各個環(huán)節(jié)，也僅此而已。
凱捷工程技術(shù)總監(jiān)Raghu Kishore Vempati表示，“容器特別適合用來運行AI/ML工作負(fù)載，但單靠容器化沒辦法提高這類模型的效率。容器化只是提供了一種能夠提高模型訓(xùn)練與模型推理生產(chǎn)力的方法，但顯然還有其他問題需要解決。”
自建還是采購，哪種方式更好？
與大多數(shù)技術(shù)選擇一樣，AI/ML工作負(fù)載的容器化領(lǐng)域也會帶來“該這樣，還是該那樣”的困擾。而且這個問題并沒有簡單直觀的答案。
目前市面上有著眾多用于容器化運行AI/ML負(fù)載的開源項目選項。
Autify公司的Mustafa表示，“機(jī)器學(xué)習(xí)工作流的容器化進(jìn)程會帶來新的成本，而且這部分成本很可能超出小型團(tuán)隊的承受范圍。但對大型團(tuán)隊來說，收益卻可能遠(yuǎn)高于成本。”
所以，IT領(lǐng)導(dǎo)者及團(tuán)隊必須帶著明確的目標(biāo)或者理由推動容器化工作。Frank坦言，“總之，別讓本就復(fù)雜的情況變得更加復(fù)雜。除非容器化機(jī)器學(xué)習(xí)負(fù)載能夠帶來超越精力投入的業(yè)務(wù)價值，否則最好別亂折騰。”
但這種價值已經(jīng)滲透到越來越多的企業(yè)當(dāng)中，也隨著AI/ML的總體普及而不斷增加。所以當(dāng)“我們應(yīng)該選擇容器化嗎？”的問題獲得了肯定的答案，接下來要考慮的則是自建還是采購。
好消息是，各類容器化平臺、工具與服務(wù)正在不斷涌現(xiàn)，目前市面上有著眾多用于容器化運行AI/ML負(fù)載的開源項目選項。比如Kubeflow就專門負(fù)責(zé)在Kubernetes上編排機(jī)器學(xué)習(xí)類工作負(fù)載。
這里分享一條普適標(biāo)準(zhǔn)，除非AI/ML工作流的容器化、部署與管理事務(wù)就是企業(yè)的業(yè)務(wù)核心，否則千萬別在這方面耗費太多精力。Haff表示，“與云原生領(lǐng)域的情況類似，當(dāng)團(tuán)隊過度專注于組裝平臺與工作流、卻忽視了處理手頭的實際業(yè)務(wù)問題時，也就離失敗不遠(yuǎn)了。很多團(tuán)隊在平臺構(gòu)建完成之后，才意識到自己需要使用的是GPU資源，這時候再要調(diào)整已經(jīng)來不及了。”
一旦遇到這種狀況，團(tuán)隊只能把大量時間浪費在補救和處理設(shè)計失誤當(dāng)中，根本沒工夫思考真正重要的模型開發(fā)、訓(xùn)練與推理工作。
Haff強調(diào)，“作為一種可行的辦法，我們不妨選擇統(tǒng)一的自助服務(wù)平臺，例如OpenShift Data Science。它既能提供集成化工作流，也允許用戶根據(jù)實際需求添加額外的開源和專有工具。”
另外，無論大家走的是商業(yè)路線、開源路線還是二者兼有，請務(wù)必為未來發(fā)展預(yù)留回旋空間。AI/ML生態(tài)系統(tǒng)每分每秒都在迅猛發(fā)展，我們自己的戰(zhàn)略也隨時可能有所變化，必須提前做好規(guī)劃。
Reznik最后總結(jié)道，“別把自己綁在一家供應(yīng)商身上。我們應(yīng)該充分發(fā)揮各類開源解決方案的優(yōu)勢，不要滿足于供應(yīng)商擺在面前的那少數(shù)幾種選項。方案的多樣性越強，我們的團(tuán)隊就將擁有更多的創(chuàng)新可能性。”
