本地大語言模型手機：從 AI 功能手機到個人 AI Runtime

系列：狀態驅動的本地具身 AI｜第 7 篇
版本：v0.1
日期：2026-08-01

摘要

2026 年的旗艦手機已經明確跨過「能不能在手機上運行生成式模型」這道門檻。Google 的 Gemini Nano 已透過 Android AICore 在超過一億台裝置上提供本地生成式能力；Gemini Nano 4 與 Gemma 4 開始進一步支援更強的 reasoning 與 tool calling；Google 的 LiteRT-LM 也已能讓開發者在 Android 上直接部署自訂 LLM。官方基準甚至顯示，Gemma-4-E2B 在 Samsung S26 Ultra 上以 GPU backend 可達約 52 tokens/s decode、約 0.3 秒 time-to-first-token。Qualcomm Snapdragon 8 Elite Gen 5 與 MediaTek Dimensity 9500 也把 on-device agentic AI、personal knowledge graph、always-on light AI、長上下文與本地大模型壓縮列為晶片級設計目標。

因此，「本地大語言模型手機」已經不是遙遠的硬體幻想。

然而，今天大多數產品仍然更接近：

\text{Phone} + \text{On-device AI Features}

而不是：

\text{Phone} = \text{Persistent Personal AI Runtime}.

真正的「本地 AI 主腦手機」必須同時具備：可持續世界狀態、長期個人記憶、多模型路由、可替換本地模型、Agent 工具執行、裝置權限仲裁、跨機器人／眼鏡／電腦的狀態同步，以及在雲端斷線時仍能保持基本智能連續性。

本文因此將手機 AI 的演化分為三階段：AI 功能手機、可部署本地模型的 AI 計算手機，以及個人 AI Runtime 手機。本文主張，2026 年硬體與本地推理 Runtime 已大致進入第二階段，但第三階段真正的瓶頸已從純算力轉向作業系統權限、背景生命週期、記憶體／散熱、模型可替換性、跨應用授權與持久狀態治理。

本文最後提出一個 Personal AI Runtime Phone 參考架構：

\boxed{ \text{Always-on Sensors} \rightarrow \text{Event Bus} \rightarrow \text{World State} \rightarrow \text{Router} \rightarrow \text{Local Model Pool} \rightarrow \text{Permission Broker} \rightarrow \text{Apps / Robots / Devices} }

在這個架構中，手機不再只是 AI 的顯示終端，而成為使用者隨身攜帶的「狀態與智能核心」。

關鍵詞： 本地大語言模型、AI 手機、Gemini Nano、AICore、LiteRT-LM、Snapdragon、Dimensity、Agent Runtime、世界狀態、個人 AI 主腦

1. 先定義：本文說的不是一般「AI 手機」

「AI 手機」這個詞已經被用得太寬。

只要有：

AI 修圖；
通話摘要；
錄音整理；
翻譯；
圈選搜尋；
文字改寫；

都可能被稱為 AI 手機。

本文要討論的不是這一類。

可以先定義三個層級。

Level A：AI Feature Phone

\text{Phone} + \text{AI Features}.

特點：

AI 是若干 App 功能；
模型由 OEM／OS 提供；
使用者通常不能替換核心模型；
記憶主要屬於各 App；
AI 沒有統一世界狀態；
不一定有持久 Agent。

今天大部分量產 AI 手機仍主要在這一層。

Level B：Local Model-Capable Phone

\text{Phone} + \text{Local Model Runtime}.

特點：

可本地部署 LLM／VLM；
可以離線；
可以使用 GPU／NPU；
開發者可選擇模型；
App 能建立自己的 Agent。

2026 年的 Android 已經相當明確進入這一階段。

Level C：Personal AI Runtime Phone

\boxed{ \text{Phone} = \text{Personal AI Runtime} }

特點：

持續世界狀態；
長期記憶；
可替換本地模型；
多模型路由；
系統級 Agent；
跨 App 操作；
權限與風險仲裁；
跨身體狀態同步；
離線仍保持基本人格／任務連續性。

本文真正討論的是 Level C。

2. 2026 年：手機本地生成式 AI 已經是現實

Google 目前的 Android 文件明確指出，Gemini Nano 可以在 Android 裝置本地執行，不必連網，也不必把資料送到雲端。

