On-Device 與雲端 API:在 10K、50K 與 100K MAU 時的真實成本數學

你的 AI 功能在測試環境裡表現完美。回應迅速、模型有能力、成本可以忽略不計。然後你達到了 10K 月活躍使用者,帳單也跟著到了。

這個時刻,把能擴張的應用程式與那些悄悄被推倒重來的應用程式區分開。根據 Forrester 2026 年的報告,百分之七十的 CIO 把 AI 成本不可預測性列為最大的採用障礙。Menlo Ventures 發現,組織 AI 月均支出從 2024 年的 6.3 萬美元跳升到 2025 年的 8.55 萬美元,一年內成長 36%。Replit 的毛利率據報導隨推論用量擴張從 +36% 擺動到 -14%(Sacra)。

好消息是:你可以在它發生之前就把它建模出來。本文展示這套數學。

價格全景

首先,我們先把真實的數字擺出來。所有價格按每 100 萬 tokens 計,資料為 2026 年初。

在每一家供應商那裡,輸出 tokens 的成本都明顯高於輸入 tokens。這一點很重要,因為大多數成本估算只關注輸入長度,而低估了輸出端。

成本模型:幾個假設

為了讓討論具體起來,我們需要一個基準用量假設。下面是一個帶有 AI 助理功能的行動應用程式的合理模型:

• 每位使用者每天 3 次互動(對一款日常使用的應用程式而言較為保守)
• 每次互動 500 輸入 tokens(簡短的 system prompt 加上使用者訊息)
• 每次互動 500 輸出 tokens(段落長度的回覆)
• 月活躍使用者分別為 10K、50K 與 100K

也就是每位使用者每月 30 次互動,每次互動總計 1,000 tokens(輸入和輸出各佔一半)。

每位使用者每月總 tokens:30,000(15K 輸入 + 15K 輸出)。

規模化下的雲端 API 成本

下面是這套數學在三個 MAU 節點產生的結果。

10,000 MAU

50,000 MAU

100,000 MAU

這些是最低估算。它們不包含重試邏輯、串流額外負擔、隨對話延伸而成長的上下文視窗,也不包含執行 RAG 時 embedding 呼叫的成本。真實世界的 token 用量通常是估算值的 1.5 到 2 倍。

On-Device 這條替代路線

On-device 推論把模型跑在使用者的硬體上。模型分發完成之後,每一次推論對你來說都是零成本。沒有按 token 收費、沒有 API 呼叫、沒有出口流量費。

你真正需要支付的兩塊成本是:

1. Fine-tuning(一次性):在雲端 GPU 服務上訓練一個 LoRA 適配器,根據資料集大小和基礎模型不同大約要花 $5–$50。這是每個模型版本的一次性成本,不是按使用者或按推論收費。

2. 模型分發(每次安裝一次性):你隨應用程式一起發送一個 GGUF 檔案。適合行動端的實用模型 GGUF 體積:Llama 3.2 1B 的 Q4_K_M 量化版是 808MB;3B 版本是 2.02GB。1GB 檔案按標準費率走 CDN 出口,每次安裝不到 $0.10。對 10K 使用者來說,這意味著大約 $1,000 的總分發成本,在安裝時攤銷,而不是按月發生。

月度持續成本:$0。

收支平衡點

以 GPT-4o-mini 作為基準(注重成本的團隊常用之選):

只要 MAU 超過幾百,$5–$50 的一次性 fine-tuning 成本基本上在第一個月就會回本。真正的成本只剩整合所需的工程時間和最初的模型分發。

雲端 API 的隱藏成本

價格表並不是故事的全部。雲端 API 依賴會帶來一組不會出現在月帳單上的成本。

速率限制與延遲尖峰

每一家主要供應商都會施加速率限制:每分鐘 tokens、每分鐘請求數、每日上限。這些都按帳戶等級分層,要往上調通常需要數週的使用歷史。在出現尖峰的時候(走紅的瞬間、產品發布、某個功能開始流行),你恰恰會在最需要可靠性的時候撞上限制。速率限制錯誤需要客戶端的重試邏輯,這增加了複雜度,並可能級聯成使用者能感知到的故障。

延遲也會浮動。雲端模型端點是共享基礎設施。在尖峰負載期,P99 延遲可能達到 5–10 秒。相對地,on-device 推論是確定性的。它跑在專屬硬體上,沒有網路來回。

