後 API 時代的架構：讓 AI 功能不再虧損的 SaaS 技術棧

第一代 AI 驅動的 SaaS 建立在第三方 API 上。OpenAI、Anthropic、Google——選擇您的供應商、接入 SDK，一週內就能上線 AI 功能。這種方式構建快速，而且奏效。

但這種架構存在結構性問題：每一個觸及 AI 的客戶操作都要花費您的錢。不是隨使用量擴展的基礎設施成本，而是直接的、按每個 Token 計費、與每次請求線性增長的成本。您的銷售成本隨著每位新用戶、每個新功能、每次參與度提升而增長。

後 API 技術棧消除了這一問題。它用在您控制的基礎設施上運行的微調模型取代了按 Token 計費的 API 調用，並通過與 OpenAI 相容的端點提供服務，使您的應用程式代碼幾乎不需要任何更改。按 Token 的成本實際上降為零。您的 AI 功能變得像您的資料庫一樣在成本上穩定。

API 依賴問題

以下是 SaaS 產品規模化後 API 依賴的實際表現：

收入： AU$200,000/月（4,000 位用戶，每位 AU$50/月）

啟動時（1,000 位用戶）的 AI API 成本： AU$3,500/月——可接受，佔預期收入的 3.5%

4,000 位用戶時的 AI API 成本： AU$14,000/月——佔收入的 7%，開始讓人感到壓力

預計 10,000 位用戶時的 AI API 成本： AU$35,000/月——現在成為繼薪資和辦公室之後的第三大支出

問題不僅在於成本，而在於成本結構：

• 沒有真正有意義的批量折扣。 企業 API 協議可能給您 10-20% 的折扣。而您的基礎設施成本在規模化時會下降 50-80%。
• 無法優化運行時。 您無法改變模型的運行方式。您無法根據特定吞吐量需求進行量化。您無法高效批量處理請求。
• 廢棄風險。 OpenAI 廢棄了 GPT-3.5 Turbo，然後廢棄了建立在其上的微調模型。團隊被迫重建。這種情況將再次發生。
• 速率限制作為擴展障礙。 您的應用程式吞吐量受他人速率限制器的限制。
• 零護城河。 每位競爭對手都能以相同價格使用相同的模型。

後 API 技術棧的樣貌

後 API 架構有四個層次：

┌──────────────────────────────────────────────┐
│              您的 SaaS 應用程式               │
│                                              │
│  ┌────────────────────────────────────────┐  │
│  │       與 OpenAI 相容的客戶端           │  │
│  │    （相同 SDK，相同請求格式）          │  │
│  └───────────────────┬────────────────────┘  │
│                      │                        │
│  ┌───────────────────▼────────────────────┐  │
│  │           本地 API 伺服器              │  │
│  │     (Ollama / llama.cpp / vLLM)        │  │
│  │    提供 /v1/chat/completions           │  │
│  └───────────────────┬────────────────────┘  │
│                      │                        │
│  ┌───────────────────▼────────────────────┐  │
│  │         微調模型（GGUF）               │  │
│  │   7B-14B 參數，Q4_K_M 量化             │  │
│  │   在您的生產資料上訓練                 │  │
│  └───────────────────┬────────────────────┘  │
│                      │                        │
│  ┌───────────────────▼────────────────────┐  │
│  │         推理硬體                       │  │
│  │   帶 GPU 的 VPS / Mac Studio / 本地   │  │
│  │   每月固定費用 AU$500-2,000            │  │
│  └────────────────────────────────────────┘  │
└──────────────────────────────────────────────┘

每一層都是標準的、廣為人知的組件。任何環節都沒有專有的鎖定。讓我們逐一介紹。

第一層：與 OpenAI 相容的客戶端

這是您的應用程式代碼所接觸的部分。關鍵洞見在於：它不需要更改。

如果您的應用程式目前像這樣調用 OpenAI API：

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": prompt}]
)

您的後 API 代碼看起來是這樣的：

