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 權杖的美元價格，輸入／輸出。

有兩種不同的東西都稱為「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，即可直接確認。