SpecForge v0.3.0：统一投机解码堆栈发布

从耦合训练器到训练流水线

一道边界，三份契约

1. 采集契约

2. 交付契约

3. 生命周期契约

这种分离解锁了什么

独立的推理和训练资源池

初步系统结果：3 台采集服务器 + 5 个训练器

一个运行时支持多种草稿家族

数据源与部署是可以独立选择的

特性源不等于数据策略

一份配置，一个入口

训练示例：Qwen3.6-27B

训练示例：Kimi-K3

草稿模型服务性能

更多覆盖不同方法和目标的草稿模型

已发布的模型与性能

验证训练-服务一致性

当我们首次发布 SpecForge 时，一个训练任务同时拥有冻结的目标模型和正在优化的草稿模型。这使得 EAGLE3 草稿模型训练变得实用，并与 SGLang 直接兼容，但也将两种截然不同的工作负载绑定到了同一个进程生命周期和资源拓扑上。

今天，我们为 SpecForge 推出一项重大更新。新运行时将目标模型推理与草稿模型训练分离，支持更广泛的投机解码算法家族，并将在线、离线和解聚的工作流统一到一个类型化的训练入口点。同时，我们发布了更多草稿模型，覆盖了不同的投机解码方法和不同的目标模型。

在线训练现已完全解聚。打补丁的 SGLang 服务器采集目标模型特征，Mooncake 传输张量，训练器工作进程通过单独的控制平面消费轻量级引用。

推理和训练可以独立扩展。在我们的 8×H20 测试床上，3 台 SGLang 服务器和 5 个训练器工作进程的拓扑相比之前的共置实现，端到端训练吞吐量提升约 10%。

一个运行时现在支持多种草稿家族：EAGLE3、EAGLE3.1、P-EAGLE、DFlash、Domino 和 DSpark，以及 DFlash 可选的 D-PACE 目标函数。

更多草稿模型正在发布，其中大部分由社区贡献。合作伙伴和个人贡献者使用此运行时训练并发布了覆盖不同投机解码方法和不同目标模型的草稿模型，全部仅使用开放数据训练。

此版本还附带一个训练-服务一致性门，用于验证采集、训练、导出和 SGLang 服务在受控示例上达成一致——在投入完整训练前进行快速正确性检查。

从耦合训练器到训练流水线

在线草稿模型训练包含两个不同的工作负载：

目标侧在训练对话上运行一个大型冻结模型以采集隐藏状态。它是推理密集型的，通常使用张量并行，并受益于生产级推理引擎。

草稿侧用前向和反向传播训练一个更小的模型。它通过数据或序列并行扩展，具有不同的内存和计算特征。

在之前的共置设计中，两侧共享一个生命周期和一种固定的资源布局。这产生了三个实际限制：

固定的推理-训练比例。扩展训练器工作进程也会影响目标模型放置，即使只有一侧是瓶颈。

资源干扰。目标采集和草稿优化在同一紧密耦合的任务中相互竞争。

共享的故障边界。缓慢或失败的特征生成可能导致训练停滞，而过度的生产可能造成无界的内存压力。

关键观察很简单：训练器不需要拥有目标模型。它们只需要所选训练目标函数所需的 token 序列、掩码和目标特征。使该边界显式化将 SpecForge 从一个包含目标模型的训练器进程转变为协调的训练流水线。

一道边界，三份契约

新在线运行时有一个生产者池和一个消费者池。生产者在打补丁的 SGLang 采集服务器间调度提示词。SGLang 将特征张量写入 Mooncake，而 SpecForge 只通过控制平面发送轻量级的 SampleRef 元数据。训练器 rank 在准备好构建批次时解析这些引用。

图 1. 在线解聚训练流程。大张量保留在数据平面；引用和生命周期状态通过控制平面传输。

1. 采集契约

deployment.disaggregated.server_urls 中的每个 URL 创建一个连接到打补丁 SGLang 服务器的滚动更新工作进程。工作进程从共享控制器租用不相交的提示词，因此采集容量可以改变而无需更改训练器拓扑。

采集支持是在固定版本 sglang==0.5.14 之上的一小部分补丁：patches/sglang/v0.5.14/spec-capture.patch 添加了 --enable-spec-capture 标志和一个服务器端 sink，使用特征存储的键布局将采集的张量直接写入 Mooncake。采集服务器是一个应用了此补丁的标准 SGLang 服务器。