client = openai.OpenAI(base_url="http://localhost:11434/v1")
response = client.chat.completions.create(
    model="my-fine-tuned-model",
    messages=[{"role": "user", "content": prompt}]
)

兩行發生了變化：基礎 URL 和模型名稱。您應用程式的其他所有部分——提示構建、回應解析、錯誤處理、串流——保持完全相同。OpenAI SDK 可以與任何實作 OpenAI API 規範的伺服器配合使用。

這就是為什麼遷移比大多數團隊預期的要簡單得多。您不是在重寫 AI 整合。您只是將它指向另一台伺服器。

第二層：本地 API 伺服器

Ollama、llama.cpp server 和 vLLM 都提供與 OpenAI 相容的 API 端點。它們負責：

• 將模型載入記憶體（GPU 或 CPU）
• 管理並發請求
• 串流 Token 生成
• 優化吞吐量的 KV 快取管理

Ollama 是最簡單的選項。安裝它，拉取一個模型，5 分鐘內就有一個運行中的 API 伺服器。它處理模型管理、自動 GPU/CPU 分配和並發請求處理。最適合：希望簡單並運行 1-3 個模型的團隊。

llama.cpp server 給您更多對推理參數的控制——上下文窗口大小、批量大小、線程數、量化載入。最適合：需要從硬體中榨取最大吞吐量的團隊。

vLLM 專為高吞吐量生產服務設計。它實作了 PagedAttention 以實現高效記憶體管理，並支援連續批量處理。最適合：服務 100 個以上並發用戶且有嚴格延遲要求的團隊。

對於擁有 50,000 個以下用戶的大多數 SaaS 產品，Ollama 是正確的選擇。它已為生產環境做好準備，維護良好，運營開銷極小。

第三層：微調模型

模型是品質的來源。基礎 7B 模型在您的特定任務上無法匹敵 GPT-4o。一個在您確切使用場景的 2,000-5,000 個範例上微調過的 7B 模型，在這些特定任務上將達到甚至超過 GPT-4o 的表現。

微調流程：

1. 從當前 API 使用中導出訓練資料。 您現有的 GPT-4o 或 Claude 輸出就是您的黃金標準。為每種任務類型導出輸入輸出對。

2. 使用 QLoRA 進行微調。 這是一種參數高效方法，只訓練模型權重的一小部分。使用 QLoRA，7B 模型在單個 GPU 上 30-90 分鐘即可完成微調。

3. 合併並量化。 將 LoRA 適配器合併到基礎模型中，並量化為 GGUF 格式。Q4_K_M 量化將模型大小減少約 75%，品質損失極小。7B 模型從約 14GB 縮小到約 4GB。

4. 評估。 在 200-500 個範例的保留測試集上運行量化模型。與您的雲端 API 輸出進行比較。目標是在您的特定任務上達到 90-98% 的品質對等。

GGUF 格式是所有主要推理引擎支援的開放標準。您的模型檔案可在 Ollama、llama.cpp 和任何相容 GGUF 的運行時之間移植。

Ertas 自動化了第 2-3 步：上傳您的資料集，選擇基礎模型，即可收到準備部署的微調 GGUF 檔案。無需 ML 專業知識，無需管理訓練基礎設施。

第四層：推理硬體

硬體層是經濟效益改變的地方。不再是按 Token 定價，而是固定的每月基礎設施成本。

選項 A：GPU VPS（AU$400-1,500/月）

Lambda Labs、Vast.ai、RunPod 或主要雲端 GPU 實例等供應商。單個 A10G 或 L4 GPU 實例可以每秒處理量化 7B 模型的 50-100 個以上請求。這對大多數 SaaS 工作負載來說已綽綽有餘。

優點：無需管理硬體，可按需擴容/縮容，支援多個地區。 缺點：每月費用，供應商依賴（雖然易於移植）。

選項 B：專用硬體（一次性 AU$3,000-8,000，之後每月 AU$50-200 電力/共置費）

配備 RTX 4090（24GB VRAM）的工作站或搭載 M 系列晶片的 Mac Studio。RTX 4090 可輕鬆處理量化 14B 模型。Mac Studio M4 Ultra 可處理高達 70B 的量化模型。

