DeepSeek v4 Flash 对比 Qwen3.6-27B、Qwen3.5-122B 和 Gemma 4 31B 基准测试
摘要
用户在本地编码基准测试中对 DeepSeek v4 Flash 与 Qwen3.6-27B、Qwen3.5-122B 和 Gemma 4 31B 进行了对比,发现 Flash 总体胜出,但 Qwen 122B 表现惊人,首次尝试成功率更高且 token 消耗更低。
编辑:为了说明清楚,这个基准测试是为了评估可以在我的(以及这里许多其他人的)128GB 内存系统上运行的模型的能力。它并非旨在比较模型的绝对能力。请阅读设置部分了解具体细节——这是为那些想知道他们可以在本地运行的最聪明的模型是什么的人准备的——仍然是 DSv4 Flash,即使是量化版。请在发表评论前务必阅读设置部分和注释。有点震惊于在 LOCAL LLM 子版块中,对一个关于人们实际可以在本地运行什么的测试竟然会有如此多的敌意…… =/ 只是想分享我在本地(非 API)对 DSv4F 0731 在 High 和 Low 推理强度(不是 Max)下进行的 agentic 编码基准测试…… 我运行了 Aider Polyglot 的一个 109 题子集(包括 JS/C++/Python 语言),基于我最常做的编码任务。该基准测试在测试框架中衡量文件编辑和 diff 能力,并给模型两次尝试完成任务的机会——第一次是盲试,如果失败,它可以在看到第一次尝试的结果后再获得一次机会。我跟踪了首次尝试通过率、第二次尝试通过率、格式正确的 diff 数量、格式错误数量、上下文溢出次数(60k token 限制)和超时次数(1 小时限制,包括重试)[第一张图片]。我还跟踪了成本,基于秒/用例、提示词 token、完成 token、预填充和解码 token,以及千 token/解决每个问题 [第二张图片]。最后,我按语言细分了每个模型的成功率 [第三张图片]。总体而言,正如预期,Flash 在 High 模式下是总冠军。然而,它的领先优势并不大,而且为了达到这个成绩,它在 token 消耗上是最佳 122B 模型的 5 倍以上。此外,Qwen 模型在首次尝试中解决的问题数量远多于 DS4,这是一个令人惊讶的发现。总的来说,我对 122B 的表现感到震惊。我使用了出色的 ThinkingCap 微调的 27B 模型,因为我不想在基础 27B 完成基准测试之前就老死——在我为了选择日常使用的模型而进行的先前编码和知识基准测试中,27B 和 ThinkingCap 的表现总是在统计误差范围内,但 ThinkingCap 完成相同任务仅使用了总 token 数的 20-30%。如果你觉得 27B 过度思考的话,我强烈推荐你试试它。或者,如果你的硬件能装得下,就直接运行 122B——它在我的所有测试中都持续超出预期。设置:M5 Max 128GB DeepSeek v4 Flash:antirez 混合 Q4-Q2 imatrix,Dwarfstar 推理引擎。Qwen3.5-122B:Unsloth Q5_K_XL,llama.cpp [n=4] Qwen3.6-27B-ThinkingCap:Unsloth Q8_0,llama.cpp [n=4] Gemma4-31B-QAT:Unsloth Q4_K_XL(QAT 未压缩)[n=4] 注释:我在 DSv4 中同时运行了 High 和 Low 推理模式,因为我使用的 DSv4 推理引擎 Dwarfstar 当前版本在发送推理强度时有一个怪癖。基本上,DeepSeek 在 preview 和 0731 之间改变了推理强度的编码方式,因此在 preview 上触发 Max 强度的字符串现在在 0731 上触发 High 强度,一个新的字符串触发 Max,而如果不传递字符串,0731 不会默认 High,而是默认 Low 强度。目前在不修改代码的情况下无法在 Dwarfstar 中调用 Max 强度,而且在看到 Low/High 的 token 使用量后,我决定反正实际使用中也不太可能用 Max,所以我没有进行运行 Max 所需的修改。反正我已经在上面烧掉了好几天的 GPU 时间了…… Aider Polyglot 的 JS/C++/Python 集合有 109 个问题,而不是 107 个。然而,有 2 个问题在我发现之前多次触发了 linter 的一个 bug,导致生成失控,因为 linter 反馈了一个空的错误消息。特别是 DS4F 生成了 60k token 来寻找一个不存在的错误,这让我发现了这个问题,因为我原本以为运行卡住了。为了公平起见,我已将这 2 个问题从所有指标中排除。对于 llama.cpp 模型,我设置了 n=4(4 个同时运行的线程)。每秒 token 数(Tok/sec)是 4 个同时线程中某一个的数值,因此总速度需要乘以 4。这让我完成基准测试的速度大约快了 2.5 倍。Dwarfstar 不允许这样做,所以为了公平起见,我在相同的提示词/输出上分别测量了每个模型的聚合解码和单流解码速度,然后按比例缩放墙钟时间,以确保数字具有可比性。欢迎分享你做过的任何基准测试或对比!编辑:是的,0731(不是 preview)中确实有 Low 推理模式:https://www.reddit.com/r/LocalLLaMA/comments/1vdqsod/deepseekv4flash0731_when_low_is_higher_than_high/
相似文章
Qwen 3.8 27b 对比 Deepseek Flash
这篇文章对比了开源AI模型Qwen 3.8 (27B) 和 Deepseek Flash,讨论了基准测试,并寻求用户经验以评估它们的性能。
DeepSeek-v4-Flash-Mini 54GB GGUF 运行速度约 20.5 t/s
一个社区构建将 DeepSeek-V4-Flash 压缩为 54GB 的 IQ2_XXS GGUF 变体,采用激进的 2 位量化,在本地硬件上实现了约 20.5 tokens/s 的速度,同时大幅降低了显存/内存占用。
gemma-4-12b-it vs Qwen3.5-9B 在共同基准测试中的对比:Qwen 在 5/8 项基准测试中击败 gemma,虽体积更小但总体胜出
Qwen3.5-9B 在 8 项基准测试中的 5 项中优于 gemma-4-12b-it,尽管模型体积更小。gemma 仅在编程能力上略胜一筹。
Qwen 3.8 Flash Next、DeepSeek V4 与时间的权衡
一位使用 128GB Mac Studio M1 Ultra 的用户对比了本地运行 Qwen 3.8 Flash Next 和 DeepSeek V4 的体验,指出 Flash Next 基准测试分数更高,但完成每个任务所需的时间却长得多,并质疑质量与速度之间的实际权衡是否值得。
Qwen3.8:27B 对比 Flash Next。大家都知道跑分,但至少对我来说,现实完全是另一回事
一位开发者对比自托管的 Qwen3.8-27B-GGUF(Q4_K_XL,通过 llama.cpp)与云端的 Qwen3.8 Flash Next,认为尽管跑分更差,稠密的 27B 在代码质量上更好、需要的返工迭代更少、代码评审更简洁,且在其规格到 PR 的工作流中 token 消耗低得多。