← 目錄

K1 論文詳解

2026-10-08


跨 Tokenizer 的 On-Policy 蒸餾:與其追求對齊覆蓋率,不如確保監督訊號可靠

Rethinking Cross-Tokenizer On-Policy Distillation: From Alignment Coverage to Supervision Reliability

Bingxi Hou、Guochao Jiang、Guofeng Quan、Weiqing Li、Wenfeng Feng、Guohua Liu、Yuewei Zhang▲ 153Hugging FacearXiv
On-Policy Distillation跨 Tokenizer知識蒸餾Reverse KL數學推理與程式碼生成

背景

知識蒸餾(distillation)是把大模型的能力轉移給小模型的標準手法。近年 On-Policy Distillation(OPD)特別受關注:學生模型先自己生成回答,再由老師模型對這些回答逐 token 給出機率分佈作為回饋,學生據此調整。相較於只模仿老師固定輸出的做法,OPD 看的是學生自己會走到的路徑,能減少訓練與推論之間的分佈落差。

只要老師與學生使用同一套 tokenizer,事情就單純:每個位置的詞表一致,可以直接比較兩個機率分佈。但現實中最想配對的組合常常來自不同家族,例如用 Qwen 當老師、Llama 當學生,各自的 tokenizer 切字方式與詞表都不同。這時要比較老師與學生的預測,必須同時在兩個層面做對齊:序列層(同一段文字在兩邊被切成哪些 token)和詞表層(兩邊的詞表怎麼對應)。

過去的跨 tokenizer 方法,如 ULD、Extended ULD、GOLD、SimCT,大多沿著「盡量擴大對齊覆蓋率」的方向設計。如果某段文字兩邊切法不同,就想辦法為它設計損失,讓每個學生生成的 token 都有監督訊號。這篇論文反過來問:擴大覆蓋率真的有幫助嗎?還是多出來的監督其實品質堪慮?

方法

論文並未提出複雜的新架構,而是拆解問題,提出一組簡潔的設計與診斷。

第一,嚴格 1:1 對齊群組(strict 1:1 groups)。 在學生生成的文字中,有些位置剛好是一個學生 token 對應一個老師 token,兩者涵蓋完全相同的文字區間。在這些位置,兩邊預測的是「同一件事」,分佈可以直接比較。其餘位置則是多對多的「不匹配群組」(mismatch groups)。

第二,共享詞表。 在嚴格對齊位置,只取兩邊詞表的交集來比較分佈。論文發現交集保留了幾乎所有的機率質量。

第三,學生自選的 top-16 子集。 在每個嚴格位置,不用整個共享詞表,而是只取學生自己機率最高的 16 個 token,在這個子集上計算 reverse KL。這讓監督既精簡又集中在學生真正會生成的候選上。

第四,span MSE 作為對照。 為了提供完整覆蓋,作者在不匹配群組上額外加入 span log-probability 的 mean squared error:把整段 span 的對數機率加總後,要求老師與學生接近。這是擴大覆蓋率的典型做法,也正是論文要檢驗的對象。

第五,梯度診斷。 作者取用只用嚴格損失訓練的 checkpoint,量測 span 損失的梯度與嚴格損失梯度之間的 cosine similarity(方向一致性)與 norm 比值(相對大小),並用「把嚴格梯度隨機分成兩半互相比較」作為對照組,排除單純梯度雜訊的解釋。

實驗涵蓋三組異質師生配對:Qwen2.5-7B-Instruct → Llama-3.2-3B-Instruct、Granite-4.1-8B → Phi-4-mini-instruct、Granite-4.1-8B → Qwen2.5-7B-Base。另有 Qwen3-235B → Granite-4.1-8B 的大型老師實驗。評測包含數學(MATH500、GSM8K、AIME 2024–2026、AMC23、Minerva-Math)與程式碼(HumanEval、MBPP、LiveCodeBench)。

實驗結果

