近期，HuggingFace 發布的超過 200 頁的超長技術博客，系統性地分享訓練先進 LLM 的端到端經驗。

博客的重點是 LLM 開發過程中「混亂的現實」。它坦誠地記錄了哪些方法有效、哪些會失敗，以及如何應對實際工程中遇到的陷阱。內容基于團隊的實際項目經驗，特別是他們近期使用 384 塊 H100 GPU 訓練 3B 參數模型 SmolLM3 的過程。

博客中提供了深入的技術細節、代碼片段和調試技巧，對于有興趣親自構建 LLM 的讀者來說非常有指導意義。

下面是對博客內容的概述，非常推薦感興趣的讀者閱讀原文。

• 博客地址：https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#positional-encodings--long-context

訓練羅盤：Why→What→How

這一部分是在投入技術細節（如何訓練）之前，提出了一個關鍵問題：「你是否真的需要訓練這個模型」？

鑒于（如 Qwen、Gemma、Llama 等）世界級開源模型層出不窮，大多數人可能并不需要從頭開始訓練自己的模型。

Why

文章列舉了一些不應該訓練模型的錯誤理由，例如：「我們有閑置算力」、「別人都在做」或「AI 是未來」。

然后提供了一個流程圖，幫助你思考是否真的訓練一個自己的模型。

當你發現：現有模型不可用 —> 提示詞工程無法解決 —> 微調無法解決，你就可以考慮從頭開始訓練了。

定制化預訓練通常適用于三個主要領域：

• 研究： 你有一個明確的科學問題需要回答。例如，測試新的優化器、探索模型能力（如僅用強化學習）或測試新的數據集（如純合成數據）。
• 生產： 你的業務有無法被滿足的特定需求。如 DNA、法律、金融等高度專業化的詞匯或邏輯； 需要在特定硬件（如無人機、本地 FPGA）上運行，或有嚴格的延遲要求；處于受監管行業，需要對訓練數據和模型行為有 100% 的控制和可追溯性。
• 戰略開源： 你發現并有能力填補當前開源生態系統中的一個特定空白。

What

一旦你明確了「Why」，就可以推導出「訓練什么 (What)」。包括模型類型（密集型、MoE、混合型、某種新型）、模型大小、架構細節和數據混合。

同時前面的領域目標決定了你的訓練決策：例如，為設備端運行 —> 訓練小型高效模型；需要多語言能力 —> 使用更大的 tokenizer 詞匯表；超長上下文 —> 混合架構。

這個決策過程分為兩個階段。規劃：將你的約束（來自「Why」）映射到具體的模型規格；驗證：通過系統性的實驗（消融實驗）來測試你的選擇。

文章指出了成功 LLM 訓練團隊的兩個關鍵特質：

• 迭代速度： 訓練 LLM 是一個「邊訓練邊學」的過程。能夠快速、頻繁地（例如每季度而不是每年）迭代訓練新模型的團隊，會進步得更快。
• 數據管理： 最優秀的團隊是那些「癡迷于高質量數據」的團隊，數據質量的影響遠超架構選擇。

文章還建議，預訓練團隊一開始不需要很多人（2-3 人足矣），關鍵是配備足夠的算力并保持快速迭代。

每一個大型模型都始于一個小型消融

在開始訓練 LLM 之前，需要做出一系列關鍵決策（架構、優化器、數據組合等）。人們常以為這些決策是靠深思熟慮得出的，但僅憑推理是不夠的，因為 LLM 的行為常常反直覺。

一個典型的例子是：使用看似「最高質量」的 arXiv 科學論文數據，反而可能會損害模型（尤其是小模型）的性能，因為它過于專業化，缺乏通用文本的多樣性。

既然純粹的思考行不通，答案就是像經驗主義者一樣「運行大量實驗」（即消融實驗）。

設置消融實驗的完整流程：

選擇你的基線

不要從零開始，應該選擇一個已被驗證的、成熟的架構（如 Llama 3.1、Qwen3、Gemma3）作為起點，這樣可以繼承所有已知的優化和穩定性經驗。

