Galaxy S23 FE 跑本地 LLM：前景模式決定效能

圖片：Wikimedia Commons／Pang Ka Kit（CC BY 2.5）

TechLab 編輯部（譯）·2026-10-27

一部 Galaxy S23 FE 能否代替部分雲端 AI 工作，關鍵未必只是模型大小或手機記憶體，而是 Android 對背景 app 的資源分配。XDA 作者 Shekhar Vaidya 以 Exynos 2200、8GB RAM 版本實測，在 Termux 以 llama.cpp 載入 Gemma 4 E2B；當 Termux 留在背景、Chrome 顯示網頁介面時，生成速度只有約 0.1 token/s。

作者其後把 Termux 和 Chrome 放在分割畫面，讓 Termux 保持前景，Gemma 4 E2B 的生成速度升至約 5.4 至 6.6 token/s；其 llama-bench 短測更錄得 11.39 token/s。這代表把舊手機改作私隱優先、處理簡單改寫、摘要或分類的本地 AI 節點有一定可行性，但使用方式與系統排程限制，會直接左右成果。

背景運行令速度大跌

作者先嘗試以 PocketPal 載入 Gemma 4 E2B，但 app 多次因記憶體問題崩潰。改用 Termux 安裝 llama.cpp，並載入 Unsloth Q4_K_M 版本後，約 3.11GB 的模型可成功啟動本機 server。問題出現在實際使用：一個輸出 8 個 token 的簡單 prompt 用了 1 分 11 秒；另一個摘要測試輸出 68 個 token，花近 12 分鐘。

電池限制、閒置 app 休眠及省電模式均已關閉或放寬後，速度仍沒有改善。作者改測約 1.18GiB 的 Qwen 3.5 2B，同樣表現不佳，顯示瓶頸未必單純來自模型規模。

前景 app 可用核心較多

作者在 Termux 內執行 llama-bench，並檢查 cgroup 與可用 CPU 核心設定。其觀察是：Termux 留在前景時可使用 0 至 7 號核心；轉到背景時則只剩 0 至 2 號核心。Qwen 3.5 2B 在短測中，背景狀態的 prompt 處理及生成速度分別為 1.68 和 0.17 token/s；前景狀態則升至 24.29 和 13.33 token/s。Gemma 4 E2B 在前景短測的生成速度為 11.39 token/s。

作者推測，Android 或 Samsung 的背景群組調度限制了沒有可見視窗的 app 可用核心數；他尚未確認這是 Android 共通行為，還是 Samsung 的個別實作。為避開限制，他採用 Termux 與 Chrome 分割畫面：前者維持本地推理 server，後者開啟 llama 網頁介面。壓力測試中，該設定在 2 分 4 秒生成了 730 個 token。

可作輕量工具，仍要覆核內容

模型質素亦是取捨。作者指較小的 Qwen 3.5 2B 在其測試出現不少虛構內容，包括杜撰 Gemma 型號及發布日期；Gemma 4 E2B 對其日常的摘要、電郵回覆和部分技術計算 prompt 表現較好。不過，這是單一作者在特定模型量化、手機版本及系統設定下的結果，不能視為所有 Android 手機或本地模型的通用結論。

分析而言，這次測試最有用的啟示是：流暢度不能只看 CPU 或 RAM。模型量化、散熱、背景程式，以及 app 是否保持前景，都可能改變結果。即使手機能把推理留在本機、減少把文字送往雲端，使用者仍需長開分割畫面，並覆核小型模型的輸出，因此較適合作為低風險、短內容工作的輔助工具。

接下來值得觀察的是，同一套 Termux、llama.cpp 與模型配置在非 Samsung Android 手機上，是否也會因背景排程而出現類似落差；這將決定分割畫面是否只是個別裝置的權宜方法，還是手機本地 LLM 的普遍使用門檻。