腾讯开源 AngelSpec，挑战“一刀切”的推测解码方案

腾讯混元在报告称 Hy3-A21B 推理速度较标准自回归解码最高提升 2.40 倍后，现已开源 AngelSpec。该框架为两条不同的推测解码路径整合了训练、评估与部署支持。其核心主张挑战了一种常见假设：单一草稿生成方法无法高效应对所有语言模型工作负载。

AngelSpec 包含多 Token 预测（MTP），通过轻量级自回归草稿模型提出多个未来 Token。它还引入了 DFly，这是一种并行生成更长 Token 组的块扩散系统。腾讯表示，在其测试的各类服务条件下，DFly 的吞吐量较 DFlash 高出 10.5% 至 11.8%。

这一比较之所以重要，是因为 DFlash 已经推动推测解码摆脱了严格的串行草稿生成方式。AngelSpec 并非只是提出另一种更快的草稿模型，而是围绕各自最擅长处理的工作负载组织两种对比鲜明的方法，并根据运行时条件调整验证方式。

由此形成的是一个以更贴近实际运营的视角看待推理加速的开源框架。开发者可以查看训练流程、测试已发布的 Hy3 草稿模型，并研究性能如何随流量变化。不过，腾讯报告的增益来自其自身的模型、配置和评估设计。独立生产环境的结果仍是决定性但尚缺失的证据。

AngelSpec 将研究选择转化为部署选择

AngelSpec 将推测解码视为工作负载选择问题，而非争夺单一通用草稿架构的竞赛。

腾讯研究人员于 2026 年 7 月 28 日提交了首版 AngelSpec 论文。修订版于 7 月 29 日发布。随后，公司宣布开源发布训练代码和 Hy3-A21B 草稿模型权重。

推测解码使用一个更小或成本更低的草稿模型来提出多个未来 Token。完整的目标模型会一并检查这些提议，并接受其中匹配的前缀。当提议足够准确时，系统便能生成多个有效 Token，同时避免进行同等数量、成本高昂的目标模型推理。

在采用所需的验证和拒绝流程时，该方法能够保留目标模型的输出分布。因此，它改变的是 Token 的生成效率，而不是用草稿模型的答案替代目标模型的答案。

草稿质量仍决定这一理论优势能否转化为实际加速。较弱的草稿模型会生成被拒绝的 Token，增加工作量却无法推进生成。较大的草稿模型或许预测准确，但可能消耗过多时间和内存。当系统测试的候选内容超过请求所需时，验证本身也可能变得昂贵。

AngelSpec 将这些变量纳入统一的训练和评估框架。它支持 MTP 和块并行推测解码，包括隐藏状态生成、长上下文训练、rollout 工作流以及在线接受率评估。该发布旨在覆盖从研究检查点到实际运行的推理服务之间更完整的路径。

框架中的两条草稿生成路径按输出行为划分问题。腾讯使用多样化的对话数据训练 MTP 草稿模型，适用于开放式语言场景——在这类场景中，后续 Token 仍具有相对较高的不确定性。其块扩散路径则在代码和数学数据上训练，这些领域中较长的续写往往遵循更可预测的结构。

这种专门化是此次发布最重要的变化。许多推测解码比较关注哪种方法的平均表现更好，而 AngelSpec 转而考察哪种草稿结构适合特定分布，并通过统一的开发路径提供两种结构。

配套权重也使得该发布比仅描述不可用系统的论文更便于测试。腾讯表示，已通过其模型渠道发布适用于 Hy3-A21B 的 MTP 和 DFly 草稿模型。开发者仍需具备相应的目标模型和合适的服务硬件，但无需在开始评估前重建每个训练阶段。

Hy3 为这次发布提供了一个要求颇高的目标模型。官方 Hy3 模型仓库 将其描述为一个混合专家模型，拥有 2,950 亿总参数和 210 亿激活参数。仓库还列出了一个 38 亿参数的 MTP 层，以及 256,000 Token 的上下文窗口。

