Alaya-DSpark × GLM-5.2：2.9×吞吐提升背后的推理加速技术

AlayaNeW面向GLM-5.2训练并开源的推测解码草稿模型。通过草稿模型并行起草、主模型批量验证、按置信度动态调整验证范围，在保持输出一致性的前提下将推理吞吐提升至约 352 tok/s，整体加速约 2.9 倍。

大模型生成慢，很多时候不是“想不出来”，而是受到自回归解码的限制：模型需要一个token一个token地生成。以GLM-5.2为例，传统解码每次前向计算只能确定下一个token，长文本生成需要反复执行解码计算，GPU也容易受到串行生成的限制。

Alaya-DSpark是AlayaNeW面向GLM-5.2训练并开源的加速草稿模型，采用推测解码（Speculative Decoding）：先由轻量级草稿模型生成一组候选token，再由GLM-5.2并行验证，从而减少解码轮数。关键是，最终结果仍由GLM-5.2验证和决定。在满足严格校验条件的情况下，生成结果与原始模型保持一致。

简单来说：不是让模型少思考，而是让GLM-5.2一次多生成几个token。相关模型如下：

目前，AlayaNeW/GLM-5.2-DSpark已支持与 GLM-5.2/GLM-5.2-FP8配对使用，可直接部署于SGLang和vLLM。

一次生成多个候选，让大模型统一验收

如果把普通自回归解码理解成“逐字写作”，那么推测解码就是让一个轻量模型提前起草一小段，再让主模型一次性审核，整个过程可以简单理解为：

草稿模型先行：轻量模型提前生成后续几个候选token。
主模型并行验证：GLM-5.2一次检查整段候选序列，接受正确的前缀，并在出现错误的位置进行修正。
进入下一轮生成：已经验证通过的token成为下一轮解码的起点。

草稿模型预测得越准确，GLM-5.2每轮能够接受的token就越多，整体生成速度也就越快。反过来，如果草稿模型经常预测错误，主模型就需要频繁拒绝和修正候选token，推测解码的收益也会随之下降。因此，推测解码真正的关键并不只是“增加一个草稿模型”，而是：草稿模型是否足够了解主模型。

这也是Alaya-DSpark的核心设计目标——针对GLM-5.2专门训练一套配套的草稿模型。Alaya-DSpark基于DeepSeek提出的DSpark方法，整体流程可以概括为下面三个阶段。

DSpark 图 1 · DSpark加速生成流程示意图

并行起草：传统自回归解码需要逐token生成，而DSpark草稿模型会一次向前预测一小段候选序列。草稿阶段本身计算成本较低，因此可以快速生成多个候选token，为主模型后续验证提供输入。

连贯收口：在候选生成之后，通过额外的轻量处理减少候选之间的不一致，让多个预测token更容易形成连续、合理的文本。这样可以降低“前面预测正确、后面突然接不上”的情况，提高整段候选序列被主模型接受的概率。

按置信度进行验证：每个候选token都对应一定的预测置信度。对于置信度较低的尾部候选，不一定需要继续提交给主模型验证。系统可以根据当前负载动态决定本轮验证的长度：

负载较高时：减少低置信度候选的验证，避免浪费主模型计算资源。
负载较低时：可以扩大验证范围，进一步提高单轮接受长度。

最终，主模型仍然负责确认哪些token可以被接受。因此，对最终用户来说，最大的变化并不是模型能力发生了变化，而是：同样的GLM-5.2，同样的输出结果，token可以更快地生成出来。

模型设计：为GLM-5.2训练，而不是套用通用草稿

推测解码的效果高度依赖草稿模型与主模型之间的匹配程度。社区中已经存在面向GLM-5.2的DSpark草稿模型，但通用草稿方案在不同任务、不同语言和不同上下文长度下，接受长度可能存在明显差异。

Alaya-DSpark的训练目标不是构建一个“什么模型都能配”的通用草稿，而是让它尽可能贴合 GLM-5.2自身的生成分布和输出习惯。具体来说，我们主要从三个方面进行设计。

