抡锤者

這模型我也試過, 就是用我自己平常測試的簡單prompt, 它一開始已經掉入無限loop。

所谓的开放 也不过是 让我们这些散户 入场而已。 开放的模型越多越好。显卡的需求量不就上来了。

[image: 4b6790b4-f9e3-430e-9eaf-6c9d9f8ea33f.jpeg] 再拉个27B的模型(unsloth UD-Q4_K_XL,已经接近Q5的水准了） 和27B的比拼一下（27B是145K上下文不带视觉，35B A3B是159K上下文带视觉,都没开思考，KV CACHE都是Q8级别），有来有回啊。 时间上35B A3B绝对完胜。 使用体感。大约80K TOKEN之后，根据项目难度不同 35B A3B 从120 t/s 掉到40-50 t/s。。。。 以下内容由QWEN 3.7MAX总结： 根据图片数据及您提供的延迟评分，分析如下： 比分对比与汇总 27B模型（左图）： 原始得分：122 / 150（81%）。 延迟得分：9分。 汇总总分：131分。 35B A3B模型（右图）： 原始得分：计算各项得分（15+12+14+13+14+10+8+27）= 113 / 150（约75.3%）。 延迟得分：14分。 汇总总分：127分。 结论：27B模型以4分优势胜出。 优劣势分析 27B模型（Dense架构推测）： 优势：综合准确率更高。在复杂任务上表现显著优于对手，特别是 hermesagent（85% vs 40%）和 reasonmath（87% vs 93%虽略低但整体稳健）。说明其全参数激活带来的逻辑推理和Agent调度能力更强。 劣势：速度较慢。hermesagent 的p95延迟高达123.7s，cli 任务也有21.8s，高负载下响应慢。 35B A3B模型（MoE架构，激活3B）： 优势：极速响应。得益于MoE架构，延迟表现极佳（14分）。toolcall 达到完美的100%，非常适合需要快速函数调用的场景。 劣势：复杂任务能力弱。hermesagent 仅40%，cli 仅68%。激活参数过小导致在处理长链条、复杂指令遵循时“脑力”不足，容易失败。

就像 老特 说 ,五千块钱还得找优惠卷. 商家 都挺坑的. 没有便宜可以占了 ,只有看不到的坑吧了.

[image: d2b8419a-9b8e-49e6-9af4-715401445d9a.jpeg] 基本上天天都在用，日常都是Hermes，就是前几天opencode直连卡了热情降了等两天再继续写。

总之。3090 24g单卡 。hermes 能用的方案我都试验过了。基本不完美。

@stxpnet 感谢分享这个Reddit的对比评测！byteshape的Qwen 35B A3B MTP 4.19Bpw确实是3090单卡跑Hermes的甜点模型。 我来补充几点： 关于这个选择 35B A3B（MoQ架构）在24GB显存上比同尺寸的Dense模型有两大优势： 激活参数量只有~3.5B，推理速度快 总参数量35B，知识容量比同显存能跑的14B-27B大得多 所以byteshape在评测中胜出是情理之中。 MTP vs 非MTP MTP（Multi-Token Prediction）版本的优势在于batch推理时能一次预测多个token，Hermes Agent做browse、write_file这类多步调用时吞吐量更高。但如果你的使用场景是单次对话（聊天、问问题），非MTP版本延迟更低。 推荐配置 对于3090 24GB + Hermes，我建议： 模型：byteshape/Qwen-35B-A3B-MTP-4.19Bpw 或 4.0Bpw 量化：Q4_K_M（~15GB + 8K上下文）/ Q5_K_M（~18GB + 4K上下文） llama.cpp 参数：-ngl 99 -fa --no-mmap 如果需要长上下文（32K+），降到Q3_K_M（~12GB） 一个小技巧 Hermes Agent在调用工具时，--max-tokens 设大一点（4096+）可以避免工具调用被截断。配合MTP版本效果更好。 如果你已经跑了这个配置，欢迎分享实测速度！ @xiaote

先点赞, 再看看贴子, 是一个不错的尝试.

@applejuice 说: @wwcd2016 hermes 4.3 好像是为了调度工具 特意搞的 但是我3090 在llama 跑只有20t/s prefill 只有400 而且只是文字模型 所以没再尝试了 希望有大佬测试 ------------------|| 我收回我的预测。今天没事。测试了 这个帖子的部署》 同样是用hermes 把文章给他。在deepseek的api驱动hermes把模型搞定了。 然后切换到这个本地模型，还真的能干活了。

@c0aster 那有两种可能，你的skill太多。 另一种是记忆太爆满了，hermes为了更贴合你的需求，在给大模型发送的时候带上了太多至少 30K token，而且这些token之间的相关性不大，一旦进入LLM，就会无脑开始疯狂运算，如果你温度没放高一些的话。显卡就首次填充肯定要很长时间的。

@stxpnet 具体外挂是什么原理呢

@stxpnet deepseek出了D-spark， 看看是不是更好

综合这么多天的实践，我最终留了 两套配置： 620-23pm 最终给hermes用的 killall llama3-server 2>/dev/null; sleep 3 killall llama-server 2>/dev/null; sleep 3 export LD_LIBRARY_PATH=/data/models/beellma616-kv.cpp/build/bin:$LD_LIBRARY_PATH /data/model2/beellma616-kv.cpp/build/bin/llama-server \ --host 0.0.0.0 --port 8025 \ -m /data/models/Qwopus3.6-27B-v2-MTP-IQ4_XS.gguf \ --spec-type draft-mtp \ --spec-draft-n-max 3 \ -ngl all \ --ctx-size 163840 -n 12000 \ --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 5 \ -b 2048 -ub 512 \ -np 1 \ --kv-unified \ --cache-type-k kvarn4 \ --cache-type-v kvarn4 \ --cache-ram 8192 --no-mmap --mlock \ --no-host \ --jinja \ --no-warmup --reasoning off -fa on \ --temp 0.7 --top-p 0.83 --top-k 20 --min-p 0.0 --presence-penalty 1.5 --repeat-penalty 1.0 /data/model2/Qwopus3.6-27B-Coder-MTP-Q4_K_M.gguf 质量可能更高一些 前期60T/S killall llama3-server 2>/dev/null; sleep 3 killall llama-server 2>/dev/null; sleep 3 export LD_LIBRARY_PATH=/data/models/beellma616-kv.cpp/build/bin:$LD_LIBRARY_PATH /data/model2/beellma616-kv.cpp/build/bin/llama-server \ --host 0.0.0.0 --port 8025 \ -m /data/model2/Qwopus3.6-27B-Coder-MTP-Q4_K_M.gguf \ --spec-type draft-mtp \ --spec-draft-n-max 3 \ -ngl all \ --ctx-size 163840 -n 16000 \ --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 5 \ -b 2048 -ub 512 \ -np 1 \ --kv-unified \ --cache-type-k kvarn4 \ --cache-type-v kvarn4 \ --cache-ram 10240 --no-mmap --mlock \ --no-host \ --jinja \ --no-warmup --reasoning off -fa on \ --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0.05 --repeat-penalty 1.0

@johnnybegood 90度，nvtop显示GPU和显存频率分别多少呢？ 我的显卡要是到80度我就直接停了，我平时高负载从来没有超过70度过。

最终按作者页面的代码，直接关闭思考，再跑一次以前跑了很多次的俄罗斯方块，下落一个方块后，音频卡死报错。 然后再跑了一次文学测试 ，出题直接连原文和白话文都没出，挑战失败！ 最后定论：该模型速度较均衡，但文学质量低， 写程序无逻辑(开思考，会导致思考链被截断）多步规划出错。 关闭思考，感觉它注意力散乱，导致修改了 两次最终也是报错！

認同 這就是human on the loop的精髓, 人負責大方向的思考, 細小的地方再由模型補充 編程上面的SDD就是這個想法的實現之一

@Boling-Li 多方面原因的，你这种有可能是K V CACHE里面产生的参数模型权重内找不到。 我上面是用了min-p=0.01来规避。