在您的 SaaS 中構建 AI 功能：何時停止調用 OpenAI API
通過 OpenAI 向您的 SaaS 添加 AI 功能速度很快。但在某個使用量級別，經濟性就會崩潰。以下是如何識別這個臨界點以及如何應對。
OpenAI API 是幾乎每個 SaaS AI 功能的正確起點。它部署快速，不需要基礎設施，在原型階段 GPT-4o 的質量難以置疑。
但有一個時刻——您可以計算出的特定時刻——調用 OpenAI API 就是錯誤的架構。這是您在達到那個時刻之前需要進行的分析。
為什麼您從 OpenAI API 開始（並且應該這樣做）
對於新的 AI 功能，OpenAI API 幾乎總是正確的第一步：
- 不需要 ML 專業知識
- 不需要管理基礎設施
- 開箱即用的質量非常出色
- 迭代很快——更改提示，部署，完成
這不是錯誤，而是正確的工程做法。在 OpenAI API 上構建，可以在您投資更複雜的基礎設施之前驗證功能是否值得構建。
錯誤是在使用量增長時將 OpenAI API 視為永久架構。
經濟拐點
OpenAI API 成本隨使用量線性擴展。您的基礎設施成本（伺服器、數據庫）通常是次線性擴展的——每月花費 200 澳元的數據庫伺服器可以處理比 20 澳元伺服器多 10 倍的流量。
通過 API 的 AI 成本不是這樣工作的。每個額外的查詢成本相同的邊際金額。在低使用量時，這是看不見的。在高使用量時，它成為您 COGS 的重要部分。
計算方法 ：
對於每個 AI 功能，估計：
- 每個請求的平均 token 數（輸入 + 輸出）
- 每個活躍用戶每月的平均請求數
- 當前 MAU（月活躍用戶）
- 12 個月後的預計 MAU
示例：
- AI 電子郵件草稿功能：每份草稿 800 個 token
- 用戶平均每月生成 15 份草稿
- 今天 1,000 MAU，12 個月後 10,000 MAU
- GPT-4o 成本：每份草稿約 0.02 澳元
| MAU | 月度草稿數 | GPT-4o 成本 |
|---|---|---|
| 1,000 | 15,000 | 300 澳元/月 |
| 5,000 | 75,000 | 1,500 澳元/月 |
| 10,000 | 150,000 | 3,000 澳元/月 |
| 50,000 | 750,000 | 15,000 澳元/月 |
在 1,000 MAU 時，300 澳元/月是可以接受的。在 50,000 MAU 時，單個 API 項目每月 15,000 澳元是一個真實的 COGS 問題。
現在用自托管的微調 7B 模型進行同樣的計算：
- 伺服器成本（GPU 實例或自有硬體）：500-1,500 澳元/月固定
- 基礎設施之後的每請求成本：約 0 澳元
| MAU | 月度草稿數 | 本地模型成本 |
|---|---|---|
| 1,000 | 15,000 | 800 澳元/月（基礎設施） |
| 5,000 | 75,000 | 800 澳元/月 |
| 10,000 | 150,000 | 800 澳元/月 |
| 50,000 | 750,000 | 1,200 澳元/月（更大的伺服器） |
此示例的交叉點約為 3,000-4,000 MAU。低於此，OpenAI API 更便宜（較低的固定成本，低流量）。高於此，自托管模型更便宜。
您的交叉點是您應該開始規劃遷移的日期，而不是執行的日期。 遷移需要 4-8 週。在達到交叉點 MAU 的 40% 時開始規劃。
遷移實際涉及什麼
從 OpenAI API 遷移到自托管模型並不像聽起來那麼複雜，因為：
- Ollama 和類似工具公開與 OpenAI 相容的 API
- 您的應用程序代碼只更改基礎 URL 和模型名稱
- 不需要更改應用程序架構
實際花時間的是：
- 模型選擇和評估——選擇能很好地處理您的任務的基礎模型
- 微調——在您的特定功能用例上進行訓練（如果只是提示，對於簡單任務這一步可能可以跳過）
- 基礎設施設置——部署具有適當擴展和監控的推理伺服器
- 質量驗證——驗證本地模型在您的特定任務上匹配 OpenAI 輸出質量
- 逐步推出——在完全遷移之前將一小部分流量路由到本地模型
質量：真正的顧慮
大多數 SaaS 技術負責人對從 OpenAI 遷移的顧慮是質量問題。「GPT-4o 更好，我們的用戶會注意到。」
這個顧慮對某些任務是有效的，對其他任務則被誇大了。
質量顧慮有效的任務：
- 開放式創意生成（GPT-4o 在零樣本時確實有更好的創造力）
- 複雜的多步推理任務
- 需要廣泛世界知識的任務
微調的 7B 模型匹配或超越 GPT-4o 的任務：
- 定義明確的窄範圍領域內的任務
- 重複的格式化和提取任務
- 一致風格/聲音的內容生成
- 分類和路由
對於 SaaS AI 功能，大多數任務屬於第二類。專為特定 CRM 的電子郵件起草功能，使用在良好電子郵件示例上微調的 7B 模型，將比帶有通用提示的 GPT-4o 產生更好的結果——因為微調模型已學習了在該上下文中使電子郵件好的特定模式。
在做出遷移決定之前先運行評估。用 GPT-4o 生成 100 個示例（您當前的輸出），用您的候選本地模型生成 100 個示例。根據您的質量標準盲目評分。結果通常會讓人感到驚訝。
混合架構
您不必永久選擇其中一個。實際的混合架構：
- 第一層請求（高流量，定義明確的任務）：本地微調模型
- 第二層請求（較低流量，複雜或不尋常的任務）：GPT-4o API
基於查詢複雜度信號（長度、主題分類、用戶層級）實施路由邏輯。簡單、高流量的請求走本地。複雜的邊緣案例走 OpenAI。這在保護複雜查詢質量的同時捕獲了大部分成本節省。
自托管的基礎設施選項
最低阻力： Ertas 雲端部署。您的微調模型部署到托管基礎設施，通過 OpenAI 相容 API 提供服務。無需服務器管理，無需擴展顧慮。
中等複雜度： GPU 雲端實例（Lambda Labs、Vast.ai 或主要雲端 GPU VM）。您管理 Ollama 安裝和模型加載，但底層硬體是受管理的。適合有一定運維能力的團隊。
最大控制： 自有硬體。RTX 4090 工作站或 Mac Studio 部署在本地或託管設施中。最高固定成本，高流量時最低每查詢成本，完全控制推理環境。
正確的選擇取決於您團隊的運維專業知識和流量。達到遷移臨界點的大多數 SaaS 團隊應該從托管部署開始，並在流量證明運維投入合理時遷移到自有硬體。
何時不遷移
某些 SaaS AI 功能應該永久留在 OpenAI 上：
- 少於 1% 用戶群使用的功能（不值得遷移工作）
- 任務的複雜性和新穎性確實需要前沿模型能力的功能
- 在未來 12 個月內將被替換或停用的功能
- 質量風險超過成本節省的功能（高風險用戶面對決策）
在投入遷移工作之前，誠實評估每個功能屬於哪個類別。
內部呈現的商業案例
如果您需要在內部論證這次遷移，計算是直接的：
- 在預計規模下當前月度 AI API 成本：[X]
- 遷移後預計月度基礎設施成本：[Y]
- 遷移工作：[Z 人週] × 平均開發者成本
- 盈虧平衡：遷移工作成本 ÷（X - Y）月度節省
- 12 個月淨節省：（X - Y）× 12 − 遷移成本
在典型的 SaaS 成長軌跡下，在交叉點開始的遷移在 3-6 個月內收回成本，並在 24 個月內產生 5-8 倍的成本節省。
Ship AI that runs on your users' devices.
Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
延伸閱讀
- 按 Token 計費 AI 定價的隱藏成本 — 規模化時 API 定價的完整經濟學
- 微調一次，按月收費：產品化 AI 服務模型 — 適用於為客戶產品構建 AI 的機構
- 在本地運行 AI 模型 — 部署選項和硬體指南
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading
When Your SaaS Should Graduate from API Calls to Fine-Tuning
Your AI features work. Your API bill is growing faster than revenue. Here's the decision framework, cost math, and migration path for moving from per-token APIs to fine-tuned models — with real numbers at every step.
Multi-Tenant Fine-Tuning: Per-Customer AI Models in Your SaaS
Your SaaS customers want AI that understands their data, not generic responses. Here's how to architect per-tenant fine-tuned models using LoRA adapters — with real storage math, cost breakdowns, and a serving architecture that scales to hundreds of tenants.
Adding AI Features to Your SaaS Without an ML Team
Your customers expect AI features but you don't have ML engineers. Here's how SaaS product teams can fine-tune domain-specific models using their existing product data — no Python, no ML expertise, no API cost cliff.