停止按用戶付費：獨立應用程式的固定成本 AI 架構

大多數 AI 驅動的 SaaS 應用都有一個不為人知的秘密：每新增一位用戶，業務就變得更不划算。這不是那種「伺服器需要花錢」這種抽象說法，適用於所有軟體。而是非常具體的「每次 AI 請求花費 $0.003，我的平均用戶每天發出 45 次請求」，這樣的方式正在吞噬您的利潤空間。

傳統 SaaS 的邊際成本幾乎為零。新增第 10,001 位用戶基本上不會讓您多花錢——伺服器已經在運行，程式碼已經寫好。AI 驅動的 SaaS 打破了這個模式。使用按 token 計費，每位用戶都會產生大約等比例的 AI 帳單增加。您的收入隨用戶數增長，AI 成本也隨用戶數增長。如果您的每用戶 AI 成本與每用戶收入相差不遠，您就擁有了一個越成功越糟糕的業務。

有一種更好的架構。一種無論您有 100 位還是 100,000 位用戶，AI 基礎設施成本都相同的架構。這不是理論——它今天已在早早想清楚這個數學問題的獨立開發者的生產環境中運行。本指南解釋它是什麼、如何建構，以及它確切地在哪些情況下有效，在哪些情況下無效。

按用戶計費的成本問題

讓我們把這個問題說得更具體。您建構了一個 AI 驅動的應用程式——比如一個內容優化工具。每位用戶提交文字，AI 分析後返回建議。標準流程。您收費 $19/月每位用戶。

以下是您的 AI 成本在增長過程中的樣子，假設使用 GPT-4o 定價，中等使用量（每位用戶每天 30 次 AI 請求，每次平均 1,000 個輸入 token 和 500 個輸出 token）：

在 3.6% 的收入佔比下，這看起來可以接受。但這是樂觀情境。現實中：

重度用戶會破壞您的平均值。 您最頂端 10% 的用戶產生了 40-60% 的 AI 請求。部分用戶每天觸發超過 100 次請求。那個「每用戶每天 30 次請求」的平均值，掩蓋了一條推高成本的重度使用長尾。

提示串聯會倍增 token 數量。 代理程式式功能、重試邏輯和多步驟工作流程可能將您每次用戶操作的 token 數量乘以 2-5 倍。一個「優化我的文章」按鈕在底層可能觸發三次 LLM 呼叫。

上下文視窗隨時間增長。 隨著用戶在您的應用中累積歷史，提示變得更長。那個 1,000 token 的輸入平均值，隨著您加入對話歷史、用戶偏好和先前結果，會向 3,000-4,000 token 爬升。

包含重度用戶和提示串聯的更真實圖景：

現在您收入的 10% 流向 AI 推論。對於沒有 VC 資金的獨立開發者，這是毛利率的一大塊。而且與託管成本（由於快取、CDN 和高效架構而呈次線性增長）不同，AI API 成本是線性增長的。當每個請求都是唯一的時，沒有任何快取技巧有幫助。

「固定成本」是什麼意思

固定成本 AI 架構是指您的 AI 推論成本由您的基礎設施決定，而非由您的使用量決定。您為伺服器付費，而非為 token 付費。無論那些伺服器每月處理 1,000 次還是 100,000 次請求，基礎設施成本是相同的。

核心思想很簡單：不是將每個 AI 請求發送到按 token 計費的 API，而是在您控制的硬體上自行運行 AI 模型。模型在您的 VPS 上運行。VPS 每月固定收費。每次請求的成本為零。

這之所以可行，是因為 2025-2026 年同時出現了三個進展：