覆蓋率比想像中高。 詞表差異很大,但嚴格 1:1 群組仍涵蓋多數學生 token。以學生端覆蓋率計:Qwen→Llama 為 93.56%、Granite→Phi 為 96.98%、Granite→Qwen 為 85.57%。值得注意的是,Granite→Phi 的詞表 Jaccard 重疊只有 39.49%,覆蓋率卻接近 97%,說明「詞表差很多」與「嚴格對齊很常見」可以同時成立。

共享詞表幾乎不損失資訊。 在學生訓練前自行取樣的回答上,共享詞表在嚴格位置保留了 98.99–99.90% 的老師機率質量;top-16 子集仍保有 93.54–98.44%。

Top-16 與完整共享詞表幾乎打平。 主要結果(平均準確率):

  • Qwen→Llama:完整 32.86%、top-16 32.64%、最佳基線 31.59%(SimCT)
  • Granite→Phi:完整 42.49%、top-16 42.26%、最佳基線 41.75%(GOLD)
  • Granite→Qwen:完整 47.35%、top-16 47.06%、最佳基線 46.10%(SimCT)

top-16 與完整版只差 0.2–0.3 個百分點,卻一致優於四個被比較的跨 tokenizer 基線,領先幅度約 0.5–1.3 個百分點。論文也指出 top-16 保留了完整版至少 96% 的平均提升。在 Qwen3-235B → Granite-4.1-8B 的實驗中,Strict Top-16 取得 Math 51.29%、Code 73.62%、整體 62.46%。

加了 span 監督反而變差。 在不匹配群組加入 span MSE 後,監督覆蓋率達到 100%,但在 λ 從 0.25 到 1.5 的所有設定下,準確率都比只用嚴格損失低,降幅 0.27–1.20 個百分點。

梯度診斷提供了線索。 span 梯度與嚴格梯度的 cosine similarity 在 Qwen→Llama 與 Granite→Phi 接近 0,在 Granite→Qwen 甚至為負,也就是方向幾乎無關或相互牴觸。對照組(嚴格梯度的兩半互比)的相似度一致較高,顯示問題不在梯度本身噪音大。同時,span 對嚴格梯度的 norm 比值隨訓練急遽上升:Qwen→Llama 從 0.294 升到 1.942(約 6.6 倍),Granite→Phi 從 0.008 升到 0.233(約 29 倍),Granite→Qwen 從 0.015 升到 0.269(約 17.9 倍)。意即訓練越往後,這個方向不一致的訊號就越有話語權。

意義

這篇論文最有價值的地方,是把一個被默認的設計原則拿出來檢驗。「每個 token 都要有監督」聽起來合理,但數據顯示,在老師與學生切字方式不同的位置,硬湊出來的損失可能是弱對齊甚至衝突的訊號,多加反而扣分。對實務者而言,結論相當務實:跨 tokenizer 蒸餾不必處理複雜的多對多對齊,在嚴格位置上做簡單的 top-16 reverse KL 就能達到接近完整版的效果,還勝過現有基線。

這也有工程上的好處。只看 16 個候選 token,計算與記憶體負擔比對整個詞表小得多,適合在大詞表(十萬級以上)下做 OPD;而且讓你可以選擇更大、更強但來自不同家族的老師,不必被 tokenizer 綁住。

不過有幾點需保留。第一,梯度診斷只能「解釋可能的原因」,論文自己也用 "may help explain" 這種保守措辭,並非因果證明。第二,實驗集中在數學推理與程式碼,這類輸出結構相對規整,嚴格對齊本來就高;在多語言、長文生成或詞表差異更極端的情境,覆蓋率與結論是否成立仍待驗證。第三,各組準確率差距多在 1 個百分點內,需要留意不同隨機種子下的穩定性。

整體來說,論文把問題的重心從「如何覆蓋更多」改成「覆蓋的訊號靠不靠譜」,這個視角對未來設計跨模型蒸餾、甚至其他多來源監督的訓練流程,都有參考價值。

