熱門話題
#
Bonk 生態迷因幣展現強韌勢頭
#
有消息稱 Pump.fun 計劃 40 億估值發幣,引發市場猜測
#
Solana 新代幣發射平臺 Boop.Fun 風頭正勁

Tommy
創始合夥人 @Delphi_Ventures |共同創辦人 @Delphi_Digital |主持人@PodcastDelphi |建造@VenturesRobot |我的看法
由 @_xjdr 解鎖的大型開源基礎模型訓練
XJDR 是一位瘋狂的科學家,所以我花了幾次才能真正理解它,而我仍然可能無法完全欣賞整個結果。
通常,如果你想從零開始訓練一個全新的基礎模型,你需要大量的 GPU 才能讓一個認真的訓練運行起來。這是非常昂貴的。
最難訓練的類型之一是 DeepSeek 風格的專家混合設計。它非常強大,但路由系統和訓練設置非常挑剔,小規模測試經常會失敗。因此,你最終需要一個大型集群才能學到任何東西,而當一次運行失敗時,你無法判斷是你的想法錯誤還是設置出現了問題,這樣研究就會停滯,你什麼也學不到。
XJDR 正在開源 nmoe,一個準備運行的訓練工廠,按照專家的方式進行設置,特別是為了讓這類模型能夠在單台機器上進行訓練和研究,而不會不斷出現故障。小實驗的行為就像真正的訓練一樣,因此你可以在花費八位數和幾個月的時間之前,獲得一個乾淨的肯定或否定。
實際上,人們可以進行便宜、快速的試驗,每次改變一個因素,比如模型在專家之間的路由工作方式、它的學習方式(訓練配方)、你提供的數據以及如何在每一美元中擠出更多的質量。你基本上是在壓力測試新的想法,以便獲得更好的基礎模型,就像你會對一個產品進行 A/B 測試一樣,但你可以在大型實驗室之外進行。
最終的影響是更快的迭代和巨大的成本節省,此外,更多的團隊可以現實地構建新的基礎模型。這可能意味著更好的 DeepSeek 類模型、全新的專家風格模型,以及更多的競爭和開放研究,因為入場費大幅下降,更多的突破發生在公開場合。
敬請關注,他正在開源大部分內容!
恭喜 @_xjdr。我們非常高興能支持你,並成為你故事中的一小部分。