1. 小型開源模型變得足夠好。 微調後的 Qwen 2.5 7B、Llama 3.3 8B 和類似模型可以處理大多數應用特定的 AI 任務。您不再需要 GPT-4 來處理所有事情。
2. 微調變得易於使用。 Ertas 等工具讓非 ML 開發者能在不到一小時內對其應用數據微調模型。無需 PyTorch，無需 GPU 集群，無需博士學位。
3. 本地推論變得快速。 Ollama 和 llama.cpp 使得在普通硬體上以 15-30 tokens/秒的速度運行量化 7B 模型成為可能——足夠快到用於生產環境。

固定成本架構結合了這三者：針對您的特定任務微調一個小型模型，將其部署在固定成本的 VPS 上，從該基礎設施為所有用戶提供服務。

架構

以下是固定成本 AI 應用的完整架構：

┌──────────────────────────────────────────────┐
│  您的應用（前端 + API）                         │
│  託管在 Vercel / Railway / Fly.io             │
└────────────────────┬─────────────────────────┘
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
   ┌────────────┐     ┌──────────────────┐
   │  請求路由   │     │  資料庫            │
   │            │     │  (Supabase/Neon)  │
   └──┬──────┬──┘     └──────────────────┘
      │      │
  95% │      │ 5%
      ▼      ▼
┌──────────┐ ┌──────────┐
│  Ollama   │ │ OpenAI   │
│（本地）    │ │ API      │
│  $30/月   │ │（備援    │
│  固定     │ │  僅用）  │
└──────────┘ └──────────┘

四個元件使其運作。讓我們逐一介紹。

元件 1：微調小型模型

固定成本 AI 的基礎是使用專為您的使用案例訓練的模型，而非通用前沿模型。

為什麼小型模型適用於應用特定任務： SaaS 應用中的大多數 AI 功能執行的是狹窄、重複的任務。將這段文字分類、提取這些欄位、以這種語氣重寫這段話、生成這份資料的摘要。這些任務不需要 GPT-4 對古羅馬歷史和量子力學的全面知識。它們需要一個深度學習了某個特定模式的模型。

一個在您特定任務的 1,000 個範例上微調的 7B 參數模型，大約在 90-95% 的情況下可以達到 GPT-4 在該任務上的性能。對於剩餘 5-10% 的邊緣情況，您有備援（元件 3）。關鍵洞見是：您不需要本地模型的完美。您需要「95% 的請求足夠好」——因為那 95% 才是在規模化時讓您花錢的部分。

選擇您的基礎模型：

對於大多數獨立應用，Qwen 2.5 7B 是預設選擇。它提供了能力和資源效率的最佳平衡。

使用 Ertas 微調： 上傳您的 JSONL 訓練資料（來自現有 API 日誌的輸入-輸出對），選擇基礎模型，使用 LoRA 訓練。整個過程在 Ertas 上需要 30-60 分鐘。成本：$14.50/月，無限次訓練運行。

訓練資料來自您現有的應用。如果您一直在使用 OpenAI API，您的日誌中已經有數千個輸入-輸出對。匯出它們，清理後上傳。您實際上是在用昂貴模型已經完成的工作來訓練您的替代模型。

元件 2：使用 Ollama 的本地推論

Ollama 是將您微調的模型作為本地 API 提供服務的運行時。安裝在 VPS 上，載入您的模型，您的應用發出的每個 AI 請求都在本地提供服務，每個 token 的費用為零。

基礎設施選項和成本：

一台 $26/月的 Hetzner VPS，運行 Ollama 和量化的 7B 模型，可處理 15-25 tokens/秒。對於每次 AI 請求生成 200-500 個輸出 token 的典型應用，這相當於大約 2-4 個請求/秒的持續吞吐量。這相當於每天 170,000 到 345,000 次請求。

除非您的應用流量極度爆發，否則一台 $26/月的 VPS 能處理大多數獨立應用永遠不會達到的流量。

元件 3：智慧請求路由

並非每個請求都需要發送到您的本地模型。並非每個請求都能由您的本地模型處理。智慧路由是使架構可靠運作的黏合劑。

路由邏輯很簡單：

