「還是谷歌好」，離職創業一年，我才發現訓練大模型有這麼多坑

機器之心報道

編輯：蛋醬、小舟

如何在不到一年的時間裡創辦一家公司、籌集資金、購買芯片，並搭建出追趕 Gemini pro/GPT 3.5 的 LLM？

很多人都對構建基礎架構和訓練大語言模型和多模態模型感到好奇，但真正走完「從零開始」這一流程的人很少。我們普遍認爲，儲備技術人才是前提，掌握核心算法是關鍵，但實際上，工程實踐中冒出來的挑戰，也實在令人頭疼。

一年前，乘着大模型的熱潮，Yi Tay 離開了工作 3 年多的谷歌，參與創辦了一家名爲 Reka 的公司並擔任首席科學家，主攻大型語言模型。

在谷歌時，Yi Tay 參與過許多知名的大型語言模型和多模態模型工作，包括 PaLM、UL2、Flan-U-PaLM、LaMDA/Bard、ViT-22B、PaLI、MUM 等。即使經驗如此深厚，他還是遇到了以往無法想象的困難。爲了幫助更多創業者避雷，Yi Tay 在一篇博客中分享了自己踩過的那些「坑」。

「計算稀缺和不可靠的計算提供商使事情比預期困難得多，但我們憑藉強大的技術實力渡過了難關。終於，我寫了這篇博文，揭示了其中的一些挑戰和經驗教訓。我希望這篇文章對很多人來說都是有趣或有教育意義的。」

文章發出後，得到了衆多技術創業者的議論和轉發。

連 Andrej Karpathy 也深有同感：

也有人發現了亮點：Yi Tay 所說的「荒野」（Wild）意思是「谷歌之外的公司」。

要是從基礎設施和硬件的角度來說，能媲美谷歌的團隊還真是不多。

現在，讓我們一起看看博客內容：

LLM 時代的硬件彩票

訓練模型的首要條件是獲得計算能力。這看似簡單易行，然而，最大的驚喜卻是計算提供商的不穩定性，以及集羣、加速器及其連接質量因來源不同而存在的巨大差異。

人們總以爲這只是一個加速器選擇的問題 / 爭論（TPU 與 GPU 等），所有 GPU 集羣都是一樣的。我們的體驗是，這很快就被證明是錯誤的。

我們對不同的服務提供商進行了抽樣調查，發現即使是相同的硬件，即 GPU（H100），硬件質量的差異也非常大。請注意，這裡的硬件指的是集羣的整體質量，而不一定是芯片或加速器本身。整體感覺就像購買彩票一樣。

更具體地說，我們從幾家計算提供商那裡租用了幾個集羣，每個集羣都有數百到數千個芯片。我們所見過的集羣有的還過得去（只存在一些小問題，但只需花幾個小時的時間就能解決），有的則完全無法使用，每隔幾個小時就會因各種原因出現故障。具體來說，有些集羣的節點每隔 N 個小時就會出現故障，問題包括佈線問題（N 小得不合理）、GPU 硬件錯誤等。更令人驚訝的是，同一家提供商的每個集羣在魯棒性方面也可能存在巨大差異。

同時，即使其他一些集羣的節點明顯更穩定，它們也可能存在 I/O 和文件系統不佳的問題，甚至連保存檢查點都可能導致超時，或耗費大量時間來降低集羣利用率。其他一些計算資源甚至需要完全不同的軟件層才能運行，而且對自帶代碼庫的團隊不友好 — 運行實驗或大型工作需要額外的遷移成本。

凡事都不會盡善盡美，但可以確定的是，提供商的服務質量是參差不齊的。

最令人沮喪的是什麼？幾乎不可能真正提前知道，尤其是在萬事俱備的情況下，會得到什麼樣的硬件，以及體驗會有多麼強大 / 容錯性如何。

此外，如果供應商不能按時交貨，將裝備時間推遲幾個月，導致用戶在數週或數月內無法從其他來源採購，你更無從得知。有些供應商還會不小心刪除你的檢查點。

我有沒有說過，不同的集羣會有不同的模型翻轉利用率（MFU）？如果你不幸找到了一個節點佈線不良或存在其他問題的提供商，那麼浪費的計算量是不可忽視的。如果系統的文件系統非常不理想，那麼當團隊成員開始跨集羣傳輸大量數據時，訓練運行的 MFU 就會下降。

每個服務提供商的售後水平也各不相同。從禮貌客氣到不冷不熱，從「對話式」的預製回覆到將所有問題都歸咎於用戶，不一而足。

總之，我們嘗試過的每一個集羣都有自己的風格、鬥爭和失敗模式。而且，幾乎每個集羣都需要自己的熱修復程序來解決一系列問題。儘管如此，我們還是認識到故障安全是非常重要的，爲任何集羣找到快速的熱修復方案都是關鍵所在。

在過去的幾個月裡，我們構建了許多工具，以確保一切都可用，例如，圍繞監控、高效檢查點和其他各種優化的工具，甚至安裝了我們的自定義文件系統，以實現可擴展的數據存儲，而這只是實際需求的冰山一角。

這些工具的組合爲 MFU 帶來了非同小可的改進，同時也最大限度地減少了在硬件條件惡劣的情況下的停機時間。

GPU vs TPU