这些规格使推理效率具有重要的经济意义。虽然每个 Token 只会激活完整模型的一部分，但服务部署仍需要大量内存、通信和目标模型计算。能够在每一步验证中提高接受输出量的草稿模型，可在不重新训练主模型的情况下改善延迟或吞吐量。

因此，AngelSpec 的定位不止是又一个 Hy3 配套组件。它提供了一个明确框架，用于在服务条件变化时选择、训练和评估草稿系统。正是这种更广泛的覆盖范围，对“一刀切”的推测解码提出了挑战。

报告中的增益令静态草稿策略承压

腾讯最强的主张并不只是峰值加速，而是 DFly 在从 4 到 64 的每一个测试并发级别上都处于领先。

根据论文，DFly 在 Hy3-A21B 上相较自回归解码实现了 1.98 至 2.40 倍的端到端加速。腾讯还报告称，DFly 的吞吐量比 DFlash 高出 10.5% 至 11.8%，平均接受输出长度则大约增加了 30%。

并发度衡量服务系统同时处理多少请求。它会改变计算、批处理效率、内存压力与验证开销之间的平衡。某种方法在单请求下看似很快，一旦大量请求争夺同一批加速器，可能便会失去优势。

腾讯表示，DFly 在从 4 到 64 的每一个测试并发度下都取得了最高平均吞吐量。这一区间涵盖了相对较低的流量和批处理更密集的服务场景。结果表明，除草稿模型本身的接受率外，DFly 的调度器和验证策略也有所贡献。

这些数字仍需谨慎解读。2.40 倍加速并不意味着每位用户都会看到响应快 2.40 倍。端到端加速取决于基准工作负载、输出长度、请求组合、批处理策略、硬件配置和基线配置。

吞吐量与延迟回答的也是不同问题。吞吐量衡量系统在一段时间内完成的工作量。交互用户通常更关心首个 Token 的生成时间，以及后续 Token 之间的延迟。服务可以提高总吞吐量，但对单个请求的改善可能较小或并不均匀。

这种区别令采用固定草稿策略的推理团队面临压力。静态策略可能为所有流量选择同一种草稿长度、验证深度或草稿模型。AngelSpec 认为，这些选择应响应领域、请求特征、在线负载和部署硬件。

因此，承压的目标并非某一家公司，而是将推测解码视为固定模型附属组件的路径。如果腾讯的发现能够在其他环境中成立，运营者将需要理解何时草稿工作仍具价值的路由与调度逻辑。

DFlash 提供了最直接的比较。其 块扩散设计 使用目标模型的隐藏状态，并行预测多个草稿 Token。该方法避免通过独立的串行草稿步骤逐一生成每项提议。

DFlash 的作者曾报告，在特定实验中实现超过六倍的加速，并优于 EAGLE-3。这些结果使用了不同的目标模型和测试条件，因此不应与 AngelSpec 的最高 2.40 倍结果直接比较。腾讯的相关主张是其自身 Hy3 评估中报告的受控 DFly 对比。

EAGLE 风格系统仍是另一项重要参考。它们使用目标模型特征引导较小的自回归草稿模型，通常会组织提议以实现高效验证。这类系统可在多样化文本中提供稳定结果，但草稿生成内部的串行依赖可能限制其提出长候选序列的速度。

MTP 则是该自回归路径的更轻量版本。当目标模型已经提供兼容的预测层时，它更易于集成。腾讯自身的 Hy3 发布包含 MTP 层，因此该模型成为比较轻量草稿生成与专用块并行系统的自然测试平台。

AngelSpec 对现有部署施加的压力是实际的。团队必须判断，额外的模型、调度器逻辑、性能分析和内存使用，是否能产生足够多的接受 Token，以证明其复杂性合理。该框架提供了用于探索这一问题的代码和权重，但并未使答案变得通用。

