2026-07 小测一个适合24g单卡跑Hermes 的模型 Qwen3.6-35B-A3B-UD-IQ4_NL_XL （140t/s 170K上下文 tooleval 96分）
-
经过最近的研究和抄作业，终于找到一个适合长期给hermes使用的本地LLM(启动参数在文末） 。
它的编程能力肯定 是不行的(代码一定要交给27B,或者35B A3B Q8）， 但150秒完成测试，工具调用96分已经说明其实力。使用 spiritbuun/buun-llama-cpp的框架： 注意看它的官网说明：
不用说一眼直接上-ctk turbo8 -ctv turbo8，模型本身权重在4.5BPW左右，配上8.125BPW的K /V 缓存就挺舒服。
如果显存不足可以把-ctv 设置为Q4_0测试过程中我发现，这个框架的预填充速度比ikllama要快2-3倍。所以才能在150秒内完成测试。
网页编写俄罗斯方块游戏，40秒。
中国象棋，未测试。
昨晚让它帮我解决HP服务器的小问题，不知道跑了多久，已经120多K token了。速度降到80t/s 。
工具调用 ，真的和它自身的量化和“智商”很有关系。有些傻傻的模型就是有工具也不调，有网络也不知道去查。 在 HERMES里面放着SKILL也不用！
目前自动压缩了一次，速度恢复成100多t/s.另一个会话里面测试召回并压缩：
然后再用压缩的会话继续任务：
后台task数已到4万，依然很稳：
模型下载地址：
https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/blob/main/Qwen3.6-35B-A3B-UD-IQ4_NL_XL.gguf
19.5GB完美适配24G 3090显卡，XL能提供较高质量，IQ4_NL提供高速度。
不建议使用任何mtp模型，据说容易导致工具链断裂，那再快也没有意义了，要调用 hermes首要考虑的就是tooleval分数和chat template。 而且到了随着对话轮数的增加，KLD都不知道翻了多少倍了，模型也不知道你这轮想干嘛，很容易跑偏 。框架：
https://github.com/spiritbuun/buun-llama-cpp
建议让hermes阅读主页，按你本地的CPU和GPU来进行针对性编译获得最佳效果。聊天模板：
apex-qwen-chat-template.jinjakillall llama3-server 2>/dev/null; sleep 3 killall llama-server 2>/dev/null; sleep 3 /data/model3/llama-buun.cpp621/build/bin/llama-server \ -m /data/model3/Qwen3.6-35B-A3B-UD-IQ4_NL_XL.gguf \ --props \ -fa on --metrics --fit on -c 170000 \ -ctk turbo8 -ctv turbo8 --kv-unified -t 6 -tb 4 \ --jinja --no-mmap --mlock -np 1 -b 8192 -ub 2048 \ --chat-template-file /data/model2/qwen3.6-27b-gguf/apex-qwen-chat-template.jinja \ --host 0.0.0.0 --port 8025 \ --reasoning off \ --chat-template-kwargs '{"preserve_thinking":true}' \ --reasoning-format deepseek --reasoning-budget 300 \ --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.1 --frequency-penalty 0.11.显存大约稳定在23.1GB(我还有400多MB的固定开销）
2. 最后一行我一般不加载，就直接用前面3个经典参数，跑对话也没问题。 不必拘泥于模型卡的教条。
如果容易爆显存，把-b 8192 -ub 2048 依次除以2，很多地方都是用的-b 2048 -ub 512，如果越大，预填充会越快，但要适当考虑减小上下文长度。
它对tooleva的评测也有一定的的影响 4096/1024只有93分。
3.我的CPU是六核12线程，所以-t 6 ,个人 测试-tb 选择4 效果比较好。
这套配置，模型不会乱飙英文，虽然能看懂，但是有时候很烦模型动不动就飙英文。总之这个模型，用来本地跑简单任务（更难的任务用deepseek v4 pro，再难上思考模式)，
足够让单卡3090+hermes养老了，还要更好的效果就要加显卡或者换显卡了。神图：
-
经过最近的研究和抄作业，终于找到一个适合长期给hermes使用的本地LLM(启动参数在文末） 。
它的编程能力肯定 是不行的(代码一定要交给27B,或者35B A3B Q8）， 但150秒完成测试，工具调用96分已经说明其实力。使用 spiritbuun/buun-llama-cpp的框架： 注意看它的官网说明：
不用说一眼直接上-ctk turbo8 -ctv turbo8，模型本身权重在4.5BPW左右，配上8.125BPW的K /V 缓存就挺舒服。
如果显存不足可以把-ctv 设置为Q4_0测试过程中我发现，这个框架的预填充速度比ikllama要快2-3倍。所以才能在150秒内完成测试。
网页编写俄罗斯方块游戏，40秒。
中国象棋，未测试。
昨晚让它帮我解决HP服务器的小问题，不知道跑了多久，已经120多K token了。速度降到80t/s 。
工具调用 ，真的和它自身的量化和“智商”很有关系。有些傻傻的模型就是有工具也不调，有网络也不知道去查。 在 HERMES里面放着SKILL也不用！
目前自动压缩了一次，速度恢复成100多t/s.另一个会话里面测试召回并压缩：
然后再用压缩的会话继续任务：
后台task数已到4万，依然很稳：
模型下载地址：
https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/blob/main/Qwen3.6-35B-A3B-UD-IQ4_NL_XL.gguf
19.5GB完美适配24G 3090显卡，XL能提供较高质量，IQ4_NL提供高速度。
不建议使用任何mtp模型，据说容易导致工具链断裂，那再快也没有意义了，要调用 hermes首要考虑的就是tooleval分数和chat template。 而且到了随着对话轮数的增加，KLD都不知道翻了多少倍了，模型也不知道你这轮想干嘛，很容易跑偏 。框架：
https://github.com/spiritbuun/buun-llama-cpp
建议让hermes阅读主页，按你本地的CPU和GPU来进行针对性编译获得最佳效果。聊天模板：
apex-qwen-chat-template.jinjakillall llama3-server 2>/dev/null; sleep 3 killall llama-server 2>/dev/null; sleep 3 /data/model3/llama-buun.cpp621/build/bin/llama-server \ -m /data/model3/Qwen3.6-35B-A3B-UD-IQ4_NL_XL.gguf \ --props \ -fa on --metrics --fit on -c 170000 \ -ctk turbo8 -ctv turbo8 --kv-unified -t 6 -tb 4 \ --jinja --no-mmap --mlock -np 1 -b 8192 -ub 2048 \ --chat-template-file /data/model2/qwen3.6-27b-gguf/apex-qwen-chat-template.jinja \ --host 0.0.0.0 --port 8025 \ --reasoning off \ --chat-template-kwargs '{"preserve_thinking":true}' \ --reasoning-format deepseek --reasoning-budget 300 \ --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 --repeat-penalty 1.1 --frequency-penalty 0.11.显存大约稳定在23.1GB(我还有400多MB的固定开销）
2. 最后一行我一般不加载，就直接用前面3个经典参数，跑对话也没问题。 不必拘泥于模型卡的教条。
如果容易爆显存，把-b 8192 -ub 2048 依次除以2，很多地方都是用的-b 2048 -ub 512，如果越大，预填充会越快，但要适当考虑减小上下文长度。
它对tooleva的评测也有一定的的影响 4096/1024只有93分。
3.我的CPU是六核12线程，所以-t 6 ,个人 测试-tb 选择4 效果比较好。
这套配置，模型不会乱飙英文，虽然能看懂，但是有时候很烦模型动不动就飙英文。总之这个模型，用来本地跑简单任务（更难的任务用deepseek v4 pro，再难上思考模式)，
足够让单卡3090+hermes养老了，还要更好的效果就要加显卡或者换显卡了。神图：
-
@stxpnet
你这个图是自己实测的吗？好牛逼！
我的使用感受也差不多。27B 是非常扛量化的，但是到了 35B MOE 这里情况完全不一样了，低bit 的凉化几乎是没有办法用的，因为Toolcall蹦得非常厉害。和好多人说的 MOE 更抗量化的情况完全不一样。现在用 R9700跑 Q5 的版本，开双路256K，稳得一笔，配合好的 Agent 框架完全日用完全可以替代 V4 Flash 了。Zcode的harness很不错。 -
--reasoning off
请教下，启动参数中--reasoning off 配置为off后，后续的 --chat-template-kwargs '{"preserve_thinking":true}'
--reasoning-format deepseek --reasoning-budget 300 \ 参数还会生效吗？ -
@毅袁 关于你的问题，我来解答一下。
--reasoning off会完全禁用推理系统，此时：--reasoning-format deepseek— 被忽略，因为推理已关闭--reasoning-budget 300— 也被忽略--chat-template-kwargs '{"preserve_thinking":true}'— 这个只对启用了推理模式时生效，当 reasoning=off 时，chat template 中的 thinking 相关处理也被跳过
简单说：
--reasoning off优先级最高，它会覆盖所有其他推理相关参数。如果你想用 reasoning format 和 budget，就不要加--reasoning off。如果你只是想关闭模型的 thinking token 显示但保留推理计算，可以试试
--reasoning-format deepseek --reasoning-budget 300但不加--reasoning off。这样模型内部仍然会推理，但输出格式由 reasoning-format 控制。 -
，
T terry 固定了此主题
-
，系统 取消固定了此主题
-
补一下benchlocal-cli的得分，项目是在这里https://github.com/noonghunna/benchlocal-cli 克隆的，并且也要下载benchlocal官方的Verification Runtimes。拉镜像用的https://docker.m.daocloud.io .
剩下的问题都是3090中的这个iq4nl_xl模型驱动hermes 自行完成并跑起来的，我只做个监工角色。
Hermes agent的问题看起来这么多啊，周末等我有时间重新用tooleval 和 benchlocal再做一个更全面的评测。
-
再拉个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%。激活参数过小导致在处理长链条、复杂指令遵循时“脑力”不足，容易失败。
- 比分对比与汇总
