從每月 $500 的 OpenAI 帳單到 $0：將 n8n 工作流程遷移到本地模型

你從一個使用 OpenAI 的 n8n 工作流程開始。一個簡單的——也許它分類傳入的電子郵件或從表單提交中提取資料。API 呼叫每次執行的費用不到一分錢。幾乎不引人注意。所以你又構建了五個工作流程。然後十個。然後你為需要更好推理的工作流程添加了 GPT-4。然後你的同事看到了你構建的東西，又要求了三個。

現在你面對的是每月 $500 的 OpenAI 帳單。而且還在增長。

問題是：大多數這些工作流程不需要 GPT-4。它們甚至不需要 GPT-3.5。它們需要一個在一個特定任務上非常出色的模型——分類、提取、重新格式化、摘要——而這正是微調的 7B 模型所做的。從 OpenAI API 呼叫遷移到本地微調模型並不像聽起來那麼可怕，節省的成本是巨大的：從每月數百美元到按每個 token 計費字面上為零。

本指南逐步介紹整個遷移過程。我們將稽核你的工作流程、優先考慮遷移內容、為每種工作流程類型微調模型、使用 Ollama 部署它們，並在不破壞任何東西的情況下在 n8n 中交換端點。

遷移稽核

在遷移任何東西之前，你需要了解你在處理什麼。稽核的目標是清點每個使用 AI 節點的 n8n 工作流程，按複雜性和容量對每個進行分類，並確定快速獲勝的機會。

第一步：列出所有帶有 AI 節點的工作流程。 在 n8n 中，進入你的工作流程列表並搜索包含 OpenAI 節點（或任何 AI/LLM 節點）的工作流程。對於每個工作流程，記錄：

• 工作流程名稱和目的
• 使用的模型（GPT-4、GPT-4o、GPT-3.5-turbo）
• 每天的大約執行次數
• 每次執行的平均輸入 token 數
• 每次執行的平均輸出 token 數
• 是否使用結構化輸出（JSON 模式、函數呼叫）

第二步：按任務類型分類。 大多數 AI 驅動的 n8n 工作流程屬於以下類別：

第三步：計算每個工作流程的費用。 將每個工作流程的每日執行次數乘以其 token 使用量和模型的每個 token 費率。以下是快速參考：

每天運行 500 次、800 個輸入 token 和 200 個輸出 token 的 GPT-4o 工作流程：

• 輸入：500 x 800 = 40 萬 token/天 = 1,200 萬 token/月 = $30/月
• 輸出：500 x 200 = 10 萬 token/天 = 300 萬 token/月 = $30/月
• 總計：單個工作流程每月 $60

乘以 10-15 個工作流程，你就能明白為什麼每月 $500 很快就發生了。

優先遷移哪些工作流程

並非所有工作流程都是同等的遷移候選者。理想的首要目標是：

高容量、低複雜性。 每天將 2,000 封電子郵件分類為 5 個類別的工作流程是完美的。它有清晰的輸入輸出模式、高容量（因此高節省）和低複雜性（微調的 3B 模型可以輕鬆處理）。

結構化輸出。 期望 JSON 輸出的工作流程——例如從發票中提取字段或解析表單資料——是絕佳候選者。輸出格式受到約束且可預測，這使得微調直接且評估簡單。JSON 要麼正確要麼不正確。

重複模式。 如果工作流程對數千次輸入執行本質上相同的轉換，只有輸入資料不同，微調效果很好。模型只需要學習一次模式。

首先不要遷移的工作流程：

• 任何需要最新世界知識的工作（微調模型知道它被訓練時的知識，僅此而已）
• 多步驟推理鏈，其中早期輸出饋入後期提示
• 質量主觀且難以評估的創意生成
• 任何具有安全關鍵後果的東西（醫療、法律、財務建議）

以下是優先排序框架：

遷移框架

遷移分四個階段進行。不要跳過階段。不要急於求成。

第一階段：導出執行資料

對於你要遷移的每個工作流程，你需要實際執行的輸入輸出對。這是你的訓練資料。

從 n8n 執行日誌： n8n 為每次工作流程執行存儲執行資料。你可以通過 n8n API 訪問這些，或者如果你是自托管，直接從資料庫訪問。對於 AI 節點的每次執行，提取：

• 發送到 OpenAI 的提示/輸入
• 收到的回應/輸出
• 工作流程是否成功完成（過濾掉失敗）

導出腳本方法：

