没必要二选一：DeepSeek-V3.1 把“思考模式”和“效率模式”装进同一模型 原创

当大家还在为“要不要开思维链”争论不休时，DeepSeek-V3.1 直接把答案写进了模型：一个模型，同时支持“思考（Thinking）”与“非思考（Non-Thinking）两种生成范式，按需切换。这不是简单的开关，而是一整套从 chat template 到 工具调用、从 代码代理 到 搜索代理 的系统工程。更重要的是，它依旧延续了 DeepSeek 系列“以极高性价比逼近顶级性能”的口碑，为企业和开发者打开了新的成本—性能平衡点。

下面，我们把这次升级拆解清楚：它究竟升级了什么、为什么重要、怎么用、适合谁。

1、定位与升级：把“混合思维模式”变成可控生产力

如果你关注过 V3，就知道它已经能打；而 DeepSeek-V3.1 在此基础上进一步“补齐思考与效率的两端”。

• 混合思维模式：一套chat template即可在Thinking 与 Non-Thinking之间切换。Non-Thinking更快、更适合对延迟敏感的线上业务；Thinking更稳、更适合需要严谨推理的复杂任务（如数学、编码、工具组合调用）。两种模式统一到一个模型里，避免了环境切换和权重维护的额外成本。（辅关键词：混合思维模式、长上下文）
• 工具调用与智能代理：V3.1 对tool calling做了后训练优化，严格结构化的调用格式、更稳定的agent 轨迹模板，同时支持代码代理（Code Agent）与搜索代理（Search Agent）等复杂场景。对于业务系统意味深长：从“会回答”到“会办事”。（辅关键词：工具调用、代码代理）
• 思考效率更高：在思考模式下，V3.1 的回答质量可比肩 R1-0528，但响应速度更快。面对“效率与质量”这对老难题，它选择了“减少浪费的思考”。（辅关键词：混合思维模式、MoE 架构）

一句话总结：DeepSeek-V3.1 把“如何思考、何时思考、思考到什么程度”交还给开发者，可控、稳定、能落地。

2、架构与训练：671B 参数总量的 MoE，推理只激活 37B

性能从何而来？答案藏在MoE 架构 + 长上下文训练。

• MoE 架构：模型总参数 671B，但每个 token 仅激活 37B专家，做到了“容量与成本解耦”。这意味着：保持大模型的表达能力，同时显著降低单次推理开销。（辅关键词：MoE 架构、长上下文）
• 128K 上下文：上下文直接拉到128K tokens，对代码审阅、长文档分析、合同比对、技术检索都更加友好。（辅关键词：长上下文、工具调用）
• 两阶段长上下文扩展：

     a.32K 阶段：在 630B tokens 上训练，是 V3 的 10 倍；

     b.128K 阶段：在 209B tokens 上训练，是 V3 的 3.3 倍。 这不是“把窗口调大”的简单工程，而是系统性地让模型学会理解长文本的组织与结构。（辅关键词：长上下文、混合思维模式）

• FP8（UE8M0）微缩标度：以FP8 microscaling进行效率优化，匹配新一代硬件的算力特征，让大规模训练与推理都更经济。（辅关键词：MoE 架构）

这套工程让 DeepSeek-V3.1 在大容量、低成本、长上下文这三项传统“不可兼得”的指标上找到了现实解。

3、混合思维模式：一个模板，两种“大脑”，随用随切

DeepSeek-V3.1 通过 chat template 控制模式，非常直观：

• 非思考（Non-Thinking）首轮前缀示例（关键信号：​​</think>​​）：

<｜begin▁of▁sentence｜>{system prompt}<｜User｜>{query}<｜Assistant｜></think>

多轮对话会在上下文中**保留 ​​</think>​​**，并以

<｜User｜>{query}<｜Assistant｜></think>

作为前缀继续。（辅关键词：混合思维模式）

• 思考（Thinking）首轮前缀示例（关键信号：​​<think>​​）：

<｜begin▁of▁sentence｜>{system prompt}<｜User｜>{query}<｜Assistant｜><think>

多轮与非思考类似，但**历史轮次中保留 ​​</think>​​​**，最后一轮用 ​​<think>​​ 触发思考。（辅关键词：混合思维模式、长上下文）

如何取舍？

• 做实时问答、在线客服、检索式问询：优先Non-Thinking，延迟更低；
• 做数学推理、复杂代码生成与调试、跨工具流水线：优先Thinking，质量收益显著；
• 做场景混合：在一个系统里按路由策略动态选择模式，比如“低风险问题走 Non-Thinking，高风险问题走 Thinking”。（辅关键词：工具调用、代码代理）

4、工具调用与智能代理：把“会说”升级为“会做”

ToolCall 在 非思考模式 下支持，格式严格、稳定可编排。模板要求示例（节选）：

## Tools
You have access to the following tools:

### {tool_name1}
Description: {description}

Parameters: {json.dumps(parameters)}

IMPORTANT: ALWAYS adhere to this exact format for tool use:
<｜tool▁calls▁begin｜><｜tool▁call▁begin｜>tool_call_name<｜tool▁sep｜>tool_call_arguments<｜tool▁call▁end｜>{{additional_tool_calls}}<｜tool▁calls▁end｜>

这意味着你可以把 DeepSeek-V3.1 直接塞进脚本化工作流里：先调用外部 API 拉数据 → 生成代码 → 执行 → 调试，形成一条可回放的“代理轨迹”。（辅关键词：工具调用、代码代理）

