Dify

一个必填字段 — OpenAI-API-compatible 插件 Add Model 表单中的 API Base URL — 可将 Dify 工作区中的所有 LLM 节点指向 Kunavo。

# Integrations → Model Provider → OpenAI-API-compatible → Add Model
Type                          LLM
Model Name                    claude-sonnet-5
Model display name            Kunavo · Claude Sonnet 5
API Key                       sk-kn-...
API Base URL                  https://api.kunavo.com/v1
model name for API endpoint   (leave blank — Model Name is already the id)
Completion mode               Chat
Model context size            1000000
Upper bound for max tokens    (your own ceiling for one reply)
Function Call Type            Tool Call     # defaults to no_call
Vision Support                Support       # only if you will send images
Structured Output             Support       # defaults to not supported

# Model context size is per model, not per endpoint: 1000000 is
# claude-sonnet-5's. The table below carries the rest.

分步操作

1. 在 /app/keys 创建密钥并复制——它只会显示一次。
2. 在 Dify 中，打开 Integrations → Model Provider，浏览 Install model providers（或 Marketplace）并安装由 langgenius 发布的 OpenAI-API-compatible。Dify 文档指出，只有工作区所有者和管理员可以管理服务商。
3. 在该服务商卡片上点击 Add Model。该插件没有预定义模型——它是一个 customizable-model 服务商——因此，每个要使用的 ID 都需要单独添加。
4. 按照上面的说明填写表单。Type = LLM，Model Name = 完全照填 Kunavo ID，API Key = 你的 sk-kn- 密钥，API Base URL = https://api.kunavo.com/v1，Completion mode = Chat，Model context size = 下表中的值。然后设置 Function Call Type，如有需要，再设置 Structured Output 和 Vision Support。保存。
5. 打开工作流，在需要使用该模型的节点上选择它——Dify 按节点而非按应用分配模型，因此分类器和最终撰写节点可以使用不同的 ID 和不同的价格。未选择模型的应用和节点会回退到 Default Models → System Reasoning Model。
6. 运行一个范围明确的工作流，然后在 Kunavo 账户中查看费用，而不是在 Dify 中查看——请参阅下方关于费用显示的说明。

已于 2026年9月21日 对照 Dify 的 OpenAI-API-compatible 插件页面 检查。第三方设置会发生变化；如果这里的字段名称不再与你看到的内容一致，应以该页面为准，而不是本页。

调试客户端前先验证

一个请求即可确定故障来自端点、密钥还是配置文件。如果返回 JSON，则相同的基础 URL 和密钥可以在 Dify 中使用。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

字段中应填写哪个模型 ID

每个文本模型都可通过模型 ID 访问——实时列表见 GET /v1/models，包含价格的目录见模型页面。费率单位为每 1M token 的美元，格式为输入 / 输出。

“Dify API”指的是两种不同的东西

本页讲的是其中一种，而搜索结果总是把它们混在一起。

1. 将模型接入 Dify — 上方设置区块所介绍的操作。Dify 是客户端，Kunavo 是端点，你粘贴的是 sk-kn- 密钥。随后，该工作区中每个应用的每个 LLM 节点都可以调用你添加的模型 ID。
2. 通过自己的代码调用 Dify 应用 — Dify 为已发布应用提供的 Service API，使用 Dify 自行签发的 app- 密钥。该密钥属于 Dify，不属于我们，也无法将它指向其他地方。Kunavo 不参与这种调用方向。

同一个应用通常会同时运行这两种调用：你的后端使用 Dify 密钥调用 Dify 应用，而应用中的节点使用 Kunavo 密钥调用 Kunavo。两把密钥、两笔账单；发生 401 错误时，也有两个地方需要排查。

为什么 Dify 不显示所添加模型的费用

Dify 第一方预定义模型文件包含定价区块，其中列出输入和输出费率以及每个 token 的计价单位；Dify 会将 token 数量乘以费率，在日志中显示费用。OpenAI-API-compatible 提供商架构中没有声明价格、单位或货币字段；截至上方所示日期核查时，确实如此。因此，通过此插件添加模型后，Dify 没有可用于计算的费率。费用栏并不是你找到的折扣，也不是你引入的错误，而是一个并不存在的字段。请从 Kunavo 的使用情况中查看实际费用，并将 Dify 的数字视为 token 数量。

还有一个相关开关最好保持原样：Include Usage in Stream 默认启用，会要求端点在流式输出的最后一个数据块中返回提示词和补全 token 数量。关闭它也会导致你无法获取这些 token 数量。

如果你自行托管 Dify

Docker Compose 堆栈会通过 ssrf_proxy 服务转发出站请求，因此必须能从容器网络内部访问该端点；仅能从笔记本电脑上的浏览器访问还不够。一种配置在一处能用、在另一处超时，通常就是这个原因。这属于网络问题，而不是凭据问题。在容器内部运行上方的 curl，即可直接确认。