TIDE 讓跨架構蒸餾可行

TIDE 針對 diffusion LLM 的跨架構蒸餾，加入噪聲感知與 tokenizer 感知訓練，讓小模型更能學到大模型的能力。

Turning the TIDE: Cross-Architecture Distillation for Diffusion Large Language Models 這篇論文，切的不是一般常見的「把大模型縮小」問題，而是更麻煩的一種情境：老師模型和學生模型根本不是同一種架構。對 diffusion LLM 來說，這種差異會牽涉 attention 設計、tokenizer，甚至文字是怎麼被表示與對齊。作者提出 TIDE，就是要處理這個跨架構知識移轉的落差。

這個題目很實際。diffusion large language models 本來就主打平行解碼、雙向上下文，理論上很有吸引力；但真正能撐起效果的系統，往往還是體積大、成本高。若想把能力壓到更小的模型上，蒸餾幾乎是必經之路。問題在於，過去很多方法預設學生只是老師的縮小版，架構大致對得上。只要老師和學生的內部表示開始分岔，這個假設就不太成立了。

這篇論文想解的痛點

傳統 dLLM 蒸餾，很多是在同一架構內做 inference steps 壓縮，重點是讓模型更快、更省。這類方法對單一架構很有用，但它沒有真正處理「跨架構轉移」：老師和學生在結構上不同，甚至連 tokenizer 都不一樣。

這件事不是小細節。學生模型學的不只是答案，還要學老師怎麼看文字、怎麼切 token、怎麼在不同遮罩狀態下做預測。如果 token 邊界不一致，或 masking 與 decoding 行為不同，老師給出的訊號就可能變得吵雜，甚至誤導學生。也就是說，單純模仿 logits，常常不夠。

從摘要來看，TIDE 被定位成一個專門處理 cross-architecture dLLM distillation 的框架。它要解的不是「一個模型怎麼變快」，而是「當老師和學生不是同一種模型時，知識怎麼傳得過去」。

TIDE 到底怎麼運作

TIDE 由三個模組組成，而且每個模組都對準一種常見失真來源。第一個是 TIDAL。它會根據訓練進度和 diffusion timestep 來調整蒸餾強度。白話一點，就是老師在不同 timestep 的可靠度不一樣，學生不該用同一種力道去學所有階段。

第二個模組是 CompDemo。它透過 complementary mask splitting 來補強老師的上下文。因為 diffusion 模型在高遮罩比例下做預測時，看到的上下文太少，老師本身也可能不穩。CompDemo 的想法，是用互補式的 mask 切分，讓老師能看到更完整的上下文，減少在重度 masking 下的失真。

第三個模組是 Reverse CALM。摘要說它是一個 cross-tokenizer objective，核心是把 chunk-level likelihood matching 反過來處理，並帶來 bounded gradients 與 dual-end noise filtering。用比較白話的方式講，這像是在老師和學生 tokenizer 不一致時，提供一種更穩定的對齊方式，避免訓練過程因為 tokenization 差異而發散。

三個模組合起來，分別處理三件事：什麼時候該相信老師、怎麼讓老師的上下文更完整、以及怎麼跨 tokenizer 對齊輸出。這比「直接把老師輸出硬塞給學生」更貼近真實部署場景。

論文實際證明了什麼

摘要裡最明確的結果，是 TIDE 把 8B dense 和 16B MoE 的老師模型，蒸餾到一個 0.6B 學生模型，並且走了兩條 heterogeneous pipelines。作者表示，在八個 benchmark 上，蒸餾後的系統平均比 baseline 高 1.53 分。摘要沒有公開完整 benchmark 名稱與每項細節，所以這裡只能確認有八個測試與平均提升，不能補更多表格外資訊。

比較醒目的單點結果出現在 code generation。HumanEval 上，TIDE 的分數是 48.78，對照 AR baseline 的 32.3。這個落差不小，代表它不只是把平均分數往上推，也可能在開發者很在意的下游任務上真的有感。

不過，從目前可見的資訊來看，還是要保守解讀。這份來源只有摘要，沒有完整 benchmark 細節、沒有訓練成本、沒有 wall-clock time，也沒有更廣泛的蒸餾基線比較。換句話說，我們知道它有效，但還不知道成本多高、穩定性如何、或是不是只在作者列出的 heterogeneous pipelines 才有這種效果。

• 老師模型：8B dense、16B MoE
• 學生模型：0.6B
• 八個 benchmark 平均提升：1.53 分
• HumanEval：48.78 對 32.3（AR baseline）

對開發者有什麼影響

如果你在做模型部署，這篇最有意思的地方，不是蒸餾本身，而是它承認了現實中的 heterogeneity。實務上，團隊常常沒辦法挑到「老師和學生完全同款架構」的組合。你可能想壓縮的是不同家族的模型，甚至是 tokenizer、attention pattern 都不一樣的系統。

TIDE 提示了一個很重要的方向：跨架構壓縮，可能不能只看輸出對不對，還要把蒸餾目標做成 representation-aware。也就是說，當老師和學生對文字的內部表示不一致時，蒸餾方法本身就得跟著調整。這篇的三個模組，正好對應了這個思路：噪聲感知、masking 下的上下文補強、以及 tokenizer 感知的對齊。

這對實作端的啟發很直接。若你在評估蒸餾方案，除了看最終分數，也要問：老師和學生是不是同一種 tokenizer？注意力結構差多少？在不同 timestep 下，老師的訊號是否一樣可靠？如果答案都是否定的，那就不能期待傳統蒸餾 objective 自動幫你解決。

同時，限制也很明顯。這篇目前能驗證的內容，仍然只來自 arXiv 摘要。它告訴我們方法存在、三個模組是什麼、以及 headline result 是多少，但沒有提供足夠資訊去判斷泛化能力、超參數敏感度、或額外複雜度是否值得。

即便如此，TIDE 仍然是一個重要訊號。diffusion LLM 的研究，正在從「能不能蒸餾」走向「當老師和學生根本不是同一種語言時，還能不能蒸餾」。這篇的答案是可以，但前提是蒸餾過程要懂噪聲、懂 masking，也要懂 tokenizer 差異。

對台灣開發者來說，這類工作最值得注意的，不只是分數提升，而是它把蒸餾問題從單純壓縮，推進到跨架構協作。未來如果要把大型 diffusion LLM 落地到更小的部署環境，這種「讓學生學會跟老師不同步的表示方式」的設計，可能會比單純縮參數更關鍵。

這篇可以怎麼看

如果只用一句話總結，TIDE 是在解一個很多蒸餾方法沒正面碰的問題：老師和學生不一樣時，怎麼讓知識真的傳下去。它不是把既有蒸餾再微調一下，而是把 timestep、mask、tokenizer 這三個容易出問題的地方都納入設計。

而就目前摘要能證實的範圍來看，它至少在 0.6B 學生上做出了可量化的提升，也在 HumanEval 這種開發者熟悉的任務上交出明顯差距。剩下的問題，就要等完整論文看更多 ablation、更多成本資訊，才能判斷這套方法到底是研究上漂亮，還是實務上也夠划算。