把 reasoning 关掉，模型还剩下多少活能干

Reddit 的 r/LocalLLaMA 上有人提问，有没有人真的把 reasoning level 设成 None。提问者说，agentic 任务里想省时间，但一直不敢，最低只用到 medium。

跟帖里，No reasoning 的适用场景比想象中具体。

• 翻译。有网友说 Gemma 4 26B、31B 和 Index Translate 9B、35B 效果可以，代价是每段大约一个词错。
• 确定性子步骤。JSON schema 提取、router 分类、执行已经计划好的 diff。思路是 planner 保持 medium，tool execution 关掉 reasoning，循环时间减半，准确率没明显掉。
• 但执行端关掉思考会看不到计划过期。文件在 planner 读完之后变了，它还可能自信地应用错误 diff。有网友的兜底是让 apply_diff 校验文件 sha256，不匹配就把控制权交回 medium planner。
• 纯机械任务更适合脚本。写 bash 或 AST codemod，比让模型无思考执行更稳。No reasoning 留给模糊粘合层，比如把编译器错误、DOM 节点映射成工具参数。

还有工程细节：如果 chat template 把 thinking 开关塞进 system prompt，会破坏 prefix cache；如果追加在 user turn 末尾，比如 qwen3 的 /no_think 或 llama.cpp 的 chat_template_kwargs，共享历史前缀还能缓存。有网友用无思考子 agent，限制上下文到 64k 或 128k，主会话等待时并发跑多个 executor，复用 32k 计划上下文，省 prefill，也加快 decode。

另一些人把 reasoning 关掉用于分类、OCR、captioning、compaction、RAG query rephrasing、STT/TTS 短回答、alt text、文件重命名。有网友说，很多不需要逻辑思考的场景，关掉 reasoning 反而更好。压缩摘要测了几周，更多 thinking 没带来更好摘要，速度还慢。

电话 agent 的经验更复杂。有网友做一个高复杂度电话 agent，因为延迟要求，主模型一直不用 reasoning。代价是上下文工程变重：工具结果和错误要直接告诉模型下一步做什么，滚动系统提醒格式，工具结果只给 1 到 3 行，日期时间按可原样回复的格式给，还要检查模型是否忘记工具调用或重复自己。用约 200 个调用场景测 qwen flash next，low reasoning 比 no reasoning 通过率至少高 20%，所以他在评估加硬件跑 low reasoning。

也有反例和提醒。有网友说视觉任务有时不用 reasoning 更好。有人用 None 快速跑 1000 个问题做 agent 基准，省 GPU 时间。有人提醒，别把论坛评论当客观事实，要自己测。还有人开玩笑，第一次用 LLM 时不知道 reasoning，关了一个多月，一直纳闷模型怎么这么笨。

整体看，No reasoning 适合低延迟、短链路、结果可校验的任务。只要任务里有计划过期、多步依赖、需要自我检查，就得靠 harness、校验和提示词补上。省下来的几秒，可能要在工程里还回去。