DeepSeek 刚开源 DSpark 五天，Red Hat 就把它装进了 GLM-5.2

DSpark 不是 DeepSeek 专属。Red Hat AI 的 vLLM 团队用五天时间，训练出了首个跑在非 DeepSeek 模型上的 DSpark 投机解码器，在 4×B300 上将 GLM-5.2 的解码速度提升了约 50%。

6 月 27 日，DeepSeek 开源 DSpark——一套将 V4 系列模型推理速度提升 57%–85% 的投机解码方案。当时行业讨论的焦点很明确：这套技术能不能脱离 DeepSeek 自己的推理栈，跑到别的模型上？

答案来得比任何人预想的都快。

7 月 2 日凌晨，Michael Goin——vLLM 核心维护者、Red Hat AI 推理性能工程师——在 X 上宣布：GLM-5.2 DSpark 预览版上线 HuggingFace。这是第一个跑在非 DeepSeek 前沿模型上的 DSpark speculator，用 vLLM nightly + Speculators 库训练，在 4×B300 GPU 上实现了约 1.5 倍的解码加速。

消息发出后，AI 研究社区最大的信号放大器 @_akhaliq（50 万粉丝）立即转发。紧接着，vLLM 项目官方账号、Teortaxes（6.8 万粉 DeepSeek 铁粉）、Prime Intellect 的 Matej Sirovatka 等社区重量级账号纷纷转发或引用。截至发稿，原推已获 158 次点赞、2.2 万次浏览、60 次书签。

1.5 倍加速：一个 3B 草稿模型，让 744B 的 GLM-5.2 快起来

成果本身可以拆成三个数字来理解。

接受长度 2.75。在 50k UltraChat 验证集上，这个只有 3 轮训练（3 epochs）的预览版草稿模型，平均每轮被目标模型接受 2.748 个 token。换算成加速比，就是在解码阶段每次前向传播多产出约 1.75 倍的 token——考虑到草稿模型自身的推理开销（约 3B 参数的前向计算），端到端加速约 1.5 倍。Goin 的原话是"~1.5× faster decode for GLM-5.2-FP8 on 4×B300"。

这个数字放在上下文中才能看出分量。DeepSeek 在 V4-Flash 上用 DSpark 取得了 57%–85% 的每用户加速，但那是在 DeepSeek 自有的推理栈上，草稿模型针对自家架构深度优化。Red Hat 的预览版只训练了 3 个 epoch、用了最小规模的 UltraChat 数据，就已经拿到 1.5 倍——意味着优化空间远未耗尽。

math_reasoning 上接受长度 3.13，HumanEval 上 2.33。用 HumanEval 和数学推理两个基准在 vLLM MRV2 投机解码框架中实测，greedy 模式下 HumanEval 平均接受 2.33 个 token（7 位草稿中接受 1.33 个），math_reasoning 则达到 3.13（接受 2.13 个草稿 token）。默认采样（temperature=1.0, top_p=0.95）下数字略低：HumanEval 2.20，math_reasoning 2.92。

数学和代码场景的接受率明显高于开放对话——这与 DeepSeek 原始论文的结论完全一致：结构化推理的 token 序列更可预测，草稿模型更容易猜中。这也意味着，GLM-5.2 最强的编程和长程任务场景，恰好是 DSpark 收益最大的场景。

尾部位接受率不打折。 DSpark 最大的设计卖点是解决"后缀衰减"（suffix decay）——传统并行草稿模型（如 DFlash）一次性并行生成整块 token，每个位置独立采样，导致越靠后的 token 越容易漂移，被验证器拒绝。DSpark 在并行骨干上加了一个轻量的 Markov 序列头（rank-256 低秩分解），让每个 token 可以瞥一眼前一个 token 的选择，用几乎为零的额外开销扼制了衰减。

在这个预览版上，效果立竿见影：第 1 位接受率 71.1%，第 7 位仍保持 32.0%。作为参考，同等条件下纯并行方案 DFlash 的尾位接受率通常会跌到 20% 以下，而 Eagle 3（纯自回归方案）虽然衰减平缓但起步接受率更低。DSpark 做到了"两头占"——头位准确率高（并行骨干深度大），尾位衰减慢（Markov 头修正）。Red Hat 团队在模型卡中特意标注："后半段准确率保持良好（Markov 头对抗后缀衰减的功劳）。"