xjdr12月7日 08:15
# 為什麼訓練 MoEs 如此困難
最近,我發現自己想要一個小型的、專注於研究的訓練庫,
可以快速輕鬆地進行小實驗。這些實驗範圍
從嘗試新的注意力架構(MLA、SWA、NSA、KDA - 全部可插拔)到多精度訓練,最近還有使用「新」優化器的多優化器設置。我嘗試了三個主要的
競爭者(Nemo、Megatron 和 Torchtitan),但由於許多不同的原因,它們
都不符合我的需求,並且設置、使用和穩定運行都相當痛苦。我再次懷念我在谷歌的工具,
並且為此重寫我的生產訓練堆棧(這是專門為大型基礎設施監控和穩定性量身定做的)也感覺像是浪費時間,會使舊的和新的庫都變得更糟。
然而,這讓我思考,為什麼訓練前沿質量的「小型」
MoEs(例如總參數少於 20B)如此困難?我想要的庫/庫為什麼還不存在?經過一段時間的思考,我能想到的大多數挑戰歸結為三個不同的方面:
- FLOPS / FLOP 效率
- 負載平衡 / 路由穩定性
- 數據質量和數量
FLOPS
訓練密集模型現在相當簡單。訓練
動態大多是耦合的,如果你的架構中有足夠的參數,
模型幾乎會學會,儘管你犯了很多錯誤(這讓我多次受傷)。[DeepSeek 風格的超稀疏]( MoEs 不同,因為你的訓練動態在某種程度上是解耦的。只有一部分 MLP 在給定的標記上是活躍的,
隨著訓練的進行,活躍的專家會隨著時間的推移而變化和演變。這就是為什麼多輪訓練和數據重述對 MoEs(尤其是較大的 MoEs)如此有效的原因。
你會獲得巨大的推理效率提升和小的訓練效率提升,但代價是解耦的訓練動態(使得可預測和穩定訓練變得困難),而且你必須投入更多的 FLOPS
以確保學習到某種最佳的路由策略,並且參與各種策略的專家得到充分訓練。好吧,這就是 FLOPS / FLOP 效率挑戰出現的地方。第一個挑戰是,根據本質,超稀疏的 MoEs 需要大量的 HBM 來加載
專家,但這意味著你需要很多 GPU,因此系統中有很多閒置的 GPU。FSDP(和各種其他分片拓撲)大多是密集訓練的遺物,並且在充分利用所有這些閒置的 FLOPS 方面做得不好。這導致大多數人的超稀疏 MoE 訓練的 MFU(低)單位數字。雖然有幾種方法可以解決這個問題(未來會有更多關於這方面的內容),但我專注於兩個具體的方面:
- 新的分片拓撲(一種新穎的專家並行調度系統,保持 GPU 忙碌)
- 混合精度訓練
負載平衡 / 路由穩定性
我將把新的分片拓撲留給專門的寫作,但混合精度訓練是顯而易見的。你有這麼多閒置的 HBM,所以降低專家精度,將其減少一半或四分之一(分別為 fp8 和 nvfp4)。這在理論上是好的,但在實踐中,混合精度訓練通常需要更多的 HBM,因為你必須保持主權重和梯度在更高的精度中,然後將主權重量化到其較低的精度表示並緩存它們以供下一次前向傳遞使用。因此,它有助於推理效率(隨著越來越多的 FLOPS 用於 RL 和推理,這是一個真正的勝利),但代價是訓練期間需要更多的 HBM 和更多的 FLOPS。減少混合精度開銷應該是一個特定的重點。然而,任何你觸及的東西,無論是降低權重的精度和準確性,最終都會導致訓練動態的其餘部分不穩定。對於 MoE,這通常首先顯示出來的是路由穩定性。
DeepSeek-V3 技術報告描述了一種非常優雅的無輔助損失訓練設置,這裡幾乎沒有旋鈕,動態非常清晰。這些顯然是為經驗豐富的用戶設計的工具,因為僅用非常少的旋鈕來獲得正確的動態是非常困難的。關鍵是,DeepSeek 在穩定其路由器時大量依賴於大批量大小 - 這是我們在有限硬件上進行研究時所沒有的奢侈品。因此,我們必須更加努力地使我們的小型運行穩定、高效且信息豐富。當我開始實驗複製他們的設置,特別是針對混合精度專家時,變得非常明顯的是,梯度對於 fp8 或 nvfp4 來說太小,導致路由器無法學習,專家無法獲得足夠的資源。我嘗試了所有可能的方法來使這一切正常,首先是減少精度的反向傳遞,最終甚至使用 fp32 主權重和梯度,但路由器崩潰仍然持續。一篇及時的論文是 Character AI 博客文章,描述了他們的各種 int8 穩定性干預。我嘗試了它們所有,但最終使系統變得更加不穩定。因此,我逐一檢查它們。第一個是 muP 嵌入縮放為 10.66,logits 縮放為 0.125。這裡有很多明顯的優勢,除了路由穩定性,但這些縮放所做的一件明確的事情是將非常非常小的 fp8 和 nvfp4 專家梯度縮放到路由器終於學會的程度!然而,這些優勢也導致 bf16 梯度範數絕對爆炸,而「正常最佳實踐」的梯度裁剪和梯度縮放阻止了任何學習的發生。所以,解決方案是?去掉所有裁剪,YOLO!最後,我們有了穩定的混合精度路由器訓練。另一個最終非常有用的 Kaiju 干預是專家輸出前的單個彈性虛擬標量,初始化為 2.0,以匹配 bf16 梯度縮放,從而使得 nvfp4 和 fp8 在損失曲線上幾乎呈現出與基線 bf16 訓練運行相同的表現(FP8-BF16 差距從 ~0.8 降至 <0.1 在 3k 步驟)。這裡還有許多其他技巧和「最佳實踐」(未來的帖子中會有更多關於這些的內容),但重點是:
- 添加 muP 縮放
- 去掉所有其他裁剪,勇敢面對
- 彈性虛擬標量輸出前的標準化
- 保持無輔助損失和標記選擇路由(因為我們知道在這個家中對錯的區別)
數據
現在我們有了相對穩定的訓練動態,顯然如果我想與任何人分享這個庫,我們需要一些更好的數據來真正充分利用這個訓練庫。另一個及時的發布是 [OLMo-3]( 及其開源數據混合配方(向 Ai2 致敬!!)。然而,當我嘗試直接使用來自 huggingface 的 OLMo-3 混合時,我得到了相當糟糕的結果(與我典型的 FineWeb-Edu 基準相比)。所以,數據探險開始了,... 數據集相當髒。因此,我做了任何瘋狂的人會做的事情,我著手建立一個受前沿啟發的數據管道,以便我能真正充分利用這個訓練庫。
這個管道有幾個關鍵組件:
- **啟發式預過濾器**:語言 ID、長度過濾、MinHash 去重、n-gram 重複、困惑度異常、毒性 - 標準的東西,用來在消耗 GPU 週期之前去除明顯的垃圾
- **SeqIO 風格的動態混合**:確定性、可恢復的抽樣,無論總標記預算如何,保持你的目標比例(40% CC、20% 代碼等) - 對於代理運行至關重要,因為你不是在 6.7T 標記上進行訓練
- **基於模型的質量評分**:這就是有趣的地方
對於質量評分,我遵循了 [Seed-Coder]( 的模式:使用大型預言模型生成訓練標籤,然後提煉成快速分類器。我最初嘗試了幾個預言模型(Kimi-K2、DeepSeek-V3.2 和 [gpt-oss]( 120B),但最終只保留了 120B 類模型作為預言者 - 它們在細微的質量判斷上始終表現最佳。預言者在五個維度上對數據樣本進行評分,評估一般內容(有用性、正確性、一致性、複雜性、冗長性 - 每個 0-4)和四個維度的代碼(可讀性、模塊化、清晰性、可重用性 - 每個 0-10)。然後,我取了一個凍結的 gpt-oss 20B 主幹,並附加了兩個小頭:
- **探測頭**在第 18 層:均值池化隱藏狀態 → 線性(2880→5)。超便宜,早期捕捉明顯的垃圾
- **評判頭**在第 24 層:全序列注意 → 小型變壓器編碼器 → 線性(512→5)。更昂貴,但捕捉細微的質量問題
早期退出設計是關鍵 - 如果探測得分低於閾值,我們完全跳過評判。在大規模運行中,這節省了約 15% 的計算,同時保持質量。閾值(τ_drop,τ_keep)在保留集上進行校準,以達到目標保留率。
令我驚訝的是,我對 OLMo-3 數據集的保留率約為 CC 和互聯網來源的 30%,對於代碼、數學和科學則為 50%。這是大量過濾,但代理模型評估顯示出明顯的改進,超過了未過濾的基準。
我們終於擁有了一個相對功能完善的系統,近似於我對大型訓練基礎設施和之前使用的優秀工具的所有喜愛,但專門為研究和小型模型生產運行訓練小型 MoEs 而構建。然而,由於不斷的實驗和故障排除,這個庫變得一團糟。此外,我的開發團隊由我和一群 AI 代理組成。正如 Vik 最近所說的,「活在混亂中,死於混亂」,雖然我通常對「這個家中不允許混亂」非常嚴格,但整夜故障排除的殘骸和各種被放棄的實驗的屍體佈滿了我的庫。配置和啟動的複雜性也爆炸性增長。最初受到 [nanochat]( 的啟發的東西現在看起來更像 Megatron(無意冒犯)。
結果?我們現在可以在有限的硬件上進行有意義的 MoE 研究 - 在單個 B200 GPU 上的 7B2A 代理,在單個 8×B200 節點上的 16B4A - 都達到 30-40k tokens/sec/GPU。更重要的是,擴展是可預測的:我們的 1→8 GPU 運行顯示出一致的行為,這使我們有信心在小型代理上進行的研究將轉移到更大的運行。我們將在接下來驗證 32 和 64 GPU 的擴展。
解決方案?從頭開始重寫所有內容,動機是與更大的社區分享。因此,這就是我現在正在做的事情。在接下來的幾周內,我將向社區發布各種訓練庫、博客文章、數據評分模型權重以及 w&b 風格的可視化和實驗跟踪系統。未來還有完整推理引擎等的路線圖。由於雄心的範圍和全面重寫,這將比我希望的時間長一些,但我希望社區能像我一樣覺得這有用。
---
參考文獻:
- [DeepSeek-V3 技術報告](
- [Inside Kaiju: 大規模構建對話模型](
- [Moonlight: 一個計算高效的 MoE 訓練框架](
- [Seed-Coder 技術報告](
- [OLMo-3: 其類別中最佳的完全開放模型](
(來自 nviz 儀表板的早期 fp8 訓練運行的圖片)

1.14K
需要 AI 將 @SolanaConf 的最佳公告和有影響力的片段剪輯成一個 30 分鐘的視頻

Frank12月13日 22:43
breakpoint 的內容令人驚訝地達到 S 級
內容豐富,團隊發佈重大公告,快速上傳片段
快到 2026 年了,沒有人能像 solana 一樣做到這一點,甚至連接近的都沒有
2.55K
熱門
排行
收藏
