独立开发者将腾讯 DSpine 推测解码移植进 llama.cpp 并发布 GGUF 权重：单卡 RTX 3090 自测 94～132 tok/s

11 月 8 日，独立开发者 AJ（X 账号 @ItsmeAjayKV）发帖宣布，他已把腾讯为 Qwen3.8-27B 发布的 DSpine 草稿推测解码（speculative decoding）移植进 llama.cpp，并发布了配套 GGUF 草稿权重。他给出的自测结果：单张 RTX 3090、Q4_K_M 量化的目标模型下，不加推测解码为 28.2 tok/s，换用此前的 DFlash2 草稿器后为 50.6 tok/s，换上 DSpine 后达到 94～132 tok/s——按他的说法，对 DFlash2 领先约 1.75 倍，数学和代码任务上每个验证步能接受的 token 从 5.7～5.8 个提到 7.3～7.6 个（AJ 的帖子）。

两个公开产物都真实存在：GitHub fork Ajay9o9/llama.cpp 的 dspine 分支，以及 HuggingFace 仓库 aj9o9/Qwen3.8-27B-DSpine-b16-GGUF（含 Q4_K_M、Q8_0、BF16 三种量化）（GGUF 仓库、fork 的 dspine 分支）。官方一侧同样有可核验的产物——11 月 7 日，tencent 组织在 HuggingFace 上发布了 DSpine 的 Qwen3.8-27B 草稿权重（官方模型卡），方法论文出自腾讯优图实验室与上海交通大学等机构的研究者（论文页）。官方模型卡给出的推理命令基于 SGLang；AJ 的移植版模型卡则写明，上游 llama.cpp 尚不支持 DSpine。截至本文核实（11 月 9 日），@TencentHunyuan 的 X 账号也未见 DSpine 发布公告，其近期帖文集中在 11 月 4 日发布的 Hy4 模型及后续评测转发（@TencentHunyuan 账号页）。AJ 的全部性能数字为个人一手自测，尚无系统性的独立复现。

官方模型卡上线约 24 小时后，GGUF 仓库跟着出现

这条时间线上的每个节点都带有可核验的发布时间。9 月 28 日，论文《Draft in Parallel, Condition Through Depth: Adjacent Causal Injection for Speculative Decoding》上 arXiv（论文页）；10 月，DSpine 团队按项目页 News 的记载陆续放出训练代码、Qwen3-8B 草稿权重和推理代码（DSpine 项目页、Tencent/DSpine 仓库）；11 月 7 日 14:20（UTC），官方模型卡 tencent/Qwen3.8-27B-DSpine-b16 上线，是面向 Qwen3.8-27B 的 2.03B 参数五层草稿模型，块大小 16，带 8,192 token 滑动窗口（官方模型卡）；11 月 8 日 14:07，AJ 的 GGUF 仓库创建，37 分钟后他发出移植帖。

AJ 在推文里把这件事归于 @TencentHunyuan，但可查的发布产物挂在腾讯 HuggingFace 组织与 Tencent/DSpine 仓库下，论文和项目页署名的研究者来自腾讯优图实验室（YouTu Lab）、上海交通大学和厦门大学（项目页）。官方 X 账号这边，11 月 4 日发布带视觉能力的 Hy4 模型（Hy4 发布帖），之后是数条评测转发，最近一条停在 11 月 6 日，没有 DSpine 相关内容。

DSpine 是什么：把「前驱预测」铺进整条网络深度

并行草稿器一遍前向就能同时预测一整块 token，但块内各位置在前向时并不知道前驱最终会选什么，预测链因此容易断。DSpine 的做法是让因果条件贯穿整条主干：草稿器每一层之后，相邻后继位置都会收到一个由前驱预测特征构成、经门控写入的消息，让「前驱是谁」沿网络深度一路传下去，而所有位置仍在一次前向里并行完成（项目页）。等前驱 token 真正解码出来，再把它的嵌入写回并重做最后一次写入；一个转移缓存（transition cache）把每个位置 16×16 的候选前后对分数一次并行算完，选链变成查表。AJ 在模型卡里把 DSpine 相对 DFlash 的三处新增概括为块内因果注意力、每层之后的桥接（code bridge）与串行末次写回（GGUF 仓库）。

官方在 SGLang 0.5.22、并发 8 的服务环境下评测：温度 0 时，GSM8K 的平均接受长度（acceptance length）从官方 DFlash2（块大小 8）的 5.69 提到 7.20，MATH-500 从 5.49 提到 6.49；agent（智能体）任务吞吐相对自回归解码最高到 3.84 倍（WorkBuddy Office）（官方模型卡）。论文口径是 Qwen3-8B 上七项数学、代码与聊天基准的平均接受长度从 DFlash 的 3.77 提到 4.82，SGLang 服务吞吐平均比 DFlash 高 23.3%、比 DFlash2 高 11.1%（论文页、项目页）。

单张 3090 的实测：代码 128.7 tok/s，散文只有 41.6

AJ 的测试环境在模型卡里写得很具体：RTX 3090 24 GB 全部层放进显存、Ryzen 9 9900X、Q4_K_M 目标模型（17.1 GB）、目标与草稿器都用 q8_0 KV 缓存、单并发，测速用 llama-benchy（GGUF 仓库）。推文里的 94～132 tok/s 是他发帖时的口径；发帖约半小时后他在回复里补充，这些数字全部来自自己的 RTX 3090，「忘了在主帖更新」，上下文深度与显存占用「都在测，马上发」（其回复一、其回复二）。

