隨著企業的不斷發展，機器學習和人工智能已成為董事會層面的舉措。隨著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所需的功能。