SpecForge v0.3.0：统一解耦与共置的投机解码技术栈，以及全新开放的 SpecBundle 草稿模型

SpecForge 团队

2026 年 8 月 4 日

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

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

新增内容

• 在线训练现已完全解耦。打过补丁的 SGLang 服务器捕获目标模型特征，Mooncake 负责传输张量，训练工作节点通过独立的控制平面消费轻量级引用。
• 推理和训练可以独立扩展。在我们的 8xH20 测试平台上，采用 3 个 SGLang 服务器和 5 个训练工作节点的拓扑结构，相比之前的共置实现，端到端训练吞吐量提升了约 10%。
• 单一运行时现在支持多种草稿模型家族：EAGLE3、EAGLE3.1、P-EAGLE、DFlash、Domino 和 DSpark，以及可选的 D-PACE 目标（用于 DFlash）。
• 更多草稿模型正在发布，其中大部分由社区贡献。合作伙伴和个人贡献者已使用该运行时，针对不同的投机解码方法和不同的目标模型训练并发布了草稿模型，且全部仅基于开放数据训练。

本次发布还附带了一个训练-服务一致性门控，用于验证捕获、训练、导出和 SGLang 服务在受控示例上是否一致——这是在投入完整训练运行之前进行的一次快速正确性检查。

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

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

• 目标侧在训练对话上运行一个大型冻结模型，以捕获隐藏状态。该过程推理负载较重，通常使用张量并行，并受益于生产级推理引擎。
• 草稿侧训练一个规模小得多的模型，执行前向和反向传播。它通过数据并行或序列并行进行扩展，其内存和计算特征与目标侧不同。

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

1. 固定的推理与训练比例。扩展训练工作进程也会影响目标模型的放置，即使只有一侧成为瓶颈。
2. 资源干扰。目标捕获和草稿优化在同一个紧密耦合的作业内部相互竞争。
3. 共享的故障边界。特征生成缓慢或失败可能导致训练停滞，而过量生产则可能造成无界的内存压力。

关键观察很简单：训练方并不需要拥有目标模型。他们只需要所选训练目标所需的 token 序列、掩码和目标特征。明确这一边界将 SpecForge 从一个包含目标模型的训练进程转变为一个协调的训练流水线。

一个边界，三个契约

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

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

1. 捕获契约

deployment.disaggregated.server_urls 中的每个 URL 都会创建一个与打过补丁的 SGLang 服务器连接的 rollout 工作进程。工作进程从共享控制器租用互不重叠的提示词，因此捕获容量可以在不改变训练拓扑的情况下进行调整。

捕获支持是在固定的 sglang==0.5.14 之上打的一个小补丁：patches/sglang/v0.5.14/spec-capture.patch 添加了一个 --enable-spec-capture 标志，以及一个服务端接收端，用于将捕获的张量直接写入 Mooncake，采用特征存储的键布局。捕获服务器就是应用了此补丁的标准 SGLang 服务器。

这形成了清晰的职责边界：SGLang 负责目标模型并行和特征捕获，而 SpecForge 负责提示词调度、参考发布和草稿模型优化。

2. 交付契约

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

• SGLang 将特征张量写入 Mooncake。
• 生产者发布不含张量的 SampleRef 记录。
• FeatureDataLoader 将引用解析为携带张量的训练批次。
• 训练器在优化器步进确认后释放特征对象。

训练循环依赖 FeatureStore 契约，而非特定的传输方式。因此，相同的消费路径可以使用本地特征、共享目录或基于 Mooncake 的在线捕获。

3. 生命周期契约

分布式各 rank 必须同步推进。消费者以完整的优化器步进量子释放引用，因此每个 rank 都能获得一次同步更新所需的样本。高、低在途水位线会暂停和恢复捕获，防止生产者运行得远超训练进度。

在优化器边界处，消费者 rank 0 在确认操作降低在途深度并释放特征对象之前，将已训练的样本 ID 记录到持久化的 SQLite 账本中。中断后，消费者可以利用该账本跳过已完成的样本 ID，并重放剩余的引用。

生产者侧的失败也是显式的。失败的捕获工作进程会将其租用的提示词返回给共享控制器，使健康的进程能够继续工作。如果所有捕获服务器都不可用，或某个提示词耗尽重试预算，运行将明确失败。

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

这种分离带来的价值

新的边界带来了两个用户可见的收益：基础设施可以围绕工作负载进行均衡，算法实现可以共享同一个训练运行时。

独立的推理池和训练池

