在大型語言模型訓(xùn)練中，穩(wěn)定性是個大挑戰(zhàn)。LLM訓(xùn)練涉及的數(shù)據(jù)和計算量遠(yuǎn)超傳統(tǒng)深度神經(jīng)網(wǎng)絡(luò)。比如，訓(xùn)練一個萬億token的LLM可能要數(shù)周，這遠(yuǎn)超常規(guī)DNN訓(xùn)練。在這種大規(guī)模下，失敗和單點性能下降很常見。這些問題對整個任務(wù)影響巨大。失敗成本高昂，所以減少恢復(fù)時間非常關(guān)鍵。一個性能下降的單點不僅影響自己，還拖慢整個數(shù)萬個GPU的任務(wù)。這些問題可能由硬件故障、軟件錯誤、數(shù)據(jù)問題或其他訓(xùn)練意外引起。為確保LLM訓(xùn)練的穩(wěn)定性和效率，需要采取一些措施。比如使用高可靠性硬件和軟件，設(shè)計強(qiáng)健的訓(xùn)練算法，實施有效的監(jiān)控和故障恢復(fù)機(jī)制。這樣，LLM訓(xùn)練才能在大規(guī)模挑戰(zhàn)下順利完成任務(wù)。 最近，字節(jié)和北大聯(lián)合發(fā)布了一篇論文，介紹了萬卡英偉達(dá)A100系統(tǒng)大規(guī)模訓(xùn)練的技術(shù)改進(jìn)及經(jīng)驗，其中關(guān)于監(jiān)測和工具的改進(jìn)尤其值得關(guān)注。 為了提升穩(wěn)定性，字節(jié)使用了一種深度監(jiān)控方法。這種方法不僅關(guān)注表面指標(biāo)，還深入系統(tǒng)各個部分，收集詳細(xì)信息。這樣可以幫助就可以診斷系統(tǒng)問題，找出穩(wěn)定性問題的根源。 字節(jié)還開發(fā)了一套自動化故障定位和恢復(fù)系統(tǒng)。這個系統(tǒng)通過心跳信息實時檢測異常，并提供預(yù)警。還有一套診斷測試，用于識別引起問題的節(jié)點。他們還優(yōu)化了checkpoint和恢復(fù)程序，減少訓(xùn)練中斷。 為了解決單點性能下降的問題，字節(jié)開發(fā)了一個性能分析工具。這個工具記錄了詳細(xì)的CUDA事件，并生成了系統(tǒng)范圍內(nèi)的熱圖和時間線跟蹤。還開發(fā)了一個3D可視化工具，顯示不同部分之間的數(shù)據(jù)依賴關(guān)系。 通過這些方法，能夠更有效地監(jiān)控和診斷大型語言模型訓(xùn)練中的穩(wěn)定性問題，從而提高了訓(xùn)練的穩(wěn)定性和效率。 訓(xùn)練過程中的監(jiān)控字節(jié)跳動開發(fā)了一個LLM訓(xùn)練框架，該框架能夠?qū)崿F(xiàn)自動故障識別和快速恢復(fù)，從而實現(xiàn)容錯性，最大限度地減少人工干預(yù)，并對正在進(jìn)行的訓(xùn)練任務(wù)的影響微乎其微。 在收到提交的訓(xùn)練任務(wù)后，驅(qū)動進(jìn)程會與定制的Kubernetes接口，分配計算資源，并為每個執(zhí)行器啟動相應(yīng)的Pod。每個執(zhí)行器管理一個節(jié)點。執(zhí)行器完成一系列初始化任務(wù)后，在每個GPU上創(chuàng)建訓(xùn)練進(jìn)程，并啟動一個訓(xùn)練守護(hù)進(jìn)程，定期向驅(qū)動發(fā)送心跳。這些心跳包含各種信息，用于實時異常檢測和預(yù)警。 當(dāng)驅(qū)動進(jìn)程檢測到特定訓(xùn)練進(jìn)程的異常狀態(tài)，或未在預(yù)定時間內(nèi)收到執(zhí)行器的心跳時，它會觸發(fā)故障恢復(fù)程序。驅(qū)動會暫停所有執(zhí)行器上的正在進(jìn)行訓(xùn)練任務(wù)，并命令它們運(yùn)行一系列輕量級但全面的自我檢查診斷測試。這些測試覆蓋了大多數(shù)常見的硬件和軟件故障。 一旦確定問題節(jié)點，驅(qū)動將提交需要封鎖的節(jié)點IP地址和其上運(yùn)行的Pod信息給Kubernetes。Kubernetes會將故障節(jié)點驅(qū)逐，并用通過診斷測試的健康節(jié)點替換。此外，字節(jié)跳動提供了一個用戶界面，允許手動驅(qū)逐節(jié)點，特別是那些通過手動分析確定的節(jié)點。 恢復(fù)過程完成后，驅(qū)動從最新的checkpoint恢復(fù)訓(xùn)練。字節(jié)跳動還優(yōu)化了checkpoint和恢復(fù)過程，以最小化訓(xùn)練進(jìn)度的損失。 數(shù)據(jù)收集和分析系統(tǒng)通過心跳消息收集數(shù)據(jù)。心跳消息是一種健康檢查的方式，就像心跳一樣，它定期告訴系統(tǒng)的其他部分：“我還在工作！”這些消息包含了執(zhí)行器的基本信息，比如它的IP地址（就像是它在網(wǎng)上位置的地址），Pod名稱（Pod是Kubernetes中一個可以理解為一個容器或一組容器的單位），以及硬件信息（比如GPU的狀態(tài)）。同時，它們還報告了訓(xùn)練進(jìn)程的當(dāng)前狀態(tài)，這樣驅(qū)動進(jìn)程就能及時發(fā)現(xiàn)任何明顯的異常。 訓(xùn)練進(jìn)程的stdout/stderr日志也被包括在內(nèi)，它們會被實時匯總、過濾和分析。如果檢測到特定的警告或錯誤關(guān)鍵詞，驅(qū)動進(jìn)程會報告實時診斷信息。訓(xùn)練進(jìn)程的stdout/stderr日志是程序運(yùn)行時打印出來的信息。當(dāng)你的電腦程序出現(xiàn)問題時，它會彈出一個錯誤信息。這些日志就是大型語言模型訓(xùn)練時打印出來的“錯誤信息”或“狀態(tài)更新”。 此外，心跳消息中還包含了RDMA流量指標(biāo)，這有助于了解網(wǎng)絡(luò)利用率和效率。RDMA流量指標(biāo)是一種衡量數(shù)據(jù)在網(wǎng)絡(luò)中傳輸效率的方法。RDMA（遠(yuǎn)程直接內(nèi)存訪問）是一種高效的網(wǎng)絡(luò)通信技術(shù)，它允許數(shù)據(jù)直接從一臺機(jī)器的內(nèi)存?zhèn)鬏數(shù)搅硪慌_機(jī)器的內(nèi)存，而不需要經(jīng)過每臺機(jī)器的操作系統(tǒng)。RDMA流量指標(biāo)就像是高速公路上的交通流量，它告訴數(shù)據(jù)在網(wǎng)絡(luò)中流動的速度和效率。 有些訓(xùn)練過程中的異?？赡懿粫憩F(xiàn)為明確的錯誤，看起來訓(xùn)練一切正常。在這種情況下，RDMA流量指標(biāo)就變得非常重要。由于訓(xùn)練任務(wù)是周期性的，每個步驟的網(wǎng)絡(luò)流量特征應(yīng)該表現(xiàn)相似。因此，RDMA流量顯著下降或異常波動可能是潛在異常的信號。一旦檢測到這些不規(guī)則情況，驅(qū)動進(jìn)程會發(fā)出警報，以便人工調(diào)查。如果流量完全停止，驅(qū)動進(jìn)程會自動啟動故障恢復(fù)程序。 為了提升訓(xùn)練穩(wěn)定性和性能的監(jiān)控，字節(jié)跳動開發(fā)了一個精確到毫秒級的監(jiān)控系統(tǒng)。不同級別的監(jiān)控被用來跟蹤各種指標(biāo)。二級監(jiān)控通常用于評估整體健康狀態(tài)，排除常見配置對訓(xùn)練的影響，比如ECN/PFC/QoS配置、鏈路波動或其他NIC問題。而毫秒級監(jiān)控用于確定網(wǎng)絡(luò)是否擁塞，以及數(shù)據(jù)并行和管道并行的數(shù)據(jù)傳輸速度是否達(dá)到了物理極限。 這個監(jiān)控系統(tǒng)就像是一個精密的雷達(dá)系統(tǒng)，能夠?qū)崟r監(jiān)測訓(xùn)練過程中的各種細(xì)節(jié)。二級監(jiān)控就像是常規(guī)的健康檢查，它確保一切運(yùn)行正常，排除了一些常見的配置問題。而毫秒級監(jiān)控就像是超級精密的儀器，它能夠檢測到非常細(xì)微的變化，比如網(wǎng)絡(luò)是否擁堵，數(shù)據(jù)傳輸速度是否打滿等。 診斷測試字節(jié)跳動在診斷測試中面臨一個權(quán)衡：測試執(zhí)行時間和準(zhǔn)確性的平衡。如果測試時間太長，會影響有效的訓(xùn)練時間；如果錯誤率高，可能會導(dǎo)致實際上正常的機(jī)器被錯誤排除。通過反復(fù)實驗和優(yōu)化，字節(jié)跳動部署了一套輕量級的診斷測試，這些測試能夠有效地覆蓋在實際訓(xùn)練過程中遇到的多種硬件和軟件故障。
為了診斷主機(jī)內(nèi)部網(wǎng)絡(luò)的潛在瓶頸，字節(jié)跳動使用內(nèi)部開發(fā)的工具進(jìn)行兩項測試。回路測試測量了所有RDMA網(wǎng)絡(luò)接口卡（RNICs）到主機(jī)內(nèi)部各種端點（包括內(nèi)存節(jié)點和GPU）的回路帶寬。它進(jìn)行了一個主機(jī)內(nèi)的全網(wǎng)格測試，覆蓋了所有可能的鏈路組合。這樣，可以根據(jù)端到端帶寬結(jié)果推斷出鏈路特定的帶寬降級和PCIe配置的不規(guī)則性。第二個RNIC到RNIC的測試檢查了同一主機(jī)上不同RNIC之間的連接性和帶寬性能。這些測試提供了RNIC是否滿足硬件速度規(guī)格以及底層路由配置是否正確設(shè)置的見解。
為了識別GPU通信中的潛在故障，字節(jié)跳動在單個節(jié)點內(nèi)的GPU之間運(yùn)行了一個全到全的測試，觀察帶寬是否與預(yù)期基準(zhǔn)一致。一旦通過了主機(jī)內(nèi)部通信測試，每個節(jié)點還會與同一ToR交換機(jī)下的相鄰機(jī)器進(jìn)行all-reduce測試，以評估節(jié)點間GPU通信的性能。 ToR交換機(jī)是一種網(wǎng)絡(luò)設(shè)備，它將多個機(jī)器連接到一個局域網(wǎng)（LAN）中。NCCL是NVIDIA Collective Communications
Library的縮寫，它是一個用于GPU通信的庫，可以讓多個GPU之間有效地交換數(shù)據(jù)。這些測試確保了GPU之間的通信順暢，這對于大型語言模型的訓(xùn)練至關(guān)重要，因為GPU需要頻繁地交換數(shù)據(jù)和同步信息。 故障隔離恢復(fù)訓(xùn)練在識別并移除故障機(jī)器后，驅(qū)動程序需要通過加載最近的checkpoint中的模型權(quán)重和優(yōu)化器狀態(tài)來恢復(fù)訓(xùn)練。確保最新的checkpoint盡可能接近故障發(fā)生時的訓(xùn)練進(jìn)度狀態(tài)，以最小化計算和時間的損失至關(guān)重要。這要求在訓(xùn)練期間增加checkpoint的頻率。然而，也希望減少checkpoint過程引入的延遲，特別是那些阻塞訓(xùn)練進(jìn)度、阻礙系統(tǒng)整體吞吐量的關(guān)鍵路徑上的時間。 為了實現(xiàn)快速checkpoint，字節(jié)跳動引入了一種優(yōu)化的、兩階段的方法： 在第一階段，每個GPU工作者將其芯片狀態(tài)寫入主機(jī)內(nèi)存，并繼續(xù)訓(xùn)練過程。通過優(yōu)化PyTorch的序列化機(jī)制和使用固定內(nèi)存，這個過程可以由于高PCIe帶寬而只需要到幾秒鐘，從而最小化對正在進(jìn)行的訓(xùn)練過程的干擾。 在第二階段，一個后臺進(jìn)程接管，異步地將狀態(tài)從主機(jī)內(nèi)存?zhèn)鬏數(shù)揭粋€分布式文件系統(tǒng)（在字節(jié)的部署中是HDFS）進(jìn)行集中維護(hù)。將操作分為兩個階段解耦，使得GPU任務(wù)幾乎可以立即恢復(fù)訓(xùn)練，而將寫入HDFS的更耗時的過程卸載到一個單獨的、非阻塞的進(jìn)程中。 從checkpoint恢復(fù)時間是特別重要的，因為訓(xùn)練在沒有最后checkpoint的情況下無法啟動。瓶頸在于HDFS的帶寬，尤其是當(dāng)多個任務(wù)需要讀取其對應(yīng)的狀態(tài)分區(qū)時。 為了緩解這個瓶頸，字節(jié)提出了一種優(yōu)化的數(shù)據(jù)檢索策略。其實，多個任務(wù)經(jīng)常共享相同的狀態(tài)分區(qū)，例如，同一數(shù)據(jù)并行組中的任務(wù)。相應(yīng)地，指定該組中的一個任務(wù)從HDFS讀取共享的狀態(tài)分區(qū)，從而將負(fù)載線性化。然后，這個任務(wù)將狀態(tài)分區(qū)廣播到所有其他共享相同數(shù)據(jù)的任務(wù)重。這種方法有效地緩解了HDFS的帶寬限制，大大減少了恢復(fù)時間。 總的來說，字節(jié)跳動的方法通過優(yōu)化checkpoint和恢復(fù)過程，確保了在大規(guī)模訓(xùn)練中能夠快速地從故障中恢復(fù)，減少了訓(xùn)練中斷的時間，提高了訓(xùn)練的效率和穩(wěn)定性。 訓(xùn)練中的故障排除盡管字節(jié)的LLM訓(xùn)練框架可以自動發(fā)現(xiàn)、定位并解決大多數(shù)常見故障，但仍有一些硬件異常會概率出現(xiàn)，并且無法通過機(jī)器自檢發(fā)現(xiàn)。一些異?？赡苁沟孟到y(tǒng)看起來正常運(yùn)行，但實際上大大降低了訓(xùn)練效率。為了應(yīng)對這些細(xì)微的情況，字節(jié)已經(jīng)實現(xiàn)了一些定制的監(jiān)控和分析工具，用于逐個案例進(jìn)行異常檢測。 這些工具就像是一支專門的偵探團(tuán)隊，它們使用各種高級技術(shù)和方法來深入調(diào)查問題。例如，它們可能會分析訓(xùn)練過程中的數(shù)據(jù)模式，尋找那些可能暗示著硬件或軟件問題的微小變化。它們還可能會監(jiān)控系統(tǒng)的性能指標(biāo)，比如處理速度和能源消耗，來發(fā)現(xiàn)任何不尋常的波動。 此外，這些工具還可以幫助團(tuán)隊識別那些可能被忽視的異常情況。想象一下，一個系統(tǒng)可能在大部分時間都表現(xiàn)正常，但偶爾會出現(xiàn)小問題，這些問題可能不會導(dǎo)致系統(tǒng)完全崩潰，但會逐漸降低訓(xùn)練效率。這些工具能夠幫助團(tuán)隊識別并修復(fù)這些問題，確保訓(xùn)練過程始終保持高效。 總之，這些定制的監(jiān)控和分析工具是字節(jié)跳動確保訓(xùn)練過程穩(wěn)定性和效率的最后一道防線。通過這些工具，團(tuán)隊能夠發(fā)現(xiàn)并解決那些自動化系統(tǒng)可能無法捕捉到的復(fù)雜問題，確保大型語言模型的訓(xùn)練能夠順利進(jìn)行。 CUDA事件監(jiān)控及性能分析字節(jié)發(fā)現(xiàn)在擁有數(shù)萬個GPU的大規(guī)模訓(xùn)練環(huán)境中，即使配置相同，不同的訓(xùn)練運(yùn)行也表現(xiàn)出不同的計算效率。而且，在不同規(guī)模下，訓(xùn)練任務(wù)的性能并不一致。各種訓(xùn)練任務(wù)的MFU（計算利用率）隨時間逐漸下降。而且通過單GPU GEMM（矩陣乘法）微基準(zhǔn)測試下，并每位發(fā)現(xiàn)不同節(jié)點間存在明顯差異。 為了診斷這些性能問題，字節(jié)開發(fā)了一個性能分析工具，該工具可以記錄每個機(jī)器在運(yùn)行期間關(guān)鍵代碼段的執(zhí)行時間。與torch profiler或Megatron-LM計時器不同的是，這個工具基于CUDA事件方法計時事件。這種方法最小化了CUDA同步的需求，從而防止性能下降，可以在生產(chǎn)訓(xùn)練任務(wù)中一致地運(yùn)行它。 這個工具提供了兩種可視化模式，并可以從不同的角度分析收集的數(shù)據(jù)。
CUDA事件計時器產(chǎn)生的每一條數(shù)據(jù)都被存儲在一個遠(yuǎn)程分析數(shù)據(jù)庫中，允許從任何步驟事件輕松檢索詳細(xì)信息。雖然計時器數(shù)據(jù)以逐行格式寫入本地文件，但一個單獨的流處理器然后實時地將這個日志文件同步到Kafka隊列中。分析數(shù)據(jù)庫通過處理這個Kafka隊列的數(shù)據(jù)保持更新，使得在不中斷訓(xùn)練任務(wù)的情況下可以進(jìn)行實時分析。所有監(jiān)控功能都在真實生產(chǎn)訓(xùn)練期間開啟，與訓(xùn)練時間相比，開銷可以忽略不計。 3D并行訓(xùn)練可視化在3D并行訓(xùn)練中，數(shù)據(jù)流動和任務(wù)順序的復(fù)雜性非常高。每個任務(wù)可能在某一時刻同時參與幾個同步或異步操作，這導(dǎo)致了它們之間的依賴關(guān)系非常復(fù)雜。這種復(fù)雜性也加劇了故障診斷的難度：當(dāng)一個GPU節(jié)點出現(xiàn)故障時，節(jié)點所在的集群集群可能會在NCCL通信操作中停滯，最終導(dǎo)致系統(tǒng)范圍內(nèi)的超時。從外部來看，這種情況表現(xiàn)為一般的阻塞，但根本原因往往隱藏在大量的超時消息中。 為了快速定位問題節(jié)點，字節(jié)設(shè)計讓每個任務(wù)在通信超時記錄自己正在進(jìn)行的操作。這些日志然后被于3D并行的可視化表示中。 3D并行訓(xùn)練集群邏輯上可以分為三個維度：張量并行、流水線并行和數(shù)據(jù)并行。當(dāng)選擇一個特定的任務(wù)時，3D并行可視化可以顯示此任務(wù)在3D邏輯拓?fù)渲械奈恢?，?shù)據(jù)流動的方向以及涉及的不同通信操作。重要的是，在發(fā)生錯誤的情況下，該工具提供了直接訪問任務(wù)錯誤消息的途徑（如果有的話）。這個工具，在用于診斷訓(xùn)練異常時，可以更快地識別和解決故障。 比如前面提到的案例，當(dāng)有缺陷的GPU在執(zhí)行NCCL通信操作時導(dǎo)致阻塞。這樣的阻塞可能會掛起整個機(jī)器，導(dǎo)致其他依賴節(jié)點的連鎖超時，最終導(dǎo)致整個訓(xùn)練過程癱瘓。為了快速識別這些故障節(jié)點，可以使用3D并行訓(xùn)練可視化工具。由于等待故障節(jié)點而超時的節(jié)點會在退出時記錄它們的正在進(jìn)行的操作。相比之下，如果只是故障GPU的節(jié)點被掛起，并沒有記錄任何此類信息。因此，通過檢查日志和可視化中的數(shù)據(jù)流，這些問題節(jié)點可以輕松定位。一旦確定，這些節(jié)點可以通過健壯的訓(xùn)練框架手動隔離和標(biāo)記為待維護(hù)。 經(jīng)驗分享字節(jié)對萬卡生產(chǎn)訓(xùn)練任務(wù)進(jìn)行了數(shù)周的故障記錄進(jìn)行了分析，發(fā)現(xiàn)：
字節(jié)還分享了一些有趣的故障診斷和修復(fù)經(jīng)驗，需要使用上面提到的故障排除工具進(jìn)行分析。
基于字節(jié)對CUDA事件計時器的使用，在多個實驗設(shè)置中觀察到了另一個相關(guān)現(xiàn)象：特定的主機(jī)執(zhí)行相同的正向計算大約需要多10%的時間。不同的實驗還得出了一致的現(xiàn)象，所以斷定，問題不是軟件本身的，而是集群中某些機(jī)器固有的問題。在隔離并從集群中移除這些有問題的主機(jī)后，觀察到MFU大約提高了0.7%。
進(jìn)行此類大規(guī)模訓(xùn)練實驗時，觀察到的另一個現(xiàn)象是訓(xùn)練效率隨時間變化并不保持一致。相反，隨著訓(xùn)練的進(jìn)行，的訓(xùn)練任務(wù)的MFU逐漸下降?；贑UDA事件計時器指標(biāo)的逐步分析，發(fā)現(xiàn)在正向計算階段發(fā)生了變化。深入代碼，把這個不規(guī)則性歸因于某些代碼段的波動。例如，不規(guī)則的垃圾收集可能會引入訓(xùn)練過程中的干擾，某些PyTorch操作可能會導(dǎo)致性能波動。這些操作處于關(guān)鍵路徑上，但在訓(xùn)練過程中可能會受到影響。在修改或刪除那些有問題的代碼段后，再也沒有觀察到MFU的顯著下降。
偶爾會遇到由于網(wǎng)絡(luò)接口頻繁振蕩而導(dǎo)致的訓(xùn)練停滯或訓(xùn)練速度下降問題。當(dāng)網(wǎng)絡(luò)接口振蕩現(xiàn)象發(fā)生時，網(wǎng)絡(luò)接口首先會下線然后再次上線。下線和上線之間的時間間隔通常持續(xù)幾秒鐘。在下線過程中，所有傳輸中的數(shù)據(jù)包將被丟棄。學(xué)到的第一個教訓(xùn)是應(yīng)該明確設(shè)置超時閾值到一個更大的值，否則默認(rèn)值會使NCCL超時非?？?，并在網(wǎng)絡(luò)卡再次上線之前返回一個完成錯誤。學(xué)到的第二個教訓(xùn)是這個問題的根本原因是網(wǎng)絡(luò)卡、AOC電纜和交換機(jī)之間的鏈接質(zhì)量差。通過在網(wǎng)絡(luò)卡信號強(qiáng)度、AOC電纜質(zhì)量和交換機(jī)側(cè)信號強(qiáng)度方面進(jìn)行底層質(zhì)量控制，可以將振蕩頻率降低到令人滿意的水平。 總結(jié)在大型語言模型（LLM）的訓(xùn)練過程中，字節(jié)跳動面臨了多個穩(wěn)定性挑戰(zhàn)，包括系統(tǒng)失敗、單點性能下降和硬件異常。為了應(yīng)對這些挑戰(zhàn)，字節(jié)跳動開發(fā)了一系列的診斷和恢復(fù)工具，以及優(yōu)化策略，包括深度監(jiān)控、快速checkpoint和恢復(fù)、性能診斷以及3D并行訓(xùn)練可視化。這些工具和策略使得字節(jié)跳動能夠自動檢測和修復(fù)大多數(shù)常見故障，大大減少了人工干預(yù)的需求，并且最小化了訓(xùn)練中斷的時間，從而提高了訓(xùn)練的效率和穩(wěn)定性。 字節(jié)跳動的深度監(jiān)控策略通過心跳消息收集執(zhí)行器的基本信息和訓(xùn)練進(jìn)程的狀態(tài)，實現(xiàn)實時異常檢測和預(yù)警。其快速checkpoint和恢復(fù)機(jī)制通過優(yōu)化checkpoint和恢復(fù)過程，確保了在出現(xiàn)故障時能夠快速恢復(fù)訓(xùn)練。性能診斷工具，如CUDA事件監(jiān)控，幫助識別和解決計算落后者和性能下降等問題。3D并行訓(xùn)練可視化工具則通過展示數(shù)據(jù)流和任務(wù)順序的3D邏輯拓?fù)?，幫助診斷訓(xùn)練過程中的問題。 此外，字節(jié)跳動還面臨了網(wǎng)絡(luò)接口頻繁振蕩的問題，通過設(shè)置更大的超時閾值和提高網(wǎng)絡(luò)接口的信號質(zhì)量，成功減少了振蕩頻率。 總的來說，字節(jié)跳動通過這些工具和策略，成功地提高了LLM訓(xùn)練的穩(wěn)定性和效率，即使在大規(guī)模訓(xùn)練環(huán)境中也能夠保持系統(tǒng)的穩(wěn)定運(yùn)行。 |
|
|