Goin 本人也坦承这个版本"训练不充分"（undertrained preview），更强的 checkpoint 正在训练中。但即便是一个 3 epoch、50k 样本的预览版，其核心指标已经验证了技术路线的可行性——DSpark 可以脱离 DeepSeek 的模型和推理栈独立工作。

3B 参数量，8 张 B300，50k 条 UltraChat：一个周末能跑出来的预览版

这个 speculator 的训练管线本身也值得拆开看。

在线训练架构。与传统"先抽 hidden state 存盘再离线训练"的流水线不同，Red Hat 采用了 Speculators 库的在线训练模式：一台 vLLM 服务器以 TP4 运行 GLM-5.2-FP8，实时流式输出 hidden states；训练器在剩余 GPU 上以数据并行方式消费这些状态。整个过程在单节点 8×B300 上完成，由 Verda Cloud 提供算力支持。

轻量草稿模型。草稿模型只有约 3B 参数——5 层草稿层（draft layers），block_size=8，词表 32000，辅助层取自目标模型的第 8、23、39、55、70 层。这比 DeepSeek 为 V4 训练的 DSpark 草稿头更大，但考虑到 GLM-5.2 是 744B 的 MoE 架构（39B 激活参数），这个尺寸基本合理。

训练配方。数据用了 GLM-5.2-FP8 自己重新生成的 50k UltraChat 提示-回答对，seq_len=4096。损失函数混合了交叉熵（权重 0.1）、总变分损失（权重 0.9）和置信度头的 BCE。学习率 6e-4，余弦调度，SiLU 激活。3 个 epoch。

配方的关键细节是 max_anchors=1024——这是 DFlash 训练中的锚点数量，决定了草稿模型能从目标模型的多少层提取辅助 hidden states。更大的锚点数通常意味着更丰富的特征，但也意味着更大的显存和通信开销。

Matej Sirovatka（Prime Intellect）在引用推文中写道："真没想到 DSpark + GLM-5.2 能在论文发布后这么快就跑起来，昨天不到一天就搞定了。"这句话概括了整个项目的社区意义：DSpark 论文 6 月 27 日发表，vLLM 7 月 1 日合并 DSpark 支持（PR #47093），Red Hat 7 月 2 日发布模型——整个链条不到一周。

五天、两个 PR、一个预览版：DSpark 从 DeepSeek 专属到通用技术的速度

从更广的视角看，这件事的意义超出了 GLM-5.2 这一款模型。

DSpark 的可迁移性被验证了。 DeepSeek 原始论文提到 DSpark 也适用于 Qwen 和 Gemma，并发布了 Qwen3-4B 的草稿模型 checkpoint。但 GLM-5.2 是完全不同的模型架构——MoE + DSA（Dynamic Sparse Attention）+ MTP（Multi-Token Prediction）多头——且在 DeepSeek 论文中并未被测试。Red Hat 用实际训练结果证明，DSpark 的并行骨干 + Markov 序列头 + 置信度调度三重设计确实可以跨模型家族迁移。

vLLM 生态补齐了关键一环。就在 Goin 发推的几个小时前，vLLM 官方账号宣布 DSpark 投机解码已原生支持 vLLM。这意味着训练出来的 speculator 可以直接用 vllm serve 部署——不需要自己改推理引擎，不需要等定制 kernel。官方公告中特别提到 DSpark 在 vLLM 中"复用了现有的 SparseMLA 后端而非定制 attention kernel，将整个草稿骨干和采样循环捕获进单个 CUDA graph，并与 prefix caching 和 FP8 KV cache 兼容"。这套工程方案让社区开发者可以"训练即部署"。

中国最强开源模型有了社区驱动的加速方案。 GLM-5.2 发布于 6 月 13 日，是 Z.ai（智谱 AI）当前的旗舰模型——744B MoE，39B 激活参数，1M 上下文，MIT 开源协议。在 Terminal-Bench 2.1（81.0）、SWE-bench Pro（62.1）、FrontierSWE（74.4）等核心编程基准上，它是排名最高的开源模型，综合能力仅次于 Claude Opus 4.8。GLM-5.2 自身已内置改进版 MTP 投机解码（接受长度提升 20%），但 DSpark 的加入为社区提供了另一条加速路径。

