推理强度：从三档模式到 1–100

“思考多少”早已是调用方的参数。V4.1 改变的是这个参数在模型内部的形态：从几个离散的模式，变成一个连续的旋钮 [1]。

前代：三种模式，三套训练配置

V4 论文说，V4-Pro 与 V4-Flash 各支持三种推理模式 [2]：

这三种模式是在不同的强化学习配置下分别训练出来的专门模型，各用不同的长度惩罚和上下文窗口，再整合进一个模型 [2]。评测时三种模式的上下文窗口分别给 8K、128K 与 384K [2]。Think Max 注入的指令开头是“Reasoning Effort: Absolute maximum with no shortcuts permitted.”（推理强度：绝对最大，不许走捷径）[2]。

后来 V4-Flash-0731 的模型卡写到 reasoning_effort 支持 low、high、max 三档；8 月 13 日的公告也宣布 V4-Pro 与 V4-Flash 的 API 支持这三档：low 用于简单任务，high 用于日常 Agent 工作流，max 用于复杂任务 [3][4]。

V4.1：一个 1 到 100 的整数

V4.1 在强化学习里引入一个标量推理强度 $e \in \{1, \dots, 100\}$，作为显式的条件信号，单轮推理和多轮 Agent 任务都用 [1]。做法是在系统提示词前面加一行强度说明。官方编码器实际渲染出来是这样（取强度 75 为例；报告正文里的措辞与此略有出入，以编码器为准）[6]：

<｜System｜>Reasoning Effort: 75 (range 1-100, the higher the value, the more thorough the reasoning)

训练时怎么让模型学会“按强度办事”？报告第 5.1.4 节与附录 C 的要点 [1]：

• 对每个训练提示词，在训练用的每个强度档位上各采样若干条回答；同一提示词、同一强度的回答组成一个小组，奖励只在小组内减均值、算相对优势。也就是说，不同强度的回答从不直接比较。
• 强度的差别全靠奖励里的长度惩罚塑造：推理 token 越多扣分越多，扣分有上限；惩罚系数随强度指数衰减——强度每提高一个训练档位的间距，系数就乘上一个小于 1 的固定因子。强度越低，模型越被逼着少想。
• 附录 C 给了一个动机：假设多想一步的边际收益大致呈指数衰减，这种惩罚形式会让“偏好的推理长度”与强度近似成线性关系。报告特意说明这只是局部近似，实际长度不必严格线性或单调。
• 训练只用了有限几个档位，部署时可以用中间值，得到插值的行为。

API 里只有三档

V4.1 的公开 API 没有开放 1–100 的整数，而是给了三个预设档位，直接映射到这个标量上 [1][5]：

官方“思考模式”文档（9 月 19 日查阅）的具体规则 [5]：

• 开关：OpenAI 格式与 Anthropic 格式都用 thinking 的 type 取 enabled / disabled；Responses API 用 reasoning.effort，取 none 即关闭思考。思考模式默认打开，默认档位是 high。
• 强度：OpenAI 格式用 reasoning_effort，Anthropic 格式用 output_config.effort，取值 low / high / max。其他写法会被归并：minimal 算 low，medium 与 xhigh 算 high，ultra 算 max。
• 采样参数：思考模式下 temperature、presence_penalty、frequency_penalty 不生效（设置了也不报错）；top_p 只在思考模式下生效，有效范围 0.95–1.0，低于 0.95 按 0.95 处理。

自己部署时的一个坑：映射改过一次

V4.1 没有附带 Jinja 格式的对话模板，官方用仓库里的 encoding/encoding.py 定义提示词格式 [6]。它接受 1–100 的整数，或者字符串 "low"、"high"、"max"，分别映射到 50、75、100，默认 "high"（75），这和 API 一致 [6]。