它不是普通 App 直接自行管理模型，而是運行在：

\text{AICore}

這個 Android 系統服務中。

AICore 負責：

模型分發；
模型更新；
安全處理；
硬體加速；
App 與模型之間的隔離。

因此：

\boxed{ \text{OS-managed on-device foundation model} }

已經正式存在。

這是一個非常重要的歷史節點。

3. Gemini Nano 4：本地模型正在從「摘要器」走向 agentic capability

2026 年 4 月，Android 宣布 Gemma 4 進入 AICore Developer Preview，並指出這些模型將成為下一代 Gemini Nano 4 的基礎。

Android 官方目前也直接使用：

local agentic intelligence

來描述 Gemma 4 的 Android 能力方向，並提到 advanced reasoning 與 tool calling。

到了 2026 年 7 月，Android 官方開發者文章表示，Gemini Nano 已在超過：

140\,\text{million}

台裝置上運行。

這意味著：

裝置端基礎模型已不再只是幾款實驗手機的展示，而開始成為 OS 級基礎設施。

這一點非常關鍵。

因為從「手機有模型」到「手機 OS 有模型服務」只差一步，就會進入：

\text{AI Runtime as System Infrastructure}.

4. 但 AICore 還不是本文所說的 Personal AI Runtime

AICore 很重要，但它目前主要解決：

\text{Model Deployment} + \text{Inference Service}.

它並沒有自動提供：

使用者自定義的完整世界狀態；
跨 App 長期記憶；
任意模型替換；
多機器人共享狀態；
系統級任務生命週期；
完整 Agent 權限治理。

所以：

\boxed{ \text{AICore} \neq \text{Personal Agent OS}. }

它更像 Personal Agent OS 的一個重要底層元件。

5. LiteRT-LM：另一條更開放的路線

Google AI Edge 在 2026 年提供 LiteRT-LM：

在 Android、iOS、Web、Desktop 與 Embedded 裝置上運行本地 LLM。

這與 AICore 很不一樣。

AICore 比較像：

\text{OS-managed model service}.

LiteRT-LM 則更像：

\text{developer-controlled local inference runtime}.

這意味著開發者可以：

自己選模型；
自己打包；
自己控制推理流程；
在支援裝置上離線執行。

因此真正的 Personal AI Runtime 很可能不是二選一。

而是：

\boxed{ \text{System Model Service} + \text{Custom Local Model Runtime} }

共同存在。

6. 一個非常重要的 2026 基準：手機已經可以「像樣地」跑小型 LLM

Google LiteRT-LM 官方 benchmark 中，Gemma-4-E2B：

模型檔約 2.58 GB；
在 Samsung S26 Ultra 上：
- CPU decode 約 47 tokens/s；
- GPU decode 約 52 tokens/s；
- GPU time-to-first-token 約 0.3 秒。

這不是大型 70B 模型。

但這個速度已經足以支援：

即時文字對話；
intent parsing；
task routing；
狀態摘要；
簡單 tool calling；
本地 Agent 決策。

也就是說：

\boxed{ \text{Small Local Agent Model} }

在 2026 年已經不是慢到不可用。

而真正重要的是：

它不需要處理所有問題。

第 5 篇的按需智能意味著，只要小模型能處理大部分高頻事件，大模型便可以稀疏啟動。

7. Qualcomm：手機 SoC 已經開始直接設計「個人 Agent」

Snapdragon 8 Elite Gen 5 的官方定位已經不只寫 generative AI，而明確使用：

\text{personalized Agentic AI}.

其 Sensing Hub 包含：

always-sensing camera；
AI processor；
Personal Scribe；
Personal Knowledge Graph。

Qualcomm 甚至把：

understand and adapt to user habits, preferences, and conversations

直接作為晶片級 agentic AI 使用情境。

更有意思的是，Qualcomm 的 Mobile AI 頁面目前宣稱 Snapdragon 8 Elite Gen 5 已能在手機處理器上運行 GPT-OSS，峰值標示最高約：

20\text{ tokens/s}.

這是廠商公布的特定展示數字，不代表所有手機、所有上下文與所有量化設定都能長時間維持相同速度。

