你本地用 Ollama 拉起 DeepSeek R1，本来想快点拿答案，结果它先噼里啪啦吐一大段思考过程，日志刷屏、首字慢、下游程序还得再写正则去剥。这篇不聊模型好不好，只解决一件事：怎么把这层思考输出关掉或绕开，按调用方式分场景给可执行动作，并说清什么情况下不该关。
你本地用 Ollama 拉起 DeepSeek R1，本来是想快点拿到答案，结果它先噼里啪啦吐一大段思考过程出来。日志刷屏、首字变慢，下游程序还得再写一版正则把那层包裹剥掉，多一道活。这篇不评价模型本身好坏，只解决一件事：怎么把深度思考的输出关掉或者绕开。
关法按调用方式分三种，各自的入口不一样，改了一处不等于全关。下面按「先判断该不该关 → 三种入口怎么关 → 改完怎么验证 → 有哪些边界」的顺序走，最后给一个排查顺序表。全程只给判断标准和动作，具体数字以你本机实测为准。
先判断：你这场景到底该不该关
关不关，先看任务性质，不要一上来就调参数。适合关的是那些答案形态固定、不需要推理链的活；不适合关的是真要靠多步推导才出结果的活。这两类混在一个脚本里，就该拆成两条调用路径，而不是统一开或统一关。
- 适合关：格式固定的信息抽取、文本分类、批量改写、批处理脚本里要机器直接读的输出、对首字延迟敏感的在线接口。
- 不适合关：多步数学、代码调试、逻辑链条长的推理题；关掉等于把它相对普通模型的那部分能力砍了，结果会明显变浅。
- 只是嫌网页界面里过程太显眼，而不是嫌慢？那要解决的是前端展示层的过滤，不是模型行为，别去改参数。
- 拿不准就先各跑一批对比，具体延迟基线可以先到 /tools/speed-test 量一遍再决定。
按入口分：三种调用方式各自的关法
Ollama 的关键点是：命令行、HTTP 接口、上层工具这三条路互不影响。你在这台机上用命令行关掉了，不代表另一个进程走接口调它也关了。先确认你是哪条路，再对症下手。
- 命令行一次性调用在 ollama run 后面直接把参数带上，参数写成键值对形式随请求下发。跑完看输出里还有没有思考段，没有就说明这一条生效了。
- 已进会话想临时改在会话里用 /set parameter 改当前会话的参数，改完当场生效，退出会话恢复默认值。适合调试阶段反复试，不适合写进生产。
- 走 HTTP 接口调用在请求体里带参数开关，别只改命令行。用 curl 或你惯用的调试工具发一条最简单的提示词，看返回 JSON 里思考字段是否为空。
- 用 SDK 或上层工具Dify、Open WebUI、各种 Agent 框架通常有自己的模型配置层，参数会在这里被覆盖或补默认值。要改的是工具那一层的模型设置，改 Ollama 全局配置对它没用。
还有一个绕不开的前提：参数能不能被识别，取决于你本地那份模型模板有没有接这个开关，以及当前 Ollama 版本是否支持。模板里没接，你传了也是空转，这是最常见的卡点。查模板的办法是看本地模型的 Modelfile，确认里面有没有对应的参数槽位。
改完怎么确认真的关掉了
很多人改完只看输出「像不像」，这不可靠。要验证就三件事：看结构、看时间、看长度。三条都对上了才算真生效，缺一条都可能是模板忽略了你传的参数。
- 用最简单的一句提示词跑一次，检查返回结构里还有没有独立的思考字段或前后包裹标记。
- 命令行下同时观察首字返回时间和总输出字符数，两个都明显变短，才说明参数真被吃进去了。
- 别拿复杂推理题做验证样本，那种题即使参数生效也可能触发出思考，测不准。
- 改完记得换回一条你平时真在跑的业务提示词再跑一遍，格式类任务最容易看出差别。
如果参数死活不生效，别死磕，走兜底。兜底有三条，从轻到重：提示词层面压制、下游输出清洗、直接换模型。多数情况下第二条最稳，因为它不依赖模型行为。
| 兜底手段 | 怎么做 | 什么情况下不好用 |
|---|---|---|
| 系统提示里要求直接给结论 | 在系统提示里写明只输出最终答案、不要过程 | 遇到强推理触发词时未必压得住，模型仍可能吐思考 |
| 下游清洗输出 | 把固定的思考包裹标记用正则剥掉，再落库或返回 | 标记格式变了就要跟着改，属于被动跟随 |
| 换非推理模型 | 任务不需要推理链时，直接换成普通模型 | 任务真的需要多步推理时，换完结果会变浅 |
| 拆调用路径 | 把格式类和推理类请求分成两条路径分别配参 | 架构改动成本高，小脚本没必要 |
选型上不确定该留哪个模型，可以到 /models 对照参数和适用场景再定，比在两个思考型模型之间反复试参数省事。
边界：关了思考不等于没成本，也不等于变聪明
有几个容易误判的点，提前说清楚，免得你按错误预期去上线。核心就一句：关思考改善的是延迟和可读性，不改变模型能力上限，也不自动降低上下文开销。
- 上下文长度按总 token 算，思考段被压掉只是让你少看；如果历史里已经被写进去，后面每轮还在重复占用，得在建历史时就截断。
- 关掉思考后同一条提示词的效果会变，之前调好的提示词和少样本示例要重新过一遍，别直接上线。
- 批量任务建议先抽样跑一批开与关的对比，某些类别差异大的就保持开启，不要一刀切。
- 显存占用和并发能力不会因为关思考而变化，想让同样的卡多跑几路，得回到部署侧按量化和参数去调，参考 /models/deploy 上的说明。
最后给一个排查顺序：先确认调用入口是哪条路，再确认本地模型模板里有没有对应参数槽位，然后发一条极简提示词看结构、时间、长度三个信号，三个都不动就走下游清洗兜底，还不行就换模型或拆路径。按这个顺序走，基本不会在无效改参上浪费时间。想横向看看不同方案的实际表现，可以到 /guides 里的相关指南对照着看。
下一步把你本机当前的延迟和输出长度先量出来做基线，再决定关不关、关到什么程度；顺带核对一下所选模型的参数说明，避免在模板不支持的情况下空改参数。→常见问题
参数传了但是照样输出思考过程，是什么原因？
先查三处：一是你改的是命令行而他实际走的是 API；二是上层工具把参数覆盖了；三是本地那个模型的模板根本没接思考开关。三处都排除后，用最短提示词再测一次，看返回里有没有独立思考字段，有字段说明是模板层面的问题，只能用输出清洗兜底。
关掉思考之后回答变差很多，还能救吗？
说明这类任务本来就需要推理链。两个方向：一是把任务拆小，让每一步都不需要长链思考；二是把思考开着但限制在服务端不外泄，前端只展示结论。硬压思考去跑复杂推理，通常会换来更自信的错答案，比慢一点更麻烦。
关掉思考能省多少显存或者能多跑几个并发？
基本不省显存。权重和 KV 缓存该占多少还是多少，关思考影响的是生成阶段吐多少 token，所以主要改善首字延迟和总耗时。想提并发得从量化、上下文上限和 batch 这几项入手，具体算一遍看 /models/deploy。