// 從 n8n 執行中提取訓練對的偽代碼
const executions = await n8nApi.getExecutions({
  workflowId: "your-workflow-id",
  status: "success",
  limit: 5000,
});

const trainingData = executions.map((exec) => {
  const aiNode = exec.data.resultData.runData["OpenAI Node"][0];
  return {
    input: aiNode.parameters.prompt,
    output: aiNode.data.main[0][0].json.text,
  };
});

// 寫成 JSONL
const jsonl = trainingData
  .map((d) => JSON.stringify(d))
  .join("\n");
fs.writeFileSync("training-data.jsonl", jsonl);

每種工作流程類型需要多少資料？

對於大多數 n8n 工作流程，兩到四週的執行日誌提供了超過足夠的訓練資料。

第二階段：每個工作流程進行微調

現在的問題是：你是為所有工作流程訓練一個模型還是每種工作流程類型一個模型？

每種工作流程類型一個模型 幾乎總是正確的選擇。原因如下：

• 每個模型可以很小很快（3B-7B 參數），因為它只需要處理一個任務
• 質量更高，因為模型不會被競爭的任務模式混淆
• 你可以在要求改變時獨立更新每個模型
• 如果一個模型表現不佳，你只需重新訓練那個——不是全部

使用 Ertas 進行微調過程：

1. 將 JSONL 訓練文件上傳到 Ertas
2. 選擇基礎模型：
   • Qwen 2.5 3B 用於簡單分類和提取（在 4GB RAM 上運行）
   • Qwen 2.5 7B 用於摘要和生成（在 8GB RAM 上運行）
3. 配置 LoRA 訓練（對大多數工作流程，默認值就很好）
4. 訓練——500 個範例在 3B 模型上大約需要 15 分鐘，7B 大約需要 30 分鐘
5. 對保留的測試範例進行評估
6. 導出為 GGUF

第三階段：部署和測試

在單個 Ollama 實例上部署所有你的微調模型。Ollama 高效地處理多個模型——它將活躍模型加載到記憶體中，並可以在幾秒鐘內在模型之間切換。

部署設置：

# 在 VPS 上安裝 Ollama
curl -fsSL https://ollama.com/install.sh | sh

# 創建每個模型
ollama create email-classifier -f Modelfile.email-classifier
ollama create invoice-extractor -f Modelfile.invoice-extractor
ollama create ticket-summarizer -f Modelfile.ticket-summarizer

多個模型的 VPS 規格：

即使在最高端——每月 $96 運行 10 多個模型——你也只是在支付每月 $500 OpenAI 帳單的一小部分。

平行測試策略： 在生產中交換任何東西之前，與你現有的 OpenAI 工作流程並行運行你的微調模型至少一週。方法如下：

1. 克隆你要遷移的每個工作流程
2. 在克隆中，用指向你的 Ollama 端點的 HTTP 請求節點替換 OpenAI 節點
3. 在相同觸發器上同時運行兩個工作流程
4. 並排比較輸出

建立一個簡單的比較試算表：

對於分類和提取工作流程，你需要至少 95% 的匹配率。對於生成和摘要，需要人工判斷——但輸出應該在功能上等同，不一定完全相同。

第四階段：交換和監控

一旦平行測試確認了質量，就交換生產工作流程。

漸進切換方法：

• 第 1 週： 遷移 P0 工作流程（分類、提取）。保留 OpenAI 作為後備——如果本地模型返回錯誤或置信度低，回退到 OpenAI。
• 第 2 週： 如果 P0 穩定，刪除 P0 工作流程的 OpenAI 後備。用後備遷移 P1 工作流程。
• 第 3 週： 刪除 P1 的後備。評估 P2 工作流程。
• 第 4 週： 根據評估結果遷移或延後 P2。

n8n 中的後備模式：

輸入 → 本地模型（Ollama）→ IF（置信度 > 閾值）→ 使用本地結果
                                               → ELSE → OpenAI API → 使用 API 結果

監控清單：

• 每天追蹤每個工作流程的錯誤率
• 比較執行時間（大多數任務本地應該更快）
• 記錄任何回退到 API 的事件並調查原因
• 監控 VPS 資源使用率（CPU、RAM）
• 每週通過抽樣每個工作流程 20-30 個結果來檢查輸出質量

遷移費用計算

以下是典型遷移的數字：

之前：OpenAI API 費用

之後：本地微調模型

每月節省：$355.50。每年節省：$4,266。

