如何將AI/ML與物件儲存結合使用

隨著企業的不斷髮展，機器學習和人工智慧已成為董事會層面的舉措。隨著AI/ML融入到每一個軟體堆疊和架構中，幾年前似乎近乎神話般的功能現在被視為理所當然。這被稱為AI優先架構。

在AI/ML的世界裡，重點是找到能夠準確捕捉資料中複雜關係的模型，並使用這些模型通過準確的預測創造商業價值。

現實是，在實現這一崇高目標之前，需要大量的資料探勘。儘管AI/ML的宣傳和關注點在於使用最新、最酷的建模技術，但已經反覆證明，通過適當的資料整理和找到向模型展示資料的方法，可以實現對複雜關係建模能力的最大提升，從而使模型在訓練時瞭解細微差別。

簡而言之，這主要是關於資料，而不是模型。

在構建AI優先架構時，會出現幾個關鍵需求，尤其是與儲存相關的需求。在本文中，我們將概述需要考慮的內容和原因。

可伸縮性

在設計AI/ML架構時，首要考慮的是可伸縮性。雖然可伸縮性有多個方面，但我們關注的是資料基礎設施的可伸縮性。一些非常有趣的工作正在有限的環境中進行，那裡沒有太多可用的培訓資料，但最好的結果仍然來自於在涉及大規模培訓的用例中進行的工作。

大規模的訓練不是幾百T——通常是幾十到幾百P。從管理和效能角度來看，這個容量超過了傳統SAN/NAS架構的能力。

一旦過了幾個PBs，你就會看到物件儲存。物件儲存對於這種規模的問題來說是獨一無二的，因為它可以無限擴充套件，跨網路擴充套件，並隨著增長提供線性效能。

此外，物件儲存天生適合不同型別的資料——半結構化、非結構化和結構化。隨著訪問資料的AI/ML框架尋求建立功能，更多不同型別的資料變得重要，在一個地方儲存、版本和管理所有資料的能力變得非常重要。

此外，隨著這些不同型別的資料擴充套件到許多PB領域，為不同型別的資料建立和維護不同的儲存解決方案變得非常昂貴。將永續性整合到物件儲存中可以節省基礎設施成本。

RESTful API/S3

由於上述關於可伸縮性的要求，幾乎每個AI/ML平臺都支援物件儲存。物件儲存為所有型別的訓練資料提供了一個單一的儲存庫，並且幾乎可以無限擴充套件。使用單一儲存架構可以簡化部署並降低運營成本。

S3 API是物件儲存的事實標準，因此，它是AI/ML資料架構領域的事實標準。事實上，大多數現代AI/ML平臺都是為S3 API構建的，後來通常由社群進行擴充套件，以支援傳統的SAN/NAS解決方案。

理由很簡單：RESTful API是設計分散式軟體系統和物件永續性的現代方法，S3正好符合定義。此外，部署在AWS上並使用S3構建的AI/ML專案非常普遍，很明顯，S3 API，即物件儲存，實際上是大規模AI/ML專案的一個需求。

你能用POSIX(行動式作業系統介面)做小規模的工作嗎?是的，但這是更多的沙箱工作。對於大規模的真正AI/ML，S3將是資料基礎設施的API。

物件鎖定

在金融服務、醫療保健和政府等受監管的環境中，物件鎖定是一個重要的問題。儘管如此，並不是所有的物件儲存都支援物件鎖定，並且很少有物件儲存針對操作部署進行了優化。

其核心功能是確保在設定的時間段內不能刪除或覆蓋物件。需要適應不同的模式，但總體目標是確保源上不會發生篡改。版本控制很容易。

這對於AI/ML模型和訓練檔案來說尤其重要，因為它們的目標是一個可操作的科學試驗。確保訓練資料的有效性與驗證模型本身同樣重要。

物件生命週期管理

在現代企業中，模型不是一成不變的。隨著時間的推移，越來越多不同的資料可用，模型需要相應地更新。這不應該是一個手動過程，因為這將使模型從靜態開始。

物件儲存可以提供完整的生命週期管理功能。這包括隨著模型老化從熱層到溫層的分層，以及管理有關資料更新、轉換和刪除的策略。