基線雖好，但并非為你量身定制，因此需要修改。然而，「任何架構上的改變都伴隨著風險」。為此，必須遵守「去風險」的紀律，即：「除非你測試過它確實有幫助，否則不要改變任何東西。」

修改的難點在于組件太多且相互作用。你不能測試所有組合。正確的方法是：一次只測試一個有潛力的變更。如果它有效，就將其整合，使其成為新的基線，然后再測試下一個變更。

選擇訓練框架

這是一個關鍵的技術決策，需要在功能、穩定性和吞吐量之間權衡。

文章對比了幾個主流框架：

• Megatron-LM / DeepSpeed：功能強大，經過實戰考驗，但代碼庫龐大且復雜。
• TorchTitan：更輕量級，易于上手和實驗，但相對較新。
• nanotron (作者自研)：提供了完全的靈活性，但需要大量投入來開發和測試。

設計消融實驗

實驗必須足夠快（以便快速迭代）和足夠可靠（結果能外推到最終模型），有兩種主要方法：

• 全尺寸模型，少量數據： 使用最終模型的尺寸（如 SmolLM3 使用 3B 模型），但在更少的 Token 上訓練（如 100B 而非 11T）。
• 小型代理模型： 如果目標模型太大（如 1T 參數），則使用一個按比例縮小的代理模型（如 3B 模型）進行實驗。

接下來文章介紹了其基準消融設置（1B 的 Llama 模型，訓練 45B Token），并展示了配置文件的關鍵部分（數據、模型、優化器等）。

理解哪些有效：評估

文章指出，評估實驗結果時，只看訓練損失 (Loss) 是不可靠的。例如，訓練維基百科的 Loss 更低，但不代表模型能力更強；更換分詞器也會導致 Loss 無法直接比較。因此，必須使用更細粒度的下游評估。

一個可靠的評估任務應具備四個標準：單調性、低噪聲、超隨機性能和排名一致性。

特別是在早期實驗中，「完形填空（CF）」格式比「多項選擇（MCF）」更優越，因為后者（如 MMLU）在模型訓練的早期階段表現接近隨機，無法提供有效的早期信號。

消融實驗的真正價值不僅在于構建好模型，更在于它為未來的調試提供了信心：當主訓練不可避免地出錯時，系統性的實驗結果能幫助團隊快速定位問題。

不過，這種價值的成本極其昂貴。以 SmolLM3 為例，消融和調試所消耗的 GPU 時間超過了主訓練運行的一半。

模型架構設計

這部分內容詳細闡述了設計和確定 LLM 架構的完整決策過程，從高層目標到具體的組件選擇和超參數設置。

文章以一個名為 SmolLM3 的 3B（30億參數）模型為例，系統性地展示了如何從零開始構建一個模型的「藍圖」。

文章深入探討了構成現代 Transformer 的核心架構選擇并指出，當今的模型（如 Qwen3、Gemma3）共享 Transformer 基礎，但通過組件改進（如 GQA、位置編碼）來解決具體問題（如內存、穩定性）。

• 注意力機制：這是推理時的主要瓶頸，關鍵在于 KV 緩存。文章對比了 MHA（標準，高內存）、MQA（極端壓縮，可能損失性能）和 GQA（分組查詢）。消融實驗證實，GQA 在性能上與 MHA 相當，但極大節省了 KV 緩存，是 SmolLM3 的最終選擇。
• 長上下文：文章探討了兩種策略。首先是文檔掩碼，在訓練「打包」的數據時，它能防止模型關注到序列中不相關的其他文檔，這被證實對長上下文擴展至關重要。其次是位置編碼，標準 RoPE 在長序列上外推能力有限。SmolLM3 采用了 NoPE（實為 RNoPE）的混合策略，即交替使用 RoPE 層（處理短上下文）和 NoPE 層（處理長距離檢索），消融實驗表明這種方法在不犧牲短上下文性能的同時，為長上下文打下了基礎。
• 嵌入共享：對于 SmolLM3 這樣的小模型，嵌入層占比較大。文章通過消融實驗證明，將參數用于增加模型深度（更多層）比用于「解綁」輸入和輸出嵌入層更有效。因此，SmolLM3 采用了嵌入共享。
• 穩定性：為防止大規模訓練崩潰，文章測試了 Z-loss、QK-norm 等技術。最終，SmolLM3 采用了 OLMo2 的技巧，即移除嵌入層的權重衰減，以提高穩定性。