1. 每個 AI 請求首先到達路由器
2. 路由器將請求發送到本地 Ollama 模型
3. 如果 Ollama 在預期格式內返回有效回應，則使用它
4. 如果 Ollama 出錯、超時或返回格式錯誤的回應，則退回到 OpenAI API

在您的應用中實作：

async function aiRequest(input: string): Promise<string> {
  try {
    // 首先嘗試本地模型
    const localResponse = await fetch("http://ollama-vps:11434/api/generate", {
      method: "POST",
      body: JSON.stringify({
        model: "my-fine-tuned-model",
        prompt: input,
        stream: false,
      }),
      signal: AbortSignal.timeout(10000), // 10s 超時
    });

    const result = await localResponse.json();

    // 驗證回應格式
    if (isValidResponse(result.response)) {
      return result.response;
    }

    // 格式無效——退回
    return await openaiRequest(input);
  } catch (error) {
    // 錯誤或超時——退回
    return await openaiRequest(input);
  }
}

實際上，路由分配看起來像這樣：

關鍵洞見：您不需要在第一天就在本地處理 100%。從 80% 本地開始並迭代。每個月，審查退回到 API 的請求，將它們加入訓練資料，重新訓練，並部署更新的模型。隨著時間推移，本地模型處理越來越多的邊緣情況，API 成本趨近於零。

在成熟階段，仍然進入 API 的 2-3% 是真正困難的情況——新穎的邊緣情況、不尋常的輸入、與訓練資料根本不同的請求。這個殘留的 API 成本微不足道。

元件 4：水平擴展

在某個時間點，一台 VPS 已經不夠。當您遇到超過單一實例吞吐量的持續高流量時，您進行水平擴展——添加更多 VPS 實例，每個都運行相同的模型。

擴展數學：

注意每用戶成本。透過水平擴展，您的每用戶 AI 成本隨著增長而降低。在 100,000 用戶時，您每月每用戶的 AI 推論費用為 $0.002。在同等規模下使用 OpenAI API，您每月每用戶大約需支付 $0.68（基於前面的真實成本估算）。

這是 340 倍的成本差異。

在多個 Ollama 實例之間進行負載平衡很簡單。在您的 Ollama 機群前使用簡單的輪詢或最少連線負載平衡器（nginx、HAProxy 或您的雲端供應商內建的 LB）。每個實例運行相同的模型，因此任何實例都可以處理任何請求。

成本建模：API 與固定成本架構的規模比較

以下是包含所有基礎設施成本的全面比較：

損益平衡點出乎意料地低——大約 100-200 位用戶，取決於使用模式。低於此，固定成本架構相當或略便宜。高於此，節省是巨大的，並隨每位額外用戶而複利增長。

在 10,000 位用戶時，您每月節省 $6,582.50——每年 $78,990。這不是四捨五入的誤差。這是生活方式業務和掙扎業務之間的差異。

換一種說法。如果您向每位用戶收費 $19/月，並有 10,000 位用戶，您的月收入為 $190,000。使用 API 架構，$6,750 流向 OpenAI（3.6%——或實際上，考慮重度用戶，$19,000 即 10%）。使用固定成本架構，$167.50 流向 AI 基礎設施（收入的 0.09%）。這個利潤差異每個月都在複利累積。

固定成本架構不適用的情況

固定成本架構並非普遍優越。以下是堅持使用 API（或使用混合方法）更有意義的場景：

即時多模態任務。 如果您的應用使用 AI 處理圖像、音訊或視訊，您需要自行託管成本顯著更高的模型和硬體。視覺模型需要具有大量 VRAM 的 GPU。Whisper 等音訊轉錄模型是 CPU 密集型的。固定成本數學仍然有效，但基礎設施成本更高，將損益平衡點推高到 1,000-5,000 位用戶。

