Android LLM 效能基準：Snapdragon 對比 Tensor

Android 的晶片組多樣性對裝置端 AI 來說既是挑戰也是機會。不像 iOS 只需針對少數 A 系列晶片，Android 涵蓋了 Qualcomm Snapdragon、Google Tensor、Samsung Exynos 和 MediaTek Dimensity，分布在數百款裝置型號上。

好消息是：旗艦和近期中階 Android 裝置以可用的速度運行 1-3B 參數模型。只要你瞄準正確的層級，碎片化是可以管理的。

晶片組版圖

旗艦（2023-2026）

中階（2024-2026）

入門（2024-2026）

基準測試結果

所有基準測試使用 llama.cpp 搭配 CPU 推理（多執行緒）以及可用時的 Vulkan GPU 加速。GGUF Q4_K_M 量化，2048 上下文長度。

1B 參數模型（約 600MB GGUF Q4）

過去 2-3 年的每款旗艦和中階晶片組都能以每秒 20 token 以上的速度運行 1B 模型。即使入門級的 Snapdragon 6 Gen 3 也能提供可用的效能。

3B 參數模型（約 1.7GB GGUF Q4）

3B 模型在旗艦裝置上運行良好（搭配 GPU 達 15+ tok/s）。中高階裝置（SD 7+ Gen 3、Dimensity 8300）可用。中低階和入門裝置難以達到舒適聊天的 10 tok/s 門檻。

Vulkan GPU 加速

Vulkan GPU 加速是 Android 上快速裝置端推理的關鍵。相比純 CPU 推理，大多數裝置的提升幅度在 20-40%：

• Snapdragon 8 Gen 3：搭配 Vulkan 提升 30-35%
• Tensor G4：提升 25-30%
• Exynos 2400：提升 20-30%
• 中階 Snapdragon 7：提升 20-25%

llama.cpp 透過 n_gpu_layers 參數啟用 Vulkan 加速。將其設定為模型的完整層數即可將所有運算卸載到 GPU。

碎片化策略

Android 碎片化可透過分層方式管理：

第 1 層：1B 模型（4GB+ RAM）

涵蓋 85% 以上的在用 Android 裝置。包括過去 3-4 年的所有智慧型手機、過去 2 年的大多數入門裝置。

• 模型大小：約 600MB（Q4_K_M）
• RAM 需求：推理時 800MB
• 速度：根據晶片組 12-55 tok/s
• 適合：分類、自動完成、智慧建議、短回應

第 2 層：3B 模型（8GB+ RAM）

涵蓋過去 2-3 年的旗艦和中高階裝置。在已開發市場大約 40-50% 的在用 Android 裝置，且逐年增長。

• 模型大小：約 1.7GB（Q4_K_M）
• RAM 需求：推理時 2.2GB
• 速度：在支援的裝置上 10-30 tok/s
• 適合：聊天、摘要、內容生成、複雜任務

運行時偵測

在運行時偵測可用 RAM 和晶片組以選擇適當的模型：

fun selectModelTier(): ModelTier {
    val memInfo = ActivityManager.MemoryInfo()
    val activityManager = getSystemService(ACTIVITY_SERVICE) as ActivityManager
    activityManager.getMemoryInfo(memInfo)

    val totalRamGb = memInfo.totalMem / (1024 * 1024 * 1024)

    return when {
        totalRamGb >= 8 -> ModelTier.THREE_B
        totalRamGb >= 4 -> ModelTier.ONE_B
        else -> ModelTier.NONE // 裝置條件太受限
    }
}

溫度和電池影響

溫度節流

Android 裝置在持續推理期間比 iPhone 更容易出現溫度節流。節流行為因廠商而異：

• Samsung：積極節流，持續負載 3-5 分鐘後速度降低 20-40%
• Pixel：適度節流，5-7 分鐘後降低 15-25%
• OnePlus/電競手機：較為寬鬆，降低 10-20%

電池消耗

運行推理大約消耗：

• 1B 模型：生成時 2-3W
• 3B 模型：生成時 3-5W

作為參考，典型手機電池容量為 4,000-5,500 mAh。3B 模型持續生成大約每分鐘消耗 1% 電量。對於典型使用模式（每小時幾次短互動），電池影響可以忽略不計。

最佳化

• 使用與裝置效能核心數量匹配的 CPU 執行緒數（通常為 4）
• 不使用時卸載模型以消除閒置功耗
• 對於背景任務（分類、標記），批次處理比逐次呼叫更省電

對開發者的意義

1. 1B 模型是普遍可行的。 以 1B 為目標以獲得廣泛覆蓋。在你的領域上微調以在此大小下最大化品質。

2. 3B 模型適合旗艦裝置。 如果你的使用者群偏向較新的裝置（付費應用程式中常見），3B 提供明顯更好的生成品質。

3. Vulkan 很重要。 務必啟用 GPU 加速。20-40% 的速度提升是免費的效能。

4. 偵測並適應。 使用運行時 RAM 偵測來提供正確的模型層級。不要在 4GB 裝置上強制使用 3B 模型。

5. 微調，不只是縮小。 在你的領域資料上微調的 1B 模型，在你的特定任務上優於通用 3B。像 Ertas 這樣的平台讓這變得容易：上傳資料、使用 LoRA 訓練、匯出 GGUF、部署。

Android 生態系統擁有硬體。推理引擎（llama.cpp）處理了晶片組的多樣性。缺少的部分是適合你使用場景的正確模型。