但查 Hugging Face 上的提交历史可以看到，9 月 10 日最早上传的编码器用的是另一套映射：low、high、xhigh、max 对应 25、50、75、100；同一天 07:17（UTC）的提交才改成现在的 50 / 75 / 100 [7]。截至 9 月 19 日，vLLM 的配方页仍按旧映射描述：low 为 25、high 为 50、xhigh 为 75，两个开关都不设时默认开启思考、强度 50 [8]。

所以同样写“high”，在官方 API 上是 75，在按旧映射实现的推理引擎里可能是 50。要和 API 对齐，直接传整数最稳妥。 vLLM 配方页还提醒了一个容易误判的现象：默认开着思考，如果 max_tokens 给得太小，额度会全花在思考上，返回空内容并以长度截断结束，看起来像模型坏了，其实不是 [8]。

效果：官方口径

报告第 5.3.2 节与附录 B 给出的曲线（强度从 25 调到 100，均为 DeepSeek 自测）[1]：

代价是输出 token 约增加到 2.5 倍。几条值得记住的细节 [1]：

• 收益集中在前段：60–80 的强度已经拿回最高档的大部分准确率，token 用量不到最高档的一半；从 80 提到 100，Agent 轨迹变长 1.6–1.8 倍，准确率只多一点点。报告的建议是把最高档留给最难的任务。
• 单题长度可以预估：从 25 到 100，每个基准的平均回答长度都稳定地增加 2.0–3.1 倍，例如 AIME 2026 从 4.6k 到 11.4k token、MathArena Apex 2025 从 29.1k 到 86.1k token；后者的准确率从 25.3% 升到 65.6%，AIME 2026 在最高档达到 100%。
• 跨脚手架时没那么听话：在 Claude Code、DeepSeek Harness 与 mini-SWE 三种脚手架上，轨迹长度都随强度单调增长，但准确率只是大致跟随，中间档位会出现平台和回落。在接近饱和的 Terminal-Bench 2.1 上，报告的原话是“脚手架的选择至少和强度档位一样重要”。

对照阅读：同期的 Qwen3.8-Max 提供三档且默认最高档，Kimi K3 也是多档推理强度。三家都把“想多少”交给调用方，V4.1 是其中唯一把它训成连续整数的。

第三部分结束。下一部分讲训练：先从预训练开始。👉 45T token、Muon 与 Sinkhorn

参考文献

• [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. arXiv:2609.19969 —— 第 5.1.4 节（标量推理强度的训练方法与 API 档位映射表）、第 5.3.2–5.3.3 节（强度与准确率、长度的曲线）、附录 B.2–B.3（跨脚手架与各基准明细）、附录 C（指数惩罚的动机）。
• [2] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. arXiv:2606.19348 —— 三种推理模式、分别训练的做法、Think Max 注入指令、评测上下文窗口。
• [3] Hugging Face 模型卡：deepseek-ai/DeepSeek-V4-Flash-0731 —— reasoning_effort 支持 low、high、max 三档。
• [4] DeepSeek. “DeepSeek-V4-Pro GA Release.” 2026-08-13. api-docs.deepseek.com/news/news260813 —— V4-Pro 与 V4-Flash 的三档推理强度及适用场景。
• [5] DeepSeek API 文档. “思考模式.” 2026-09-19 查阅. api-docs.deepseek.com/zh-cn/guides/thinking_mode —— 开关与强度参数、取值归并规则、思考模式下的采样参数限制。
• [6] Hugging Face：deepseek-ai/DeepSeek-V4.1-Flash 的 encoding/README.md 与 encoding.py —— 数值强度前缀、字符串映射与默认值。
• [7] Hugging Face：deepseek-ai/DeepSeek-V4.1-Flash 的提交历史 —— 2026-09-10 早期提交中的 25 / 50 / 75 / 100 映射，与之后改为 50 / 75 / 100 的提交。
• [8] vLLM Recipes. “deepseek-ai/DeepSeek-V4.1-Flash.” 2026-09-19 查阅. recipes.vllm.ai/deepseek-ai/DeepSeek-V4.1-Flash —— 第三方推理引擎文档：它描述的档位映射、默认值与 max_tokens 过小的现象。