但它至少說明：

\boxed{ \text{20B-class local inference is no longer physically absurd on mobile silicon.} }

真正剩下的是 sustained power、RAM 與產品化問題。

8. MediaTek：always-on AI 與大模型記憶體效率已經進入晶片設計

Dimensity 9500 的官方資料同樣非常值得注意。

它包含：

NPU 990；
Generative AI Engine 2.0；
Transformer 專用處理；
LLM memory compression；
BitNet 1.58-bit model support；
Super-Efficient NPU；
always-on light AI；
最高 128K 級長文字處理能力。

這說明手機 SoC 的設計方向已經從：

\text{camera AI}

逐漸變成：

\boxed{ \text{persistent personal AI workload}. }

尤其是：

\text{always-on light model} + \text{large model on demand}

這與本系列提出的多時間尺度、多模型路由幾乎是同一個工程方向。

9. 真正的瓶頸開始從 TOPS 轉向記憶體

對本地 LLM，粗略的 4-bit 權重估算可以寫成：

M_{\mathrm{weights}} \approx 0.5P\text{ GB},

其中 $P$ 是十億參數。

例如：

模型規模	4-bit 權重粗估
3B	約 1.5 GB
7B	約 3.5 GB
14B	約 7 GB
20B	約 10 GB
32B	約 16 GB

但這只是權重。

實際執行還需要：

KV cache；
runtime；
GPU/NPU buffer；
vision encoder；
ASR/TTS；
Android；
App；
世界狀態；
資料庫。

因此：

M_{\mathrm{runtime}} > M_{\mathrm{weights}}.

所以未來真正的 AI-native phone 很可能需要：

24\text{ GB} \sim 32\text{ GB}

甚至更大的可用記憶體，才能讓較大的本地模型、長上下文與多模態服務同時存在得比較舒服。

這不是對某款未來產品的保證，而是依目前模型記憶體需求所做的工程推估。

10. 但「大 RAM 手機」本身仍然不等於 AI 主腦

就算明天出現：

32\text{ GB RAM} + \text{fast NPU},

仍然缺少最重要的 Runtime。

真正的 Personal AI Phone 必須有：

\mathcal P = ( S, K, R, M, A, D ),

其中：

$S$ ：World State；
$K$ ：Long-term Memory；
$R$ ：Model Router；
$M$ ：Model Pool；
$A$ ：Authority / Permission Runtime；
$D$ ：Device Mesh。

手機晶片只解決：

M

的一部分。

剩下五個結構才真正決定它是不是「個人 AI」。

11. 世界狀態必須成為手機的一級系統

今天手機裡其實已經有大量世界訊號：

時間；
位置；
相機；
麥克風；
藍牙；
Wi-Fi；
通知；
行事曆；
聯絡人；
裝置狀態；
穿戴設備；
汽車；
智慧家庭。

但它們大多分散在各 App 與系統服務中。

Personal AI Runtime 需要建立：

S_t^{\mathrm{personal}}

例如：

current_location
current_device
current_task
active_conversation
nearby_robot
headset_state
calendar_context
user_attention
battery_budget
network_state

其中每一項還應有：

timestamp；
source；
confidence；
permission scope。

於是手機不必每次問 LLM：

我現在在哪裡？剛剛在幹嘛？

它只需要：

\phi(S_t^{\mathrm{personal}})

作為模型上下文。

12. 個人記憶不能只等於聊天紀錄

如果手機真的成為 AI 主腦：

\text{Memory} \neq \text{Chat History}.

至少要分：

K= K_{\mathrm{episodic}} \cup K_{\mathrm{semantic}} \cup K_{\mathrm{procedural}} \cup K_{\mathrm{preference}}.

包括：

事件記憶；
人物／世界知識；
已學技能；
穩定偏好；
長期任務。

同時必須與當前世界狀態區分：

\boxed{ \text{Memory says what happened;} \quad \text{State says what is happening now.} }

這是手機從聊天工具變成長期 Agent 的必要條件。

13. 真正困難的問題其實是 Android 權限

目前 Android 的安全模型刻意假設：

App 不應任意控制其他 App 與整個 OS。

每個 App 都運行在有限權限的 sandbox 中。

要存取：

