n8n 本地 AI：用你自己的微調模型替換 OpenAI

你的 n8n 工作流程運行良好。你構建了分類電子郵件、從發票中提取資料、評分潛在客戶和起草後續消息的自動化——所有這些都由可靠提供高質量結果的 OpenAI 節點提供支持。

但是那些 AI 節點中的每一個都是一個持續的費用。每次執行都燃燒 token。每個 token 都出現在你的每月帳單上。隨著你的自動化規模擴大——更多工作流程、更多客戶、更多容量——那個帳單同步增長。

如果你可以完全免費地在本地運行完全相同質量的 AI 呢？

這正是本教程逐步引導你的內容。到最後，你將有一個在 Ollama 上運行的微調模型，連接到你的 n8n 工作流程，產生與 OpenAI 相同質量的輸出——每次執行費用為零。

不需要 ML 背景。不需要 Python 腳本。只是從「每個 token 付費給 OpenAI」到「本地運行你自己的模型」的具體步驟。

我們在構建什麼

以下是最終狀態：

┌──────────────────────────────────────────┐
│              n8n 工作流程                  │
│                                           │
│  觸發器 → 處理 → [AI 節點] → 動作          │
│                        │                  │
│                        ▼                  │
│              HTTP 請求節點                │
│         POST localhost:11434/api/chat     │
└──────────────────┬───────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────┐
│            Ollama 服務器                  │
│                                           │
│  ┌─────────────────────────────────────┐ │
│  │  你的微調模型（GGUF）                 │ │
│  │  在你的工作流程資料上訓練             │ │
│  │  在 CPU 上運行——不需要 GPU           │ │
│  └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘

你的 n8n 工作流程像以前一樣觸發。HTTP 請求節點不是 OpenAI 節點發送請求到 api.openai.com（並消耗 token），而是將相同的提示發送到在你的本地機器或 VPS 上運行的 Ollama。Ollama 運行你的微調模型並返回結果。相同格式。相同質量。零 API 費用。

關鍵洞察：你的微調模型在你現有 OpenAI 工作流程的確切輸入/輸出對上訓練。 它不需要知道 GPT-4 知道的一切。它只需要複製你的工作流程所依賴的特定行為。

前提條件

在開始之前，確保你有：

• 運行的 n8n 實例 — 自托管或 n8n cloud。本教程假設你有帶有 OpenAI 節點的現有工作流程。
• 安裝了 Ollama — 在你的 n8n 服務器、附近的 VPS 或你的本地機器上。安裝：curl -fsSL https://ollama.com/install.sh | sh
• Ertas 帳戶 — 用於在不需要代碼的情況下微調你的模型。在 ertas.io 註冊（$14.50/月）。
• 工作流程執行歷史 — 你要轉換的工作流程至少有 200 次成功執行。越多越好。

Ollama 的硬體需求：

帶有 Q4 量化的 7B 參數模型使用大約 4-5GB 的 RAM。如果你的 n8n 服務器有 16GB 以上的 RAM，你可以在同一台機器上與 n8n 一起運行 Ollama，不會有問題。

第一步：導出你的 OpenAI 訓練資料

你現有的工作流程在每次執行時都在生成訓練資料。每次執行都包含發送到 OpenAI 的輸入和返回的輸出。這正是我們微調模型所需要的。

確定目標工作流程

選擇你想要首先轉換的工作流程。理想的候選者是：

• 高容量 — 每天運行 50 次以上（最大費用節省）
• 任務範圍窄 — 分類、提取或模板化生成（最容易微調）
• 質量一致 — OpenAI 輸出可靠地好（乾淨的訓練資料）

提取輸入/輸出對

方法 1：從 n8n UI 手動提取

1. 在 n8n 中打開目標工作流程
2. 點擊側欄中的「執行」
3. 過濾「成功」狀態
4. 點擊進入每次執行並找到 OpenAI 節點
5. 記錄輸入（發送到 OpenAI 的消息數組）和輸出（回應內容）
6. 格式化為 JSONL：

{"input": "分類這封電子郵件：您好，我想取消我的訂閱...", "output": "cancellation"}
{"input": "分類這封電子郵件：我的訂單何時到達？", "output": "shipping_inquiry"}
{"input": "分類這封電子郵件：產品 2 天後壞了...", "output": "defect_report"}

這對於收集 50-100 個範例有效，但對於更大的資料集會變得乏味。

方法 2：通過 n8n API 自動提取

創建一個單獨的 n8n 工作流程，以程序方式提取執行資料：

1. 添加一個HTTP 請求節點呼叫 n8n API：

   • URL：http://localhost:5678/api/v1/executions?workflowId=YOUR_WORKFLOW_ID&status=success&limit=500
   • 在標頭中添加你的 n8n API 密鑰

2. 添加一個代碼節點來提取和格式化 AI 節點資料：