優點：一次性成本分攤到 3-5 年，每次推理的長期成本最低，完全物理控制。 缺點：硬體管理，無地理分佈，容量上限。

選項 C：僅 CPU VPS（AU$80-300/月）

量化 7B 模型在 CPU 上以每秒 2-8 個 Token 的速度運行。對於每月請求量低於 50,000 次且可接受 2-3 秒以上延遲的工作負載，這是最廉價的選項。不需要 GPU。

優點：最廉價，最簡單，可在任何 VPS 上運行。 缺點：推理速度慢，吞吐量有限。

規模化成本比較

讓我們比較一個從每月 100,000 增長到 1,000,000 次 AI 請求的 SaaS 產品在 12 個月內的總擁有成本：

雲端 API（GPT-4o）：

後 API 技術棧（GPU VPS 上的微調 7B 模型）：

節省：12 個月 AU$179,400。 在更高的使用量下，差距會進一步擴大，因為後 API 成本幾乎不會增加。

您仍然需要雲端 API 的情況

後 API 技術棧不意味著零 API 使用量。有些合理的理由保留雲端 API 整合：

邊緣案例的備用方案。 當您的微調模型遇到未接受過訓練的請求類型時，將其路由到雲端 API。這應該佔流量的 5-15%，隨著您擴展訓練資料而逐漸減少。

新功能開發。 在原型設計新 AI 功能時，使用雲端 API 驗證概念並收集訓練資料。一旦功能穩定且有足夠的範例，即可微調並遷移。

需要前沿推理的任務。 複雜的多步驟推理、需要廣泛世界知識的創意生成，或 7B 模型真的無法匹敵 200B 以上模型的任務。這些確實存在，但它們在大多數 SaaS 工作負載中所佔的比例比團隊預想的要小。

最終狀態不是「無 API」——而是「例外時才用 API」。API 成為您的研發工具和備用方案，而不是您的生產推理層。

無需重寫應用的遷移

工程團隊最常見的顧慮是遷移複雜性。以下是實際範圍：

所需的更改：

1. 添加路由配置（哪些任務類型路由到哪個後端）——50-100 行代碼
2. 將本地 API 伺服器 URL 作為環境變數添加——1 行
3. 更新已路由任務的模型名稱引用——查找並替換
4. 添加本地推理延遲和吞吐量的監控——標準可觀測性

不需要的更改：

• 不需要重寫提示（微調模型學習了任務，所以提示更簡單或保持不變）
• 不需要更改回應解析（相同的 API 格式）
• 不需要更改串流邏輯（相同的 SSE 協議）
• 不需要更改錯誤處理（相同的錯誤格式）
• 不需要更改身份驗證（本地伺服器，無需 API 金鑰）

對於具有 3-5 個 AI 功能的典型 SaaS 產品，遷移工作量為一名工程師 2-4 週的時間。大部分時間花在微調和評估上，而不是代碼更改上。

為模型可移植性構建

GGUF + 與 OpenAI 相容的 API 架構的一個優勢：您不依賴任何特定模型。當更好的基礎模型發布時——而且每隔幾個月就會發布——您可以：

1. 在現有資料集上微調新的基礎模型
2. 對比現有生產模型評估它
3. 在推理伺服器上熱切換模型檔案
4. 零應用程式代碼更改

這與 API 依賴完全相反。您控制模型生命週期。您決定何時升級。沒有廢棄通知，沒有強制遷移，沒有破壞性更改。

您的模型是磁碟上的一個檔案。您的推理伺服器是一個開源二進制文件。您的應用程式與標準 API 通信。每一層都可以獨立替換。這就是後 API 技術棧。

延伸閱讀

• Migrate from OpenAI API to Fine-Tuned Local Model — 逐步遷移指南
• OpenAI-Compatible Local API with Fine-Tuned Models — 設置您的本地推理端點
• The Real Cost of API Dependency in Production AI — API 依賴風險的完整分析