文章對比了密集型、MoE（混合專家）和 Hybrid（混合模型）三種架構。MoE 通過稀疏激活（只激活部分「專家」）來用更少的計算換取更大的容量，但內存占用極高。Hybrid（如 Mamba）則通過線性注意力或 SSM 來解決 Transformer 在長上下文上的計算瓶頸。SmolLM3 因其「端側部署」的目標（內存受限）而堅持使用密集型架構。

隨后，文章轉向了常被低估的 Tokenizer。選擇分詞器涉及詞匯量大小（影響壓縮率和嵌入矩陣大小）和算法（BPE 最常用）。

文章引入了「Fertility」（每詞平均 Token 數）和「連續詞比例」作為評估指標。通過對比 Llama3、Gemma3、Qwen3 等，SmolLM3 最終選擇了 Llama3 的 128k 詞匯表，因為它在目標語言和模型大小之間取得了最佳平衡。

接下來，文章探討了決定訓練過程的核心要素：優化器、學習率和批量大小。文章指出，直接借用其他模型的超參數雖然簡單，但可能不是最優的，因為這些值是針對特定的架構、數據和約束條件優化的。

最后回顧了關于模型規模（參數量 N）和數據量（Token 數 D）的經典權衡。

數據管理藝術

這部分內容詳細闡述了「數據策展的藝術」，強調了在 LLM 訓練中，數據是決定模型「學到什么」的關鍵因素，其重要性甚至超過了模型架構。

模型架構決定了模型如何學習，而數據則決定了模型學習的內容。如果數據質量差或「混合比例」不當，再好的架構或超參數也無法挽救。

文章指出，構建一個優秀的數據集并不僅僅是收集好數據，而是要設計一個訓練混合。

例如，過分增加代碼數據的比例（「上采樣」）會隱式地減少其他數據的比例，可能損害模型的通用能力。

此外，對于像 SmolLM3 這樣需要 11T Token 的超長訓練，如果只使用「最高質量」的數據，將導致嚴重的數據重復，這對模型性能有害。

為了解決這些平衡性問題，現代 LLM 訓練已經從「靜態混合」（如 GPT-3）演變為多階段訓練（如 Llama3、SmolLM2）。這種方法在訓練過程中動態地改變數據混合比例。

其核心洞察是，模型的最終行為深受其在訓練末期看到的數據的影響。因此，策略是：

• 在訓練早期，使用豐富、多樣化但質量稍低的數據（如網頁文本）。
• 在訓練末期（特別是在學習率衰減的「退火階段」），引入稀缺、高質量的數據（如專業數學和代碼數據集），以最大化其影響力。

何時改變混合比例通常由性能驅動的干預決定：例如，當發現模型的數學能力停滯不前時，就是引入更多高質量數學數據的信號。

確定數據配方的過程依賴于系統的消融實驗。與架構不同，數據混合的消融實驗必須在目標模型規模（例如 3B）上運行，因為模型的容量會顯著影響它吸收不同數據的效果。

文章介紹了兩種主要的實驗方法：

• 從零開始的消融：使用目標模型（如 3B）進行短期訓練（如 100B Token），以測試不同的初始混合比例。
• 退火實驗：這是測試多階段課程的關鍵。團隊會從主訓練中（例如在 7T Token 處）獲取一個檢查點，然后用新的數據混合（例如 40% 基線 + 60% 新數學數據）繼續訓練一小段時間（如 50B Token），以驗證新數據在后期引入的有效性。

作者提到，盡管存在 DoReMi 等自動優化方法，但在他們的實踐中，仔細的手動消融實驗仍然是 SOTA 模型（包括 SmolLM3）確定數據混合的最佳途徑。

文章最后以 SmolLM3 為例，展示了如何應用這些原則。

堪比「馬拉松」的長周期訓練

