Qwen 3.8-27B总想太久，先调medium还是设8192 token预算？

一名 Reddit 用户称，他的 Qwen 3.8-27B 在 llama.cpp 里曾连续思考超过 90 分钟。加上 8192 token 的推理预算后，模型会在达到上限时转去回答或发起工具调用。不过评论区给出了另一条思路：先把 reasoning_effort 从默认的高强度降到 medium。两种设置解决的不是同一件事，我更建议先调 medium，再把 8192 token 预算当保险丝。

8月15日，我们看过它在12GB笔记本显卡上跑量化版，也看过32GB单卡开128K上下文审计多年老代码。模型能跑起来之后，新的烦恼变成了什么时候肯停。简单问答等半天，代理改文件又迟迟不肯调用工具，本地运行省下的调用费，很容易被等待时间吃回去。

Simon Willison 的体验把这个反差说得很具体。他使用 LM Studio 的17GB Q4_K_M量化版时，文档所述的 xhigh 推理档位被保留下来。一次 SVG 任务花了21分钟，消耗22276个推理 token，最后生成3223个输出 token；同一提示词关闭推理后耗时137秒，输出3715个 token。速度差距很大，但关闭推理也不等于白捡速度。他在另一个边界框工具任务里发现，无推理版本几乎能用，却把框画错了位置。

所以，普通问答、摘要和边界清楚的小修改，可以先试这段参数：

--chat-template-kwargs '{"reasoning_effort": "medium"}'

medium 调的是模型从一开始准备投入多少推理强度，8192 token 预算管的是它最多还能想多久。 前者像换挡，后者更像限位器。社区里也有用户称，medium 用于 OpenCode 修改两个 Markdown 文件时，比 reasoning-budget 设为0的结果更好，不过这只是一次没有完整环境记录的个人测试。

如果任务偶尔会陷入长时间循环，再叠加预算兜底：

--reasoning-budget 8192 --reasoning-budget-message "Time to stop thinking. Give the final answer or make the tool call now."

这段消息的意思很直接，预算耗尽后停止继续推理，给出最终答案，或者立即调用工具。发帖者认为8192 token在自己的任务里够用，速度与推理深度也能接受；多名评论者则提醒，中途碰到上限可能让最终输出变差。8192因此适合作为这位用户验证过的起点，不能直接当成所有机器、量化版本和任务的最佳答案。

还有一处不能省。reasoning_effort 的可选档位、reasoning-budget 的执行方式以及聊天模板能否传递这些设置，可能随 llama.cpp 版本和模板变化。动手前先记下 llama.cpp 版本、模型文件和聊天模板，启动时确认参数被识别。只把命令贴进去，却没有确认当前构建是否接收，后面的耗时比较就失去了意义。

真正有用的对照也不该只看生成速度。固定模型文件、量化版本、硬件、上下文、提示词和代理工具，分别跑一条普通问答和一条双 Markdown 文件修改任务，再按下面这张表记录：

配置

需要记录

通过条件

medium

总耗时、思考 token、答案要点、文件 diff

回答命中预设要点，文件只改指定位置

xhigh + 8192预算

是否触发预算、触发时任务进行到哪一步、工具调用是否完成

预算结束后答案完整，工具调用没有停在半路

xhigh、不设预算

总耗时、思考 token、最终成品

作为复杂任务的质量参照

这是一张复现记录表，不是现成跑分。普通问答可以预先写下三到五个必答点；修改文件则保留原文件和预期 diff。跑完不要只比较谁先出字，还要看答案有没有漏条件、Markdown 是否误改其他段落、工具调用是否真的落盘。这样才能判断 medium 是提速，还是把必要思考一并削掉了。

任务复杂度也要分开。日常问答和范围明确的小改动优先从 medium 开始；跨文件规划、长链编程和需要多次工具调用的工作，可以保留更高推理强度，同时设置预算观察是否会撞线。如果预算耗尽时计划还没完成、工具调用停在中间，或者 diff 出现计划外修改，就停止自动执行，恢复更高档位或拆小任务，再由人检查最终结果。

你在本地跑 Qwen 3.8-27B 时，最长遇到过多久的思考？调到 medium 后，速度和成品质量分别有什么变化？