AngelSpec 如何让 DFly 更具选择性

DFly 将并行草稿生成与自回归信息相结合，再将验证工作投入预期回报最高的位置。

块扩散草稿模型会同时预测多个位置，而不是逐一完成它们。并行预测可降低草稿生成延迟，尤其是在候选块较长时。不过，句子或代码序列中的 Token 高度依赖同一块中更早的 Token。

这种依赖带来了一项弱点。如果每个位置都是根据被掩码或不完整的相邻内容进行预测，较后的提议可能会遗漏自回归草稿模型天然具备的信息。一个早期错误便可能缩短目标模型接受的前缀，使提议块的大部分内容被浪费。

DFly 通过两个相互关联的组件来解决这一张力。其骨干网络以目标模型的特征为条件，同时保留块并行生成。一个以前序 Token 为条件的自回归头，也为预测提供更早 Token 的信息，从而改善提议块内部的依赖关系。

该架构并未将整个草稿过程变为传统的串行流程。腾讯的设计试图在骨干网络中保留并行工作，同时加入足够的前序信息以提高候选内容的一致性。这种平衡是其平均接受长度提升主张的核心。

接受长度是指目标模型在遇到不匹配前批准的提议 Token 数量。更长的接受前缀可将每一步昂贵验证分摊到更多有用输出上。然而，如果生成和检查这些候选内容耗时过多，仅最大化接受长度也可能产生误导。

因此，AngelSpec 增加了一种名为 D-Cut 的自适应验证方法。验证深度指目标模型检查每个提议续写内容的范围。固定深度可能会对不确定的候选内容投入过多，或在高度可预测的候选内容上过早停止。

D-Cut 将验证能力视为共享的批次级资源。它估算保留额外候选位置的预期价值，并将该价值与经过性能分析的运行时成本进行比较。随后，调度器便可在多个请求之间，将更多验证工作导向高置信度前缀。

这是一项服务决策，而不只是模型决策。即便两个请求运行在同一模型上，也可能需要不同深度的验证。结构化代码补全可以维持较长且置信度高的前缀，而开放式聊天回复可能在仅生成几个 token 后就开始分歧。

硬件同样会改变这笔账的计算方式。较大的验证批次在一种加速器配置上可能很高效，在另一种配置上却可能代价高昂。通信成本、内存带宽、内核以及目标模型的并行度，都会影响多验证一个候选位置是否能节省时间。

这正是 AngelSpec 会分析运行时成本，而非只依赖概率估计的原因。某个候选项看似很可能被接受，但如果检查它会让批次扩展为低效形态，其实际效用仍可能很差。调度器既需要置信度，也需要实测的系统成本。

Nvidia 的推测式解码文档展示了部署框架如何已经提供针对不同方法的配置。其 DFlash 支持需要草稿模型、草稿长度、掩码 token 以及选定的目标层。AngelSpec 则将问题进一步推进到跨实时请求的自适应资源分配。

这种按领域划分的方法与运行时自适应形成互补。MTP 仍然是面向高不确定性对话输出的轻量级路径。DFly 则面向代码和数学任务，在这些场景中，并行块能够捕捉更长的可预测序列。没有任何一种方法天然适用于所有请求。

以生成重复性测试套件的 AI 编程服务为例。导入语句、函数签名和断言模式都可能让下一个代码块相对容易预测。DFly 可以提出更长的续写，且在置信度维持较高时，D-Cut 能保留更深入的验证。

再考虑同一服务回答一个含糊的架构问题。相同提示词可以引出多种有效解释。由于草稿模型和目标模型可能选择不同措辞，被接受的前缀可能缩短。较小的 MTP 提议可以避免将资源花在一个存活概率很低的长候选块上。

这一机制使得此次发布的意义不止于单项基准测试提升。它将推测式解码重新定义为一项横跨训练数据、草稿架构、请求分类和服务成本的策略。加速效果来自这些层面的协同，而不是最大化某一项孤立指标。