這是保守估計。隨著工作流程容量增長，API 費用本來會線性增長，而本地基礎設施費用保持不變。如果你的電子郵件分類器增加到每天 1,600 次執行，VPS 的本地費用仍然是每月 $48。在 OpenAI 上，光是那個工作流程就會跳到每月 $90。

我們沒有遷移的（以及原因）

誠實很重要。不是所有東西都應該脫離 API。以下是我們有意保留在 OpenAI 上的工作流程：

報告生成器。 這個工作流程接受 15 個資料點並生成帶有戰略建議的 2,000 字分析。它需要真正的推理、多個資料來源的綜合和創意框架。7B 模型可以處理格式化，但分析質量與 GPT-4 相比明顯下降。我們把它保留在 API 上。每天 50 次執行，費用可以管理（每月 $62），質量差異很重要。

電子郵件起草者。 與報告生成器類似——它起草複雜的多段電子郵件，這些郵件引用了以前的對話歷史並需要微妙的語氣匹配。微調模型可以很好地處理簡單回覆，但對長篇、上下文豐富的草稿很吃力。我們把複雜草稿保留在 GPT-4 上，把簡單回覆模板遷移到本地模型，將工作流程一分為二。

任何涉及財務計算的東西。 我們有一個工作流程接受原始交易資料並生成帶有計算總額的財務摘要。計算在 n8n（不是 LLM）中完成，但 LLM 格式化最終報告。即使 LLM 只是格式化，賭注也足夠高，我們把它保留在 GPT-4 上，因為它在數字任務上的幻覺率較低。安心值每月 $35。

規律是：當任務需要（a）對新型輸入的真正推理，（b）長篇創意生成，或（c）即使 2% 的錯誤率也不可接受的高風險準確率時，保留在 API 上。

30 天後的結果

以下是運行遷移堆疊一個月後實際發生的事情：

費用減少：78%。 從每月 $453 降至 $97.50。我們預期節省更多，但我們保留了三個我們原計劃遷移的工作流程在 API 上（見上文）。節省仍然是每年 $4,266。

延遲改善：平均快 40%。 這讓我們感到驚訝。Hetzner VPS 上的本地推理比 OpenAI API 呼叫始終更快，尤其是在高峰時段。電子郵件分類器從平均 800ms（OpenAI）降至平均 320ms（本地 Ollama）。沒有網絡往返，沒有 API 隊列，沒有速率限制。

質量指標：

• 分類準確率：97.2%（本地）vs 98.1%（OpenAI）。不到 1% 的差異。
• 提取準確率：95.8%（本地）vs 96.4%（OpenAI）。可以忽略不計的差異。
• 摘要質量（人工評估，100 個樣本）：4.2/5（本地）vs 4.4/5（OpenAI）。可接受。

可靠性： 30 天內 Ollama VPS 零停機。零速率限制錯誤。相比之下，OpenAI API 在高峰時段每天有 3-5 個速率限制錯誤，每個都需要重試邏輯並增加延遲。

意外收穫：資料隱私。 通過本地推理，我們的工作流程資料都不會離開我們的基礎設施。對於處理客戶電子郵件、發票和支持票券的工作流程，這是一個我們事先沒有完全重視的重大合規優勢。

遷移時間線

對於擁有 10-15 個 n8n 工作流程和中等技術水平的團隊，以下是實際的時間線：

• 第 1 週： 稽核所有工作流程、分類、優先排序。導出訓練資料。
• 第 2 週： 在 Ertas 上微調 P0 工作流程的模型。設置 Ollama VPS。
• 第 3 週： 對 P0 工作流程進行平行測試。微調 P1 模型。
• 第 4 週： 將 P0 切換到生產。開始平行測試 P1。
• 第 5-6 週： 切換 P1。評估 P2。進入穩定狀態。

從開始到完成六週。第一個費用節省在第 4 週出現。到第 6 週，你以信心全額節省運行。

每月 $500 的 OpenAI 帳單並非不可避免。它是使用通用模型完成特定任務的擴展產物。微調本地模型是修復方案——遷移比你想象的更直接。

延伸閱讀

• 從 API 依賴到模型所有者：90 天遷移行動手冊 — 從 API 到擁有模型的完整分階段計劃
• n8n + 本地 LLMs：構建符合 HIPAA 的自動化工作流程 — 本地模型如何解決醫療保健工作流程的合規問題
• n8n 到微調模型的機構行動手冊 — 將 n8n 遷移產品化為機構服務
• 按 Token 計費 AI 定價的隱藏費用 — 為什麼按 token 定價與可持續業務根本不一致