一个草稿模型被单独发布出来，却明确写着不能独立做文本生成。inclusionAI 放出的 Ling3-Tiny-UBTree-B16，定位是给 Ling-3.0-tiny 配套的投机解码草稿模型，必须和目标模型一起用。

打开网易新闻 查看精彩图片

它的结构由两部分拼起来：五层 DFlash 主干，加一个可学习的大二元组选择器。前者负责并行提出未来位置的候选 token，后者并行给相邻候选之间的转移打分。

UBTree 的流水线可以拆成四步：

  • DFlash 主干并行提出候选 token；
  • 选择器并行给相邻候选的转移打分；
  • 在验证预算内构建树，保留有希望的枝干；
  • 目标模型验证整棵树，提交被接受的续写。

配套论文还提出了树原生训练，在高温度目标轨迹上做重归一化的 KL 监督，目的是让模型更愿意给出合理的备选分支。方法细节和实验都在论文里。

规格上有个容易误读的点：B16 指的是草稿块大小，不是验证树的节点预算。参数量的统计只覆盖这个仓库里分发的张量，草稿模型与目标模型共享 token 嵌入和语言模型头，这部分共享权重不计入其中。

工程侧还没落地。面向 Ling3 的 UBTree 适配尚未发布到开源 SGLang 社区，公开的安装说明和服务配方要等集成可用之后才会补上。也就是说，现在拿不到一套能直接跑起来的部署流程。

性能数据同样空着。这个 checkpoint 的基准结果标注为待补，TBD 表示尚未报告。按约定，后续会一并公布运行时版本、树预算、并发度和计时协议。

指标口径倒是先讲清楚了：接受长度指每个验证步平均提交的 token 数，包含目标 token；加速比则是在相同硬件、相同输入、相同解码设置下，与仅用目标模型的自回归解码对比得出。

权重以 MIT 许可证发布。若在研究中使用 UBTree，需引用 Liang 等人的论文《UBTree: Parallel Tree Drafting via Unigram and Bigram Models for Speculative Decoding》，收录于 arXiv 预印本。