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