大多数语言模型训练时只问一个问题，给定前文，下一个 Token 是什么。多词元预测会在同一位置同时问未来第二个、第三个乃至第四个 Token。几个预测任务共享 Transformer 主干，各自使用输出头计算损失。
我对照了 Meta FAIR 团队的论文、实验表和公开训练代码。论文讨论了训练质量与推理速度两件事。训练时多看几步，可能促使模型学习跨 Token 的模式；推理时，多余的预测头又能拿来提出后续候选，做自推测解码。
多几个输出头不能直接堆显存
词表通常远大于隐藏层维度。若四个头同时保存整份词表 logits 及其梯度，显存很快被占满。论文的实现先运行共享主干，再依次完成每个输出头的前向与反向计算，把梯度累积回主干，当前头用完便释放。这样峰值存储从随预测头数量增长，降到只需保留一个头的词表输出与主干梯度。
作者为了公平比较，还固定了模型总参数量。增加未来预测头时，会从共享主干里减去相应层数。实验因此比较的是同样参数和训练计算预算下，损失函数与结构安排带来的差异，不能理解成免费加了几个完整模型。
规模会改变结果。论文训练了从 3 亿到 130 亿参数的代码模型。较小模型上的多词元预测可能落后于单词元基线，模型变大以后优势才明显。130 亿参数模型相对可比基线，在 HumanEval 上多解决 12% 的题，在 MBPP 上多解决 17%。这组数字来自代码生成评测，不能推到所有语言任务。
预测几个未来 Token 也要试。作者在 70 亿参数、2000 亿代码 Token 的设置里比较 1、2、4、6 和 8 个未来位置，四词元方案整体最好。预测太远时，未来分支更多，单个隐藏状态很难同时给出准确答案，额外训练目标可能开始拖累主任务。
训练出来的头还能参与解码
最简单的部署仍可只保留下一个 Token 预测头，其余头训练完就不用。若启用自推测解码，后续头先给出候选，原模型再验证，流程不需要单独的草稿模型。论文在 70 亿参数四词元模型上测得，代码任务平均三条建议能接受 2.5 个 Token，推理速度提高约三倍；自然语言文本约提高 2.7 倍。
论文也报告多词元训练对摘要等生成式任务有帮助，在选择题和负对数似然评测上没有明显退步。这个表述仍有边界。训练语料、模型大小、分词方式和任务类型都会改变最佳预测步数，固定用四个头并无普遍保证。
如果准备训练模型，我会先用较小预算比较单词元、双词元和四词元，保持参数量、训练 Token 与评测样本一致。除了最终分数，还要记录每个未来头的准确率和推理接受率。多词元预测真正节省推理时间，需要训练收益与候选命中同时成立。若后续头很少被接受，它们只在训练阶段增加了一个辅助目标。