我在5090显卡上测试了DFlash2对Qwen3.8 27B模型的支持

Reddit r/LocalLLaMA 工具

摘要

用户在Qwen3.8 27B模型上测试了DFlash2,报告称代码生成时的推理速度有所提升,但与MTP相比内存使用量增加。

以下是DFlash2的公告,几天前在llama.cpp上尝试了DSpark后,我对此非常兴奋,但有些失望,因为它并没有真正工作。总之,我花了一些时间设置它(你需要用pr #27342重新构建llama.cpp)。以下是我的配置:-hf bartowski/Qwen3.8-27B-GGUF:Q5_K_L \ -hfd incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M \ --no-mmproj \ --spec-type draft-dflash \ --spec-draft-n-max 7 \ --host 0.0.0.0 \ --port 8080 \ --alias qwen3.8-27b \ -ngl 99 \ -fa on \ --ctx-size 160000 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --batch-size 2048 \ --ubatch-size 1024 \ -np 2 \ --kv-unified \ --no-context-shift \ --temp 0.8 \ --top-p 0.95 \ --top-k 20 \ --min-p 0.0 它似乎工作得相当好,在可预测生成(代码)时比MTP有稍大的速度提升。之前,我觉得在模型生成代码时,使用MTP平均大约能得到140tk/s,其他情况下约100tk/s。使用DFlash2,Qwen3.8 27B在长代码生成块的短时爆发中能达到约200tk/s,但在思考时似乎速度较低,约80-90tk/s。平均而言,一个完整的一次性代码生成请求似乎平均约120tk/s(禁用推理,因此生成95%为代码,基本上是最佳情况)。这是从MTP的良好改进,但我之前在Qwen3.6 27B上使用DFlash得到了更好的结果。DFlash2似乎相当消耗内存,我不得不将上下文从220k降低到160k(实际上可能能适应约180k),相比之下使用MTP。目前不幸的是,对我个人来说可能不值得使用。如果有人得到了更好的结果,我很乐意看到你们的配置!
查看原文

相似文章

z-lab/Qwen3.8-27B-DFlash2

Hugging Face Models Trending

介绍了 DFlash 2,一种用于与 Qwen3.8-27B 模型进行投机解码的块扩散草稿器,在基准测试中展示了改进的接受长度和吞吐量。

incoai/Qwen3.8-27B-DFlash2

Hugging Face Models Trending

DFlash 2 是一个用于投机解码的块扩散草稿模型,可提升 Qwen3.8-27B 语言模型的推理速度,在基准测试中提供更高的接受长度和吞吐量。