Karpathy：中肯的，一針見血的。
如何在不到一年的時間裡創辦一家公司、籌集資金、購買晶片，並搭建出追趕 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 也深有同感：
成熟的公司有專門的團隊維護叢集。隨著規模的擴大，叢集已經脫離了工程學的範疇，變得更加生物化，因此需要專門負責「硬體健康」的團隊。
「照看」訓練執行是一項令人沮喪的訓練大型模型日常生活體驗。你需要仔細監控執行的生命體徵：損失峰值、數值問題、吞吐量、梯度規範、策略熵等。每當執行效能下降或趨於平穩時（可能經常發生），你都要快速查詢堆疊跟蹤，看看發生了什麼。你必須快速完成這項工作，否則可能會有 10000 個 GPU 閒置。通常，這是你從未見過的新的、奇特的、可怕的錯誤，所以你需要尋求幫助，看看是否有人能發現問題所在。
最嚴重的錯誤發生在凌晨 4 點。通常沒人能看到，所以你只能禁止一些看起來有點可疑的節點，並嘗試重新啟動執行。有時，執行失敗只是因為你當天沒有得到神的眷顧，所以你在啟動命令中加入了 while True: 迴圈。潛在的問題可能多種多樣，從某些 GPU 發熱過高、偶爾突然做錯乘法運算到某些路由器當機導致網路檔案系統 I/O 減少，再到資料中心的某個人在未溝通的維護過程中物理斷開電線連線。有的問題你甚至永遠不會知道。
也有人發現了亮點：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