TRACE:用 rollout 的量化結果引導訓練,讓 MoE 模型的 FP4 強化學習追上 BF16

TRACE: Rollout-Guided Quantization-Aware Training for FP4 Reinforcement Learning of MoE Language Models

QwenXin Wang、Hao Yu、Zhengyang Zhuge、Bochao Mao、Zheng Li、Junda Feng、Yuyan Luo、Yi Zhang▲ 70Hugging FacearXiv
FP4強化學習MoE量化感知訓練LLM 後訓練

背景

用強化學習(RL)對 LLM 做後訓練時,最花時間和記憶體的往往不是梯度更新,而是 rollout,也就是讓模型大量生成回答再拿去算 reward。推理或長鏈 agent 任務的輸出動輒 128K tokens,rollout 常常佔掉一個 RL step 的大部分時間。因此社群開始用低精度(FP8,甚至 FP4)來跑 rollout,把權重、activation 和 KV cache 都壓小,吞吐量就能大幅提升。

低精度 rollout 有個老問題:train-rollout discrepancy。訓練端通常用 BF16(或另一套量化路徑)算 log-prob,rollout 端用 FP4 取樣。兩邊數值不一致,policy gradient 就會帶有偏差,嚴重時 RL 會不穩定或崩掉。FP4 只有十幾個可表示的值,這個落差比 FP8 更明顯。

論文指出,現有的 FP4 RL 方法(例如 Vanilla QAT、QaRL、QUADS、Score Centering)多半各自提高訓練路徑和 rollout 路徑的量化精度,卻沒有直接縮小兩條量化執行路徑之間的差距。另一條常見做法是先用 BF16 訓完,再做 post-hoc FP4 量化,但訓練時沒讓模型適應 FP4,最終品質會掉。

TRACE(Train-Rollout Quantization Alignment via Compact GuidancE)針對這個缺口設計,對象是 Mixture-of-Experts(MoE)語言模型。

方法

TRACE 由兩個部分組成。

1. Rollout-guided quantization-aware training。 一般 QAT 在訓練時模擬量化,rounding 由訓練端自己的數值決定。FP4 的 rounding 很敏感,值落在兩個相鄰 codeword 中間時,訓練端和 rollout 端只要有微小的數值差異,就可能各自捨入到不同的格子。

TRACE 的做法是把 rollout 端實際得到的 FP4 codeword 記下來,訓練時直接拿來引導捨入。對每個訓練端的 activation,它在相鄰的 FP4 codeword 之間選出最接近 rollout 結果的那一個,也就是 q* = argmin |q − q_rollout|。這樣兩條路徑的量化值會盡量對齊,discrepancy 從源頭被壓低,而不是各自追求「對 BF16 的誤差最小」。

2. Quantization-information caching。 完整保存 rollout 端每一層的量化資訊,儲存和通訊成本非常高。論文估算在範例模型上,每個 step 大約要 51 TB,實務上不可行。

作者先做了一個觀察:跨層來看,超過 99% 不一致的量化值,兩邊只差一個相鄰的 FP4 codebook 項目。這表示不需要完整記錄 rollout 的結果,只要保留足以判斷「該往上還是往下捨入」的資訊。TRACE 因此只保存 mantissa 位元與 scale 資訊,而且只保存較深層的部分,因為 rounding 的修正主要發生在深層。這大幅降低了儲存與通訊負擔,同時保留大部分引導效果。

另外,框架考慮了非同步訓練的情況。rollout 用的 policy 可能比訓練端的 policy 更新,這種 staleness 會削弱引導的效果,論文把它列為限制之一。

實驗結果

實驗涵蓋四個大型 MoE 模型:Qwen3.5-35B-A3B(35B 總參數 / 3.3B active)、Qwen3.5-122B-A10B(122B / 10B active)、Qwen3.8-Flash-Next(125B / 6B active)和 Qwen3.8-2.4T-A95B(2.4T / 95B active)。任務分成推理、coding 和長時程 RL 三類。