從前面來看，此時已經準備好了大部分的工作，經過驗證的模型架構、最終確定的數據混合方案、調好的超參數，剩下的任務就是搭建好基礎設施（這在最后講解），然后「開始」訓練。而訓練是一個堪比「馬拉松」的長周期過程，過程中可能會出現各種情況，所以要做好面對各種挑戰的準備。

而這部分主要講的就是，訓練前的「飛行前檢查」、過程中那些不可避免的意外狀況，以及如何保持系統穩定、不中斷。

文章以啟動 SmolLM3 前執行的「起飛前檢查」清單為例，展示了在開始訓練前的準備工作，包括基礎設施準備、評測系統準備、Checkpoint 與自動恢復機制、指標日志記錄、訓練配置復核等。

尤其是在最后按下「訓練」按鈕之前的訓練配置復核，一定要仔細檢查訓練配置文件、啟動腳本、Slurm 提交命令等，以確保參數、路徑、環境變量都正確無誤。

當然，即使做好了萬全準備，在規模化訓練過程中，也依然會遇到一些問題。比如在訓練啟動后的短短數小時內系統的吞吐率（throughput）驟然下滑、持續下滑，以及在引入新的 dataloader（數據加載器） 后，雖然吞吐率下降的問題不再出現，但損失曲線（loss curve）卻明顯變得更加噪聲化，波動比以前大得多等等，各種問題隨時都會出現，所以要做好及時應對各種問題的準備。

另外，文章還指出，在現代 LLM 的預訓練中，通常會采用多階段訓練策略（multi-stage training），每個階段使用不同的數據混合比例，并在最后階段進行上下文長度擴展。比如 Qwen3 就采用了通用階段、推理階段、長上下文階段的三階段訓練方案。而 SmolLM3 采用了類似的理念，在訓練過程中計劃性地引入高質量數據集并擴展上下文長度，同時根據性能監控結果進行動態調整。

超越基礎模型——2025 年的后訓練階段

這部分主要介紹了模型的后訓練（Post-training）。以 SmolLM3 為例，在完成預訓練（Pre-training）后就擁有了 SmolLM3 的原始能力（raw ability），但在 GPU 的溫度還未降下之前，就進入了后訓練（Post-training）階段。

當然，在這一切開始之前，就像預訓練階段一樣，你也要問自己三個問題：

• 你是不是真的需要后訓練？如今許多開源權重模型在各種任務上已能媲美閉源模型，其中一些甚至可以在本地運行（通過量化與低計算配置）。如果你的目標只是一個通用助手，那么 Hugging Face Hub 上的現成模型可能已經足夠好，沒必要重新訓練。
• 你是否擁有高質量、領域特定的數據？后訓練的最大價值體現在特定任務或領域上。若通用模型在這些場景下表現欠佳，高質量的專用數據能讓你定向優化輸出效果。
• 你能衡量成功的標準嗎？如果沒有清晰的評估標準，你將無法判斷后訓練是否真的給你帶來了改進。

如果確定了要進行后訓練，那么又出現一個問題，你想要后訓練實現什么目標：一個嚴格執行指令、幾乎不偏題的模型？一個多才多藝的助手，能靈活切換語氣與角色？一個擅長數學、代碼或推理任務的「思考引擎」？還是一個能多語言流暢交流的通用對話體？

只有明確目標才能選擇合適的技術路線。

而一旦前面這幾個問題答案都明確之后，接下來就要開始進行訓練了，主要步驟包括：

• 監督微調（SFT）：注入核心任務能力；
• 偏好優化（PO）：直接從人類或 AI 偏好中學習；
• 強化學習（RL）：在監督數據之外提升模型的可靠性與推理深度；
• 數據篩選與整理（Data Curation）：平衡數據的多樣性與質量；
• 評估體系（Evaluation）：持續跟蹤進展并及早發現性能回退。

文章以 SmolLM3 為例，回答了在進行后訓練階段需要回答的幾大問題：

