腾讯开源的 DSpine 推测解码挺有意思，但什么时候能在 Mac 上支持 Qwen3.8-27B？

最近一直在研究 Apple Silicon 本地运行大模型的性能，发现腾讯开源了一个推测解码项目 DSpine。

GitHub： https://github.com/Tencent/DSpine

DSpine 的思路是通过多层并行预测、逐层传递前一位置的预测信息，提高草稿 Token 的接受率，从而减少大模型实际执行的解码轮次。

它不是新的大语言模型，而是一种推理加速方案。

一、Mac 上已经有比较明显的加速效果

腾讯官方提供了一组 Apple Silicon 测试：

硬件：M4 Pro 、64GB 内存、16 核 GPU

模型：Qwen3-8B BF16

在 T=0 的单流 MLX 测试中，平均解码速度：

推理方案
速度

普通 mlx-lm
15.37 tok/s

DFlash
29.81 tok/s

DSpine
38.52 tok/s

相对于普通 MLX ，DSpine 达到了约 2.5 倍的生成速度。

在另一个 SGLang-MLX 服务测试中，单并发、贪心解码下，DSpine 平均达到 60.46 tok/s ，对照基线为 14.77 tok/s ，约 4.09 倍。

这些数据来自不同测试配置，不能直接混为一谈，但至少证明 DSpine 在 Apple Silicon 上已经实现了有意义的加速。

二、Qwen3.8-27B 的数据更值得关注

腾讯还发布了针对 Qwen3.8-27B 的 DSpine 草稿模型。

在官方 SWE-bench Pro Agent 请求回放测试中：

模型：Qwen3.8-27B BF16

推理：SGLang + CUDA

并发：8

思考级别：xhigh

开启 Prefix Cache

测试结果：

方案
总吞吐量

普通自回归解码
248.17 tok/s

DFlash2
711.60 tok/s

DSpine
791.30 tok/s

DSpine 相比普通解码达到约 3.19 倍吞吐量，相比 DFlash2 也有约 11% 的优势。

注意：791 tok/s 是 CUDA 环境下 8 路并发 Agent 回放的总吞吐量，不是单用户速度，更不是 Mac 上的测试成绩。

三、真正的问题：Mac 目前还没有完整的 27B 方案

目前项目虽然已经提供 Apple Silicon 的 MLX 实现，但公开的 Mac 实现主要支持 Qwen3-8B 这类全注意力模型。

Qwen3.8-27B 的官方高性能实现依赖 SGLang CUDA 路线，包括 FlashAttention 3 、Triton 、ReplaySSM 等组件。

因此，目前不能直接把 27B 的 DSpine 草稿模型放进 MLX 或 oMLX ，就获得官方 CUDA 测试中的加速效果。

四、我自己的使用场景

目前设备：

MacBook Pro M5 Pro ，64GB 内存

Qwen3.8-27B ，Jundot oQ4e-mtp 量化版本

使用 ZCode 进行实际项目开发

需要至少 128K 上下文

任务涉及代码库分析、工具调用、多文件修改及 UI 实现

我测试过 oMLX 、Kapitsa 等推理引擎。

目前实际长上下文编程时，常见生成速度大约 27 tok/s ，Kapitsa 快的时候能达到 35 tok/s 。

模型的代码实现效果可以，但完整 Agent 任务仍然可能执行接近两个小时。

所以我现在更关心的不是 4K 短上下文跑分，而是 80K ～ 128K 上下文下，单用户持续编程任务的真实执行效率。

五、想讨论几个问题

腾讯 DSpine 是否有计划把 Qwen3.8-27B 完整适配到 Apple Silicon / MLX ？

27B 的混合架构、ReplaySSM 等部分，在 Metal / MLX 上移植的主要难点是什么？

现有 27B 4bit 量化模型，未来能否搭配 DSpine 草稿模型使用？

有没有开发者已经测试过 Mac M5 Pro / M5 Max 上的 DSpine 27B ？

最关心的一点：在 128K 长上下文、单并发编程 Agent 场景下，DSpine 还能保持多少实际加速收益？

个人感觉，Apple Silicon 本地推理现在已经可以运行不少质量很好的 27B 模型，代码能力也逐渐达到可用水平。

但长时间 Agent 任务的速度依然是一个明显瓶颈。

希望后续能有更多针对 Apple Silicon 、长上下文、真实 Agent 工作负载的优化，而不只是短提示词的 tokens/s 跑分。

发表回复