推理(Qwen3.5-35B-A3B),TRACE 對比 QUADS:

  • LiveCodeBench:66.4 vs 60.4
  • AIME 2024:86.3 vs 80.5
  • AIME 2025:78.5 vs 75.4
  • HMMT 2025:70.0 vs 59.0
  • 平均 75.3,與 BF16 rollout 基線的 74.9 相當

較大模型與長時程任務:

  • DeepSWE(122B):TRACE 33.0 vs QAT 28.8
  • Terminal-Bench(Flash-Next):70.6 vs QAT 60.4
  • GDPval(2.4T):90.2 vs QAT 88.7

與 post-hoc 量化比較:對 BF16 訓練出的 policy 事後做 FP4 量化(Vanilla NVFP4、4over6、H-Scale),表現最好的 H-Scale 平均為 71.4,TRACE 為 75.3,差距約 3.9 分。

效率:在 Qwen3.5-35B-A3B、128K 輸出長度下,聯合 FP4(權重/activation 加 KV cache)rollout 最高有 5.4× 的 rollout 加速(相對 BF16 rollout)。額外的 guidance 開銷不大,每個 RL step 為 713 秒,vanilla 聯合 FP4 rollout 為 664 秒,多了 7.4%。論文的吞吐量拆解約為:模型 forward 86%、KV dequantization 8%、quantization guidance 6%。

消融:只保留 5 層的量化資訊,平均分數從 75.3 掉到 73.4,所以快取多少層確實會影響結果。

另外有一個有趣的現象:一開始因為量化而下降的表現,會在 RL 過程中逐漸回升,最後追平甚至超過 BF16 rollout。論文認為這是 policy 在訓練中適應了低精度執行。

資料來源說明:以上細節取自 Hugging Face 論文頁,arXiv 摘要頁只提供摘要層級的內容,表格中的逐項數字我沒有另外交叉核對。

意義

首先,TRACE 說明 FP4 RL 的關鍵可能不在於把單邊量化做得更準,而在於讓訓練端與 rollout 端看到同一套量化結果。這個想法簡單,卻直接處理 off-policy 偏差的來源,在 FP4 這種格子很稀疏的精度下特別有價值。

其次,在實用面上,5.4× 的 rollout 加速加上 BF16 等級的 RL 結果,代表長輸出、agent 類 RL 訓練的成本有機會明顯下降。對 Blackwell 這類原生支援 NVFP4 的硬體,這條路線也很吻合。

第三,「訓練時就適應 FP4」比「訓完再量化」更好,而且訓練好的模型直接就是 FP4 友善的,部署時也能受益。從 75.3 對 71.4 的差距來看,這個差異不小。

不過也有一些保留。快取方案仰賴「只差一格」這個經驗觀察,是否能推廣到其他模型架構或量化格式,還需要更多驗證。非同步訓練中的 policy staleness 會削弱引導效果,這在大規模系統裡很常見。每步還是要多付出約 7% 的時間,並且需要在 rollout 與訓練之間傳遞額外的量化資訊,工程整合並不輕鬆。實驗幾乎都是 Qwen 系列 MoE,在其他模型家族上的表現尚待觀察。

CheckerBench:長時程 Agent 能自己寫出靜態分析 Checker 嗎?

CheckerBench: Can Long-Horizon Agents Synthesize Static-Analysis Checkers?

Humanlaya Data LabHang He、Li Wang、Hao Chen、Yuchen Shao、Yuling Shi、Lisheng Wang、Peiyang Liu、Goose Lin▲ 52Hugging FacearXiv
CheckerBench靜態分析Coding AgentBenchmarkCVE

背景

