DeepSeek V4 Pro (0813):思考回传与三接口矩阵

本文介绍 deepseek-v4-pro-0813 的使用要点和常见陷阱。在 AIHubMix 上,该模型可通过 Chat Completions、Responses 以及兼容 Claude 的 Messages API 调用。另请参阅:DeepSeek 官方 API 文档。

各章节中标注"已验证"的结论和示例响应,均来自 2026-08-13 通过 AIHubMix 接口(Chat Completions / Responses / Messages)的实际调用;未标注"已验证"的规格条目来自 DeepSeek 官方文档。

1. 模型定位与规格速览

V4 Pro 是 DeepSeek V4 系列的高端版本(轻量版 deepseek-v4-flash 是它的兄弟型号)。该系列可追溯到 2026-04-24 发布的 DeepSeek-V4 Preview,而 0813 是 DeepSeek 为当前版本分配的 MODEL VERSION 标识。除原始规格外,它有四个突出特点:

• 稀疏化的前沿模型:总参数 1.6T,激活参数 49B(采用 MoE,即混合专家架构,每次推理只激活部分专家网络:总参数决定知识容量,激活参数决定单次调用的计算成本)。模型卡列出了 CSA+HCA 混合注意力、mHC 以及 Muon 优化器。
• 采用 MIT 许可的开放权重:deepseek-ai/DeepSeek-V4-Pro 以 MIT 许可证发布在 HuggingFace 上(这是最宽松的开源许可之一,允许商业使用和闭源再分发),可以自行部署。对于这种规模的模型来说,采用 MIT 许可并不常见。模型卡中的自部署说明还建议,在 Think Max(最高思考档位)下运行时,上下文窗口应不小于 384K tokens。这是面向自部署的部署建议,并非托管 API 的规格。
• 多协议支持是原生提供的,而非第三方转译:DeepSeek 本身提供 OpenAI Chat API、兼容 Anthropic 的端点(/anthropic,会将 claude-opus* 映射到该模型),以及 Responses API(DeepSeek 称其原生支持该格式,并针对 Codex 做了适配)。它还在单独的端点上以 Beta 形式提供 FIM(fill-in-the-middle,中间填充)补全,这不属于 AIHubMix 的三个接口。
• 缓存命中与未命中价格相差约 120 倍:DeepSeek 公布的定价机制为缓存命中 $0.003625/M,缓存未命中 $0.435/M(输出 $0.87/M),且缓存是自动生效的,无需设置任何参数。对于会复用长前缀(系统提示词、长文档)的工作负载,这一差距将主导账单。实际零售价格以模型页面显示为准。

已验证:超出 max_tokens 会被参数校验拒绝,而不是静默截断。发送 max_tokens=9999999 会返回 HTTP 400,错误信息会指出该字段并给出上限 393216。

# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"

❗ 图片不会报错,但会被丢弃:Responses API 的官方表述为"Image and file inputs are not supported (input_image parts do not cause an error, but are replaced with a placeholder text)"。也就是说,input_image 部件不会导致请求失败,而是被替换为占位文本。在 Chat Completions 中,用户消息的 content 只接受字符串;在 Messages 中,type="image" 块被标记为不支持。在搭建多模态路由时,切勿把"没有报错"当作模型确实看到了图片的证据。

2. 如何关闭思考?三个接口,三种字段形式

V4 Pro 默认开启思考:不传任何参数,响应中就会返回思考内容。要关闭思考,三个接口各自使用不同的字段形式。

Chat Completions

使用顶层的 thinking 对象。

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent

已验证:设置 thinking.type="disabled" 后,message.reasoning_content 和 usage.completion_tokens_details.reasoning_tokens 会同时消失,这证实开关已生效。

Responses

Responses 没有单独的开关;关闭思考即将档位设置为 none。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item

已验证:reasoning.effort="none" 与默认档位在响应中有明显差异(思考 token 降为零,reasoning 输出项消失),这证实设置已生效。

Messages

名称和形式与 Chat Completions 相同:顶层的 thinking 对象。

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]

已验证:关闭后,thinking 块会完全消失,只保留 text 块。

关于思考档位:测试中,low 和 max 在 Chat Completions 上都返回了 200(省略该字段时使用默认的 high)。但对于同一问题,各档位的思考 token 数并不呈单调变化(简单问题:low=43 / max=27;困难问题:low=114 / max=92),而且响应中也不会回显任何档位信息。也就是说,档位参数会被接受,但从响应中观察不到任何可区分的信号。在 Responses 上,只能从响应端确认 none 档位(关闭思考)的效果。

3. 为什么多轮对话突然返回 400?思考历史必须原样回传

这是该模型最常见的一个陷阱:在思考模式下,多轮对话必须将上一轮的思考内容原样回传,否则请求会被拒绝。这不是质量下降,而是直接的 HTTP 400。

三个接口以不同的字段名承载同一份思考内容:

