腾讯把投机解码全链路开源了

腾讯混元开源 AngelSpec，目标是把投机解码真正送进生产环境

腾讯混元团队在 7 月 29 日正式开源 AngelSpec，一次性开放 drafter 训练、架构设计和线上部署链路，并同步发布 Hy3-A21B 对应的 MTP 与 DFly drafter 权重及训练代码。

**AngelSpec 是一个覆盖草稿模型训练、结构设计和推理部署的投机解码框架。**与只给论文算法、单个算子或离线实验脚本的项目不同，AngelSpec 强调的是端到端：开发者可以从已有目标模型出发训练 drafter，再把它接入实际推理服务，而不必自行拼装数据生成、模型适配、验收和部署工具。

这次开源最值得关注的并不是腾讯又提出了一种加速方法，而是它试图把投机解码从“跑通 demo”变成一套可复制的生产流程。对于已经把模型权重、量化和推理引擎优化到接近极限的团队，drafter 可能是继续压低逐 token 延迟的少数有效杠杆之一。

投机解码不是让小模型替大模型回答

**投机解码（Speculative Decoding）是一种由轻量 drafter 预生成多个候选 Token，再由目标模型并行验证候选结果的推理加速技术。**它的核心价值是减少大模型串行执行前向计算的次数，而不是把最终输出质量交给小模型决定。

普通自回归生成每次通常只确认一个 Token。假设模型要生成 100 个 Token，最直接的方式就需要连续完成约 100 轮解码；每一轮都要读取大模型权重，并等待上一个 Token 确定之后才能继续。模型越大、显存带宽压力越高，这种串行瓶颈越明显。

投机解码则让较小的 drafter 先猜出一段候选序列，例如一次提出 4 个 Token，再由目标模型在一次前向过程中并行检查。若 4 个候选全部被接受，一轮目标模型计算就可以推进多个 Token；若部分候选不符合目标模型分布，则从拒绝位置修正并继续生成。

**Drafter 是在投机解码中负责快速提出候选 Token 的轻量预测模型或预测模块。**一个好的 drafter 不只要运行快，还要尽可能贴近目标模型，因为候选接受率直接决定了加速收益。drafter 太弱会频繁猜错，太大又会让草稿阶段本身成为额外负担。

在采用正确验收与重采样规则的前提下，投机解码可以保持目标模型原有的采样分布。这一点把它和简单的“小模型先答、大模型兜底”区分开来：最终裁决者仍然是目标模型，drafter 只是尝试把串行步骤批量化。

AngelSpec 开放的是三段此前经常断开的链路

**AngelSpec 的核心产品价值是把训练、架构和部署三个环节放进同一套框架。**投机解码的论文并不少，真正困难的是让候选生成策略、目标模型接口、缓存管理和线上调度保持一致。

根据腾讯混元 7 月 29 日公布的信息，本次开源至少包含以下三层能力：

1. **Drafter 训练链路。**团队可以围绕目标模型生成训练信号，训练与目标模型输出分布更匹配的草稿模块。
2. **Drafter 架构支持。**首批公开内容涉及 MTP 与 DFly 两条路线，方便开发者比较不同候选生成结构。
3. **线上部署链路。**框架目标不是止步于离线准确率，而是把候选生成、验证和推理服务衔接起来。

**MTP（Multi-Token Prediction，多 Token 预测）是一种在单个位置同时预测多个未来 Token 的结构或训练方法。**它不再只学习“下一个 Token 是什么”，而是尝试直接预测后续多个位置，因此天然适合作为投机解码的候选生成器。

**DFly drafter 是腾讯混元在 AngelSpec 中公开的另一类草稿模型方案。**截至此次发布信息披露时，腾讯尚未在新闻材料中完整列出其结构规模、训练数据配比、候选长度和各场景接受率，因此现阶段不宜仅凭名称推断其具体技术实现。判断 DFly 是否优于 MTP，最终仍要看仓库技术文档和可复现实测。

本次同步放出的 Hy3-A21B 相关资产包括 MTP drafter 权重、DFly drafter 权重以及相应训练代码。现成权重的意义很直接：开发者不必先投入一轮完整训练，就可以验证目标模型、drafter 和部署框架是否能够形成闭环；训练代码则让团队有机会针对自己的模型分布、业务提示词和输出长度重新适配。

两套 drafter 不等于两档固定性能

