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

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

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

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

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

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

連 Andrej Karpathy 也深有同感：

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

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

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

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

要是從基礎(chǔ)設(shè)施和硬件的角度來說，能媲美谷歌的團(tuán)隊(duì)還真是不多。

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

LLM 時(shí)代的硬件彩票

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

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

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

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

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

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

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

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

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

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

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

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

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

GPU vs TPU

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

與我在谷歌使用 TPU 的經(jīng)歷相比，GPU 的故障率讓我完全大吃一驚。事實(shí)上，我并不記得 TPU 發(fā)生過很多故障，即使是在大型運(yùn)行中也是如此，不過我不確定，自己是否只是因?yàn)閾碛谐錾幕A(chǔ)架構(gòu)和專門的硬件團(tuán)隊(duì)才不知道這一點(diǎn)。事實(shí)上，谷歌的 UL2 20B 模型是通過意外運(yùn)行一個(gè)月來訓(xùn)練的。如果是在 GPU 領(lǐng)域，它肯定會在最初幾天內(nèi)就失敗。

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

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

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

多集群設(shè)置的痛苦

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

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

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

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

野生代碼

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

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

2）它們有點(diǎn)被棄用了；

3）它們對我們團(tuán)隊(duì)中的非 xoogler 不友好。

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

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

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

另外，我從來不知道更改模型并行性的能力不是自動(dòng)（免費(fèi)）的，直到某些代碼庫要求我編寫一個(gè)轉(zhuǎn)換器來更改模型的并行性。對我來說，這絕對是一個(gè)「WTF 時(shí)刻」。

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

少一點(diǎn)原則，多一點(diǎn) Yolo

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

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

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