目标模型的张量和专家并行现在归属于 SGLang；草稿模型的数据和序列并行归属于 SpecForge。这两个池可以在同一个本地管理进程下运行，也可以作为由调度器分别管理的独立任务运行。

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

初步系统结果：3 个捕获服务器 + 5 个训练器

在 8×H20 测试平台上，我们评估了 Qwen3-8B Domino 训练，上下文长度为 3K token。将工作负载重新分配到三个 SGLang 捕获服务器和五个训练器工作节点后，实测端到端训练吞吐量比之前的同置实现提升了约 10%。

运行时	目标捕获	草稿训练	相对端到端训练吞吐量
之前的同置版本	与训练任务耦合	固定的同置布局	1.00×
新的分离式运行时	3 个 SGLang 服务器	5 个训练器工作节点	1.10×

下面的性能剖析图展示了两种运行时拓扑下具有代表性的训练时间窗口。

(a) 同置基线

(b) 分离式：3 个 SGLang 服务器 + 5 个训练器工作节点

图 2. Qwen3-8B Domino 在 3K token 上下文长度下具有代表性的训练时间窗口。吞吐量表给出的是端到端对比；轨迹图提供了两种执行模式的定性视图。

在该工作负载中，性能剖析表明性能提升来自于特征生产供给与训练器需求之间更好的匹配。更广泛的收益在于可配置性：不同的目标模型规模、序列长度和草稿算法可以使用不同的捕获与训练比例，而无需再实现另一种训练器。

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

SpecForge 最初以 EAGLE3 为重点。新的运行时将通用系统关注点与策略特定的建模代码分离开来。

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

方法	策略特定思路	SpecForge 支持
EAGLE3	带训练时测试和多层目标特征融合的直接 token 预测	在线分离式、本地离线式和分离式离线式；可选 LK 损失目标
P-EAGLE	通过共享隐藏状态进行并行多 token 预测	在线分离式
EAGLE3.1	EAGLE3 配置变体，带逐层归一化和注意力漂移设置	通过 eagle3 策略实现在线分离式
DFlash	并行预测一个 token 块的块扩散草稿生成	在线分离式、本地离线式和分离式离线式；可选 D-PACE 目标
Domino	并行草稿主干网络，后接轻量级因果修正头	在线分离式、本地离线式和分离式离线式
DSpark	带置信度建模的半自回归草稿生成，用于自适应验证	在线分离式、本地离线式和分离式离线式

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

数据源与部署是相互独立的选项

在线和离线描述的是目标特征的来源。本地和分离式描述的是训练工作流的部署方式。将这两个概念分开，更容易理解所支持的组合：

特征来源	本地/数据流部署	生产者/消费者部署
在线 SGLang 捕获	不支持	支持，配合 Mooncake
离线特征检查点	支持	支持，配合共享特征存储

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

特征来源不是数据策略

在实践中，还有一个区别很重要。捕获服务器会对您提供的对话执行完整的预填充，并且绝不会生成训练响应，因此在线捕获并不会决定草稿模型学习谁的文本——数据集才决定这一点。这个选择比任何拓扑决策都更重要：当数据集响应由人类或其他模型编写时，草稿模型学习到的是延续目标模型本身很少会生成的文本，其接受率会远低于同一草稿模型在目标模型生成的数据上所能达到的水平。在我们的训练运行中，使用目标模型重新生成数据集响应——采用将用于服务的推理模式进行贪婪解码——一直是影响最终接受率的单一最大杠杆。我们建议所有策略都使用目标模型生成的数据。下文描述的一致性门控也依赖于同一特性：只有当训练样本是目标模型在温度为 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

数据集	AR	MTP-S3	MTP-S7	DFlash-B8	DFlash-B16	Domino-B8	Domino-B16
GSM8K	1.00×	2.68×	3.22×	3.79×	4.25×	4.36×	5.25×
MATH500	1.00×	2.80×	3.55×	4.29×	5.07×	4.60×	5.72×
HumanEval	1.00×	2.65×	3.18×	3.98×	4.47×	4.20×	4.98×
MBPP	1.00×	2.57×	2.98×	3.73×	3.91×	3.97×	4.49×
MT-Bench	1.00×	2.44×	2.65×	3.00×	3.05×	3.31×	3.44×
Alpaca	1.00×	2.38×	2.54×	2.87×	2.84×	3.18×	3.34×

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

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

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

因此，除了运行时之外，现在还有一大批开放草稿模型可用——而最引人注目的地方在于，其中我们自己训练的少之又少。在生产环境中运行 SpecForge 的团队为他们实际服务的训练了草稿模型，并将权重回馈给社区，且全部仅使用开放数据训练。下面列出的十一个检查点中有九个是以这种方式贡献的，来自蚂蚁集团 AQ、RadixArk、招商银行、Domino 作者以及社区个人成员。