與此相關的是物件儲存幾乎無限的可擴充套件性。在一個可以擁有儘可能多的儲存空間的世界中，它們都可以存在於一個名稱空間中。從物件生命週期管理的角度來看，這提供了無數的可能性——所有這些都是通過RESTful API實現自動化的。

將不同的資料型別都放在一個名稱空間中，大大簡化了資料管理和驗證過程。在規模上，這提高了運營效率並節省了資金。

效能

與規模一樣，效能也有多個方面。在轉向大規模效能之前，讓我們先看看讀寫效能。

發現一組給定模型的超引數，以優化訓練能力是一項挑戰。對於一個給定的模型，事先給定一組訓練資料是無法確定最優超引數的。

超引數調整是一門藝術，而不是一門科學，通常歸結為在每個引數範圍內對離散點進行智慧或非智慧搜尋，直到找到一個合適的集合(“網格搜尋”)。

更復雜的是，給定一組選定的超引數，模型在整個訓練過程中的收斂速度不是線性的，這意味著當給定的超引數集在給定的訓練集上針對給定的模型進行評估時，必須允許每個模型完成收斂訓練，以便評估結果模型的適用性和超引數集的可取性。

簡單地說：這可能是大量重複的試錯訓練。對於非常大的資料集，這需要大量讀取訓練檔案。

在當前的“Auto ML”庫中，資料科學家或開發人員對這項工作的大部分內容都是隱藏的。它被隱藏並不意味著它沒有發生。當我們將訓練叢集的大小增加到數百或數千個計算節點以並行化“Auto ML”過程時，我們會建立一種情況，即給定的訓練檔案會被讀取數百或數千次。

如果該訓練檔案很大，則I/O量的增加速度大致等於正在評估的模型數量乘以我們決定測試每個超引數的離散點數量乘以給定模型的超引數數量。

簡而言之，從永續性儲存中讀取訓練檔案的效能很重要。你可以隨心所欲地優化程式碼，但模型訓練仍將取決於讀取效能。快取當然有幫助。但歸根結底，這是一個檔案I/O挑戰。

多快是快?對於上下文，在NVMe的32個節點上執行的MinIO讀取速度為325 GiB/sec。這應該是AI/ML設定的目標。

更復雜的AI/ML用例——Lambda Compute Eventing

一旦開發出一個似乎執行良好的模型，通常需要在投入生產之前對其進行驗證。在金融服務組織中，這通常由一個單獨的模型驗證團隊完成，該團隊不屬於資料科學開發的一部分。他們有意分開，負責驗證組織使用的數學/模型的正確性。除了驗證模型的正確性外，模型驗證團隊通常還負責測試和了解模型在各種意外不利經濟條件下的行為，這些不利經濟條件可能不是模型培訓的一部分。

例如，如果我們討論的是金融模型，而使用的訓練資料是最近的歷史資料，這是常見的，那麼模型驗證團隊可能會根據不利資料執行模型，例如大蕭條時期的歷史資料或全球衝突時期的歷史資料，如戰爭、極端市場波動、收益率曲線反轉或負實際利率。他們還可以用理論資料測試模型，以評估穩定性。模型驗證團隊在評估數學/模型的行為以及組織的總體風險方面發揮著作用。這不是一個小的努力。

要使用物件儲存操作AI/ML，一個真正強大的功能是Lambda Compute Eventing(LCE)。LCE有助於自動化這個複雜的模型驗證工作流。通常，為建模過程生命週期中的每個步驟建立單獨的桶，LCE用於通知相關方新物件到達每個桶。該事件會觸發模型進展階段的適當處理，以及滿足合規性要求或內部檢查所需的任何業務級別稽核。

總結

儘管最近的技術炒作會讓我們都相信，找到下一個偉大、複雜的建模方法是資料科學的聖盃，但實際上，資料的收集和正確管理，以及確保建模過程安全性和可再現性的正確MLOP，才是真正為組織創造價值的方法。MinIO本質上提供了在現代企業中建立和使用大規模AI/ML所需的功能。