已验证(触发条件):该校验在携带 tools 的多轮请求中稳定触发(模型发出工具调用,随后将工具结果发回)。在没有工具、模型直接作答的普通多轮请求中,本轮测试未触发该校验,请求返回 200。换言之,工具编排(智能体 / 函数调用类工作负载)是最容易遇到该问题的场景,因此应将思考内容视为需要持久化并重放的会话状态的一部分。

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error

已验证:历史 assistant 消息若缺少 reasoning_content,会返回 400;补上该字段后,完全相同的请求返回 200,并能正常继续对话。

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400

已验证:只需原样将 response.output 拼接回去即可。在组装历史时按 type == "message" 过滤输出项,会丢弃 reasoning 项并触发 400,这是最常见的踩坑方式。

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking block -> HTTP 400

已验证:从 content 数组中删除 thinking 块会返回 400(其中 error.type 为 invalid_request_error)。

4. 工具调用

每个接口都使用自己的协议格式声明工具,这些格式彼此不可互换。

Chat Completions

嵌套格式(function 对象包裹 name / parameters)。指定函数名的 tool_choice 可强制调用。

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}

❗ 已验证:思考开启时不能使用 tool_choice: "required"。它会返回 400,提示 Thinking mode does not support this tool_choice;关闭思考(thinking.type="disabled")后,完全相同的请求返回 200。如果需要"必须调用工具"的语义,请改用指定函数名的 tool_choice(如上例所示,开启思考时同样可用),或先关闭思考,再使用 required。

Responses

扁平格式(type / name / parameters 位于同一层级)。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["reasoning", "function_call"]; arguments = {"city": "Paris"}

已验证:将 Chat Completions 的嵌套格式(function: {...})照搬到 Responses 中会返回 400,应使用扁平格式。tool_choice: "required" 同样受到与 Chat 相同的思考模式限制。

Messages

Anthropic 原生格式(input_schema),并可使用 tool_choice: {"type": "any"} 强制调用。

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}

❗ 并行工具调用无法关闭,这是 DeepSeek 自身的设计:官方 Anthropic 兼容页面在 tool_choice 一行中说明 disable_parallel_tool_use is ignored,Responses 页面同样写明 parallel_tool_calls | Ignored (parallel tool calling is always enabled)。测试结果一致:询问两个城市的情况并设置 disable_parallel_tool_use: true,仍会返回两个 tool_use 块。如果需要串行执行,请只取第一个调用,或在客户端自行排队。

工具数量与上下文成本：在单次请求中发送 200 个函数定义，仍返回 200 和正常回答，也没有触发任何数量校验（仅在该路径上观察到；未测试更多数量）。但该请求的 prompt_tokens 达到 6,105，工具定义会完整进入上下文并计费。工具较多时，应按场景裁剪工具集，而不是无条件声明全部工具。

5. 结构化输出

Chat Completions

response_format 支持 JSON 模式。

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}

已验证：输出是有效的 JSON。

Responses

通过 text.format 声明 JSON Schema，支持 strict 模式。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"a":1}

已验证：输出严格符合给定的 Schema。

Messages

Messages（Anthropic）协议没有与 response_format / text.format 等价的字段。常见的变通方法是把 Schema 放在工具中：声明一个 input_schema 为目标 Schema 的工具，设置 tool_choice: {"type": "any"}，然后从 tool_use 块的 input 中读取结构化结果。本轮测试没有专门验证这种模式；如果需要严格的 Schema 保证，请优先选择 Chat Completions 或 Responses。

6. 如何启用上下文缓存？无需启用，它是自动的

上下文缓存（相同前缀会被复用，缓存部分按较低费率计费）默认开启，无需任何参数。第二次使用相同长前缀的请求会在 usage 中报告命中情况，字段名因 API 而异。有关缓存细节和当前定价，请参阅 模型页面；有关跨模型的缓存策略和命中率技巧，请参阅提示词缓存实践。

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0

已验证：在同一通道上连续发出两次相同长前缀的调用，cached_tokens 从 0 变为 640。

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896

已验证：上述前缀由一个内容完全相同的 Responses 请求预热，第一次 Messages 调用随即命中 896 个 token，这与缓存以内容前缀为键、并在各协议接口之间共享的特点一致。

7. logprobs：Chat 返回两个通道

logprobs（对数概率，即模型对每个候选 token 的置信度细节）在两个 API 上的返回结构不同，解析代码需要分别处理。

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text

❗ 已验证：Chat 对 content 和 reasoning_content 都会返回对数概率。如果代码只读取 logprobs.content（即标准 OpenAI 响应结构），它不会报错，但会静默漏掉思考通道；如果代码假设 logprobs 下只有一个数组，请先加入结构检查。

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details

已验证：Responses 只在最终文本条目上附带 logprobs，没有 Chat 上那种双通道结构。

Messages

