DSpark 如何加速 Spark-X2.6：从逐词生成到批量验证

Fri, 06 Nov 2026 23:45:27 +0800

本地运行语言模型时，模型往往需要逐个生成 Token。回答越长，用户等待的时间也越长。推测解码（Speculative Decoding）提供了另一种生成路径：先用成本较低的草稿模型预测一段内容，再让目标模型一次验证这一段，从而减少目标模型串行运行的次数。

本文以 SparkLLM 发布的 Spark-X2.6-4B 和配套 DSpark 草稿模型为例，解释验证过程和性能数据的含义，帮助已经了解语言模型基本用法的读者判断是否值得在本地尝试。文中的速度数据来自项目方模型卡，并非独立复测；资料核查于 2026 年 11 月 7 日。

从逐个生成到一次验证多个候选

语言模型将文本拆成 Token，可以把它理解为模型处理的文本片段。普通自回归生成先根据已有上下文预测下一个 Token，把结果加入上下文，再预测下一个。由于后一步依赖前一步的结果，这些生成步骤需要串行进行。

推测解码将工作分给两个模型：目标模型负责最终的生成规则，草稿模型提前提出一串候选。目标模型可以针对这串已知候选，在一次前向计算中得到各位置的验证结果。验证仍要按顺序决定哪些候选可保留，但不必为每个候选单独运行一次目标模型。

假设草稿给出四个候选 A B C D。在贪心解码的示例中，目标模型同意前两个位置，在第三个位置选择 X：

草稿候选： A  B  C  D
验证结果： ✓  ✓  ✗
本轮输出： A  B  X

C 被拒绝后，D 依赖的前文已经改变，因此也要丢弃；下一轮从 A B X 继续。如果所有候选都被接受，目标模型还可根据完整候选前缀给出一个额外 Token。实际生成也可能提前遇到结束符或输出长度上限。

上述例子只描述贪心路径。对随机采样，验证不是简单比较两个模型各自抽到的 Token：标准推测采样通过接受概率和拒绝后的修正分布，保留目标模型的采样分布。分布一致不意味着同一个随机种子必然产生逐字相同的回答；具体保证也取决于推理引擎的采样实现和配置。推测解码论文给出了这种方法的理论说明。

DSpark 在这条路径中做什么

Spark-X2.6-4B-GGUF 是目标模型；Spark-X2.6-4B-DSpark-GGUF 是专门配套它的草稿模型。后者提供候选，不能替代目标模型独立完成这条推理路径。

模型卡列出的草稿模型有 624M 参数、5 层滑动窗口注意力，窗口大小为 512，权重采用 BF16；目标模型可使用 BF16 或量化后的 GGUF 权重。它利用目标模型第 2、10、18、25、33 层的隐藏状态，也就是目标模型处理中间得到的表示，辅助生成候选。草稿模型每次前向最多提出 7 个 Token，再交由目标模型验证。

滑动窗口限制了该注意力层直接关注的位置范围；完整推理的资源消耗还包括目标模型、缓存和其他操作，不能据此断言整体成本与上下文长度无关。草稿模型也要占用内存并执行计算，因此增加它并不自动带来加速。

接受长度不是速度倍数

项目方以最多 7 个草稿 Token、最多输出 4096 个 Token 测量平均接受长度。这里的接受长度包含目标模型额外提供的一个 Token，所以最大值是 8；例如平均值为 4，并不表示每轮平均接受了 4 个草稿 Token。

测试设置	六个数据集上的平均接受长度
目标温度 1，High thinking，草稿概率采样	4.02
目标温度 1，Low thinking，草稿概率采样	4.07
目标温度 1，关闭 thinking，草稿概率采样	4.50
目标温度 0，High thinking，草稿贪心解码	4.55

这四列同时改变了思考模式、目标温度或草稿采样方式，不能据此单独归因于其中某个设置。在第一列中，MATH500 为 4.59，Arena-Hard-v2 为 3.22，说明这组测试的不同任务上，草稿能被利用的长度不同。

每轮推进的 Token 越多，越有机会摊薄目标模型的调用成本；但一轮还要支付草稿生成和目标验证的时间。一个便于判断的近似关系是：

加速比 ≈ 平均每轮输出 Token 数 × 普通解码每 Token 耗时 ÷ 推测解码每轮耗时。

因此，即使平均每轮推进约 4 个 Token，也不能推导出 4 倍加速。如果草稿经常很早被拒绝，或草稿与验证的额外开销较大，收益会缩小，甚至可能变慢。

项目方实测：看清比较条件

下表是模型卡中六个数据集的平均生成吞吐量，单位为 Token/秒。RTX 4090 使用 llama.cpp，M5 Pro 使用 MLX；两种设备同时采用不同推理引擎，不能把差异单独归因于硬件。量化格式也不同。

设备、引擎与目标模型精度	普通解码	使用 DSpark	平均加速比
RTX 4090 · llama.cpp · BF16	95	203	2.14×
RTX 4090 · llama.cpp · Q4_K_M	226	447	1.98×
M5 Pro · MLX · BF16	31	77	2.50×
M5 Pro · MLX · INT4	71	115	1.62×

这是四组配置各自的平均加速比，不是所有任务都处于 1.62–2.50 倍之间。例如 M5 Pro 的 BF16 测试中，MATH500 为 2.94 倍；M5 Pro 的 INT4 测试中，Arena-Hard-v2 为 1.30 倍。表中吞吐量和倍数经过取整，直接相除可能略有差异。

这些数据反映生成阶段的吞吐量，不等于首 Token 延迟或完整请求的端到端加速。提示词处理、输出长度、并发负载、采样参数、显存和实现版本都可能改变实际效果。主模型量化后，普通解码本身也更快；草稿开销能否继续换来足够收益，需要在目标设备上测量。

在自己的工作负载上判断

如果设备有空间同时容纳目标模型、BF16 草稿权重和运行时缓存，并且应用经常生成较长文本，可以尝试对比。对于输出很短、提示词处理占主要时间或设备内存紧张的场景，先测量完整请求延迟与内存占用，再决定是否启用。

比较时保持目标模型及其量化版本、提示词、输出长度、采样和思考模式、上下文长度以及并发数一致，分别运行开启和关闭 DSpark 的请求。记录预热后的生成 Token/秒、首 Token 延迟、端到端耗时和峰值内存；多次运行并覆盖自己的典型任务。推测解码改变随机数的使用方式，采样结果可能不同，比较时应控制工作负载而不是要求文本完全相同。

截至核查日，模型卡给出的 GGUF 示例使用 XHToken/llama.cpp 的 master 分支，面向 Linux、Bash 和 NVIDIA GPU，并注明上游集成仍在进行。模型卡列出的 M5 Pro 数字来自 MLX，不能直接套用上述 CUDA 命令。安装步骤和支持状态会变化，实际部署前应查看模型卡中的版本与说明；普通运行只需要目标模型，启用该草稿路径则还需要对应的 DSpark 权重和支持它的运行时。

来源：