文档中心

Appearance

✨费用中心控制台

使用 DeepSeek 的 thinking 参数 ​

DeepSeek 推理请求可以使用 thinking.type 控制当前轮是否思考，并可使用 reasoning_effort 表达推理强度要求。本文主要面向 OpenAI-compatible Chat Completions 路径上的 deepseek-v4-pro 和 deepseek-v4-flash；如果使用 Anthropic Messages 路径，或使用 deepseek-v3.2 系列，请以目标模型和协议的实际返回为准。工具调用场景还需要保留模型返回的推理字段。

设置当前请求的 thinking.type ​

当前请求需要思考时，设置 thinking.type: "enabled"。简单请求或延迟敏感请求可以测试关闭思考后的效果。以下 Python 示例使用 OpenAI SDK。

language-python
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["API_KEY"],
    base_url="https://cloud.infini-ai.com/maas/v1",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "What is 2 + 2? Give only the final answer."}],
    max_tokens=256,
    extra_body={"thinking": {"type": "enabled"}},
)

关闭思考时使用：

language-python
extra_body = {"thinking": {"type": "disabled"}}

如果目标模型是专用推理模型，关闭参数可能不是常规支持路径。deepseek-r1 这类强推理模型不要把关闭思考作为可靠业务路径；上线前用目标模型验证一次。

在 GenStudio 中，DeepSeek V4 的 OpenAI-compatible 路径优先使用 thinking.type。enable_thinking 只能作为兼容参数在目标模型验证后使用，不应替代模型系列原生参数。

用 curl 验证 thinking.type 请求体 ​

先用 curl 确认请求体中已经传入 DeepSeek 的 thinking.type。运行前先在当前终端设置 API_KEY 环境变量。以下 curl 命令适用于 bash/zsh 等 POSIX 风格 Shell（macOS/Linux、WSL、Git Bash）。如果使用 Windows PowerShell 或 CMD，请按对应 Shell 的语法调整命令。

language-shell
curl --request POST \
  --url "https://cloud.infini-ai.com/maas/v1/chat/completions" \
  --header "Accept: application/json, text/event-stream" \
  --header "Authorization: Bearer $API_KEY" \
  --header "Content-Type: application/json" \
  --data-raw '{
    "model": "deepseek-v4-pro",
    "messages": [
      {
        "role": "user",
        "content": "What is 2 + 2? Give only the final answer."
      }
    ],
    "max_tokens": 256,
    "thinking": {
      "type": "enabled"
    }
  }'

终端录制

用 curl 验证 DeepSeek thinking.type

在演示库中打开

适用于验证 DeepSeek 推理开关字段是否按预期传入。

设置 reasoning_effort 前衡量效果 ​

需要让模型投入更多推理时，可以在支持的模型上设置 reasoning_effort。DeepSeek V4 的 OpenAI-compatible 路径建议使用 high 或 max。如果当前请求已经设置 thinking.type: "disabled"，不要同时发送 reasoning_effort。该参数是否改变质量、延迟和 token 用量，需要用业务 prompt 验证。

language-python
extra_body = {
    "thinking": {"type": "enabled"},
    "reasoning_effort": "high",
}

不要只因为请求被接受就假设推理强度一定发生了业务可见变化。记录延迟、输出 token 和任务质量后再决定默认值。

读取 DeepSeek 的 reasoning_content ​

DeepSeek 推理内容通常位于 reasoning_content。读取时兼容字段缺失。

language-python
message = response.choices[0].message
reasoning = getattr(message, "reasoning_content", None)

if reasoning:
    print(reasoning)
print(message.content)

流式响应中读取 delta.reasoning_content，并跳过空 choices。

普通多轮只回传用户可见回答 ​

普通多轮对话只需要延续用户可见回答时，可以回传 assistant 的 content。不要为了让历史看起来完整而人工写入 reasoning_content。

如果业务需要审计或展示推理内容，可以在应用侧保存它；是否把它继续传给模型，应按工具调用和目标模型要求决定。

工具调用后保留 reasoning_content ​

当 assistant 消息发起工具调用且返回了 reasoning_content，继续请求时保留该字段。

language-python
assistant_message = {
    "role": "assistant",
    "content": response.choices[0].message.content or "",
    "tool_calls": [
        {
            "id": tool_call.id,
            "type": "function",
            "function": {
                "name": tool_call.function.name,
                "arguments": tool_call.function.arguments,
            },
        }
        for tool_call in response.choices[0].message.tool_calls
    ],
}

reasoning = getattr(response.choices[0].message, "reasoning_content", None)
if reasoning:
    assistant_message["reasoning_content"] = reasoning

messages.append(assistant_message)

如果 SDK 或框架序列化时丢掉扩展字段，工具调用后的下一次请求可能无法保持原有上下文。

如果某次工具调用响应本来就没有返回 reasoning_content，保留这个缺失状态即可；不要补写空字符串、摘要或人工生成的推理内容。对 DeepSeek V4，后续请求仍应保留真实的 tool_calls、tool_call_id 和工具结果。

分开排查采样参数和推理参数 ​

推理请求没有按预期变化时，先把采样调参和推理调参分开验证。

  • 先只保留 thinking 和 reasoning_effort，确认请求被接受。
  • 再逐一加入 temperature、top_p 等采样参数。
  • 如果模型文档说明某些采样参数会被忽略或不兼容，以模型文档和实际请求结果为准。

不要在同一个排查请求里同时修改 prompt、采样参数和推理参数，否则很难定位是哪一项导致行为变化。