重點
- NVIDIA 在 arXiv.22019 公開一份完整的 midtraining 配方：在預訓練與 SFT 之間，用 256K 上下文訓練數千億 token 的軟體工程資料，為代理人後訓練打底。
- 資料七成五是自然的軟體工程資料（PR、整個 repo、commit 歷史、建置與 CI log），代理人軌跡只佔約一成，而且工具回傳內容不算 loss。
- Nemotron 3.5 Lightning（30B／3B active）經 500B token midtraining、再做相同的完整 SFT 後，SWE-bench Verified 從 60.7 升到 64.5，Multilingual 從 55.8 升到 62.8。
- 較大的 Nemotron 3.5 Super（120B／12B active）經 280B token 後，DeepSWE 從 11.7 升到 15.7；但 SWE-bench Multilingual 與 Pro 沒有進步。
- 作者自己點出的限制：每組比較只跑一次、只在 Nemotron 上測、沒有跟「把同樣 token 花在更長的預訓練或 SFT」比較，RL 實驗也很短。
要解決什麼問題
Qwen3-Coder-Next、GLM-5、Kimi-Dev、Composer 2 等寫碼模型，都在收斂的基礎模型上加了一段數千億 token 的 midtraining，但技術報告多半只粗略帶過，很少交代資料怎麼建、怎麼過濾、怎麼配比，也很少量化每個設計選擇的影響。
論文點出兩頭的落差：
- 預訓練通常只用 4K 到 8K 的短上下文（Nemotron 是 8K 預訓練再延伸到 1M），語料裡幾乎沒有代理人互動；而整個 repo、commit 歷史、PR、建置 log 這類資料動輒數萬到數十萬 token，放不進去。
- SFT 以合成對話資料為主；已有研究指出 SFT 拉太長會削弱模型之後從 RL 得到的進步，作者說自己的訓練也觀察到這點。
Midtraining 就放在兩者之間，讓一部分學習從 SFT 搬出來，讓 SFT 可以維持短一點。
資料配方
整體配比（依訓練 token 計）：
| 來源 | 不重複 token | 配比 | 500B 執行中實際看到 | epoch |
|---|---|---|---|---|
| Issue–PR | 216.9B | 40.8% | 205.2B | 0.95 |
| 整個 repo | 104.1B | 20.0% | 100.7B | 0.97 |
| 代理人軌跡 | 39.4B | 10.0% | 50.3B | 1.28 |
| Diff 資料 | 16.0B | 3.0% | 15.1B | 0.95 |
| 建置與 CI log | 6.5B | 1.2% | 6.1B | 0.95 |
| 預訓練資料回放 | 約 2.0T | 20.0% | 100.7B | 0.05 |
| 長上下文資料 | 67.4B | 5.0% | 25.2B | 0.37 |
各來源的做法：
- Issue–PR：從至少 10 顆星的公開 GitHub repo 收集已合併的 PR，結合 repo 快照、PR 描述、連結的 issue 與 review 討論，共 1,210 萬個 PR。有連結 issue 的 PR 由結構化的 LLM 評審檢查 issue 和 patch 是否相符，列出七種失敗模式（例如 revert、issue 引用錯誤、只修一部分、PR 做的事遠多於 issue）。
- 整個 repo：對 14 種語言建 import 圖，只保留至少 20% 程式檔有 import 到同 repo 其他檔案的 repo（Ruby 因 Rails 自動載入放寬到 10%）。README 放最前面，接著依 import 圖深度優先排列，讓相關檔案相鄰；共約 104B token。作者觀察到依賴排序比字母排序更能拉開強弱模型的 bits-per-byte 差距。
- Diff 資料：兩種樣本。一是多檔編輯：給 PR 變更前的檔案，要模型寫出變更後的樣子；二是程式演化文件：一個檔案的初始狀態、由舊到新的真實 commit 序列，再到最終狀態。
- 建置與 CI log：LogHub 的系統 log、GitHub Actions 執行 log 與 workflow 歷史，另有 632 筆「log 片段配診斷」的樣本。
- 代理人軌跡：約 39B token，超過 100 萬條軌跡、約 50 萬個不同查詢、3,000 萬次工具呼叫，涵蓋 OpenHands、OpenCode、SWE-agent、Codex、Claude Code、Terminus 等十多種 scaffold。品質最高的軌跡保留給 SFT，midtraining 用的是其餘的。
所有來源都只留寬鬆授權，並對 SWE-bench 與 Terminal-Bench 去污染、遮蔽密鑰；重複的分隔符、hash、時間戳等不希望模型模仿的內容不算 loss。
訓練設定
- 上下文長度 256K，batch 為 64 條序列，Megatron-LM、GB300 GPU。
- 學習率短暫 warmup 後維持常數：Lightning 用 5e-5，Super 用 1e-5。
- 評估協定：對 midtraining 前後的模型做完全相同的 SFT 再比較。SFT 有兩種預算，短 SFT 33B token、完整 SFT 100B token。
作者特別說明，LoCoDiff、RepoBench、bits-per-byte 這類基礎模型指標雖然會隨 midtraining 進步，但跟後訓練結果對不太上，不足以拿來決定配方，所以改用固定的短 SFT 當訊號。
主要結果
Nemotron 3.5 Lightning：token 量拉到 500B
完整 SFT 後的 pass@1（%）：
| midtraining token | SWE-bench Verified | SWE-bench Multilingual | Terminal-Bench 2.0 | SWE-bench Pro |
|---|---|---|---|---|
| 0（基礎模型） | 60.7 | 55.8 | 22.6 | 32.0 |
| 100B | 64.1 | 57.4 | 22.5 | 34.9 |
| 300B | 63.5 | 62.0 | 24.9 | 36.3 |
| 500B | 64.5 | 62.8 | 23.6 | 35.5 |
Verified 與 Pro 的進步大多在 100B token 就到位，Multilingual 一路升到 500B，Terminal-Bench 起伏較大，在 300B 最高。pass@k 在四個基準上也都升了 2.3 到 4.7 分，作者據此說 midtraining 擴大了模型解得出的題目範圍，不只是讓它更穩定。
另一個變化是上下文用得比較省：沒有 midtraining 時，4.1% 的 SWE-bench Pro rollout 因塞滿 256K 上下文而失敗，500B 之後只剩 0.6%。
Nemotron 3.5 Super：換大模型
完整 SFT 後的 pass@1（%）：
| midtraining token | SWE-bench Verified | SWE-bench Multilingual | SWE-bench Pro | DeepSWE | BrowseComp |
|---|---|---|---|---|---|
| 0（基礎模型） | 72.9 | 69.0 | 53.9 | 11.7 | 61.8 |
| 65B | 72.5 | 68.2 | 52.4 | 13.5 | 61.8 |
| 280B | 74.3 | 67.9 | 51.8 | 15.7 | 64.8 |
進步最明顯的是最難的 DeepSWE。Multilingual 與 Pro 在完整 SFT 後反而低了 1.1 與 2.1 分，短 SFT 後則持平或略高，作者不把這些差異解讀為一致的效果。
換 harness 也撐得住
開源模型會被接到各種代理人框架上，所以作者測了不同 harness。Super 在 65B token、短 SFT 後，五個 harness 的 SWE-bench Verified 平均進步 8.6 分、Terminal-Bench 2.1 平均進步 6.8 分；Lightning-8K 在完整 SFT 後，六個 harness 的 SWE-bench Verified 平均進步 11.6 分，其中 Codex harness 進步最多（+19.0）。作者也說明，因為沒有只用單一 scaffold 軌跡訓練的對照組，分不出這是 scaffold 多樣性還是軌跡本身的效果。
消融實驗
- 代理人軌跡是主要來源：在 Lightning-8K 上做 100B token 對照，只用自然資料的版本在完整 SFT 後，SWE-bench Verified 只比基礎模型多不到 1 分；加入軌跡後再多 3.0 分。作者仍把自然資料留作大宗，理由是它對檔案狀態追蹤、跨檔建模與 harness 穩健性有幫助，而且軌跡佔太多就等於一段更長的 SFT。
- 工具回傳不算 loss：把工具回傳也納入 loss，SWE-bench Verified pass@1 從 37.8 掉到 27.5，約少 10 分（這組用的是較早版本的 SFT 配方）。作者推測檔案內容、測試 log 這類回傳又長又雜，會占用學習代理人自身動作的能力。
- Diff 資料撐起 LoCoDiff：10B token 的對照中，不含 diff 資料時 LoCoDiff 完全重建的比例是 1.3%，一半換成 diff 資料後升到 29.8%。
- 學習率不能拉太高：Lightning-8K 以 5e-5 訓練 100B token 後，MATH-500 從 79.7 掉到 61.7；1e-5 時是 78.8。
- 回放比例：20% 回放下，Super 到 65B token 時四類通用能力基準都在起點 1.2 分以內；試過 40% 沒有明顯更好。
- 順便延伸上下文：只做 256K midtraining 的 Lightning-8K，在 RULER 128K 以內跟長上下文版基礎模型差約 5 分，256K 則落後 14 分；midtraining 之後再接長上下文階段，64K 到 256K 每個長度都勝過原本的長上下文模型（256K：79.7 對 76.6）。
限制
論文自己列出的限制：
- 代理人基準雜訊大、每組比較只跑一次，一兩分的差距（特別是 Terminal-Bench）可能只是執行間的變異；Super 上 SWE-bench 的執行間變異約 1 分、DeepSWE 約 2 分。
- 沒有跟「同樣的 token 拿去延長預訓練或 SFT」比較。
- 只在 Nemotron 上測，主要也只測代理人寫碼。
- SFT 用的是偏代理人的資料配比，不是完整的通用後訓練配比。
- RL 只在 Lightning-8K 上跑了單一 seed、20 步的 GRPO，只能說明 midtraining 的領先在 RL 開頭沒有消失（SWE-bench Verified 一路維持約 2 分領先），不能說明它提高了 RL 能帶來的進步。
資料處理腳本與訓練集中繼資料，作者說會在之後的版本釋出。