麥克風；
相機；
聯絡人；
裝置；
其他敏感系統資源；

需要明確權限。

有些權限甚至只允許：

\text{system / signature app}

使用。

這對一般 App 是好事。

但對 Personal AI Runtime 會形成根本矛盾：

如果 AI 不能跨 App、不能管理背景狀態、不能調用系統工具，它就很難成為真正的「主 Agent」。

因此：

\boxed{ \text{AI Phone} }

最終很可能不是靠普通 App 完成。

而需要：

\boxed{ \text{OS-integrated Agent Runtime}. }

14. Background Runtime 也是大問題

Android 長期限制背景執行，原因很合理：

省電；
控制 RAM；
防止 App 長期偷偷運作；
改善使用者體驗。

但 Personal AI 恰恰需要：

\text{persistent background state}.

解法不應是：

讓一個 App 永遠在背景跑 20B 模型。

而應該把系統拆成：

\text{Tiny Always-on Service} + \text{Event Wakeup} + \text{On-demand Model}.

也就是：

世界狀態服務常駐；
低功耗事件偵測常駐；
小 Router 常駐或快速喚醒；
大模型休眠。

這完全吻合手機 OS 原本的省電哲學。

15. 所以真正的 AI 手機 Runtime 應該長這樣

可以建立：

                 Sensors / Apps / Devices
                          │
                          ▼
                    Event Gateway
                          │
                          ▼
               ┌──────────────────┐
               │ Personal World   │
               │ State Runtime    │
               └────────┬─────────┘
                        │
             ┌──────────┴───────────┐
             │                      │
             ▼                      ▼
      Long-term Memory         Model Router
                                    │
             ┌──────────────┬───────┴────────┐
             ▼              ▼                ▼
         Tiny Model     Local Daily LLM   Local Large
                                               │
                                               ▼
                                             Cloud
                                               │
                                               ▼
                                     Structured Proposal
                                               │
                                               ▼
                                        Permission Broker
                                               │
                    ┌──────────────┬───────────┴─────────┐
                    ▼              ▼                     ▼
                   Apps          Robot                 Glasses

核心是：

\boxed{ \text{State First} \rightarrow \text{Model Second} \rightarrow \text{Permission Before Effect}. }

16. Permission Broker 會是比模型更重要的系統元件

假設 AI 說：

「我幫你把門打開。」

這不是普通 tool call。

Runtime 應該檢查：

\operatorname{Allow} ( \text{agent}, \text{action}, \text{resource}, \text{context} ).

例如：

AI 有沒有控制門鎖的權限？
使用者是否在附近？
現在是不是深夜？
是否需要二次確認？
這是高風險操作嗎？
指令是否來自本人？

所以：

\boxed{ \text{Agent Tool Calling} \neq \text{Unrestricted Device Control}. }

真正成熟的 AI Phone 必須有 Agent-specific authority model。

17. 手機最適合成為「主腦」的原因不是 NPU

手機有幾個其他硬體很難同時具備的條件：

\boxed{ \text{Always with the user} }

它同時擁有：

身分驗證；
安全晶片；
5G；
Wi-Fi；
Bluetooth；
UWB；
GPS；
camera；
microphone；
battery；
display；
私人資料；
App ecosystem。

因此手機天然知道：

「這個人的目前數位世界」。

迷你機器人只知道：

「這個房間」。

眼鏡只知道：

「目前視野」。

電腦只知道：

「目前工作環境」。

手機則可以成為：

\boxed{ \text{Personal State Anchor}. }

18. AI 可以換身體，但狀態錨點仍在手機

假設個人 AI 有三個 embodiment：

D= \{ \text{Phone}, \text{Robot}, \text{Glasses} \}.

早上：

AI → phone speaker

出門：

AI → glasses + earbuds

回家：

AI → robot

如果所有長期記憶與世界狀態都存在手機：

S_t^{\mathrm{personal}}

那麼身體切換並不代表：

\text{new AI instance}.

而只是：

\text{change embodiment endpoint}.

這已經開始接近第 8 篇要討論的問題。

19. 本地模型也不應只有一個

一台真正的 AI-native phone 更可能有：