模型卡现在的摘要口径是：代码与数学约 125 tok/s、混合聊天任务约 90 tok/s，对比 DFlash2 约 52 tok/s、无推测解码约 28 tok/s，整体 3.2 倍、代码任务最高 4.5 倍，与推文区间接近（GGUF 仓库）。分任务表显示增益并不均匀，温度 0、10 个混合提示（数学、写作、摘要/翻译，以及 Python、C++、JavaScript、SQL 代码）下的结果：

全任务平均：温度 0 时 DSpine 90.1 tok/s（基线 28.2 的 3.19 倍），温度 1 时 80.4 tok/s；DFlash2 分别为 51.7 和 50.6（GGUF 仓库）。提速的直接来源就是「每验证步接受」一列：对照 AJ 在推文里给出的 DFlash2 自测值，DSpine 在数学和代码上每步多接受约三成（AJ 的帖子）。模型卡同时注明，在小说续写、代码讲解这类语料上，草稿器平均每步只能接受约 2.5～3.5 个 token，散文任务的增益明显缩水。

上下文是代价：16 token 草稿块多占约 1.2 GB 显存

DSpine 不是白拿的速度。AJ 的模型卡给出 24 GB 卡上的最大可加载上下文对照：不加推测解码 176,128，DFlash2（7 token 草稿）102,400，DSpine（15 token 草稿）只有 65,536（GGUF 仓库）。瓶颈在目标模型：Qwen3.8 是带循环层的混合架构，验证草稿时要为每个草稿 token 保留一份循环状态副本，每份约 150 MB；16 token 的 DSpine 块因此比 8 token 的 DFlash2 块多占约 1.2 GB，直接从上下文预算里扣除。预填充（prefill）速度也略降：8,192 上下文时从 1,115 tok/s 降到 969 tok/s。不过模型卡的结论是，在它装得下的每个上下文深度上，DSpine 仍是三者中最快的。

移植版还有两个使用门槛。其一，--spec-draft-n-max 15 必须手动指定，默认值 3 只用到 16 token 块的一小部分，模型卡写明会损失大部分加速；其二，上游 llama.cpp 不支持这些文件，官方版本会直接拒绝加载而不是错误运行，想跑只能克隆 AJ 的 dspine 分支自行编译（GGUF 仓库、dspine 分支）。

官方账号未见公告，评论区先给出数据点与失败报告

这条推文截至本文核实时有 523 个赞、约 3.1 万次浏览、534 次收藏和 40 条回复（AJ 的帖子）。评论区很快出现第三方数据点：用户 KitikKote54227 在双 3060 Ti（各 8 GB）上跑 IQ3_S 量化，报出 50 tok/s（该回复）；X 用户 ARahim 提醒「在 Mac 上 DFlash2 仍然更快」（该回复）；用户 Kdrple 重新编译移植版后在 AMD ROCm 上「目前没有拿到加速」，并说明只是给想试的 Radeon 用户参考（该回复）。用户 sepo100 先询问平台支持、得到「llama.cpp 能跑的地方都能跑」的答复，几小时后回报：在他机器上「比 DFlash2 慢得多」，同时说明自己试的是 Qwopus v2 这一社区版本、而非原版权重（该回复）。

口径质疑也出现了。用户 Eliovp 提醒，最大的提速是对比完全不用推测解码的基线；对 DFlash2，官方卡上的 agent 吞吐增益只有约 8%～21%（按官方模型卡的加速倍数换算），他还说自己在 3-bit 量化的 Qwen3.8-27B 上观察到「普通提示没有每步增益，agent 文本有」（该回复）。用户 guannanjiayou 点出另一层差别：官方数字跑在 SGLang 并发 8 下，「这里大多数人要的是 batch 1 的 3090 数字」（该回复）。正面的声音同样直接：用户 dad__vibes 写道，「同一天把 DSpine 移植进 llama.cpp 并发出 GGUF，对在家跑 Qwen3.8-27B 的人来说是个大利好」（该回复）。

对在家跑 27B 模型的 llama.cpp 用户，当下多了一条不依赖 SGLang 的路径：克隆一个 fork 就能试。能不能离开这个 fork，取决于上游 llama.cpp 是否合并 DSpine 支持——评论区已经有人问起，挡在上游合并前的是自定义算子还是 GGUF 格式（该回复）；AJ 自己给出的下一步是「我在做一个完整的拆解」（其回复）。

参考链接

• AJ（@ItsmeAjayKV）的移植发布帖
• aj9o9/Qwen3.8-27B-DSpine-b16-GGUF（AJ 的 GGUF 仓库与模型卡）
• Ajay9o9/llama.cpp 的 dspine 分支
• tencent/Qwen3.8-27B-DSpine-b16（官方模型卡）
• DSpine 项目页
• 论文：Draft in Parallel, Condition Through Depth（arXiv:2609.36173）
• Tencent/DSpine 推理代码仓库
• @TencentHunyuan 账号页
• @TencentHunyuan 的 Hy4 发布帖
• AJ：数字来自 RTX 3090 的说明回复
• AJ：上下文与显存测试进行中的回复
• AJ：「在做完整拆解」的回复
• KitikKote54227：双 3060 Ti 数据点
• ARahim：Mac 上 DFlash2 更快的提醒
• Kdrple：AMD ROCm 无加速的反馈
• sepo100：Qwopus v2 上失败的回报
• Eliovp：口径质疑
• guannanjiayou：并发环境差别的提醒
• dad__vibes：正面评价
• lotar_vk：上游合并障碍的提问