• 代码代理（Code Agent）：官方提供了轨迹模板，定义了生成—执行—调试的交互协议；在SWE-bench（Agent 模式）这类评测里，V3.1 展现出明显优势。对于日常工程，这意味着它不只是“写个函数”，而是能围绕目标持续迭代。（辅关键词：代码代理、工具调用）
• 搜索代理（Search Agent）：在需要时效信息的任务（商业、财经、技术研究）里，可通过多轮工具调用接入外部搜索工具，逐步查证、整合。对企业场景而言，这是从“闭卷答题”迈向“开卷办事”。（辅关键词：工具调用、长上下文）

5、性能速览：编码与数学强势，代理类任务拉开差距

DeepSeek-V3.1 的评测覆盖 通识、代码、数学、工具使用、代理任务 等多个维度。以下摘取官方提供的关键数据（同一来源，仅重排）：

5.1 代表性对比（与 R1-0528 等同类版本参照）

结论很清晰：在编码与数学两大高门槛任务上，Thinking 模式的 V3.1 追平或反超强基线；而在代理型任务上，结构化工具调用 + 轨迹模板带来了显著领先。（辅关键词：代码代理、工具调用、Benchmark）

这些数据印证了“思考模式更适合高难度、结构化强依赖的任务”，而非思考模式依旧是追求延迟/吞吐的理想选择。（辅关键词：混合思维模式、Benchmark）

6、部署与许可：MIT 开源，兼容 V3 生态

好用还得好落地。DeepSeek-V3.1 在这两点上给得很足：

• MIT 许可：权重与代码在 Hugging Face / ModelScope 全量开放，研究与商用都可直接使用。（辅关键词：开源、工具调用）
• 与 V3 结构兼容：本地推理说明已给出，迁移成本低；当然，受制于模型规模，需要较强 GPU 资源，但社区生态与工具链正在持续降低门槛。（辅关键词：长上下文、MoE 架构）

7、上手即用：官方用法与 Chat Template 速查

Transformers 直接调用示例（原文示例保留）：

import transformers

tokenizer = transformers.AutoTokenizer.from_pretrained("deepseek-ai/DeepSeek-V3.1")

messages = [
    {"role": "system", "content": "You are a helpful assistant"},
    {"role": "user", "content": "Who are you?"},
    {"role": "assistant", "content": "<think>Hmm</think>I am DeepSeek"},
    {"role": "user", "content": "1+1=?"}
]

tokenizer.apply_chat_template(messages, tokenize=False, thinking=True, add_generation_prompt=True)
# '<｜begin▁of▁sentence｜>You are a helpful assistant<｜User｜>Who are you?<｜Assistant｜></think>I am DeepSeek<｜end▁of▁sentence｜><｜User｜>1+1=?<｜Assistant｜><think>'

tokenizer.apply_chat_template(messages, tokenize=False, thinking=False, add_generation_prompt=True)
# '<｜begin▁of▁sentence｜>You are a helpful assistant<｜User｜>Who are you?<｜Assistant｜></think>I am DeepSeek<｜end▁of▁sentence｜><｜User｜>1+1=?<｜Assistant｜></think>'

要点提示：

• ​​thinking=True/False​​ 直接切换混合思维模式；
• 模板里 ​​<think>​​​ 与 ​​</think>​​ 是触发/标记信号；
• 多轮对话会在上下文中**保留 ​​</think>​​**，保持推理可追踪。（辅关键词：混合思维模式、长上下文）

ToolCall 基础格式（原文节选保留）：

<｜tool▁calls▁begin｜><｜tool▁call▁begin｜>tool_call_name<｜tool▁sep｜>tool_call_arguments<｜tool▁call▁end｜>{{additional_tool_calls}}<｜tool▁calls▁end｜>

实践建议：

• 强约束 JSON：提前用 Schema 校验参数，防止“半结构化”导致流水线中断；
• 幂等与重试：网络/外部 API 不可控，给代理链路加重试 + 超时 + 兜底；
• 安全与审计：代码代理/搜索代理建议全链路日志留档，对企业合规非常关键。（辅关键词：工具调用、代码代理）

8、业务落地怎么选：三条实用路线

1）检索与问答一体化（Non-Thinking 为主）适合在线客服、知识库、SOP 问答。Non-Thinking 输出更快；需要时再局部切换 Thinking 处理“疑难问答”。（辅关键词：混合思维模式、长上下文）

2）研发效能与数据工程（Thinking + Code Agent）面向代码生成—执行—调试闭环，结合 SWE-bench 这类代理评测的表现，选择 Thinking 做复杂改动，再交由 CI 执行验证。适合单测修复、脚手架生成、日志分析。（辅关键词：代码代理、工具调用）

3）研究与分析工作台（Search Agent + 长上下文）财经研报、技术情报、合规审查等场景，把搜索代理接入后，配上128K 上下文进行多源整合、证据链梳理。对于“从数据到结论”的流程，是生产力级别的升级。（辅关键词：搜索代理、长上下文）

9、你可能关心的几个细节

• V3.1 与 V3 的关系：结构兼容，V3.1-Base在 V3 基础上通过两阶段长上下文扩展继续训练，数据量级显著增加（32K：630B；128K：209B）。（辅关键词：长上下文、MoE 架构）
• 模型下载与版本：DeepSeek-V3.1-Base / DeepSeek-V3.1两个权重可用，总参数 671B、激活 37B、上下文 128K。
• 本地部署：建议先在推理服务层做模式路由与调用速率治理，再考虑更重的Agent 链路与数据治理；否则容易把“会做事”的模型，拖进“会卡住”的系统。（辅关键词：工具调用、代码代理）

10、一句话结论

DeepSeek-V3.1 把“能深度思考”与“能快速响应”同时放进一个开源、可商用的包里。对于正在寻找“高质量 + 低成本 + 好落地”组合拳的团队，这是一个非常务实的选择。（辅关键词：混合思维模式、MoE 架构、工具调用）

本文转载自​​Halo咯咯​​    作者：基咯咯