
當你的應用程式有了使用者,AI API 帳單會暴漲 10 倍
大多數 AI 教學跳過的成本計算。你的 API 帳單隨每位使用者線性成長,而真實的乘數比定價頁面顯示的更嚴重。以下是 1K、10K 和 100K MAU 時會發生的事。
你建了一個 AI 功能。運作得很好。你的 50 位 Beta 測試者很喜歡。每月 API 帳單是 $4.20。你發布了。
你的應用程式被推薦。下載量飆升。你達到 5,000 月活躍使用者。API 帳單來了:$1,687。下個月,10,000 MAU。帳單:$3,375。再下個月,20,000 MAU。你現在每月在 AI 推論上花費 $6,750。
這不是失敗。這是按 token 定價在規模化時可預測的數學結果。每篇教學都教你如何呼叫 API。沒有一篇給你看這條曲線。
天真的估算
大多數開發者這樣計算 API 費用:
每次請求的 token * 每個 token 的價格 * 每月的請求次數
使用 GPT-4o-mini(每百萬 token 輸入 $0.15、輸出 $0.60)、每次請求 1,000 個 token、10K MAU 每天 3 次請求:
10,000 使用者 * 3 請求/天 * 30 天 * 1,000 token = 每月 9 億 token 費用:4.5 億輸入 * $0.15/M + 4.5 億輸出 * $0.60/M = $67.50 + $270 = $337.50
看起來可以管理。以下是為什麼這是錯的。
隱藏的乘數
乘數 1:系統提示是按請求計費的
你的系統提示會隨每次 API 呼叫一起傳送。它不會在請求之間被快取(提示快取功能可用,但有特定要求,不適用於所有情況)。典型的行動應用程式系統提示有 800-1,500 個 token:
You are a helpful assistant for [App Name]. You help users with
[specific tasks]. Always respond in [format]. Never [constraints].
When the user asks about [topic], refer to [guidelines]...
以 1,200 個 token 計算,在 10K MAU、每天 90K 次請求的情況下,每月增加 12 億個額外輸入 token。光是系統提示在 GPT-4o-mini 上每月就多出 $180。
乘數 2:對話歷史會累積
基於聊天的功能會包含先前的訊息作為上下文。輸入成本隨每一輪成長:
| 輪次 | 輸入 Token(累計) | 輸出 Token |
|---|---|---|
| 第 1 輪 | 1,200(系統) + 200(使用者) = 1,400 | 400 |
| 第 2 輪 | 1,400 + 400 + 200 = 2,000 | 400 |
| 第 3 輪 | 2,000 + 400 + 200 = 2,600 | 400 |
| 第 4 輪 | 2,600 + 400 + 200 = 3,200 | 400 |
| 第 5 輪 | 3,200 + 400 + 200 = 3,800 | 400 |
一個 5 輪對話的總輸入 token:13,000。天真估算的 5 * 200 = 1,000 個使用者輸入 token 少算了 13 倍。
乘數 3:重試和錯誤處理
在規模化時,2-5% 的 API 呼叫會失敗。速率限制、逾時、伺服器錯誤。每次重試都完整重新傳送:系統提示、對話歷史和使用者的訊息。加上 3-5% 到你的總 token 數。
乘數 4:RAG 上下文注入
如果你使用檢索增強生成來提供相關上下文(產品文件、知識庫文章),每次注入增加 500-3,000 個 token。這是在其他所有成本之上的。
真實的乘數
當你把所有隱藏成本加在一起,真實的 token 使用量通常是天真估算的 3-5 倍。以下表格使用 3 倍作為保守乘數。
真實成本表
GPT-4o-mini($0.15 / $0.60 每百萬 token)
| MAU | 天真 | 真實 (3x) | 佔 $4.99/月營收的比例 |
|---|---|---|---|
| 500 | $17 | $51 | 2.0% |
| 1,000 | $34 | $101 | 2.0% |
| 5,000 | $169 | $506 | 2.0% |
| 10,000 | $338 | $1,013 | 2.0% |
| 50,000 | $1,688 | $5,063 | 2.0% |
| 100,000 | $3,375 | $10,125 | 2.0% |
GPT-4o($2.50 / $10.00 每百萬 token)
| MAU | 天真 | 真實 (3x) | 佔 $4.99/月營收的比例 |
|---|---|---|---|
| 500 | $281 | $844 | 33.8% |
| 1,000 | $563 | $1,688 | 33.8% |
| 5,000 | $2,813 | $8,438 | 33.8% |
| 10,000 | $5,625 | $16,875 | 33.8% |
| 50,000 | $28,125 | $84,375 | 33.8% |
| 100,000 | $56,250 | $168,750 | 33.8% |
百分比保持不變,因為營收和成本都隨使用者線性成長。如果 AI 在 1K 使用者時吃掉營收的 2%,在 100K 使用者時也吃掉 2%。如果吃掉 34%,在每個規模都吃掉 34%。改變的是絕對數字:$51/月可以忽略不計,$10,125/月是一筆嚴肅的支出。
真實公司的經歷
這個模式有據可查:
Replit 據報導毛利率從 +36% 搖擺到 -14%,因為 AI 推論成本隨使用量擴展(Sacra, 2025)。他們的 AI 功能很受歡迎。他們的成本也隨著這種受歡迎程度擴展。
Jasper 透過銷售 AI 寫作輔助建立了 $120M ARR。他們 的底層成本結構(以加價轉售 API token)限制了毛利率,並造成了顯著的競爭壓力。
Menlo Ventures 發現組織平均每月 AI 支出從 2024 年的 $63K 跳升到 2025 年的 $85.5K,一年內增加 36%。成本趨勢正在加速。
70% 的資訊長將 AI 成本的不可預測性列為他們最大的採用障礙(Forrester, 2026)。不可預測性來自按 token 費用隨使用量的線性擴展。
結構性問題
從 GPT-4o 切換到 GPT-4o-mini 可降低約 15 倍的成本。這很有意義。但它不改變結構。GPT-4o-mini 的成本仍然隨每位使用者線性擴展。曲線沒那麼陡,但仍然是一條向上的直線。
提示快取、縮短系統提示和回應長度限制等最佳化可以降低 20-40% 的成本。這些值得做。但它們是把線往下移,而不是改變斜率。
唯一改變斜率的方法是改變成本結構。從變動(按 token)到固定(按訓練次數)。這就是裝置端推論做的事。
替代方案:固定成本 AI
在你的領 域資料上微調小型模型。匯出為 GGUF。部署到裝置端。成本結構從:
雲端 API: 每次請求 $0.0001-$0.01 * N 次請求 = 隨使用者成長
裝置端: 一次性微調 $5-50 + 約 $0.08/GB CDN 分發 = 固定,不論使用者多少
在 10K MAU 時,裝置端比雲端 API 每月省 $1,000-$16,000。在 100K MAU 時,省 $10,000-$168,000 每月。
損益平衡來得很快。GPT-4o-mini 在僅 500 MAU 時,月 API 費用($51)就在第一個月超過一次性微調費用。GPT-4o 在任何非微量的使用者數時,損益平衡幾乎是即時的。
像 Ertas 這樣的平台讓微調流程變得容易上手:視覺化介面、不需要 ML 專業知識、上傳資料、訓練、匯出 GGUF、發布。障礙不再是技術問題,而是認知問題。
該怎麼做
從第一天就追蹤你的真實 API 費用。不是天真的估算,而是供應商帳務儀表板上的真實數字。計算每位使用者每月的成本。
設定一個閾值。當你的每位使用者 AI 費用超過 $0.10/月,或你的總 AI 支出超過 $500/月時,開始制定遷移計劃。從 API 日誌中擷取訓練資料。微調。部署到裝置端。A/B 測試。
數學會自己解決。唯一的 問題是你在它成為危機之前還是之後處理它。
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

AI API Pricing for Mobile: The Real Cost Per User
How to calculate the true cost of AI per mobile app user. Provider comparison, hidden multipliers, and the unit economics that determine whether your AI feature is sustainable.

Claude API vs OpenAI API for Mobile Apps
A side-by-side comparison of Anthropic's Claude and OpenAI's GPT models for mobile app integration. Pricing, rate limits, capabilities, and when neither is the right answer.

Fine-Tuning vs Prompt Engineering for Mobile Apps
Prompt engineering is fast and flexible. Fine-tuning is accurate and cheap at scale. Here is the practical comparison for mobile developers deciding between the two approaches.