AngelSpec：给聊天和代码分别配不同的草稿模型，推理再快一倍

arXiv 今天挂出来一篇 AngelSpec 的论文，讲的是怎么把推测解码（Speculative Decoding）做细。它在 Hy3-A21B 上跑出了 1.98–2.40x 的加速（对比自回归解码），比目前已知的 DFlash 方案再高 10.5–11.8%。但这篇真正值得看的不是数字，而是它怎么理解「一个草稿模型不可能在所有场景都好用」，并为此做了三层分工。

推测解码现在是大模型推理加速的标配思路——用一个轻量级的草稿模型先快速写一串 token，主模型再来批量验证，接受的保留，不接受的丢弃。理想很直接，但始终没解决一个问题：不同场景的输出分布差太远了。

聊天场景里话题跳跃、信息密度低、token 分布高度不确定（高熵）；写代码和推公式则是另一种节奏——生成长、模式固定、低熵、可预测性强。对前者，最好用自回归式的 MTP（多 token 预测），每个 token 逐个生成，稳定但慢一点；对后者，块并行的扩散模型能一次性起草一长段候选序列，把起草本身的时间摊薄。但这俩不能互相替代，选错了反而吃亏。

AngelSpec 的做法是，不纠结「哪种草稿结构最优」，直接给每个场景专配一套。

训练层分了两条线：MTP 草稿模型喂的是开放聊天类数据，专门对付高熵对话；块扩散草稿模型拿代码和数学数据训，用来应对长而规律的生成功。数据和结构一起 co-specialize，而不是训一个通用草稿器往所有场景塞。

架构层，他们提了一个叫 DFly 的块扩散框架。设计上把两个东西拼在一起：一个 hybrid target-conditioning 主干，用来更好吸收目标模型的特征；一个 predecessor-conditioned 自回归头，用来增强块内部的依赖建模——让并行生成的那些 token 不至于各说各话。关键是一边保持并行化生成，一边补上串行建模的精度。

到了推理层就更实际了。实际线上服务里，请求类型每小时都在变，并发数起起伏伏，每段输入的接受长度和验证开销都是动态的。DFly 没有给一组固定参数走天下，而是把验证当成一个共享的批处理资源来调度：哪个 prefix 置信度高，就给谁多分配算力。结合一个 profiling 代价模型，在线自适应调整验证深度。

高并发的代码补全来了，DFly 自动切进块扩散模式加短验证轮次；深夜零散聊天请求来了，又切回 MTP 配深验证。这些切换不需要人工介入。

整篇论文的贡献最后落在 Hy3 系列上做了实测。DFly 在 Hy3-A21B 上平均接受长度提升约 30%，从 4 到 64 的并发区间内都能拿到最高的平均吞吐。

AngelSpec 本身是开源释放的——训练和扩展方法都包含在内，不是只放个推理脚本。

比单纯的「又快了 10%」更有价值的是：它承认了「通用方案」在推理优化这条路上的阶段性天花板。 过去两年大家都在卷一个 drafter 通吃所有任务，AngelSpec 直接说这条路走不远，不如给 chat 配一个专用草稿、给 code 配另一个，然后在 runtime 层再自适应调配。这个思路在工程上更重，但更接近真实线上的复杂度。

当然，这套方案不是无代价的。维护两套草稿模型意味着训得更杂、存得更多、部署时需要做路由判断。对于做 API 服务的团队来说，这套权衡是否划算，要看场景是否足够典型——如果你的流量极端偏向某一类任务，把资源摊到两套方案上反而可能是浪费。

论文已经挂在 arXiv 上，代码也标注了 release。感兴趣的可以直接翻源码看 DFly 的调度逻辑和代价模型是怎么实现的——那部分才是真正工程上手的东西。