Speed Up LLM Inference with DSpark Speculative Decoding

通过 DSpark 推测解码加速 LLM 推理 - KDnuggets

publ: 2026年8月31日

• 博客热门文章

• 主题 AI 职业建议 计算机视觉 数据工程 数据科学 语言模型 机器学习 MLOps NLP 编程 Python SQL

• 数据集

• 活动

• 资源 快速参考指南 推荐 技术简报

• 广告

订阅时事通讯

#header end

/ad_wrapper

通过 DSpark 推测解码加速 LLM 推理

学习如何使用 DSpark 推测解码在相同 GPU 上提升本地 LLM 生成速度，结合 Qwen3-8B、llama.cpp 和 CUDA 进行演示。

作者：

Abid Ali Awan

，KDnuggets 副编辑，2026年8月31日发布于

语言模型

<div class="addthis_native_toolbox"></div>

有许多方法可以充分利用您已有的模型和 GPU 基础设施。量化、优化内核和更好的推理引擎都能有所帮助，但推测解码尤其有用，因为它可以在不简单增加更多 GPU 的情况下提高生成速度。

现在已有多种推测解码方法。传统方法使用较小的草稿模型，而多标记预测（MTP）一次性预测多个未来标记。Medusa 和 EAGLE 等方法改进了这些草稿的生成方式，而 DFlash 则并行生成候选标记块。

DSpark 采用不同方法，结合并行草稿生成与轻量级顺序组件。这使得后续草稿标记可以利用早期预测信息，同时保留大部分并行生成的速度优势。

在本指南中，我们将使用 Qwen3-8B 和 llama.cpp 测试 DSpark。我们将正常基准测试模型，启用匹配草稿模型的 DSpark，并比较生成速度，观察相同 GPU 能获得多少性能提升。

DSpark 的工作原理

DeepSeek 的 DSpark 改进了推测解码的草稿生成部分。

并行草稿模型可以一次性预测整个标记块，速度很快，但由于后续预测不完全依赖块中早期预测的标记，准确性可能下降。DSpark 结合并行主干与轻量级顺序组件，使后续草稿位置能够整合早期预测标记的信息，同时保留大部分并行生成的速度优势。

简而言之：

DSpark 还可以估计草稿标记通过验证的可能性，使低置信度块部分能够被丢弃，而不是浪费验证计算资源。llama.cpp 通过其 DSpark 实现和可选置信度阈值暴露了这一功能。

DeepSeek 报告称，当与 DeepSeek-V4 部署时，DSpark 相比之前的 MTP-1 生产基线将每用户生成速度提升了 60-85%。这些数字不应被视为我们小型本地模型的预期结果，因此我们将自行测量差异。

1. 构建 llama.cpp 并下载模型

我们将从源代码构建最新的 llama.cpp，以便使用其当前的 DSpark 实现和 CUDA 加速。

安装所需工具：

apt-get update
apt-get install -y git cmake build-essential

克隆官方 llama.cpp 仓库：

cd /workspace
git clone https://github.com/ggml-org/llama.cpp

启用 CUDA 支持进行构建：

cmake llama.cpp -B llama.cpp/build \
  -DBUILD_SHARED_LIBS=OFF \
  -DGGML_CUDA=ON

cmake --build llama.cpp/build \
  --config Release \
  -j \
  --clean-first \
  --target llama-cli llama-mtmd-cli llama-server llama-gguf-split

这将生成我们需要的二进制文件，同时允许模型在GPU上运行。

接下来，创建模型文件的目录：

mkdir -p /workspace/models

我们将使用Hugging Face CLI手动下载GGUF文件，以避免下载时间影响基准测试。

安装CLI：

pip install -U huggingface_hub

如果Hugging Face令牌存储在HF_TOKEN中，请使用以下命令进行身份验证：

hf auth login --token "$HF_TOKEN"

下载Qwen3-8B Q4_K_M目标模型：

hf download \
  Qwen/Qwen3-8B-GGUF \
  Qwen3-8B-Q4_K_M.gguf \
  --local-dir /workspace/models

然后下载匹配的DSpark Q8_0草稿模型：

hf download \
  ggml-org/Qwen3-8B-GGUF \
  dspark-Qwen3-8B-Q8_0.gguf \
  --local-dir /workspace/models

第一个文件是生成最终输出的主要模型。较小的DSpark模型将为目标模型生成推测性草稿标记以进行验证。

确认两个文件都已就绪：

ls -lh /workspace/models

你应该看到类似以下内容：

4.7G  Qwen3-8B-Q4_K_M.gguf
1.2G  dspark-Qwen3-8B-Q8_0.gguf

在完成llama.cpp构建并下载两个模型后，我们可以先测量启用推测性解码前的正常Qwen3-8B生成速度。

2. 测量基准速度

在启用DSpark之前，我们需要一个基准。我们将正常运行Qwen3-8B并记录其生成速度，以便与启用推测性解码的运行进行比较。

进入llama.cpp目录：

cd /workspace/llama.cpp

在不启用推测性解码的情况下运行Qwen3-8B：

./build/bin/llama-cli \
  -m /workspace/models/Qwen3-8B-Q4_K_M.gguf \
  -ngl all \
  -fa on \
  --temp 0 \
  --top-k 1 \
  -n 512 \
  -st \
  -p "Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think"

此处，-ngl all将所有模型层卸载到GPU，而-fa on启用Flash Attention。