就我自己的公司來說，大部分時間都在使用 GPU 訓練模型。不過在加入 Reka 之前，我在谷歌的大型語言模型訓練中一直使用 TPU。CUDA 和 nccl 對我來說是最陌生的東西 (我是從一位曾在 Nvidia 工作的同事那裡才知道它的發音是 Nickel 的）。

與我在谷歌使用 TPU 的經歷相比，GPU 的故障率讓我完全大吃一驚。事實上，我並不記得 TPU 發生過很多故障，即使是在大型運行中也是如此，不過我不確定，自己是否只是因爲擁有出色的基礎架構和專門的硬件團隊纔不知道這一點。事實上，谷歌的 UL2 20B 模型是通過意外運行一個月來訓練的。如果是在 GPU 領域，它肯定會在最初幾天內就失敗。

話雖如此，我認爲這可能更多與管理加速器的硬件團隊的能力有關，而不是底層芯片。擁有良好的硬件支持（來自計算提供商）非常重要。而這在很大程度上取決於他們是否真的有能力，於是，又印證了「硬件彩票」的概念。

GPU 領域給人的感覺很奇怪。與分佈式訓練在 TPU pods 上的一等公民地位相比，多節點訓練更像是一種事後考慮。在 GPU 領域，感覺就像不同的提供商以不同的方式將它們連接起來，以實現多節點訓練，這導致不同地方的做法差異很大。

雖然我不是硬件專家，但這就是我的真實印象。

多集羣設置的痛苦

我職業生涯的大部分時間都是在谷歌基礎架構上度過的，這些基礎架構主要運行在 Borg、Xmanager 和 Colossus 上。因此，必須在不同的集羣中建立新環境的概念對我來說非常陌生。

在當今時代，擁有多個加速器池集羣似乎是不可避免的，除非專門在一個地點建立大量的加速器池。更具體地說，GPU 的供應（或供應不足）自然而然地造成了這種集羣採購模式，在這種模式下，事物的性質是支離破碎的。訓練大型模型還需要大量的 TB 級數據，即使只是移動數據也會帶來諸多不便。同時，複製數據通常也不是一件簡單的事情，而且在超大規模的情況下，複製數據的成本也很高。

顯然，最理想的情況是建立某種編排層，專門將作業發送到不同的服務器。我相信，許多注重人工智能的大公司一般都有某種基礎設施，以提高研究人員的生活質量。但是，對於一家初創公司來說，在開始階段建立這種複雜而花哨的 ML 訓練基礎設施其實是不可能的。

目前，我們公司開發了許多內部工作流程來緩解這些問題，並繼續朝着世界級試驗基礎設施的黃金標準邁進。(有人告訴我，對於非頂級 / 大型公司來說，這種簡陋的設置或多或少是一種常態）。

野生代碼

衆所周知，一直以來我最喜歡的代碼庫是 T5X 和 Mesh Tensorflow，但它們有一些缺點：

1）它們在 Google 之外沒有得到那麼多的支持；

2）它們有點被棄用了；

3）它們對我們團隊中的非 xoogler 不友好。

我們最終選擇了一些普通的、看似穩定且更流行的東西，即 pytorch。pytorch 對團隊中的大多數人（除了我）來說更容易使用。

在最初的幾個月裡，我對 pip、git、docker 和所有「野生(wild)」的東西感到困惑。話又說回來，我不能 100% 確定在外部使用 google 代碼庫有多穩定或對用戶友好。

坦率地說，外部代碼庫的質量明顯落後於我在谷歌習慣使用的代碼庫。主要是因爲谷歌內部的代碼庫往往是由 ML 大牛自己編寫的（例如 Noam Shazeer、Barret Zoph、Adam Roberts、Hyung Won Chung 等人），並且與我在外部嘗試過的代碼庫相比感覺更好。

另外，我從來不知道更改模型並行性的能力不是自動（免費）的，直到某些代碼庫要求我編寫一個轉換器來更改模型的並行性。對我來說，這絕對是一個「WTF 時刻」。

令人驚訝的是，這些代碼庫對大規模編碼器 - 解碼器訓練甚至 prefixLM 訓練的支持非常少。

少一點原則，多一點 Yolo

系統地擴展模型通常需要有原則地從小到大，即分多個階段（1B→8B→64B→300B 等）進行實驗，然後選出獲勝者並不斷擴展它們。在初創公司中，我們執行大規模掃描來檢查超參數的計算量要少得多。最後，我們不得不多次運行 Yolo，幸運的是結果很好。

最終，我們只需要極少數的較小規模和較短的燒蝕運行即可獲得強大的 21B Reka Flash 和 7B 邊緣模型，以及我們即將推出的最大核心模型。在運行次數非常有限的情況下找到可靠的方案具有挑戰性，並且考慮到搜索空間極其巨大，需要立即更改許多變量。爲了做到這一點，人們必須放棄大型科技公司的系統性，而在很大程度上依賴「Yolo」、直覺和本能。

值得慶幸的是，我以及我們團隊中的許多人在我們的 ML 職業生涯中已經積累了相當多的「直覺」，可以在很短的嘗試時間內得到正確的結果。雖然我們在之前的工作中訓練過非常好的模型，但訓練基礎設施、數據、新想法的融合和其他環境問題的差異仍然可能導致結果的巨大差異。也就是說，強大的先驗有助於顯著減少搜索空間，這可能就是我們能夠通過如此少的試驗、資源和實驗訓練出真正強大的模型的原因之一。

原文鏈接：https://www.yitay.net/blog/training-great-llms-entirely-from-ground-zero-in-the-wilderness