靜態分析工具(static analyzer)是軟體安全的基礎設施。Clang Static Analyzer(CSA)和 CodeQL 這類工具本身只是引擎。真正抓出特定漏洞的,是針對該漏洞模式寫成的 checker。寫 checker 很吃專業:要讀懂漏洞描述,理解程式庫的結構,把缺陷的語意(例如「某條路徑上沒拿鎖就存取共享資源」)改寫成分析器專屬的 API 邏輯,再反覆編譯、跑分析、看結果、修正。

近年的 coding agent benchmark 大多評估 patch generation、漏洞偵測或 issue 修復。這些任務的產出是一段修補程式碼,或一個「有漏洞/沒漏洞」的判斷。它們很少測一個更貼近真實安全工程的能力:agent 能不能在一個 repository 裡,從頭到尾做出一個可重複使用的分析工具?論文指出現有評測有四個缺口:

  • 評測目標不以 checker 為中心。
  • 互動時程太短,agent 沒有機會走完「寫、編譯、看回饋、修正」的迴圈。
  • 各系統的評測協定零散,結果無法互相比較。
  • 指標多半只量 patch 層級的正確性,不量 checker 特有的性質,例如 false positive 的控制。

CheckerBench 與配套的 CheckerLab 就是為了補上這些缺口。

方法

CheckerBench 的資料。 共 300 個可執行任務,來自 297 個 CVE、167 個 repository、85 種 CWE。語言涵蓋五個生態系:C/C++ 159 題(使用 CSA),Python 51 題,Java、JavaScript、Go 各 30 題(使用 CodeQL)。最常見的弱點類型是 CWE-787(out-of-bounds write)、CWE-125(out-of-bounds read)和 CWE-22(path traversal)。

每個任務包含:

  • 漏洞版與修復版兩個 revision
  • 釘死版本的分析環境(pinned toolchain)
  • 一份最小的 checker scaffold

任務刻意隱藏 CVE/CWE 標籤,避免 agent 靠記憶走捷徑。建構流程共六步:從 NVD 連結到修復 commit、重建可執行環境、打包任務、建立獨立 verifier、收集人工輔助的 rollout、品質控管與資料切分。

CheckerLab 的評測。 CheckerLab 是共用的評測框架,會獨立重新編譯 agent 提交的 checker,不信任 agent 自己回報的結果。它檢查:

  1. Build:能否獨立編譯。
  2. Diagnostic contrast:checker 必須在漏洞版報出問題,在修復版不報。
  3. Patch localization:消失的報告必須對應到 patch 實際修改的函式,避免 checker 只是碰巧在某處報警。
  4. False positives:在主線程式碼上的誤報比例。
  5. Tool use:互動輪數與工具呼叫次數。

主指標 Pass@1 是「單次獨立合成就通過完整評測」的任務比例。

受測對象。 7 個模型(GPT-5.6-Sol、Claude Opus 4.8、Qwen3.8-Max、DeepSeek-V4-Pro、GLM-5.2、Kimi-K3、HY4-Preview)搭配 3 種 agent harness(OpenCode、Claude Code、Hermes Agent),共 21 種 model-harness 組合,每種跑 3 次獨立重複。

實驗結果

整體表現偏低。 21 種組合的平均 Pass@1 只有 32.30%,最佳組合(Claude Opus 4.8 搭配 OpenCode)為 45.33%。平均 Build 成功率 78.25%,Diff. SR(通過漏洞/修復對比檢查)為 73.65%。也就是說,agent 多半能寫出能編譯、有一定對比效果的 checker,但要同時通過 patch 定位和誤報控制就困難得多。

語言差異明顯。 C/C++(CSA)最難,最強模型也只有 24.53%。Python 上 Claude Opus 4.8 領先,達 65.36%。Go 由 DeepSeek-V4-Pro 領先(53.33%)。Java 與 JavaScript 由 Qwen3.8-Max 領先(約 54% 與 53.33%)。以 harness 平均來看,DeepSeek-V4-Pro 在 Claude Code 上拿到 38.33%。

