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

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

一年前，乘著大模型的熱潮，Yi Tay 離開了工作 3 年多的谷歌，參與創(chuàng)辦了一家名為 Reka 的公司并擔任首席科學家，主攻大型語言模型。

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

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

文章發(fā)出后，得到了眾多技術創(chuàng)業(yè)者的議論和轉發(fā)。

連 Andrej Karpathy 也深有同感：

成熟的公司有專門的團隊維護集群。隨著規(guī)模的擴大，集群已經(jīng)脫離了工程學的范疇，變得更加生物化，因此需要專門負責「硬件健康」的團隊。

「照看」訓練運行是一項令人沮喪的訓練大型模型日常生活體驗。你需要仔細監(jiān)控運行的生命體征：損失峰值、數(shù)值問題、吞吐量、梯度規(guī)范、策略熵等。每當運行性能下降或趨于平穩(wěn)時（可能經(jīng)常發(fā)生），你都要快速查找堆棧跟蹤，看看發(fā)生了什么。你必須快速完成這項工作，否則可能會有 10000 個 GPU 閑置。通常，這是你從未見過的新的、奇特的、可怕的錯誤，所以你需要尋求幫助，看看是否有人能發(fā)現(xiàn)問題所在。

最嚴重的錯誤發(fā)生在凌晨 4 點。通常沒人能看到，所以你只能禁止一些看起來有點可疑的節(jié)點，并嘗試重新啟動運行。有時，運行失敗只是因為你當天沒有得到神的眷顧，所以你在啟動命令中加入了 while True: 循環(huán)。潛在的問題可能多種多樣，從某些 GPU 發(fā)熱過高、偶爾突然做錯乘法運算到某些路由器宕機導致網(wǎng)絡文件系統(tǒng) I/O 減少，再到數(shù)據(jù)中心的某個人在未溝通的維護過程中物理斷開電線連接。有的問題你甚至永遠不會知道。

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

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

現(xiàn)在，讓我們一起看看博客內(nèi)容：

LLM 時代的硬件彩票

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

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

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

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

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

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

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

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

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

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

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

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

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

GPU vs TPU

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

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

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

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

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

多集群設置的痛苦

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

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

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

目前，我們公司開發(fā)了許多內(nèi)部工作流程來緩解這些問題，并繼續(xù)朝著世界級實驗基礎設施的黃金標準邁進。(有人告訴我，對于非頂級 / 大型公司來說，這種簡陋的設置或多或少是一種常態(tài)）。

野生代碼

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

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

2）它們有點被棄用了；

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

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

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

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

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

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

少一點原則，多一點 Yolo

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

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

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