const executions = $input.all();
const trainingData = [];

for (const exec of executions) {
  const nodes = exec.json.data?.resultData?.runData;
  if (nodes && nodes['OpenAI']) {
    const openaiNode = nodes['OpenAI'][0];
    const input = openaiNode.data?.main?.[0]?.[0]?.json?.messages;
    const output = openaiNode.data?.main?.[0]?.[0]?.json?.choices?.[0]?.message?.content;

    if (input && output) {
      const userMessage = input.find(m => m.role === 'user')?.content || '';
      trainingData.push({
        input: userMessage,
        output: output
      });
    }
  }
}

return [{ json: { trainingData, count: trainingData.length } }];

3. 添加一個寫文件節點將輸出保存為 JSONL 文件。

方法 3：前瞻性資料收集

如果你還沒有足夠的執行歷史，在你的當前工作流程中添加一個日誌記錄步驟。在你的 OpenAI 節點後插入一個代碼節點，將每個輸入/輸出對附加到文件或資料庫。運行 1-2 週直到你有 300 個以上的範例。

你需要多少資料？

以「最佳」列為目標。你在最低限度時會得到好的結果，但最佳給你一個更好地處理邊緣案例的模型。

清理你的資料

上傳之前，做一個快速質量審查：

• 刪除失敗的輸出。 如果 OpenAI 返回錯誤或無意義的回應，刪除那個對。
• 刪除重複項。 精確重複的輸入/輸出對沒有幫助。保留一個副本。
• 檢查一致性。 如果類似的輸入產生截然不同的輸出，調查一下。你的模型將學習平均值——不一致的訓練資料產生不一致的輸出。
• 標準化格式。 確保所有輸出遵循相同的格式（例如，所有分類標籤是小寫，所有 JSON 輸出使用相同的模式）。

第二步：使用 Ertas 微調你的模型

現在你有了乾淨的資料集。是時候把它變成一個模型了。

上傳你的資料

1. 登錄 Ertas Studio，網址 app.ertas.io
2. 創建一個新專案（以你的工作流程命名，例如「電子郵件分類器」或「發票提取器」）
3. 點擊「上傳資料集」並拖入你的 JSONL 文件
4. Ertas 驗證文件並顯示預覽——驗證幾個範例看起來正確

選擇你的基礎模型

對於 n8n 自動化任務，這些是推薦的選擇：

我們對大多數 n8n 工作流程的推薦：Qwen 2.5 7B。 它非常擅長處理結構化任務，並產生乾淨、一致的輸出——正是自動化工作流程所需要的。

配置訓練

Ertas 根據你的資料集自動配置訓練參數：

• LoRA rank： 根據任務複雜性自動選擇（自動化任務通常為 16-32）
• 學習率： 針對你的資料集大小進行優化
• 訓練輪次： 自動化資料集通常為 3-5 輪
• 驗證分割： 你的資料的 10% 被保留用於評估

你可以根據需要調整這些，但默認值針對自動化用例進行了調整，開箱即用效果很好。

開始訓練

點擊「開始訓練」。根據你的資料集大小：

• 200-500 個範例：約 15-20 分鐘
• 500-1,000 個範例：約 25-35 分鐘
• 1,000 個以上範例：約 35-50 分鐘

你可以實時觀察訓練損失曲線。對於自動化任務，你通常會看到損失在第一輪急劇下降並在第 3 輪趨於穩定。

評估結果

訓練完成後，Ertas 顯示你：

• 準確率指標： 對於分類任務，你會得到按類別細分的精確率、召回率和 F1 分數。
• 並排比較： 你的微調模型對測試範例的輸出 vs. 原始 GPT-4 輸出。
• 樣本預測： 通過模型運行任何輸入並立即查看輸出。

要注意的事項：

• 分類準確率超過 90%（對於定義明確的類別）
• 提取完整性（所有字段都被捕獲）
• 生成質量（讀起來自然，匹配預期格式）

如果質量不在你需要的地方，最常見的修復是：

1. 添加更多訓練範例（特別是對於表現不佳的類別）
2. 清理不一致的訓練對
3. 增加 LoRA rank（從 16 到 32）

第三步：導出為 GGUF 並加載到 Ollama

從 Ertas 導出

1. 在你的 Ertas 專案中，點擊「導出模型」
2. 選擇 GGUF 格式
3. 選擇 Q4_K_M 量化——這是 7B 模型質量和文件大小之間的最佳平衡：

Q4_K_M 以 Q8 60% 的文件大小提供約 99% 的質量。對於輸出短且結構化的自動化任務，質量差異可以忽略不計。

4. 下載 GGUF 文件。它將被命名為類似 email-classifier-q4km.gguf。

加載到 Ollama

將 GGUF 文件傳輸到你的服務器（運行 Ollama 的機器）：

