---

上周三帮团队把 Dify 的底层模型从 qwen3.6-plus 升级到 qwen3.7-plus，本以为改个 model ID 就完事，结果 thinking_budget 参数的行为跟 3.6 版本有两处不一样——一处是默认值变了，另一处是流式模式下仅传 thinking_budget=0 不足以关闭推理，还需额外传 enable_thinking: false（非流式模式不受此影响）。记录一下完整流程和对比结论，供有类似需求的读者参考。

核心结论：qwen3.7-plus（model ID：qwen3.7-plus）接入 Dify 自定义模型，改 3 个地方就能跑——base_url、model name、credentials。但如果想精确控制推理成本，thinking_budget 这个参数需要搞清楚：写 0 是关闭推理，不传则默认开启推理（thinking token 也会计费）。具体单价以 DashScope 官网定价 为准，本文不列固定数字，避免价格调整后产生误导。

---

这篇适合谁

• 正在用 Dify 搭 AI 应用，想把底层模型换成 qwen3.7-plus 的
• 之前用 qwen3.6-plus 或 qwen-plus-latest，升级后发现 thinking_budget 行为变了的
• 想在 Dify 里精细控制推理成本（关闭/开启/设预算梯度）的
• 用 OpenAI 兼容协议接 DashScope，但不确定 extra_body 怎么在 Dify model_config 里写的

---

整体流程

1. 获取 DashScope API Key（阿里云百炼平台）
2. 在 Dify 后台添加自定义模型供应商
3. 填写 model_config JSON（重点：thinking_budget 配置）
4. 测试调用，验证 thinking 模式开关是否生效
5. 根据业务场景选择合适的 budget 值

graph LR
 A[阿里云百炼<br>获取 API Key] --> B[Dify 后台<br>添加自定义供应商]
 B --> C[填写 model_config<br>含 thinking_budget]
 C --> D[测试调用<br>验证输出]
 D --> E{需要推理?}
 E -->|是| F[设 budget 1024~16384]
 E -->|否| G[设 budget=0]

---

先说结论

以下行为描述基于 qwen3.7-plus 实测，不代表 qwen3.6-plus 的行为（两者差异见后文"与 qwen3.6-plus 的两处差异"一节）。output 计费单价以 DashScope 官网 当前公示价格为准。

配置方式	thinking_budget 值	实际行为	计费模式	适用场景
不传该字段	模型默认（实测约 4096，非官方文档值）	开启推理，消耗 thinking token	thinking 价格档	复杂推理、代码生成
设为 0	0	关闭推理，无 reasoning_content	non-thinking 价格档	简单问答、翻译、摘要
设为 1024~2048	低预算	轻度推理，快速响应	thinking 价格档	日常对话、轻度分析
设为 8192~16384	高预算	深度推理，响应较慢	thinking 价格档	数学证明、复杂逻辑

---

第一步：获取 DashScope API Key

去阿里云百炼控制台，开通 DashScope 服务，在「API Key 管理」页面创建一个 Key。注意不要把这里的 Key 与阿里云主账号的 AccessKey 混淆，两者是不同的凭证体系。

拿到的 Key 格式如下（sk- 开头）：

sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

---

第二步：Dify 添加自定义模型供应商

进 Dify 后台 → 设置 → 模型供应商 → 添加自定义模型。供应商类型选「OpenAI API 兼容」，填入以下信息：

{
  "model_name": "qwen3.7-plus",
  "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
  "api_key": "sk-你的DashScope密钥"
}

model_name 这里建议写具体版本号 qwen3.7-plus，而非 qwen-plus-latest。qwen-plus-latest 是别名，会随官方更新自动指向最新版本，生产环境中可能在无感知的情况下发生模型切换，影响输出稳定性。

---

第三步：配置 thinking_budget（重点）

Dify 的自定义模型支持在 model_config 里传 extra parameters，thinking_budget 通过这个机制传入。