**MTP 与 DFly 的实际差异必须放到接受率、草稿成本和端到端延迟中评估。**单看 drafter 参数量或每秒候选 Token 数，无法判断最终收益，因为投机解码是一个由草稿与验证共同构成的系统。

| 对比维度 | MTP drafter | DFly drafter | 生产环境应关注什么 | |---|---|---|---| | 基本定位 | 多 Token 预测路线 | AngelSpec 开放的另一类 drafter 路线 | 是否适配目标模型和推理引擎 | | 本次开放内容 | Hy3-A21B 对应权重与训练代码 | Hy3-A21B 对应权重与训练代码 | 能否直接复现官方流程 | | 候选生成方式 | 同时预测多个未来 Token | 具体结构以项目文档为准 | 单轮候选长度与额外计算量 | | 关键指标 | 接受长度、接受率、drafter 延迟 | 接受长度、接受率、drafter 延迟 | 端到端 TPOT、吞吐量和尾延迟 | | 当前公开跑分 | 发布快讯未给出统一数字 | 发布快讯未给出统一数字 | 不能用未经披露的数据代替实测 | | 更适合的场景 | 需结合任务分布测试 | 需结合任务分布测试 | 代码生成、长回答通常更容易观察收益 |

腾讯目前没有在此次简短发布信息中给出统一加速倍数、首 Token 延迟、每输出 Token 延迟或 GPU 吞吐数字。这个缺口很重要，因为投机解码不存在一个脱离硬件、批大小和任务类型的固定“提速百分比”。

**接受率是 drafter 提出的候选 Token 被目标模型认可的比例。**如果一次草拟 4 个 Token，却通常只能接受第 1 个，那么系统既付出了 drafter 成本，也没有明显减少目标模型迭代次数；如果大部分轮次能够连续接受 3 至 4 个 Token，才更可能获得可观收益。

**平均接受长度是每轮验证后能够直接确认的候选 Token 数量。**它往往比单纯接受率更接近真实加速效果，但仍不能代替端到端延迟，因为目标模型验证、KV Cache 读写、批调度和通信开销都会影响结果。

AngelSpec 真正要解决的是工程“最后一公里”

**投机解码最难的部分通常不是理解算法，而是让它与线上推理系统协同工作。**实验环境可以固定 batch size、提示词长度和候选数量，生产环境却要同时面对动态批处理、不同上下文长度、流式输出和突发流量。

第一类问题来自 KV Cache。候选 Token 在被验证前具有不确定性，一旦某个位置被拒绝，后续草稿对应的缓存就不能直接当作已确认状态继续使用。推理框架需要高效处理缓存提交、回滚或重用，否则理论上省下的模型计算会被内存操作抵消。

第二类问题来自动态批处理。在线服务通常把多个用户请求拼成批次，以提高 GPU 利用率，但不同请求每轮接受的 Token 数不同：有的请求接受 4 个，有的只接受 1 个。调度器必须处理这种“每条请求推进速度不同”的情况，避免为了少数请求拖慢整个批次。

第三类问题来自 drafter 与目标模型之间的成本平衡。高并发离线吞吐场景往往已经能通过大批次充分利用 GPU，此时再加入 drafter 未必划算；低批量、强交互和长回答场景对逐 token 延迟更敏感，投机解码通常更有发挥空间。

第四类问题来自任务分布。代码、固定格式文本和重复结构较强的内容，后续 Token 往往更容易预测；高温度创作、开放式对话和频繁切换语言的任务更不稳定，候选接受率可能下降。用单一 benchmark 得出的结论，很难直接代表真实业务。

AngelSpec 如果能把这些环节做成统一可配置和可观测的部署流程，其价值会明显高于“再提供一个训练脚本”。对开发者来说，能够追踪每层接受率、平均接受长度、草稿耗时、验证耗时和回滚比例，才有可能把投机解码调到可上线状态。

它与量化、推理引擎不是替代关系

**投机解码解决的是生成过程串行化问题，而量化主要解决权重存储、带宽和计算成本问题。**两者作用在不同层面，因此通常可以叠加，而不是二选一。

| 技术路线 | 主要解决的问题 | 是否改动模型权重表示 | 对输出质量的影响 | 与 AngelSpec 的关系 | |---|---|---:|---|---| | 投机解码 | 减少目标模型串行解码轮次 | 通常不需要 | 正确采样下可保持目标分布 | AngelSpec 的核心方向 | | FP8/INT8/INT4 量化 | 降低显存占用和带宽压力 | 是 | 取决于量化方案与校准质量 | 可与投机解码叠加 | | Continuous Batching | 提升多请求并发利用率 | 否 | 通常无影响 | 需要与投机调度协同 | | Prefix Cache | 复用重复提示词计算 | 否 | 无影响 | 优化 Prefill，作用阶段不同 | | CUDA Graph/算子融合 | 降低调度与算子开销 | 否 | 通常无影响 | 可进一步压低固定开销 |