对齐主模型：训练数据中的回答由GLM-5.2生成或重写，使草稿模型学习的是：GLM-5.2接下来最可能如何生成。而不是学习其他模型的输出风格。
覆盖真实使用场景：训练数据覆盖代码、推理、中文对齐、长上下文等场景，而不是主要针对英文闲聊等单一任务进行优化。这使得草稿模型能够更好地适应实际推理服务中的多样化请求。
开箱即用：目前提供的权重可以用于SGLang和vLLM，并支持与FP8 / BF16的GLM-5.2配对使用。同时，Alaya-DSpark作为外挂草稿模型运行，不会修改GLM-5.2的模型权重。

这意味着主模型和草稿模型可以相对独立地迭代：主模型升级，可以重新匹配对应草稿；草稿模型可以独立优化；推理服务本身不需要改变原有OpenAI API协议。

模型训练：基于Alaya NeW智算引擎

为了优化训练参数、降低重复训练带来的成本，我们采用离线方式进行模型训练。

整体流程可以分为两个阶段：

首先生成模型训练所需的cache数据，并将其保存到Alaya NeW大容量存储中。
后续训练任务直接复用cache数据，进行不同配置下的训练和参数优化，最终得到适用于生产环境的模型。

这种方式可以避免在多轮实验中重复生成相同的数据处理结果，提高训练资源利用率。训练任务运行在 Alaya NeW弹性容器集群VKS 上。VKS负责多机多卡GPU资源的统一调度和运行环境管理；训练数据、缓存数据和模型检查点则由平台存储服务承载。

计算与存储相互解耦后，同一份缓存数据可以在多轮实验中重复使用，也方便对不同训练配置进行对比。对于多人、多任务并行的训练场景，平台还提供智能队列调度和资源配额管理：

训练任务可以自动排队，并按照优先级执行。
团队可以按照成员或业务线分配算力额度。
通过统一调度减少资源争抢和GPU闲置。

这套基础设施覆盖了Alaya-DSpark训练过程中的资源调度、缓存复用、数据存储和任务运行，为多轮训练与参数优化提供稳定的计算基础。

模型效果：任务覆盖更广，长上下文下更稳定

为了评估Alaya-DSpark的实际效果，我们在同一套评测环境中，将Alaya-DSpark与社区公开的 Red-DSpark 进行了对比。重点关注的指标是接受长度（Acceptance Length）：主模型每完成一轮验证，平均能够接受多少个token。

接受长度越高，意味着一次验证能够推进更长的输出序列，需要执行的解码轮数越少，因此通常能够获得更高的推理吞吐。接受长度对比

图2 · 接受长度对比。左图覆盖11类真实任务，右图覆盖1k到32k上下文长度。青色实线为Alaya-DSpark，橙色虚线为Red-DSpark。

从结果来看，有三个比较明显的特点。

11类任务中均保持优势：在代码、数学、推理、写作、问答、角色扮演、多语、RAG等11类任务中，Alaya-DSpark的接受长度均高于对比方案。中文、检索、摘要等实际线上场景，也是训练数据中重点覆盖的部分。其中，多语和RAG场景的差距尤其明显：
- 多语：Alaya-DSpark 4.43，Red-DSpark 2.63
- RAG：Alaya-DSpark 4.87，Red-DSpark 4.33
长上下文下保持稳定：在1k～32k上下文范围内，Alaya-DSpark的接受长度整体保持在 4.5～4.8 左右，随上下文长度增加没有出现明显下降。相比之下，Red-DSpark在短上下文下仍能保持一定效果，但随着上下文长度增加，接受长度明显下降：
- 1k、2k：接受长度仍可达到3以上
- 8k：下降至 1.95
- 32k：进一步下降至 1.16
加速来自更高的接受长度：推测解码并没有通过降低主模型的计算精度或改变回答能力来换取速度。主模型依然是GLM-5.2，负责对草稿进行验证。真正发生变化的是：一次验证能够接受更多token，因此完成同样长度的输出需要更少的解码轮数。在我们的测试中：
- 原生自回归解码：约 121 tok/s
- Alaya-DSpark：约 352 tok/s
- 整体吞吐提升：约 2.9×

换句话说，Alaya-DSpark的目标并不是让模型“少算一点”，而是让主模型每次计算推进得更远。

逐位置接受率：为什么Alaya-DSpark能保持更高的接受长度？