关闭推理模式的完整配置：

{
  "model": "qwen3.7-plus",
  "extra_body": {
    "thinking_budget": 0
  }
}

开启推理、设定预算的配置：

{
  "model": "qwen3.7-plus",
  "extra_body": {
    "thinking_budget": 4096
  }
}

注意：thinking_budget 必须是整数，传浮点数（如 2048.0）或字符串（如 "2048"）会触发参数校验错误，错误信息大致为（以下为示意性描述，实际返回文本以 DashScope 接口为准）：

InvalidParameter: thinking_budget must be a non-negative integer

---

第四步：验证输出差异

用同一个 prompt「请推导贝叶斯公式」分别测试两种配置，输出差异明显：

• thinking_budget=0：直接返回结果，响应体中无 reasoning_content 字段，响应时间约 1.2 秒。
• thinking_budget=4096：响应里多了 choices[0].message.reasoning_content，其中包含模型的推理过程，正式回答在 content 字段。响应时间约 3.8 秒。

Python 验证示例：

from openai import OpenAI

client = OpenAI(
    api_key="sk-你的key",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)

关闭推理的调用：

resp = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=[{"role": "user", "content": "今天星期几？"}],
    extra_body={"thinking_budget": 0}
)
print(resp.choices[0].message.content)

开启推理的调用：

resp = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=[{"role": "user", "content": "证明根号2是无理数"}],
    extra_body={"thinking_budget": 8192}
)
print("思考：", resp.choices[0].message.reasoning_content)
print("回答：", resp.choices[0].message.content)

---

与 qwen3.6-plus 的两处差异

以下差异均为作者对比日志后的实测观察，非官方文档说明，供参考。

差异一：默认 budget 值变了。
qwen3.6-plus 不传 thinking_budget 时，实测默认推理预算约为 2048 token；qwen3.7-plus 实测默认值约为 4096 token（均为实测推断值，非官方文档数据）。直观感受是升级后不改配置，响应会慢一点，但推理质量有所提升。

差异二：流式模式下 budget=0 的行为。
qwen3.6-plus 流式模式下传 thinking_budget=0 即可关闭推理。但 qwen3.7-plus 流式模式下，仅传 thinking_budget=0 可能仍会输出部分 thinking token，需同时传 enable_thinking: false 才能完全关闭。非流式模式不受影响，thinking_budget=0 单独使用即可。

说明：enable_thinking 参数与 thinking_budget 的交互行为为作者实测结论，建议在接入前查阅 DashScope 官方文档 确认当前参数规范，以官方文档为准。

流式关闭推理的写法：

stream = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=[{"role": "user", "content": "翻译这段话"}],
    stream=True,
    extra_body={"thinking_budget": 0, "enable_thinking": False}
)

---

通过聚合网关接入（可选路径）

如果 Dify 部署在海外，或团队同时使用多家模型需要统一管理，可以考虑走 API 聚合网关。OpenRouter、ofox.io 等平台支持 OpenAI 兼容协议转发到 DashScope。通过聚合网关接入时，只需将 base_url 改为网关地址：

client = OpenAI(
    api_key="你的网关key",
    base_url="https://api.ofox.io/v1"
)

其他参数（model、extra_body、thinking_budget）写法完全一样。实测通过此类网关调用时，extra_body 中的 thinking_budget 和 enable_thinking 参数均可正常透传，reasoning_content 也能正常返回。

---

不同场景的配置建议

场景	thinking_budget 建议	理由
客服机器人 / FAQ	0（关闭）	简单检索式回答，无需推理
文档翻译 / 摘要	0 或 1024	翻译任务不依赖深度推理
代码生成 / Debug	4096~8192	需要逻辑推理，但无需极深预算
数学证明 / 复杂分析	8192~16384	复杂任务受益于更大推理空间
RAG 知识库问答	1024~2048	检索到内容后轻度整合即可

成本粗算示例（价格以官网为准，以下仅为推算逻辑示意）：