AngelSpec 也不应被理解成 vLLM、SGLang 等推理引擎的直接替代品。推理引擎负责显存管理、批调度、模型执行和服务接口，投机解码框架则需要在这些能力之上协调 drafter 与目标模型。真正决定采用成本的，是 AngelSpec 对主流引擎、模型结构和分布式部署方式的适配程度。

腾讯此前已经通过 AngelSlim 开放模型压缩与加速工具链，覆盖量化、剪枝及投机解码相关能力；AngelSpec 此次进一步把 drafter 训练和生产部署单独拉出来，说明投机解码正在从压缩工具包中的一个选项，变成 AI Infra 团队独立建设的系统能力。不过，两套项目的功能边界和后续整合方式仍应以官方仓库说明为准。

现阶段最该看的不是“几倍加速”，而是能否复现

**AngelSpec 的第一轮评价标准应当是可复现性，而不是宣传中的峰值倍数。**腾讯此次公开信息没有给出完整统一跑分，因此任何脱离测试条件的性能结论都不可靠。

开发者评估 AngelSpec 时，至少应记录以下指标：

• TTFT（Time to First Token）：首 Token 延迟，判断 drafter 初始化是否拖慢请求启动；
• TPOT（Time per Output Token）：平均每个输出 Token 的时间，直接反映交互速度；
• P50、P95 与 P99 延迟：避免平均值掩盖线上尾延迟；
• 平均接受长度：每次目标模型验证能够确认多少个候选 Token；
• 吞吐量：固定 GPU、上下文长度和并发数下每秒生成多少 Token；
• 额外显存占用：drafter 权重、缓存及验证过程带来的显存成本；
• 不同任务分桶结果：代码、中文对话、英文写作、数学推理应分别统计；
• 与纯目标模型基线的对照：必须保持硬件、精度、批大小和采样参数一致。

一个可信的测试报告还应公开候选 Token 数量、上下文长度、输出长度、温度、张量并行规模和 GPU 型号。投机解码对这些变量高度敏感，只报“最高加速 X 倍”几乎没有决策价值。

腾讯这次开源有用，但成败仍取决于生态适配

**AngelSpec 是一次有实际工程价值的开源，但现在还不能仅凭发布信息断言它已经成为投机解码的新标准。**它的优势是覆盖训练到部署，并且直接提供 Hy3-A21B 的两套 drafter 权重和训练代码，这比只开放论文或模型权重要完整得多。

它的挑战也很明确。企业手里的目标模型未必是 Hy3-A21B，模型结构、Tokenizer、并行策略和服务引擎都可能不同；如果迁移到其他模型仍需大量定制代码，“全链路”价值就会被削弱。反过来，如果 AngelSpec 能快速扩展到更多混元模型及主流开源架构，并与 vLLM、SGLang 等部署生态形成稳定接口，它会比单点算法更具长期影响力。

对普通应用开发者而言，AngelSpec 暂时不是一个装上就能让所有模型提速的开关；对维护大规模推理集群的 Infra 团队而言，它值得立即进入评测队列。后者真正需要的不是又一张漂亮跑分表，而是一套能训练、能监控、能回滚、能与现有服务栈协同的投机解码流水线。

腾讯这次押注的方向是对的：大模型推理竞争已经从单个算子优化进入系统协同阶段。模型本身继续变大，但用户对实时响应的容忍度没有同步增加；在不更换目标模型、不明显牺牲输出质量的前提下，让一次前向确认更多 Token，仍然是最值得投入的推理优化方向之一。

参考来源

• 腾讯 AngelSpec GitHub 项目：AngelSpec 代码、权重、训练与部署说明的官方开源入口。
• 腾讯 AngelSlim GitHub 项目：腾讯混元模型压缩与推理加速工具链，可用于了解其量化和投机解码布局。
• vLLM GitHub 项目：主流大模型推理与服务引擎，用于对照投机解码的部署生态。
• SGLang GitHub 项目：面向大模型与多模态模型的高性能服务框架，用于比较调度和推理适配能力。