AngelSpec 的数据尚未证明什么

AngelSpec 提供了可信的第一方证据，但尚未证明 DFly 能在不同模型、硬件或生产流量中全面胜出。

论文中的结果来自设计该框架并训练草稿模型的团队。截至发布时，所报告的对比结果尚未得到独立复现。读者应将这些加速结果视为公司测得的主张，而非普遍适用的性能保证。

模型依赖性是第一个限制。DFly 使用目标模型的内部特征，因此草稿模型与其目标模型的架构和训练特性紧密绑定。Hy3-A21B 草稿模型无法直接成为不相关模型家族的即插即用加速器。

这种关联会提高训练和维护成本。每个受支持的目标模型可能都需要自己的隐藏状态提取流程、训练数据混合方案、检查点和验证周期。目标模型的更新也可能需要重新进行兼容性测试或训练新的草稿模型。

硬件依赖性带来了另一项不确定性。Tencent 表示 D-Cut 使用经分析的运行时成本，这承认最佳验证策略会因系统而异。为一个集群调优的策略，在不同加速器或网络拓扑上表现良好之前，可能需要新的性能分析数据。

公开的标题数据也将多种工作负载压缩为区间。代码、数学和对话任务的可预测性各不相同。平均吞吐量可能掩盖表现较弱的类别、不利的提示词长度，或草稿开销接近所节省目标模型计算量的流量模式。

长上下文行为尤其值得审视。AngelSpec 支持长上下文训练，Hy3 的上下文窗口为 256,000 token。然而，大型键值缓存会增加内存压力，并改变草稿生成和验证的相对成本。较短上下文下的结果无法确定接近模型最大窗口时的性能。

质量保持同样需要严谨的实现。推测式解码可通过正确的接受与拒绝算法保持目标分布。部署中的捷径、近似验证、修改后的采样策略或不兼容的量化都可能改变输出。运营者必须同时验证速度和行为等价性。

内存也是一项实际成本。目标模型、草稿模型、隐藏状态接口和额外运行时缓冲区必须共存。即便是轻量级草稿模型，也可能压缩键值缓存或更大批次的可用空间。在内存受限的部署中，由此产生的容量权衡可能抵消吞吐量提升。

运维复杂性同样重要。生产服务必须监控接受长度、草稿时间、验证时间、队列行为和回退性能。在 MTP 与 DFly 之间路由会引入另一层决策；一旦出错，就可能将不合适的工作负载送往错误的草稿模型。

开源发布让这些问题具备了可测试性，这很有价值。但它不会自动回答这些问题。团队应先在自身硬件上复现自回归基线，再比较任一 AngelSpec 路径。

随后，应按工作负载和流量水平拆分测量结果。实用类别包括交互式聊天、代码补全、数学推理、工具调用轨迹和长文本生成。每个类别都应包含延迟百分位数、吞吐量、内存消耗、接受长度和输出等价性检查。

公平的 DFlash 对比也需要匹配条件。应使用相同的目标模型、精度、服务框架、提示词分布、输出长度和并发度。否则，架构层面的主张可能会与内核质量或配置差异纠缠在一起。

社区反馈可以提供早期信号，但不能替代受控复现。本地部署报告通常使用量化模型、消费级硬件或改造过的服务引擎。这些结果能揭示兼容性问题，但通常无法与论文设置足够接近，从而验证其标题区间。

基准测试缺口并不意味着 AngelSpec 不重要。它界定了这个故事的下一阶段。Tencent 已提供了一套架构、代码路径和模型权重，外部团队可以在原作者无法控制的条件下对其提出挑战。

三项信号将决定 AngelSpec 能否走出 Hy3

AngelSpec 的重要性将取决于独立复现、更广泛的模型支持，以及自适应路由能否经受真实生产流量的检验。