SmolLM3 是一個優秀的基礎模型，但要在發布前變得可用，必須經過后訓練。同時，混合推理模型（如 Qwen3 系列）正快速興起，但開源社區中缺乏公開可復現的訓練配方。因此，SmolLM3 的后訓練目標有兩點：打造一個可實用的高質量模型；貢獻一份完整開源的訓練方案，讓它能與 Qwen3 的 1.7B 和 4B 模型一同位列行業前沿。

而在后訓練的實戰階段時，需要做很多事情，比如選擇后訓練框架、工具等。不同的框架各自支持不同的算法類型、微調方法、可擴展能力等。

文章總結了一些主要的框架在后訓練各環節中的支持范圍，涵蓋從監督微調到偏好優化，再到強化學習等核心領域的能力對比。

而在主要步驟階段，文章解答了為何幾乎所有的后訓練流程都是以監督微調為起點，原因很簡單：

• 便宜：相較于 RL，SFT 對算力要求低得多。你通常可以在較短時間內、用較少 GPU，獲得顯著性能提升——而無需「燒光硅片」。
• 穩定：不同于 RL 那種對獎勵設計和超參數極度敏感的訓練方式，SFT「開箱即用」——幾乎不會崩。
• 是最好的基線：一個良好的 SFT 檢查點（checkpoint）通常能提供你所需的大部分性能提升，并讓后續如 DPO 或 RLHF 等方法的訓練更加高效。

基礎設施：被忽視的關鍵一環

這部分主要是將基礎設施，因為大多數從事模型訓練的人都非常關心模型架構和數據質量，而忽視了底層的基礎設施，認為「租幾塊 GPU，撞上 Pytorch 就可以了」。然而并非如此，如果用一個比喻來形容，那就是「預訓練是蛋糕坯，后訓練是上面的糖霜和櫻桃，而基礎設施就是工業級烤箱」。沒有它，一切無從談起。

像在訓練 SmolLM3 時，使用了 384 塊 H100 GPU，持續了將近一個月，總共處理了 11 萬億個 token，工程量之浩大，過程之繁瑣。

文章指出，對于基礎設施，你首先需要知道的是，GPU 的構成、內存層級的工作方式、CPU 與 GPU 之間的通信方式、獲取 GPU 時的注意事項，以及在投入長期訓練任務前如何測試它們。

CPU 與 GPU 之間的通信路徑

其中，需要注意的是，在大型模型訓練中，擁有足夠多且高速的 GPU 固然重要，但由于 LLM 訓練通常持續數周甚至數月，持續追蹤 GPU 的健康狀態就成為了保持訓練穩定性的關鍵。

文章以 SmolLM3 的訓練為例，列舉了對 GPU 進行全面診斷的工具：

• GPU Fryer（內部工具）：一款 GPU 壓力測試工具，用于檢測是否存在熱降頻；顯存錯誤；性能異常等潛在問題。
• NVIDIA DCGM（數據中心 GPU 管理器）：一款被廣泛使用的 GPU 診斷與監控工具，能夠執行深度檢測，以驗證 GPU 硬件、監控性能，并定位故障或功率異常的根本原因。診斷范圍包括：計算單元完整性；PCIe 連接穩定性；內存完整性；熱穩定性等。

最后，關于訓練模型到底要用多少塊 GPU，文章指出決策的核心在于訓練時間、成本與擴展效率之間權衡的過程。用一個公式來估算就是：

其中，所需總 FLOPs，訓練模型所需的計算量，取決于模型規模、訓練 token 數量和架構設計；單 GPU 吞吐量，即每張 GPU 際每秒可執行的 FLOPs 數量；目標訓練時長，就是你期望訓練完成所需的時間。

以 SmolLM3 為例，根據模型規模 30 億參數、訓練 token 數：11 萬億、目標訓練時間約 4 周等信息，代入 GPU 需求公式得出的結果約為 379 GPUs。

這一計算結果指向了一個合理的范圍：約 375–400 張 H100 GPU，而最后實際上是部署了 384 張 H100，這一規模既符合我們的并行化策略（parallelism strategy），也為訓練中可能出現的節點故障、重啟等意外情況預留了充足的緩沖空間，從而確保模型能在約 4 周時間內順利完成訓練。

而這也再次證明基礎設施對于模型訓練的重要性，不要忽視它！