我们还使用确定性解码：

--temp 0 --top-k 1

这很重要，因为在测试DSpark时，我们将使用相同的提示、令牌限制和解码设置，从而获得更清晰的直接对比。

生成完成后，查找llama.cpp打印的基准摘要：

[ Prompt: 294.6 t/s | Generation: 95.0 t/s ]

对于本指南，重要的是Generation: 95.0 tokens/s这个数值。我们将使用这个数值作为测量DSpark加速效果的基准。

3. 使用DSpark运行相同测试

现在我们将启用DSpark重复基准测试。目标是保持目标模型、提示、令牌限制和解码设置不变，以便直接测量推测性解码的效果。

运行相同的Qwen3-8B模型，这次附加DSpark草稿模型：

./build/bin/llama-cli \
  -m /workspace/models/Qwen3-8B-Q4_K_M.gguf \
  -md /workspace/models/dspark-Qwen3-8B-Q8_0.gguf \
  --spec-type draft-dspark \
  --spec-draft-n-max 3 \
  -ngl all \
  -ngld all \
  -fa on \
  --temp 0 \
  --top-k 1 \
  -n 512 \
  -st \
  -p "Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think"

在此，-md 加载了 DSpark 草稿模型，而 --spec-type draft-dspark 启用了 DSpark 推测解码。--spec-draft-n-max 3 允许 DSpark 每次最多生成三个 token，-ngld all 将草稿模型卸载到 GPU。

运行结束后，记录生成速度：

[ 提示：88.0 t/s | 生成：124.9 t/s ]

现在与我们的基线进行对比：

| 配置 | 提示速度 | 生成速度 | |------------------|------------|------------| | Qwen3-8B 基线 | 294.6 t/s | 95.0 t/s | | Qwen3-8B + DSpark | 88.0 t/s | 124.9 t/s |

DSpark 将生成吞吐量从 95.0 提升至 124.9 tokens/s。这相当于约 1.31 倍的加速，或使用相同的目标模型和 GPU 时生成速度提升了约 31.5%。

DSpark 运行的提示处理速度较低，但我们主要衡量的收益是自回归生成速度。对于生成更长响应的工作负载，更高的 token 生成吞吐量对整体推理时间的影响会更加显著。

最后思考

对于本地 LLM 加速，我认为 MTP 通常仍然是更实用的选择，尤其是因为它更简单且适用于更广泛的模型范围。然而，在草稿质量更优导致更多推测 token 被接受的情况下，DSpark 可能会优于基本的多 token 预测。

好消息是 DSpark 在 llama.cpp 中非常容易设置。更大的限制是模型支持：目前只有少量模型有兼容的 DSpark 草稿模型可用。

llama.cpp 中的 DSpark 支持仍相对较新，因此根据所使用的模型和构建版本，您可能会遇到 bug 或不稳定情况。目前，DSpark 是一种值得尝试的加速技术，但就本地推理的广泛实用性而言，MTP 仍是更优选项。

Abid Ali Awan（@1abidaliawan）是一名认证的数据科学家，热爱构建机器学习模型。目前，他专注于内容创作和撰写关于机器学习与数据科学技术的博客。Abid 持有技术管理硕士学位和电信工程学士学位。他的愿景是使用图神经网络为有心理困扰的学生构建 AI 产品。

更多相关内容

• 减少 LLM 工作流推理延迟的 7 种方法
• 生产环境中减少 LLM 延迟和推理成本的 12 种方式
• LLM 微调和推理的 5 个技巧与窍门
• 提高 LLM 效率的 3 个研究驱动型高级提示技术
• 实用约束解码的入门指南
• 解码智能代理 AI：自主系统的兴起

<hr class="grey-line"><br> <div><h3>我们推荐的 5 门免费课程</h3><br> </div>

Mailchimp for WordPress v4.14.0 - https://wordpress.org/plugins/mailchimp-for-wp/

/ Mailchimp for WordPress 插件

您可以从此处开始编辑。

如果评论已关闭。

<= 上一篇

#content 结束

<script type="text/javascript">kda_sid_write(kda_sid_n);</script>

最新文章

• 使用 DSpark 推测解码加速 LLM 推理 7 个 Python 新手常见错误（以及正确做法） 用于高效小型语言模型的本地 AI 堆栈 量化和剪枝方法让您的 LLM 更加轻量 从谷歌工程师的不可或缺提示中可以学到什么 人工智能对就业市场的影响

热门文章

• 用于高效小型语言模型的本地 AI 堆栈
• 如何利用本地小型语言模型为您的项目赋能

• 如何在人工智能领域打造职业道路：三种不同的路径

• 从AI编码代理中获得更好结果的10条规则

• AI代理如何改变行业的5个实际应用案例

• 构建端到端的数据科学作品集项目

• 2026年AI编码代理的十大开源基准

• 从谷歌工程师的不可或缺提示中可以学到什么

• 仅用3条命令即可在本地运行Qwen3.8-27B作为AI编码代理

• 超越模板的Python数据类

#content_wrapper end

© 2026

Guiding Tech Media

|

关于

联系我们

广告合作

隐私政策

服务条款

2026年8月31日由 blank 发布

No, thanks!

/.main_wrapper

<script defer type="text/javascript" src="https://s7.addthis.com/js/300/addthis_widget.js#pubid=gpsaddthis"></script>

noptimize

/noptimize