第一个信号是独立推理团队可复现的 Hy3-A21B 基准测试。最有力的测试将使用已发布的 MTP 和 DFly 权重，同时报告硬件、精度、框架版本、提示词构成和输出长度。在匹配条件下，它应对比自回归解码、MTP、DFlash 和 DFly。

若复现结果接近 Tencent 所称的 1.98 至 2.40 倍区间，将强化其核心主张。若相较 DFlash 也能持续获益，则表明前序条件化和 D-Cut 的价值超越了通用的块扩散草稿生成。更小或不稳定的收益则会削弱 AngelSpec 的实际吸引力。

最有价值的独立报告不应只公布平均吞吐量。它还应包括首 token 时间、token 间延迟、尾延迟、内存使用量、接受长度以及不同并发水平下的性能。这些测量将显示，整体效率的提升是否真正改善了用户体验。

第二个信号是对另一个主要目标模型家族的支持。AngelSpec 目前最明确的证据和已发布草稿权重集中在 Hy3。若能成功移植到 Qwen、Llama 或其他被广泛部署的开放模型，将检验其框架能否泛化到 Tencent 架构之外。

移植也会揭示采用它的真实成本。研究人员需要生成目标模型隐藏状态、训练专用草稿模型、集成验证流程并分析运行时行为。一份工程工作量合理且有文档记录的移植成果，将强化该框架端到端可用性的主张。

若无法吸引移植工作，则可能表明 AngelSpec 主要是一套 Hy3 优化包。这一结果仍能惠及 Tencent 模型用户，但会削弱其作为统一推测式解码框架的更广泛论点。

第三个信号是来自混合工作负载的生产证据。Tencent 的论点依赖异质性，因此静态基准测试无法完全验证它。决定性测试在于：当流量、领域和硬件利用率不断变化时，实时服务能否在 MTP 和 DFly 之间做出正确选择。

运营者应关注路由决策在多大程度上提升了单位验证成本下的已接受输出量。他们还应衡量回退率和路由错误率。复杂的自适应系统必须在计入监控和调度开销后，依然胜过更简单的基线。

这项测试尤其适用于同时提供聊天、编程、数学工作和代理操作的服务。这类产品生成的输出在熵和长度上差异显著，也正是在这些条件下，专用草稿生成应当优于通用策略。

如果混合工作负载部署展现出稳定收益，竞争者将面临压力，需要提供类似的路由控制能力。服务框架可能从启动时选择一种推测算法，演变为按请求分配算法和验证预算。

如果收益在精心筛选的工作负载之外消失，更简单的方法仍会具有吸引力。MTP 可能更易于运维，尤其是在模型本身已提供兼容层的情况下。静态草稿策略也能减少团队必须维护的模型和策略数量。

评估此次发布的开发者应将测试结果和配置决策保存在一个可搜索的工程知识库中。推测式解码实验涉及足够多的交互变量，以至于未记录的运行结果很快便无法比较。

AngelSpec 已经改变了推理工程师面临的问题。选择不再只是是否启用推测式解码，而是草稿模型、训练分布、验证策略和硬件配置是否足够契合每个请求，从而节省真正的计算工作。

未来一到三个月将揭示外部团队是否能复现 Tencent 的数据、将 DFly 移植到 Hy3 之外，以及在实时需求下验证自适应路由。在此之前，AngelSpec 是一项拥有有前景第一方结果的严肃开放实验，而非已有定论的赢家。

对于当前服务 Hy3 的团队，下一步应是在既有自回归和 MTP 配置的基础上进行受控基准测试。对其他所有人而言，关键问题更为具体：面向工作负载的草稿生成，能否带来足够持续的效率提升，以证明额外增加一个模型和调度层是合理的？答案将决定 AngelSpec 是成为被广泛采用的推理框架，还是主要停留为与 Tencent 自身模型家族紧密绑定、经过精心工程化的优势。