这创建了清晰的拥有权边界：SGLang 拥有目标模型并行性和特征采集，而 SpecForge 拥有提示词调度、引用发布和草稿模型优化。

2. 交付契约

采集到的隐藏状态可能很大，因此通过 Python 队列或控制数据库转发它们很快就会成为瓶颈。SpecForge 将张量存储与样本协调分离：

SGLang 将特征张量写入 Mooncake。

生产者发布无张量的 SampleRef 记录。

FeatureDataLoader 将引用解析为携带张量的训练批次。

训练器在收到优化器步骤确认后释放特征对象。

训练循环依赖于 FeatureStore 契约而非特定传输。因此，同一消费者路径可以使用本地特征、共享目录或 Mooncake 支持的在线采集。

3. 生命周期契约

分布式 rank 必须共同推进。消费者以完整的优化器步骤量子释放引用，因此每个 rank 收到其进行一次同步更新所需的样本。高级和低级飞行中水印暂停和恢复采集，防止生产者任意超前于训练。

在优化器边界处，消费者 rank 0 在确认减少飞行中深度并释放特征对象之前，将已训练样本 ID 记录到保留的 SQLite 账本中。中断后，消费者可以使用该账本跳过已完成的样本 ID 并重放剩余引用。

生产者也明确处理故障。失败的采集工作进程将其租用的提示词返回共享控制器，允许健康的工作进程继续。如果所有采集服务器都不可用或提示词耗尽其重试预算，运行将大声失败。

这些契约共同使训练器独立于特征传输，同时不削弱分布式步骤对齐、有界缓冲或恢复语义。

这种分离解锁了什么

新边界产生了两个用户可见的好处：基础设施可以围绕工作负载进行平衡，算法实现可以共享一个训练运行时。

独立的推理和训练资源池

目标模型张量和专家并行现在属于 SGLang；草稿模型数据和序列并行属于 SpecForge。两个资源池可以在一个本地监督器下运行，也可以作为单独调度器管理的作业。

当两个资源池共享固定 GPU 预算时，它们的比例仍是一种资源权衡。区别在于该权衡现在是显式的和可调的，而不是硬编码到训练器中的。当有更多资源可用时，任一资源池都可以扩展，而无需强制另一个采用相同的拓扑。

在 8×H20 测试床上，我们使用 3K token 上下文长度评估了 Qwen3-8B Domino 训练。将工作负载重新分配给 3 台 SGLang 采集服务器和 5 个训练器工作进程，相比之前的共置实现，测量的端到端训练吞吐量提升约 10%。

以下配置文件展示了这两种运行时拓扑的代表性训练窗口。

(a) 共置基准

(b) 解聚：3 台 SGLang 服务器 + 5 个训练器工作进程

图 2. 3K token 上下文长度下 Qwen3-8B Domino 训练的代表性训练窗口。吞吐量表格报告了端到端对比；跟踪轨迹提供了两种执行模式的定性视图。

在此工作负载中，性能分析表明收益来自特征生成供给与训练器需求之间更精确的匹配。更广泛的好处是配置灵活性：不同的目标大小、序列长度和预测算法可以使用不同的捕获-训练比，而无需再实现一套训练器。

一个运行时支持多种预测族

SpecForge 最初对 EAGLE3 有着强烈的关注。新运行时将通用系统关注点与策略特定的建模代码分离。

每种策略都复用提示调度、特征传输、分布式执行、检查点保存和进程监督。策略只需定义它需要的目标特征、这些特征如何构成训练批次、其草稿模型架构及其目标函数。

这里所说的统一，指的是同一套配置模式、启动器、数据流契约、训练器生命周期和检查点接口。并不意味着每种策略都支持所有数据源和拓扑组合。

数据源与部署是独立的选择

在线（online）和离线（offline）描述的是目标特征的来源。本地（local）和分离（disaggregated）描述的是训练工作流的部署方式。将这些概念分开使支持的组合更容易理解：

