Qwen 3.8 思考真的要至少設low
-
-
-
这个坑很典型。
none不是「不思考但会自检」，而是连内部纠错预算都没有：一旦第一步选错分支，后面只会按同一模式重复，表现出来就是死循环。low给了最小思考预算，模型才有机会在中途发现方向不对并回退。选择上我一般这么分：
- 分类、抽取、固定格式转换：
none够用； - 写代码、调引擎、多步工具调用：至少
low，复杂排障用medium； - 纯聊天或创意发散，思考档位影响反而小。
量化档位（IQ3_XXS / IQ3_S）影响的是单步判断质量，不会直接制造这种「无思考死循环」；如果改成
low后循环消失，基本可以确定是思考预算问题，不是量化或 engine 的锅。 - 分类、抽取、固定格式转换：
-
确实如此。我最近在单张 RX 7900 XTX 上针对不同 Thinking 档位进行了对照测试。Thinking Off 虽然响应速度很快，但在部分复杂推理任务上，与 Low 存在明显的质量差距。**
一、60 题混合能力测试：Off vs Low
测试时间：2026 年 10 月 18 日。
测试配置：temperature=0、max_tokens=16384，每道题分别请求 Thinking Off、Low、Medium。
指标 Off Low 差距 综合准确率 76.4%（42/55） 90.7%（49/54） +14.3 个百分点 GSM8K 100%（20/20） 100%（20/20） 相同 MMLU 70%（14/20） 85%（17/20） +15 个百分点 GPQA 40%（4/10） 80%（8/10） +40 个百分点 AIME 2025 80%（4/5） 100%（4/4 有效） Low 有 1 题截断 中位耗时 1.6 秒 17.8 秒 约 11.1 倍 中位输出 Tokens 71 372 约 5.2 倍 这 60 道题包含什么？
题集 题数 主要测试能力 GSM8K 20 数学应用题、多步骤算术推理 MMLU 20 数学、物理、化学、计算机、经济、医学、逻辑等学科知识 GPQA 10 高难度科学知识与推理 AIME 2025 5 数学竞赛级推理 HumanEval 5 Python 代码生成（本轮未执行评分） 合计 60 HumanEval 的 5 道题未计入综合准确率，因此 Off 的分母为 55，Low 因另有 1 题截断，分母为 54。
最值得关注的是 GPQA：Off 只有 40%，Low 达到 80%。 虽然只有 10 道抽样题，但至少说明在这组较复杂的科学推理任务中，开启 Low 有明显收益。
不过，60 题是按题集抽样，并非按任务难度均衡设计，也不能直接代表真实 Agent 的综合成功率。
二、HumanEval 164 题全量代码测试
为了进一步比较 Coding 能力，还进行了 HumanEval 164 题完整执行评分。
指标 Off Low Medium 正确率 93.3%（153/164） 95.1%（156/164） 95.7%（157/164） 中位耗时 0.79 秒 2.69 秒 3.04 秒 P90 耗时 1.46 秒 5.20 秒 6.67 秒 中位输出 Tokens 151 527 633 这一组的特点恰好不同：
- 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。四、实际使用建议
结合目前的测试，我倾向于采用以下策略：
任务类型 建议档位 理由 文件操作、简单工具调用 Off 减少多轮 Agent 的推理开销 常规代码生成 Off 起步 HumanEval 已有 93.3% 正确率 复杂计算、疑难 Debug Low 在复杂推理抽样中收益明显 高难度科学与逻辑问题 Low / Medium Off 存在明显失分风险 重大方案与最终交付 Low + 独立复核 降低单一模型遗漏错误的风险 对于长期 Agent，我更倾向于让主模型保持高速执行，同时在重要步骤、关键中间成果和最终产出阶段，利用第二个模型进行独立复核。
原因很简单：模型不一定知道自己什么时候犯了错误，所以不能完全依赖模型自行决定是否需要更深入的思考或专家帮助。
-
真是血淋淋的教訓
貪快選none
小問題是很快
但是一旦分析錯誤
Qwen 3.8 思考真的要至少設low
一直無窮迴圈
好死不死我又在改AI engine
整個被投向錯誤方向（我以為是我 AI Engine改壞了)
然後發現怎麼全壞了
一路猜
改context 改 kv dtype....馬的！都沒效果結果改成low....突然不會死循環了，會思考了
真是血淋淋一場教訓
-
-
-
-
-
@stxpnet 我也在找，你要是找到了分享下哈。
之前我本来想让AI给自己写个路由，甚至想引入JEV做判断，转念一想，让一个不够聪明的model管理不够聪明的它自己的我的这种想法是不是不够聪明？
后来我发现完全可以用命令来控制，平时无非就是默认无思考模式速度拉满，需要质量了，telegram里一条/reasoning命令启动low或者medium思考模式，完成任务再切换回去。除此之外，重要的交付任务，我现在先用27B跑完，然后让本地的FN再复核一遍，往往有新发现。也算是一种折衷的变相解决方案。
-
-
-
-
@Ben-Lee 我用QNF 来想大致方向然后交给27b 做
-
，
G gao Gao 引用了 此主题
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！