接受长度可以反映一轮最终“收下多少token”，但如果进一步观察每一个位置的接受率，就可以看到草稿模型预测质量的差异。

逐位置接受率对比

图3 · 逐位置接受率对比。左图为11类任务加权后的逐位置接受率；右图为1k / 8k / 32k上下文下的逐位置接受率。青色为Alaya-DSpark，橙色为Red-DSpark。

在11类任务的加权结果中，两条曲线从第一位开始就已经出现明显差异：

Alaya-DSpark第一位接受率：76.0%
Red-DSpark第一位接受率：68.2%

随着位置继续向后，Alaya-DSpark仍然保持更高的接受率。这意味着草稿模型不仅第一步预测更加准确，而且能够持续预测一段较长的候选序列。其中，多语任务的差异尤其明显：

Alaya-DSpark第一位接受率：82%
Red-DSpark：53%

这也是Alaya-DSpark在接受长度指标上取得更高结果的重要原因。上图中右边图表进一步展示了不同上下文长度下的逐位置接受率。在1k上下文下，两种方案都保持了一定的预测能力，Alaya-DSpark已经表现出更高的接受率。当上下文长度增加到 8k：

Red-DSpark第一位接受率下降到约51%，后续位置的接受率快速接近零；
Alaya-DSpark在1k /8k /32k三种上下文长度下的曲线基本保持一致，第一位接受率仍在83% 以上。

到了32k上下文，Red-DSpark第一位接受率进一步下降到约8%。对于长文档、长代码以及多轮会话，这意味着当上下文变长后，草稿模型仍然能够维持较高的预测准确性，而不是逐渐失去推测能力。

因此，从逐位置接受率和整体接受长度两个指标来看，Alaya-DSpark的优势并不集中在某一个单一任务，而是体现在：更广的任务覆盖、更稳定的长上下文表现，以及更高的逐位置接受率。对于生产环境中的GLM-5.2推理服务而言，这些因素最终都会影响实际吞吐。

Alaya-DSpark模型正式上线Hugging Face

使用最新支持DSpark的SGLang或vLLM，即可将Alaya-DSpark作为GLM-5.2的草稿模型进行推测解码。

SGLang

export SGLANG_ENABLE_SPEC_V2=1

sglang serve \
  --model-path zai-org/GLM-5.2-FP8 \
  --trust-remote-code \
  --tp-size 8 \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --speculative-algorithm DSPARK \
  --speculative-draft-model-path AlayaNeW/GLM-5.2-DSpark \
  --speculative-dspark-block-size 8

vLLM

vllm serve zai-org/GLM-5.2-FP8 \
  --trust-remote-code \
  --tensor-parallel-size 8 \
  --reasoning-parser glm45 \
  --tool-call-parser glm47 \
  --speculative-config '{
    "method": "dspark",
    "model": "AlayaNeW/GLM-5.2-DSpark",
    "num_speculative_tokens": 8,
    "draft_sample_method": "probabilistic"
  }'

推理接口仍然可以使用标准的OpenAI Chat Completions协议，应用侧无需因为启用DSpark而修改调用方式。变化发生在模型推理内部：还是GLM-5.2，只是更快地把结果生成出来。

提示

Alaya-DSpark是针对GLM-5.2专门训练的草稿模型。更换其他主模型后，需要重新训练与之匹配的草稿模型。

写在最后

大模型推理的下一阶段，不只是继续增加参数规模，也包括让现有的模型能力能够以更高效率服务真实业务。

Alaya-DSpark将DSpark推测解码方法应用到GLM-5.2，通过草稿模型提前预测、主模型批量验证和基于置信度的动态验证，在保持模型输出分布一致性的前提下，进一步降低自回归解码的串行开销。

最终目标很简单：让同一个GLM-5.2，在不改变模型能力和调用方式的情况下，更快地完成生成。模型已开源，欢迎在推理服务中直接使用，也欢迎基于自己的业务数据进一步探索和优化。

开源地址：AlayaNeW/GLM-5.2-DSpark

如需引用：

@misc{alayanew2026glm52dspark,
  title={GLM-5.2-DSpark},
  author={AlayaNeW},
  year={2026},
  howpublished={\url{https://huggingface.co/AlayaNeW/GLM-5.2-DSpark}}
}

目录