每次在线运行都使用生产者/消费者拓扑；训练器永远不会初始化共置的目标模型。离线 EAGLE3、DFlash、Domino 和 DSpark 训练可以在本地运行，也可以使用独立的摄取池和消费者池运行。P-EAGLE 目前仅支持在线训练。

特征源不是数据策略

在实践中还有一个更重要的区别。捕获服务器对你提供的对话执行完整的预填充，从不生成训练响应，因此在线捕获并不选择草稿从谁的文本中学习——数据集决定这一点。这个选择比任何拓扑决策都更重要：当数据集响应由人类或另一个模型编写时，草稿学习的是目标模型本身很少产生的文本延续，而接受率在远低于相同草稿在目标生成数据上达到的水平时就饱和了。在我们的训练运行中，用目标模型重新生成数据集响应——以将被服务的推理模式贪婪地生成——一直是最终接受率的最大杠杆。我们建议为每种策略使用目标生成的数据。下面描述的一致性门（consistency gate）依赖于相同的属性：其服务阶段只有在训练样本是目标在温度 0 时能复现的文本时才能通过。

完整的策略矩阵见训练指南，分离式训练指南见部署详情。

一个配置，一个入口

拓扑与模型、数据、算法和优化器设置共存于同一个类型化的 YAML 文档中。以下节选展示了上面使用的三服务器/五训练器形态：

training:
  strategy: domino

deployment:
  mode: disaggregated
  trainer:
    nnodes: 1
    nproc_per_node: 5
  disaggregated:
    control_dir: outputs/qwen3-8b-domino/control
    consumer_state_dir: outputs/qwen3-8b-domino/consumer-state
    backend: mooncake
    server_urls:
      - http://capture-0:30000
      - http://capture-1:30000
      - http://capture-2:30000

同一命令解析并启动所选拓扑：

specforge train --config run.yaml

在单节点上，启动器可以同时监督两个 SpecForge 角色。在外部调度器下，各池可以使用相同配置独立启动：

# 推理和摄取池
specforge train --config run.yaml --role producer

# 草稿模型训练池
specforge train --config run.yaml --role consumer

没有方法特定的 Python 训练入口点。完整的、可运行的配置示例见 examples/configs。

训练示例：Qwen3.6-27B

使用单条命令在单节点上启动训练和推理：

specforge train --config examples/configs/qwen3.6-27b-dspark-disaggregated.yaml

训练示例：Kimi-K3

训练配方列在 docs/recipes/kimi-k3-dspark-disaggregated.md。

草稿模型服务性能

训练系统吞吐量和草稿模型服务加速回答的是不同的问题。上面 H20 的结果衡量的是训练管道的效率。以下评估衡量的是用 SpecForge 训练的草稿检查点的端到端服务加速；它不用作 10% 训练运行时间结果的证据。

我们在 2×A100 GPU 上对 Qwen3.6-27B-Domino 进行了评估。所有值均相对于仅目标自回归解码（AR = 1.00×）。B8 和 B16 表示草稿块大小分别为 8 和 16。

在并发度为 1 时，Domino-B16 在所有六个数据集上都提供了最高加速，范围从 Alpaca 的 3.34× 到 MATH500 的 5.72×。

更多跨方法和目标 的草稿模型

一个训练栈只有在产生人们实际能部署的检查点时才有价值。投机解码提供了强有力的理论保证，并在令牌接受率和端到端速度上带来了一致的收益，但开源社区的采用受到生产级训练工具的缺乏、高质量草稿检查点的稀缺以及这些草稿训练数据规模较小的限制。

因此，除了运行时之外，现在还有一套更大的开放草稿模型可用——而引人注目的是，我们自己训练的只占其中很小一部分。在生产中运行 SpecForge 的团队为他们实际服务的目标训练了草稿预测器，并将权重贡献回来，全部仅使用开放数据。以下列出的 11 个检查点中有 9 个是以这种方式贡献的，来自 Ant Group AQ、RadixArk、招商银行、Domino 作者和社区个人成员。

这种流入沿着两个轴扩展了目录：

更广泛的目标覆盖——覆盖社区实际部署的开源模型，从指令调优模型扩展到推理模型以及当前开放权重发布的前沿。

更广泛的方法覆盖。按照上一节描述的算法，发布的检查点现在涵盖 EAGLE3、DFlash、Domino 和 DSpark。范围内的一些目标也附带了一个原生 MTP 头，让社区有机会在同一目标上比较这些预测器与原生 MTP。

