作為當前兩大核心IT發展趨勢，AI/ML與容器已經被企業廣泛應用。各個團隊不斷尋求將人工智能與機器學習工作負載良好結合的方法，而二者之間愈發緊密的結合也讓企業不得不向各類商業及開源技術發出求助請求。 

[[434556]]

ISG公司企業技術分析師Blair Hanley Frank表示，“對IT領導者們來說，最好的消息莫過于過去幾年來，在容器當中大規模運行機器學習的工具與流程都得到了顯著改善。豐富的開源工具、商業產品及教程正在幫助數據科學家和IT團隊啟用并運行這類復雜系統。”

但在IT領導者與團隊深入研究容器化AI/ML工作負載的基礎技術之前，不妨先認真考慮以下幾項原則。打好基礎，未來的道路才能走得平穩而輕盈。

AI/ML工作負載代表的是工作流

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

在AI/ML領域，工作流的起點始于數據收集與準備。沒有這一步，模型不可能走得太遠。

Haff強調，第一步就是數據的收集、清潔與處理。完成了這些環節，“接下來才是模型訓練，即根據一組訓練數據調整參數。模型訓練完成后，工作流中的下一步就是部署至生產環境。最后，數據科學家們需要監控模型在生產中的性能，跟蹤各類預測及性能指標。”

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

Haff解釋道，“在傳統上，這樣的工作流往往需要跨越不同環境、在兩到三位負責人之間往來交接。但基于容器平臺的工作流能夠支持自助服務，幫助數據科學家輕松將開發好的模型集成到應用場景當中。”

與其他容器化工作負載相似的收益

Autify公司AI與ML負責人Nauman Mustafa認為，容器化技術在AI/ML工作流場景下擁有三大總體優勢：

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

雖然機器學習模型與其他應用或服務有著完全不同的技術要求與考量因素，但容器化能夠帶來的好處仍然高度共通。

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

Reznik強調，“容器使用的系統資源要低于裸機或者虛擬機系統。”這又能進一步加快部署速度。“我很喜歡問「你的編碼速度能有多快」，因為越早完成編碼、就能先一步使用容器部署解決方案。”

各團隊仍須保持一致

雖然工作流程的模塊化程度更高，但各團隊、各成員仍然需要保持密切的協同關系。

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

容器化當然能夠提高一致性與協作水平，但這些增益絕不會憑空而來。

Red Hat公司全球軟件工程總監Sherard Griffin指出，“如今這個時代高度強調結果的可重復性，所以企業可以使用容器來降低AI/ML技術的準入門檻，幫助數據科學家輕松共享并重現實驗結果，同時始終遵循最新的IT與信息安全標準。”

運營要求其實并沒有變

容器化技術的各項優勢對AI/ML的幫助與其他工作負載類型基本相同，這一點在運營中也有體現。因此在實際運營過程中，我們也需要像對待其他容器化應用一樣認真思考以下三項運營要求：

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

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

如同自動化沒辦法改善天然存在缺陷的流程，容器化也不可能解決AI/ML工作負載中的那些根本問題。例如，如果機器學習模型里存在偏見/偏差，那在容器中運行也絲毫不會改善產出效果。

誠然，容器化有著自己的獨特優勢，但這些優勢絕非萬金油、不可能解決一切潛在問題。面對數據錯誤或者是偏見/偏差，容器化唯一能做的就是加快工作流中的各個環節，也僅此而已。

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

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

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

目前市面上有著眾多用于容器化運行AI/ML負載的開源項目選項。

Autify公司的Mustafa表示，“機器學習工作流的容器化進程會帶來新的成本，而且這部分成本很可能超出小型團隊的承受范圍。但對大型團隊來說，收益卻可能遠高于成本。”

所以，IT領導者及團隊必須帶著明確的目標或者理由推動容器化工作。Frank坦言，“總之，別讓本就復雜的情況變得更加復雜。除非容器化機器學習負載能夠帶來超越精力投入的業務價值，否則最好別亂折騰。”

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

好消息是，各類容器化平臺、工具與服務正在不斷涌現，目前市面上有著眾多用于容器化運行AI/ML負載的開源項目選項。比如Kubeflow就專門負責在Kubernetes上編排機器學習類工作負載。

這里分享一條普適標準，除非AI/ML工作流的容器化、部署與管理事務就是企業的業務核心，否則千萬別在這方面耗費太多精力。Haff表示，“與云原生領域的情況類似，當團隊過度專注于組裝平臺與工作流、卻忽視了處理手頭的實際業務問題時，也就離失敗不遠了。很多團隊在平臺構建完成之后，才意識到自己需要使用的是GPU資源，這時候再要調整已經來不及了。”

一旦遇到這種狀況，團隊只能把大量時間浪費在補救和處理設計失誤當中，根本沒工夫思考真正重要的模型開發、訓練與推理工作。

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

另外，無論大家走的是商業路線、開源路線還是二者兼有，請務必為未來發展預留回旋空間。AI/ML生態系統每分每秒都在迅猛發展，我們自己的戰略也隨時可能有所變化，必須提前做好規劃。

Reznik最后總結道，“別把自己綁在一家供應商身上。我們應該充分發揮各類開源解決方案的優勢，不要滿足于供應商擺在面前的那少數幾種選項。方案的多樣性越強，我們的團隊就將擁有更多的創新可能性。”