從雲端 API 遷移到裝置端 AI：完整指南

您有一個行動應用程式，其 AI 功能由雲端 API 驅動。它能用，但成本在增長，延遲很明顯，而且您希望支援離線使用。本指南詳細介紹從雲端 API 到裝置端推理的完整遷移過程。

遷移不是重寫。它是一個漸進式過渡，裝置端 AI 逐步替代雲端 API 的特定功能，每一步都經過驗證。

第一階段：評估（第 1 週）

盤點您的 AI 功能

列出每個呼叫雲端 AI API 的功能：

功能	每日 API 呼叫	平均 Token 數	月成本	需要離線？
聊天助手	5,000	2,500	$450	最好有
內容分類	12,000	800	$180	是
智慧回覆	8,000	600	$120	是
摘要	2,000	3,000	$270	否

按遷移價值優先排序

為每個功能評分：

成本影響： 高頻功能節省最多錢
延遲敏感度： 速度最重要的功能從裝置端獲益最大
離線價值： 使用者在無網路時需要的功能
複雜度： 簡單任務（分類、短文字生成）更容易遷移

從最高價值、最低複雜度的功能開始。分類和智慧回覆是典型的首選候選。

設定品質基線

遷移之前，衡量雲端 AI 在每個功能上的表現：

# 評估集：200-500 個帶有人工驗證正確答案的樣本
evaluation_set = load_evaluation_data("eval_set.jsonl")

for example in evaluation_set:
    cloud_response = call_cloud_api(example.input)
    cloud_score = evaluate(cloud_response, example.expected)
    log_baseline(example.id, cloud_score)

基線是您的裝置端模型必須達到或超過的標準。

第二階段：準備訓練資料（第 1-3 週）

從 API 日誌提取

您現有的 API 呼叫日誌是主要的訓練資料來源：

從日誌基礎設施匯出 API 日誌（輸入/輸出對）
過濾品質（成功的回應、使用者接受的輸出）
匿名化（移除 PII）
格式化為標準的聊天訓練格式

# 從 API 日誌中提取訓練資料
training_examples = []
for log in api_logs:
    if log.status == "success" and log.user_feedback != "negative":
        training_examples.append({
            "messages": [
                {"role": "user", "content": log.user_input},
                {"role": "assistant", "content": log.model_output}
            ]
        })

用合成資料補充

如果您的 API 日誌不足（少於 500 個高品質樣本），用合成資料補充：

使用雲端 API 產生最佳樣本的變體
為日誌中代表不足的邊界情況建立樣本
手動驗證合成樣本（抽樣 10-20%）

目標資料集大小

功能	最少	建議
分類	500	1,000
智慧回覆	500	2,000
對話	1,000	3,000
摘要	500	2,000

第三階段：微調（第 3-4 週）

選擇基礎模型

功能類型	建議模型	大小
分類、標籤	Llama 3.2 1B	600MB (Q4)
智慧回覆、建議	Llama 3.2 1B	600MB (Q4)
對話、工作階段	Llama 3.2 3B	1.7GB (Q4)
摘要	Llama 3.2 3B	1.7GB (Q4)

使用 LoRA 訓練

將訓練資料上傳到微調平台。設定 LoRA 參數：

Rank：16-32（1B）或 32-64（3B）
學習率：1e-4 到 2e-4
Epochs：3-5
評估集拆分：10%

Ertas 等平台處理訓練基礎設施：選擇基礎模型，上傳資料，設定參數，在雲端 GPU 上訓練，匯出 GGUF。

對照基線評估

用評估集執行微調後的模型：

for example in evaluation_set:
    on_device_response = run_local_model(example.input)
    on_device_score = evaluate(on_device_response, example.expected)
    compare_to_baseline(example.id, on_device_score)

通過標準： 主要指標上裝置端準確率與雲端基線在 3% 以內。

需要時迭代

如果模型未達到品質標準：

為失敗的類別新增更多訓練樣本
增加 LoRA rank 以獲得更多容量
嘗試更大的基礎模型（1B 到 3B）
調整超參數（降低學習率，增加 epochs）

