- US - English
- China - 简体中文
- India - English
- Japan - 日本語
- Malaysia - English
- Singapore - English
- Taiwan – 繁體中文
Invalid input. Special characters are not supported.
簡介：
幾十年來，軟體一直使用檢查點儲存系統狀態。這種方法既可以簡單地將記憶體中的資料塊轉儲到儲存裝置，也可以編寫一段程式碼中的某個部分，或將其作為確認一段程式碼或軟體已正確執行和測試的方法。
但在 AI 領域呢？ 我們從客戶和合作夥伴處瞭解到，在 AI 系統執行檢查點正成為一項挑戰，因此在這篇由三部分組成的 AI 檢查點系列部落格中，我們將首先探討一些基本原理以及它們的重要性。在第二篇部落格中，我們將討論檢查點的效能要求。最後，在第三篇部落格中，我們將介紹美光和 Lightbits 儲存裝置如何解決各種檢查點問題。
什麼是 AI 中的檢查點？
檢查點儲存 AI 訓練任務的狀態，一旦出現問題，可以從上次安全儲存資料的時間點重新開始訓練，避免從頭開始重新啟動任務。這就像在任何電玩遊戲中使用「儲存遊戲」選項一樣。
五年多來，AI 訓練一直是企業的重要工作負載，但是，為什麼我們現在要討論檢查點問題？ 答案有兩個方面。這與正在訓練的模型類型有關，也與訓練方式的基本原理之一有關。
轉換器模型的興起
轉換器模型在資料中心已無處不在。解釋轉換器模型不在本部落格的討論範圍之內，我們關注的主要影響是平行化的啟用。
轉換器模型（如 ChatGPT、Llama、Gemini 等）可以處理循序資料（如句子和段落），並將其轉化為可以在大量硬體上平行處理的向量。
對於以前的模型，在叢集中新增更多的 GPU 會很快導致訓練效能的回報遞減，而平行化的啟用導致了大型 AI 訓練叢集的爆炸式增長。（在本例中，「大型」指的是 1,000 台伺服器和 10,000 個 GPU。）
訓練的基本原理
讓我們把訓練分成幾個步驟：
- 訓練新資料（從資料中學習更新過的模型權重）
- 在所有 GPU 之間共享更新過的模型權重
現代訓練同步進行這兩個步驟，這意味著所有 GPU 在繼續訓練新資料之前會停止訓練以共享更新過的模型權重。標準訓練流程均以這種方式相互綁定，即如果任何元件在訓練期間出現故障，整個叢集都必須停止，並從之前的檢查點重新載入。
元件故障率
下一個難題是瞭解當我們增加可能發生故障的元件數量時，故障率的歸併情況。
為使統計資料有效，我們需要假定 GPU 在對一批資料進行訓練時不會發生故障。
所有這一切意味著，當我們估算叢集的故障率時，故障率是叢集規模的冪次。我們可以將其視覺化為故障前平均時間（MTTF）：
我們發現，隨著叢集規模的增加，MTTF 達到了驚人的低值。在使用 24,000 個加速器的情況下，我們估計每兩小時會發生一次故障。圖表最右側顯示，對於目前部署的超大叢集，MTTF 不到 30 分鐘。
為什麼儲存因素對檢查點很重要
現在我們對訓練及其流程有了更多瞭解，讓我們來看看一些真實情境。
以擁有 4,050 億個參數的開放式大型語言模型 Llama 3 為例，這類模型的檢查點大小約為 5TB。
假設我們希望在故障間隔進行 20 次檢查點檢查，以達到 95% 的良好叢集吞吐量。
這意味著，對於 MTTF 為 124 分鐘的 24,000 個加速器，我們將每 6 分鐘檢查一次。這樣，每天將進行 233 次檢查點檢查（每次 5TB），叢集每天將寫入 1.1 PB 的檢查點資料。以 24 小時的運行平均值計算，整個叢集需要 13 GB/s 的持續寫吞吐量。
從這個例子中，我們可以看出，檢查點取決於儲存裝置效能。這也是美光和 Lightbits 支持 MLPerf 儲存裝置基準套件（MLCommons 的一部分）的原因所在，其目的是建立基準以測試檢查點流程，並瞭解架構 AI 解決方案時對叢集和儲存裝置的要求。
結論和下一篇部落格
在第一篇部落格中，我們討論了為什麼檢查點是訓練中的一個重要因素，以及為什麼為檢查點提供高效能儲存解決方案非常重要。
請繼續關注本系列的下一篇部落格，我們將討論大規模（企業、雲端服務提供商和超大規模）的檢查點儲存要求。
如欲瞭解 Lightbits 和美光先進儲存裝置和記憶體解決方案的更多資訊，請瀏覽 www.lightbitslabs.com/micron/。