供應商鎖定與停用風險

模型 API 不是穩定的契約。OpenAI 已經停用了 GPT-3、GPT-3.5 以及多個 fine-tuning 端點。Anthropic、Google 等公司也走的是類似路徑。當一個模型被停用時,你會拿到一個遷移視窗,通常是 6–12 個月,用來更新提示、重新測試、重新部署。在 GPT-4o-mini 上效果良好的提示工程,不一定能直接遷移到新模型上。

On-device 模型不會按供應商的時間表停用。你自己控制何時升級,可以無限期地為舊版本應用程式提供支援,而不必為一個你已經無法控制的 API 端點繼續付費。

網路依賴

每個 AI 功能都要求保持網際網路連線的行動應用程式,會受到一個硬性約束。On-device 模型可以離線執行。對於筆記應用、生產力工具、local-first 應用,或任何面向連線品質不穩定地區的應用程式而言,離線能力是真正的競爭優勢,而不只是錦上添花。

隱私與資料駐留

每一次 API 呼叫都會把使用者的輸入傳送到第三方伺服器。對處理敏感資料(健康、金融、法律、HR)的應用程式來說,這創造了合規面。On-device 推論把使用者資料保留在裝置上。資料從不離開。

雲端 API 仍然合理的場景

On-device 並不是每一個用例的正確答案。請坦誠面對下面這些情境:

**原型開發和早期階段。**當 MAU 還不到幾百的時候,經濟性更偏向雲端。你還在驗證功能。使用 GPT-4o-mini 或 Gemini Flash,仔細監測 token 使用情況,等到 1K–5K MAU 的時候再回頭審視模型架構。

**需要前沿模型能力的任務。**1B–7B 參數範圍的 on-device 模型在摘要、分類、抽取、簡單 Q&A、短文本生成上有能力。它們不適合複雜的多步推理、跨大型程式碼庫的程式碼生成,或那些真正受益於 100B+ 參數模型的任務。如果你的功能需要 GPT-4o 等級的推理,on-device 不是替代品。

**低吞吐量的 B2B 工具。**如果你只有 200 名企業使用者,每人每週 10 次互動,你的 GPT-4o 帳單不到 $100/月。在這種量級,搬到 on-device 的工程投入並不划算。

**需求快速變化的任務。**如果你的 system prompt 每週都在變,而且你正在快速迭代模型行為,雲端的迭代迴路要快得多。重新做 fine-tuning 並重新分發一個 on-device 模型,比推送一份新的 system prompt 要花更多時間。

一個實用的決策框架

這個決策不是非此即彼。一種常見的混合架構是:把核心功能(摘要、打標籤、快速回覆)放在 on-device,把特定的高複雜度請求路由到雲端 API。這樣可以讓 80%–90% 的推論量留在 on-device,以零 token 成本執行,同時為邊緣情境保留對前沿能力的存取。

通往 On-Device 的工程路徑

歷史上,on-device AI 的實際門檻一直是工具鏈。Fine-tuning 需要 ML 基礎設施,匯出到 GGUF 需要模型轉換工具,把推論整合到行動應用程式需要平台特定的繫結。

這就是 Ertas 的位置。該平台在一條流水線裡處理 fine-tuning(基於你資料集的 LoRA 適配器)、量化以及 GGUF 匯出。你提供訓練資料和目標用例。你拿到一份可用於行動部署的 GGUF 檔案,以及面向 iOS(透過 llama.cpp 繫結)和 Android 的整合指引。

$5–$50 的一次性 fine-tuning 成本,對比一份會隨你獲得的每一位使用者線性成長的月度 API 帳單:這道數學題很快就會自己解出來。

結論

在 10K MAU 使用 GPT-4o-mini 時,你每月支付 $337。在 50K MAU 時是 $1,687。在 100K MAU 時是 $3,375 一個月,而且這是用便宜模型加保守用量假設算出來的。GPT-4o 在 100K MAU 時是 $56,250 一個月。

On-device 推論在不到 $50 的一次性 fine-tuning 投入和在安裝時攤銷的模型分發成本之後,執行成本是 $0。

收支平衡不是幾個月之後的事。對幾乎任何活躍使用者超過幾百的應用程式來說,API 帳單會在上線後的第一個計費週期內就超過 fine-tuning 的成本。問題不是 on-device 是不是更便宜。問題是你什麼時候去把它做出來。