Dify 在 RoamerHost 的方案是 NT$1,599／月，是價格帶較高的服務。這篇文章說明為什麼——不是因為軟體本身收費（Dify 是開源的），而是因為它的架構確實需要那些資源。
30 秒總覽
| 項目 | 內容 |
|---|---|
| 為什麼比較吃資源 | 多容器架構，不是單一應用 |
| 模型推論在哪跑 | 不在你的機器上，在供應商那邊 |
| 你的實例負責什麼 | 編排、檢索、知識庫管理 |
| 最重的一步 | 文件解析與建立索引 |
| 自架的門檻 | 要管一整組容器，不是一個 |
Dify 實際上是一組服務，不是單一應用
一個完整的 Dify 部署包含 API 服務、背景工作程序、向量資料庫、關聯式資料庫與快取層。跟 n8n 那種「單一 Node.js 程序」的架構相比，這是完全不同的量級。
這直接反映在方案規格上：
| 項目 | Dify | 對照：n8n |
|---|---|---|
| CPU | 2 核 | 1 核 |
| 儲存空間 | 10 GB | 2 GB |
| 費用 | NT$1,599／月 | 平均每月 NT$499（年繳） |
10 GB 的儲存空間主要是給知識庫用的——文件原檔、切塊後的文字、以及向量索引都要存。
RAG 知識庫解決什麼問題
直接把公司文件貼進 ChatGPT 的對話框有兩個硬限制：內容長度受限於上下文視窗，而且每次對話都要重貼。
RAG（檢索增強生成）的做法是：先把文件切成小塊、轉成向量存進資料庫；使用者提問時，先用問題去檢索最相關的幾個片段，再把這些片段連同問題一起送給模型。
這樣做的實際好處是知識庫大小不受上下文視窗限制——你可以放進幾百份文件，因為每次只有最相關的片段會被送進模型。附帶的好處是成本：送進模型的 token 少很多。
要留意的是，RAG 的品質高度取決於切塊策略。文件切得太碎會失去上下文、切得太大則檢索精度下降。Dify 的介面讓你可以調整切塊參數並實測效果，這是它比自己寫 RAG 管線省事的地方。
工作流編排：比純聊天機器人多一層
Dify 不只是做聊天介面。它的工作流編排讓你把「呼叫模型」變成流程中的一個節點，前後可以接條件判斷、資料處理、外部 API 呼叫。
實務上這代表你可以做出「先判斷使用者意圖 → 分流到不同的處理邏輯 → 查詢內部系統 → 用模型組織成回覆」這種多步驟的應用，而不是單純的一問一答。
你需要自己準備模型 API Key
這點要講清楚：Dify 是應用開發平台，不含模型本身。你需要自己準備 OpenAI、Anthropic 或其他供應商的 API Key，模型的呼叫費用由你直接付給模型供應商。
好處是你完全掌控用哪個模型、花多少錢，也可以隨時換供應商；壞處是初次設定多一個步驟。
託管把哪一部分拿走了
這個架構的複雜度不會因為託管而消失，只是換人承擔。實際被拿走的是四件事：
- 元件之間的版本相容——升級時哪些要一起升
- 資源分配——哪個容器該給多少記憶體
- 備份的完整性——資料庫、向量索引、原始檔案要一起備
- 出事時的判斷——症狀都是「怪怪的」，要知道從哪查起
第四項是最花時間的，也最難用金額估算。那不是一次性的學習成本，是每次出事都要重來一遍的東西。
它到底由哪些部分組成
理解這個，就知道為什麼自架的維運成本比一般應用高：
| 元件 | 負責什麼 | 掛掉會怎樣 |
|---|---|---|
| API 服務 | 核心邏輯 | 整個服務不能用 |
| Worker | 背景工作（文件解析、建索引） | 上傳一直卡在處理中 |
| 前端 | 介面 | 打不開，但 API 還活著 |
| 關聯式資料庫 | 應用設定、對話紀錄 | 資料不見 |
| 快取 | 工作佇列與暫存 | 背景工作卡住 |
| 向量資料庫 | 知識庫的檢索索引 | 知識庫失效 |
重點在最後一欄：任何一個元件出問題，症狀都會表現成「Dify 怪怪的」，而你要自己判斷是哪一個。這才是自架的真實成本——不是安裝的那幾小時，是往後每次出事的排查時間。
一個常見的誤解
「AI 很吃 CPU，所以要買大一點的方案。」
實際上你串的是外部模型，推論全部在對方的伺服器上跑。你的實例只負責把問題整理好送出去、把回答接回來。這部分幾乎不吃你的運算資源，吃的是你的 API 帳單。
所以「回答很慢」加 vCPU 一點用都沒有——那是模型的回應時間。真正吃資源的是哪些，在 資源邊界那篇。
常見問題
Q：為什麼不能像 n8n 一樣單一容器？
因為它要做的事本質上是多個角色：即時回應請求、背景處理文件、儲存結構化資料、儲存向量索引。硬塞進一個容器會讓其中一項拖累其他項。
Q：託管版跟自架的架構一樣嗎？
元件組成一樣，差別在誰負責維護與監控這些元件。
Q：向量資料庫是什麼？
存放知識庫索引的地方。文件被切段之後，每一段會產生一組代表語意的數字，檢索時就是在這裡面找最接近的。它壞掉的症狀是「知識庫明明有資料但撈不到」。
Q：資料存在哪些地方？
應用設定與對話紀錄在關聯式資料庫，知識庫的索引在向量資料庫，原始檔案另外存。備份要涵蓋全部，只備份其中一個是不完整的。
Q：升級會影響資料嗎？
版本更新有時伴隨資料結構變更。自架的話升級前務必備份，並先看官方的版本更新紀錄有沒有破壞性變更。
這篇的實際用途
你不需要記住六個容器的名字。這篇真正該帶走的只有兩件事：
一、Dify 比你想的複雜，所以自架的成本主要在維運不在安裝。看到「一鍵部署」的教學不代表往後就沒事了。
二、出問題時先分辨是哪一層——模型的、檢索的、還是元件的。三種的解法完全不同，排查順序在常見錯誤排除。
資料來源與延伸連結
Dify 的功能與介面會隨版本調整，實際操作前建議對照官方文件：
- Dify 官方文件
- Dify 版本更新紀錄——功能異動以此為準
- Dify 原始碼與 Issue 追蹤
延伸閱讀
想找人幫你做？
這些流程要是不想自己搭，或是規模大到需要有人一起規劃，浪花科技（RoamerHost 的母公司）承接企業流程自動化與 AI Agent 的委託開發：
Dify
