技術架構

Dify 的技術強項：RAG 知識庫、工作流編排與為什麼它比較吃資源

Dify 是本站資源需求最高的服務之一（2GB 記憶體、2 核 CPU）。本文說明它的架構為什麼需要這些資源，以及 RAG 知識庫與工作流編排實際解決的問題。

A

Admin

Dify 在 RoamerHost 的方案是 NT$1,599／月，是價格帶較高的服務。這篇文章說明為什麼——不是因為軟體本身收費（Dify 是開源的），而是因為它的架構確實需要那些資源。

Dify 實際上是一組服務，不是單一應用

一個完整的 Dify 部署包含 API 服務、背景工作程序、向量資料庫、關聯式資料庫與快取層。跟 n8n 那種「單一 Node.js 程序」的架構相比，這是完全不同的量級。

這直接反映在方案規格上：

10 GB 的儲存空間主要是給知識庫用的——文件原檔、切塊後的文字、以及向量索引都要存。

直接把公司文件貼進 ChatGPT 的對話框有兩個硬限制：內容長度受限於上下文視窗，而且每次對話都要重貼。

RAG（檢索增強生成）的做法是：先把文件切成小塊、轉成向量存進資料庫；使用者提問時，先用問題去檢索最相關的幾個片段，再把這些片段連同問題一起送給模型。

這樣做的實際好處是知識庫大小不受上下文視窗限制——你可以放進幾百份文件，因為每次只有最相關的片段會被送進模型。附帶的好處是成本：送進模型的 token 少很多。

要留意的是，RAG 的品質高度取決於切塊策略。文件切得太碎會失去上下文、切得太大則檢索精度下降。Dify 的介面讓你可以調整切塊參數並實測效果，這是它比自己寫 RAG 管線省事的地方。

Dify 不只是做聊天介面。它的工作流編排讓你把「呼叫模型」變成流程中的一個節點，前後可以接條件判斷、資料處理、外部 API 呼叫。

實務上這代表你可以做出「先判斷使用者意圖 → 分流到不同的處理邏輯 → 查詢內部系統 → 用模型組織成回覆」這種多步驟的應用，而不是單純的一問一答。

這點要講清楚：Dify 是應用開發平台，不含模型本身。你需要自己準備 OpenAI、Anthropic 或其他供應商的 API Key，模型的呼叫費用由你直接付給模型供應商。

好處是你完全掌控用哪個模型、花多少錢，也可以隨時換供應商；壞處是初次設定多一個步驟。

完成訂閱後 60 秒,系統自動幫你裝好 Dify——獨立容器、資源硬性上限不與他人共用、HTTPS 開箱即用。

月付訂閱、不綁約、隨時取消