行動應用程式的 OpenAI API：快速入門與沒人提到的費用

每篇關於在行動應用程式中加入 AI 的教學都以相同方式開始：取得 API 金鑰、發送 POST 請求、顯示回應。很簡單。但它們都沒有提到當真正的使用者開始使用功能時，你的帳單會發生什麼事。

本指南提供你兩個面向。你需要的快速入門整合方式，以及你需要在擴展中存活的成本計算。

快速入門

從行動應用程式整合 OpenAI 的 API 很直接。以下是兩個平台的模式。

Swift (iOS)

func sendMessage(_ message: String) async throws -> String {
    var request = URLRequest(url: URL(string: "https://api.openai.com/v1/chat/completions")!)
    request.httpMethod = "POST"
    request.setValue("Bearer \(apiKey)", forHTTPHeaderField: "Authorization")
    request.setValue("application/json", forHTTPHeaderField: "Content-Type")

    let body: [String: Any] = [
        "model": "gpt-4o-mini",
        "messages": [
            ["role": "system", "content": systemPrompt],
            ["role": "user", "content": message]
        ]
    ]
    request.httpBody = try JSONSerialization.data(withJSONObject: body)

    let (data, _) = try await URLSession.shared.data(for: request)
    let response = try JSONDecoder().decode(ChatResponse.self, from: data)
    return response.choices.first?.message.content ?? ""
}

Kotlin (Android)

suspend fun sendMessage(message: String): String {
    val client = OkHttpClient()
    val json = JSONObject().apply {
        put("model", "gpt-4o-mini")
        put("messages", JSONArray().apply {
            put(JSONObject().put("role", "system").put("content", systemPrompt))
            put(JSONObject().put("role", "user").put("content", message))
        })
    }
    val request = Request.Builder()
        .url("https://api.openai.com/v1/chat/completions")
        .post(json.toString().toRequestBody("application/json".toMediaType()))
        .addHeader("Authorization", "Bearer $apiKey")
        .build()
    val response = client.newCall(request).execute()
    return JSONObject(response.body!!.string())
        .getJSONArray("choices")
        .getJSONObject(0)
        .getJSONObject("message")
        .getString("content")
}

這是簡單的部分。發布後就能運作。現在來看教學跳過的部分。

價格概況（2026 年初）

輸出 token 比輸入 token 貴 2.5-4 倍。這很重要，因為大多數成本估算都低估了輸出的部分。

天真的估算 vs 現實

天真的成本計算：（輸入 token + 輸出 token）* 每個 token 的價格 * 請求數。這是錯的。它嚴重低估了真實成本，因為忽略了隱藏的乘數。

隱藏乘數 1：系統提示

你的系統提示會隨每一次 API 呼叫一起傳送。它不會在請求之間被快取。典型的行動應用程式系統提示有 500-1,500 個 token。有些達到 2,000 以上。

以每個系統提示 1,000 個 token、10,000 MAU 每天發送 3 次請求計算：光是系統提示每月就多出 9 億個額外輸入 token。以 GPT-4o-mini 的費率計算，光這一項每月就要 $135。

隱藏乘數 2：對話歷史

基於聊天的功能會包含先前的訊息作為上下文。到第三輪對話時，你已經在重新傳送前兩輪加上系統提示。到第五輪時，你在重新傳送所有內容。

一個 5 輪對話，每則訊息 500 個 token：第 1 輪 = 500 個 token，第 2 輪 = 1,500，第 3 輪 = 2,500，第 4 輪 = 3,500，第 5 輪 = 4,500。總輸入：12,500 個 token，但使用者感覺只有 5 則短訊息。

隱藏乘數 3：重試和失敗

在規模化運作時，2-5% 的 API 呼叫會失敗（速率限制、逾時、伺服器錯誤）並需要重試。每次重試都是完整重新傳送整個提示，包括系統提示和歷史紀錄。

隱藏乘數 4：真實總計

當你把系統提示、對話歷史成長和重試開銷加在一起，真實的費用通常是天真估算的 3-5 倍。

規模化成本表

使用行動 AI 助手模式：每天 3 次互動、每次互動 1,000 個 token（天真估算），套用 3 倍的隱藏成本乘數。

GPT-4o-mini（$0.15 / $0.60 每百萬 token）

GPT-4o（$2.50 / $10.00 每百萬 token）

如果你的應用程式每月收費 $4.99，在 10K MAU 時你的營收是 $49,900。GPT-4o 吃掉其中的 $16,875，佔營收的 34%，僅僅用於 AI 推論。GPT-4o-mini 好一些，$1,013，但仍然佔營收 2% 且隨使用者線性成長。

當數學算不過來的時候

根本問題是成本結構，而不是每個 token 的價格。雲端 AI 是隨每位使用者成長的變動成本。每一項價格最佳化（切換模型、縮短提示長度、快取）都只是爭取時間，並不改變底層曲線。

替代方案是裝置端推論。在你的領域資料上微調小型模型，匯出為 GGUF，透過 llama.cpp 在本地端執行。一次性微調費用 $5-50。之後每次推論成本為零，不論 MAU 多少。

微調的 3B 模型在領域特定任務上達到 94% 的準確率，而 GPT-4 使用提示工程僅有 71%。對於大多數行動應用程式的使用情境（聊天助手、分類、內容撰寫），裝置端模型不只更便宜，在特定任務上表現更好。

像 Ertas 這樣的平台以視覺化介面處理微調流程：上傳資料、在雲端 GPU 上訓練、匯出 GGUF、部署到你的應用程式。從雲端 API 轉向裝置端不需要 ML 團隊。

現在該怎麼做

從 GPT-4o-mini 開始。它是驗證用途中成本和能力的最佳平衡。建立功能、發布它、確認使用者會使用它。

從第一天就追蹤你的實際 token 使用量。不是天真的估算，而是包含系統提示、對話歷史和重試在內的真實數字。建立一個顯示每位使用者每月成本的儀表板。

當這個數字超過每位使用者每月 $0.05 時，就開始規劃遷移到裝置端。你的 API 日誌已經包含了你需要的訓練資料。