奖励凭证：热议 +3 分 · 编号 h2513-1962-1（系统自动发放，显示稍有延迟）

之前我本来想让AI给自己写个路由，甚至想引入JEV做判断，转念一想，让一个不够聪明的model管理不够聪明的它自己的我的这种想法是不是不够聪明？ 后来我发现完全可以用命令来控制，平时无非就是默认无思考模式速度拉满，需要质量了，telegram里一条/reasoning命令启动low或者medium思考模式，完成任务再切换回去。

除此之外，重要的交付任务，我现在先用27B跑完，然后让本地的FN再复核一遍，往往有新发现。也算是一种折衷的变相解决方案。

@David-Chen said:

貪快選none
小問題是很快
但是一旦分析錯誤
Qwen 3.8 思考真的要至少設low
一直無窮迴圈

昨天在測試的時候剛好遇到一模一樣的狀況
Reasoning none 無窮迴圈 => 改成low 就繼續正常跑了
Reasoning xhigh 沒問題

一、60 题混合能力测试：Off vs Low

测试时间：2026 年 10 月 18 日。

测试配置：temperature=0、max_tokens=16384，每道题分别请求 Thinking Off、Low、Medium。

这 60 道题包含什么？

HumanEval 的 5 道题未计入综合准确率，因此 Off 的分母为 55，Low 因另有 1 题截断，分母为 54。

最值得关注的是 GPQA：Off 只有 40%，Low 达到 80%。 虽然只有 10 道抽样题，但至少说明在这组较复杂的科学推理任务中，开启 Low 有明显收益。

不过，60 题是按题集抽样，并非按任务难度均衡设计，也不能直接代表真实 Agent 的综合成功率。

二、HumanEval 164 题全量代码测试

为了进一步比较 Coding 能力，还进行了 HumanEval 164 题完整执行评分。

这一组的特点恰好不同：

• Off 已经达到 93.3%，代码生成能力并不弱。
• Low 只比 Off 提高 1.8 个百分点，但中位耗时增加到约 3.4 倍。
• Medium 相比 Low 只多通过 1 题，生成时间和 Token 消耗进一步增加。

因此，开启更多思考，并不一定具有相同的性价比，收益很大程度取决于任务类型。

需要说明的是，上述是请求 Thinking 档位的对照结果；Hipfire 没有为每次请求提供独立的 effective-mode 字段，因此不能声称底层实际思考状态均已获得完全验证。

三、Hermes 对话中如何切换 Thinking 档位？

在 Hermes + Hipfire 27B 环境中，可以尝试使用以下命令切换当前会话的思考档位：

日常任务：Thinking Off

/reasoning off

复杂推理：Thinking Low

/reasoning low

更深入的分析：Thinking Medium

/reasoning medium

这些命令用于切换推理档位，并不是切换模型或 GPU 路由。模型仍然是 Hipfire 上的 Qwen3.8-27B。

Hipfire API 层已经验证能够通过每次请求的 reasoning_effort 参数切换思考行为，但 Hermes 是否把会话档位正确传递到 Hipfire，还要看实际 Provider 配置。

一个需要注意的配置问题

此前 Hermes Provider 中曾存在以下设置：

chat_template_kwargs:
  enable_thinking: false

如果这个设置仍被固定注入请求，即使在对话中输入 /reasoning low，也可能无法真正启用思考。

因此，建议通过实际请求确认 reasoning_content 是否非空、输出行为是否发生预期变化，而不只是检查 Hermes 是否接受了命令。

如果需要在对话中切换 Hipfire 27B 与另一套 Flash-Next 模型，则属于模型路由切换，应使用 Hermes 的 /model 命令选择已配置的模型，而不是 /reasoning。

四、实际使用建议

结合目前的测试，我倾向于采用以下策略：

对于长期 Agent，我更倾向于让主模型保持高速执行，同时在重要步骤、关键中间成果和最终产出阶段，利用第二个模型进行独立复核。

原因很简单：模型不一定知道自己什么时候犯了错误，所以不能完全依赖模型自行决定是否需要更深入的思考或专家帮助。

选择上我一般这么分：

• 分类、抽取、固定格式转换：none 够用；
• 写代码、调引擎、多步工具调用：至少 low，复杂排障用 medium；
• 纯聊天或创意发散，思考档位影响反而小。

量化档位（IQ3_XXS / IQ3_S）影响的是单步判断质量，不会直接制造这种「无思考死循环」；如果改成 low 后循环消失，基本可以确定是思考预算问题，不是量化或 engine 的锅。