推理模型

推理模型针对需要多步问题求解而非快速直接文本生成的复杂任务进行了优化。它们特别适用于数学、代码分析、规划、逻辑推导、结构化决策，以及模型在生成最终答案之前需要通过中间步骤进行思考的任务。

与通用文本模型相比，推理模型通常以延迟换取更强的逐步问题求解能力和在困难指令上的更好表现。

何时使用推理模型

当您的任务涉及以下情况时，请使用推理模型：

多步数学或符号推理
代码调试、代码生成或代码解释
复杂规划和决策支持
需要中间步骤的长篇分析
必须在步骤之间思考的工具使用智能体

对于简单的摘要、改写或聊天任务，标准文本模型通常更快、更经济。

推理输出如何工作

许多推理模型返回两种不同的输出：

content：向用户展示的最终答案
reasoning_content：模型的推理内容或思考过程

在 OpenAI 兼容响应中，reasoning_content 通常与 content 一起在助手消息中返回。某些模型可能仅对支持的模型系列公开推理内容，某些模型可能将部分推理内容直接包含在 content 中。

示例响应结构：

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "The answer is 925.",
        "reasoning_content": "25 multiplied by 37 can be computed as..."
      }
    }
  ]
}

基本用法

您可以通过与文本模型相同的 OpenAI 兼容 /chat/completions API 来调用推理模型。

curl 'https://api.luchentech.com/inference/v1/chat/completions' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <your_token_here>' \
  --data '{
    "model": "minimax/minimax-m2.5",
    "messages": [
      {
        "role": "user",
        "content": "Solve this step by step: If a train travels at 60 mph for 2.5 hours, how far does it go?"
      }
    ],
    "max_tokens": 1024
  }'

从以下位置读取最终答案：

choices[0].message.content

如果所选模型支持公开推理内容，您还可以读取：

choices[0].message.reasoning_content

流式推理输出

流式输出对于推理模型尤其有用，因为它们的输出可能比标准聊天模型更长、更慢才能完成。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.luchentech.com/inference/v1",
)

stream = client.chat.completions.create(
    model="minimax/minimax-m2.5",
    messages=[
        {
            "role": "user",
            "content": "Solve this carefully: what is the square root of 144, and why?"
        }
    ],
    stream=True,
    max_tokens=1024,
)

reasoning_parts = []
answer_parts = []

for chunk in stream:
    if not chunk.choices:
        continue
    delta = chunk.choices[0].delta
    if delta.reasoning_content:
        reasoning_parts.append(delta.reasoning_content)
    if delta.content:
        answer_parts.append(delta.content)

print("Reasoning:", "".join(reasoning_parts))
print("Answer:", "".join(answer_parts))

流式输出时，推理模型可能会在不同的数据块中分别发送 reasoning_content 和最终答案内容。

多轮对话

推理模型可以像文本模型一样在正常的多轮对话流程中使用：

{
  "model": "minimax/minimax-m2.5",
  "messages": [
    {
      "role": "user",
      "content": "A company has revenue of $3.2M and expenses of $2.4M. What is the profit margin?"
    },
    {
      "role": "assistant",
      "content": "The profit is $0.8M. Profit margin is profit divided by revenue, so the margin is 25%."
    },
    {
      "role": "user",
      "content": "Now explain that in plain English for a non-finance audience."
    }
  ]
}

在标准对话使用中，通常只需要保留可见的助手 content，除非特定模型或工作流需要保留推理状态。

推理与工具调用

对于更高级的智能体，某些推理模型支持跨工具调用的交替思考。在这些流程中，模型可能会推理、调用工具、接收工具输出，然后在生成最终答案之前继续推理。

在支持此行为的模型系列中，跨助手轮次保留之前的 reasoning_content 可以改善逐步工具使用。这在以下情况尤其重要：

助手在一个任务中重复调用工具
模型必须对中间工具输出进行推理
您正在构建多步智能体工作流

如果您为下一轮手动重建助手消息，请在模型和 SDK 支持时包含 reasoning_content。

传递回后续请求的助手消息示例：

{
  "role": "assistant",
  "content": "Let me calculate that.",
  "reasoning_content": "I should use the calculator tool for this arithmetic operation.",
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "calculator",
        "arguments": "{\"operation\":\"add\",\"a\":15,\"b\":27}"
      }
    }
  ]
}

如果所选模型不支持保留推理状态，包含此字段通常会被忽略而不会造成损害。

仅当所选模型明确支持时才使用这些控制。

推理模型的提示词技巧

推理模型通常在提示词清晰且以目标为导向时表现最佳。

直接说明任务并包含期望的结果
需要时要求以特定格式给出最终答案
对于数学或逻辑任务，说明您想要简洁答案还是详细解答
对于编码任务，包含语言、运行时或框架等约束
避免不必要的风格指令，除非它们对任务很重要

示例：

{
  "role": "user",
  "content": "Analyze this Python function for time complexity and suggest a more efficient implementation."
}

对于某些推理模型系列，更简单的提示词比层层叠加的系统指令效果更好。

参数建议

推理模型通常比创意聊天模型更适合保守的采样设置。

一个合理的起始点是：

{
  "temperature": 0.6,
  "top_p": 0.95,
  "max_tokens": 2048
}

如果模型开始重复自身或产生不稳定的推理：

降低 temperature
保持适中的 top_p
如果最终答案被截断，增加 max_tokens
对于长生成使用流式输出

上下文与 Token 预算

对于推理模型，总上下文使用量通常包括：

用户输入
对话历史
内部推理 Token
最终答案 Token

这意味着长提示词加上长推理内容可能会快速消耗上下文。

最佳实践：

为推理和最终输出预留足够空间
避免将 max_tokens 设置为等于模型完整上下文长度
当旧的对话轮次不再需要时进行裁剪
在多轮会话中存储长推理内容时要小心

最佳实践

仅在受益于深度思考的任务上使用推理模型
对于复杂或长时间运行的请求，优先使用流式输出
在开发期间检查 reasoning_content 以调试模型行为
除非您的产品明确需要推理内容，否则仅向最终用户展示最终答案
在自动化工作流中使用输出之前进行验证
在真实任务而非仅合成基准上测试提示词

常见问题

输出被截断

这通常是因为：

max_tokens 太小
总上下文太大
非流式请求在长推理运行中超时

尝试增加 max_tokens、缩短输入并启用流式输出。

模型速度慢

推理模型通常比标准文本模型慢，因为它们在中间思考上花费更多 Token。

尝试：

使用较小的推理模型
在支持时减少推理预算
对更简单的任务切换到标准文本模型

模型产生不稳定或重复的推理

尝试：

降低 temperature
使用适中的 top_p
简化提示词
避免过多或冲突的指令

何时使用推理模型​

推理输出如何工作​

基本用法​

流式推理输出​

多轮对话​

推理与工具调用​

推理模型的提示词技巧​

参数建议​

上下文与 Token 预算​

最佳实践​

常见问题​

输出被截断​

模型速度慢​

模型产生不稳定或重复的推理​

相关指南​