尖端推理任務。 如果您的應用真的需要 GPT-4 或 Claude 級別的推理——複雜的多步驟分析、細膩的創意寫作、高級程式碼生成——微調的 7B 模型可能不夠。這些任務代表 AI 能力的前沿，小型模型根本無法複製它們。然而，請誠實地審計您的應用：大多數「我們需要 GPT-4」的說法都經不起仔細審視。大多數應用 AI 任務比開發者想像的更窄。

極度多樣化的任務集。 如果您的 AI 功能處理數百種根本不同的任務類型，沒有主要模式，微調就變得不切實際（您需要數十個專門模型）。這在實踐中很罕見——大多數應用有 3-5 個核心 AI 任務，佔 90% 的請求。

非常早期階段（產品市場契合前）。 如果您仍在迭代您的 AI 功能做什麼，承諾微調是過早的。在您弄清楚產品時使用 API。一旦您知道您的 AI 做什麼（並且可以將其表達為清晰的輸入-輸出模式），那就是切換到固定成本的時機。

需要認證模型的監管環境。 某些受監管行業需要專門認證或稽核過的 AI 模型。自行託管的開源模型可能不符合這些要求。在遷移前請與您的合規團隊確認。

實作路線圖

以下是從 API 遷移到固定成本架構的四週計劃：

第 1 週：資料收集和稽核

• 在所有 AI API 呼叫上啟用日誌（輸入、輸出、延遲、成本）
• 運行一週以建立基準指標
• 分類您的 AI 任務並識別最高量的任務
• 計算您目前每用戶的 AI 成本

第 2 週：微調

• 從您的 API 日誌中匯出最高量任務的 500-2,000 個輸入-輸出對
• 上傳到 Ertas 並在 Qwen 2.5 7B 上微調
• 評估：測試 50 個輸入並與 GPT-4 回應比較
• 如果品質可接受（90% 以上的匹配率），繼續。如果不行，清理訓練資料並重新訓練。

第 3 週：部署和平行測試

• 啟動一台 Hetzner CX42（$26/月）並安裝 Ollama
• 部署您微調的模型
• 使用 API 備援實作請求路由器
• 平行運行：將每個請求同時發送到本地和 API，比較結果
• 監控一週

第 4 週：切換和監控

• 將生產流量切換到本地優先架構
• 保持 API 備援活躍（反正您已在付費——只有在本地失敗時才會被呼叫）
• 監控錯誤率、延遲和用戶反饋
• 穩定運行一週後，考慮遷移您的下一個 AI 任務

對您應用中的每種 AI 任務類型重複第 2-4 週。大多數獨立應用有 2-4 個不同的 AI 任務，因此完整遷移需要 4-8 週。

結論

按 token 計費的 AI 定價創造了一種成功懲罰您的商業模式。更多用戶意味著更多 AI 成本，在規模化時這些成本會吞噬您的利潤。

固定成本架構打破了這種耦合。您的 AI 基礎設施成本由您運行的硬體固定，而非您服務的用戶決定。一台 $26/月的 VPS 以零每 token 費用服務 5,000 位用戶。在 50,000 位用戶時，五台總共 $130/月的 VPS 替代了本來 $33,750/月的 API 呼叫費用。

微調（使用 Ertas，$14.50/月）使本地模型對 95-98% 的請求足夠好。智慧路由使用 API 備援處理其餘部分。結果是一個每個新用戶都是純利潤的 AI 架構，就像傳統 SaaS 一樣。

您不需要等到 AI 帳單變得令人痛苦。實作固定成本架構的最佳時機是在規模化之前——當遷移簡單且風險低時。現在就建構架構。之後再擴展。保留收入。

---

延伸閱讀

• 2026 年獨立開發者的 AI 模型成本 — 獨立開發者 AI 實際成本的全面分析
• 獨立應用的自行託管 AI — 為何自行託管 AI 推論是最大的利潤槓桿
• 規模化後的 SaaS AI 功能成本 — AI 功能成本隨 SaaS 增長的行為方式