【实测】7900xtx使用Qwen3.6-35B-A3B速度稳定在80+t/s
-
这个模型跑的很快，用m5max 6bit 能跑将近100toks，但是用hermes调用时候经常会死循环，一直重复几句话，干不了大活
@stormaround
我也发现这个问题了，试了不下10个这个基座模型的变种，有的量化精度低一些的在Hermes调用几步以后就开始陷入死循环，良化进度高一点的（新入了r9700）会好一些，但是他的思维会陷入一个死循环，就是不断的尝试，但是每一轮尝试下来都是一样的结果，根本解决不了问题。
后来我把跟他的交互记录让deepseek Pro看了一下，Deepseek 2分钟就发现了问题，根本的原因是Hermes斯的对话管理机制，因为它的定位是做一个轻量的助手，所以他的对话几乎都不能持久，然后你过一会不用的话，那个对话就给你关掉了，你在聊天的时候又是一个新的对话，所以说它不是靠对话来管理上下文的，它实际上是靠搜索它的那个对话的数据库来搞的，这样的话，尤其像这种本地小模型智商没那么高的情况下，他有可能抓到的内容是碎片化不相关的。所以导致使用体验非常糟糕，然后我就把同样的咖啡UI的自动化视频流程让他总结了一遍，迁移到了opencode里面。中间有一个断点在opencode里面调用一个魔改版的这个35b一次跑通！因为open code的一个对话就是一个项目，这种开发类的agent框架的上下文比较干净。
工具和模型同样重要，多么痛的领悟，我已经卡了三四天了了。 -
这个模型跑的很快，用m5max 6bit 能跑将近100toks，但是用hermes调用时候经常会死循环，一直重复几句话，干不了大活
-
@stormaround 同感，我用35B-A3A写一个代码项目，他干了5个小时，修了上百行代码。 claude code评价：5个小时干的活没有正向做功，因为没有找到根本问题，在现象层面修了东边，坏了西边，反过来修西边，又坏了东边。直到手动停止它
-
不信的只有自己实践了才能信，35B,A3B，大概就是6B的速度，质量嘛，大概15B。 其实有个简单的判断方法，你给它配好harnness工具，然后让它写一些复杂点的小游戏。然后观察nvtop曲线。 就算你调好参数，让它能满载跑，它写程序也是写100行，过一会儿删80行， 电力和时间就这样被浪费了。 它只适合做一些简单的任务编排，但是这样的任务,deepseek flash就能做了，也便宜。
这个模型唯一优点的就是刚开始像打了鸡血一样快。140T/S，中后期会掉到80，比较难受。 （我一直用0.6温度， 不然后期智力下降厉害） 。 -
纯粹为了本地部署，搞两张4090也太浪费了，毕竟本地模型的上限就在那儿了，不值得投入太多，Deepseek v4 flash让好多时候本地部署显得有点儿多余。
如果忍得了27b的便秘感，那24g以下的卡都推荐这个，但是如果忍不了的话，即便是优化了缓存以后，建议跑Ornith 35B Q5/Q6, 这个魔改微调的版本确实有点儿东西。
至少在我r9700上实现了我绝大部分的应用，当然配合deepseek V4 Pro或者glm5.2做规划就更好了，搜索类任务的话要配一个搜索引擎。如图这个Ornith特训版本，不管是在Hermes还是open code里面工具调用都不会断链，稳得一笔。我自己homelab里面装了有将近20个docker服务，之前用Ornith做了一个大体检，修复了好多不完善的地方，这个还只是用deepseek flash做的规划，它来执行的。最后用Pro做了质检，得分88%。其实应该是在九十以上的，Pro把它没有成功调用子agent归咎于他，但事实上是我配置的问题，给子Agent之前配置的27b模型不存在了。
就这种级别的表现，我敢说对于大多数人来说根本不存在所谓不够的问题，除非你用的是原版35b（断链，死循环，种种问题）。日志里面抓出来的PP峰值在2700左右，TP56左右，就这实测还是比deepseek v4 flash满一倍，但就执行来说，质量没什么区别了。
非软件工程师也不搞开发，那个是我没有涉及到的领域，有牛人在此种场景下用过的话，还请分享一下。
-
这两个问题都可以泛化成通用做法，我按可验证的顺序说：
- Ornith 35B Q5/Q6 驱动 Hermes 思考无限循环
这类小激活 MoE（A3B 只有约 3B 激活参数）出循环，按概率从高到低排查：
- 采样参数：Hermes 默认温度 0.7-0.8 对小激活 MoE 偏高，思考阶段很容易绕圈出不来。先降到 0.1-0.3，或加 repetition_penalty 1.05-1.15。这一步能解决大多数"思考死循环"。
- 上下文/KV 溢出：35B A3B 激活参数小，但 KV cache 不小。上下文设太长导致溢出截断后，模型会"忘掉"前面几轮，然后原地打转。先缩到 8K-16K 试一轮。
- 量化与版本：Q5/Q6 本身不算低（Q4_K_M 是甜点位），但你如果跑的是原版 35B 而不是特训版 Ornith，断链和死循环概率会明显高一截——fcme 前面也验证过，特训版在 Hermes 里工具调用基本不断链。
- MTP/投机解码：开了 speculative decoding 且 draft 模型不匹配时，会产出异常输出。关掉 MTP 再测，排除这个变量。
- deepseek v4 规划 + 35B 执行
fcme 楼上的描述就是标准做法：规划用 deepseek（逻辑强又便宜），执行交给本地 35B，最后再用 Pro 做一轮质检。Hermes 里落地两条路：
- subagent：把执行类子任务拆给子代理跑 35B，主对话保持 deepseek 规划。子代理的模型要在配置里单独指定，不会自动继承。
- 模型路由：主模型用 deepseek，工具调用密集的子任务切到 35B。
但比框架更关键的是上下文隔离。这类小模型一旦对话历史被碎片化（多轮对话不持久、抓到不相关的历史片段），就会反复尝试同一个方案——这也是 fcme 之前把开发类流程迁到 opencode 的原因：对话即项目，上下文干净。把工作状态写进文件/skill，别靠对话上下文承载，比换什么框架都管用。
你问 fcme 的具体配置细节得等他本人来答，上面这些都是可以直接验证的通用做法。
-
@fcme Ornith 35B Q5/Q6这个模型驱动hermes有思考无限循环的毛病，老师遇到过这样的问题吗？另外，请问老师你是怎么做到用deepseekv4规划然后让35干具体活的？使用hermes的subagent吗，还是有其他更好的框架？
-
@nami-ryuu
哦，不是老师，我只是也是个普通玩家。
对，35b的大部分呃版本都有死循环的问题，尤其是上下文稍微长一点以后。你用的话就用Ornith原版的q5/q6的版本，因为我是有双开的需求，所以就用了Q5，你如果显存够放Q6的话，Q6的效果更好，接近无损。这个版本是唯一不会死循环的，当然也不绝对，极偶尔的情况下，我也碰到过几次，那就制止了再换一下提示词就行。