假设 non-thinking output 单价为 P₀，thinking output 单价为 P₁，每天处理 50 万 output token：

1. 仅计正式 output 的价差：50万 × (P₁ - P₀) / 1M
2. 若 thinking token 额外占正式 output 的 30%，则实际计费 output 增加至 50万 × 1.3 = 65万 token，总差价变为 65万 × (P₁ - P₀) / 1M，约为步骤 1 结果的 1.3 倍

以 DashScope 某时期公示价格（non-thinking $1.2/M、thinking $1.6/M，仅供逻辑演示，请以官网当前价格为准）代入：步骤 1 约 $0.20（≈ ¥1.4），步骤 2 约 $0.26（≈ ¥1.8）。一个月累计差价约 ¥42~¥54。简单场景关闭推理，成本节省效果明显。

---

踩坑记录 / 报错对照表

报错信息（示意）	原因	解法
401 Unauthorized - invalid api key	Key 填错或未激活	去百炼控制台确认 Key 状态
thinking_budget must be a non-negative integer	传了浮点数或字符串	改成 int 类型，如 2048
thinking_budget value is out of range	传了负数或超过上限（上限值以官方文档为准）	传入 0 或合理正整数
429 Too Many Requests	并发超限或免费额度用完	降低并发 / 充值 / 换 Key
Connection error - Failed to connect	网络不通或 URL 写错	检查 base_url 拼写，确认网络连通
响应里没有 reasoning_content	budget=0 或模型不支持	确认 budget>0 且 model 为 qwen3.7-plus

表中报错文本为示意性描述，实际返回内容以 DashScope 接口响应为准。

---

常见问题 FAQ

Q: thinking_budget=0 和完全不传 thinking_budget 有什么区别？

区别明显。thinking_budget=0 明确告知模型不进行推理，响应体中不会出现 reasoning_content，按 non-thinking 价格档计费。不传则使用模型默认值（qwen3.7-plus 实测约 4096，非官方文档数据），会产生 thinking token，按 thinking 价格档计费。具体单价以 DashScope 官网为准。

Q: Dify 里怎么传 extra_body 参数？

在 Dify 的自定义模型配置里，找到「模型参数」或「高级设置」区域，将 extra_body 作为 JSON 对象填入。不同版本的 Dify UI 位置可能略有差异，但底层均通过 OpenAI SDK 的 extra_body 机制传递。

Q: qwen3.7-plus 和 qwen-plus-latest 到底用哪个？

qwen-plus-latest 是别名，会自动指向当前最新的 qwen-plus 系列版本。如需稳定性（如生产环境），建议写死 qwen3.7-plus，避免官方静默升级导致输出风格或参数行为发生变化。

Q: 思考过程（reasoning_content）的 token 怎么计费？

thinking token 按 thinking 价格档计费。也就是说，如果模型推理消耗了 2000 token、正式回答消耗了 500 token，计费基数是 2500 token，均按 thinking 单价计算。简单任务关闭推理可以有效避免这部分额外开销。

Q: 设了 thinking_budget=8192 但实际思考只用了 1200 token，会按 8192 收费吗？

不会。thinking_budget 是上限，不是固定消耗。实际计费按真实产生的 token 数计算，未用完的预算不收费。

Q: 通过 ofox.io 等聚合网关调用时，thinking_budget 参数还能正常工作吗？

实测可以正常工作。聚合网关透传 extra_body 参数，不会修改 thinking_budget 或 enable_thinking 的值，reasoning_content 也能正常返回。

---

小结

qwen3.7-plus 接入 Dify 本身流程不复杂，主要需要花时间理清的是 thinking_budget 的行为——尤其是与 qwen3.6-plus 的两处差异，以及流式与非流式模式下的不同表现。建议生产环境默认关闭推理（budget=0），仅在明确需要深度推理的场景单独开启并设合理上限，兼顾成本控制与输出质量。