如果你已经用 SpecForge 训练了草稿模型，我们希望将它托管在这些模型旁边——欢迎贡献新的目标和新的算法。

发布的模型与性能

所有检查点均发布在 Hugging Face 的 SpecBundle 集合中。

部分模型的结果如下，按算法分组。

图 3. 三种 EAGLE3 草稿模型在同一预测配置下（3 步，top-k 1，4 个草稿令牌）：输出吞吐量与自回归基线的对比，加速倍数标注在每个条形上方。Step-3.5-Flash 和 Qwen3-32B 在 4 × H200 上以并发度 16 测量；Kimi-K2.7-Code 数字是其模型卡上发布的 8 × H200、并发度 8 的结果。

图 4. Qwen3.5-397B-A17B 在 8 × B200 上（TP8，bfloat16，思考启用，贪婪解码，最大输出令牌 4096）：DFlash 在块大小 8 时相对于自回归基线的输出吞吐量。块大小 16 在并发度 1 时更高——在 HumanEval 上最高达 4.31×——而块大小 8 在负载下是更强的选择。完整数字（包括 MTP 对比）见模型卡。

图 5. Qwen3.6-27B 在 2 × A100 上（TP2，BF16，思考启用，贪婪解码）：Domino 在块大小 8 时相对于自回归基线的输出吞吐量，加速倍数标注在每个条形上方。收益在并发度 1 时最大——在 MATH500 上高达 4.60×——在并发度 32 时收窄至 1.48–2.11×，此时目标模型已得到更好的利用。完整的每个工作负载数字（包括其他块大小以及 MTP 和 DFlash 对比）见模型卡。

图 6. Kimi-K3 在 8 × B300 上：DSpark 相对于自回归基线在五个工作负载上的输出吞吐量，加速倍数标注在每个条形上方。收益在并发度 1 时最大——在 GSM8K 上高达 3.14×——在并发度 16 时收窄至 1.37–2.36×，此时目标模型已得到更好的利用。MT-Bench，五个中最开放的，在每个并发度下收益最小。完整数字见模型卡。

验证训练-服务一致性

模型质量基准测试和正确性门禁（correctness gate）服务的目的不同。基准测试衡量的是泛化能力；门禁则检查训练、导出和服务是否实现了相同的算法契约。

SpecForge 为 DFlash 系列模型（包括 Domino）提供了端到端的训练和服务门禁，包含三个阶段：

选择一个有效样本。门禁在生成可审计的提示产物之前，检查目标聊天模板、推理模式、分词器行为、序列长度和最小可训练后缀。

通过公开训练路径进行过拟合。通过 specforge train 启动的有限轮次运行重复该样本，然后要求达到配置的损失阈值和 token 准确率阈值，以及精确的最终检查点。

导出并服务检查点。通过 specforge export 导出，启动带有 DFlash 推测解码的 SGLang，并验证每个请求的接受率元数据以及与目标 token 前缀的一致性。

这个门禁设计得刻意严格且范围狭窄。通过它表示捕获、训练、导出和服务在一个受控示例上达成一致；它不能替代留出的模型质量或服务性能评估。

此版本改变了 SpecForge 的扩展单位。一次运行不再是恰好包含一个目标模型的训练器进程；而是一个协调的流水线，其推理能力、存储和优化能力可以独立调整规模。

我们的下一步是为剩余的目标模型完成草稿模型的发布，并继续扩展算法和模型目录。我们还将在不同模态（如 VLM）以及不同硬件平台（包括但不限于 AMD 和 Ascend）上进行测试和适配。

感谢 SGLang 和 SpecForge 社区、支持推测解码方法的作者，以及帮助测试新运行时和算法集成的所有贡献者。

SpecForge 团队：Jiaping Wang、Shenggui Li、Xiaoming Dong、Chao Wang 和 Ji Li

RadixArk 团队：Cheng Mao、Yi Sun 和 Kan Wu

Domino 团队：Jianuo Huang

Ant Group AQ 团队：Yefei Chen、Yuan Wang

China Merchants Bank 团队：Peixiang Tan

Meta/Pytorch：Richard Zou