誤報率因 harness 而異。 通過的 checker 中,OpenCode 平均誤報率 6.63%,Claude Code 只有 1.97%。同在 OpenCode 下,Claude Opus 4.8 的誤報率為 13.79%(174 筆警告),GPT-5.6 為 0.00%(僅 7 筆警告)。高 Pass@1 不代表 checker 品質好,有些模型靠放寬偵測條件換取通過率。

失敗原因。 論文分析了 4,360 次失敗的 run:

  • 預算耗盡:25.32%
  • 合成流程不當:22.96%
  • 語意建模不足:21.15%
  • 誤報過多:15.96%
  • 差異偵測或定位問題:8.17%
  • 對單一 patch 過度擬合:3.56%
  • 缺少或無效的產物:1.83%
  • 編譯或註冊錯誤:1.05%

一個典型例子是,agent 規劃的是 path-sensitive 分析,實作時卻退化成單純的 AST matching,漏掉鎖與控制流條件。設計想得到,但寫不出來。真正卡住的是語意建模與流程,不是語法層級的編譯錯誤。

時間預算與 ablation。 Pass@1 隨時間累積:10 分鐘 7.24%、30 分鐘 26.05%、50 分鐘 32.30%,40 分鐘就拿到 93.02% 的成功案例,邊際效益遞減。對 DeepSeek-V4-Pro 搭配 OpenCode 的 ablation 顯示:

設定Pass@1
完整系統39.67%
移除 skills 與 strategy references8.33%
隱藏執行回饋13.33%
一次性生成(one-shot)0.33%

移除 skills 庫讓表現掉約 79%。一次性生成幾乎全滅,可見迭代回饋是這類任務的核心。

與既有方法比較。 在 61 個 Linux kernel 任務上,論文方法的 valid-checker 率為 80.3%,先前的 checker 合成系統 KNighter 為 67.2%。移除 skill library 後降到 29.5%。

資料污染檢查。 論文做了時間點分析(Claude Opus 4.8 有 3 題、GLM-5.2 有 1 題的 CVE 在模型發布後才公開),也在 100 題補充集上比較原始、改寫與替換識別字三種輸入。識別字替換使 Claude Opus 4.8 的 Pass@1 下降 3 個百分點,DeepSeek-V4-Pro 下降 2 個百分點。精確的 CVE 回憶率降了 7–9 個百分點,對 Pass@1 影響有限。這說明「認得這個漏洞」只帶來有限的好處,主要挑戰仍是合成能力。

意義

對 agent 研究: CheckerBench 把評測從「產出一段 patch」推進到「產出一個可獨立驗證、可重複使用的工具」。這更接近長時程 agent 的真實場景:目標模糊、需要多輪工具互動、成功與否要由獨立 verifier 判定。32.30% 的平均值表示這個能力還遠談不上成熟。

對安全工程: checker 一旦寫好,就能在整個程式庫、甚至跨專案反覆執行,價值遠高於一次性的 patch。如果 agent 能可靠地把 CVE 轉成 checker,就能把一次漏洞修復擴展成一整類漏洞的持續防護。不過目前 C/C++ 最高只有約 25%,而這正是記憶體安全漏洞的主戰場,離實用還有距離。

實務啟示:

  1. 只看 Pass@1 不夠,要一併看誤報率。
  2. harness 與 skills 的設計對結果影響極大,不亞於換模型。
  3. 執行回饋不可或缺,隱藏回饋就掉到 13.33%。
  4. 預算耗盡占失敗的四分之一,可見 agent 在規劃與時間分配上仍有改善空間。

限制: 通過評測只代表 checker 在這些 CVE 上表現符合預期,不保證它能發現未知漏洞。任務集以 C/C++ 為主(159/300),且只涵蓋 CSA 與 CodeQL 兩種分析器。論文也使用了人工引導的 rollout 校準。這些設計選擇是否影響結論的泛化,值得後續觀察。整體而言,CheckerBench 提供了一個難度適中、診斷維度完整的測試平台,未來要看的是模型能不能把「設計得出來」變成「實作得出來」。