\mathcal M= \{ M_{\mathrm{sense}}, M_{\mathrm{router}}, M_{\mathrm{daily}}, M_{\mathrm{reason}}, M_{\mathrm{cloud}} \}.

例如：

Always-on

M_{\mathrm{sense}}

做：

wake word；
event detection；
attention；
簡單分類。

Router

M_{\mathrm{router}}

判斷：

要不要推理；
用哪一層模型。

Daily

M_{\mathrm{daily}}

處理：

對話；
摘要；
local tools；
日常 Agent 任務。

Reason

M_{\mathrm{reason}}

較大、較耗電，只在必要時喚醒。

Cloud

最後才升級。

因此手機不是：

\text{one model device}.

而是：

\boxed{ \text{model orchestration device}. }

20. 模型可替換性是一條非常重要的分界

今天 AICore 的優點是：

OS 幫你管模型；
App 不需操心部署；
有安全與硬體最佳化。

但真正的 Personal AI Runtime 還需要另一種能力：

使用者是否能選擇自己的模型？

例如：

Daily model = Model A
Coding model = Model B
Private model = Model C
Vision model = Model D

因此未來可能形成：

\text{System Model} + \text{User Model} + \text{Task Model}.

這比「只有一個官方助手」更接近個人計算平台的歷史。

手機當年真正變成電腦，不是因為它可以打電話。

而是因為：

使用者可以裝不同 App。

AI-native phone 真正成熟的類似指標可能是：

使用者可以裝不同模型與 Agent Runtime。

21. NPU 生態仍然沒有完全統一

2026 年 Google LiteRT 的 NPU delegate 文件本身透露出一個重要現實：

不同 Android 廠商的 NPU runtime 仍有差異。

目前 Google 官方已提供／整合 Qualcomm AI Engine Direct delegate，而 Pixel 與 Samsung System LSI 的 NPU delegates 仍列為後續支援。

也就是：

\boxed{ \text{Android NPU ecosystem} }

還沒有完全像：

\text{GPU + standardized API}

那麼透明。

這會直接影響「任意本地模型」跨手機部署的難度。

因此未來真正 AI-native OS 必須把：

\text{model} \rightarrow \text{best available accelerator}

進一步標準化。

22. 散熱會決定「能跑」與「能常用」之間的差異

手機 demo 可以短時間做到：

20\text{ tokens/s},

不代表可以：

20\text{ tokens/s}\times24\text{ hours}.

長期負載會遇到：

thermal throttling；
battery drain；
RAM pressure；
background scheduling。

因此：

\boxed{ \text{Peak Capability} \neq \text{Sustained Personal AI}. }

真正 AI Runtime 的解法仍然是第 5 篇的：

\text{Sparse Invocation}.

大模型應該像：

CPU 的 turbo。

不是：

永遠滿功耗運作。

23. 一個合理的 2026–2030 時間線

以下是基於目前晶片、Runtime 與 OS 發展所做的研究預測，不是確定產品發布資訊。

2026：基礎件已到位

已經存在：

OS-managed on-device model；
custom local LLM runtime；
on-device agentic model；
flagship NPU；
local small-model real-time inference；
always-on light AI。

因此：

\boxed{ \text{hardware feasibility} \approx \text{yes}. }

但 Personal AI Runtime 尚未完整形成。

2027–2028：第一批真正 AI-native phone 很可能出現

較可能具有：

24 GB 或更高記憶體；
多本地模型；
長期記憶；
本地 Agent；
更深 OS tool access；
裝置間 AI continuity；
local/cloud routing。

這個時間區間是工程推估，不是已公布 roadmap。

2028–2030：個人 AI 主機可能成為旗艦機新形態

此時競爭可能不再只是：

\text{camera} + \text{benchmark}.

而是：

你的 AI 記得多少？
離線能做多少？
能不能換模型？
能不能跨設備？
Agent 有多穩定？
世界狀態是否屬於使用者？
能不能把手機當 AI hub？

到這時：

\text{Phone}

才真正可能從「AI 入口」變成：

\boxed{ \text{Personal Intelligence Host}. }

24. 這與 Ryzen AI Max+ 395 的關係

Ryzen AI Max+ 395 本身顯然不是手機晶片。

它的參考意義是：

\boxed{ \text{large shared memory} + \text{heterogeneous compute} }