Messages（Anthropic）协议没有对应字段。如需 token 级别的概率细节，请使用 Chat Completions 或 Responses。

8. 哪些 API 可以联网搜索？

这里的联网搜索是服务端工具（检索在服务器上执行，客户端不会自行发出请求），测试中它在 Responses 和 Messages API 上都确实执行了。

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["reasoning", "web_search_call", "reasoning", "message"]

已验证：输出序列中出现了 web_search_call 条目，这说明服务器确实执行了一次检索。

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1

已验证：usage.server_tool_use.web_search_requests 计数为 1，说明检索请求确实发生并被计量。

Chat Completions

在 Chat 上无法触发联网搜索。DeepSeek 官方 Chat API 参考文档的请求结构中没有任何搜索工具字段（这一结论是逐项核对字段列表后得出的；DeepSeek 并未明确声明不支持）。官方明确表示支持服务端搜索的 API 是 Responses（web_search），官方 Messages 兼容性页面也列出了与搜索相关的内容块。

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A

已验证：发送 web_search_options 或 enable_search 不会报错，但也不会进行任何检索——响应中不包含 annotations（联网搜索执行时附在响应上的引用列表），且 usage 与对照组逐字段一致。如需联网访问，请使用 Responses 或 Messages API。

9. 使用注意事项：DeepSeek 的设计与我们路径上的偏差

以下所有情况都返回 HTTP 200，但行为与直觉相反。原因各不相同，应对方式也不同，因此分为两组列出：第一组是 DeepSeek 对模型的设计，更换服务商也不会改变；第二组是 AIHubMix 路径上的当前行为，我们正在处理。

9.1 由 DeepSeek 设计决定

9.2 AIHubMix 路径上的当前行为

9.3 DeepSeek 未作定义，因此无法判定对错

为 reasoning_effort 发送枚举范围之外的值（例如 bogus_xyz），会返回 200 和正常回答，没有错误，也没有可观察的效果。事实本身很清楚：该路径目前不校验 reasoning_effort 枚举。不清楚的是它是否应该校验：DeepSeek 公布了合法枚举，但从未说明非法级别是否应当被拒绝，因此没有可供比对的基准，这意味着它既不能算作官方行为，也不能算作我们路径上的缺陷。稳妥的做法是在客户端自行校验级别，不要指望 API 来拦截。

10. 能力 × API 支持矩阵

下表各单元格给出了每个 API 中对应的参数 / 字段写法。除标注为 DeepSeek 明确说明的内容外，所有结论均来自 2026-08-13 对 AIHubMix 生产 API 的实际调用。

图例:✅ 已验证可用 · 🟡 接受该参数但无法确认是否生效 · ❗ 需要注意(见上文说明)· ➖ 该 API 不存在此概念

常见问题

deepseek-v4-pro-0813 在 AIHubMix 上支持哪些 API?
支持 Chat Completions(/v1/chat/completions)、Responses(/v1/responses)以及兼容 Claude 的 Messages API(/v1/messages)。

为什么多轮对话突然返回 400?
最常见的原因是没有回传思考历史。在思考模式下,上一轮的思考内容必须原样重放:Chat 需在 assistant 消息上附带 reasoning_content,Responses 需附带 type="reasoning" 的输出项,Messages 需附带 thinking 内容块。带工具的多轮对话最容易出问题——许多框架在组装历史时按 type == "message" 过滤输出项,从而丢掉了 reasoning 项。

能否关闭思考?
可以。在 Chat 或 Messages 上发送 thinking: {"type": "disabled"},在 Responses 上发送 reasoning: {"effort": "none"}。关闭后,思考内容和思考 token 都会消失。

三个 reasoning_effort 档位有区别吗?
low / high / max 均可接受(默认 high;为兼容起见,medium 和 xhigh 会映射为 high)。测试中,同一问题在不同档位下的思考 token 数没有单调差异,且不会回传任何信息,因此无法从调用方确认其差异。只有 Responses 上的 none 档位(关闭思考)会产生明显可观察的差别。

为什么 tool_choice: "required" 返回 400?
开启思考时不接受该值(错误信息为 Thinking mode does not support this tool_choice)。若要在开启思考时强制调用特定函数,请使用指定函数名的 tool_choice({"type": "function", "function": {"name": "..."}});或者先关闭思考,再使用 required。

如何启用上下文缓存?
无需启用,缓存是自动的。将稳定不变的内容(系统提示词、知识片段、工具定义)放在请求的最前面,命中数会在 usage 中返回:Chat 为 prompt_tokens_details.cached_tokens,Responses 为 input_tokens_details.cached_tokens,Messages 为 cache_read_input_tokens。

定价和实时状态请参阅 deepseek-v4-pro-0813 模型页面;更多模型请访问 模型库。

相关实操指南:Kimi K3 实操指南(新参数及三种 API 支持矩阵)和 GPT-5.6 提示词缓存与计费变更。