Simon Mo（vLLM 团队、Inferact 创始人）的评论戳中了关键："DSpark 已合并。几天之内，vLLM 的社区努力就推动了低延迟高交互推理的前沿。自己在家训练，1000 tok/s。"

从 MTP 到 DSpark 再到 TwoTower：GLM-5.2 的推理加速版图

把这件事放进更大的推理加速竞赛中看，GLM-5.2 现在同时拥有两条投机解码路径，而整个行业正在多条技术路线上同步推进。

内置 MTP：出厂自带，零成本。 GLM-5.2 原生支持 Multi-Token Prediction 投机解码——模型在训练时就学习同时预测后续多个 token。Z.ai 团队在 GLM-5.2 架构中引入了两项关键改进：IndexShare（每 4 个 transformer 层共享 indexer，将 1M 上下文下的每 token FLOPs 降低 2.9 倍）和 KVShare（在 MTP 层间复用 KV cache，消除训练-推理不一致）。配合 rejection sampling 和端到端 TV loss 训练，MTP 接受长度从 4.56 提升至 5.47（+20%）。这是模型出厂自带的加速方案——部署即用，不需要额外训练任何组件。

社区 DSpark：外挂加速器，空间更大。 Red Hat 训练的外部 speculator 走另一条路——并行骨干 + 序列修正头 + 置信度调度。与 MTP 相比，DSpark 的核心差异不在草稿质量而在架构灵活性：MTP 的草稿头与目标模型共享参数、训练阶段就已固化，而 DSpark 的草稿模型是完全独立训练的，可以针对特定场景（如代码补全、长文档问答）精调，也可以在更好的训练数据和更长训练周期下持续提升。此外，DSpark 的置信度调度器可以根据服务器负载动态调整验证深度——这是 MTP 不具备的能力。

两条路线并不互斥。对于自建推理服务的团队，最务实的策略可能是：先上 MTP 拿到 20% 的免费加速，再评估业务负载特征——如果是代码生成、数学推理等高结构化场景，且对延迟敏感，则值得投入 GPU 时间训练 DSpark speculator。Red Hat 的预览版相当于提供了一份"可行性证明"和训练配方。

同一赛道的其他玩家。 7 月 1 日，NVIDIA AI 发布了 Nemotron-Labs-TwoTower——一种将 30B 模型拆成两半并行写 token 的扩散语言模型方案，在保持 98.7% 质量的前提下实现 2.42 倍加速。这是一种与投机解码完全不同的技术路线：不依赖草稿模型，而是通过架构改造让模型自身并行生成。同一天，vLLM v0.24.0 发布，带来 DeepSeek-V4 的 FlashInfer 稀疏索引缓存、prefill chunk-planning 等多项推理优化。两条消息与 DSpark 合并叠加，让 7 月初成为 LLM 推理加速史上密度最高的几天。

竞争格局已经清晰：DeepSeek 用 DSpark 把自家模型的推理成本压到极致，vLLM 社区把 DSpark 变成通用基础设施，Red Hat 证明了它可以跑在非 DeepSeek 的前沿模型上。下一步要看的是 Anthropic、Google、OpenAI 等闭源厂商是否会在自己的推理栈中采用类似方案——如果他们跟进，DSpark 级投机解码将成为行业标配。

DSpark 的生态扩张，比论文预想的更快

这个预览版的发布，验证了一个比加速数字更重要的判断：DSpark 正在从 DeepSeek 的内部优化工具，变成开源推理生态的公共基础设施。

DeepSeek 开源 DSpark 时做了两件关键的事：论文附带了 Qwen3 和 Gemma 的草稿模型 checkpoint，训练代码以 MIT 协议发布。但真正让 DSpark"出圈"的是 vLLM 社区的快速跟进——从论文发表到原生支持合并，只用了三天（PR #47093 在 6 月 30 日提交，7 月 1 日合并）。Red Hat 的 GLM-5.2 speculator 则证明，有训练工具（Speculators 库）和推理引擎（vLLM nightly）两样东西，社区开发者自己就能为任何模型训练 DSpark 草稿头。

Michael Goin 说得好："这是第一个非 DeepSeek 前沿模型的 DSpark speculator。更强的 checkpoint 还在后面。"——如果这句话兑现，DSpark 可能成为下一代推理加速的标准配置，就像 Flash Attention 曾经做到的那样。

参考链接：

（本文由 AREX Agent 基于公开信息自动生成，如有事实出入请以一手来源为准。）_