對本地模型非常重要。

未來手機不可能直接縮成：

128\text{ GB},120\text{ W}

的 AI Max+ 395。

但設計思想可能收斂：

\text{CPU} + \text{GPU} + \text{NPU} + \text{shared memory} + \text{model-aware runtime}.

手機真正需要的是：

把同樣的「本地模型優先」思想壓縮進幾瓦到十幾瓦的持續功耗範圍。

因此 AI PC 與 AI Phone 的差異，未來可能越來越像：

\text{power envelope} + \text{memory ceiling},

而不是「一個能跑 LLM、一個不能」。

25. 最重要的轉變：手機從 App Host 變成 Agent Host

傳統智慧手機：

\text{Phone} = \text{App Host}.

使用者主動：

找 App；
打開；
輸入；
執行；
關閉。

Personal AI Runtime 則可能變成：

\text{Phone} = \text{Agent Host}.

Agent：

持續知道任務；
接收事件；
在權限內調用 App；
按需推理；
在不同裝置切換 embodiment。

於是 App 反而可能逐漸變成：

\text{Agent Tools}.

這不是說 GUI App 會消失。

而是：

App 不再是使用者唯一的執行入口。

這是一個比「手機裡多一個聊天機器人」大得多的轉變。

26. 結論：真正的本地 AI 手機已經不是硬體科幻，而是 Runtime 問題

2026 年已經可以確認：

\boxed{ \text{On-device LLM on phones is real}. }

真正尚未完成的是：

\boxed{ \text{On-device Persistent Personal Agent Runtime}. }

兩者之間的差距主要不再是：

手機晶片夠不夠快？

而是：

世界狀態；
長期記憶；
背景 Runtime；
權限；
模型切換；
多設備同步；
熱與能源；
個人資料治理。

所以本文最後把「AI 本地大語言模型手機」定義為：

\boxed{ \text{AI Phone} = \text{Local Model Pool} + \text{Persistent World State} + \text{Long-term Memory} + \text{Agent Runtime} + \text{Permission Broker} + \text{Device Mesh}. }

當這六個部分同時成立，手機才不只是「能跑本地大模型」。

它會變成：

一個隨身攜帶、持續維持個人世界狀態、可以把智能投射到不同身體上的個人 AI 主機。

因此最後一篇的問題已經自然出現：

如果手機只是狀態錨點，而 AI 可以透過機器人、眼鏡、耳機、汽車與電腦行動，

那麼：

AI 的「身體」到底還是不是單一裝置？

參考資料

Android Developers. Gemini Nano. Updated 2026-04-02.
https://developer.android.com/ai/gemini-nano
Android Developers Blog. Announcing Gemma 4 in the AICore Developer Preview. 2026-04-02.
https://developer.android.com/blog/posts/announcing-gemma-4-in-the-ai-core-developer-preview
Android Developers Blog. Build intelligent Android apps: On-device inference. 2026-07-22.
https://developer.android.com/blog/posts/build-intelligent-android-apps-on-device-inference
Google AI Edge. LiteRT-LM Overview.
https://developers.google.com/edge/litert-lm/overview
Google AI Edge. LiteRT Overview.
https://developers.google.com/edge/litert/overview
Google AI Edge. LiteRT delegate for NPUs. Updated 2026-06-02.
https://developers.google.com/edge/litert/android/npu/overview
Qualcomm. Snapdragon 8 Elite Gen 5 Mobile Platform.
https://www.qualcomm.com/smartphones/products/8-series/snapdragon-8-elite-gen-5
Qualcomm. Mobile AI — Built for Generative AI at the Edge.
https://www.qualcomm.com/smartphones/features/mobile-ai
MediaTek. Dimensity 9500 — Flagship 5G Agentic AI Platform.
https://www.mediatek.com/dimensity-9500
Android Developers. Permissions on Android. Updated 2026-07-14.
https://developer.android.com/guide/topics/permissions/overview
Android Open Source Project. Application Sandbox.
https://source.android.com/docs/security/app-sandbox
Android Developers. Background Execution Limits. Updated 2026-03-03.
https://developer.android.com/about/versions/oreo/background

07_本地大語言模型手機_從AI功能手機到個人AI_Runtime