【新智元導讀】一家大模型初創公司從創立到訓練出大模型，要克服怎樣的難題？前谷歌科學家離職後創業一年，發文自述算力是訓練大模型的難點。
前谷歌大腦科學家Yi Tay去年3月離職後，創辦了一家初創公司。
創業一年，他發文表示「痛並快樂著」。
在這篇博文中，我討論了： 1. 在不同計算提供商中采購計算和差異的經驗。我們最大的發現/驚喜是差異超級不同，幾乎是人們可以獲得的「硬件彩票」！ 2. 討論「野外」基礎設施/代碼，並過渡到我在谷歌的習慣 3. 訓練模型時的新思維方式。
在整個創業過程中，他認爲最大的困難便是——算力稀缺、算力提供商差異巨大，讓大模型的訓練比預期要難得多。
對此，Yi Tay寫了一篇長文，自述了從0開始如何創辦一家公司，籌集資金、購買芯片，訓練出了能夠與Gemini pro/GPT 3.5，甚至超越其他LLM的模型。
Karpathy對此表示深刻地贊同：「這篇文章精彩地討論了一個鮮爲人知的話題：訓練LLM的難點」。
在大公司維護計算集群的時候，隨著規模擴大，集群管理更像是生物學而非工程學。
工程師需要像「保姆」一樣密切監控訓練過程，關注關鍵指標，一旦出現問題要及時排查，否則會浪費大量計算資源。
訓練常常因爲各種未知原因失敗，需要重啓嘗試。訓練大模型考驗整個計算系統的容錯能力，因此除了考慮性能和成本，還要評估整體服務質量和團隊效率。
接下來看看他是如何講述，自己一年來的創業曆程。
「野外」訓練LLM（由Dall-E生成）
LLM時代的硬件彩票
訓練模型的首要條件是獲取算力。這看起來很簡單易行。
然而，最大的驚喜是計算提供商的不穩定性，以及集群、加速器及其連接性的質量存在著巨大的差異。
人們總是認爲，這只是一個關于加速器選擇的問題/爭論（TPU還是GPU等等），所有的GPU集群都是平等的。
對我們來說，這很快被證明是錯誤的。
當我們對不同的服務提供商進行抽樣時，發現即使對于相同的硬件，即GPU（H100），硬件質量的差異也有很大差異。
請注意，這裏的硬件指的是整體集群質量，而不一定是芯片或加速器本身。就像「彩票」一樣。基本上：
並非所有硬件都是一樣的。不同硬件提供商的集群質量差異非常大，以至于要想訓練出好的模型需要付出多大的代價，這簡直就是在抽簽。簡而言之，LLM時代的硬件彩票。
更具體地說，我們從幾家計算供應商那裏租用了幾個集群，每個集群都有數百到數千個芯片。
我們已經看到了各種集群，從還可以的（只存在一些小問題，但只需花幾個小時的時間就能解決）到完全不可用的集群，每隔幾個小時就會因爲無數的原因而失敗。
具體地說，一些群集的節點每N小時出現一次故障，出現的問題包括布線問題（其中N小得不合理）、GPU硬件錯誤等。
更令人驚訝的是，同一提供商的每個群集在魯棒性方面也可能存在很大差異。
與此同時，即使其他一些群集可能具有更穩定的節點，它們也可能會受到I/O和文件系統不佳的影響，即使保存檢查點也可能導致超時或極長的時間消耗在群集利用率上。
其他一些計算源甚至需要完全不同的軟件層才能運行，並且對帶來自己代碼庫的團隊不友好——需要額外的遷移成本來運行實驗或大型工作。
凡事沒有什麽是十全十美的！但提供商的服務質量是參差不齊的。
最令人沮喪的是什麽？幾乎不可能真正提前判斷，特別是在萬事俱備的情況下，人們將獲得什麽樣的硬件，以及體驗的魯棒性/容錯性如何？
最重要的是，你也無法知道供應商是否只是未能按時交貨，將發貨推遲了幾個月，導致用戶滯留數周或數月，無法從其他來源采購。
有些供應商還會不小心，刪除你的檢查點。
我有沒有提到過，不同的集群會有不同的模型翻轉利用率（MFU）？
你也會得到一個不同的模型翻轉使用(Mfu)爲不同的集群！？如果不幸發現提供商的節點布線不良或出現其他問題，計算量浪費是無法忽視的。
在團隊成員開始跨集群傳輸大量數據的那一刻，如果系統的文件系統非常不理想，訓練運行的MFU就會下降。
每個服務提供商的售後服務也各不相同。有禮貌客氣的，有不冷不熱的，也有把每一件事都歸咎于用戶的套話。
總體而言，我們嘗試的每個集群都有自己的風格、鬥爭和失敗模式。
而且，似乎每個集群都需要針對自己的一組問題，使用熱修複程序。盡管如此，我們已經了解到故障安全是重要的，爲任何集群找到快速熱修複方案是關鍵所在。
在過去的幾個月裏，我們構建了這麽多，只是爲了確保東西是可用的，例如，圍繞監控、高效檢查點和各種其他優化的工具。
甚至，到了安裝我們的定制文件系統以實現可擴展數據存儲的程度——而這只是實際需要的冰山一角。
這些工具的組合帶來了大量的MFU改進，同時也最大限度地減少了面對糟糕的硬件時的停機時間。
GPU vs TPU
我們在Reka的大部分時間裏，都在用GPU對模型進行訓練。
就我個人而言，在谷歌Pre-Reka生活中，當涉及到LLM訓練時，我一直使用TPU。Cuda和NCCL對我來說是最陌生的東西。
與我在谷歌使用 TPU 的經曆相比，GPU 的故障率讓我完全大吃一驚。
事實上，我並不記得TPU即使在大型運行中失敗率很高。不過我不確定，自己是否只是因爲擁有出色的基礎架構和專門的硬件團隊才不知道這一點。
事實上，UL2-20B模型（在谷歌）的訓練是意外運行一個月來進行的。它從未失敗過。如果這是在GPU領域，它肯定會在最初的幾天內失敗。
也就是說，我認爲這可能更多地，取決于管理加速器的硬件團隊的能力，而不是底層芯片。
擁有良好的硬件支持（來自你的計算提供商）非常重要。而這在很大程度上取決于他們是否真正有能力，這強化了「硬件彩票」的概念。
GPU領域給人感覺很奇怪。感覺多節點訓練更像是事後才想到的，而不是作爲TPU pods艙上的一等公民進行的分布式訓練。
在GPU領域，感覺不同的提供商似乎以不同的方式對它們進行布線，以實現多節點訓練，這導致在不同地點如何完成工作的差異很大。
多集群設置的痛苦
我職業生涯的大部分時間都是在Google Infra上度過的，它主要運行在Borg、XManager和Colossus上。
因此，必須在不同的集群中實際設置新環境的概念，對我來說是陌生的。
在當今世界，擁有多個加速器池集群似乎是不可避免的，除非一個加速器池專門在一個地點建設大量加速器池。
更具體地說，GPU供應（或缺乏）也自然導致了這種集群式采購模式，在這種模式下，事物本質上是支離破碎的。
訓練大型模型還需要大量的數據，即使只是移動它們也會造成許多不便。同時，在超大規模複制數據通常也不是直截了當和令人望而卻步的。
顯然，最理想情況是建立某種編排層，它是專門將作業發送到不同的服務器而構建的。
我相信許多注重AI的大公司通常都有某種基礎設施，以提高人工智能研究人員的生活質量。
然而，對于一家精幹的新創業公司來說，在一開始就構建這種複雜而別致的ML訓練基礎設施是不可能的。
目前，我們最終開發了許多內部工作流來緩解其中許多問題，並正在繼續朝著世界級實驗基礎設施的黃金標准邁進。
「野外」代碼
我一直以來最喜歡的代碼庫是T5X和Mesh TensorFlow，但它們存在一些問題：
1) 它們在谷歌之外得不到太多支持，
2)它們有點不受歡迎
3)它們對我們團隊中非Xoogler的人不友好。
我們最終選擇了一些普通的，看起來很穩定，更受歡迎的（例如pytorch），團隊中的大多數人都更容易接觸到它。
在我最初的幾個月裏，我被pip、git、docker和所有這些野外的東西絆倒了。話又說回來，我不能100%確定在外部使用谷歌代碼庫會有多穩定或用戶友好。
坦率地說，我不得不說，外部代碼庫的質量遠遠落後于我在谷歌習慣的那些代碼庫。
主要是因爲谷歌內部的代碼庫往往是由ML大神自己編寫的（比如Noam Shazeer、Barret Zoph、Adam Roberts、Hyung Won Chung等），並且與我在外部嘗試過的代碼庫相比感覺更好。
特別是，當我涉足其他公司開發的東西時，我發現自己對代碼質量超級惱火。
此外，我從來不知道更改模型並行性的能力，並不是自動的（免費的），直到一些代碼庫要求我編寫一個轉換器來更改模型的並行性。對我來說，這肯定是個難得的時刻。
另一件令人驚訝的事情是，這些代碼庫對大規模編解碼器訓練，甚至prefixLM訓練的支持是如此之少。
爲此，盡管出于任何原因對GitHub問題提出了合理的要求，但即使是閃電般的關注也一直拒絕爲Prefix LM訓練提供支持。
少一點原則，多一點Yolo
系統地擴展模型通常需要一個人以有原則的方式從小到大，即分多個階段 （1B->8B->64B->300B等）進行實驗，並挑選獲勝者並不斷擴大參數規模。
在一家初創公司中，我們執行這些大規模掃描，以檢查超參數所需的計算機數量要少得多。
我們不得不多次運行Yolo，幸運的是結果很好。
最終，我們只用了較小規模和較短的燒蝕運行，即可獲得強大的21B Reka Flash和7B EDGE模型，以及我們即將推出的最大核心模型。
在運行次數非常有限的情況下，找到可靠的方案具有挑戰性，並且考慮到搜索空間極其巨大，需要立即更改許多變量。
爲了做到這一點，人們必須放棄大科技公司的系統性，而在很大程度上依賴「Yolo」、直覺和本能。
慶幸的是，我和團隊中的許多人，在我們的ML職業生涯中積累了相當多的這種直覺，以便在相當短的時間內將得到正確結果。
雖然我們以前的工作中訓練過非常好的模型，但在訓練基礎設施、數據、新想法的納入和其他環境問題上的差異仍然會導致結果上的巨大差異。
也就是說，強大的先驗有助于顯著減少搜索空間，這可能是我們能夠以如此少的試驗、資源和實驗來訓練真正強大的模型的最容易的解釋之一。
作者介紹---Yi Tay
Yi Tay目前是人工智能初創公司Reka的聯合創始人兼首席科學家。
這是一家專注于人工智能研究和産品的初創公司，旨在構建令人驚歎的生成式模型和推進AI研究。據介紹，目前Reka正在訓練先進的多模態AI模型。
在創立Reka之前，Yi Tay曾在谷歌大腦度過了精彩的3.3年，在那裏他爲許多業界定義的LLM做出了貢獻，如PaLM、UL2、Flan-2和Bard，以及多模態模型，如Pali-X和VIT-22B。
值得注意的是，Yi Tay也是PaLM-2和PaLM-2API建模的聯合負責人。
在Yi Tay擔任谷歌研究科學家期間，他發表的大部分作品都圍繞著Transformer展開，尤其是與效率、可伸縮性和架構研究相關的內容。---[新智元報導*編輯：桃子/來源: 新智元 ]
參考資料：https://www.yitay.net/blog/training-great-llms-entirely-from-ground-zero-in-the-wilderness