scp email-classifier-q4km.gguf user@your-server:/home/user/models/

創建一個Modelfile，告訴 Ollama 如何服務你的模型：

FROM /home/user/models/email-classifier-q4km.gguf

PARAMETER temperature 0.1
PARAMETER num_ctx 4096
PARAMETER stop "<|im_end|>"

關鍵參數：

• temperature 0.1 — 低溫度用於一致、確定性的輸出。對自動化任務至關重要。
• num_ctx 4096 — 上下文窗口大小。如果你的輸入更長，請增加。
• 停止 token — 取決於你的基礎模型。Qwen 使用 im_end token，Llama 使用序列結束 token。

在 Ollama 中創建模型：

ollama create email-classifier -f Modelfile

測試它：

ollama run email-classifier "分類這封電子郵件：你好，我需要更改訂單 #4521 的收貨地址。"

你應該得到類似 shipping_inquiry 的回應——匹配你的工作流程期望的格式。

驗證 API 端點

Ollama 默認在端口 11434 上提供 REST API。用 curl 測試它：

curl http://localhost:11434/api/chat -d '{
  "model": "email-classifier",
  "messages": [
    {
      "role": "system",
      "content": "將以下電子郵件分類為以下類別之一：cancellation, shipping_inquiry, defect_report, billing_question, general_inquiry"
    },
    {
      "role": "user",
      "content": "你好，我的上一個訂單被收費兩次。"
    }
  ],
  "stream": false
}'

預期回應：

{
  "model": "email-classifier",
  "message": {
    "role": "assistant",
    "content": "billing_question"
  }
}

如果這有效，你就可以將它連接到 n8n 了。

第四步：在 n8n 中創建 Ollama 節點

現在是實際的工作流程更改。打開你要轉換的 n8n 工作流程。

選項 A：替換為 HTTP 請求節點（推薦）

這給你完全控制請求，並適用於任何 n8n 版本。

1. 禁用 OpenAI 節點（暫時不要刪除它——你需要它進行比較測試）

2. 在 OpenAI 節點所在的位置添加一個 HTTP 請求節點

3. 配置 HTTP 請求節點：

方法： POST

URL： http://localhost:11434/api/chat

（如果 Ollama 在不同的服務器上，使用那個服務器的 IP 而不是 localhost）

標頭：

• Content-Type：application/json

Body（JSON）：

{
  "model": "email-classifier",
  "messages": [
    {
      "role": "system",
      "content": "將以下電子郵件分類為以下類別之一：cancellation, shipping_inquiry, defect_report, billing_question, general_inquiry"
    },
    {
      "role": "user",
      "content": "={{ $json.email_body }}"
    }
  ],
  "stream": false,
  "options": {
    "temperature": 0.1
  }
}

將 $json.email_body 替換為任何引用你工作流程中前一個節點的輸入資料的表達式。

4. 在 HTTP 請求後添加一個代碼節點以提取回應：

const response = $input.first().json;
const result = response.message?.content?.trim() || response.response?.trim() || '';

return [{
  json: {
    classification: result,
    model: response.model,
    raw_response: response
  }
}];

5. 連接代碼節點的輸出到你工作流程中接下來的任何東西（OpenAI 節點連接到的同一個節點）。

選項 B：使用 OpenAI 兼容端點

Ollama 還在 /v1/chat/completions 提供 OpenAI 兼容 API。如果你的 n8n 版本有允許更改基礎 URL 的 OpenAI 節點，你可以：

1. 打開 OpenAI 節點設置
2. 將基礎 URL 更改為 http://localhost:11434/v1
3. 將模型設置為 email-classifier
4. 刪除 API 密鑰（或設置任何虛擬值——Ollama 不需要）

這種方法需要更少的工作流程更改，但取決於你的 n8n 版本在 OpenAI 節點中支持自定義基礎 URL。

選項 C：原生 Ollama 節點

最近的 n8n 版本（1.20+）在 AI 節點部分包含原生 Ollama 集成。如果可用：

1. 添加 Ollama 聊天模型節點
2. 設置基礎 URL 為 http://localhost:11434
3. 選擇你的模型名稱
4. 將其連接到你的工作流程

這是最簡單的選項，但給你最少的請求參數控制。

第五步：測試和比較

在正式上線之前，進行適當的比較測試。

A/B 測試你的工作流程

1. 在你的工作流程中同時保留 OpenAI 節點和 Ollama 節點
2. 在它們之前添加一個Switch節點，將 50% 的執行發送到每個節點
3. 在每個之後添加日誌記錄節點以捕獲輸出
4. 通過分割運行 100 次以上真實執行

比較輸出

收集比較資料後，評估：

對於分類任務：

對於分類，微調模型通常比 GPT-4 更一致，因為它專門在你的類別上訓練，不會表現出通用模型具有的創意變化。

對於提取任務：

