n8n + Ollama + 微調模型：零 API 費用的自動化堆疊

如果你用 n8n 構建自動化，你可能已經注意到隨著使用量增長，OpenAI API 費用是如何累積的。文件分類、資料提取、電子郵件分類——這些任務都需要 AI，但它們也是重複的、可預測的，以及在你有足夠資料時可以微調的。

本指南展示了一個三部分堆疊：n8n 用於工作流程協調，Ollama 用於本地 LLM 服務，以及用於你的特定任務的微調適配器。結果是一個在你的硬體上運行的自動化堆疊，按每個請求計算費用為零。

為什麼這個堆疊有效

n8n 的原生 AI 節點連接到 OpenAI API。切換到本地模型只需要將該 API 端點重定向到本地運行的 Ollama 實例。Ollama 公開了一個與 OpenAI API 格式兼容的 REST API，所以交換相對簡單。

微調部分是乘法因子。通用的 Llama 3.1 8B 對分類或資料提取任務的準確率可能達到 70-75%。在你的特定任務資料上微調的相同模型通常達到 88-95%。你以零邊際費用獲得更高的準確率。

權衡是什麼：

• 需要本地 GPU 硬體（最少 8GB VRAM 用於 7-8B 模型）
• 微調需要前期時間
• 模型更新需要管理（你不再自動獲得 GPT-4o 的最新版本）

對於以可預測工作負載運行大量 AI 自動化的機構或企業，節省往往在幾個月內超過設置成本。

設置 Ollama 本地端點

在 n8n 服務器可訪問的機器上安裝 Ollama：

# 在 Linux 上
curl -fsSL https://ollama.ai/install.sh | sh

# 下拉基礎模型
ollama pull llama3.1:8b

# 驗證 API 正在運行
curl http://localhost:11434/api/tags

對於多個 n8n 工作流程並發訪問 Ollama，配置它以監聽網絡接口而不僅僅是 localhost：

# 在 /etc/systemd/system/ollama.service 中（Linux）
Environment="OLLAMA_HOST=0.0.0.0:11434"

Ollama 的 API 格式與 OpenAI 的 v1/completions 端點兼容。這意味著任何 HTTP 節點都可以直接呼叫它。

在 n8n 中配置 HTTP 請求節點

在 n8n 中，不要使用 OpenAI 節點，而是使用 HTTP 請求節點：

節點配置：

• 方法：POST
• URL：http://your-ollama-host:11434/api/generate
• 認證：無（或添加基本認證如果你在反向代理後面添加了它）
• 內容類型：JSON

請求體：

{
  "model": "llama3.1:8b",
  "prompt": "{{ $json.your_input_field }}",
  "stream": false,
  "options": {
    "temperature": 0.1,
    "num_predict": 500
  }
}

低溫度（0.1）對分類和提取任務的重要性： 高溫度增加創意性——這對摘要有用，但對你需要一致標籤或結構化輸出的任務有害。對於資料提取或分類，使用 0.0-0.2。

解析回應： Ollama 返回 { "response": "..." } 對象。在你的工作流程中使用表達式 {{ $json.response }} 提取文字。

用微調模型替換通用模型

這是堆疊從「能用」變成「真正好用」的地方。

識別要微調的工作流程任務：

不是所有 n8n AI 任務都值得微調。優先考慮：

• 高容量任務（每天 1,000+ 次運行）
• 有清晰正確/錯誤答案的任務（分類、提取、結構化格式化）
• 重複使用相同輸入模式的任務

對於創意或開放式任務（電子郵件起草、內容生成），通用模型通常就足夠了。

收集訓練資料：

查看你的 n8n 執行日誌。如果你已經在使用 OpenAI 進行分類，你有現有的輸入/輸出對。導出它們：

# 從 n8n PostgreSQL 資料庫（如果使用 pg 後端）
SELECT
  data->>'input_text' as input,
  data->>'classification' as output
FROM execution_data
WHERE workflow_id = 'your-workflow-id'
AND status = 'success'
LIMIT 2000;

理想情況下你有 500-3,000 個範例。更多更好，但你可以從更少開始。

在 Ertas Studio 中訓練：

1. 將輸入/輸出對格式化為 JSONL（指令-回應格式）
2. 上傳到 Ertas Vault
3. 在 Llama 3.1 8B 上運行 LoRA 微調（通常 30-60 分鐘用於 1,000-2,000 個範例）
4. 將適配器導出為 GGUF 格式
5. 通過 Ollama 加載模型：

# 創建 Modelfile
cat > Modelfile << EOF
FROM llama3.1:8b
ADAPTER /path/to/your-adapter.gguf
SYSTEM "你是專門分類進入客戶支持票券的 AI 助手。"
EOF

# 創建模型
ollama create your-classifier-v1 -f Modelfile

# 測試它
ollama run your-classifier-v1 "分類這個支持請求：..."

費用比較

以客戶支持票券分類工作流程為例，每天 5,000 個票券：

硬體費用：RTX 4090 大約 $1,800。假設 3 年使用壽命，每年 $600。即使費用節省不大，隱私和延遲改進也值得。對於更大的工作量，節省要大得多。

注意：費用數字是說明性的——實際費用因使用量、模型和 API 定價變化而異。

管理多個微調模型

當你為不同工作流程構建多個適配器時，你需要追蹤哪個版本做什麼：

Ollama 命名慣例：

# 使用清晰的版本名稱
ollama create support-classifier-v2 -f Modelfile
ollama create invoice-extractor-v1 -f Modelfile
ollama create email-triage-v3 -f Modelfile

# 列出所有模型
ollama list

在 n8n 中，使用工作流程級別的變量存儲模型名稱：

在工作流程設置中存儲模型名稱作為環境變量，這樣你可以在不觸碰每個節點的情況下更新它。使用 HTTP 請求節點中的 $vars.MODEL_NAME 而不是硬編碼模型名稱。

版本控制策略：

• 保留訓練資料與每個模型版本的哈希一起保存
• 在升級前在現有工作流程的保存樣本上測試新版本
• 在切換生產之前在 n8n 中平行運行新舊版本

流量管理：多個工作流程，一個 Ollama 實例

如果多個 n8n 工作流程同時觸發，單個 Ollama 實例可能會排隊請求。對於低到中等流量，這沒問題——Ollama 的隊列效果不錯。對於高流量：

選項 1：為不同工作流程運行多個 Ollama 實例

# 在不同端口運行 Ollama
OLLAMA_HOST=0.0.0.0:11434 ollama serve &
OLLAMA_HOST=0.0.0.0:11435 ollama serve &

選項 2：切換到 vLLM 用於並發處理

vLLM 比 Ollama 更好地處理並發請求，帶有適當的批次處理。切換只需要更新你的 n8n HTTP 節點的端點 URL——API 格式相似。

選項 3：n8n 中的排隊

對於高峰期的突發流量，在 n8n 中添加速率限制或排隊邏輯。這比運行額外的 GPU 服務器更便宜。

延伸閱讀

• n8n + 本地 LLMs：構建符合 HIPAA 的自動化工作流程 — 在有合規要求的醫療保健背景中應用相同堆疊
• 本地運行 AI 模型：完整指南 — Ollama、llama.cpp 和 vLLM 的深入設置指南
• 機構如何通過微調削減 90% AI 成本 — 更廣泛的成本削減策略超越單個工作流程