Target Regeneration Shrinks the Gains of Draft-Training Objectives in Speculative Decoding
Target Regeneration Shrinks the Gains of Draft-Training Objectives in Speculative Decoding
我们看到新的Loss function 相比于 Cross-Entropy显著提高了Acceptance ， 但是这个增益究竟是来自Loss本身，还是因为训练数据原本就不符合target的输出分布?
Abstract
- 核心问题: External Responses 与 Target Responses 不一致
假设我们的训练数据来自于另外一个模型，例如GPT-4 , 而现在希望为Qwen3-8B 训练一个Drafter，那么训练集中的某个位置真实token可以看作是 yt， 而Qwen3-8B在某个位置上最可能生成的数据和y_t不一样。
假如我们直接使用普通的CE，其实是在要求Draft模仿外部数据的Token,但是SD要匹配的是Target的输出。
这个时候使用KD 就是很合理的了，训练drafter 匹配 完整target的token distribution， 看起来就能获得明显受益。
- 而这个地方有一个问题，如果训练数据原本就是target写的的呢？
在这种情况下，普通CE训练的token大多就已经和 target的 greedy prediction 对齐。
这就让KD的纠正作用下降了。
Introduction
- 作者认为，现有的工作可能高估的 Loss Function的收益
很多文章比较 CE VS KD ， 然后发现KD可以显著提高acc， 于是宣称设计了更好的drafter
但是如果CE学的是别的模型产生的token, KD 学的是target的模型的概率分布，那么KD天然具有一个优势。
它纠正了External responses 和 Target Outputs 之间的不一致
KD相比于普通CE，它还可以提供除了Top-1 Token之外的概率信息.
所以作者的想要证明的就是,KD 的收益在Target Regeneration 之后还剩下多少。
| Objective | 核心思想 |
|---|---|
| CE | 预测Corpus Token |
| KD | 模仿 Target的概率分布 |
| KD + GATE | 排除Greedy verification中无法到达的位置 |
最后给出的结论是：
Target Regeneration 会显著缩小 KD 和 Survival Gate 相对于 CE 的额外收益，而且这种现象无法仅用训练数据变长来解释。
其实相当于就是一般来说 CE学习的数据集是外部的，KD学的是target的，不是用 Target 数据后 KD 的绝对效果更差，而是用 Target 数据后，KD 相对于 CE 的优势大幅缩小。
Experiment
这篇文章没啥好说的思维算法之类的，直接看看实验吧。
作者在CE, KD, KD + GATE 三个训练的目标函数下，处理了四种数据处理方式
- External: 原始外部模型生成的答案
- Full Regeneration: Target 自己重新生成答案
- Truncated 将Target 的生成答案截断到原答案长度
- Loss Window 保留完整生成答案，只监督原始答案等长度的前缀
后两种主要用于控制 Target Regeneration 让训练文本变长这个混杂变量。
Result
- Regeneration 显著削弱了KD的优势
即使控制监督长度，KD 的优势仍然明显小于 External 数据上的表现。 - 有些 KD 增益来自 CE Baseline 退化
作者发现，在 External Corpus 上，随着训练 Epochs 增多，CE 的 MAT 反而下降得比 KD 更快。
也就是说，某些新 Loss 的增益还可能部分来自不够合理的 Baseline Training Schedule。 - 不只是Dflash，作者发现在EAGLE3等也存在这个现象。
作者还做了一个Greedy - label control， 不用完整KD，而是直接将训练标签替换成Target在相同Prefix下预测的Greedy token。
结果在external corpus上
- 普通 CE -> greedy label CE 提高 9.3
- Greedy-label ce -> 完整KD: 提高 4.7
所以KD的一大部分收益来自于修正原始数据和 Target之间的监督不一致
而在 Target-regenerated Corpus 上，Greedy-label CE 相对普通 CE 已经没有可测量的额外收益。
相关推荐
2026-10-31
Rust Diary DAY2 —— Ownership and reference
所有权和借用 Rust的内存安全性是其最为显著的特征。在以往，内存安全几乎都是通过GC的方式实现，但是GC会引来性能、内存占用的问题。 Rust因此采用了所有权系统。 所有权 所有的程序都得和计算机内存打交道，如何从内存中申请空间来存放程序的运行内容，如何在不需要的时候释放这些空间，成了重中之重。 在语言的演变中，产生了三种流派 GC: 程序运行的时候不断寻找不再使用的内存，eg: java go 手动管理: 程序员自己去申请和释放内存，eg: C C++ 所有权系统: 编译器在编译期就能知道内存的使用情况，eg: Rust 例子 123456int* foo(){ int a ; a = 100; char *c = "xyz"; return &a;} a和c都是局部变量，但是局部变量a存在栈中，离开作用域之后，a申请的栈上内存都会被回收，从而造成了悬空指针的问题。 变量c是常量字符串，存储在常量区域， "xyz" 只有在整个程序结束后才能回收这片内存。 所以内存安全问题，一直都是程序员很头痛的问...
2026-11-02
RustDiary -Day4 : Tuple, Struct
元组 元组是多种类型组合到一起形成的，因此它是复合类型，元组的长度是固定的，元组的顺序也是固定的。 123fn main() { let tup: (i32, f64, u8) = (500, 6.4, 1);} 变量tpu被绑定了一个元组值 (500,6.4,1), 该元组的类型是(i32, f64, u8) 元组使用括号将多个类型组合到一起。 用模型匹配解构元组 1234567fn main() { let tup = (500, 6.4, 1); let (x,y,z) = tup; println!("The value of y is: {}", y);} 上述代码首先创建一个元组，然后帮他绑定到tup上面，然后用 let( x,y,z) = tup来完成模式匹配。。 用 . 来访问元组 模式匹配可以让我们一次性的把元组中的值取出来，但是如果只是想要访问特定的元素，那么模式匹配就略显繁琐，对此，Rust提供了.的访问方式: 12345678910fn main(){ le...
2026-10-29
Bit-Accurate Modeling of GPU Matrix Multiply-Accumulate Units: Demystifying Numerical Discrepancy and Accuracy
Bit-Accurate Modeling of GPU Matrix Multiply-Accumulate Units: Demystifying Numerical Discrepancy and Accuracy Abstract 现代的AI 高度依赖 MMAU。 MMAU是什么呢？ Matrix Multiply -Accumulate Units 所以本质上就是一种进行矩阵乘法，然后加回去的计算单元。而硬件厂商通常只公开MMA的指令集和接口，不公开完整的内部浮点算数行为。 数学上，我们知道 D = AB + C 但是硬件是一个黑盒，我们知道这个黑盒函数的数学定义，但不知道它内部的运算序列。 然后所以由于这种黑盒性质，就导致了一个问题—— 同样的输入，硬件却可能给出不同的结果。 因此，这种不同的结果带来的不稳定性一是降低了数值精度，二是影响了神经网络的训练的稳定性。 因此，我们现在面临着两个问题 Numerical Discrepancy —— 为什么两个GPU的结果不一样? Numerical Accuracy —— 哪个结果更接近真实值？ 所以authors提出...
2026-11-03
RustDiary Day 5 - struct and array
元组 元组是多种类型组合到一起形成的，因此它是复合类型，元组的长度是固定的，元组的顺序也是固定的。 123fn main() { let tup: (i32, f64, u8) = (500, 6.4, 1);} 变量tpu被绑定了一个元组值 (500,6.4,1), 该元组的类型是(i32, f64, u8) 元组使用括号将多个类型组合到一起。 用模型匹配解构元组 1234567fn main() { let tup = (500, 6.4, 1); let (x,y,z) = tup; println!("The value of y is: {}", y);} 上述代码首先创建一个元组，然后帮他绑定到tup上面，然后用 let( x,y,z) = tup来完成模式匹配。。 用 . 来访问元组 模式匹配可以让我们一次性的把元组中的值取出来，但是如果只是想要访问特定的元素，那么模式匹配就略显繁琐，对此，Rust提供了.的访问方式: 12345678910fn main(){ le...
2026-11-03
Rust Diary Day 5-> Linked List
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162// 填空，让代码运行use crate::List::*;enum List { // Cons: 链表中包含有值的节点，节点是元组类型，第一个元素是节点的值，第二个元素是指向下一个节点的指针 Cons(u32, Box<List>), // Nil: 链表中的最后一个节点，用于说明链表的结束 Nil,}// 为枚举实现一些方法impl List { // 创建空的链表 fn new() -> List { // 因为没有节点，所以直接返回 Nil 节点 // 枚举成员 Nil 的类型是 List Nil } // 在老的链表前面新增一个节点，并返回新的链表 fn prepend(self,...
2026-10-30
RustDiary Day1: 变量绑定与解耦
变量绑定与解耦 命名规范 Crates 包 无 Modules snake_case Types UpperCamelCase 特征Traits UpperCamelCase 枚举 Enumerations UpperCamelCase 结构体 Structs UpperCamelCase 函数 Functions snake_case 方法 Methods snake_case 通用构造器 General constructors new or with_more_details 转换构造器 from_some_other_type 宏 Macros snake_case! 局部变量 Local variables snake_case 静态类型 Statics SCREAMING_SNAKE_CASE 常量Constants SCREAMING_SNAKE_CASE 类型参数Type parameters UpperCamelCase 生命周期 Lifetimes 小写字母 'a 'de 'src 变量绑定 1let a = "hello wor...