微調模型傾向於產生更一致的輸出格式，因為它們通過訓練學習了你的特定模式，而不是通過提示遵循模式指令。

對於生成任務：

生成任務最主觀。讓 20-30 個輸出通過人工審閱者，並在 1-5 的比例上評分質量和適當性。

效能基準

以下是在 $30/月 VPS（4 vCPU，16GB RAM）上使用微調 Qwen 2.5 7B 模型的常見 n8n 自動化任務的真實世界效能資料：

批次工作流程的吞吐量優勢很顯著。如果你有一個每天早上處理 500 封電子郵件的工作流程，OpenAI 版本需要 12-25 分鐘（受速率限制）。本地版本在 25-50 秒內完成。

常見問題故障排除

模型太慢

症狀： 簡單任務的回應需要 5 秒以上。

修復：

• 檢查 VPS CPU 使用率——如果它在 100% 滿負荷，你需要更多 vCPU 或更強大的機器
• 使用 Q4_K_M 量化而不是 Q8——一半的記憶體，快 30%
• 如果你的輸入很短，減少 num_ctx——2048 上下文窗口比 4096 更快
• 確保沒有其他資源密集型進程在同一服務器上運行

與 OpenAI 相比質量下降

症狀： 輸出明顯比 GPT-4 產生的差。

修復：

• 更多訓練資料。 最常見的修復。從 200 個增加到 500 個以上範例。
• 更乾淨的訓練資料。 刪除 OpenAI 輸出錯誤或不一致的任何範例。
• 更具代表性的資料。 如果某些類別或輸入類型代表性不足，專門為那些添加更多範例。
• 更高的 LoRA rank。 如果你使用了 rank 8 或 16，試試 32。這給模型更多學習你的任務的能力。
• 嘗試不同的基礎模型。 如果 Mistral 7B 不夠用，試試 Qwen 2.5 7B 或 Llama 3.3 8B。不同的基礎模型有不同的優勢。

上下文長度錯誤

症狀： 模型在較長輸入上返回垃圾或錯誤。

修復：

• 在你的 Modelfile 中增加 num_ctx（例如，從 4096 到 8192）
• 注意：更大的上下文使用更多 RAM。帶有 8K 上下文的 7B 模型需要約 6GB RAM。
• 如果你的輸入定期超過 4K token，考慮在發送到模型之前截斷或摘要輸入
• 對於非常長的輸入（8K 以上 token），考慮兩階段方法：先摘要，然後從摘要中分類/提取

Ollama 沒有回應

症狀： n8n 收到連接被拒絕或超時錯誤。

修復：

• 驗證 Ollama 正在運行：systemctl status ollama 或 ollama list
• 檢查端口：curl http://localhost:11434/api/tags 應該返回 JSON 回應
• 如果 n8n 在不同的機器上，確保 Ollama 綁定到 0.0.0.0：在 Ollama 環境配置中設置 OLLAMA_HOST=0.0.0.0
• 檢查防火牆規則：端口 11434 必須可從 n8n 機器訪問
• 檢查 RAM：如果服務器耗盡記憶體，Ollama 可能已崩潰。dmesg | grep -i oom 將顯示記憶體不足的終止。

輸出格式不一致

症狀： 模型有時返回 "billing_question"，有時返回 "Billing Question" 或 "The category is billing_question."

修復：

• 在 n8n 中添加後處理步驟（代碼節點）以標準化輸出：小寫、修剪空白、去除前綴
• 改進訓練資料一致性——確保所有訓練範例使用完全相同的格式
• 將溫度降低到 0.05（幾乎確定性）
• 添加明確指定輸出格式的系統提示

正式上線

一旦你驗證了質量並解決了任何問題：

1. 刪除 A/B 分割 — 將 100% 的流量路由到本地模型
2. 保持 OpenAI 節點禁用（不刪除）作為第一週的後備
3. 監控 7 天 — 每天檢查輸出，比較錯誤率
4. 7 天後： 如果一切看起來不錯，刪除 OpenAI 節點並從 n8n 憑證中刪除 API 密鑰
5. 設置重新訓練計劃 — 每 4-8 週導出新的執行資料並在擴展的資料集上重新訓練模型

你的 n8n 工作流程現在以零 API 費用運行。每次執行都是免費的。擴展到 10 倍的容量，你的帳單保持完全相同：Ertas $14.50 加 VPS $30。

每月 $44.50 用於無限 AI 自動化。沒有 token。沒有速率限制。沒有意外發票。

---

延伸閱讀

• n8n 到微調模型的機構行動手冊 — 機構如何將本地 AI 為其 n8n 自動化客戶產品化
• 為你的應用微調模型 — 任何應用的微調通用指南，不只是 n8n
• GGUF 格式解析 — 關於 GGUF 格式以及為什麼它對本地部署很重要的一切