别把 SFT 里的 `packing` 当成白捡吞吐的开关:TRL 里 `bfd`、`bfd_split`、`wrapped` 真正卖掉的不是同一种东西

📅 2026/7/14 6:06:45 👁️ 阅读次数 📝 编程学习
别把 SFT 里的 `packing` 当成白捡吞吐的开关:TRL 里 `bfd`、`bfd_split`、`wrapped` 真正卖掉的不是同一种东西

别把 SFT 里的packing当成白捡吞吐的开关:TRL 里bfdbfd_splitwrapped真正卖掉的不是同一种东西

很多人做 SFT 时,一看到packing=True就会把它理解成“把 padding 浪费收回来,几乎没有副作用”。但我把 TRL 现在的实现、警告和一个最小模拟实验放在一起看后,结论反而更像这样:packing 确实能把 token 利用率从 80% 左右拉到 95% 以上,但你到底是在卖掉超长样本尾部 token、卖掉对话边界,还是在错误 attention 实现下把不同样本混到一起,取决于你开的根本不是同一个开关。

这篇文章不讲 SFT 入门,也不复读“padding 少了所以更快”。我只想把 TRL 里最容易被忽略的 3 个事实讲清楚:bfdbfd_splitwrapped语义不同;packingpadding_free不是一回事;如果你的 attention kernel 不认识文档边界,packing 还可能带来跨样本污染。

1. 常见说法为什么不完整:你以为只是少了 padding,官方实现其实还在替你做别的决策

很多教程会把 sequence packing 写成一句话: