瀏覽次數(shù)： 時間：2024-12-16 04:15:33
凱發(fā)k8國際廳登錄從裸機(jī)到70B大模型：基礎(chǔ)設(shè)施設(shè)置與腳本今年6月，大模型公司Imbue依托它們自主構(gòu)建的基礎(chǔ)設(shè)施，從零起步，成功訓(xùn)練出一個70B參數(shù)的模型，其在相關(guān)推理任務(wù)上的卓越表現(xiàn)遠(yuǎn)零樣本GPT-4o。
》一文中，他們分享了用于模型評估的數(shù)據(jù)集，包含11個公共數(shù)據(jù)集的高質(zhì)量子集，以及一套用于代碼理解的原始問題。重點(diǎn)分享了為什么選擇這些特定的數(shù)據(jù)集，以及數(shù)據(jù)創(chuàng)建過程和實(shí)際數(shù)據(jù)集的詳細(xì)信息。
除了經(jīng)驗(yàn)教訓(xùn)外，他們還分享了為確保主機(jī)健康而自主開發(fā)的大量基礎(chǔ)設(shè)施腳本，旨在幫助其他團(tuán)隊(duì)更便捷地為自己的模型訓(xùn)練創(chuàng)建穩(wěn)定的基礎(chǔ)設(shè)施。
一個用于為InfiniBand網(wǎng)絡(luò)結(jié)構(gòu)生成全面預(yù)熱工作負(fù)載的腳本，目的是測試每一個可用的鏈路。
我們的計(jì)算目標(biāo)在于實(shí)現(xiàn)大規(guī)模語言模型的快速實(shí)驗(yàn)。為此，我們需要大量高速GPU，并確保它們能夠以高速相互通信。
本文重點(diǎn)介紹一個由511臺服務(wù)器構(gòu)成的集群，其中部署了4088枚H100 GPU，均勻分布在每臺服務(wù)器上，每臺服務(wù)器搭載8個GPU?？紤]到統(tǒng)一網(wǎng)絡(luò)結(jié)構(gòu)管理節(jié)點(diǎn)對連接的需求，保留了部分連接并且用于管理 InfiniBand 網(wǎng)絡(luò)。
在這511臺配置了GPU的主機(jī)中，每個GPU均直接連接到一塊 ConnectX-7 卡。這塊卡具備高效的數(shù)據(jù)交換能力，通過自身的 ConnectX-7 卡，能夠以400 Gbps的速度向InfiniBand網(wǎng)絡(luò)中的其他任何GPU發(fā)送和接收數(shù)據(jù)，從而確保了集群內(nèi)部的高速數(shù)據(jù)流通。
我們的InfiniBand網(wǎng)絡(luò)拓?fù)浔环Q為“完全非阻塞（fully non-blocking）”，因?yàn)槔碚撋厦總€GPU均能實(shí)現(xiàn)與其他GPU的最大速率通信。這是通過三層InfiniBand網(wǎng)絡(luò)架構(gòu)實(shí)現(xiàn)的：當(dāng)正確連接時，三層InfiniBand交換機(jī)能夠在整個網(wǎng)絡(luò)上實(shí)現(xiàn)這種高水平的吞吐量。請參閱下方的InfiniBand網(wǎng)絡(luò)概述：
請注意，訓(xùn)練網(wǎng)絡(luò)的通信是通過InfiniBand而非以太網(wǎng)進(jìn)行的。盡管這些計(jì)算機(jī)也連接到了以太網(wǎng)，但該網(wǎng)絡(luò)主要用于傳輸數(shù)據(jù)集、檢查點(diǎn)和其他數(shù)據(jù)。如果通過以太網(wǎng)發(fā)送數(shù)據(jù)將會非常緩慢，因?yàn)閿?shù)據(jù)需要首先從GPU傳輸?shù)紺PU，然后再通過一根100 Gbps的以太網(wǎng)卡發(fā)送。
技術(shù)在以太網(wǎng)上進(jìn)行訓(xùn)練，但在硬件和軟件兩方面都需要大量額外工作，并且通常比InfiniBand更不可靠（詳情參見論文(
輔助以太網(wǎng)絡(luò)，它允許訪問基本輸入/輸出系統(tǒng)（BIOS）、電源供應(yīng)以及其他底層計(jì)算機(jī)接口的控制界面。如果沒有這個管理網(wǎng)絡(luò)，我們就必須手動使用USB驅(qū)動器、鍵盤和顯示器來設(shè)置我們的節(jié)點(diǎn)，這對于成百上千臺機(jī)器而言，顯然不是一個高效且可持續(xù)的解決方案。
使用我們的集群進(jìn)行高性能訓(xùn)練意味著每個組件——InfiniBand、以太網(wǎng)、GPU以及節(jié)點(diǎn)本身——都必須近乎完美地協(xié)同工作。如果超過12000個連接中的任何一個稍微不穩(wěn)定，都可能拖慢整個訓(xùn)練過程的進(jìn)度。本文剩余部分將詳細(xì)闡述實(shí)現(xiàn)所有組件完美運(yùn)行的過程，并確保其持續(xù)穩(wěn)定運(yùn)行的方法。
在成功建立管理網(wǎng)絡(luò)與集群之間的初始以太網(wǎng)絡(luò)連接后，我們獲得了對主板管理控制器（BMC）的訪問權(quán)限。BMC作為一種專業(yè)化服務(wù)處理器，能夠?qū)χ鳈C(jī)系統(tǒng)進(jìn)行實(shí)時監(jiān)控，并通常與一個獨(dú)立網(wǎng)絡(luò)相連接。這使得我們能夠如同身臨其境般地操控每一臺計(jì)算機(jī)，同時提供了豐富的API接口，涵蓋了硬件健康狀況的監(jiān)控、BIOS配置的調(diào)整以及電源管理的全面控制。有了這些組件，我們卷起袖子開始設(shè)置集群。
我們首先使用iDRAC（戴爾的主板管理控制器）在一臺服務(wù)器上安裝Ubuntu 22.04，該服務(wù)器將用于設(shè)置其他所有內(nèi)容。除此之外，iDRAC還允許我們從本地計(jì)算機(jī)掛載并從ISO鏡像啟動，瀏覽器中提供了一個虛擬控制臺。理想狀態(tài)下，這將是此過程中唯一的手動安裝步驟。
在完成首臺目標(biāo)服務(wù)器的部署后，我們繼續(xù)安裝Ubuntu的Metal-as-a-Service（MAAS）軟件，以便配置剩余的服務(wù)器。通過PXE（預(yù)啟動執(zhí)行環(huán)境）啟動機(jī)制和iDRAC的自動化工具，我們通過指令讓所有服務(wù)器從網(wǎng)絡(luò)啟動，并確保MAAS能夠響應(yīng)PXE啟動請求。在執(zhí)行初始網(wǎng)絡(luò)啟動時，服務(wù)器無需在本地存儲上安裝任何軟件，即可通過DHCP（動態(tài)主機(jī)配置協(xié)議）從MAAS獲取IP地址并加載初始內(nèi)核。隨后，這個基礎(chǔ)系統(tǒng)環(huán)境自動用于執(zhí)行持久的操作系統(tǒng)安裝。
然而，在實(shí)際操作中，由于MAAS與BMC的集成不夠穩(wěn)定，我們不得不提前通過iDRAC API收集每臺服務(wù)器的MAC地址（作為唯一的硬件標(biāo)識符），以便進(jìn)行后續(xù)的管理
例如，在最初的配置嘗試中，時間同步偏差異常嚴(yán)重，導(dǎo)致HTTPS證書驗(yàn)證失敗，從而阻礙了通過apt進(jìn)行軟件安裝。
進(jìn)一步來說，MAAS服務(wù)器需承擔(dān)多重角色——從DHCP和DNS服務(wù)，到HTTP代理、NTP服務(wù)、cloud-init配置管理，以及維護(hù)MAC地址與IP、主機(jī)名和自定義元數(shù)據(jù)之間關(guān)聯(lián)的基礎(chǔ)真實(shí)數(shù)據(jù)庫——這使得我們難以定位問題的根本源頭。
此外，MAAS的生命周期管理學(xué)習(xí)曲線同樣陡峭，因?yàn)樗荚谔幚砣虏渴鸬膹?fù)雜性，支持節(jié)點(diǎn)的逐步遷移，并應(yīng)對各種調(diào)試/不健康的中間狀態(tài)。
在設(shè)置大型GPU集群的過程中，我們發(fā)現(xiàn)大約有10%的機(jī)器無法啟動，這主要是由于服務(wù)器物理問題造成的。我們遇到的一些問題包括：未連接或接線錯誤的以太網(wǎng)電纜、iDRAC硬件故障、損壞的電源單元、不良的NVME（非易失性內(nèi)存表達(dá)式）驅(qū)動器、缺失的內(nèi)部連線，以及網(wǎng)絡(luò)卡或GPU無法識別。
我們對這些問題進(jìn)行了自動化檢查，將一些機(jī)器送回戴爾進(jìn)行重新測試，并為數(shù)據(jù)中心工作人員提交了相應(yīng)的工單。自己搭建集群的優(yōu)勢在于，我們能夠立即將健康的機(jī)器投入使用，同時等待其他機(jī)器維護(hù)工作的完成。
在所有非操作系統(tǒng)驅(qū)動器上配置RAIDZ ZFS存儲池（這使機(jī)器能夠在一塊驅(qū)動器故障的情況下繼續(xù)運(yùn)行，同時提供免費(fèi)的透明壓縮功能，這對于純文本數(shù)據(jù)集和重復(fù)性日志特別有用，使我們能夠常規(guī)性地利用比原本多約10倍的空間）。
隨后，我們執(zhí)行了基本的GPU診斷以確認(rèn)GPU的總體功能狀態(tài)——那些功能不正常的GPU通常會在數(shù)小時內(nèi)出現(xiàn)硬件問題。
在此期間，我們嘗試對所有400個節(jié)點(diǎn)并行部署軟件包時，遭遇了帶寬瓶頸。同時，這也是我們首次在數(shù)據(jù)中心部署期間接收到關(guān)于各組件的高溫警報(bào)。針對首batch出現(xiàn)的散熱問題，我們主要通過固件升級的方式進(jìn)行了有效解決。
1.針對GPU相關(guān)的錯誤，我們主要通過重新插卡進(jìn)行了修復(fù)：首先，物理地將重達(dá)200磅的服務(wù)器從機(jī)架上滑出，接著拆除了蓋板與GPU之間的所有連線，隨后將GPU從插槽中取出并重新安裝，最后恢復(fù)所有連線并重新將服務(wù)器放回機(jī)架。
2.根據(jù)Ubuntu服務(wù)器日志顯示，GPU與PCIe（外圍組件互連Express）總線或網(wǎng)絡(luò)卡之間的數(shù)條連線出現(xiàn)了“帶寬限制：
在完成PCIe交換總線固件更新后，我們發(fā)現(xiàn)在集群中約有四分之一的主機(jī)需要重新配置內(nèi)部PCIe總線。
這一現(xiàn)象可能是因?yàn)檫@些較為脆弱的連線被安置在機(jī)箱與GPU之間，導(dǎo)致在執(zhí)行GPU維護(hù)操作時，這些連線容易受到震動或被意外拔除。
在Linux系統(tǒng)中，硬盤驅(qū)動以隨機(jī)順序出現(xiàn)，這一現(xiàn)象導(dǎo)致MAAS服務(wù)混淆，導(dǎo)致操作系統(tǒng)被安裝到了錯誤的驅(qū)動上。
錯誤的溫度讀數(shù)，導(dǎo)致風(fēng)扇一直以100%的功率旋轉(zhuǎn)。此問題部分源于所使用的NVIDIA驅(qū)動程序存在缺陷。我們已通過降級至先前的驅(qū)動程序版本，成功解決了驅(qū)動相關(guān)的問題。
直接GPU-GPU 通信（GDR，或 GPUDirect RDMA Peer Memory Client）無法成功應(yīng)用。
InfiniBand的優(yōu)勢在于集中式架構(gòu)，這意味著整個網(wǎng)絡(luò)由一個控制中心管理。因此，我們僅需與單一實(shí)體進(jìn)行交互，即可管理和配置320個網(wǎng)絡(luò)交換機(jī)。我們的首要任務(wù)是識別每個交換機(jī)和與其連接的設(shè)備，將這一信息與布線圖相匹配，并依據(jù)其實(shí)際物理位置對交換機(jī)進(jìn)行重命名。
最初，UFM無法檢測出320個網(wǎng)絡(luò)交換機(jī)，更不用說識別網(wǎng)絡(luò)中預(yù)期部署的所有主機(jī)。經(jīng)過與數(shù)據(jù)中心合作伙伴的深入溝通，我們確認(rèn)交換機(jī)均已開啟且連接無誤，但仍無法被系統(tǒng)檢測。
在檢查網(wǎng)絡(luò)布線清單時，我們發(fā)現(xiàn)網(wǎng)絡(luò)頂層設(shè)計(jì)有誤：原本應(yīng)是一個統(tǒng)一的網(wǎng)絡(luò)結(jié)構(gòu)，卻分成了八個獨(dú)立網(wǎng)絡(luò)，彼此之間缺乏共同的路由路徑。在重新布線連接后，我們實(shí)施了檢查流程，確保所有物理連接與新設(shè)計(jì)保持一致。
在解決了物理布線的困擾之后，統(tǒng)一網(wǎng)絡(luò)結(jié)構(gòu)管理器（UFM）順利地與網(wǎng)絡(luò)中所有InfiniBand交換機(jī)建立了鏈接。然而，幾乎每一個交換機(jī)端口都開始報(bào)告過高的溫度讀數(shù)，即便在數(shù)據(jù)傳輸尚未啟動的情況下，溫度有時竟高達(dá)70攝氏度。
我們發(fā)現(xiàn)這一現(xiàn)象的根源在于同一網(wǎng)絡(luò)機(jī)架內(nèi)的各個交換機(jī)之間存在著空隙，導(dǎo)致熱空氣在機(jī)架內(nèi)部循環(huán)流動，最終又回流至前端區(qū)域。為了解決這一問題，我們數(shù)據(jù)中心的合作伙伴迅速協(xié)助我們定診斷了故障原因，并研發(fā)出一套行之有效的應(yīng)對方案。
許多端口也表現(xiàn)出高錯誤率，或是在正常工作與故障之間波動，這種狀況業(yè)內(nèi)被稱作“抖動（flapping）”。
這些問題僅在端口活躍運(yùn)作時才會顯現(xiàn)，因此提前檢測變得極具挑戰(zhàn)性，因?yàn)檎麄€網(wǎng)絡(luò)由10,000個具有高度冗余的連接構(gòu)成。
數(shù)據(jù)中心的合作伙伴幫助我們清理并重新安裝了警報(bào)端口，同時，在等待替換部件期間，我們停用了剩余的警報(bào)收發(fā)器。
盡管InfiniBand對硬件故障具有極高的容錯率，但一旦大約10%的網(wǎng)絡(luò)結(jié)構(gòu)開始出現(xiàn)故障，自適應(yīng)路由等特性就難以可靠地工作，從而無法有效地應(yīng)對鏈路隨機(jī)中斷的情況。
在此期間，我們成功實(shí)施了包含100至200臺機(jī)器的多節(jié)點(diǎn)訓(xùn)練任務(wù)。我們的流程主要基于現(xiàn)場發(fā)揮：我們有時會在隨機(jī)選擇的節(jié)點(diǎn)上啟動訓(xùn)練，觀察其性能表現(xiàn)，并盡可能讓更多的節(jié)點(diǎn)保持運(yùn)行狀態(tài)。這種方法使我們能夠識別出InfiniBand網(wǎng)絡(luò)結(jié)構(gòu)中可靠的子網(wǎng)絡(luò)，但同時也存在一定的挑戰(zhàn)，因?yàn)槊看胃挠糜谟?xùn)練的節(jié)點(diǎn)集時，InfiniBand鏈路的默認(rèn)配置也會隨之改變。
為了更高效地診斷InfiniBand的問題，我們針對整個集群量身定制了一個專門工作負(fù)載，該工作負(fù)載同時在整個fabric的每個端口上盡可能多地傳輸數(shù)據(jù)。
工作負(fù)載截然不同，后者會通過NCCL在服務(wù)器PCIe模塊（SXM）插槽，讓GPU通過NVLink進(jìn)行通信，從而優(yōu)化單個節(jié)點(diǎn)內(nèi)部的GPU間通信。
故障。到一天運(yùn)結(jié)束時，所有保持運(yùn)行的端口都被認(rèn)為足夠穩(wěn)健，可以繼續(xù)使用，而其余的端口則被停用或進(jìn)行后續(xù)的維修。
為了實(shí)現(xiàn)GPU之間能夠通信且無需產(chǎn)生CPU計(jì)算開銷，我們啟用了名為GPUDirect RDMA的功能，該功能允許GPU直接與InfiniBand網(wǎng)絡(luò)卡進(jìn)行通信。這一過程涉及兩個關(guān)鍵步驟：
然而，一個常被忽視的關(guān)鍵細(xì)節(jié)是：并非每臺機(jī)器都有相同的3%故障概率；實(shí)際上，只有少數(shù)幾臺“問題”機(jī)器會不斷以各種形式出現(xiàn)故障，直到它們被徹底修復(fù)。這一點(diǎn)突顯了在單一fabric上部署大量機(jī)器的優(yōu)勢。與其在我們的大規(guī)模訓(xùn)練運(yùn)行中隨機(jī)應(yīng)對“打地鼠”式的故障，我們轉(zhuǎn)而致力于構(gòu)建一個由已知可靠機(jī)器組成的集合，這些機(jī)器被稱為“黃金”機(jī)器。
InfiniBand的維護(hù)主要涉及響應(yīng)UFM警報(bào)、更換故障的電纜和收發(fā)器，以及偶爾診斷更棘手的錯誤，例如故障的交換機(jī)。大規(guī)模性能退化通常由兩個因素引起：
固件更新，尤其是當(dāng)這種更新僅針對一般集群進(jìn)行時，可能會破壞UFM的狀態(tài)，并導(dǎo)致所有InfiniBand交換機(jī)上的UFM都需要重啟。
同時進(jìn)行的大規(guī)模GPU服務(wù)器重啟，可能會向UFM狀態(tài)中涌入大量更新數(shù)據(jù)，從而同樣引發(fā)對UFM服務(wù)的重啟需求。
請注意，這些運(yùn)行狀況檢查大多針對我們特定的運(yùn)行環(huán)境，并不一定關(guān)聯(lián)基礎(chǔ)硬件，或者修復(fù)和自動化起來極為簡便。這是有意為之的設(shè)計(jì)：為了實(shí)現(xiàn)機(jī)器能夠訓(xùn)練這一總體目標(biāo)，我們希望有一個單一的入口點(diǎn)，它能給出“可以”或“不可以”的明確答復(fù)，并抽象掉所有那些“瑣碎”的細(xì)節(jié)。
我們檢查了GPU的數(shù)量是否準(zhǔn)確無誤，確認(rèn)ECC（錯誤糾正碼）檢查功能已激活，并確保沒有檢測到任何ECC錯誤。此外，我們還對連接GPU之間的NVLink拓?fù)浣Y(jié)構(gòu)進(jìn)行了檢查，確保其穩(wěn)定運(yùn)行且無任何故障。
我們確保了Docker能夠運(yùn)行配備GPU的容器（即NVIDIA容器運(yùn)行時工作正常），同時所有用于監(jiān)控/分析的相關(guān)Docker容器均處于活躍狀態(tài)，并且配置了正確的主機(jī)權(quán)限。
我們檢查了dmesg日志，確保其中沒有出現(xiàn)硬件Xids或SXid錯誤（這是NVIDIA GPU或GPU間NVIDIA交換拋出的故障）。同時，我們還仔細(xì)審查了所有的dmesg日志條目，確保它們都能被歸入我們列出的“常規(guī)/預(yù)期日志條目”類別中。
我們檢查了機(jī)器上的iDRAC錯誤，并忽略了非致命錯誤信息。這一檢查過程是針對戴爾服務(wù)器設(shè)計(jì)的，并不包含在我們將開源的健康檢查內(nèi)容。
我們確認(rèn)了zpool已妥善掛載，Docker已正確與其建立連接，并且在進(jìn)行操作時不會引發(fā)CPU鎖定現(xiàn)象。
我們對機(jī)器上的NVLink錯誤進(jìn)行了排查。經(jīng)驗(yàn)表明，這些問題似乎并不會直接導(dǎo)致訓(xùn)練任務(wù)失敗，但它們可能會延緩訓(xùn)練進(jìn)程。
我們借助flint和hca_self_test工具，檢查了對Mellanox OFED驅(qū)動程序的版本、卡片固件以及收發(fā)器固件，確保它們與NVIDIA驅(qū)動程序兼容，并已正確編譯。
我們查詢了PCIe設(shè)備，以確認(rèn)GPU、PSB（PCIe交換總線）以及網(wǎng)卡之間的連接速度和寬度是否符合預(yù)期。此外，我們還檢查了交換機(jī)固件是否更新至最新版本。這個腳本是由戴爾開發(fā)的，而非Imbue團(tuán)隊(duì)，因此我們目前無法分享它。
利用PyTorch初始化矩陣計(jì)算，并評估NVLink的帶寬以及GPU的計(jì)算速度和內(nèi)存效率。我們設(shè)置了正確的GDR標(biāo)志以測試InfiniBand和NVLink的性能。
通過ib_write_bw并激活-use_cuda，我們實(shí)現(xiàn)了在InfiniBand卡上傳輸數(shù)據(jù)，并對PCIe及InfiniBand卡的帶寬進(jìn)行了精確測量。為了確保能夠捕捉出現(xiàn)“抖動”的InfiniBand鏈路，我們進(jìn)行了長達(dá)15分鐘的持續(xù)測試。
我們執(zhí)行了多節(jié)點(diǎn)診斷運(yùn)行，以檢驗(yàn)NCCL的初始化功能以及是否存在隨機(jī)停滯的情況。如果發(fā)生停滯，我們分支的NCCL代碼會添加額外的日志記錄。這個過程可能需要12到24小時，因此，我們通常只在添加新節(jié)點(diǎn)或懷疑存在問題時才會運(yùn)行此測試。
檢查DCGM導(dǎo)出中是否存在任何GPU時鐘節(jié)流事件（不包括預(yù)期的gpu_idle和power_cap）。進(jìn)行多節(jié)點(diǎn)訓(xùn)練，激活所有GPU、InfiniBand卡、CPU和磁盤，是測試這些功耗事件的最佳方法。
一旦硬件進(jìn)入工作狀態(tài)，便可以著手啟動訓(xùn)練流程了。在本節(jié)中，我們將基于在集群上執(zhí)行大規(guī)模語言模型訓(xùn)練的實(shí)戰(zhàn)經(jīng)驗(yàn)，分享由此得來的見解和具體調(diào)試步驟。
雖然這一步驟看似基礎(chǔ)，但它對于保證訓(xùn)練啟動的可重現(xiàn)性和易于審查性至關(guān)重要，尤其是涉及到Docker鏡像緩存或不可見機(jī)密配置等中間抽象時，這些因素可能會引起混淆。
另外一項(xiàng)基本檢查，即確認(rèn)所有機(jī)器均在線運(yùn)行，并且生成的堆棧跟蹤或日志能夠輕松地進(jìn)行匯總和檢查。我們采用了Loki、Prometheus和Grafana的堆棧，但任何適合的日志聚合或追蹤SaaS都可以勝任。
我們構(gòu)建了一個系統(tǒng)，以便在發(fā)生故障時自動重新啟動，這使得日志和報(bào)錯的聚合變得更加重要，以防止將不同重啟過程中的報(bào)錯混淆。我們遇到的一些常見錯誤包括：
GPU內(nèi)存不足（OOM）錯誤，表現(xiàn)類似 CUDA out of memory Tried to allocate … 。為了解決這個問題，我們雙重檢查了配置和代碼，并回滾了所有可能因啟動時PyTorch設(shè)備指定不當(dāng)而導(dǎo)致的GPU#0額外資源占用的新近代碼更改。
CPU/RAM內(nèi)存不足（OOM）錯誤，這類錯誤在錯誤日志中往往不易察覺，通常最佳檢測手段是通過主機(jī)外部的dmesg日志來識別。我們主要在遇到子進(jìn)程或網(wǎng)絡(luò)對等方被OOM Killer回收時，遭遇以 CalledProcessError 或 ConnectionError 形式出現(xiàn)的錯誤。我們傾向于在檢測到dmesg中的OOM Killer調(diào)用時，直接使健康檢查失敗并重啟系統(tǒng)。我們還檢查了代碼路徑中是否包含了足夠的手動垃圾回收（參見下文關(guān)于如何禁用垃圾回收的章節(jié)），并確保沒有意外嘗試在CPU上進(jìn)行計(jì)算或?qū)埩堪徇\(yùn)到CPU上。
首要任務(wù)是自動化系統(tǒng)，以便重新執(zhí)行所有診斷性健康檢查（詳見前述章節(jié)），并在排除不健康主機(jī)的情況下自動重啟運(yùn)行。我們遇到了一些隨機(jī)的硬件故障，包括Xid和SXid錯誤，這些錯誤可能導(dǎo)致運(yùn)行崩潰，不會生成有意義的Python堆棧跟蹤。某些情況，例如行重映射（row remapping），可以通過簡單的重啟來恢復(fù)。
此外，我們還觀察到由異常格式化的訓(xùn)練數(shù)據(jù)引起的崩潰。例如，語料庫中的一個超大型單一文檔可能導(dǎo)致GPU或CPU出現(xiàn)內(nèi)存不足（OOM）錯誤。
為了規(guī)避這類問題，我們實(shí)施了一個完全確定性的數(shù)據(jù)加載器，這使得每次崩潰都能通過關(guān)聯(lián)到特定的epoch或步驟編號來輕松地重現(xiàn)。
我們發(fā)現(xiàn)，通過禁用數(shù)據(jù)加載或用假數(shù)據(jù)（例如全零數(shù)據(jù)）替換，可以有效確認(rèn)數(shù)據(jù)是否真的是導(dǎo)致崩潰的根本原因。
最終，利用任何偏好的指標(biāo)聚合方法來記錄網(wǎng)絡(luò)及節(jié)點(diǎn)整體健康統(tǒng)計(jì)信息同樣至關(guān)重要。諸如以太網(wǎng)短暫斷開連接或磁盤空間耗盡等問題可能不會直接以清晰的錯誤信息顯現(xiàn)，但它們可以通過收集到的數(shù)據(jù)輕松進(jìn)行關(guān)聯(lián)。
這類錯誤在調(diào)試過程中極其棘手，一方面是因?yàn)槿狈τ兄谠\斷的信息，另一方面則是因?yàn)樗鼈兺y以穩(wěn)定地重現(xiàn)。最令人記憶猶新的錯誤類型，其特征由以下類似錯誤信息標(biāo)識
這意味著，一個或多個主機(jī)未能完成NCCL操作，甚至可能從NCCL和InfiniBand連接中崩潰，導(dǎo)致所有其他主機(jī)在特定的張量操作上同步阻塞，直到達(dá)到 NCCL_TIMEOUT。遺憾的是，由于NCCL庫的特性，要找出是哪個具體的主機(jī)導(dǎo)致了這一問題變得異常艱難。
我們對NCCL庫進(jìn)行了日志改進(jìn)（詳見我們的fork），以便更清晰地追蹤崩潰發(fā)生時的活動消息或操作，進(jìn)而識別出那些似乎阻礙了訓(xùn)練運(yùn)行的主機(jī)或GPU。
請注意，為了識別表現(xiàn)異常的主機(jī)，我們通常需要確定哪些主機(jī)沒有生成特定的日志消息。這些消息的缺失表明該主機(jī)上的工作進(jìn)程已經(jīng)落后或已崩潰。
在其他情況下，盡管沒有出現(xiàn)有用的錯誤消息，但無響應(yīng)的問題通?？梢躁P(guān)聯(lián)到硬件相關(guān)的問題，例如之前提到的Xid/SXid/ECC錯誤，這些錯誤會導(dǎo)致NVIDIA驅(qū)動程序或NVIDIA Docker通信驅(qū)動程序鎖定。
為了區(qū)分NCCL掛起、驅(qū)動程序掛起以及Python代碼中的爭用條件或死鎖，我們使用了Py-Spy和GNU項(xiàng)目調(diào)試器（GDB）等工具，在遇到停滯進(jìn)程時進(jìn)行現(xiàn)場調(diào)試。通過這種方法，我們能夠捕捉到一個特定的問題，即由于Python線程設(shè)置配置不當(dāng)，我們無法在某些主機(jī)上正確啟動八個多線程的NCCL GPU進(jìn)程，這些主機(jī)在預(yù)PyTorch初始化代碼階段遇到了競爭條件。
缺乏監(jiān)控工具可能會讓這些問題比之前類別更加棘手。除了使用Py-Spy、堆棧跟蹤檢查和GDB之外，我們還啟動了NVIDIA Nsight和性能分析工具來協(xié)助診斷，其中一些工具在高度分布式的環(huán)境中操作起來相當(dāng)困難。
遺憾的是，訓(xùn)練速度的下降或低于以往所觀測到的模型浮點(diǎn)運(yùn)算次數(shù)（MFU）利用率，可能是由多種復(fù)雜因素共同作用的結(jié)果。
首先，對配置、代碼和環(huán)境變量進(jìn)行復(fù)查證明是非常有幫助的。我們曾遭遇過運(yùn)行錯誤模型、不正確的batch大小、錯誤的UFM或NCCL配置、不恰當(dāng)?shù)腃UDA_DEVICE_MAX_CONNECTIONS設(shè)置等問題，所有這些都會導(dǎo)致性能不佳。
此外，我們發(fā)現(xiàn)，相較于平滑或窗口平均值，直接測量每組batch的瞬時MFU更為有用，因?yàn)檫@種未經(jīng)過平滑處理的MFU曲線形狀通常能幫助我們快速診斷問題的類別。這些問題涵蓋了：
這種情況通常是由退化或故障的InfiniBand鏈路引起的，尤其是如果某個特定的GPU關(guān)聯(lián)的InfiniBand網(wǎng)絡(luò)接口卡（NIC）出現(xiàn)故障，導(dǎo)致NCCL嘗試通過本地NVLink路由流量，并使用同一主機(jī)上另一個GPU上的NIC。這也可能是由CPU節(jié)流（CPU throttling）引起的，這需要針對特定主機(jī)調(diào)整一些BIOS設(shè)置。
隨機(jī)且罕見地（大約每15分鐘發(fā)生一次）出現(xiàn)單組batch突然急劇下降（下降10倍），隨后立即完全恢復(fù)到良好的MFU
導(dǎo)致這種情況最常見的原因似乎是運(yùn)行中的一臺主機(jī)上安排了其他 CPU-heavy的工作負(fù)載。與其構(gòu)建用于識別特定主機(jī)的分析工具，我們發(fā)現(xiàn)通過PID粗略監(jiān)控CPU使用率更容易操作。這種波動也可能與偶爾的網(wǎng)絡(luò)問題有關(guān)，比如數(shù)據(jù)加載時的瓶頸問題。我們使用了指標(biāo)監(jiān)控，并為數(shù)據(jù)加載、檢查點(diǎn)以及任何非NCCL代碼添加了Python代碼計(jì)時日志，這種方法證明非常有效和可靠。
從理論上講，這種情況可能是由于交換機(jī)上的熱量積累造成的，但我們并未觀察到這一現(xiàn)象。相反，我們使用了Python和NVIDIA分析器來確定原因，這種性能下降似乎是由于自動垃圾回收導(dǎo)致的。
在調(diào)試這些性能下降時，我們注意到吞吐量出現(xiàn)周期性的下降，這種波動幾乎呈現(xiàn)出一種確定性。隨著訓(xùn)練的不斷深入，這些波動對分布式操作的影響范圍逐漸增大。這促使我們提出了一個假設(shè)，即這些波動可能與自動垃圾回收有關(guān)，我們通過性能分析和測試驗(yàn)證了這一假設(shè)。一旦我們禁用了自動垃圾回收，并在所有主機(jī)上安排垃圾回收在特定時間間隔內(nèi)進(jìn)行，這些吞吐量的“下降”現(xiàn)象就消失了。
的同步分布式訓(xùn)練算法 FSDP。在阻塞操作期間，運(yùn)行垃圾收集的單個工作進(jìn)程可能會減慢其他所有工作進(jìn)程的速度。如果有數(shù)百個工作進(jìn)程，這可能會導(dǎo)致速度顯著下降。
我們觀察到這種情況與NVIDIA GPU的“時鐘節(jié)流原因（clock throttle reasons）”相關(guān)，我們通過應(yīng)用合適的設(shè)置來使用NVIDIA DCGM收集到了這些信息。這通常是由于GPU過熱（GPU溫度過高或主機(jī)冷卻風(fēng)扇損壞/性能下降）或電源供應(yīng)故障導(dǎo)致的。凱發(fā)K8官網(wǎng)平臺注冊
此外，當(dāng)我們同時將所有8個GPU的利用率、8倍的NIC InfiniBand利用率和CPU/RAM/磁盤的利用率全部推至最大時，一些具有特定電源供應(yīng)硬件的主機(jī)會出現(xiàn)電壓問題，但這種問題僅在所有組件同時被充分利用時出現(xiàn)——通常是在實(shí)際進(jìn)行訓(xùn)練運(yùn)行時。
這個問題同樣與InfiniBand硬件有關(guān)，通常是由網(wǎng)絡(luò)中較高層次的適配器性能輕微下降或不穩(wěn)定（即“flapping”鏈接）引起的，而不是主機(jī)到T2層的冗余較低的連接部分造成的。
這也是InfiniBand硬件相關(guān)的問題，但通常是由于網(wǎng)絡(luò)中較高層的中度降級或抖動鏈路（flapping link）引起的——而不是在冗余較低的主機(jī)到T2層。
遺憾的是，許多這些問題很難直接歸因于某個特定的主機(jī)，并且由于InfiniBand交換技術(shù)具有拓?fù)涓兄匦?，?dǎo)致與InfiniBand相關(guān)問題尤其難以確定。InfiniBand似乎在InfiniBand fat-tree設(shè)計(jì)中傾向于相鄰的主機(jī)，而UFM（用戶功能管理器）可以以導(dǎo)致不對稱鏈路速度的方式路由數(shù)據(jù)包。
你是在健康主機(jī)上運(yùn)行的嗎？所有依賴的服務(wù)是否都在運(yùn)行，包括第三方SaaS服務(wù)，如Docker Hub、GitHub或其他你所用的堆棧依賴的服務(wù)？
你確定你使用的是與上次完全相同的代碼、環(huán)境、配置、版本、主機(jī)列表、排名順序和隨機(jī)種子嗎(如果可能的話)？
在這一部分，我們將介紹我們開發(fā)的幾種工具和系統(tǒng)，旨在確保訓(xùn)練過程能夠順利進(jìn)行，盡可能地減少人工干預(yù)。鑒于我們團(tuán)隊(duì)規(guī)模較小，難以承擔(dān)起持續(xù)的人工維護(hù)工作，因此我們致力于自動化更多流程。
幾乎所有的訓(xùn)練運(yùn)行問題都可以歸因于故障的機(jī)器或網(wǎng)絡(luò)組件。在大型集群中，這種故障發(fā)生頻率較高，因此自動禁用故障機(jī)器和網(wǎng)絡(luò)組件，并請求維修的過程至關(guān)重要。
我們構(gòu)建了一個系統(tǒng)，能夠自動從最近的檢查點(diǎn)重新啟動出現(xiàn)故障的運(yùn)行。首先，它會在所有可用的機(jī)器上執(zhí)行一系列健康檢查，并根據(jù)每臺機(jī)器通過的檢查項(xiàng)目對其健康狀況進(jìn)行分類；接著，系統(tǒng)會嘗試在健康狀況評估最高的機(jī)器上重新啟動訓(xùn)練任務(wù)。
我們所觀察到的所有網(wǎng)絡(luò)組件故障均被UFM檢測到，并記錄在UFM事件日志中，因此應(yīng)對網(wǎng)絡(luò)故障僅需分析UFM日志，針對每條事件采取相應(yīng)的應(yīng)對措施。
盡管UFM事件系統(tǒng)包含多種事件類型，但在實(shí)際應(yīng)用中，我們發(fā)現(xiàn)只有少數(shù)幾種事件才是問題所在，主要涉及鏈路故障或符號錯誤計(jì)數(shù)過高。
通過識別這些事件，我們編寫了腳本用于解析UFM事件日志，禁用近期事件中涉及的鏈路和端口，針對這些網(wǎng)絡(luò)組件提交維護(hù)工單，并在完成維護(hù)后重新啟用這些組件。
很早就發(fā)現(xiàn)，大規(guī)模分布式訓(xùn)練運(yùn)行的瓶頸之一是進(jìn)出集群的以太網(wǎng)速度。如果數(shù)百名工作人員試圖同時下載數(shù)據(jù)集和模型檢查點(diǎn)，帶寬約為10Gbit/s的共享以太網(wǎng)連接很快就會飽和。
我們設(shè)置了默認(rèn)的 Torch 分析器以及 NVIDIA 的 Nsight Systems。后者有助于準(zhǔn)確了解前向/后向傳遞和 NCCL 通信需要多長時間，并確定我們是否因給定模型大小和worker數(shù)量而受到通信或計(jì)算的瓶頸。然而，Nsight Systems 有點(diǎn)難以使用，因?yàn)樗枰谔貦?quán)模式下運(yùn)行 Docker，禁用與性能監(jiān)控事件相關(guān)的安全檢查，并且保存配置文件通常需要停止整個訓(xùn)練過程。
此外，我們發(fā)現(xiàn)編寫工具來檢測緩慢的訓(xùn)練batch并理解緩慢的潛在原因非常有益。其中最有效的工具是一種監(jiān)控每個batch運(yùn)行時間，并在batch運(yùn)行異常緩慢時記錄所有worker的堆棧跟蹤工具，這使得識別存在細(xì)微硬件或軟件問題的特定主機(jī)變得更加簡便。
在我們使用集群的最初幾個月（當(dāng)時我們的健康檢查還沒有像現(xiàn)在這樣全面），我們經(jīng)常遇到這樣的情況：在特定一組機(jī)器上運(yùn)行的訓(xùn)練失敗了，但不清楚哪臺機(jī)器出了問題。
為了查明故障主機(jī)，我們開發(fā)了一些工具，以便輕松地將一組機(jī)器劃分為若干子集，并在每個子集機(jī)器上啟動一個較小的作業(yè)。
例如，如果 一組48 臺機(jī)器上的作業(yè)出現(xiàn)故障，我們會在 6 組（每組 8 臺）機(jī)器上啟動小規(guī)模作業(yè)運(yùn)行，然后在 8 組（每組 6 臺）機(jī)器上啟動小規(guī)模作業(yè)運(yùn)行。通常情況下，這兩個階段中每個階段，只會有一次運(yùn)行失敗，因此我們可以非常自信地得出結(jié)論，兩個階段中都參與了故障運(yùn)行的機(jī)器是有問題的。
能夠相互替換機(jī)器極為實(shí)用。對于任何特定的訓(xùn)練運(yùn)行，我們發(fā)現(xiàn)擁有比實(shí)際需要多出10-20%的機(jī)器是有益的，這樣在機(jī)器發(fā)生故障時，我們能夠輕松地重新啟動運(yùn)行。通過設(shè)置集群網(wǎng)絡(luò)使每臺機(jī)器都與所有其他機(jī)器緊密相連，我們實(shí)際上可以利用任何處于工作狀態(tài)的子集機(jī)器。
對于每一次在訓(xùn)練過程中遇到的硬件或軟件故障，編寫相應(yīng)的測試和自動化解決方案是非常值得的，因?yàn)檫@些已解決的問題可能會再次發(fā)生。同樣地，對于每一個難以理解的錯誤信息，開發(fā)工具使其更加清晰易懂也是十分有價(jià)值的。
重現(xiàn)性是優(yōu)質(zhì)科學(xué)研究的基礎(chǔ)。我們迅速采納的一個原則是“每次只變動一個因素”，即便是處理最簡單的情況也不例外。
“信任，但需實(shí)踐檢驗(yàn)”。每當(dāng)我們在流程中引入新的外部工具，或無論是內(nèi)部還是外部新加入團(tuán)隊(duì)成員時，我們確保對其聲明進(jìn)行復(fù)核，特別是當(dāng)后續(xù)步驟依賴于這些結(jié)果時。
構(gòu)建大規(guī)模語言模型所需的基礎(chǔ)設(shè)施極其復(fù)雜。我們之所以選擇深度參與基礎(chǔ)設(shè)施的搭建，一方面是因?yàn)槲覀儓?jiān)信理解所使用系統(tǒng)的重要性，另一方面是因?yàn)槲覀冾A(yù)見到這終將帶來更高的效率。經(jīng)過完整流程的實(shí)踐，我們非常慶幸采取了這一策略——擁有對基礎(chǔ)設(shè)施的完全控制權(quán)，并能在各個抽象層次上輕松地解決問題。
雖然這個過程需要大量的監(jiān)督和迭代，但它使我們能夠深入理解底層流程，構(gòu)建一系列工具確保主機(jī)健康，學(xué)習(xí)如何自動化系統(tǒng)以確保訓(xùn)練過程的持續(xù)平滑，最終創(chuàng)建了允許我們快速迭代訓(xùn)練尖端語言模型的基礎(chǔ)架構(gòu)。
這一基礎(chǔ)設(shè)施建設(shè)過程體現(xiàn)了我們對研究和構(gòu)建AI智能體堅(jiān)實(shí)基礎(chǔ)的方法：深入探究細(xì)節(jié)，持續(xù)優(yōu)化現(xiàn)有流程，并構(gòu)建實(shí)用的工具和系統(tǒng)，使我們這個充滿活力的團(tuán)隊(duì)能夠應(yīng)對更大的挑戰(zhàn)。
718052212