这种流入从两个维度拓宽了模型目录：

1. 更广泛地覆盖社区实际部署的开源模型目标，从指令微调模型扩展到推理模型，以及当前开放权重发布的前沿。
2. 更广泛的方法覆盖。按照上一节所述的算法，本次发布的检查点现已涵盖 EAGLE3、DFlash、Domino 和 DSpark。范围内的多个目标模型还自带原生 MTP 头，让社区有机会在同一目标上将这些草稿模型与原生 MTP 进行对比。

如果您使用 SpecForge 训练了草稿模型，我们很乐意将其与这些模型一同托管——欢迎贡献新的目标模型和新的算法。

已发布模型与性能

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

目标模型	草稿模型	算法	提供方
GLM-5.1	🤗	EAGLE3	蚂蚁集团 AQ
Kimi-K2.5	🤗	EAGLE3	蚂蚁集团 AQ
Kimi-K2.6	🤗	EAGLE3	蚂蚁集团 AQ
Kimi-K2.7-Code	🤗	EAGLE3	蚂蚁集团 AQ
Qwen3-32B	🤗	EAGLE3	招商银行
Qwen3.5-35B-A3B	🤗	EAGLE3	SpecForge
Step-3.5-Flash	🤗	EAGLE3	RadixArk
Qwen3.5-397B-A17B	🤗	DFlash	LMSYS
Qwen3.6-27B	🤗	Domino	Domino 团队
Inkling-Small	🤗	DSpark	RadixArk
Kimi-K3	🤗	DSpark	RadixArk

以下按算法分组展示其中部分模型的结果。

EAGLE3

图 3. 三个 EAGLE3 草稿模型在相同草稿配置（3 步、top-k 1、4 个草稿 token）下的输出吞吐量，与自回归基线对比，每根柱子上方标注了加速比。Step-3.5-Flash 和 Qwen3-32B 在 4 × H200、并发 16 下测量；Kimi-K2.7-Code 的数据为其模型卡上发布的 8 × H200、并发 8 的结果。

DFlash

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

Domino

图 5. Qwen3.6-27B 在 2 × A100（TP2、BF16、启用思考模式、贪心解码）上：Domino 在块大小 8 时的输出吞吐量与自回归基线对比，每根柱子上方标注了加速比。加速效果在并发 1 时最大——在 MATH500 上最高达 4.60×——在并发 32 时收窄至 1.48–2.11×，此时目标模型已被更充分地利用。

完整的按工作负载统计数字，包括其他块大小以及 MTP 和 DFlash 对比，均可在模型卡上查看。

DSpark

图 6. Kimi-K3 在 8 × B300 上的表现：DSpark 在五个工作负载下相对于自回归基线的输出吞吐量，加速比标注在每个柱状图上方。在并发度为 1 时增益最大——GSM8K 上最高达 3.14×——在并发度为 16 时收窄至 1.37–2.36×，此时目标模型已被更好地利用。MT-Bench 是五个工作负载中开放性最强的，在每个并发级别下受益都最小。完整数据见模型卡。

验证训练-服务一致性

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

SpecForge 为 DFlash 系列模型（包括 Domino）提供了端到端的训练和服务门控。它执行三个阶段：

1. 选择一个有效样本。门控在生成可审计的提示词工件之前，检查目标聊天模板、推理模式、tokenizer 行为、序列长度和最小可训练后缀。
2. 通过公开训练路径进行过拟合。它通过 specforge train 启动一个有界运行来重复该样本，然后要求达到配置的损失和 token 准确率阈值以及精确的最终检查点。
3. 导出并服务该检查点。它通过 specforge export 导出，启动带有 DFlash 投机解码的 SGLang，并验证每个请求的接受元数据以及与目标 token 前缀的一致性。

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

下一步计划

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

我们的下一步计划是完成上述其余目标模型的草稿模型发布，并继续扩展算法和模型目录。我们还将在不同模态（如 VLM）以及更多硬件平台上开展测试与适配，包括但不限于 AMD 和昇腾。

致谢

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

SpecForge 团队：王佳平、李胜贵、董晓明、王超、李季

RadixArk 团队：毛诚、孙毅、吴侃

Domino 团队：黄佳诺

蚂蚁集团 AQ 团队：陈叶飞、王媛

招商银行团队：谭培祥

Meta/PyTorch：Richard Zou

Modal 团队