開發人員傾向於軟體定義、開源、雲端原生且簡單的技術。這本質上定義了物件儲存。
on AI/ML
介紹
為機器學習 (ML) 專案的所有階段選擇最佳儲存至關重要。研究工程師需要建立多個版本的資料集並嘗試不同的模型架構。當模型升級到生產環境時，它在對新資料進行預測時必須有效運作。 — 在生產中運行的訓練有素的模型是將人工智慧添加到應用程式中的，所以這是最終目標。
身為一名人工智慧/機器學習架構師，這就是我過去幾年的生活。我想分享我所了解的有關培訓和服務模型的專案要求以及可用選項的知識。將此視為一項調查。我將涵蓋從傳統檔案系統變體到現代雲端原生物件儲存的所有內容，這些物件儲存是為滿足與大型語言模型 (LLM) 和其他生成 AI 系統相關的大規模效能要求而設計的。
一旦我們了解了要求和儲存選項，我將審查每個選項，看看它如何滿足我們的要求。
在我們深入研究需求之前，回顧一下當今軟體產業正在發生的事情將是有益的。正如您將看到的，機器學習和人工智慧的發展正在推動需求。
機器學習和人工智慧的現狀
能夠以接近人類精度進行聊天的大型語言模型 (LLM) 正在主導媒體。這些模型需要大量資料來訓練。關於生成人工智慧還有許多其他令人興奮的進步，例如文字到圖像和聲音生成。這些也都需要大量的數據。
這不僅僅是LLM的問題。存在解決基本業務問題的其他模型類型。迴歸、分類和多標籤是非生成性的模型類型，但可以為企業增加真正的價值。越來越多的組織正在尋求這些類型的模型來解決各種問題。
另一個現像是，越來越多的企業正在成為SaaS供應商，利用客戶的私人資料提供模型訓練服務。考慮一個LLM，一名工程師接受網路數據和數千本書的培訓來回答問題，就像 ChatGPT 一樣。該LLM將是一位能夠回答各種主題的基本問題的多面手。然而，如果使用者提出需要特定行業（如醫療保健、金融服務或專業服務）的高級知識的問題，它可能無法提供有用、詳細和完整的答案。可以使用附加資料對經過訓練的模型進行微調。因此，受過通才培訓的LLM可以使用特定行業的數據進行進一步培訓。該模型將為有關該行業的問題提供更好的答案。對於LLM來說，微調尤其有益，因為他們的初始培訓可能要花費數百萬美元，而微調成本便宜得多。
無論您正在建立什麼模型，一旦投入生產，它就必須可用、可擴展且具有彈性，就像您作為應用程式的一部分部署的任何其他服務一樣。如果您是提供 SaaS 解決方案的企業，您將有額外的安全要求。您需要防止直接存取代表您競爭優勢的任何模型，並且需要保護客戶資料的安全。
讓我們更詳細地看看這些要求。
機器學習儲存要求
下面列出的儲存要求來自技術決策者評估任何技術可行性的視角。具體來說，軟體解決方案中使用的技術必須是可擴展的、可用的、安全的、高效能的、有彈性的和簡單的。讓我們看看每個要求對機器學習專案意味著什麼。
可擴充性：儲存解決方案的可擴充性是指其無需進行重大變更即可處理不斷增加的儲存量的能力。換句話說，隨著容量和吞吐量需求的增加，可擴充儲存可以繼續發揮最佳功能。考慮一個組織透過一個專案開始其 ML/AI 之旅。該項目本身可能沒有很大的儲存需求。然而，很快其他團隊就會提出他們的倡議。這些新團隊可能有較小的儲存需求。然而，總的來說，這些團隊可能會對中央儲存解決方案提出相當大的儲存要求。可擴展的儲存解決方案應該擴展其資源（無論是擴展還是擴展），以處理新團隊添加資料所需的額外容量和吞吐量。
可用－可用性是指作業系統執行任務的能力的屬性。操作人員經常測量整個系統隨時間的可用性。例如，該系統在該月 99.999% 的時間內可用。可用性也可以指單一請求在資源開始處理之前所經歷的等待時間。等待時間過長會導致系統無法使用。
無論定義如何，可用性對於模型訓練和儲存至關重要。模型訓練不應因儲存解決方案缺乏可用性而出現延遲。生產中的模型應在當月 99.999% 的時間內可用。對資料或模型本身的請求可能很大，但等待時間應該很短。
安全性– 在進行所有讀取或寫入操作之前，儲存系統應該知道您是誰以及您可以做什麼。換句話說，儲存存取需要經過身份驗證和授權。靜態資料也應該是安全的，並提供加密選項。上一節中提到的假設的 SaaS 供應商在向客戶提供多租戶服務時必須密切注意安全性。鎖定資料、版本資料和指定保留策略的能力也是安全要求的一部分。
高效能— 高效能儲存解決方案針對高吞吐量和低延遲進行了最佳化。在模型訓練過程中，表現至關重要，因為更高的表現意味著實驗完成得更快。機器學習工程師可以執行的實驗數量與最終模型的準確性成正比。如果使用神經網絡，則需要進行多次實驗才能確定最佳架構。此外，超參數調整需要進一步的實驗。使用 GPU 的組織必須注意防止儲存成為瓶頸。如果儲存解決方案無法以等於或大於 GPU 處理速率的速率傳輸數據，系統將浪費寶貴的 GPU 週期。
彈性— 彈性儲存解決方案不應出現單點故障。彈性系統會盡力防止故障，但當發生故障時，它可以正常恢復。這樣的解決方案應該能夠參與故障轉移和停留練習，其中模擬整個資料中心的遺失以測試整個應用程式的彈性。
在生產環境中運行的模型需要彈性。然而，彈性也可以為模型訓練增加價值。假設 ML 團隊使用使用叢集的分散式訓練技術。在這種情況下，為該叢集提供服務的儲存以及叢集本身應該具有容錯能力，以防止團隊因故障而損失數小時或數天的時間。
簡單－工程師將「簡單」和「美麗」視為同義詞。這是有原因的。當軟體設計很簡單時，它就會經過深思熟慮。簡單的設計適合許多不同的場景並解決許多問題。 ML 的儲存系統應該很簡單，尤其是在新 ML 專案的概念驗證 (PoC) 階段，此時研究人員需要專注於特徵工程、模型架構和超參數調整，同時嘗試提高模型的效能，因此足夠準確，可以為業務增加價值。
儲存格局
有多種用於機器學習和服務的儲存選項。如今，這些選項分為以下幾類：本機檔案儲存、網路附加儲存 (NAS)、儲存區域網路 (SAN)、分散式檔案系統 (DFS) 和物件儲存。在本節中，我將討論每一個並將它們與我們的要求進行比較。我們的目標是找到一個能夠滿足所有要求的最佳選項。
本機檔案儲存：研究人員工作站上的檔案系統和專用於模型服務的伺服器上的檔案系統是用於機器學習儲存的本機檔案系統的範例。本機儲存的底層裝置通常是固態硬碟 (SSD)，但也可能是更先進的非揮發性記憶體高速驅動器 (NVMe)。在這兩種情況下，計算和儲存都位於同一系統上。
這是最簡單的選擇。這也是 PoC 階段的常見選擇，其中一個小型研發團隊試圖從模型中獲得足夠的性能，以證明進一步的支出是合理的。雖然這種方法很常見，但也有缺點。
本機檔案系統的儲存容量有限，不適合較大的資料集。由於沒有複製或自動縮放，本地檔案系統無法以可用、可靠和可擴展的方式運作。它們與它們所在的系統一樣安全。一旦模型投入生產，就有比本地文件系統更好的選擇來提供模型服務。
網路附加儲存 (NAS)： NAS 是連接到網路的 TCP/IP 設備，該網路具有 IP 位址，就像電腦一樣。儲存的底層技術是磁碟機 RAID 陣列，檔案透過 TCP 傳送到客戶端。這些設備通常作為設備交付。管理資料和 RAID 陣列所需的計算被打包到單一裝置中。
NAS 設備可以受到保護，而底層儲存的 RAID 配置提供了一定的可用性和可靠性。 NAS 使用伺服器訊息區塊 (SMB) 和網路檔案系統 (NFS) 等資料傳輸協定來封裝 TCP 進行資料傳輸。
當存在大量檔案時，NAS 設備會遇到擴充問題。這是由於其底層儲存結構的層次結構和路徑造成的，其最大數量為數百萬個檔案。這是所有基於文件的解決方案都存在的問題。 NAS 的最大儲存量約為數十 TB。
儲存區域網路 (SAN)： SAN 將伺服器和 RAID 儲存結合在高速互連上。使用 SAN，您可以使用光纖通道協定 (FCP) 將儲存流量置於專用光纖通道上。文件操作請求可能透過 TCP 到達 SAN，但所有資料傳輸都是透過專用於高效傳輸資料的網路進行的。如果專用光纖網路不可用，SAN 可以使用互聯網小型電腦系統介面 (iSCSI)，它使用 TCP 進行儲存流量。
SAN 的設定比 NAS 設備更複雜，因為它是一個網路而不是一個設備。您需要一個單獨的專用網路才能發揮 SAN 的最佳效能。因此，SAN 成本高昂並且需要付出相當大的努力來管理。
雖然 SAN 與 NAS 相比可能看起來很引人注目（改進的效能以及類似的安全性、可用性和可靠性等級），但它仍然是一種基於文件的方法，存在前面描述的所有問題。改進的性能並不能彌補額外的複雜性和成本。總儲存容量最大約為數百 PB。
分散式檔案系統：分散式檔案系統（DFS）是跨多台電腦或伺服器並且能夠以分散式方式儲存和存取資料的檔案系統。分散式檔案系統不是單一集中式系統，而是將資料分佈在多個伺服器或容器上，允許使用者存取和修改文件，就像在單一集中式檔案系統上一樣。
分散式檔案系統的一些熱門範例包括 Hadoop 分散式檔案系統 (HDFS)、Google 檔案系統 (GFS)、Amazon 彈性檔案系統 (EFS) 和 Azure Files。
檔案可以像上述基於檔案的解決方案一樣受到保護，因為作業系統提供了一個看起來像傳統檔案系統的介面。分散式檔案系統在提供可靠性的叢集中運作。與 SAN 相比，在叢集中運作可能會帶來更好的吞吐量；然而，當存在大量文件時（就像所有基於文件的解決方案一樣），它們仍然會遇到擴展問題。
物件儲存：物件儲存已經存在相當長一段時間了，但當 Amazon 在 2006 年透過簡單儲存服務 (S3) 使其成為第一個 AWS 服務時，物件儲存發生了革命性的變化。現代物件儲存是雲端原生的，其他雲端很快就將其產品推向市場。 Microsoft 提供 Azure Blob Storage，Google 則提供 Google Cloud Storage 服務。 S3 API 是開發人員與儲存和雲端互動的事實上的標準，並且有多家公司為公有雲、私有雲、邊緣和託管環境提供與 S3 相容的儲存。無論物件儲存位於何處，都可以透過 RESTful 介面存取。
與其他儲存選項相比，物件儲存最顯著的差異在於資料以平面結構儲存。儲存桶用於建立物件的邏輯分組。以 S3 為例，使用者先建立一個或多個儲存桶，然後將其物件（檔案）放入其中一個儲存桶中。一個桶子不能包含其他桶，一個檔案只能存在於一個桶中。這似乎是有限制的，但物件具有元數據，並且使用元數據，您可以模擬檔案系統中目錄和子目錄提供的相同級別的組織。
物件儲存解決方案在作為分散式叢集運作時也能表現最佳。這為他們提供了可靠性和可用性。
物件儲存在規模方面與眾不同。由於底層儲存的平坦位址空間（每個物件僅在一個桶中，且桶內沒有桶），物件儲存可以在潛在的數十億物件中快速找到物件。此外，物件儲存提供近乎無限的規模，可達 PB 級甚至更高。這使得它們非常適合儲存資料集和管理大型模型。
下面是一個儲存記分卡，顯示了針對需求的解決方案。
人工智慧的最佳儲存選擇
最終，儲存選項的選擇將綜合考慮需求、現實和必要性，但是，對於生產環境，物件儲存是有充分理由的。
原因如下：
- 大規模效能－現代物件儲存速度很快，即使面對數百 PB 和並發請求也能保持快速。您無法透過其他選擇來實現這一目標。
- 非結構化資料—許多機器學習資料集都是非結構化的—音訊、視訊和影像。即使是可以儲存在資料庫中的表格 ML 資料集，也可以在物件儲存中更輕鬆地進行管理。例如，工程師通常將構成訓練集的數千或數百萬行視為可以透過單一簡單請求儲存和檢索的單一實體。驗證集和測試集也是如此。
- RESTful API — RESTful API 已成為服務之間通訊的事實上的標準。因此，存在用於身份驗證、授權、運動安全性和通知的經過驗證的訊息傳遞模式。
- 加密– 如果您的資料集包含個人識別訊息，則必須在靜態時對您的資料進行加密。
- 雲端原生（Kubernetes 和容器） ——可以在 Kubernetes 管理的容器中運行其服務的解決方案，可以跨所有主要公有雲移植。許多企業都有內部 Kubernetes 集群，可以運行 Kubernetes 原生物件儲存部署。
- 不可變－實驗的可重複性非常重要，如果底層資料移動或被覆蓋，實驗就不可重複。此外，當世界各國政府開始監管人工智慧時，保護訓練集和模型不會被意外或故意刪除將成為人工智慧儲存系統的核心能力。
- 糾刪碼與 RAID 的資料彈性和可用性— 糾刪碼使用簡單的磁碟機來提供彈性儲存所需的冗餘。另一方面，RAID 陣列（由一個控制器和多個磁碟機組成）是另一種必須部署和管理的裝置類型。糾刪碼工作在物件級別，而 RAID 工作在區塊級別。如果單一物件損壞，糾刪碼可以修復該物件並使系統快速（幾分鐘內）恢復到完全運作狀態。 RAID 需要重建整個卷，然後才能讀取或寫入任何數據，重建可能需要數小時或數天，具體取決於驅動器的大小。
- 所需數量的文件– 許多用於訓練模型的大型數據集都是從數百萬個小文件創建的。想像一個擁有數千台物聯網設備的組織，每台設備每秒鐘都會進行一次測量。如果每個測量都是一個文件，那麼隨著時間的推移，文件總數將超過文件系統可以處理的數量。
- 可跨環境移植－軟體定義的物件儲存可以使用本機檔案、NAS、SAN 以及在 Kubernetes 叢集中使用 NVMe 磁碟機運作的容器作為其底層儲存。因此，它可以跨不同環境移植，並可以在任何地方透過 S3 API 提供對底層儲存的存取。
用於 ML 訓練和推理的 MinIO
MinIO 因其效能、規模、大規模效能和簡單性而成為 AI/ML 堆疊中的基礎元件。 MinIO 理想地配置在使用 NVMe 磁碟機的容器叢集中；但是，您可以根據需要選擇使用幾乎任何儲存配置。
實施軟體定義的雲端原生方法的一個優點是程式碼變得可移植。隨著 ML 項目從概念驗證到資助項目，最後到在叢集中提供預測服務的生產模型的成熟，訓練程式碼和模型服務程式碼不需要更改。
雖然可移植性和靈活性很重要，但如果以犧牲效能為代價，它們就毫無意義。 MinIO 的性能特徵眾所周知，並且全部作為基準發布。
後續步驟
開始新專案的研究人員應該在他們的工作站上安裝 MinIO。以下指南將幫助您入門。
如果您負責構成開發、測試和生產環境的集群，那麼請考慮新增 MinIO。
邊做邊學
開發人員和資料科學家越來越多地控制自己的儲存環境。 IT 部門嚴密保護儲存存取的日子已經一去不復返了。開發人員自然會傾向於軟體定義、開源、雲端原生且簡單的技術。這本質上將物件儲存定義為解決方案。
如果您要使用您最喜歡的 ML 工具設定新工作站，請考慮透過安裝本機解決方案將物件儲存新增至您的工具包。此外，如果您的組織具有用於實驗、開發、測試和生產的正式環境，請將物件儲存添加到您的實驗環境中。這是向組織中的所有開發人員介紹新技術的好方法。您也可以使用在此環境中運行的真實應用程式來執行實驗。如果您的實驗成功，請將您的應用程式推廣到開發、測試和生產。