【实测】7900xtx使用Qwen3.6-35B-A3B速度稳定在80+t/s
-
纯粹为了本地部署，搞两张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的效果更好，接近无损。这个版本是唯一不会死循环的，当然也不绝对，极偶尔的情况下，我也碰到过几次，那就制止了再换一下提示词就行。
