「You Only Compute Once」：Clockwork 想如何終結 AI 訓練重新開始
請查看你的收件匣中的確認信，你可以在那裡調整偏好設定，甚至加入其他群組。
在你常用的社群媒體平台追蹤 TNS。
「You Only Compute Once」：Clockwork 想如何終結 AI 訓練重新開始
在規模夠大的 GPU 叢集上，總會有東西出問題。這就是現實。標準修法是回復到上一個檢查點，然後重新運算從那之後的所有內容，這既慢又昂貴。https://clockwork.io/ 想讓這種修法成為過去，而且它願意為此提出保證。
Clockwork 能防止故障中斷訓練執行，基礎在於 TorchPass，也就是 Clockwork 的容錯產品，該產品已在 3 月正式推出。當 GPU 或整個節點故障時，TorchPass 可以把訓練工作的記憶體中狀態，包括模型權重、梯度與最佳化器狀態，移到健康的備用 GPU，或是正在執行較低優先順序工作的 GPU，並讓工作持續執行，通常只需幾分鐘就能復原。
週三，該公司推出 YOCO Guarantee，也就是「You Only Compute Once」的縮寫。公司保證，在受支援的訓練執行中，90% 的故障都會在不損失進度、不回復檢查點、不重新運算的情況下解決。如果 Clockwork 在某個合約年度未達標，客戶可獲得下次續約或擴充費用 25% 的折抵。
「AI 團隊需要的是模型完成訓練，不是節點保持在線。」——Clockwork 執行長 Suresh Vasudevan。
Clockwork 執行長 Suresh Vasudevan 表示：「AI 團隊需要的是模型完成訓練，不是節點保持在線。業界一直在衡量節點正常運作時間，並把它稱為可靠性。YOCO 讓我們對唯一真正重要的事情負責：你的模型完成訓練。」
以即時遷移取代回復檢查點
Clockwork 的共同創辦人暨商務長 Dan Zheng 向 The New Stack 說明目前的現況：「如果你定期建立檢查點，然後某個環節出錯，你就得回到上一個檢查點；那可能是一小時、兩小時前。你必須重新計算。」
當然，這些重新計算的工作沒有一項是免費的。團隊必須為昂貴的 GPU 時間付費，重做已經做過的工作。
TorchPass 透過在工作仍在執行時移動它，避開這些回滾。「從很高層次來看，我喜歡把它想成幾乎像 vMotion，但這是給 GPU 用的，所以有點像 gMotion，」Zheng 說。他指的是 VMware 用來稱呼在不中斷服務的情況下，將執行中的虛擬機器在實體主機之間轉移的術語。
但這個替代資源當然必須從某個地方來。「如果其中一張 GPU 故障，而你可以存取一個備用節點，這可以是一個待命節點，也可以是一個正在跑低優先順序工作的節點，」Zheng 說。
團隊可以預留閒置節點作為專用備援；或者，為了避免替閒置 GPU 付費，也可以讓 TorchPass 從較低優先順序的工作中抽調一個節點，關閉那個工作，把該節點納入訓練叢集，並重建 GPU 之間的連線，讓這次執行從下一個步驟繼續，而不是回到上一個檢查點。
TorchPass 也不必等到東西真的壞掉才動作。當警訊已經出現時，它可以在故障前先移動工作。「如果溫度超過某個門檻，你就知道 GPU 遲早會故障，」Zheng 說。「那我為什麼不在還能存取 GPU 記憶體時先處理？」
如何啟用 TorchPass
TorchPass 有兩種模式，主要差異在於各自必須搬移多少狀態，以及因此能多快復原。
較快的選項具備模型感知能力；依 Zheng 的說法，只需要多寫幾行程式碼。這讓 TorchPass 能精準知道要抓取什麼，因此可以搬移較少資料，並在數十秒內復原。
另一種則是團隊所稱的「模型透明」模式。使用它時，訓練團隊不需要修改任何訓練程式碼。「我們可以擷取系統層級的快照，」Zheng 說。這是比較容易使用 TorchPass 的方式，但相對地，它會搬移更多資料，且需要幾分鐘才能復原。
不過，突發當機仍然是問題。畢竟 TorchPass 沒辦法替已經死亡的節點建立快照。針對這種情況，Clockwork 表示，它會從工作已經在執行中的健康資料平行副本，重建遺失 worker 的狀態；這些副本原本就是為了平行運算而存在。
TorchPass 也有它的限制，Zheng 也承認這點。他說：「如果整個網路都掛了，那你也無能為力。這就像整個停電一樣，沒有人能做什麼。」
一次失敗的執行真正要付出什麼代價
在大規模環境中，故障並不是罕見事件。Clockwork 的公告引用 Meta FAIR 團隊的研究指出，在一個 1,024 顆 GPU 的叢集上，平均故障間隔時間是 7.9 小時；到了 16,384 顆 GPU，則降到 1.8 小時。Clockwork 表示，結果就是 GPU 叢集實際上只跑出理論效能的 30% 到 50%。但團隊主張，瓶頸不在硬體，而是在硬體周邊的可靠性模型；這套模型假設故障遠比這些叢集實際遇到的情況少得多。
Clockwork 估計，在典型的 2,048 顆 GPU H200 部署中，由故障導致的重啟，每年會耗掉超過 600 萬美元的無效運算成本。
「不是給 Anthropic 和 OpenAI 用的」
Zheng 說：「這套解決方案不是給 Anthropic 和 OpenAI 用的，因為他們有足夠深厚的工程實力。也不是給 Google 用的。它真正是給其他所有人用的。」他指的是那些 AI 原生新創、企業，以及量化與生技團隊；這些團隊想要他所說的「前沿 AI 實驗室等級的韌性」，但不想自己打造。
隨著更多工作從預訓練轉向後訓練與強化學習，這個市場正在成長，也讓比一年前更多的團隊開始面對大型訓練工作。Clockwork 表示，其客戶已包括新型雲端（neocloud）業者 Nebius、Nscale 和 WhiteFiber，以及 DCAI，還有 Uber、Wells Fargo 等企業。
不過，市場認知仍在追趕中。Zheng 說：「我們談過的很多人太習慣檢查點重啟了，他們甚至不知道還有其他東西可以用。」
測試顯示了什麼
Clockwork 表示，最常見的替代方案其實就是維持現狀。團隊頻繁建立檢查點，然後在出問題時承擔重新計算的成本。
另一個是 TorchFT，這是 Meta 在 2024 年底釋出的開源框架。它的做法是在 GPU 故障時丟棄整個副本群組，讓工作在沒有該群組的情況下繼續執行，直到替換完成。Clockwork 表示，這種做法即使在沒有任何故障發生時，每一步也都會帶來額外開銷；該公司則把 TorchPass 定位為更輕量的選項，適合在數百到一兩千顆 GPU 上執行、故障不會每隔幾分鐘就發生的中等規模工作。
SemiAnalysis 對 TorchPass 做了一些獨立基準測試。
SemiAnalysis 技術團隊成員、ClusterMAX 基準測試主要作者 Jordan Nanos 表示：「供應商做一張投影片說自己的產品可行，和把這件事寫進合約裡，是很不一樣的。在我們的測試中，針對在 64 張 H200 組成的叢集上進行 GPT-OSS-120B 訓練，若以工作完成時間和 checkpoint-restart 相比，TorchPass 提供了最快、也最有效率的容錯效能。就這項工作而言，TorchPass 也在 MFU 和每 GPU 每秒 token 數上勝過 TorchFT，同時達到相同的復原時間。YOCO Guarantee 只是反映我們在測試中看到的結果，並把它變成合約承諾。」
可靠性作為軟體層
Zheng 說：「我喜歡回想我早期在 Google 的日子，例如 Google File System。你用的是通用的旋轉式硬碟，但從開發者的角度來看，你想要的是寫入一次，並確保資料會被持久保存。你不會在意資料中心裡是不是有人需要換一顆硬碟。」
他說：「我們也需要在軟體層建立這樣的韌性層，讓開發者或 AI 研究者能有更高的信心。你只要專注在訓練上，不必擔心基礎設施。」
可觀測性
Clockwork 最初來自一個任務和公司現況相當不同的專案：同步伺服器時鐘。但因為這也涉及非常精準地測量這些伺服器之間的延遲，團隊意識到，光是做這件事就能對叢集有很多了解。自那之後，公司持續擴展這方面的能力；值得注意的是，可觀測性至今仍然是 Clockwork 核心工作的一部分。
Zheng 表示，TorchPass 和 Clockwork 的監控工具彼此互補。他說：「它某種程度上和 TorchPass 相輔相成；只要辨識出問題，就可以進行遷移。」
這家公司近期許多新工作其實都投入在可觀測性上。Zheng 表示，它的機群監控工具現在可以把 fabric 問題追蹤到特定鏈路或交換器，而 Clockwork 正在和幾家大型雲端營運商試行這項能力。他說，只要夠早發現 GPU 效能劣化或鏈路壅塞，TorchPass 就能在故障真正發生前把工作移走。
由社群建立的路線圖、文章、資源與學習旅程，協助 開發者選擇自己的道路，並在職涯中持續成長。