每次變更後重新評估。大多數模型在 2-3 次訓練迭代內達到生產品質。

第四階段：整合（第 4-5 週）

將 llama.cpp 新增到專案

按照平台特定的整合指南：

iOS：Swift Package 或預編譯 framework
Android：llama.android 函式庫或 NDK 建置
React Native：llama.rn 套件

建構 AI 提供者抽象

建立一個通用介面，雲端和裝置端提供者都實作：

protocol AiProvider {
    func generate(prompt: String, maxTokens: Int) async throws -> AiResponse
    var isAvailable: Bool { get }
}

class CloudProvider: AiProvider { /* 現有實作 */ }
class OnDeviceProvider: AiProvider { /* 新的 llama.cpp 實作 */ }

實作模型分發

選擇打包或安裝後下載。為 GGUF 檔案設定 CDN 託管。實作下載進度 UI、SHA256 驗證和儲存管理。

新增路由邏輯

根據模型可用性和 A/B 測試分組將請求路由到雲端或裝置端：

func getProvider(for userId: String) -> AiProvider {
    let cohort = getCohort(userId)

    if cohort == .onDevice && onDeviceProvider.isAvailable {
        return onDeviceProvider
    }
    return cloudProvider
}

第五階段：A/B 測試（第 5-7 週）

漸進式發布

第 5 週：10% 裝置端（監控當機、錯誤）
第 6 週：50/50 分組（收集對比指標）
第 7 週：分析結果

關鍵監控指標

任務完成率（主要）
功能參與度（D7 留存）
延遲（TTFT 和總延遲）
當機率
使用者回饋（如果有回饋機制）

決策標準

遷移如果任務完成率在雲端的 3% 以內且當機率沒有增加。迭代如果品質較低但接近（差距在 5% 以內）。用更多資料重新訓練。暫停如果品質差距顯著（超過 5%）。調查根本原因。

第六階段：遷移（第 7-8 週）

全面發布

在 1-2 週內推進到 100% 裝置端：

75% 裝置端，25% 雲端（1 週）
100% 裝置端（保留雲端作為回退）

保留雲端作為回退

不要立即移除雲端 API 整合。保留它作為以下情況的回退：

無法執行模型的裝置（4GB 以下 RAM）
模型下載失敗
發現模型品質問題時的緊急回滾

逐步關閉雲端

在 100% 裝置端穩定運行 30 天後：

降低雲端 API 層級（降低速率限制承諾）
90 天後：評估是否保留雲端回退或完全移除
追蹤雲端回退使用率。如果低於 1% 的請求，可以安全移除。

第七階段：營運（持續）

模型更新流程

建立定期更新週期：

從使用者互動中收集新訓練資料
每月或每季重新訓練
對照前一版本模型進行評估
透過 OTA 模型更新推送
每次更新後監控品質指標

監控

追蹤裝置端 AI 健康指標：

推理延遲（P50，P95）
模型載入成功率
生成品質（透過使用者回饋/操作）
記憶體使用和當機率
模型下載成功率

成本追蹤

記錄成本節省：

遷移前的雲端 API 帳單
遷移後的雲端 API 帳單（僅回退）
模型分發的 CDN 成本
微調成本（每次重新訓練）
每月淨節省

時間線總結

階段	持續時間	關鍵交付物
評估	第 1 週	功能清單、品質基線
準備資料	第 1-3 週	清洗、格式化的訓練資料集
微調	第 3-4 週	達到品質標準的 GGUF 模型
整合	第 4-5 週	應用程式中的 llama.cpp、模型分發就緒
A/B 測試	第 5-7 週	品質對等的統計證據
遷移	第 7-8 週	100% 裝置端，保留雲端回退
營運	持續	定期模型更新、監控

總計：從開始到完全遷移 8 週。 後續模型更新（重新訓練和部署）只需要幾天而非幾週。

微調步驟是 Ertas 等平台節省最多時間的地方。上傳您的 API 日誌資料，選擇基礎模型，訓練，匯出 GGUF。平台處理 GPU 基礎設施、訓練最佳化和 GGUF 轉換。您的重心保持在資料品質和應用程式整合上。